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

> либо создавать в ней объект - родительскую структуру

Чуть больше букв писать придётся, да.

Возможно, в каких-то случаях применение плюсов оправдано.

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

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

Смысл множественного наследования я себе вообще слабо представляю за исключиением каких-нибудь утилитарных классов типа ref_counted, noncopiable. А вот RTTI, exceptions и шаблоны ограничивают пожалуй только в embedded. Без этого всего C++ будет просто кастрированным унылым говном.

Еще поработаю майором Очевидностью + вброшу.

Области применения:

* Веб-приложения, серверная сторона.
PHP. Быдлокодинг. Абсолютно тупой язык с дебильным синтаксисом и беспомощной стандартной библитекой, куда в кучу свалено всё что можно и что нельзя. Зато имеет достаточно быструю реализацию интерпретатора.
Perl. Потенциально мощный, но запутанный. Тоже дурацкий синтаксис. Тоже быстрый.
Питон. Реинкарнация перла с обратным знаком: на перле программят волосатые мужики в свитере и с липкой от пива клавитурой, на питоне — пишут на Самым Правильным Методикам наивные мальчики в дорогих пиджаках. На самом деле, как язык питон очень хорош, плюс к этому, имеет приличную реализацию интепретатора, и не одну.
Руби. Технологически самый совершенный из. Чистое ООП. Развитые элементы функциональщины. Очень читабельный синтаксис. Ключевой минус — интерпретатор работает как черепаха. С версии 1.9 стало побыстрее, но всё равно не дотягивает до конкурентов.

* Веб-приложения, клиентская сторона.
JavaScript, без вариантов. Из языка могло бы получиться что-то очень хорошее, задатки есть, но выросло то, что выросло. Всего несколько граблей в семантике и синтаксисе, но зато очень грамотно расставлены и присыпаны листьями. Прототипное ООП — полезно изучить, чтобы хотя бы знать, что оно существует как альтернатива классам. Недоразвитые элементы функциональщины.

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

Питон или Руби одинаково подходят. Руби чуть удобнее. Также необходимо знать sh. И желательно изучить make. В редких случаях может потребоваться Си, если сильно критична производительность.
Можно попробовать Tcl, отдельным субъектам нравится.

* Графические утилиты/приложения под иксами.

Опять выбираем: Питон или Руби. Под Питон вроде как больше биндингов библиотек, он предпочтительнее. Также можно писать на Vala, Java, языках dotNet — но лучше не нужно.
Если вдруг понравился Tcl, то Tcl Tk.
Если отдельные участки сильно критичны по производительности, оформляем их модулями на Си и используем из основной программы

* Системное и/или низкоуровневое программирование. Высокопроизводительные службы.

Си без вариантов.

А где язык С в «* Веб-приложения, серверная сторона»?

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

А теперь попробуй объяснить, чем он концептуально отличается от Си. Та же статическая система типов вокруг указателей и структур. Те же скаляры. Те же массивы. То же управление памятью.

> А где язык С в «* Веб-приложения, серверная сторона»?

Ну если говорить о коде http-сервера... Но зачем?

А CGI приложения на сях — ну можно, но где это встречается в реальности?

s/обработки теста/обработки текста/

А CGI приложения на сях — ну можно, но где это встречается в реальности?

У таких быдлокодеров, как я :)

У меня вообще вся серверная часть для всех веб-приложений (в т.ч. элементарное преобразование данных из БД и вывод их пользователю) на сях.

> * Веб-приложения, серверная сторона.

Тут тоже tcl применяется: AOL, ОpenACS, ...

Здесь главное начать, а не с какого.

> Здесь главное начать, а не с какого.

Не фига, хоть и прошло много лет, а ничего проще и надежней tcl/tk таки нет в Linux.
Все ломается в угоду бздыками умников и «развитию» - как дурной бесконечности и забавы для любителей обновлений.)

Ассемблер x86_64

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

А теперь попробуй объяснить, чем он концептуально отличается от Си.

Концептуально - ничем. Знание C - необходимый, и, в принципе, самодостаточный скилл программиста (не быдлокодера). Но сначала можно набить много шишек на указателях и нестрогой типизации. Идти к нему через паскаль может оказаться комфортнее. Кроме того, строгость последнего окажет благотворное влияние на формирование программистского мышления, потом и на C будешь правильнее писать. Сам начинал с C, потому что книжка в свое время в руки попалась. Но, оглядываясь назад, паскаль бы много дал вначале, не зря его позиционировали для обучения.

>С++ становится неуправляемым

Хорошо пошутил, молодец.

А то )

> При некотором скилле на плюсах можно что угодно и быстро делать.

«Некоторый скилл» заключается в следующем:

Язык заставляет программиста изучить систему метапрограммирования через шаблоны, паттерны, различные механизмы и принципы декомпозиции программы, управления памятью и работы с указателями (глубокое копирование, смарт указатели, интерфейсные указатели, 100500 реализаций коллекций и итераторов, грани, фабрики, объекты классов, выделение памяти из пула, множественная передача, ручной подсчёт ссылок, автоматический подсчет ссылок... блджад! кажется, я могу перечислять названия этих магических заклинаний бесконечно!), освоить парочку запутанных библиотек шаблонов, научиться читать и понимать 10-строчные сообщения об ошибках, состоящие из <<<<>>>>, реализовать в процессе всего этого несколько матерых велосипедов, чтобы понять изученное, и... И ничего не даёт взамен.

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

> Идти к нему через паскаль может оказаться комфортнее.

Хм, сомнительно.)

Кроме того, строгость последнего окажет благотворное влияние на формирование программистского мышления, потом и на C будешь правильнее писать.

Типа, надо подучить хорошо пистон перед освоением perl ))

Ассемблер x86_64

Точно. 64 бита правда не особо нужны, но начать надо именно с ассемблера. Без него довольно трудно иметь хорошее понимание, как там все внутри работает.

ну 64 бита для того, чтобы не отставать от жизни. а так можно и с 16 начинать.

python3

сабж

и... И ничего не даёт взамен.

Тред потихоньку зарастает жиром.

Представьте себе такую ситуацию. Есть десктоп на котором стоит система с гномом или КДЕ или чем-то ещё, неважно. И абсолютно весь софт, кроме ядра, написан питоне/руби/лиспе. Все демоны, системные библиотеки, рабочий стол, офис, IDE, разный вспомогательный софт. Представили? А теперь подумайте как это все будет адово тормозить, жрать память в неимоверных количествах на пустом месте. Все эти ваши питоны могут нормально работать лишь потому, что большая часть остального софта написана на C/C++.

Эх... Времена изменились. Раньше термин «высокий уровень» по отношению к языку подразумевал наличие слоя абстракции над системой команд процессора. Языком высокого уровня вполне можно было назвать Си или Паскаль. Теперь «высокий уровень» подразумевает высокий уровень потребления машинных ресурсов.

> Типа, надо подучить хорошо пистон перед освоением perl ))

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

>* Системное и/или низкоуровневое программирование. >Высокопроизводительные службы.

Си без вариантов

http://www.disy.cse.unsw.edu.au/lxr/source/pistachio/src/?v=okl4-3.0

> Представьте себе такую ситуацию. Есть десктоп на котором стоит система с гномом или КДЕ или чем-то ещё, неважно. И абсолютно весь софт, кроме ядра, написан питоне/руби/лиспе.

Тред потихоньку зарастает жиром.

Всего два абзаца переставил, и даже развернутый ответ писать не надо.

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

Я одного не могу понять: откуда берутся эти байки о «четкости», «строгости» и т.п. паскаля.

согласен. паскаль - гуано, си -няшка

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

Пользователю насрать, как легко и эффективно ты воплощал свои суперидеи на настоящих высокоуровневых языках. результат жрет память и тормозит в 10-100 раз больше чем аналог на крестах? приложение ф топку, автора в биореактор на переработку, раз думать ленится.

> результат жрет память и тормозит в 10-100 раз больше чем аналог на крестах?

Тяжко там вам приходится в параллельной реальности.

после васика только на руби.

> Тяжко там вам приходится в параллельной реальности.

Добро пожаловать, на планету Земля, брат по разуму! Да, у нас тут, в XXI веке дела обстоят именно так.

Первый контакт, блджад...

> И абсолютно весь софт, кроме ядра, написан питоне/руби/лиспе.

лиспе

Кстати, кто юзал EQL? Как оно?

http://password-taxi.at/EQL

Реально ли заменить плюсы? Не такой же тормоз, как питон?

Тяжко там вам приходится в параллельной реальности.

http://habrahabr.ru/blogs/programming/66562/

Назови свои цифры, насколько в среднем питон тормознее плюсов.

scheme

в C ты будешь учится не программировать, а искать сегфолты, переполнения буфера, утечки памяти и другие C-специфичные ошибки.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gpp&lang2=p...

Tcl/Tk (тред не читал).

Плюсы:

• Кроссплатформенный — хошь под винды, хошь под Линукс.
• Язык сам по себе прост, как двери, и при этом достаточно мощный. Есть биндинги к базам данных, можно рисовать графики, можно работать с железом. Некоторые особо упоротые на нем даже сайты пишут.
• GUI из коробки и «встроен в язык», прост в понимании и реализации, мышкой возить не надо. Опять же, есть layuot managers.
• Это «почти лисп», только с несколькими типами скобочек :-)

Минусы:

• Иногда создается ощущение, что язык и библиотеки поддерживают и развивают слоупоки. Так что брать самые новые версии интерпретатора не советую.
• Некоторые неочевидные вещи приходится подолгу искать и спрашивать на форумах. Но — на ЛОРе есть специалисты по этому языку; ни один из моих вопросов без ответа не остался, за что всем им огромное спасибо.

Сам начал изучать этот язык после того, как ниасилил Qt, а начальство требовало GUI, да чтоб еще и под винду работало. В языке разобрался где-то за 3-4 дня, еще столько же писал первую серьезную программу, которой коллеги до сих пор пользуются для настройки своих датчиков.

Еще один непониматель того, что:

1) имеет значение не абсолютная скорость выполнения алгоритма, а скорость работы программы относительно налагающихся на неё требований производительности;
2) совершенно ничто не мешает писать критичные участки на Си — как отдельные процессы, так и модули, вызываемые из другого языка, и результат получается ничуть не хуже, и удосбтво разработки ничуть не страдает;
3) требования программы к ресурсам вообще в общем случае никак не коррелируют с используемым языком, а коррелируют с алгоритмами, применёнными в. А уж тормозящих на пустом месте быдлокодов на плюсах написано столько, что все лиспы, питоноруби и тикли вместе обзавидуются такому «эффективному» расходованию вычислительных мощностей.

В общем, забавный срачег, но пора бежать по делам. Завтра продолжим эту «высокоинтеллектуальную» беседу, если тред не снесут...

хоть и прошло много лет, а ничего проще и надежней tcl/tk таки нет в Linux.

+1!

Более того, большой плюс — кроссплатформенность. Я под винду пишу на этом языке чуть ли не больше, чем под Линукс — и все прекрасно работает. При этом я — не программист по образованию. Некоторый опыт был только с турбо-паскалем (куда же без него), встроенным языком матлаба и б-гомерзким VB6.

> Смысл множественного наследования я себе вообще слабо представляю за исключиением каких-нибудь утилитарных классов типа ref_counted, noncopiable. А вот RTTI, exceptions и шаблоны ограничивают пожалуй только в embedded.

Насколько я знаю, RTTI используется в C++ только для dynamic_cast, т.е. для обхода системы типов C++. Если вам необходима эта фича, то скорей всего вы неправильно спроектировали вашу программу.

Проблема с exception handling в том, что exception-safe код довольно сложно писать, и очень просто допустить в нем ошибку, приводящую к утечке памяти или другого ресурса. Намного проще не использовать исключения вообще.

Шаблоны хорошая штука, но то, как они используются в stdlib и boost - это жуть. Медленно компилируется и на какую-нибудь простенькую ошибку (например вместо == написал =) компилятор выдает несколько страниц текста, в котором даже намёка нет на истинную причину ошибки.

Вобщем эти фичи унылое говно.

Без этого всего C++ будет просто кастрированным унылым говном.

Следовательно C++ - унылое говно само по себе.

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

Э-э. Обычно в каждой новой версии добавляются новые приятные вкусности. Сам юзал 8.6 еще с alpha1 на сервере и на клиентских машинах - ни разу не подвел. Правда, скорость по тестам ниже, чем у 8.4 :(

Некоторые неочевидные вещи приходится подолгу искать и спрашивать на форумах

В дистрибутиве ActiveState полный хелп, там все есть с примерами кода, правда на буржуйском. А так, тут где-то на ЛОРе пробегала ссылка на переводную книжку Хоббса и Уэлша - лучший учебник.

Что-то ваш Tcl как-то убого выглядит, эдакая смесь скриптов на баше с javascript'ом...

> согласен. паскаль - гуано, си -няшка

си - няшка, только после того, как его освоишь. но бывают люди, которым это, похоже, вообще не дано.

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

Э-э. Обычно в каждой новой версии добавляются новые приятные вкусности. Сам юзал 8.6 еще с alpha1 на сервере и на клиентских машинах - ни разу не подвел. Правда, скорость по тестам ниже, чем у 8.4 :(

C этим не спорю. Но вот мне понадобилось строить графики (да еще и «красивые») — библиотека blt гуглится только для версии 8.4 хоть тресни. И ОГРОМНОЕ СПАСИБО тому энтузиасту, который таки портировал ее для версии 8.5 и сделал инсталлер для винды.

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

В дистрибутиве ActiveState полный хелп, там все есть с примерами кода, правда на буржуйском. А так, тут где-то на ЛОРе пробегала ссылка на переводную книжку Хоббса и Уэлша - лучший учебник.

По языку — да. Но снова-таки, некоторые вещи описаны весьма лаконично, непрофессионалу понять сложновато. Вон я недавно задавал вопрос о трассировке переменной — не ты ли мне тогда дал исчерпывающий ответ? А на той же wiki.tcl.tk описание-то есть, но понятно там не все. Ну и по некоторым вкусным библиотекам (например, TkZinc) документации негусто.

> Плюсы позволяют гораздо меньше думать о всякой рутине типо освобождения ресурсов в случае ошибки (RAII, smart pointers). И это очень сильно сокращает спектр ошибок, которых можно наделать. И код более емким становится, больше смысла, меньше вознию. Ну и благодаря шаблонам там куда более богатые возможности в компайл тайме. Чего стоят хотя бы Boost.MSM, Boost.Spirit. А если уж про C++0x (грядущий стандарт) говорить...

YOU* are full of bullshit. (c) Linus Torvalds

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it.

C++ leads to really really bad design choices. You invariably start using the «nice» library features of the language like STL and Boost and other total and utter crap, that may «help» you program, but causes:

- infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)

- inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.

Что-то ваш Tcl как-то убого выглядит, эдакая смесь скриптов на баше с javascript'ом...

Здравствуй, зелененький, здесь еды нет :-)

Эта смесь «скриптов на баше и javascripta» уже десятки лет управляет телескопами — какая разница, как она выглядит?

> Некоторые особо упоротые на нем даже сайты пишут.

а это таки заразно ))

кстати, потом весьма забавляет вся маячня с пистонами, фреймворками и их названиями.

Мало того, и на Марсе tcl америкосы применили.

Хм, а ведь действительно: погуглил маленько, оказалось, что интерфейсы управления некоторыми мелкими телескопами написаны на Tcl/Tk. В принципе, если железяка дешевая и скорость некритична - скриптовый язык вполне подойдет...

> Но снова-таки, некоторые вещи описаны весьма лаконично, непрофессионалу понять сложновато

Да, бывает порой, приходится помедитировать над смыслом написанного, ну и примеры погонять. С «Практическое программирование на Tcl и Tk» легче, жаль я видел только издание по 8.4.

о трассировке переменной — не ты ли мне тогда дал исчерпывающий ответ?

да