Здравствуйте, Eye of Hell, Вы писали:

EOH>Ну говорить он может что угодно. Я правильно понимаю что он соавтор STL? Довольно трудно разрабатывать библиотеку к языку, которого ты не знаешь .

Запросто, особенно если она уже была разработана на другом языке.

Здравствуйте, LaPerouse, Вы писали:

ГВ>>Здравствуйте, LaPerouse, Вы писали:
LP>>>PS Как только ты сказал слово "объект", можешь забыть о модульности.
ГВ>>Почему?

LP>Потому что завязываешься на реализацию.

Объекты нельзя группировать в модули? Я что-то пропустил в устройстве мироздания?

Здравствуйте, dsorokin, Вы писали:

ГВ>><troll mode>
ГВ>>А во что там врубаться? Концпеция ООП замкнута на неопределённость: всё есть объекты, они обмениваются сообщениями, сами объекты состоят из объектов, обменивающихся сообщениями, а сообщения представляют собой объекты, обменивающиеся сообщениями. На колу мочало...
ГВ>></troll mode>

D>Смолток?

Ну да, есть такая штука. Одно из воплощений ООП.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, LaPerouse, Вы писали:

ГВ>>>Здравствуйте, LaPerouse, Вы писали:
LP>>>>PS Как только ты сказал слово "объект", можешь забыть о модульности.
ГВ>>>Почему?
LP>>Потому что завязываешься на реализацию.
ГВ>Объекты нельзя группировать в модули? Я что-то пропустил в устройстве мироздания?

Можно, но если ты завяжешься на сам объект, а не его интерфейс, у тебя будет гнилой монолитный дизайн, не подлежащий рефакторингу — раз, замене одних модулей другими без правки и пересборки — два.

Работа с объектами сводится к двум операциям:
1. Создание объекта
2. Работа с ним через его интерфейс

Первое — это тонкий момент, если ты создаешь объект явно, ты завязываешься на реализацию. По факту создание объекта нужно перепоручать фабрикам и DI-контейнерам. Остается второе — работа с объектом через его интерфейс. Понятие объекта по сути растворяется — у тебя есть некий сервис, определяемый интерфейсом объекта (компоненты), и ты в терминах этого (и других) сервисов определяешь поведение своего объекта (компоненты). Мы абстрагированы от объекта средой, которая за нас создает и биндит объекты в наш объект (компоненту). Мы лишь описываем декларативно (в xml-файле например), от каких сервисов зависит наш объект. Вся система представляет из себя ориентированный граф, в котором вершинами являются компоненты (модули), исходящие из модуля стрелки определяют сервисы, реализуемые данным модулем, а входящие в модуль стрелки — сервисы, потребляемые данным модулем для реализации своих сервисов.

Смотри например устройство декларативных сервисов OSGi 4.2 (http://www.osgi.org/Release4/Download) или Spring.

Здравствуйте, 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, объектно-ориентированная до мозга интерфейса. Как-то не склеивается парадигма.

Здравствуйте, gandjustas, Вы писали:

LP>>Забудьте про объекты. Это неверное представление об ООП. Думать о программе в терминах объектов — означает использовать не слишком высокий уровень абстракции. ООП — это абстрактные интерфейсы. Правильнее даже сказать — сервисы. Все. Точка. То, что за этими сервисами торчат объекты с состоянием (или без?) — лишь детали. Которые не должны интересовать архитектора системы.

G>SOA — вот самый правильный ООП.

SOA — самый правильный способ связать старые не переписываемые софтины в одну кучу.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, 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, объектно-ориентированная до мозга интерфейса. Как-то не склеивается парадигма.

Ничего не понял.

Здравствуйте, LaPerouse, Вы писали:

LP>>>Можно, но если ты завяжешься на сам объект, а не его интерфейс, у тебя будет гнилой монолитный дизайн, не подлежащий рефакторингу — раз, замене одних модулей другими без правки и пересборки — два.
ГВ>>С чего ты взял, что: а) игнорируется интерфейс, б) дизайн не предусмотрит замену одних объектов другими? Вроде как, это классика дизайна ПО.
LP>Я так понял с твоих слов, что ты не видишь ничего плохого в непосредственном создании объектов.

Видимо, я плохо сформулировал, хотя, меня здесь извиняет то, что я не предполагал рассказывать азы проектироваия ПО. Да, я против (резко против!) излишней связности, которая, в частности, проявляется в прямом указании типа создаваемого объекта. С другой стороны, иногда это весьма полезно.

ГВ>>Какой ещё сервис? Я могу положить объект в массив, присвоить переменной значение объектного типа, сравнить (ужас!) объекты. Где это всё в абстракции "сервисов", которая, если судить по твоим словам отрицает такие любопытнейшие явления, как "жизненный цикл", "состояние", "экземпляр"?

LP>Все эти операции доступны, сервис — лишь абстракция. Жизненный цикл компоненты может управляться средой (если объект статический) или динамически через предоставляемый средой фабричный сервис.

Если они доступны, то вопрос — как? Неужто ради, например, контейнеров нужно заводить сервис ContainerProvider?

LP>>>Смотри например устройство декларативных сервисов OSGi 4.2 (http://www.osgi.org/Release4/Download) или Spring.
ГВ>>А вот теперь начинаем долго медленно думать, почему в основе OSGi всё же лежит Java, объектно-ориентированная до мозга интерфейса. Как-то не склеивается парадигма.
LP>Ничего не понял.

А что тут не ясного? Java — ОО-язык (мопед не мой, но под такой маркой он продаётся), на Java построен фреймворк OSGi, насквозь сервисный. Почему из этого следует, что SOA есть истинное ООП — тайна, недоступная моему ничтожному разуму.

Здравствуйте, D. Mon, Вы писали:

EOH>>

Сегодня случайно наткнулся на Elements of Programming. Полистал — очень интересная и глубокая книга. C++ знаю очень слабо. Но именно эта книга вызвала интерес и заставила задаться вопросом — почему Степанов выбрал именно этот язык?

EOH>>Это надо у него спросить . Возможно, он просто его лучше всего знает? Более 20 лет использовал, соавтор STL.
DM>Он сам говорит, что С++ не знает. Что изучил в одной книжке краткое описание на 9 страниц, им и пользуется.

Что-то мне подсказывает, что это изощрённый стёб. Знаешь, что-то вроде premature optmization (далее по тексту). Или, скажем так, априорный контраргумент тем, кто гундосит, что, мол, для изучения C++ нужно знать наизусть 1500 (или сколько их там?) страниц стандарта, потому ы-ы-ы-ы... специалистов нет, всё пло-о-о-охо, нужны обезья-а-анки, хнык-хнык-хнык-хнык.

В прочем, это догадки, я просто люблю лёгкий цинизм в исполнении старшего поколения. У них это получается изящно.

Здравствуйте, pgregory, Вы писали:

P>Все просто: C++ – единственный на сегодня язык, позволяющий эффективно использовать generic programming. С++ он ни в коей мере идеалом он не считает, но лучшего языка для GP найти не может. Степанову не нравятся языки, которые не позволяют по полному использовать железо (x86, то есть), и строят над ним свои абстракции. Лучшей абстракцией над железом он считает "Си-машину".

Язык си вобщем то сильнейшая вещь своего времени. Куда сильнее всяких лиспов.

>Если поискать, можно найти его высказывания на эту тему (stepanovpapers.com).

P>P.S. Степанов начинал на схеме, и пришел к С++, в отличие от многих.

Вот бы узнать у него, чем ему схемы эти не понравились.

Здравствуйте, Ikemefula, Вы писали:

P>>P.S. Степанов начинал на схеме, и пришел к С++, в отличие от многих.

I>Вот бы узнать у него, чем ему схемы эти не понравились.

Думаю, все просто — полезнее делать библиотеку для языка, которым действительно пользуются люди.

Здравствуйте, Геннадий Васильев, Вы писали:

EOH>>>Это надо у него спросить . Возможно, он просто его лучше всего знает? Более 20 лет использовал, соавтор STL.
DM>>Он сам говорит, что С++ не знает. Что изучил в одной книжке краткое описание на 9 страниц, им и пользуется.

ГВ>Что-то мне подсказывает, что это изощрённый стёб. Знаешь, что-то вроде premature optmization (далее по тексту). Или, скажем так, априорный контраргумент тем, кто гундосит, что, мол, для изучения C++ нужно знать наизусть 1500 (или сколько их там?) страниц стандарта, потому ы-ы-ы-ы... специалистов нет, всё пло-о-о-охо, нужны обезья-а-анки, хнык-хнык-хнык-хнык.

ГВ>В прочем, это догадки, я просто люблю лёгкий цинизм в исполнении старшего поколения. У них это получается изящно.

Тогда рекомендую посмотреть видео его недавних лекций в яндексе. Он там рассказывает и про раздутый стандарт, и про принимающий его комитет. Что-то вроде: куча людей, которые ничего не знают, но обо всем имеют мнение.

Здравствуйте, D. Mon, Вы писали:

DM>Тогда рекомендую посмотреть видео его недавних лекций в яндексе. Он там рассказывает и про раздутый стандарт, и про принимающий его комитет. Что-то вроде: куча людей, которые ничего не знают, но обо всем имеют мнение.

Ссылкой не поделишься?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ссылкой не поделишься?

http://video.yandex.ru/users/ya-events/tag/%D0%B0.%D1%81%D1%82%D0%B5%D0%BF%D0%B0%D0%BD%D0%BE%D0%B2/

Здравствуйте, gear nuke, Вы писали:

...

Судя по этомувсе было более прозаично . Просто ему предложили работу сделать что-то для плюсов. Причем у плюсов даже не было подходящего инстумента для этого в то время:

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.

Здравствуйте, heavyweapondude, Вы писали:

...

Это относится к первому знакомству Степанова с плюсами, STL был создан позднее уже в HP Labs.

Здравствуйте, frontsquat, Вы писали:

F>Для этой книги в частности и для своих экспериментов вообще. Тут уже пояснили его стремление к низкоуровневости и эффективности. Тогда выбор понятен. Но вся эта возня с указателями, ручным управлением памятью и т.п. кажется шагом возможно и не назад, но как минимум вбок. Создание более высоких абстракций и поиск их эффективных реализаций на низком уровне — мне кажется более правильным направлением. Короче — Haskell.

Какие у Хаскеля есть средства для реализации "их эффективных реализаций на низком уровне"?

Здравствуйте, Тролль зеленый и толстый, Вы писали:

ТЗИ>Очевидно, чувак просто не врубается в концепцию ООП, при этом строит из себя умного, составляя тяжеловесные рассуждения.

Вот еще не врубающиеся чуваки: здесь

Здравствуйте, LaPerouse, Вы писали:

LP>ООП — это абстрактные интерфейсы.

Хочу понять, что именно имеется в виду, и потому задаю вопрос: можно ли struct, члены которого являются указателями на функции, рассматривать как абстрактный интерфейс?

Здравствуйте, LaPerouse, Вы писали:


LP>Забудьте про объекты. Это неверное представление об ООП. Думать о программе в терминах объектов — означает использовать не слишком высокий уровень абстракции. ООП — это абстрактные интерфейсы. Правильнее даже сказать — сервисы. Все. Точка. То, что за этими сервисами торчат объекты с состоянием (или без?) — лишь детали. Которые не должны интересовать архитектора системы.

Это тебя занесло сначала в компонентное программирование, которое есть подвид ООП с кучей ограничений.