LINUX.ORG.RU

Планы разработки языка D3

 


0

2

На днях в блогах разработчиков языка программирования D и его референсного компилятора dmd появилось сообщение о том, что ветка D2 вскоре будет заморожена и дальнейшие изменения вноситься не будут кроме исправляющих существенные и часто повторяющиеся ошибки. По совам главного разработчика D Уолтера Брайта это связано с тем, что D2 стал слишком стабилен и вносить в него новые свойства оказывается опасно. Другой разработчик --- известный программист Андрей Александреску выразил озабоченность тем фактом, что качество реализации D2 в dmd достигло такого уровня, когда он может быть использован для реализации конкретных прикладных проектов. По словам обоих авторов описанные выше проблемы являются непреодолимым препятствием для реализации в D2 новых, более современных концепций и передовых идей.

В связи с этим команда авторов D2 и компилятора dmd рассматривает варианты перехода на 3-ю ветку для внесения существенных изменений в структуру проекта. Основные проблемы D2 с точки зрения его дизайна по словам разработчиков следующие.

  • Слишком большая неопределённость и обилие типов. В частности, 3 типа юникода: char, wchar и dchar, 8 целочисленных типов данных, 3 с плавающею запятой. В качестве примера приводится язык Python, где в версии 3 оставлен всего 1 целочисленный, 1 действительнозначный и 1 юникодовый типы. Уменьшение числа типов способствует лучшей читаемости и поддержке кода и в то же время избавляет от ряда ошибок при переносе на другие архитектуры.
  • Недостаточная реализация концепции метапрограммирования. Проблема заключается в том, что компилятор нередко не знает, чего от него хочет программист, а тот не может объяснить это компилятору.
  • Поддержка целочисленных вычислений с большими числами. DВ настоящее время в D2 поддерживаются максимум 64 битные целые числа, что в будущем неизбежно приведёт к проблемам. Следует реализовать механизм поддержки целых чисел произвольного размера по аналогии с существующим типом real. При этом размер типа будет определяться на этапе компиляции, а не динамически, как в Python.
  • Поддержка «открытых» классов, к экземплярам которых можно добавлять новые поля и методы динамически во время работы программы. При этом будет реализован механизм памяти: каждый объект помнит свой исходных класс и знает все свои поля и методы, так что можно в реальном времени проверить, был ли добавлен нужный метод в данный объект или нет.

Вопрос об отделении ветки D3 будет рассматриваться после выпуска корректирующего обновления dmd 2.059 и 1.074.

>>> Подробности

★★★★★

Проверено: maxcom ()

Ответ на: комментарий от Deleted

/* Офтопик (всё равно тема первоапрельская :) */

А у тебя джабер в профиле только для красоты прописан? :) Ты его когда-нибудь вообще пускаешь? :)

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

Авторизовал. На последней неделе не пускал жаббер вынужденно.

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

программист может и на ассемблере всё оптимально написать - для типичного десктопа с 5 ядрами двух архитектур(CPU/GPU), ага. Но почему-то он этого не делает.

Сравнение некорректно. Программист не пишет на ассемблере потому, что это неудобно и нерационально. А какие преимущества твой подход имеет перед ифами?

Deleted
()

3 типа юникода: char, wchar и dchar, 8 целочисленных типов данных, 3 с плавающею запятой.

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

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

и вас тоже с праздником ;)

Так это шутка? Тьфу блин, а я так внимательно читал. Захожу на лор за новыми тех. новостями, т.к. это серьезный технический ресурс, а тут школьно-семейные шутки.. ппц, совсем упоролись, уж лучше опеннет.

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

Батенька, одно дело реализации некоего стандарта, другое когда два разных стандарта.

Tango не является стандартом, только Phobos. Tango --- это альтернативная реализация.

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

GUI под windows: ... *много-много трёхбуквенных слов*...

Я в курсе, что такие слова есть. :) Но эти либы РАБОЧИЕ? Используются 5 лет в продакшене? На их основе легко делать другие контролы?

Дело в том, что на уровне «форма-кнопка» ВСЕ тулкиты - одинаковы. Чёрт прячется в деталях, когда, например, нельзя в рантайме фрэйм с контролами вставить в отдельное окно или другой контрол. (это одна из фишек, крайне мне необходимых)
Я пробовал около десятка этих гуёв, все отмелись по нескольким причинам:
1. Архитектура - бред сивой кобылы (напр., контролы в виде HTML)
2. Проект завис на уровне кнопка-скроллбар-чекбокс и не обновлялся несколько лет.
3. Проект даже не смог скомпилироваться.
4. Элементы имеют уё**ный вид.

К пункту 3 относится упоминаемый gtkD - исходники настолько протухли, что авторы даже не заметили переход сообщества D на неизменяемые строки string.

Вообще, мне не очень нравятся даже технически «обёртки» над чужими либами - есть риск нарваться на какие-нибудь выравнивания структур, «не такая» передача параметров/строк/вещественных, ограничения на использования D как такового - например, там, где можно было воспользоваться родными mixin'ами, ты вынужден юзать «завёрнутые» контролы.
Другими словами, библиотека должна быть написана на D, используя всю его мощь. Иначе получится как с дотнетом - сначала ввели ублюдственные коллекции/массивы, на них базировали кучу классов, а потом, протрезвев, вдруг ввели дженерики и все сразу поняли, какой отстой был раньше, А МЕНЯТЬ УЖЕ НИЧЕГО НЕЛЬЗЯ. Исторически сложившееся гуано - его надо всячески избегать.
Я не ищу причин не писать, мне Ди как раз нравится больше всего, но для полного перехода в него нужны надёжные библиотеки - без них ни один коммерческий проект даже не взглянет на этот аутентичный самородок.

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

А про дотнет это троллинг или правда нраица ?

:) Спасибо, смешно (хоть 1-ое уже и прошло). Вообще-то .НЕТ - это то, что меня кормит последние 6 лет. Если у вас не (хаскель/лисп) головного мозга, выразительных возможностей .НЕТ вполне хватает для всех мыслимых задач. На сегодня это лучшее из всего, что может предложить мир программазма (включая VS).

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

Вот сразу же и подтверждение: «SDWF is currently at an alpha stage of development.» Т.е. речь о серьёзном применении не идёт вообще, тут даже DFL выглядит куда солиднее. Грустно пока в стане Ди...

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

а сегодня это лучшее из всего, что может предложить мир программазма (включая VS).

Писал на Питоне и буду писать. И не понимаю, чем для меня .NET лучше?

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

Пооооооосллеееееееее пооооооввсеемееееееееестнооооогооооо вввнееееедреееееееениииииияяя PyPy разницы не будет. А так пока есть.

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

Писал на Питоне и буду писать.

:) Разве кто-то вас тянет за причинный орган писать на C#? Если в нише ваших приложений Пестон - лучшее, что можно использовать - используйте! Я пишу приложения для виндо-десктопа и сервера, задачи весьма разнообразные, поэтому наличие библиотек «для всех случаев жизни» - критично. Выбрали .NET и, судя по прогрессу, не ошиблись.
Если вы серьёзно собираетесь зарабатывать на жизнь программированием, я бы рекомендовал именно .NET;

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

узнал что у D ажно две «стандартные» библиотеки

А чего в этом особенного? вон у С в каждом конпеляторе своя «стандартная» C runtime library, а в С++ ещё одна. Да, есть POSIX которому мало что соответствует (добавь сюда ещё одну с нативным интерфейсом ядра), у С++ есть libstd++ и недавно libcxx.

В D1 был Phobos за авторством Волтера Брайта, и Tango от сообщества. В D2 — Phobos от Брайта и Александреску, разделение Phobos на druntime и сам Phobos, выкладывание их на гитхаб и реагирование на pull-реквесты. А недавно в D2 ещё и Tango портировали.
За последний год всё более-менее интересное успели переписать на D2 и Phobos, так что Tango под D2 не очень-то нужен, ну и к концу года когда D1 объявят deprecated, от второй библиотеки можно будет окончательно избавиться.

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

макросы, где тело макроса (string mixin) подставляется в код во время компиляции (CTFE, compile-time function execution). Чтобы разворачиваемый код был полезен, нужны такие штуки, как typeof, type tuple, std.algorithm, std.ranges. Это вполне работает во время компиляции — см. std.regex, парсер GOLDIE, парсер Pegged. Пару лет назад один человек даже scheme4d написал, на макросах времени компиляции.

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

я предлагаю вариант как сделать, чтоб и в синтаксис ничего не вводить, и программист лишнего не писал - но чтоб при этом компилятор всю необходимую ему информацию мог получить.

особая CTFE магия помогает: см. слайды «ModernCOMProgramminginD». Правда исходники он не выложил — типа там куски кода от WinRT и вообще некрасиво.

http://forum.dlang.org/thread/jfmohh$1i81$1@digitalmars.com#post-jfmohh:241i81:241:40digitalmars.com

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

Tango --- это альтернативная реализация.

...в которой есть свой более полезный API с блекджеком, которого нет в Phobos

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

Алсо, хелловорд на танго выдаёт более компактный бинарник чем хелловорд на фобос (120k против 200k, что всё равно слишком много по сравнению с сисколлом write :)) — тут уже нужно выкидывать gc, заменять на gcstub и отказываться от большого куска druntime)

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

На их основе легко делать другие контролы?

меня терзают смутные сомнения, что контролы вообще надо писать на WinAPI. А GUI либа должна быть простой обёрткой. Правда да, кроссплатформенность идёт
побоку.

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

таких либ мало, особенно кроссплатформенных (но они есть).

Из более-менее зрелых либ — DWT где переписали (часть вручную, часть трансляцией кода) SWT из Java на D, и QtD где прикрутили QtJambi для генерации кода врапперов на D (аналогично тому, как делались врапперы на Jambi для Java) — в итоге код либ врапперов столько же или больше, чем сами либы Qt.

Мне кажется, нужно двигаться в другом направлении, например, в сторону интероперабельности с С++ (и написании гуя на Qt/C++). Например, реализовав для D штуку, аналогичную CXXI в моно: http://tirania.org/blog/archive/2011/Dec-19.html

В D такую штуку можно было бы написать в CTFE, используя naked asm функции. К тому же, может быть с LLVM вместо GCC получилось бы проще.

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

+10500
и пакетный менеджер для либ — наподобие go install (хотя в чём-то dvm/orbit уже сейчас годен).

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

тут даже DFL выглядит куда солиднее.

кстати, у китайцев видел порт DFL на D2. И gtk враппер там в каком-то виде есть, хз, насколько позаброшенный

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

Если вы серьёзно собираетесь зарабатывать на жизнь программированием, я бы рекомендовал именно .NET;

ну шароварщикам дотнет не шибко подходит — тащить с собой в инсталляторе рантайм, который больше всей программы...

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

вон у С в каждом конпеляторе своя «стандартная» C runtime library

Да ну?
И что есть компиляторы с нереализованными функциями прописанными в стандарте?
С учётом того что сама библиотека бедна как церковная мышь.
А ссылочку можно?

То что каждый компилятор тянет с собой кучу своих велосипедов, как расширений к стандарту это его личное дело.

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

Tango --- это альтернативная реализация.

Если смотреть на пример из педивикии, то видно, что это скорее не реализация, а ещё альтернативный велосипед.
-----------------------------
version(Tango)
Stdout.formatln(«args[{}] = {}», i, a);
else
writefln(«args[%d] = '%s'», i, a);
-----------------------------

А альтернативная реализация это ulibc и glibc.
Т.к. и там и там объявление функции printf подключается через stdio.h

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

Лиж бы язык похаять. В тех же плюсах ситуация не лучше: почти каждая библиотека норовит что-то по-своему реализовать, и ничего - терпите теже велосипеды.

Phobos is the standard runtime library that comes with the D language compiler.

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

Лиж бы язык похаять.

Не «лиш бы», а бесит когда разработчики очередного языка устраивают забег по уже не раз пройденным другими граблям.
«Мы радостно воздвигаем препятствия, а потом героически их преодолеваем»

И да, я нигде не говорил что в C/C++ ситуация лучше.
Но им простительно, т.к. С вообще старше меня, а C++ появился когда я ещё о компьютерах не задумывался.

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

Но им простительно, т.к. С вообще старше меня, а C++ появился когда я ещё о компьютерах не задумывался.

Вы не поверите, но D1 в этом году 13 лет. Это много и не удивительно, что за это время успели нагородить костылей, а потом при переходе на D2 от них избавиться.

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

Алсо, хелловорд на танго выдаёт более компактный бинарник чем хелловорд на фобос (120k против 200k, что всё равно слишком много по сравнению с сисколлом write :)) — тут уже нужно выкидывать gc, заменять на gcstub и отказываться от большого куска druntime)

Давно не писал хэлловордов. Вот если вы мне предъявите пример того, что Tango больше годится, например, для реализации процесса Грамма-Шмидта или метода Левенберга-Марквардта, я стану её сторонником.

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

Ну, как таковая стандартная либа одна - фобос. Танго же была создана сообществом, она будет побогаче возможностями, но использовать их вместе это тот ещё экшн. В настоящее время фобос довольно активно пилится и пополняется. Лично мне больше нравится именно реализация фобоса, нежели танго.

Касательно самого языка, лично мне он кажется яснее, прозрачнее и даже проще в использовании, нежели с++: здесь действительно можно просто и гибко программировать с использованием шаблонов; очень многое считается на этапе компиляции, компилятор весьма умён и сам сообразит, что можно посчитать, а что нет, что не может не радовать; контрактное программирование; mixin; static if; scope; и многое другое.

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

Помимо книги Александреску, есть ещё книжка, но по шаблонам. урла

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

А Яве ещё больше, но вот только почему-то для Явы повторно велосипед не изобретали.
Видать потому, что изначально продуманно подошли к планированию стандартной библиотеки.

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

но местами он просто дико избыточен и перегружен

Если уж говорить на чистоту, «С++ это красивая и стройная система костылей и подпорок»

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

Кстати.
Хоть и считается 13-ть, однако стабильная версия 1.0 появилась только в 2007-м
Прикинь, да? 8 лет разработки и всё-равно продукт оказался сырой.
А версии 3, если верить слухам, то вообще порежут количество базовых типов и что-нибудь ещё, что в очередной раз сломает совместимость, повторяя путь 3-го питона.

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

А Яве ещё больше, но вот только почему-то для Явы повторно велосипед не изобретали. Видать потому, что изначально продуманно подошли к планированию стандартной библиотеки.

Поэтому в Яве до сих пор полно проблем и они никак не решаются или решаются задействованием сторонних реп вместо своих. А ещё у Явы есть несколько альтернативных несовместимых реализаций. Я ещё есть .NET, который сделали на основе микрософтовой явы, но криво и потом переделывали.

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

Поэтому в Яве до сих пор полно проблем и они никак не решаются или решаются задействованием сторонних реп вместо своих.

Шозабред.
А по русски?
Каких там проблем полно?

А ещё у Явы есть несколько альтернативных несовместимых реализаций.

Пруф или 4.2.
Те что прошли сановские тесты те совместимы, так что не надо ляля.
Не, если конечно отдельные ССЗБ используют классы типа COM.sun.* то кто кроме них виноват? И о какой несовместимости может идти речь?

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

Пруф или 4.2. Те что прошли сановские тесты те совместимы, так что не надо ляля. Не, если конечно отдельные ССЗБ используют классы типа COM.sun.* то кто кроме них виноват? И о какой несовместимости может идти речь?

Dalvik.

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

Читаем внимательно на что отвечаем.
«Те что прошли сановские тесты»
Так что Dalvik мимо кассы, совсем мимо, бо не имеет права называться jvm.

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

какая 3 версия D, вы о чём?

Бггг, такая, которая в планах.
Тема как называется? «Планы разработки языка D3».

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

Да, чего-то я на число не посмотрел.
Ну если это и вправду шутка, то очень правдоподобная.

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

«Те что прошли сановские тесты» Так что Dalvik мимо кассы, совсем мимо, бо не имеет права называться jvm.

Вот не надо выворачиваться. Dalvik --- это жабамашина, несовместимая с саноскою, поскольку не прошла тесты, т.е. альтернативная несовместимая реализация. Это полностью подтверждает мой тезис, вы же противоречите сами себе. И да, под Dalvik пишут на языке Ява и мы о языке говорим, если что. Потому что runtime,включая сборщик мусора у D1Phobos и D1Tango общий, а разный только набор библиотек.

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

В каком месте Dalvik - это вообще жабомашина?

Жабомашиной, которая не прошла тесты, можно называть всякие Apache Harmony и т.п., а вот Dalvik даже архитектурно с JVM не имеет ничего общего.

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