LINUX.ORG.RU

Язык D


0

2

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

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

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

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

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

Deleted

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

warmate ()

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

buddhist ★★★★★ ()

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

m0rph ★★★★★ ()

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

metadeus ()

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

punya ★★ ()
Ответ на: комментарий от punya

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

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

metadeus ()
Ответ на: комментарий от metadeus

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

punya ★★ ()
Последнее исправление: punya (всего исправлений: 1)

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

unfo ★★★★★ ()

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

Legioner ★★★★★ ()
Ответ на: комментарий от punya

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

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

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

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

metadeus ()

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

vladimir-vg ★★ ()
Ответ на: комментарий от vladimir-vg

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

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

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

metadeus ()

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

Вряд ли.

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

Может.

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

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

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

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

erfea ★★★★★ ()

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

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

gensym ★★ ()
Ответ на: комментарий от metadeus

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

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

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

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

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

proud_anon ★★★★★ ()
Последнее исправление: proud_anon (всего исправлений: 2)

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

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от metadeus

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

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

gag ★★★★★ ()
Ответ на: комментарий от proud_anon

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

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

gag ★★★★★ ()
Ответ на: комментарий от gag

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

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

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

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

proud_anon ★★★★★ ()
Последнее исправление: proud_anon (всего исправлений: 2)
Ответ на: комментарий от punya

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от metadeus

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

KRoN73 ★★★★★ ()

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

geometer ()
Ответ на: комментарий от BattleCoder

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

iMushroom ()

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

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

anonymous ()
Ответ на: комментарий от gag

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

metadeus ()
Ответ на: комментарий от KRoN73

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

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

metadeus ()
Ответ на: комментарий от iMushroom

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

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

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

quiet_readonly ★★★★ ()
Последнее исправление: quiet_readonly (всего исправлений: 3)
Ответ на: комментарий от quiet_readonly

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

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

metadeus ()
Ответ на: комментарий от iMushroom

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

Reset ★★★★★ ()
Ответ на: комментарий от quiet_readonly

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

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

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

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

iMushroom ()
Ответ на: комментарий от metadeus

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

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

iMushroom ()
Ответ на: комментарий от Reset

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

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

iMushroom ()
Ответ на: комментарий от KRoN73

В какой же?

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

metadeus ()
Ответ на: комментарий от iMushroom

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

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

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

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

metadeus ()

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

EugeneBas ★★ ()
Ответ на: комментарий от metadeus

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от metadeus

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

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

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

dave ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

Вы серьезно?

metadeus ()
Ответ на: комментарий от dave

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

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

metadeus ()
Ответ на: комментарий от metadeus

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

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

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

dave ★★★★★ ()
Последнее исправление: dave (всего исправлений: 1)
Ответ на: комментарий от metadeus

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

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

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

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

iMushroom ()
Ответ на: комментарий от dave

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

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

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

ООП ... Scala и Common Lisp.

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

iMushroom ()
Ответ на: комментарий от dave

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

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

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

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

metadeus ()
Ответ на: комментарий от iMushroom

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

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

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

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

metadeus ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.