Язык D

стоит конечно - уже все мировые гиганты ит-бизнеса пишут на D

Да, да, любые прикладные, не особо.

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

Я пытался его плотно заюзать пару лет назад, но пришлось бросить из-за сырости, судя по чейнджлогам за это время ничего не изменилось. По результатам поплакался в бложик — http://metadeus.tumblr.com/post/713896145/d

имхо барахло. плюсы норм осилить и профит будет. «дни ненависти плюсов на хабре» не читать: бред неосиляторов от начала и до конца

плюсы норм осилить и профит будет

А зачем голову этим говном забивать? В какой области может вообще С++ понадобиться?

ооп + высокая производительность. читал я книгу как на си писать ооп. не нравится

Слишком сыро, слишком вяло развивается для убийцы C/C++.

Пять лет назад я на нем дипломную пытался писать :) Судя по всему с тех пор он недалеко ушёл. Считаю его мертвым языком, он уже не выстрелит. А вообще запомнился тем, что очень приятно на нем писать, стандартная библиотека симпатичная и удобная, сахарок в нужных местах насыпан, мощности хватает для всего, что хочется выразить.

ооп + высокая производительность. читал я книгу как на си писать ооп. не нравится

Ну высокая производительность — понятие относительное. Жаба вполне справляется на всяких хайлоадах, и ООП там не в пример проще, хоть и такое же кривое, как в плюсах.

читал я книгу как на си писать ооп. не нравится

Ну это, конечно упороться, да. Glib/GObject ещё есть, для наркоманов))

Как насчёт Go как замены плюсам? Как прокомментируют аноне?

Как насчёт Go как замены плюсам? Как прокомментируют аноне?

Замены плюсам в каких задачах? Я вообще не вижу ни одной ниши, где плюсам не было бы замены. Но зачем нужен go ещё менее понятно.

В go нет даже макросов нормальных, середина 20-ого века прям.

Стоит ли его изучать?

Вряд ли.

Может ли он стать достойной заменой плюсам?

Может.

Какие у него области применения?

ЯП общего назначения.

Говорят, сейчас он сырой, а что именно сыро?

Не столько ЯП сырой, сколько экосистема вокруг него.

Заинтересовал сабжевый язык

Умер, не приходя в сознание.

Но зачем нужен go ещё менее понятно.

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

А если хочешь нормальный ответ, то читай вот: Less is exponentially more от Роба Пайка.

В go нет даже макросов нормальных, середина 20-ого века прям.

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

А где ООП более «прямое», чем в жабе? руби?

плюсы не ООП язык всё-таки

ты еще и языком Vala наинтересуйся - потенциально крутой, даже есть софт на нем, но увы, опять же экосистема сырая, IDE только только рождаются типа поддержки в MonoDevelop, слышал недавно допилили и включили в состав

В go нет даже макросов нормальных, середина 20-ого века прям.

А разве это удобно читать код с «двойной вложенностью» что-ли? Уверенней себя чувствуешь, когда читаешь код, который не нужно препроцессить.

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

Активно? Тогда можно актуальную сссылку?

Ну, вот тут обсуждали (последнее собщение — август 2012): https://groups.google.com/forum/#!topic/golang-nuts/PYJayE50JZg/discussion

Еще вот тут обсуждают (последнее сообщение — сегодня): https://groups.google.com/forum/#!topic/golang-nuts/2STNBjQGvmo

Там еще помянули некую софтину gotgo, которая вроде как реализует темплейты каким-то способом.

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

ИМХО, плюсы — барахло. Ассемблер нормально осилить и профит будет. «Дни ненависти Ассемблера на Хабре» не читать: бред неосиляторов от начала и до конца.

Я вообще не вижу ни одной ниши, где Ассемблеру не было бы замены.

Приятно порадовала только скорость компиляции. По-моему до сих пор нет отладчика.

Используй Go, Люк!

В жабе как и в плюсах нет нормального ООП. А так - да, руби, смаллтолк, эйфель.

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

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

Ну CLOS, же.

Зачем препроцессить? В этом и суть макросов, что они инкапсулируют сложность и предоставляют абстракцию нужного уровня. Я же не про сишные макросы говорю.

Я вообще не вижу ни одной ниши, где Ассемблеру не было бы замены.

Юморист. А я вот вижу.

В C++ с модулями так же будет.

В жабе как и в плюсах нет нормального ООП

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

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

Почему-то у любого, пытающегося привести пример нормального ООП, аргументы иссякают уже после минуты спора.

Пример нормального ООП — CLOS. Множественное наследование, множественная диспетчеризация, комбинаторы методов. Минута пошла.

А на кой нужен этот сраный ООП? Плюсы сильны метапрограммированием на шаблонах, особенно в связке с бустом и возможностями C++11.

Юморист. А я вот вижу.

В какой же?

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

Может потому, что сама парадигма полностью реализована в полутора языках, а все остальное - только элементы или частичная поддержка. Вы же не считаете тот же Common Lisp чистым функциональным языком (ну или ruby). Хотя оба поддерживают данную парадигму.

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

О да...Т.е. тот же подход Erlang вы считаете неправильным? Он хоть и не ОО, но использует как раз обмен сообщениями. Но это лирика, на практике обмен сообщениями - более верный подход, нежели кривой вызов методов объектов, как это в тех же плюсах. ОО-среда должна быть «живой», т.е. меняться (реагировать) в зависимости от условий и входных данных. А не просто использовать класс как некую прослойку, абстракцию, которая просто позволяет не дублировать код.

Пример нормального ООП — CLOS. Множественное наследование, множественная диспетчеризация, комбинаторы методов. Минута пошла.

Не нормальное. Тогда и OOXtcl можно приравнять к нормальной. ОО-система в лиспах лишь надстройка. Изначально язык не поддерживал ООП, поэтому давайте не будем мешать мед с г...грушевым вареньем и честно скажем - пример Pharo, Squeak, Cincon VisualWorks.

А на кой нужен этот сраный ООП? Плюсы сильны метапрограммированием на шаблонах, особенно в связке с бустом и возможностями C++11.

А я где-то утверждал обратное? Но реализация ООП в плюсах не лучше чем в каком-нибудь perl.

В какой же?

Программирование собственных железяк, для которых и Сишечки нет или она в принципе не применима (то же самое с фортом).

Не нормальное.

Критерии нормальности в студию.

ОО-система в лиспах лишь надстройка. Изначально язык не поддерживал ООП.

И чо? В нормальном лиспе почти все надстройка, как детали реализации связаны с нормальностью/ненормальностью воплощения концепций?

Если тебя не смущает отсутствие нормальной IDE и развитых фреймворков а-ля Qt, то вперед

Контекст исходного сообщения был довольно криво выражен. Я прочитал его как недокрученное утверждение о том, что нет области, с которой не справился бы Си.

Пример нормального ООП — CLOS. Множественное наследование, множественная диспетчеризация, комбинаторы методов. Минута пошла.

Кстати, да. Множественное наследование - хорошая штука, если есть линеаризация списка наследования, а в CLOS она есть. Тогда нет «проблемы бриллианта». Эта идея с линеаризацией потом была заимствована Одерским, что вылилось в типажи (traits) в Scala. Эдакая смесь интерфейсов с реализацией и классов без конструктора.

Но по-моему ты здесь больше троллишь :) Вообще, CLOS еще очень хорош, когда есть макросы. Просто так удобнее генерировать код, когда методы и классы разделены. Впрочем, все это - темная материя для многих. Это все равно, что пытаться говорить на китайском с теми, кто его не знает.

Контекст исходного сообщения был довольно криво выражен. Я прочитал его как недокрученное утверждение о том, что нет области, с которой не справился бы Си.

«Я вообще не вижу ни одной ниши, где плюсам не было бы замены.» == «нет области, с которой не справился бы Си»

Вы серьезно?

Но по-моему ты здесь больше троллишь :)

Да ну, чего троллить. Когда я пишу на жабе то постоянно ощущаю ушербность этого классового ООПа с одиночным наследованием, мне даже прототипное ООП жабаскрипта больше по душе, т.к. гибче. А в CLOS как-то не доставлял вообще таких ощущений — все есть и всего достаточно для 99,9% нужд.

Мне в CLOS иногда не хватает того, что во многих языках класс обычно создает пространство имен. В CLOS это не так. Поэтому приходится более продуманно подходить к вопросу выбора имени метода.

Но идеального языка не существует в природе. Везде есть свои плюсы и минусы. Из языков ООП мне больше всего нравятся Scala и Common Lisp. Еще немного знаком со Smalltalk, но он какой-то совсем особенный.

Что касается ООП в Си++, то оно мне раньше нравилось, лет десять назад. Для низкоуровневого языка без автоматической сборки мусора по-своему даже очень неплохо.

Критерии нормальности в студию.

Полнота реализации парадигмы. Смаллтолк и его деалекты, раби, эльфиль.

И чо? В нормальном лиспе почти все надстройка, как детали реализации связаны с нормальностью/ненормальностью воплощения концепций?

Т.е. в лиспе есть то, что не является объектом, следовательно ОО-среда уже не полная.

Из языков ООП мне больше всего нравятся Scala и Common Lisp.

Из языков ООП ... Scala и Common Lisp.

Из языков ООП мне больше всего нравятся Scala и Common Lisp.

ООП ... Scala и Common Lisp.

Вы сделали мой день. Пошел закупаться пивом, буду отмечать что tcl стал ООП-языком.

Мне в CLOS иногда не хватает того, что во многих языках класс обычно создает пространство имен. В CLOS это не так. Поэтому приходится более продуманно подходить к вопросу выбора имени метода.

Согласен — раздражает жутко.

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

Да, тут тоже согласен. Сидя на жабе начинаешь с теплотой вспоминать даже ООП Си++ и его шаблоны.

Полнота реализации парадигмы. Смаллтолк и его деалекты, раби, эльфиль.

Ну и какие принципы ООП не реализуются в CL?

Т.е. в лиспе есть то, что не является объектом, следовательно ОО-среда уже не полная.

Не «не полная», я не чистая, тогда уж. Если не чистые системы считать неполноценными, то вам всегда придется довольствоваться одной парадигмой. Я считаю это скорее крупным минусом среды, нежели плюсом.