программистское

[avva]

Очередной наезд на C++, в виде презентации на этот раз. Есть кое-какие неплохие примеры, хотя, как и в прошлый раз, много энергии растрачено на специально выдуманные примеры не из реальной практики.

Comments

[theukrainian.livejournal.com]

у нас с presenter есть как минимум одно отличие. он выучил C++ чтобы пользоваться: OOP with Inline Member Functions, (Operator) Overloading, Templates

Я выучил C++ to get a job. Наверное поэтому я легче переношу недостатки C++

:)

[avva.livejournal.com]

Логично :)

[cmm.livejournal.com]

он выучил C++ чтобы пользоваться: OOP with Inline Member Functions, (Operator) Overloading, Templates

for all the wrong reasons, короче. :)

[theukrainian.livejournal.com]

хорошо! :)

[e2pii1.livejournal.com]

Использование конструкторов/деструкторов для надёжной инициализации/освобождения ресурсов, или "const" - это тоже wrong reasons ?

Что вы посоветуете использовать вместо Templates и inline functions там где нужна эффективность выполнения кода ? Препроцессор ?

[neatfires.livejournal.com]

А какие языки, по вашему мнению, лучше подходят для general-purpose programming (если предположить, что остальные условия равные - библиотеки, поддержка ОС, лицензия итд)? Конкретизирую:
1. Average case: в проектах с переменным или заранее неизвестным уровнем профессионализма разработчиков.
2. Best case.

[neograff.livejournal.com]

Haskell

[jerom.livejournal.com]

А существует сколь-нибудь существенный рынок haskell программистов?

Я вообще не видел ни одной вакансии в Москве.

[neatfires.livejournal.com]

Это к какому пункту ответ? :)

[stas]

Хорошая шутка, смешная.

[vitus_wagner]

Ключевым здесь является использование множественного числа - какие языки а не какой язык.

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

Вторым - что-нибудь из Tcl Perl Python Ruby. Что больше нравится. Мне для GUI-приложений больше нравится Tcl, для Web-приложений perl. Командно-строчный инструментарий 50/50 то и другое.

Третьим Erlang/Haskell/Oz.

Четвертым - make. Можно, конечно попробовать его заменить на какой-нибудь Bras, т.е. свести к пункту 2, но лучше не надо. Не исключено что этот инструмент стоит использовань не только в процессе сборки, но и в процессе работы.

Старый добрый shell тоже пригодится (в основном для автоматизированных тестов, сборочных скриптов и т.д. юзеру лучше sh-скрипты не давать).
Следует всячески избегать использования в sh-скриптах sed, а может и awk. Лучше сразу заменять на то, что выбрано в п.2.

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

Между п. 1 и 2 может вклиниться жаба. Но лучше её сразу задавить, пока она вас не задавила.

[avva.livejournal.com]

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

В случае, если известно, что есть средние или плохие программисты, и ничего с этим не поделать, надо использовать Джаву или C++ с железной дисциплиной стиля (или C, что не сильно отличается от C++ с железной дисциплиной стиля). Это и есть одна из главных причин, по которой эти два языка стали самыми популярными - они дают возможность изолировать вред от дураков, по крайней мере в большой степени.

Если люди хорошие, и команда небольшая, то в зависимости от того, что они знают или готовы выучить, один из таких языков, как Perl, Python, Ruby, Common Lisp, Haskell... языков, в которых профессионал может быть очень продуктивным. Конкретный выбор языка не так важен, как многим кажется. Если проект большой и людей много, и трудно обеспечить, чтобы они все знали/выучили один из этих языков, но они все еще действительно на высоком уровне, то Джава или C++ с вышеупомянутой дисциплиной.

При любом выборе грамотно настроенный процесс обязательных code reviews может оказаться более важным, чем выбор языка. То же самое касается грамотно составленного style guide, нейтрализующего многие недостатки данного языка/среды путем жесткого или мягкого запрета на использование определенных частей языка.

[gdy.livejournal.com]

Там есть просто ошибочные примеры. Страница 17, хотя бы.

[spamsink.livejournal.com]

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

[stas]

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

[migmit.livejournal.com]

"Огонёк" наехал на неодноразовые шприцы. И выиграл.

[neatfires.livejournal.com]

Я бы скорее сравнил это с наездами на марксизм с точки зрения новой экономической теории. В кружке по экономике.

[http://users.livejournal.com/malfet_/]

По моемому, ближе к концу(раздел C++ is too powerful) автор презентации делает удивительно верное утверждение: "Most people can't handle all that flexibility".

[zigmar.livejournal.com]

Ага. Верно подмечено. Особенно учитывая, что этот "most" явно включает автора этого опуса :)

[bbb.livejournal.com]

У тебя опечатка - в предложении "Очередной наезд на СПС" две последние буквы пропечатались плюсиками. Поправь, а то люди путаются.

[avva.livejournal.com]

Нет уж, пусть будет как есть! В морг так в морг.

[degor.livejournal.com]

в чем смысл таких наездов? все эти проблемы давно известны. с появлением java и с# плюсы с каждым годом становятся все более нишевым языком. все меньше софта, который есть смысл разрабатывать на плюсах.

мне кажется, это такой способ самоутверждения.

[ban-dana.livejournal.com]

открыл, пролистал, увидел кучу фигни двух основных видов:

1. Фактические ошибки (типа утверждения о том, что при выбросе исключения из конструктора нет раскрутки)
2. Наезды на фичи которые работают иначе (by design), чем автор считает нужным. Например, все разговоры об ущербности auto_ptr. Я, например, могу с таким же успехом начать возмущаться, что не могу использовать свою тойоту ярис в качестве грузовика, и заявить, что, дескать, тойота - говно.

[ban-dana.livejournal.com]

Я, собственно, не утверждаю, что автор сего опуса вообще не сказал ничего дельного, но оно, если и есть, как-то теряется на общем фоне...

[zigmar.livejournal.com]

1. да
2. auto_ptr таки да ущербный. У него не должно было быть семантики передачи владения, потому что получается что он прикидывается смартпоинтером, таковым даже близко не являясь и только вводя наивных пользователей в заблуждение. Насколько я слышал, что во всех драфтах, это был нормальный аналог нынешнего boost::scoped_ptr, но в финальную версию стандарта, каким-то образом проскочил в модифицированном виде, в которым мы имеет "счастье" наблюдать его теперь.