I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras — families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting — saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms — you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.
Сегодня случайно наткнулся на Elements of Programming. Полистал — очень интересная и глубокая книга. C++ знаю очень слабо. Но именно эта книга вызвала интерес и заставила задаться вопросом — почему Степанов выбрал именно этот язык? Появилась мысль — может просто раньше не видел чего-то в C++, что дает ему неоспоримые преимущества... Или это просто так исторически сложилось — далекие времена, авторство STL, мейнстрим... Но если причина не эта, то опять — почему C++? Почему объяснять такие вещи на нем, а не взять тот же Haskell. И вот та цитата вначале — критика ООП Степановым — еще один повод отказаться от этого языка. Конечно C++ мультипарадигменный, но в нем отсутствуют вещи, которые были в ФЯ изначально и теперь постепенно перетекают в мейнстрим. Хотелось бы услышать ваши мысли, мысли людей, которые разбираются гораздо лучше меня в этом вопросе.
P.S. И кстати, посоветуйте стоящую книгу по современному C++. На всякий случай.
Re: Alexander Stepanov, Elements of Programming, C++, мысли
Здравствуйте, frontsquat, Вы писали:
F>почему Степанов выбрал именно этот язык?
Очевидно, что STL была им написана после знакомства с каким-то ФЯ. Значит вынуждено, потому что тот ФЯ в то время не удовлетворял каким-то требованиям. Остаётся определать требования.
Проверяем гипотезу в Википедии:
C++ seemed more likely to become widely used and provide good support for generic programming even though the language was relatively immature. Another reason for turning to C++, which Stepanov recognized early on, was the C/C++ model of computation which allows very flexible access to storage via pointers is crucial to achieving generality without losing efficiency.
То есть не хватало скорости, если даже перенос некоторых вещей (инициализация контейнеров) в рантайм С++ все равно давал превосходство.
F>P.S. И кстати, посоветуйте стоящую книгу по современному C++. На всякий случай.
Современный... еще не приняли стандарт Возможно, стоит читать "Дизайн и Эволюция..." Страуструпа, что бы понять как развивался\ется С++, а так же причины такого развития и всех проблем на его пути: поддержка массы legacy кода и мифа "0й оверхед".
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re: Alexander Stepanov, Elements of Programming, C++, мысли
Здравствуйте, frontsquat, Вы писали:
F>Сегодня случайно наткнулся на Elements of Programming. Полистал — очень интересная и глубокая книга. C++ знаю очень слабо. Но именно эта книга вызвала интерес и заставила задаться вопросом — почему Степанов выбрал именно этот язык? Появилась мысль — может просто раньше не видел чего-то в C++, что дает ему неоспоримые преимущества... Или это просто так исторически сложилось — далекие времена, авторство STL, мейнстрим... Но если причина не эта, то опять — почему C++? Почему объяснять такие вещи на нем, а не взять тот же Haskell. И вот та цитата вначале — критика ООП Степановым — еще один повод отказаться от этого языка. Конечно C++ мультипарадигменный, но в нем отсутствуют вещи, которые были в ФЯ изначально и теперь постепенно перетекают в мейнстрим. Хотелось бы услышать ваши мысли, мысли людей, которые разбираются гораздо лучше меня в этом вопросе.
Все просто: C++ – единственный на сегодня язык, позволяющий эффективно использовать generic programming. С++ он ни в коей мере идеалом он не считает, но лучшего языка для GP найти не может. Степанову не нравятся языки, которые не позволяют по полному использовать железо (x86, то есть), и строят над ним свои абстракции. Лучшей абстракцией над железом он считает "Си-машину". Если поискать, можно найти его высказывания на эту тему (stepanovpapers.com).
P.S. Степанов начинал на схеме, и пришел к С++, в отличие от многих.
--
In code we trust.
Re: Alexander Stepanov, Elements of Programming, C++, мысли
Здравствуйте, frontsquat, Вы писали:
F>Приветствую всех.
F>Позвольте начать с цитаты. F>
F>I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras — families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting — saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms — you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.
F>Сегодня случайно наткнулся на Elements of Programming. Полистал — очень интересная и глубокая книга. C++ знаю очень слабо. Но именно эта книга вызвала интерес и заставила задаться вопросом — почему Степанов выбрал именно этот язык? Появилась мысль — может просто раньше не видел чего-то в C++, что дает ему неоспоримые преимущества... Или это просто так исторически сложилось — далекие времена, авторство STL, мейнстрим... Но если причина не эта, то опять — почему C++? Почему объяснять такие вещи на нем, а не взять тот же Haskell. И вот та цитата вначале — критика ООП Степановым — еще один повод отказаться от этого языка. Конечно C++ мультипарадигменный, но в нем отсутствуют вещи, которые были в ФЯ изначально и теперь постепенно перетекают в мейнстрим. Хотелось бы услышать ваши мысли, мысли людей, которые разбираются гораздо лучше меня в этом вопросе.
frontsquat пишет:
> глубокая книга. C++ знаю очень слабо. Но именно эта книга вызвала > интерес и заставила задаться вопросом — почему Степанов выбрал именно > этот язык? Появилась мысль — может просто раньше не видел чего-то в C++,
Где это он его выбрал ?
Posted via RSDN NNTP Server 2.1 beta
Re[2]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, MasterZiv, Вы писали:
>> глубокая книга. C++ знаю очень слабо. Но именно эта книга вызвала >> интерес и заставила задаться вопросом — почему Степанов выбрал именно >> этот язык? Появилась мысль — может просто раньше не видел чего-то в C++,
MZ>Где это он его выбрал ?
Для этой книги в частности и для своих экспериментов вообще. Тут уже пояснили его стремление к низкоуровневости и эффективности. Тогда выбор понятен. Но вся эта возня с указателями, ручным управлением памятью и т.п. кажется шагом возможно и не назад, но как минимум вбок. Создание более высоких абстракций и поиск их эффективных реализаций на низком уровне — мне кажется более правильным направлением. Короче — Haskell.
Re: Alexander Stepanov, Elements of Programming, C++, мысли
Сегодня случайно наткнулся на Elements of Programming. Полистал — очень интересная и глубокая книга. C++ знаю очень слабо. Но именно эта книга вызвала интерес и заставила задаться вопросом — почему Степанов выбрал именно этот язык?
Это надо у него спросить . Возможно, он просто его лучше всего знает? Более 20 лет использовал, соавтор STL.
Появилась мысль — может просто раньше не видел чего-то в C++, что дает ему неоспоримые преимущества...
По сводкам с полей серебряная пуля до сих пор не найдена. Большинство языков и технологий имеют как плюсы, так и минусы. Они как правило предназначены для специфических задач. Скорее всего, для решения математических задач на суперкомпьютере, где очень важна скорость выполнения, c/c++ имеют неоспоримые преимущества .
И вот та цитата вначале — критика ООП Степановым — еще один повод отказаться от этого языка
Я правильно понимаю, что автор цитаты и автор книги — один и тот же человек?
Конечно C++ мультипарадигменный, но в нем отсутствуют вещи, которые были в ФЯ изначально и теперь постепенно перетекают в мейнстрим. Хотелось бы услышать ваши мысли, мысли людей, которые разбираются гораздо лучше меня в этом вопросе.
Мысли о чем? О том что С++ мультипарадигменный или что функциональное программирование ползет в мейнстрим? . Вы бы уточнили чего хотите.
И кстати, посоветуйте стоящую книгу по современному C++. На всякий случай.
Google it?
Лично я такой книги не встречал, все что видел — справочники, косноязычно и с трудом рассказывающие про синтаксис . Да, и книжка Страуструпа по косноязычаю на первом месте. Понять то, что он пишет, можно только уже владея языком на очень хорошем уровне. Это мое ИМХО, естественно .
Re[3]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, frontsquat, Вы писали:
F>Здравствуйте, MasterZiv, Вы писали:
>>> глубокая книга. C++ знаю очень слабо. Но именно эта книга вызвала >>> интерес и заставила задаться вопросом — почему Степанов выбрал именно >>> этот язык? Появилась мысль — может просто раньше не видел чего-то в C++,
MZ>>Где это он его выбрал ?
F>Для этой книги в частности и для своих экспериментов вообще. Тут уже пояснили его стремление к низкоуровневости и эффективности. Тогда выбор понятен. Но вся эта возня с указателями, ручным управлением памятью и т.п. кажется шагом возможно и не назад, но как минимум вбок. Создание более высоких абстракций и поиск их эффективных реализаций на низком уровне — мне кажется более правильным направлением. Короче — Haskell.
Казалось бы, причем тут haskell...
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[2]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, Тролль зеленый и толстый, Вы писали:
ТЗИ>Очевидно, чувак просто не врубается в концепцию ООП, при этом строит из себя умного, составляя тяжеловесные рассуждения.
<troll mode>
А во что там врубаться? Концпеция ООП замкнута на неопределённость: всё есть объекты, они обмениваются сообщениями, сами объекты состоят из объектов, обменивающихся сообщениями, а сообщения представляют собой объекты, обменивающиеся сообщениями. На колу мочало...
</troll mode>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Alexander Stepanov, Elements of Programming, C++, мыс
Сегодня случайно наткнулся на Elements of Programming. Полистал — очень интересная и глубокая книга. C++ знаю очень слабо. Но именно эта книга вызвала интерес и заставила задаться вопросом — почему Степанов выбрал именно этот язык?
EOH>Это надо у него спросить . Возможно, он просто его лучше всего знает? Более 20 лет использовал, соавтор STL.
Он сам говорит, что С++ не знает. Что изучил в одной книжке краткое описание на 9 страниц, им и пользуется.
Re[3]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Тролль зеленый и толстый, Вы писали:
ТЗИ>>Очевидно, чувак просто не врубается в концепцию ООП, при этом строит из себя умного, составляя тяжеловесные рассуждения.
ГВ><troll mode> ГВ>А во что там врубаться? Концпеция ООП замкнута на неопределённость: всё есть объекты, они обмениваются сообщениями, сами объекты состоят из объектов, обменивающихся сообщениями, а сообщения представляют собой объекты, обменивающиеся сообщениями. На колу мочало... ГВ></troll mode>
Забудьте про объекты. Это неверное представление об ООП. Думать о программе в терминах объектов — означает использовать не слишком высокий уровень абстракции. ООП — это абстрактные интерфейсы. Правильнее даже сказать — сервисы. Все. Точка. То, что за этими сервисами торчат объекты с состоянием (или без?) — лишь детали. Которые не должны интересовать архитектора системы.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[4]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, LaPerouse, Вы писали:
LP>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Здравствуйте, Тролль зеленый и толстый, Вы писали:
ТЗИ>>>Очевидно, чувак просто не врубается в концепцию ООП, при этом строит из себя умного, составляя тяжеловесные рассуждения.
ГВ>><troll mode> ГВ>>А во что там врубаться? Концпеция ООП замкнута на неопределённость: всё есть объекты, они обмениваются сообщениями, сами объекты состоят из объектов, обменивающихся сообщениями, а сообщения представляют собой объекты, обменивающиеся сообщениями. На колу мочало... ГВ>></troll mode>
LP>Забудьте про объекты. Это неверное представление об ООП. Думать о программе в терминах объектов — означает использовать не слишком высокий уровень абстракции. ООП — это абстрактные интерфейсы. Правильнее даже сказать — сервисы. Все. Точка. То, что за этими сервисами торчат объекты с состоянием (или без?) — лишь детали. Которые не должны интересовать архитектора системы.
SOA — вот самый правильный ООП.
Re[4]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, LaPerouse, Вы писали:
ГВ>><troll mode> ГВ>>А во что там врубаться? Концпеция ООП замкнута на неопределённость: всё есть объекты, они обмениваются сообщениями, сами объекты состоят из объектов, обменивающихся сообщениями, а сообщения представляют собой объекты, обменивающиеся сообщениями. На колу мочало... ГВ>></troll mode>
LP>Забудьте про объекты. Это неверное представление об ООП. Думать о программе в терминах объектов — означает использовать не слишком высокий уровень абстракции. ООП — это абстрактные интерфейсы. Правильнее даже сказать — сервисы. Все. Точка. То, что за этими сервисами торчат объекты с состоянием (или без?) — лишь детали. Которые не должны интересовать архитектора системы.
Неисчислимы пути сумасбродных затей, неисчислимы...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, LaPerouse, Вы писали:
LP>>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>Здравствуйте, Тролль зеленый и толстый, Вы писали:
ТЗИ>>>>Очевидно, чувак просто не врубается в концепцию ООП, при этом строит из себя умного, составляя тяжеловесные рассуждения.
ГВ>>><troll mode> ГВ>>>А во что там врубаться? Концпеция ООП замкнута на неопределённость: всё есть объекты, они обмениваются сообщениями, сами объекты состоят из объектов, обменивающихся сообщениями, а сообщения представляют собой объекты, обменивающиеся сообщениями. На колу мочало... ГВ>>></troll mode>
LP>>Забудьте про объекты. Это неверное представление об ООП. Думать о программе в терминах объектов — означает использовать не слишком высокий уровень абстракции. ООП — это абстрактные интерфейсы. Правильнее даже сказать — сервисы. Все. Точка. То, что за этими сервисами торчат объекты с состоянием (или без?) — лишь детали. Которые не должны интересовать архитектора системы.
G>SOA — вот самый правильный ООП.
Именно.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[5]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, LaPerouse, Вы писали:
ГВ>>><troll mode> ГВ>>>А во что там врубаться? Концпеция ООП замкнута на неопределённость: всё есть объекты, они обмениваются сообщениями, сами объекты состоят из объектов, обменивающихся сообщениями, а сообщения представляют собой объекты, обменивающиеся сообщениями. На колу мочало... ГВ>>></troll mode>
LP>>Забудьте про объекты. Это неверное представление об ООП. Думать о программе в терминах объектов — означает использовать не слишком высокий уровень абстракции. ООП — это абстрактные интерфейсы. Правильнее даже сказать — сервисы. Все. Точка. То, что за этими сервисами торчат объекты с состоянием (или без?) — лишь детали. Которые не должны интересовать архитектора системы.
ГВ>Неисчислимы пути сумасбродных затей, неисчислимы...
В самом деле поразвелось всяких DI-фреймворков понимаешь... Что людям делать что ли нечего?
PS Как только ты сказал слово "объект", можешь забыть о модульности.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[6]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, LaPerouse, Вы писали:
LP>PS Как только ты сказал слово "объект", можешь забыть о модульности.
Почему?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ><troll mode> ГВ>А во что там врубаться? Концпеция ООП замкнута на неопределённость: всё есть объекты, они обмениваются сообщениями, сами объекты состоят из объектов, обменивающихся сообщениями, а сообщения представляют собой объекты, обменивающиеся сообщениями. На колу мочало... ГВ></troll mode>
Смолток?
Re[7]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, LaPerouse, Вы писали: LP>>PS Как только ты сказал слово "объект", можешь забыть о модульности. ГВ>Почему?
Потому что завязываешься на реализацию.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[3]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, Eye of Hell, Вы писали:
EOH>Ну говорить он может что угодно. Я правильно понимаю что он соавтор STL? Довольно трудно разрабатывать библиотеку к языку, которого ты не знаешь .
Запросто, особенно если она уже была разработана на другом языке.
Re[8]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, LaPerouse, Вы писали:
ГВ>>Здравствуйте, LaPerouse, Вы писали: LP>>>PS Как только ты сказал слово "объект", можешь забыть о модульности. ГВ>>Почему?
LP>Потому что завязываешься на реализацию.
Объекты нельзя группировать в модули? Я что-то пропустил в устройстве мироздания?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[4]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, dsorokin, Вы писали:
ГВ>><troll mode> ГВ>>А во что там врубаться? Концпеция ООП замкнута на неопределённость: всё есть объекты, они обмениваются сообщениями, сами объекты состоят из объектов, обменивающихся сообщениями, а сообщения представляют собой объекты, обменивающиеся сообщениями. На колу мочало... ГВ>></troll mode>
D>Смолток?
Ну да, есть такая штука. Одно из воплощений ООП.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[9]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, LaPerouse, Вы писали:
ГВ>>>Здравствуйте, LaPerouse, Вы писали: LP>>>>PS Как только ты сказал слово "объект", можешь забыть о модульности. ГВ>>>Почему? LP>>Потому что завязываешься на реализацию. ГВ>Объекты нельзя группировать в модули? Я что-то пропустил в устройстве мироздания?
Можно, но если ты завяжешься на сам объект, а не его интерфейс, у тебя будет гнилой монолитный дизайн, не подлежащий рефакторингу — раз, замене одних модулей другими без правки и пересборки — два.
Работа с объектами сводится к двум операциям:
1. Создание объекта
2. Работа с ним через его интерфейс
Первое — это тонкий момент, если ты создаешь объект явно, ты завязываешься на реализацию. По факту создание объекта нужно перепоручать фабрикам и DI-контейнерам. Остается второе — работа с объектом через его интерфейс. Понятие объекта по сути растворяется — у тебя есть некий сервис, определяемый интерфейсом объекта (компоненты), и ты в терминах этого (и других) сервисов определяешь поведение своего объекта (компоненты). Мы абстрагированы от объекта средой, которая за нас создает и биндит объекты в наш объект (компоненту). Мы лишь описываем декларативно (в xml-файле например), от каких сервисов зависит наш объект. Вся система представляет из себя ориентированный граф, в котором вершинами являются компоненты (модули), исходящие из модуля стрелки определяют сервисы, реализуемые данным модулем, а входящие в модуль стрелки — сервисы, потребляемые данным модулем для реализации своих сервисов.
Здравствуйте, LaPerouse, Вы писали:
LP>>>>>PS Как только ты сказал слово "объект", можешь забыть о модульности. ГВ>>>>Почему? LP>>>Потому что завязываешься на реализацию. ГВ>>Объекты нельзя группировать в модули? Я что-то пропустил в устройстве мироздания? LP>Можно, но если ты завяжешься на сам объект, а не его интерфейс, у тебя будет гнилой монолитный дизайн, не подлежащий рефакторингу — раз, замене одних модулей другими без правки и пересборки — два.
С чего ты взял, что: а) игнорируется интерфейс, б) дизайн не предусмотрит замену одних объектов другими? Вроде как, это классика дизайна ПО.
LP>Работа с объектами сводится к двум операциям: LP>1. Создание объекта LP>2. Работа с ним через его интерфейс
LP>Первое — это тонкий момент, если ты создаешь объект явно, ты завязываешься на реализацию. По факту создание объекта нужно перепоручать фабрикам и DI-контейнерам. Остается второе — работа с объектом через его интерфейс. Понятие объекта по сути растворяется — у тебя есть некий сервис, определяемый интерфейсом объекта (компоненты), и ты в терминах этого (и других) сервисов определяешь поведение своего объекта (компоненты).
Какой ещё сервис? Я могу положить объект в массив, присвоить переменной значение объектного типа, сравнить (ужас!) объекты. Где это всё в абстракции "сервисов", которая, если судить по твоим словам отрицает такие любопытнейшие явления, как "жизненный цикл", "состояние", "экземпляр"?
LP>Мы абстрагированы от объекта средой, которая за нас создает и биндит объекты в наш объект (компоненту). Мы лишь описываем декларативно (в xml-файле например), от каких сервисов зависит наш объект. Вся система представляет из себя ориентированный граф, в котором вершинами являются компоненты (модули), исходящие из модуля стрелки определяют сервисы, реализуемые данным модулем, а входящие в модуль стрелки — сервисы, потребляемые данным модулем для реализации своих сервисов.
LP>Смотри например устройство декларативных сервисов OSGi 4.2 (http://www.osgi.org/Release4/Download) или Spring.
А вот теперь начинаем долго медленно думать, почему в основе OSGi всё же лежит Java, объектно-ориентированная до мозга интерфейса. Как-то не склеивается парадигма.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, gandjustas, Вы писали:
LP>>Забудьте про объекты. Это неверное представление об ООП. Думать о программе в терминах объектов — означает использовать не слишком высокий уровень абстракции. ООП — это абстрактные интерфейсы. Правильнее даже сказать — сервисы. Все. Точка. То, что за этими сервисами торчат объекты с состоянием (или без?) — лишь детали. Которые не должны интересовать архитектора системы.
G>SOA — вот самый правильный ООП.
SOA — самый правильный способ связать старые не переписываемые софтины в одну кучу.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: Alexander Stepanov, Elements of Programming, C++, мы
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, LaPerouse, Вы писали:
LP>>>>>>PS Как только ты сказал слово "объект", можешь забыть о модульности. ГВ>>>>>Почему? LP>>>>Потому что завязываешься на реализацию. ГВ>>>Объекты нельзя группировать в модули? Я что-то пропустил в устройстве мироздания? LP>>Можно, но если ты завяжешься на сам объект, а не его интерфейс, у тебя будет гнилой монолитный дизайн, не подлежащий рефакторингу — раз, замене одних модулей другими без правки и пересборки — два.
ГВ>С чего ты взял, что: а) игнорируется интерфейс, б) дизайн не предусмотрит замену одних объектов другими? Вроде как, это классика дизайна ПО.
Я так понял с твоих слов, что ты не видишь ничего плохого в непосредственном создании объектов.
LP>>Работа с объектами сводится к двум операциям: LP>>1. Создание объекта LP>>2. Работа с ним через его интерфейс
LP>>Первое — это тонкий момент, если ты создаешь объект явно, ты завязываешься на реализацию. По факту создание объекта нужно перепоручать фабрикам и DI-контейнерам. Остается второе — работа с объектом через его интерфейс. Понятие объекта по сути растворяется — у тебя есть некий сервис, определяемый интерфейсом объекта (компоненты), и ты в терминах этого (и других) сервисов определяешь поведение своего объекта (компоненты).
ГВ>Какой ещё сервис? Я могу положить объект в массив, присвоить переменной значение объектного типа, сравнить (ужас!) объекты. Где это всё в абстракции "сервисов", которая, если судить по твоим словам отрицает такие любопытнейшие явления, как "жизненный цикл", "состояние", "экземпляр"?
Все эти операции доступны, сервис — лишь абстракция. Жизненный цикл компоненты может управляться средой (если объект статический) или динамически через предоставляемый средой фабричный сервис.
LP>>Мы абстрагированы от объекта средой, которая за нас создает и биндит объекты в наш объект (компоненту). Мы лишь описываем декларативно (в xml-файле например), от каких сервисов зависит наш объект. Вся система представляет из себя ориентированный граф, в котором вершинами являются компоненты (модули), исходящие из модуля стрелки определяют сервисы, реализуемые данным модулем, а входящие в модуль стрелки — сервисы, потребляемые данным модулем для реализации своих сервисов. LP>>Смотри например устройство декларативных сервисов OSGi 4.2 (http://www.osgi.org/Release4/Download) или Spring.
ГВ>А вот теперь начинаем долго медленно думать, почему в основе OSGi всё же лежит Java, объектно-ориентированная до мозга интерфейса. Как-то не склеивается парадигма.
Ничего не понял.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[12]: Alexander Stepanov, Elements of Programming, C++, мы
Здравствуйте, LaPerouse, Вы писали:
LP>>>Можно, но если ты завяжешься на сам объект, а не его интерфейс, у тебя будет гнилой монолитный дизайн, не подлежащий рефакторингу — раз, замене одних модулей другими без правки и пересборки — два. ГВ>>С чего ты взял, что: а) игнорируется интерфейс, б) дизайн не предусмотрит замену одних объектов другими? Вроде как, это классика дизайна ПО. LP>Я так понял с твоих слов, что ты не видишь ничего плохого в непосредственном создании объектов.
Видимо, я плохо сформулировал, хотя, меня здесь извиняет то, что я не предполагал рассказывать азы проектироваия ПО. Да, я против (резко против!) излишней связности, которая, в частности, проявляется в прямом указании типа создаваемого объекта. С другой стороны, иногда это весьма полезно.
ГВ>>Какой ещё сервис? Я могу положить объект в массив, присвоить переменной значение объектного типа, сравнить (ужас!) объекты. Где это всё в абстракции "сервисов", которая, если судить по твоим словам отрицает такие любопытнейшие явления, как "жизненный цикл", "состояние", "экземпляр"?
LP>Все эти операции доступны, сервис — лишь абстракция. Жизненный цикл компоненты может управляться средой (если объект статический) или динамически через предоставляемый средой фабричный сервис.
Если они доступны, то вопрос — как? Неужто ради, например, контейнеров нужно заводить сервис ContainerProvider?
LP>>>Смотри например устройство декларативных сервисов OSGi 4.2 (http://www.osgi.org/Release4/Download) или Spring. ГВ>>А вот теперь начинаем долго медленно думать, почему в основе OSGi всё же лежит Java, объектно-ориентированная до мозга интерфейса. Как-то не склеивается парадигма. LP>Ничего не понял.
А что тут не ясного? Java — ОО-язык (мопед не мой, но под такой маркой он продаётся), на Java построен фреймворк OSGi, насквозь сервисный. Почему из этого следует, что SOA есть истинное ООП — тайна, недоступная моему ничтожному разуму.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: Alexander Stepanov, Elements of Programming, C++, мыс
Сегодня случайно наткнулся на Elements of Programming. Полистал — очень интересная и глубокая книга. C++ знаю очень слабо. Но именно эта книга вызвала интерес и заставила задаться вопросом — почему Степанов выбрал именно этот язык?
EOH>>Это надо у него спросить . Возможно, он просто его лучше всего знает? Более 20 лет использовал, соавтор STL. DM>Он сам говорит, что С++ не знает. Что изучил в одной книжке краткое описание на 9 страниц, им и пользуется.
Что-то мне подсказывает, что это изощрённый стёб. Знаешь, что-то вроде premature optmization (далее по тексту). Или, скажем так, априорный контраргумент тем, кто гундосит, что, мол, для изучения C++ нужно знать наизусть 1500 (или сколько их там?) страниц стандарта, потому ы-ы-ы-ы... специалистов нет, всё пло-о-о-охо, нужны обезья-а-анки, хнык-хнык-хнык-хнык.
В прочем, это догадки, я просто люблю лёгкий цинизм в исполнении старшего поколения. У них это получается изящно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, pgregory, Вы писали:
P>Все просто: C++ – единственный на сегодня язык, позволяющий эффективно использовать generic programming. С++ он ни в коей мере идеалом он не считает, но лучшего языка для GP найти не может. Степанову не нравятся языки, которые не позволяют по полному использовать железо (x86, то есть), и строят над ним свои абстракции. Лучшей абстракцией над железом он считает "Си-машину".
Язык си вобщем то сильнейшая вещь своего времени. Куда сильнее всяких лиспов.
>Если поискать, можно найти его высказывания на эту тему (stepanovpapers.com).
P>P.S. Степанов начинал на схеме, и пришел к С++, в отличие от многих.
Вот бы узнать у него, чем ему схемы эти не понравились.
Re[3]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, Ikemefula, Вы писали:
P>>P.S. Степанов начинал на схеме, и пришел к С++, в отличие от многих.
I>Вот бы узнать у него, чем ему схемы эти не понравились.
Думаю, все просто — полезнее делать библиотеку для языка, которым действительно пользуются люди.
Re[4]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, Геннадий Васильев, Вы писали:
EOH>>>Это надо у него спросить . Возможно, он просто его лучше всего знает? Более 20 лет использовал, соавтор STL. DM>>Он сам говорит, что С++ не знает. Что изучил в одной книжке краткое описание на 9 страниц, им и пользуется.
ГВ>Что-то мне подсказывает, что это изощрённый стёб. Знаешь, что-то вроде premature optmization (далее по тексту). Или, скажем так, априорный контраргумент тем, кто гундосит, что, мол, для изучения C++ нужно знать наизусть 1500 (или сколько их там?) страниц стандарта, потому ы-ы-ы-ы... специалистов нет, всё пло-о-о-охо, нужны обезья-а-анки, хнык-хнык-хнык-хнык.
ГВ>В прочем, это догадки, я просто люблю лёгкий цинизм в исполнении старшего поколения. У них это получается изящно.
Тогда рекомендую посмотреть видео его недавних лекций в яндексе. Он там рассказывает и про раздутый стандарт, и про принимающий его комитет. Что-то вроде: куча людей, которые ничего не знают, но обо всем имеют мнение.
Re[5]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, D. Mon, Вы писали:
DM>Тогда рекомендую посмотреть видео его недавних лекций в яндексе. Он там рассказывает и про раздутый стандарт, и про принимающий его комитет. Что-то вроде: куча людей, которые ничего не знают, но обо всем имеют мнение.
Ссылкой не поделишься?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: Alexander Stepanov, Elements of Programming, C++, мыс
Судя по этомувсе было более прозаично . Просто ему предложили работу сделать что-то для плюсов. Причем у плюсов даже не было подходящего инстумента для этого в то время:
Then I was offered a job at Bell Laboratories working in the C++ group on C++ libraries. They asked me whether I could do it in C++. Of course, I didn't know C++ and, of course, I said I could. But I couldn't do it in C++, because in 1987 C++ didn't have templates, which are essential for enabling this style of programming. Inheritance was the only mechanism to obtain genericity and it was not sufficient.
Перед этим он делал уже большие библиотеки, используя, как он говорит, high order and generic programming, на Scheme и Ada.
Re[3]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, frontsquat, Вы писали:
F>Для этой книги в частности и для своих экспериментов вообще. Тут уже пояснили его стремление к низкоуровневости и эффективности. Тогда выбор понятен. Но вся эта возня с указателями, ручным управлением памятью и т.п. кажется шагом возможно и не назад, но как минимум вбок. Создание более высоких абстракций и поиск их эффективных реализаций на низком уровне — мне кажется более правильным направлением. Короче — Haskell.
Какие у Хаскеля есть средства для реализации "их эффективных реализаций на низком уровне"?
Главное гармония ...
Re[2]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, Тролль зеленый и толстый, Вы писали:
ТЗИ>Очевидно, чувак просто не врубается в концепцию ООП, при этом строит из себя умного, составляя тяжеловесные рассуждения.
Здравствуйте, LaPerouse, Вы писали:
LP>ООП — это абстрактные интерфейсы.
Хочу понять, что именно имеется в виду, и потому задаю вопрос: можно ли struct, члены которого являются указателями на функции, рассматривать как абстрактный интерфейс?
Re[4]: Alexander Stepanov, Elements of Programming, C++, мыс
LP>Забудьте про объекты. Это неверное представление об ООП. Думать о программе в терминах объектов — означает использовать не слишком высокий уровень абстракции. ООП — это абстрактные интерфейсы. Правильнее даже сказать — сервисы. Все. Точка. То, что за этими сервисами торчат объекты с состоянием (или без?) — лишь детали. Которые не должны интересовать архитектора системы.
Это тебя занесло сначала в компонентное программирование, которое есть подвид ООП с кучей ограничений.
Re[10]: Alexander Stepanov, Elements of Programming, C++, мы
Здравствуйте, LaPerouse, Вы писали:
LP>Можно, но если ты завяжешься на сам объект, а не его интерфейс, у тебя будет гнилой монолитный дизайн, не подлежащий рефакторингу — раз, замене одних модулей другими без правки и пересборки — два.
Что-то ты масло маслянное порешь, извини. Разве публичный АПИ объекта не есть его интерфейс в терминах ООП? Разве у объектов не бывает виртуальных и абстрактных методов? Разве нет технологии множественного наследования и разве нет вырожденного полностью абстрактного объекта, все методы которого совпадают с его интерфейсом, и названным для простоты этим же словом?
LP>Работа с объектами сводится к двум операциям: LP>1. Создание объекта LP>2. Работа с ним через его интерфейс
Мы всегда работаем с объектом через его интерфейс, по другому — это хаки и рефлекшн.
LP>Первое — это тонкий момент, если ты создаешь объект явно, ты завязываешься на реализацию. По факту создание объекта нужно перепоручать фабрикам и DI-контейнерам.
Единственная разумная мысль, но к обсуждаемому слабо относится. Да, посредством фабрик улучшается инкапсуляция, уменьшается связанность, но фабрика одинаково хороша как для объектов, так и для твоих "интерфейсов".
LP>Остается второе — работа с объектом через его интерфейс. Понятие объекта по сути растворяется — у тебя есть некий сервис, определяемый интерфейсом объекта (компоненты), и ты в терминах этого (и других) сервисов определяешь поведение своего объекта (компоненты).
Опять каша в голове. Объект и так — черный ящик. Ты не можешь точно сказать (кроме случаев, когда сам создал объект), с чем ты работаешь — с самим объектом, или его наследником. И тут пофиг, через твои "интерфейсы" ты с ним работаешь, или через некий публичный АПИ. Разница есть только для сред, типа .Net, где методы "интерфейсов" и объектов по разному компилятся в байт-код, но с т.з. исходника и тем паче программиста — никакой разницы. А в том же С++ так вообще никакой разницы нет м/у интерфейсом и обычным типом, есть просто множественное наследование, т.е. в случае наличия несколько публичных баз, объект располагает их несколькими публичными АПИ. Ну то бишь "интерфейсами" в твоей терминологии. В моей кстати тоже, за что я С++ и люблю, ибо он куда как более правильный ООП, чем все джавы и дотнеты вместе взятые (которые скорее компонентны, ибо нессиметричны в дизайне, относительно баз объекта).
LP>Мы абстрагированы от объекта средой, которая за нас создает и биндит объекты в наш объект (компоненту). Мы лишь описываем декларативно (в xml-файле например), от каких сервисов зависит наш объект. Вся система представляет из себя ориентированный граф, в котором вершинами являются компоненты (модули), исходящие из модуля стрелки определяют сервисы, реализуемые данным модулем, а входящие в модуль стрелки — сервисы, потребляемые данным модулем для реализации своих сервисов.
Хороши были грибы... Только к ООП тут ничего не относится из озвученного. Вернее относится, но лишь к миниатюрному его подмножеству, называемому — компонентное программирование, и то, ты его неплохо грибами приправил. КОП — хорошее такое подмножество для систем верхнего уровня, и большая такая гиря на ногах при реализации прикладной логики. Тот самый "abstraction penalty" бъет по КОП, как ни по чему другому, поэтому надо понимать, где он хорош, а где — лишь дань фанатизму или ангажированности, например ввиду влияния какой-нить наполненной громкими высказываниями книжки на неокрепший мозг.
LP>Смотри например устройство декларативных сервисов OSGi 4.2 (http://www.osgi.org/Release4/Download) или Spring.
А это уже надстройка над языком. Работая вне системы типов языка, мы получаем такую же бодягу, как в случае скриптовых слаботипизированных языков. По сути, эти XML — и есть кривая разновидность скриптинга. Кривая, потому как XML — не самый удобный язык для требуемого декларативного скриптинга, есть куча куда как более удобных. ИМХО, просто на момент разработки Spring еще не было достаточно хорошего скриптинга на платформе Java, взяли что было. Ну или от непонимания происходящего.
Re[4]: Alexander Stepanov, Elements of Programming, C++, мыс
Здравствуйте, heavyweapondude, Вы писали:
H>Просто ему предложили работу сделать что-то для плюсов. Причем у плюсов даже не было подходящего инстумента для этого в то время... H>...
Ему, как гуру, предложили сделать качественную либу для нового языка.
H>Перед этим он делал уже большие библиотеки, используя, как он говорит, high order and generic programming, на Scheme и Ada.
Там же в интервью: отказ от ФЯ был осознанным решением (а не просто пришлось)! И там же причины!
Зы: Некоторым местным любителям ФЯ, похоже, еще долго прогрессировать до аналогичных выводов
На всякий случай. 
Возможно, стоит читать "Дизайн и Эволюция..." Страуструпа, что бы понять как развивался\ется С++, а так же причины такого развития и всех проблем на его пути: поддержка массы legacy кода и мифа "0й оверхед".
. Да, и книжка Страуструпа по косноязычаю на первом месте. Понять то, что он пишет, можно только уже владея языком на очень хорошем уровне. Это мое ИМХО, естественно 
