Pzz wrote:
>> Вроде бы с этим никто не спорит. Гораздо интереснее другой момент —
>> стоит ли обращать внимание на альтернативные мейнстриму языки, или лучше
>> заняться изучением на досуге какого-нибудь фреймворка для С++?
> Я думаю, очередной фреймворк для C++ можно изучить и по ходу дела (я вот
> вообще на C++ не программирую, считая этот инструмент бесполезный
> свистулькой, и ничего, проблем пока не испытываю).
Инструментарий обычно оговаривается до начала проекта. Соответственно,
если я ничего не знаю об ACE, то я в проекте его не будет запланировано.

Или взять тот же Boost — можно из него использовать только shared_ptr, а
можно писать крутые темплейтные классы с помощью Boost.MPL.

> С другой стороны, расширять свой кругозор в сторону альтернативных
> подходов к жизни (в частности, в сторону не-мейнстримовых языков)
> занятие куда более полезное.
С тем, что оно полезное — никто не спорит. Спорят со словами "куда
более". Чем не поможет знание OCaml'а в проектах на С++?

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

G>Учеба и привычка к повышению квалификации предполагает как минимум отсутствие выкриков в духе "нафиг надо учить новые языки". А сами — изучайте себе что хотите, или не изучайте совсем ничего — думаете кому-то до вас есть дело?

Точно с таких же позиций можно спросить, почему под учебой и повышением квалификации неявно подразумевается изучение языков?

И почему, если библиотека, то идиотская, а если язык -- то полезный. Разве идиотских языков не бывает?

G>Более того, я не могу понять, почему изучение новых языков должно обязательно мешать семье, а и изучение очередной идиотской библиотеки — нет.

Потому, что на одновременное изучение и того и другого времени уже не хватает. Приходится выставлять приоритеты.

> Похожая ситуация с изучением какого-нибудь мейнстримового языка, вроде C# или Java.
>
> Перспективы изучения чего-то вроде Lisp-а или OCaml-а для меня туманны. Просто потому, что я очень быстро забываю то, что не использую. Поэтому, если я выучу OCaml и не буду на нем программировать, то через 8-10 месяцев мне придется учить его заново. Применять OCaml или Lisp на работе я просто физически не смогу, для себя вряд ли стану, т.к. у меня есть разработки, которыми я пытаюсь для себя заниматься, но они на C++.
>
> В общем, хотелось бы услышать, что, кроме банальной эрудиции, дает изучение не мейнстримовых языков программирования.
>
> R>Или, прости господи, от этого: http://www.intelib.org/
>
> Вот этого вообще не могу понять. Ну нравится программировать на Lisp, так программируй на Lisp, зачем же C++ уродовать?

Это специально, чтоб ты мог изучать Lisp в рабочее время и не забыл его из-за того, что не используешь А твои коллеги будут думать, что это С++.

eao197 wrote:
>
> Pzz>Ну что такого нового можно узнать, изучая какую-нибудь очередную ACE?
>
> Почитайте, узнаете:
> http://www.rsdn.ru/res/book/cpp/ace1.xml

Автор(ы): Дуглас С.Шмидт, Стивен Д.Хьюстон

Это первый том двухтомника «Программирование сетевых приложений на
С++», посвященный библиотеке The ADAPTIVE Communication Environment
(ACE) – одной из самых переносимых C++ библиотек, предназначенной для
разработки сложных, многоплатформенных приложений, и широко
используемой во всем мире. В нем читатель знакомится с самой
библиотекой, ее историей, основными чертами ее архитектуры и
принципами использования.

> <http://rsdn.ru/res/book/cpp/ace1.xml&gt;

Автор(ы): Дуглас С.Шмидт, Стивен Д.Хьюстон

Это первый том двухтомника «Программирование сетевых приложений на
С++», посвященный библиотеке The ADAPTIVE Communication Environment
(ACE) – одной из самых переносимых C++ библиотек, предназначенной для
разработки сложных, многоплатформенных приложений, и широко
используемой во всем мире. В нем читатель знакомится с самой
библиотекой, ее историей, основными чертами ее архитектуры и
принципами использования.

> http://www.rsdn.ru/res/book/cpp/ace2.xml

Автор(ы): Дуглас С.Шмидт, Стивен Д.Хьюстон

Это второй том двухтомника "Программирование сетевых приложений на
С++" посвященный библиотеке The ADAPTIVE Communication Environment
(ACE) — одной из самых переносимых C++ библиотек, предназначенной для
разработки сложных, многоплатформенных приложений, и широко
используемой во всем мире. В нем читатель знакомится с самой
сложной и важной частью библиотеки — каркасами.

> <http://rsdn.ru/res/book/cpp/ace2.xml&gt;

Автор(ы): Дуглас С.Шмидт, Стивен Д.Хьюстон

Это второй том двухтомника "Программирование сетевых приложений на
С++" посвященный библиотеке The ADAPTIVE Communication Environment
(ACE) — одной из самых переносимых C++ библиотек, предназначенной для
разработки сложных, многоплатформенных приложений, и широко
используемой во всем мире. В нем читатель знакомится с самой
сложной и важной частью библиотеки — каркасами.

>
> Особенно интересна вторая книга. Например, реализация паттернов Reactor
> и Proactor.

Вот уж не знал, 1) что столь простая вещь может называться столь
мудреными словами 2) что об этом аж целые книжки написаны...

Меня вообще удивляет. Мы вроде как не о зеленых чайниках говорим
(интересно, бывают ли в природе зеленые чайники?). Мы вроде как говорим
о повышении квалификации профессионалов. Неужели профессионал может
найти для себя какое-то откровение в той же ACE? Мда, падает планка,
падает...

Cyberax wrote:
>
>>> Вроде бы с этим никто не спорит. Гораздо интереснее другой момент —
>>> стоит ли обращать внимание на альтернативные мейнстриму языки, или лучше
>>> заняться изучением на досуге какого-нибудь фреймворка для С++?
>> Я думаю, очередной фреймворк для C++ можно изучить и по ходу дела (я вот
>> вообще на C++ не программирую, считая этот инструмент бесполезный
>> свистулькой, и ничего, проблем пока не испытываю).
> Инструментарий обычно оговаривается до начала проекта. Соответственно,
> если я ничего не знаю об ACE, то я в проекте его не будет запланировано.

Вообще-то, я всегда думал, что выбор инструментария, это часть процесса
проектирования, а не переговоров с заказчиком.

Не очень понятно, как можно сознательно выбирать инструментарий на
этапе, когда сама задача-то еще нуждается в уточнении.

> Или взять тот же Boost — можно из него использовать только shared_ptr, а
> можно писать крутые темплейтные классы с помощью Boost.MPL.

Это называется job security: написать программу так, чтобы кроме вас в
ней уж точно никто не смог бы разобраться

>> С другой стороны, расширять свой кругозор в сторону альтернативных
>> подходов к жизни (в частности, в сторону не-мейнстримовых языков)
>> занятие куда более полезное.
> С тем, что оно полезное — никто не спорит. Спорят со словами "куда
> более". Чем не поможет знание OCaml'а в проектах на С++?

Тем, что вы (наверное) научитесь лучше программировать. Не выбирать
библиотеки, не компоновать компоненты , не писать крутые темплейты, а
именно программировать.

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

G>>Более того, я не могу понять, почему изучение новых языков должно обязательно мешать семье, а и изучение очередной идиотской библиотеки — нет.

E>Потому, что на одновременное изучение и того и другого времени уже не хватает. Приходится выставлять приоритеты.

Кроме того, есть еще такое увлекательное занятие, как велосипедостроение Тут уж вообще приходится выбирать, или изучать чего-нибудь, или изобретать чего-нибудь. А то ведь языков много. Взять только те, которые reductor перечислил: ML(SML/O'Caml), Scheme, Common Lisp, Haskell, Prolog, Smalltallk и Forth. Уже семь, добавим сюда еще Erlang, до которого у меня никак руки не дойдут. Получается восемь. По месяцу на каждый (и то мало будет). Хотя нет, Prolog я когда-то изучал уже.

За это же время я две беты своей ObjESSty выпустил. А сейчас третью нужно делать. Вот и думаешь, что лучше: квалификацию повысить или продукт сделать, который может со временем и прибыль приносить. Вот Константин Книжник делал когда-то Open Source объектные базы, сейчас пытается на коммерческие реальсы это перевести. Имхо, хороший пример для подражания.

Pzz wrote:
> Вообще-то, я всегда думал, что выбор инструментария, это часть процесса
> проектирования, а не переговоров с заказчиком.
А у вас процесс проектирования проходит без переговоров с заказчиком?

> Не очень понятно, как можно сознательно выбирать инструментарий на
> этапе, когда сама задача-то еще нуждается в уточнении.
Предположим, что задача есть. В частности, у нас звучала так: "Сделать
все как в продукте X, но круче".

> Это называется job security: написать программу так, чтобы кроме вас в
> ней уж точно никто не смог бы разобраться
Как ни странно, но иногда крутое решение на темплейтах делает весь
остальной код намного проще и понятнее.

>> С тем, что оно полезное — никто не спорит. Спорят со словами "куда
>> более". Чем не поможет знание OCaml'а в проектах на С++?
> Тем, что вы (наверное) научитесь лучше программировать.
Я знаю OCaml и Erlang (и немного Haskell). Но не считаю их влияние
неоценимым и решающим.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

S>500 тысяч строк кода на Tcl — это сколько квадратных метров в сумарной площади всех окон ?
S>(Шутка, может и глупая, но несдержался)

Не знаю на счет TCL, но ради интереса взял на выбор первую попавшуюся директорию с исходничками на С++. Как вам, в качестве подопытного, исходники boost?

Поиск
-----

    grep.exe -c+ -v+ -d+ -r+ -e ^.*$ @boost.lst > boost.txt


boost.lst
---------

    boost_1_33_1\*.c
    boost_1_33_1\*.hpp
    boost_1_33_1\*.inl
    boost_1_33_1\*.inc
    boost_1_33_1\*.cpp
    boost_1_33_1\*.h
    boost_1_33_1\*.ipp
    boost_1_33_1\boost\compatibility\cpp_c_headers\*
    
    
Результаты
----------

Полный объем       :  75 891 156 байт   ~ 74 112.46 KB   ~ 72.38 MB
Объем выборки      :  31 116 295 байт   ~ 30 387.01 KB   ~ 29.67 MB
                   :  41%

Всего файлов       :  11 513
Файлов в выборке   :   6 232
                   :  54%

Строк              :  927 131

Ср. строк на файл  :  149
Ср. длина строки   :  34


   Таблица соответствия количества строк объему кода
+-----------+------------+-----------+-------+--------+
|   строк   |    байт    |     КБ    |   МБ  | файлов |
+-----------+------------+-----------+-------+--------+
|     1 000 |     33 562 |     32.78 |  0.03 |      7 |
|     5 000 |    167 810 |    163.88 |  0.16 |     34 |
|    10 000 |    335 619 |    327.75 |  0.32 |     67 |
|    50 000 |  1 678 096 |  1 638.77 |  1.60 |    336 |
|   100 000 |  3 356 192 |  3 277.53 |  3.20 |    672 |
|   500 000 | 16 780 959 | 16 387.66 | 16.00 |  3 361 |
| 1 000 000 | 33 561 918 | 32 775.31 | 32.01 |  6 722 |
+-----------+------------+-----------+-------+--------+

Теперь хоть буду знать как приблизительно оценить объемы

Cyberax wrote:
>
>> Вообще-то, я всегда думал, что выбор инструментария, это часть процесса
>> проектирования, а не переговоров с заказчиком.
> А у вас процесс проектирования проходит без переговоров с заказчиком?

Нет, но она не происходит "до начала проекта".

>> Не очень понятно, как можно сознательно выбирать инструментарий на
>> этапе, когда сама задача-то еще нуждается в уточнении.
> Предположим, что задача есть. В частности, у нас звучала так: "Сделать
> все как в продукте X, но круче".

Решать задачу в такой формулировке, если не удается выработать четких
требований, что значит "но круче", непрофессионально. И к тому же,
рисковано неоплатой заказа

>>> более". Чем не поможет знание OCaml'а в проектах на С++?
>> Тем, что вы (наверное) научитесь лучше программировать.
> Я знаю OCaml и Erlang (и немного Haskell). Но не считаю их влияние
> неоценимым и решающим.

А знание ACE Вы считаете неоценимым и решающим?

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

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

S>>500 тысяч строк кода на Tcl — это сколько квадратных метров в сумарной площади всех окон ?
S>>(Шутка, может и глупая, но несдержался)

AB>Не знаю на счет TCL, но ради интереса взял на выбор первую попавшуюся директорию с исходничками на С++. Как вам, в качестве подопытного, исходники boost?

мегаисследование поскипано

Многое в бусте нужно изучать чуть ли не посимвольно

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

C>Я знаю OCaml и Erlang (и немного Haskell). Но не считаю их влияние
C>неоценимым и решающим.

Вас не затруднит определить пояс в хаскеле?

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

>> Особенно интересна вторая книга. Например, реализация паттернов Reactor
>> и Proactor.

Pzz>Вот уж не знал, 1) что столь простая вещь может называться столь
Pzz>мудреными словами 2) что об этом аж целые книжки написаны...

Pzz>Меня вообще удивляет. Мы вроде как не о зеленых чайниках говорим
Pzz>(интересно, бывают ли в природе зеленые чайники?). Мы вроде как говорим
Pzz>о повышении квалификации профессионалов. Неужели профессионал может
Pzz>найти для себя какое-то откровение в той же ACE? Мда, падает планка,
Pzz>падает...

Спасибо, повеселили.
Вообще-то хочется сказать, что люди разные, это поковник Кольт уравнял наши шансы. А поскольку мы разные, то я уверен, что reductor, вы или Gaperton гораздо умнее и организованне меня. Поэтому многие вещи, которые для вас очень простые, для меня просто неподьемные и я на них трачу больше времени, усилий и не получаю таких же результатов, как вы.

Что касается профессионализма, то профессионал, это человек, зарабатывающий своей профессией. Поэтому я профессионал. Но я нашел для себя много нового и интересного в ACE.

А вообще выглядит довольно смешно. Вроде как я здесь засветился как ярый противник учебы вообще и изучения функциональных языков в частности. Но даже я, насколько помню, не спрашивал, можно ли найти какое-нибудь откровение в OCaml или Haskell. Меня просто волнует, насколько оправданным с практической точки зрения будет изучение этих языков. В самой ближайшей перспективе. В плане того, чтобы в своих проектах выбросить C++ и взять Lisp или OCaml. А вы про библиотеку, в которую было вложено труда и фантазии не меньше, чем в какой-нибудь из языков программирования так отзываетесь.

Pzz wrote:
>> > Вообще-то, я всегда думал, что выбор инструментария, это часть процесса
>> > проектирования, а не переговоров с заказчиком.
>> А у вас процесс проектирования проходит без переговоров с заказчиком?
> Нет, но она не происходит "до начала проекта".
Под началом проекта я имею в виду одобреное ТЗ и начало разработки.

>> Предположим, что задача есть. В частности, у нас звучала так: "Сделать
>> все как в продукте X, но круче".
> Решать задачу в такой формулировке, если не удается выработать четких
> требований, что значит "но круче", непрофессионально. И к тому же,
> рисковано неоплатой заказа
Под "круче" понимается большее удобство использования и возможность
дальнейшего расширения. Вообще, задачей было повторить функциональность
продукта конкурентов и при этом сделать возможным легкое добавление
новой функциональности.

>> >> более". Чем не поможет знание OCaml'а в проектах на С++?
>> > Тем, что вы (наверное) научитесь лучше программировать.
>> Я знаю OCaml и Erlang (и немного Haskell). Но не считаю их влияние
>> неоценимым и решающим.
> А знание ACE Вы считаете неоценимым и решающим?
Нет. Решающим я считаю практический опыт.

Например, в местном университете в прошлом году студентам давали
функциональное программирование — студенты все нормально поняли и
усвоили. В этом году студентам на группу дали написать достаточно
сложный курсовой (на Pascal'е) — так эти студенты, как ни в чем не
бывало, написали программу с кучей глобальных переменных и функций с
передачей аргументов по ссылке.

Спрашивается: зачем нужно абстрактоне знание без конкретного
практического опыта?

--
С уважением,
Alex Besogonov (alexy@izh.com)

eao197 wrote:
>
> Pzz>Меня вообще удивляет. Мы вроде как не о зеленых чайниках говорим
> Pzz>(интересно, бывают ли в природе зеленые чайники?). Мы вроде как говорим
> Pzz>о повышении квалификации профессионалов. Неужели профессионал может
> Pzz>найти для себя какое-то откровение в той же ACE? Мда, падает планка,
> Pzz>падает...
>
> Спасибо, повеселили.
> Вообще-то хочется сказать, что люди разные, это поковник Кольт уравнял
> наши шансы. А поскольку мы разные, то я уверен, что reductor, вы или
> Gaperton гораздо умнее и организованне меня. Поэтому многие вещи,
> которые для вас очень простые, для меня просто неподьемные и я на них
> трачу больше времени, усилий и не получаю таких же результатов, как вы.

Ну, во-первых, я ни в коем случае не хотел Вас обидеть. Если все же
обидел, прошу прощения...

> Что касается профессионализма, то профессионал, это человек,
> зарабатывающий своей профессией. Поэтому я профессионал. Но я нашел для
> себя много нового и интересного в ACE.

Тут, по-моему, важно, кем Вы себя видете в профессиональном плане:
инженером или техником.

Техник должен знать всякие там пассатижи, отвертки и прочие станки с
ЧПУ. Инженер же должен понимать принципы и общие тенденции. А что до
конкретных инстроментов, то важнее знать и понимать, какие инструменты
существуют (могут существовать) в принципе, чем достигать пределов
совершенства в использовании конкретно этой вот отвертки.

> А вообще выглядит довольно смешно. Вроде как я здесь засветился как ярый
> противник учебы вообще и изучения функциональных языков в частности. Но
> даже я, насколько помню, не спрашивал, можно ли найти какое-нибудь
> откровение в OCaml или Haskell. Меня просто волнует, насколько
> оправданным с практической точки зрения будет изучение этих языков. В
> самой ближайшей перспективе. В плане того, чтобы в своих проектах
> выбросить C++ и взять Lisp или OCaml. А вы про библиотеку, в которую
> было вложено труда и фантазии не меньше, чем в какой-нибудь из языков
> программирования так отзываетесь.

Я, в общем-то не сказал про ACE ничего плохого. Я сказал, это ACE, как и
все прочие фреймворки, бесполезна, как объект познания. Это не значит,
что ее нельзя использовать в своих программах.

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

S>Я так понимаю, что "новичок" просто ничего не сможет панять в 500 тысячах строк на любом из этих языков,

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

Когда я все же пересилил свое неприятие С# я, ничего не зная и не понимая, взял исходники януса и пошел в отладчике, шаг за шагом.

S>да и канал может быть слабый для скачивания подобных примеров

Тут я ниже написал, 500 000 строк — 16 мегабайт, с учетом того, что они составляют ~40%, то полный размер будет составлять ~40 мегабайт, с учетом сжатия ZIP в ~75 (из моего примера ниже), получаем архив в 10 мегабайт — у меня такое прокачивается менее минуты, на диалапе — это ~50 минут. Ради знаний можно и потерпеть.

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

S>Поддерживаю мнение товарищей, что Вы являетесь преподавателем

Это точно нет. Преподаватели не решают вдруг сначала публиковать свои материалы, а потом вдруг резко решить их отозвать с желанием получать от них к-л коммерческую выгоду.

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

ГВ>Вот-вот, как раз иллюстрация к моему соседнему посту пятиминутной давности. Я — о принципах, ты — о конкретике. Задача поиска конкретного компромисса в кокнретных условиях — это, что называется, совсем другая задача. Здесь сразу можно поставить очень много конкретных вопросов, начиная от "а с чего это вдруг именно XML?"

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

Anton Batenev wrote:
>
> S>Я так понимаю, что "новичок" просто ничего не сможет панять в 500
> тысячах строк на любом из этих языков,
>
> Для начала не требуется понимание. Для начала требуется подражание тому,
> что работает — т.е. делаем по образу и подобию и выясняем почему не
> получается. Меняем пару-тройку строк и смотрим что получается.

По-моему, это полная глупость. Таким образом (через подражание) можно
научиться чужие исходники подкручивать. Писать свой код так не научишься...

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

Pzz>По-моему, это полная глупость. Таким образом (через подражание) можно
Pzz>научиться чужие исходники подкручивать. Писать свой код так не научишься...

Многие художники начинали учиться копируюя работы признаных мастеров.

Мне в свое время сильно помогли исходники C++ примеров программ (особенно под Windows), которые шли в составе Borland C++ 2.0 (в частности прием с помещением указателя на экземпляр класса-окна в extra-байты окна).

Pzz wrote:
> Я, в общем-то не сказал про ACE ничего плохого. Я сказал, это ACE, как и
> все прочие фреймворки, бесполезна, как объект познания. Это не значит,
> что ее нельзя использовать в своих программах.
Отнюдь. ACE показывает как можно организовать сетевые приложения на
императивном языке с ручным управлением памятью. Для меня это не менее
фундаментально, чем изучение Лиспа как языка с нефиксированым
синтаксисом, например.

--
С уважением,
Alex Besogonov (alexy@izh.com)