Комментарии 65
Не помню, сколько лет назад впервые заинтересовался этим языком, но одно могу сказать точно, что за все эти годы он не «повзрослел» — не стал стабильным и не обзавёлся инструментарием.
По моим наблюдениям, почти все рано или поздно от него отворачиваются, даже те, кто мог бы быть его движущей силой, я о тех людях, которые делают замечательные инструменты, библиотеки или биндинги.
Скорее мертв, чем жив. К сожалению…
По моим наблюдениям, почти все рано или поздно от него отворачиваются, даже те, кто мог бы быть его движущей силой, я о тех людях, которые делают замечательные инструменты, библиотеки или биндинги.
Скорее мертв, чем жив. К сожалению…
Все верно, но моя позиция как раз и состоит в том, что это примерно потому же, почему не выстрелил Go и не выстрелит Darth — из за инертности аудитории и из за страха того, что положение не изменится в лучшую сторону.
По поводу инструментария можно делать отдельную статью, однако скажу сразу, что уже сейчас можно писать в студии (не говоря уже о QtCreator-е и эклипсе), а стандартная библиотека существенно богаче оной в C++.
По поводу инструментария можно делать отдельную статью, однако скажу сразу, что уже сейчас можно писать в студии (не говоря уже о QtCreator-е и эклипсе), а стандартная библиотека существенно богаче оной в C++.
Дело не в инертности. Если бы D был детищем Google, я бы с удовольствием писал бы на нем :) Потому что это был бы «продукт», а пока это больше похоже на хобби Брайта.
По моему личному мнению — это как раз только достоинство. LISP, C, lua, Mathematica — тоже изначально писались «для себя», без размышлений о будущей поддержке. Самый лучший продукт тот, который вырос из хобби.
Перефразирую — лучший продукт, это тот, которым хоть косвенно пользуется автор продукта.
Тоже верно, но я намекал не на это. Вы, я так понимаю, апеллируете к тому, что для себя плохо не сделаешь — ну так это бесспорно, только я говорил совсем о другом.
О том, что проект, который хобби, делается не из под палки, не для денег, не для того, чтобы клиенты схавали, не для того, чтобы даже дойти до финиша. А для души. Тщательно продумывается каждая деталь. Как минимум потому, что если это хобби, то автору элементарно нравится продумывать. Потому, если продукт доходит до логического завершения, то несомненно в лучшем виде.
О том, что проект, который хобби, делается не из под палки, не для денег, не для того, чтобы клиенты схавали, не для того, чтобы даже дойти до финиша. А для души. Тщательно продумывается каждая деталь. Как минимум потому, что если это хобби, то автору элементарно нравится продумывать. Потому, если продукт доходит до логического завершения, то несомненно в лучшем виде.
Не надо вот бросаться словами, Go живее всех живых.
На мой взгляд вы не увидили настоящей проблемы D. Вы написали, что он «не выстрелил», но потом почему-то сразу перешли к его удобству и возможностям. Язык может быть сколь угодно красивым и удобным, но это никак не поможет тому факту, что он «не выстрелил». У D нет вменяемого инструментария, он не стандартизирован уже просто с невероятной быстротой успел обзавестись несколькими несовместимыми фремворками. D подерживается неизвестно кем, к нему нет интереса со стороны ведущих компаний, вести разработку коммерческих проектов на D просто рискованно. Плюс отсутствуют специалисты по D в достаточном объеме, что тоже чревато проблемами для бизнеса. А так да, язык красивый. Но это ничего не меняет.
Более того, в D возможно то, чего мы все так хотим в Python (извиняюсь, если это на самом деле можно, но я точно знаю, что в lambda — нельзя, сам пробовал):
Кто не понял — речь о замыканиях :)
Либо я вас неправильно понял, либо вы гоните…
Обязательно познакомлюсь поплотнее, когда D2 включат в GCC. Язык действительно хорош сам по себе, но вникать глубже хелловорлдов пока смысла не вижу.
Я чего-то не понял, или в последнем примере пропущена передача в конструктор параметра s?
Не используйте сноски. В книгах можно немедленно их прочесть, а тут надо три экрана крутить ради пары слов.
А в каком смысле конструкторы не наследуются? Т.е. если самому не вызвать конструктор базового класса или не проинициализировать базовые члены вручную, то они останутся неинициализированными?
В смысле нельзя не писать их и надеяться на то, что компилятор скомпилирует
B b = new B;
где class B: A {...}, а у A определен конструктор по умолчанию.
Конструктор базового класса можно вызвать как super(args);
B b = new B;
где class B: A {...}, а у A определен конструктор по умолчанию.
Конструктор базового класса можно вызвать как super(args);
Неудобно и бессмысленно… По крайней мере, я никогда не сталкивался в C++ с ситуацией, где вызов базового конструктора, сгенерированный компилятором, приводил к проблемам.
Сдается мне, вы меня не поняли, а может я вас.
Уверен, так будет понятней:
Выводит:
A
B
~B
~A
Как и аналогичная программа на C++.
Однако, программа:
Не компилируется потому, что вместо B. this(string s) не подставляется A.this(string).
Уверен, так будет понятней:
import std.stdio;
class A
{
this() {writeln("A");}
~this() {writeln("~A");}
}
class B : A
{
this() {writeln("B");}
~this() {writeln("~B");}
}
void main()
{
B b = new B;
clear(b);
}
Выводит:
A
B
~B
~A
Как и аналогичная программа на C++.
Однако, программа:
import std.stdio;
class A
{
string s;
this() { s = ""; }
this(string s) { this.s = s; }
}
class B : A
{
override string toString() { return "trollface"; }
}
void main()
{
B a = new B("hi!");
}
Не компилируется потому, что вместо B. this(string s) не подставляется A.this(string).
С одной стороны язык D выглядит как язык мечты, невзирая на то, что язык еще окончательно не сформировался.
С другой стороны, у него не очень хорошо с платформами, отличными от x86, поэтому я бы не стал его пока использовать в реальных проектах.
С другой стороны, у него не очень хорошо с платформами, отличными от x86, поэтому я бы не стал его пока использовать в реальных проектах.
Давно присматриваюсь к D, но скорее ради интереса, чем для работы.
Всё. конечно, упирается в инструментарий. Вон Scala насколько удобна, но плагины сырые, поэтому даже JetBrains, несмотря на официальную поддержку плагина для Scala (правда — всего двумя разработчиками), решили сделать свой язык на JVM, который изначально будет хорошо интегрирован в среду разработки.
Всё. конечно, упирается в инструментарий. Вон Scala насколько удобна, но плагины сырые, поэтому даже JetBrains, несмотря на официальную поддержку плагина для Scala (правда — всего двумя разработчиками), решили сделать свой язык на JVM, который изначально будет хорошо интегрирован в среду разработки.
Все пишут про нехватку инструментов для программирования.
Согласен, их меньше, чем для некоторых других языков, однако не все так ужасно.
Вообще-то я хотел в следующей статье обсудить другие темы, но если коммьюнити желает — могу подробно описать все, что знаю (и еще нагуглю) по этому поводу. Заранее скажу, я программирую на D только пару недель, однако нехватки инструментария не ощущаю.
Согласен, их меньше, чем для некоторых других языков, однако не все так ужасно.
Вообще-то я хотел в следующей статье обсудить другие темы, но если коммьюнити желает — могу подробно описать все, что знаю (и еще нагуглю) по этому поводу. Заранее скажу, я программирую на D только пару недель, однако нехватки инструментария не ощущаю.
Мне кажется, что выход стандарта C++11 был сильным шагом. Приведённый ниже код уже поддерживается распространёнными компиляторами (проверено Visual Studio 2010, должен работать с gcc, где поддержка нового стандарта более полная). Код похож на примеры приведённые в статье. Думаю, что если стоит выбор куда инвестировать свои усилия, в изучение C++11, или в изучение D, у C++11 есть определённые преимущества. Мы уже сейчас активно используем реализованное в Visual Studio 2010 подмножество C++11 в production, и впечатления очень хорошие.
int incTwice(int a)
{
auto inc = []( int i ) { return i+1; };
return inc(inc(a));
}
#include <functional>
void testLambdas(int c)
{
auto f = []( int a ) { return a+1; };
std::function<int(int)> f2 = []( int a ) { return a+1; };
auto inc = [c] (int a) { return a+c; };
}
Верно, лямбды создаются уже и в C++.
Однако, во-первых они не так хороши. Ваше [] на самом деле почти всегда (если это делегат) совсем даже не [], а сложным выражением, выбирающим какие переменные и как туда послать. А если их много?
Во-вторых может это мой личный вкус, но std::function<int(int)> — это, конечно, хорошо, а что, если она вектор строк возвращает? Макароны получаются. Или много typedef. Замечу, что да, auto спасает, но работает оно не везде и не для всех типов.
Попробуйте, например, написать такой код:
Но это все, конечно, житейские мелочи, глобально я полностью согласен, что новый стандарт неплохо улучшил язык.
Однако лямбды — далеко не все, что я описал в статье и тем более, далеко не все, чем отличается C++ от D.
Однако, во-первых они не так хороши. Ваше [] на самом деле почти всегда (если это делегат) совсем даже не [], а сложным выражением, выбирающим какие переменные и как туда послать. А если их много?
Во-вторых может это мой личный вкус, но std::function<int(int)> — это, конечно, хорошо, а что, если она вектор строк возвращает? Макароны получаются. Или много typedef. Замечу, что да, auto спасает, но работает оно не везде и не для всех типов.
Попробуйте, например, написать такой код:
int[string] function(int[string]) getFun()
{
return (int[string] a) {return a ~= ["hi" : 1];};
}
Но это все, конечно, житейские мелочи, глобально я полностью согласен, что новый стандарт неплохо улучшил язык.
Однако лямбды — далеко не все, что я описал в статье и тем более, далеко не все, чем отличается C++ от D.
Ой, ошибочка, там И потом тип функции getFun тоже можно заменить на auto. Что тоже очень удобно.
Эквивалентная реализация на C++ будет раза в 2 длиннее из-за необходимости прописывать библиотечные типы std::function, std::map, std::string там, где D использует встроенные типы. Гораздо важнее то, что нужно больше внимания уделять логике передачи параметров и возврата результата по значению или ссылке: на С++ я бы предпочёл возвращать функцию с типом «void (map&)».
Чтобы в C++11 компилятор делал черновую работу, и сам решал что и как собирать в функцию можно использовать синтаксис [=], [&]. Первый вариант будет сохранять копию используемых переменных в функциональном объекте, второй — сохраняет ссылки. Лично я [=], [&] предпочитаю не пользоваться, и явно специфицирую, что и как должно сохраняться («Explicit is better than implicit», Zen of Python)
А вообще было бы интересно почитать об особенностях, для которых нет аналогов в языке или библиотеке C++11; о новых стилях программирования используя D.
Чтобы в C++11 компилятор делал черновую работу, и сам решал что и как собирать в функцию можно использовать синтаксис [=], [&]. Первый вариант будет сохранять копию используемых переменных в функциональном объекте, второй — сохраняет ссылки. Лично я [=], [&] предпочитаю не пользоваться, и явно специфицирую, что и как должно сохраняться («Explicit is better than implicit», Zen of Python)
А вообще было бы интересно почитать об особенностях, для которых нет аналогов в языке или библиотеке C++11; о новых стилях программирования используя D.
1) [=], [&] и то и другое, несомненно, отвратительно: большие обьекты при [=] будут тормозить + вдруг надо именно по ссылке, а встроенные типы при [&] могет нежелательно себя вести. Вы совершенно правы, что управляете процессом вручную. Вот только в D в данном случае Explicit equal to implicit. Об этом я еще расскажу, несомненно.
2) Да, я надеялся, что аудитории понравится и я смогу продолжить цикл и описать целую кучу особенностей, которые сами по себе вроде как довольно милые, но сильно не впечатляют, но учитывая, что их очень много, экономия кода и времени его написания получается внушительная. Про время я пока сужу субьективно, так как больших проектов не писал, но оно как минимум пропорционально количеству кода.
2) Да, я надеялся, что аудитории понравится и я смогу продолжить цикл и описать целую кучу особенностей, которые сами по себе вроде как довольно милые, но сильно не впечатляют, но учитывая, что их очень много, экономия кода и времени его написания получается внушительная. Про время я пока сужу субьективно, так как больших проектов не писал, но оно как минимум пропорционально количеству кода.
Насчёт (2) — не возражаете против небольшой конкуренции? :) Я вижу по количеству плюсов, что определённый интерес к языку есть, хочу написать небольшой обзор метапрограммирования/CTFE в D. Как раз то самое, что С++11 и не снилось :)
Ну как раз следующая статья у меня планировалась по метапрограммированию и compile-time computation :)
— A, B, C, D, E, F, G,
John is hiding far from me.
Looking here, looking there,
I can’t see him anywhere.
Вспомнилось с уроков английского.
Надо же, как нас муштровали этой считалкой, что даже спустя 1,5 десятка лет ее помню.
С нетерпением жду продолжения статей об «алфавитных» языках. :)
John is hiding far from me.
Looking here, looking there,
I can’t see him anywhere.
Вспомнилось с уроков английского.
Надо же, как нас муштровали этой считалкой, что даже спустя 1,5 десятка лет ее помню.
С нетерпением жду продолжения статей об «алфавитных» языках. :)
>в этом месте программисты на паскале торжествуют
Они еще остались?
Как легко можно понять по моему профилю, я — преданный поклонник D2 и считаю его лучшим образчиком _дизайна языка_ из представленных широкой публике вариантов. Но D2 своенравен и регулярно испытывает моё терпение, даже несмотря на то, что я не использую его ни для чего, кроме любительских экспериментов.
На мой взгляд, язык отчаянно нуждается в сильном open-source сообществе и главная проблема сейчас — то, что Walter всё ещё хочет сохранить за собой старые наработки Digitalmars. Люди, участвующие в разработке компилятора и стандартной бибилиотеки, вне всякого сомнения, гениальны — из регулярного чтения обсуждений тех или иных исправлений в newsgroup я узнал больше о дизайне языков, чем из любой книги. Но их довольно мало и они физически не могут выдать достаточный темп разработки для такого сложного по техническому обеспечению языка. Да, есть gdc и ldc — но в их разработке как раз «мастодонты» участия не принимают, более фанатские проекты, обречённые на постоянную синхронизацию с новыми релизами dmd.
Характерно, что самый заметный прирост скорости разработки совпал с банальным переездом проекта на github.
На мой взгляд, язык отчаянно нуждается в сильном open-source сообществе и главная проблема сейчас — то, что Walter всё ещё хочет сохранить за собой старые наработки Digitalmars. Люди, участвующие в разработке компилятора и стандартной бибилиотеки, вне всякого сомнения, гениальны — из регулярного чтения обсуждений тех или иных исправлений в newsgroup я узнал больше о дизайне языков, чем из любой книги. Но их довольно мало и они физически не могут выдать достаточный темп разработки для такого сложного по техническому обеспечению языка. Да, есть gdc и ldc — но в их разработке как раз «мастодонты» участия не принимают, более фанатские проекты, обречённые на постоянную синхронизацию с новыми релизами dmd.
Характерно, что самый заметный прирост скорости разработки совпал с банальным переездом проекта на github.
Собственно, моя мечта — Google вместо всяких Go и Darth'ов просто покупает Digitalmars с потрохами и даёт допилить эту няшку :) Несбыточная, конечно же.
Несколько минут уже разглядываю Ваш профиль и не могу увидеть того, из-за чего сразу должно стать понятным, что Вы — преданный поклонник D2 :) Выручайте, а то меня уже любопытство съест скоро :]
Кстати, у сего замечательного языка программирования наконец таки появился официальный русский сайт dlang.ru/
Кстати, этот сайт давно и надежно не работает. Как вариант, вэлком — http://dlanguage.ru. Официальный или не официальный — не суть. Но кого нашел на смежных форумах, пригласил всех. Заходите на огонек! :-)
Увы ((( Хотел сменить регистратора, и не успел буквально три дня. Кто-то умудрился выкупить доменное имя раньше, видать дальше продали. Я не совсем в курсе этого вида «бизнеса», но результат нехороший((
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Язык программирования D