> В 90-е было относительное затишье. Сейчас, похоже, наступило возвращение джидая^Wсотен похожих друг на друга, никому не нужных функционально-параллельных языков. У кого какие ставки на победителя?
У мну уже отвращение к языку из-за одного названия!
Наверно также как и водка: нахратит здаровье, ни дает ничего хорошего употребляющему ее, кроме мнимых сил и вызывает зависимость, называемую алкоголизмом.... :-/
Сдаеться мне, что авторы приверженцы хорошо побухать, раз ничего в голову кроме такого называния не пришло!
А раз так, то и ничего сверхествественного быть в продукте не может! Ибо уже давно научно доказано, что пьяный человек думает гораздо хуже трезвого....
> В 90-е было относительное затишье. Сейчас, похоже, наступило возвращение джидая^Wсотен похожих друг на друга, никому не нужных функционально-параллельных языков. У кого какие ставки на победителя?
C#, Java, C++. А объяснение простое -- сейчас не столько языки рулят, сколько библиотеки, фреймворки и дополнительные инструменты (IDE, отладчики, профайлеры и пр.). Поэтому мало придумать новый язык, нужно снабдить его всем этим. В случае OpenSource данный процесс занимает десятилетия (можно вспомнить сколько времени формировались библиотеки для Perl/Python/Ruby). А если не OpenSource, то только таким монстрам, как Sun и MS удалось в последнее время создать достаточно продвинутые платформы. Разве что Google чего-нить родит ;)
Erlang, имхо, в лучшем случае повторит судьбу Lisp-а и Prolog-а: будут потрясающие по своей успешности проекты и проникновение в различные сферы. Но мейнстримом не станет и будет использоваться только своими приверженцами.
А может и произойти как с Ruby -- толкнут на Erlang-е удачный фреймворк для попсовенькой темы, начнется бум, после которого народ набьет шишек и поостынет.
И, кстати, о Scala. Во-первых, Scala еще свое место под солнцем завоевывать нужно. А то ведь был перед Scala интересный язык Nice, так же на JVM, но канул в лету. Во-вторых, для Scala создана и развивается библиотека Actors, которая пытается добавить в Scala механизм взаимодействия актеров через сообщения (под влиянием Erlang-а, даже синтаксис похожий). Но скорость отсылки сообщений гораздо ниже, чем в Erlang-е. И на RSDN как-то народ обсуждал, что особенности .NET и JVM не позволят создать на этих платформах настолько же удачные и надежные конкурентные языки, как Erlang (хотя подробности я уже позабыл). Собственно, это же самое относится и к .NET-овскому Nemerle, но у него еще меньше шансов, имхо (над Scala хоть люди full time работают и зарплату за это получают).
>Erlang, имхо, в лучшем случае повторит судьбу Lisp-а и Prolog-а: будут потрясающие по своей успешности проекты и проникновение в различные сферы. Но мейнстримом не станет и будет использоваться только своими приверженцами.
И на это как раз и надо молиться. Что бы не пришли пионеры и не наклепали CPAN. Потому что это - вещь специализированная. Для высоконадежных приложений на нагруженном продакшене. А не хоумпейдж школы. Пусть будем мало, но по делу. Высокая энтропия в таких вещах только мешает.
Не. Я на него в конце прошлого года решил поставить, как раз перед выходом 1.0. Вначале все шло хорошо, после 1.0 еще несколько очень полезных фич добавили, но не нарушая общего впечатления. Первые публичные версии Tango объявились...
А затем к разработке D активно подключился Александреску и понеслась! Была анонсирована разработка 2.0, не совместимая с 1.0. После чего часть народа активно начала писать на 2.0, часть осталась на 1.0.
Финальный релиз Tango 1.0 так и не вышел до сих пор...
В общем, я пришел к тому же выводу, что и некоторые другие мои знакомые, которые пробовали D раньше: если уж с 2001 года Брайт не смог понять, какой язык он хочет сделать, то почему нужно верить в то, что он знает это сейчас? ХЗ
Так что я лучше пока свои C++ные вещи буду до ума доводить, чем ждать прогресса в D.
> Была анонсирована разработка 2.0, не совместимая с 1.0.
А где можно почитать про несовместимость?
> Финальный релиз Tango 1.0 так и не вышел до сих пор...
Чем Phobos-то так плох?
> если уж с 2001 года Брайт не смог понять, какой язык он хочет сделать, то почему нужно верить в то, что он знает это сейчас?
Что значит "какой"? Причём здесь понимание Брайта? Это практический язык; он не для понимания, он для использования. Компилятор готов и работает. Язык в целом прилично задокументирован. Бери и пользуйся.
>> Финальный релиз Tango 1.0 так и не вышел до сих пор...
>Чем Phobos-то так плох?
Да просто сравните функциональность Phobos и Tango. Ну и просто Tango -- это объектно-ориенированная библиотека, в отличии от написанной в C-подобном стиле Phobos.
Кстати, наличие для одного еще очень молодого языка сразу двух несовместимых между собой библиотек -- это overkill. Есть, правда, какой-то tangobos, который реализует Phobos средствами Tango
>> если уж с 2001 года Брайт не смог понять, какой язык он хочет сделать, то почему нужно верить в то, что он знает это сейчас?
>Что значит "какой"? Причём здесь понимание Брайта?
Например, при том, что изначально Брайт создавал D без шаблонов -- это была его принципиальная позиция. И что? Шаблоны появились, что затянуло релиз 1.0 на несколько лет.
Потом Брайт не хотел иметь в языке const-модификатор. И что? В версии 2.0 появился не только const, но и invariant. Хотя это такие принципиальные вещи, которые должны быть в языке изначально.
> Это практический язык; он не для понимания, он для использования. Компилятор готов и работает. Язык в целом прилично задокументирован. Бери и пользуйся.
Практическим он станет тогда, когда для него появятся вещи типа ACE, SOCI, OTL, Crypto++ и пр. А пока его можно использовать только для некритичных экспериментов.
>> Отечественный лимонад "колокольчик" В НАРОД!!!
>Ты тоже его помнишь?!
Это только в Лужках Московских про него забыли, и запивают водку колой. В остальной России до сих пор для этого есть "колокольчик" :)
Вглядывался, ломал глаза и моск, так и не понял, в каком месте там ломается обратная совместимость.
С каких пор добавление фич в язык стало преступлением?!
> Да просто сравните функциональность Phobos и Tango. Ну и просто Tango -- это объектно-ориенированная библиотека, в отличии от написанной в C-подобном стиле Phobos.
И? Не вижу никаких проблем использовать фобос, если хочется стабильности. Он вполне функционален. Не вижу никаких проблем использовать тангу, если хочется стройности мысли. Для независимых и опенсорсных проектов постоянная бетовость - это вообще норма жизни. Пока не возьмёт под крыло какая-нибудь оборотистая компания и не наведёт энтерпрайзу.
> Хотя это такие принципиальные вещи, которые должны быть в языке изначально.
Says who? Не могу согласиться. Вещь является "принципиальной", если из-за неё, "по-хорошему-то", надо переделывать значительный кусок интерфейса стандартной библиотеки. Const на такое немножко не тянет.
> Практическим он станет тогда, когда для него появятся вещи типа ACE, SOCI, OTL, Crypto++ и пр.
Ой, я таких аббревиатур не знаю даже. И ничо, живой.
> Вглядывался, ломал глаза и моск, так и не понял, в каком месте там ломается обратная совместимость.
Надо полагать, вы так расписываетесь в незнании языка. Оно правильно, говорить о языке D гораздо проще, чем использовать его.
Попробуйте скомпилировать этот код компиляторами D 1.0 и D 2.0:
void doSomething( char[] name )
{
// Do something with name...
}
void main()
{
doSomething( "Hello, World!" );
}
> С каких пор добавление фич в язык стало преступлением?!
Добавление фич -- это, например, введение в язык текстовых mixin-ов и import-а для любых типов файлов. А вот появление const/invariant больше смахивает на очередной редизайн языка.
>> Да просто сравните функциональность Phobos и Tango. Ну и просто Tango -- это объектно-ориенированная библиотека, в отличии от написанной в C-подобном стиле Phobos.
>И? Не вижу никаких проблем использовать фобос, если хочется стабильности. Он вполне функционален.
Ну сравните тогда, к примеру, набор примитивов синхронизации, контейнеров, классов для ввода/вывода в Phobos и Tango. Особенно досаждает отсутствие в Phobos аналогов condition variables или хотя бы Java-вского метода Object.notify.
Да и GC в Tango реализовали более быстрый.
> Для независимых и опенсорсных проектов постоянная бетовость - это вообще норма жизни.
Вот на примерах OpenSSL, PostgreSQL, ACE, Boost-а и пр. не могу согласиться с подобной мыслью.
>> Хотя это такие принципиальные вещи, которые должны быть в языке изначально.
Says who? Не могу согласиться. Вещь является "принципиальной", если из-за неё, "по-хорошему-то", надо переделывать значительный кусок интерфейса стандартной библиотеки. Const на такое немножко не тянет.
Says who? Поломали бы еще моск хотя бы на предмет того, что const/invariant в D (в отличии от C/C++) транзитивны. И что из этого следует.
>> Практическим он станет тогда, когда для него появятся вещи типа ACE, SOCI, OTL, Crypto++ и пр.
>Ой, я таких аббревиатур не знаю даже.
Ну ничо, google вам в помощь.
> И ничо, живой.
А программировать что-нибудь серьезное пробовали? Хотя бы не на D?
Вы глупый человек, tailgunner. То, что языков всегда много - это правильно. Не будет этой экосистемы, не будет эволюции с миллионами мутаций - не будет и развития.
> Попробуйте скомпилировать этот код компиляторами D 1.0 и D 2.0:
Рассматриваю это как баг в 2.0, поскольку противоречит документации, где сказано: "If no storage class is specified, the parameter becomes a mutable copy of its argument."
> Ну ничо, google вам в помощь.
Нууу разве ж с первого взгляда осознаешь, где там ссуть... Оценить взглядом могу ACE - это какой-то уж совсем мега-комбайн, плохо предствляю куда его. SOCI не понравилсо - я ЭТО делаю НЕ ТАК. OTL и Crypto++ мимо - not my area.
> А программировать что-нибудь серьезное пробовали? Хотя бы не на D?
Да я в основном на скриптовых. Кресты вообще выучить несподобился - не приглянулис.
>> Попробуйте скомпилировать этот код компиляторами D 1.0 и D 2.0:
> Рассматриваю это как баг в 2.0, поскольку противоречит документации, где сказано: "If no storage class is specified, the parameter becomes a mutable copy of its argument."
Это не баг, это фича. Из-за добавления в D 2.0 const/invariant строковые литералы сейчас имеют тип invariant(char[N]), где N -- это размерность литерала. А invarint(char[]) не совместим с просто char[]. invariant неявно приводится только к const. Поэтому передача строковых литералов в качестве char[] (что активно используется в D 1.0) в 2.0 уже нелегитимно -- нужно менять прототипы вызываемых методов.
Но это только верхушка айсберга, просто самый яркий пример. В действительности, из-за const/invariant будет очень сложно использовать совместно старый 1.0-код и новый 2.0-код. Вариантов всего два: либо переписать старый код с использованием const/invariant, либо не использовать в новом коде const/invariant. Но второй вариант не имеет смысла -- тогда вся суть перехода на 2.0 теряется.
> Я не понимаю, почему мутации должны проявляться именно так.
А как ещё? Рождается мутант, проверяется жизнью, в настоящей экосистеме, и либо даёт потомство, либо дохнет навсегда. Для этого нужно, чтобы особей (в том числе и мутантных) в популяции было много. Очень много. Учите мат. часть.
> Язык Concurrent C++ разработан 20 лет назад.
И он не имеет ни малейшего отношения к параллельному программированию. Он тот самый мутант, который даже никакого потомства не дал.
> Рождается мутант, проверяется жизнью, в настоящей экосистеме, и либо даёт потомство, либо дохнет навсегда. Для этого нужно, чтобы особей (в том числе и мутантных) в популяции было много. Очень много. Учите мат. часть.
Как уже заметил анонимный брат (ты?) я глуп и по определению неспособен выучить матчасть. И понять, почему эволюция ЯП должна развиваться так же, как естественная эволюция биологических существ - тоже неспособен.
>> Язык Concurrent C++ разработан 20 лет назад.
> И он не имеет ни малейшего отношения к параллельному программированию.
А Джехани, лох, и не знал этого :D
Я отвечал на эту фразу: "не было еще ни одной попытки родить concurrent C++". Привел С++-производный язык, который прямо предназначался для concurrent programming - т.е. показал, что минимум одна попытка была сделана (этих попыток было много, на самом-то деле).
> Он тот самый мутант, который даже никакого потомства не дал.
Мне трудно судить: это был исследовательский проект, и на что он повлиял (или не повлиял) - я просто не знаю.
> И понять, почему эволюция ЯП должна развиваться так же, как естественная эволюция биологических существ - тоже неспособен.
А, ну тогда все ясно. Ты только учти - по тем же законам эволюции развивается любая прикладная отрасль. Исключений нет. Хорошо это или плохо - не нам решать, это объективные законы развития.
> А Джехани, лох, и не знал этого :D
Цель проекта была совсем иной. Это язык для SMP. Ничего общего с massive parallel computations.
> Привел С++-производный язык, который прямо предназначался для concurrent programming
В данном случае под "concurrent programming" понимается нечто совершенно иное.