Самые уродливые ЯП

А чего в нём уродливого? Наоборот, прост как палка.

С++, bash.

Прведите, пример такого случая, пожалуйста

если вспомню - приведу, тьфу-тьфу, на моей последней работе с C++ дела иметь уже не приходится

Этот тред полон неосиляторами shell.

если вспомню - приведу

Т.е. языка не знаете, но говном оплёвываете.
:(

BASIC, Turbo Pascal

Java - за аннотации, instanceof, extends, implements.
CLIPS - эдакая пародия на LISP для эмулирования экспертных систем (ИИ) за неимоверное количество скобок.
Matlab - выкинул и использовал Python

C++

Visual Basic

ессесна не знаю, хотя два года на нём работу работал

ессесна не знаю, хотя два года на нём работу работал

не можешь привести пример - значит не знаешь, а «два года на нём работу работал» - «индусы» и поболее работают

Проще перечислить наименее уродливые: С, python, общелисп, racket. haskell концептуально симпотный, но уж очень много ограничений для применения в продакшне... да и статическая типизация зачастую избыточна.

сопсна, мне просто жалко тратить драгоценные годы своей жизни на изучение этого страшилища

дык, я и написал - не знаю, дальше что? C++ страшен и не нужен, а за скоростью воздыхайте дальше на своих 486х с 16 мегабайтами оперативки

python

не уверен

я тебе даже больше скажу, я ни одного языка толком не знаю, и как-то не особо страдаю от этого

изучение этого страшилища

по ссылке нытье неосилятора, говорю как человек, который многое бы в плюсах переправил

а за скоростью воздыхайте дальше на своих 486х с 16 мегабайтами оперативки

ну вот сейчас мне платят 6500$ в месяц за задачу, которую не потянула Java на планшетах, это кстати один из трех проектов, что я сейчас делаю за деньги, но вы и дальше воздыхайте на свои любимые ЯП для хомячков - с ними проще

я тебе даже больше скажу, я ни одного языка толком не знаю, и как-то не особо страдаю от этого

я и не сомневался

входной язык autotools, конечно

Да ну
есть хуже

Возможно, но действовал мне на нервы этот

sub main()
debug.print(«нервы»)
end sub

Указатели кажутся мне вершиной ужаса программиста.

неосилятор ))

Работа с указателями - самое торкающее, что есть в С

сопсна, мне просто жалко тратить драгоценные годы своей жизни на изучение этого страшилища

Статья явно писана неосилятором, не разобравшимся толком не только в C++, но и в принципах построения кода в принципе (простите за тафтологию).

C изучается за пару днуй и осваивается за неделю-две.

Я студентов лет 20 назад учил, так все до одного без проблем разобрались за семестр(занятия раз в неделю)

дык, я и написал - не знаю, дальше что? C++ страшен и не нужен, а за скоростью воздыхайте дальше на своих 486х с 16 мегабайтами оперативки

C++ как раз нужен для computation expensive задачь, его не нужно пихать в каждую дырку в наше время. Но есть задачи, которые даже на C++ приходится повозится, что-бы работало быстро (и да, я имею личный опыт разработки подобных вещей, на текущем рабочем месте, так что это не «теоретически такие задачи есть» а «мне самому постоянно приходится с этим сталкиватся, и альтернатив C++ у меня нет»).

а за скоростью воздыхайте дальше на своих 486х с 16 мегабайтами оперативки

Тем не менее, Гуглокарты на жабе садят бытарейку за 20 минут а на Блэкбери, С/С++ карта без проблем водила меня по маршрутам 2 часа и телефон без подзарядки дожил до вечера.

6500$ в месяц

зачем столько денег нужно? Мне в два раза меньше за глаза хватает и ещё остаётся.

на свои любимые ЯП

зачем любить ЯП? Любить нужно женщин, ценить жрачку, вкусный алкоголь. А ЯП может быть красивым, может быть уродливым, но любовь - это что-то из серии «хочется странного».

с ними проще

ессесна, ведь с ними можно думать о реализации задачи, а не делать закат солнца вручную

дык, я и написал - не знаю, дальше что?

не нужно оплёвывать говном, то, чего не знаете.

А по пунктам возражения будут?

не нужно оплёвывать говном, то, чего не знаете.

эта, как там, «сперва добейся», да?

C++ - переусложнённый язык, даже когда в этой переусложнённости смысла нет. Я уже избил этот пример, но ни один плюсокодер мне так и не выдал безитераторную альтернативу std::transform (который map). Не, ну вы конечно можете дальше ждать с моря погоды, может быть в стандарте ещё лет через 8 появится. range based for же сделали в итоге. Лямбды с auto. да и кучу всего другого полезного, что в других языках было 300 лет тому назад.

А пока что это не нужно, да

Как и композиция, карринг итп.

его не нужно пихать в каждую дырку в наше время.

золотые слова! Не серебряная пуля потому что.

Но есть задачи, которые даже на C++ приходится повозится, что-бы работало быстро

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

мне самому постоянно приходится с этим сталкиватся, и альтернатив C++ у меня нет

сочувствую, что ещё сказать

Работа с указателями - самое торкающее, что есть в С

и зачастую ненужное, так как вызвано несовершенством языка/компилятора

Makefile, вот где ужас и непонимание как оно будет работать в конкретном случае и что сделает с передаваемыми параметрами.

ну да, плохой негодный компилятор, libastral не поддерживает

зачем libastral? есть куча стандартных паттернов при работе с указателями, так что всё вполне однозначно. Нужно отличающееся от стандартного поведение - байтолюбствуйте nazdorovie!

Самый примитивный пример - передача параметров.

зачем столько денег нужно?

чтоб потом иметь время и возможность заниматься тем, что больше нравится

зачем любить ЯП?

не знаю, но у тебя, например, явно есть предпочтения - и это нормально

ессесна, ведь с ними можно думать о реализации задачи

в списке твоих «любимых» ЯП - практичных нет, так что ты явно лукавишь

чтоб потом иметь время и возможность заниматься тем, что больше нравится

то есть тебе не нравится писать на плюсах?

явно есть предпочтения

это не любовь

в списке твоих «любимых» ЯП - практичных нет, так что ты явно лукавишь

применимые на практике (может и не массово) - есть. Хотя, это не самое главное, главное - они в основном красивы и изящны, в отличие от.

Я уже избил этот пример, но ни один плюсокодер мне так и не выдал безитераторную альтернативу std::transform (который map)

ты его так сильно избил, что написал аж целый комментарий, ну и если что - std::transform не завязан на итераторы, но тебе простительно этого не знать, ты всего два года на плюсах писал ;)

то есть тебе не нравится писать на плюсах?

я хочу заниматься своими проектами, а не чужими

это не любовь

я не вкладываю буквальное значение в это слово, когда говорю об ЯП

применимые на практике (может и не массово) - есть

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

Хотя, это не самое главное, главное - они в основном красивы и изящны

это ли не любовь ;)

PowerShell

Lua

std::transform не завязан на итераторы

http://www.cplusplus.com/reference/algorithm/transform/

я хочу заниматься своими проектами, а не чужими

меня уже давно не интересует программирование «для себя», есть гораздо более интересные вещи

но не любой ЯП имеет большое кол-во качественных компиляторов, библиотек, инструментов

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

это ли не любовь ;)

не думаю

т.е. ты даже не знаешь, что такое шаблоны?

Вы же все равно язык не знаете, смысл вам по пунктам разжевывать?

Самая большая проблема чувака, написавшего сей C++ FQA пожалуй в том, что он пытается смотреть на C++ глазами C#/Java программиста. У C++ совершенно особый runtime, это язык который развив в последних своих ревизиях, огромные высокоуровневые способности, мало уступающие Java и C#, не утратил своей тесной интеграции с аппаратной частью. Как говорил Страуструп - «не нужно абстрагироваться от машины, машина - ваш друг» (дословно, точной цитаты не помню), и C++ полностью реализует эту возможность, при этом являясь высокоуровневым языком, позволяющим общатся с машиной и оставатся на высоком уровне одновременно. Но это порождает некоторые особенности того-же рантайма, которые в теории то можно пофиксить, но это приведет уменьшению других качеств языка.

В частности пункт 1 списка «No compile time encapsulation» - это оно и есть. Однако это ограничение языка легко обходится тем-же Bridge pattern-ом.

Пункт «Outstandingly complicated grammar» - говорить нечего, «неосилятор, сам признался». С++ предоставляет много возможностей напрочь отсутствующих в других языках (те-же темплейты в том виде, как они есть в C++, еще есть только в ADA), и за это приходится платить да, временем компиляции возросшим и более сложным к пониманию синтаксисом, не умеешь - не берись.

«No way to locate definitions» - в современных IDE все эти проблемы давно решены.

«No run time encapsulation» - опять полный бред, попытка обратится к массиву за его границами приводит к exception-у std::out_of_range, которое можно отловить, обработать, и продолжить работать дальше, если очень хочется.

«No binary implementation rules» - это скорее плюс, а не минус, т.к. позволяет компилятору сгенерировать наиболее эффективный код под данную платформу.

«No reflection» - чего нет, того нет. Если бы в C++ была reflection, то это были бы не C++ а Java, с той-же скоростью работы.

«Very complicated type system» - что сказать, неосилятор.

«Very complicated type-based binding rules» - еще раз неосилятор.

«Defective operator overloading» - от части поторение предыдущего пункта, т.к. ссылается на него. Что касается про то, что должен возвращать overloading оператор, - во первых уже больше не проблема с использованием moving семантики, а во вторых и раньше не было проблемой, т.к. парадигма для тяжелых обьектов - «легкий в плане обьема мелкий внешний класс, с shared_ptr<impl> внутри», так что все копируется быстро по значению, никаких проблем не возникает.

«Defective exceptions» - чел жалуется, что «заставляют писать exception safe code». НЕОСИЛЯТОР. Писать код exception safe - не сложнее, чем писать hello world на бейсике. Так-же жалуется что «приходится использовать RAII», однако не стоит забывать, что RAII - черезвычайно сильная и мощная концепция, и очень жаль что в C# и Java она не поддерживается полноценно и так удобно, как в C++. Если бы оно было бесполезным, в C# и Java не стали бы вносить костыли, которые как-то эмулируют RAII. Да, в C# и Java есть GC, но, сюрприз-сюрприз, он следит только за памятью. А вот всякие там сокеты, хендлы, потоки - как-то забывает закрывать. И даже если finalize метод класса закроет рано или поздно, - некогда не известно, когда это случится, а это может привести к тому, что данные например по сети не будут посланы до тех пор, пока GC не надумает прибить обьект, или еще к чему похуже. С RAII мы бесплатно плучаем абсолютно детерминированное поведение, с 100% определенным порядком вызова деструкторов.

«Duplicate facilities» - ему бы книжек почитать умных, что люди советуют использовать, а что не использовать. Говоря о том-же даже векторе vs c-array, они служат для разных целей, и для вектора - люди используют вектор. c-array нужен только там, где нужны POD типы, - таких случаев не много.

«No high-level built-in types» - «ни о чем», какая разница, где обьявлены типы - в ядре языка, или в библиотеке, которая является стандартной и идет с компилятором все равно. Да сообщения об ошибках порой выходят большие, но это расплата за высокую производительностью.

«Manual memory management» - устарело лет так 12 назад. Всякие там boost::shared_ptr и std::shared_ptr, не только не хуже GC, но в чем-то и лучше, т.к. решают успешно те-же задачи (с оговоркой, что приходится чуть больше думать, и не забывать разруливать цикличные ссылки через weak_ptr), но они-же и дают то, чего не может дать ни один GC - абсолютный детерменизм, - всегда можно достоверно просчитать, когда какой деструктор будет вызван.

«Defective metaprogramming facilities» - во первых, помимо шаблонов, сейчас в C++ имеются и полноценные лямбды, из которых можно динамически скомпановать произвольный код. Во вторых, шаблоны в C++ - довольно уникальный инструмент, которого нет ни в C# ни в Java. Начнем с того, что Generic-и, как они есть в C# и Java - это по сути синтаксический и type check sugar к просто классам, получающим в качестве аргументов обычные Object. Плюсовые же шаблоны разворачиваются индивидуально в момент компиляции, и позволяют компилятору производить глубокую оптимизацию кода, в зависимости от конкретных параметров шаблона, что в ряде случаев увеличивает производительность на порядки, и при этом позволяет писать generic код, который потом просто инстанциируется множество раз для разных типов данных. Ну и вообще, шаблоны в C++ - это Тьюринг-полный язык, сам по себе, и используя только синтаксис шаблонов и ничего более, можно например во время компиляции, заставить компилятор посчитать факториал числа или еще чего. Чел верно подмечает, что нельзя смешивать динамический полиморфизм и статический, но тут уж извините, либо то, либо то. Последствие высокой производительности.

«Unhelpful standard library», - boost же, и ACE.

«Defective inlining», - мало о чем. Да, если явно писать inline, то имеем эти проблемы. Можно не писать явно inline, писать функцию как обычно, и задать опции оптимизации компилятору и линковщику, и они сами, все что можно заинлайнить, заинлайнят. Будет 1-в-1 аналог недавно появившегося в C# свойства «AggressiveInlining»

«Implicitly called & generated functions» - скажу кратко - неосилятор. Это вообще то, чему новичков учат на первых порах, и за что сильно бьют линейкой по рукам, если не учитывают в коде. Да, особенность языка, но всем известная.

Haskell.

Тем не менее, Гуглокарты на жабе садят бытарейку за 20 минут а на Блэкбери, С/С++ карта без проблем водила меня по маршрутам 2 часа и телефон без подзарядки дожил до вечера.

У вас есть уже смарт с BB10? Просто на более древних BB, писать можно было _только на java_.

меня уже давно не интересует программирование «для себя», есть гораздо более интересные вещи

ага - работа на кого-то

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

если говорить про практичность (а мы говорили о ней) - «красивый язык с минимумом инструментов» это именно «программирование «для себя»», а не способ эффективно решить задачу

Да.

Шож, это тогда сильный аргумент, купить на следующей итерации обновления телефона, что-нибудь на BB10, вместо андроеда :)

З.Ы. По слухам Microsoft для Windows RT тоже мотивирует разработчиков писать на чистом C++, для того, что-бы жрало поменьше.