Очень хотелось бы услышать мнения опытных людей по поводу как часто приходится использовать «высший пилотаж» в своей повседневной деятельности (имеется ввиду разработка ПО и все что с этим связано)?
Меня интересует применение шаблонов, множественного наследования, RTTI и паттернов проектирования.
Стоит ли на этом заострять внимание, или просто достаточно знать, что такое существует?
13 августа 2008 в 16:01
ясно. спасибо за ответы.
13 августа 2008 в 12:05
2 Жека jkff Кирпичев:
Настоящие мужики не используют многопроцессорные системы (киваю на Кнута)
13 августа 2008 в 12:01
Вообще наверное Настоящие Мужыки на Настоящих Многопроцессорных Системах на си используют штуки типа MPI.
13 августа 2008 в 7:05
>а ведь ось на эрланге не напишешь.
а зачем?
>можно ли на том же си или си++ оптимизировать под эм.. случайное количество процессоров программу? (извините, если глупый вопрос)
можно в теории, конечно. но это будет слишком сложно, проще выучить Erlang или Haskell.
чтобы мультипрограммировать на Си, нужно:
- точно знать, где у нас есть общее состояние (чтобы заняться синхронизацией записи/чтения)
- функции писать по возможности "чистые"/идемпотентные, reentrant и затем уже thread-safe (проблема в том, что на Си/Си++ никто не пишет "чистые" функции)
- и т.п. (если вспомню, еще допишу)
12 августа 2008 в 22:02
в этой теме обсуждался erlang и я поискал статейку о нём и почитал. и там было среди достоинств вот что. на языках типа си надо отдельно оптимизировать под двух- и четырёхпроцессорные системы. ну а если больше появиться. а эрланг с этим норм справиться. это всё хорошо. но первая же мысль, которая мне пришла после этого, а ведь ось на эрланге не напишешь. можно ли на том же си или си++ оптимизировать под эм.. случайное количество процессоров программу? (извините, если глупый вопрос)
12 августа 2008 в 17:02
2 EveryOne
Спасибо всем, в общем то я получил ответы на свои вопросы и сделал определенные выводы (!)
12 августа 2008 в 15:05
2 Евгений Семенников:
На C# это немного проще, и в сети есть куча примеров:
//www.codeproject.com/KB/graphics/julijanpiecha...
//www.codeproject.com/KB/graphics/charting.aspx
Построение графиков для одного конкретного приложения — это довольно простая задача, и здесь вполне можно обойтись своими силами.
12 августа 2008 в 15:01
Статью Java vs C++ нашел на платном ACM, прочитал – действительно, маленькая лажовая нереалистичная алгоритмическая задачка – прочитать текстовый файл и определенным сумасшедшим образом трансформировать каждую строку.
Так что сравнение этой статьи с приведенной мною считаю некорректным.
12 августа 2008 в 15:00
2 Алексей Claymore Бобьяков
со всем хотя бы типичным функционалом для отображения графиков… хм… я думал, что это уже сделано, так ведь целый движок придется написать.
сейчас вот, к слову сказать, поступило указание перейти на C#, пришлось бы эту библиотеку под NET затачивать.
12 августа 2008 в 14:02
2 Артём Шалхаков:
Понятно. То есть как раз для тех задач, в которых C++ применяется очень редко. Например, для разработки CMS сейчас в основном используют PHP, Java, .NET, Python и Ruby. Вас интересует Haskell и SML, но в сколько-нибудь большом проекте вы их не использовали, и своё мнение строите на чужих отзывах.
2 Евгений Семенников:
А разве так сложно написать свой класс/библиотеку для отображения графиков?
12 августа 2008 в 14:02
2 Жека Кирпичев
//www.flownet.com/gat/papers/lisp-java.pdf
>> там тоже делались очень интересные выводы
>Какие?
собсно, что на Лиспе писать проще и быстрей, чем на Жабе и Си++
>И какие там задачи рассматривались?
это надо оригинальный пейпер читать ("Java vs C++: Efficiency Issues to Interpersonal Issues"), а его в сети я не нашел
12 августа 2008 в 14:01
> там тоже делались очень интересные выводы
Какие?
И какие там задачи рассматривались?
Искусственных бенчмарков типа "10млн раз выполнить 2 + 2 " везде хватает, а вот приведенная статья как раз представляет собой нормальный пример – реальное коммерческое приложение, замеряются реальные, важные наблюдаемые характеристики.
12 августа 2008 в 13:01
2 Жека Кирпичев
>Это Conference of Commercial Users of Functional Programming. Думаешь, врут?
разумеется, нет)
кстати, где-то в сети видел слайды Java vs C++ vs Common Lisp, там тоже делались очень интересные выводы
2 Алексей Бобьяков
>А какие из вышеперечисленных языков на работе используете лично вы? И для каких задач?
я применяю JavaSсript и XPath/XSLT кажный божий день, а Haskell'ом и SML'ом очень сильно интересуюсь (буду следующие проекты писать на Haskell, скорее всего), SML же тут при том что есть SMLtoJs (хорошая альтернатива чистому JS в браузере, и если бы не IE, то…)
на Питоне у нас напейсан http-сервер/CMS (для наших целей самое оно)
12 августа 2008 в 13:00
>> Про управление железом…
Ну если, контроллеры програмить, то да – С хватает.
А если, извините, 2ух метровая стойка до отказа напичканная датчика, каждый из которых имеет N каналов?
Плюс еще нужно график рисовать- кстати, одна из причин, почему до сих пор используется BuilderC++ 6.0 лично мной (TChart), данные в базе сохранить и успеть че – нить включить.
И все это один человек (! ) разрабатывает.
Думаю на С долго автоматитьпридется, а вот зашаблонить это не трудно, там ведь многое повторяется.
С TChart ваще проблема, не могу аналогов найти чтобы на visual studio пересесть.
Те языки, которые здесь упомянуты, кроме с++/с# – думаю так или иначе в универе втречалить. У меня образование не программерское, поэтму прийдется пробелы самому восполнять.
12 августа 2008 в 12:02
2 Артём Шалхаков:
А какие из вышеперечисленных языков на работе используете лично вы? И для каких задач?
12 августа 2008 в 12:02
> но никто ж не поверит
//cufp.galois.com/2007/slides/JanNystrom.ppt
Это Conference of Commercial Users of Functional Programming. Думаешь, врут?
(про 13 раз я наврал – они там сделали 3 версии: C++, Erlang+C, чистый Erlang. Erlang+C – в 18 раз короче C++, а чистый эрланг – в 7 раз короче. В районе 23 слайда)
Обрати также внимание на слайды про отказоустойчивость – умирание и воскресение узлов во время работы системы; в С++ версии об этом речи вообще не шло.
12 августа 2008 в 12:01
2 Евгений Семенников:
Шаблоны активно используются в разработке на всех языках, в которых они есть, множественное наследование используется крайне редко и довольно опасно, так что его ты вряд ли встретишь.
Шаблоны проектирования изучать в отрыве от реальных задач практически бесполезно — неочевидно зачем и когда их нужно использовать. Новички часто забывают, что шаблоны ввели для обозначения характерных и ярких приёмов программирования, для удобства общения (например, чтобы было достаточно сказать «а здесь я использовал Фасад», и все в команде поняли, что именно вы сделали), а не для выбора «походящего» к конкретному коду шаблона из справочника.
12 августа 2008 в 11:03
2 Роман Комаров
>C/C++, java, c# – это мэйнстрим, это поддерживают IBM, Sun, MS, Oracle.
Ну, мэйнстрим — это не обязательно "хорошо" или "правильно" или еще что-то в этом духе. Даже миллион леммингов могут ошибаться.
>Дело не в том, что круто, а что не круто… А в том, что используется!
)
Референсная реализация ECMAScript4/JS2.0 написана на SML (правда, в императивном стиле, жутко
Haskell тоже используется, но самое важное, что у него огромный потенциал в целом и в мультипрограммировании в частности (кстате, там уже есть software transactional memory, а в С++ до сих пор парятся с потоками и блокировками)
SML — адназначна для компиляторов, интерпретаторов, разбора текста, и прочего подобного (там калькулятор выражений можно написать в 50 строк, на Си++ такое если и напишешь, потом запаришься с обеспечением такой же безопасности)
Ruby — Ruby On Rails (развод трудящихся, конечно, но очень удачный)
ECMAScript — всеми нежно любимый JavaSсript
и кстати, в язык совсем не надо вбухивать много $$$, чтобы он стал полезен (а то получаются такие монстры, как C#, Java, ABAP и прочий "корпорейт буллшит")
2 Жека Кирпичев
>исходники уменьшились в 13 раз, а производительность возросла в 3 раза
можно почти такое же сказать о Лиспе каком-нибудь, но никто ж не поверит — его просто молча переизобретают раз в год или около того ^_^
2 Евгений Семенников
> Интересно, а на чем тогда железом управлять? А?
Форт, мать его)
boost::mpl это важная часть библиотеки Boost
12 августа 2008 в 10:03
> Кто продвигает Erlang?
Изначально Ericsson. Есть десятки коммерчески успешных проектов на эрланге, использующих его именно для того, для чего он предназначался – разработка огромных отказоустойчивых распределенных систем с uptime 99.9999%
У Facebook, например, на нем написана соответствующая часть чата, расчитанного на 70млн юзеров в онлайне.
На эрланге написан самый популярный джаббер-сервер ejabberd .
Да дохрена компаний на нем пишут.
В описанных задачах у эрланга конкурентов просто нет, ни одного. Даже производительность – не аргумент: уже были бенчмарки, как yaws выдерживает 70 тысяч одновременных коннекшнов к серверу с сохранением пропускной способности, тогда как апач дохнет на нескольких сотнях (но этот бенчмарк так себе); была презентация, как программу на С++ переписали на эрланг, исходники уменьшились в 13 раз, а производительность возросла в 3 раза – за счет прекрасной работы с сетью и переключением задач в ядре erlang runtime.
Вычисления на эрланге действительно очень медленные – до 30-100 раз медленнее, чем на си – но их на нем и не пишут. А если приперло – то у него есть интерфейсы к другим языкам. У эрикссона основной проект состоит из 1.5млн строк эрланга и 700тыс. строк на С++.
12 августа 2008 в 10:02
> ЗЫ рекомендую отвернуться от Си++, потому что это ни разу не "круто"
Дело не в том, что круто, а что не круто… А в том, что используется!C/C++, java, c# – это мэйнстрим, это поддерживают IBM, Sun, MS, Oracle.
Кто продвигает Erlang?
12 августа 2008 в 10:02
>> Интересно, а на чем тогда железом управлять? А?
Для этого есть C.
>>На практике редко удается применить, потому и вопрос возник. Я не имею ввиду простые случаи.
На практике постоянно применяется. Шаблоны позволяют развязать части системы и сделать ее более гибкой, повышают безопасность кода (например, позволяют уменьшить количество ошибок типкастинга в рантайме).
Про множественное наследование трудно сказать — на любителя, но допускаю, что есть ситуации, когда без него код становится громоздким/не наглядным.
Что касается RTTI, то в по крайней мере C# без него не обходится.
Паттерны — это вообще святое. GoF собрали опыт многих лет работы проектировщиков, выжали из него самые удачные решения, которые проверены временем. Большинство паттернов так или иначе реализованы в "фирменных" фреймворках и мы ими пользуемся незадумываясь. Например, итератор или абстрактная фабрика.
12 августа 2008 в 10:01
>> Артём Шалхаков
спасибо за советы.
>> рекомендую отвернуться от Си++
Интересно, а на чем тогда железом управлять? А?
>> Haskell, OCaml, SML, Erlang, Ruby, Python, ECMAScript
ни разу о них не слышал, кроме Python
boost::mpl – тоже не знаю, что это, но обязательно узнаю
Ну и тем не менее, складывается такое впечатление, что все эти паттерны, шаблоны – это все хорошо с педагогической точки зрения, т.е. для обучения.
На практике редко удается применить, потому и вопрос возник. Я не имею ввиду простые случаи.
12 августа 2008 в 8:01
ага, поправил)
12 августа 2008 в 7:05
Артем, GoF — это справочник, его не надо учить наизусть
12 августа 2008 в 7:04
>Стоит ли на этом заострять внимание, или просто достаточно знать, что такое существует?
нада знать, что это такое и зачем оно нужно, вполне может пригодиться.
шаблоны в Си++, правда, унылое г., ничего тут не попишешь (смотрим дуст, эээ, т.е. boost::mpl, и восхищаемся хаками для каждого компилятора и дивной, чудной скорости компиляции)
паттерны проектирования это такие изящные костыли, которые приходится использовать из-за недостатков самого языка
RTTI и исключения тоже довольно полезны (одно — для управления ресурсами, второе — чтобы баг не прошел незамеченным)
множественное наследование не применял, не пойму, зачем оно вообще. наследование, к слову, это плохая идея, потому что реализация класса X становится зависимой от реализации класса Y, тяжело отлаживать и фсе такое. (некоторые, правда, справляются)
ЗЫ рекомендую отвернуться от Си++, потому что это ни разу не "круто", применяйте вменяемые языки — Haskell, OCaml, SML, Erlang, Ruby, Python, ECMAScript — тысячи их!