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 ()

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

ZOMG. Пусть прочитают книгу по семейным отношениям. Оба.

anonymous ()

Все правильно, все по делу.

Xintrea ★★★★★ ()

Блин, написали бы лучше о новом языке R2D2,не объединяющем лучшие возможности R и D, но также удваивающем их.

DRVTiny ★★★★★ ()

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

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

Anonymous ★★★★★ ()

Дебилы на выпасе. Один помычал, остальные ржут.

anonymous ()

Не могу определить чего тут больше: выноса мозга или выноса парсера.

anonymous ()

По совам главного разработчика

кхм...

pathfinder ★★★ ()

И у тебя спина белая.

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

Если программист не может объяснить, что он хочет, компилятору, то это значит одно: программист слишком плохо знает язык, ему нельзя поручать написание реальных программ :)

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

Скажешь это, когда Ruby дорастет по производительности до уровня D :) Или хотя бы научится адекватному multithreading-у (JRuby не считается).

А пока Ruby остается красивым языком, который, однако, никак не катит в качестве замены компилируемых ЯП.

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

А как же автобилды? Ну и меня не радует перспектива делать за компилятора то, с чем он успешно справляется сам уже сейчас.

Deleted ()

Эти ваши оголтелые линуксоиды даже в первоапрельской теме умудряются о чём-то спорить :D

burjui ()

компилятор нередко не знает, чего от него хочет программист

Обратное, зачастую, тоже верно.

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

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

Боюсь представить, сколько веков потребуется, чтобы скомпилировать тот же Qt.

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

Язык - абстракция, в нем тормозов не бывает. Тормоза бывают зато в реализациях.

Deleted ()

яничегонепонел

Vudod

Плохой, не годный писатель

Satou ★★★★ ()

Поддержка «открытых» классов, к экземплярам которых можно добавлять новые поля и методы динамически во время работы программы. При этом будет реализован механизм памяти: каждый объект помнит свой исходных класс и знает все свои поля и методы, так что можно в реальном времени проверить, был ли добавлен нужный метод в данный объект или нет

Больше всего понравилось, тонко.

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

franchukroman

А как же автобилды? Ну и меня не радует перспектива делать за компилятора то, с чем он успешно справляется сам уже сейчас.

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

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

Боюсь представить, сколько веков потребуется, чтобы скомпилировать тот же Qt.

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

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

Больше всего понравилось, тонко.

Наибольший юмор в том, что ещё, по-моему, и относительно несложно реализуемо (по-питонски).

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

Какая именно информация была бы полезна компилятору?

Это точно не мои личные пожелания в плане того, инлайнить ли функцию, разворачивать ли цикл, раскрывать ли хвостовую рекурсию - со всем этим он и сам отлично справляется.

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

А если программист ответит хуже, чем это же могут сделать современные компиляторы? Нам страдать от его ССЗБизма?

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

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

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

один раз - каждую компиляцию? спрашивать про _каждую_ функцию и _каждый_ цикл? И ведь это только 2 оптимизации из кучи возможных.

loz ★★★★★ ()

По совам главного разработчика

sched ()

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

Толсто. А так хорошая шутка бы получилась.

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

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

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

Например библиотека может содержать несколько вариантов одной и той-же функции обработки списка и инструкцию для компилятора:

использовать вариант А если обрабатываемый список содержит менее 256 элементов более чем в 86% случаев;
использовать вариант Б если обрабатываемый список содержит более 256 элементов в более чем 66% случаев;
иначе - использовать вариант Ц (при вызове пересчитывает элементы и вызывает оптимальную функцию)

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

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

один раз - каждую компиляцию?

только когда видит новый участок кода или новую возможность оптимизировать уже «обсуждённый» участок


спрашивать про _каждую_ функцию и _каждый_ цикл?

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

Anonymous ★★★★★ ()

По-моему, про белую спину и то смешнее...

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

Не понимаю, вам понравился _юмор_ или что? Добавлениями пропертей можно уже сейчас развлекаться в .NET; Запоминать добавленное вроде бы незачем.

matumba ★★★★★ ()

Между прочим, я прочёл всю новость на полном серьёзе, т.к. у D всё же есть некоторые проблемы. Но проблемы скорее в библиотеках - отсутствии важных либ по UI и DBMS.

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

Между прочим, я прочёл всю новость на полном серьёзе, т.к. у D всё же есть некоторые проблемы. Но проблемы скорее в библиотеках - отсутствии важных либ по UI и DBMS.

Спасибо! Я писал её как на полном серьёзе, а потом вставил пару шуток.

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

Юмор в том что смысл D - это статический полиморфизм, выпилиывающий быдлядскую интроспекцию классов из статически и строго типизированоого языка.

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

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

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

Вот именно.

Например библиотека может содержать несколько вариантов одной и той-же функции обработки списка и инструкцию для компилятора:

использовать вариант А если обрабатываемый список содержит менее 256 элементов более чем в 86% случаев; использовать вариант Б если обрабатываемый список содержит более 256 элементов в более чем 66% случаев; иначе - использовать вариант Ц (при вызове пересчитывает элементы и вызывает оптимальную функцию)

Можно менее оторванный от реальности пример?

Зачем тут вероятности?

И зачем ради этого расширять синтаксис языка, если программист может закодить то же поведение несколькими if-ами?

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

Это было совершенно другое. Директивами можно было включать/выключать проверки, оптимизации, дебаг-инфу и т.д. Директивы имеют приоритет в сравнении с опциями ком. строки. Не прижилось из-за того, что смешивать систему сборки и язык - полнейший бред. Хотя, некоторые директивы в паскале-коде весьма популярны (например, директивы условной компиляции).

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

на полном серьёзе: D1 к концу года, 31.12.2012 обещают объявить deprecated, и выкинуть. Останется только D2. Под него уже портировано всё более-менее серьёзное: Tango https://github.com/SiegeLord/Tango-D2 книжка https://bitbucket.org/soarowl/tango-d2-references/src , xfBuild https://github.com/AndrejMitrovic/xfbuild

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

смысл D -это статический полиморфизм,

допустим

выпилиывающий быдлядскую интроспекцию классов из статически и строго типизированоого языка.

ненене. Без druntime эта интроспекция не работает. Другое дело, что эта интроспекция прекрасно работает во время компиляции, CTFE функциями. Что позволяет делать например такие вещи как парсер времени компиляции https://github.com/PhilippeSigaud/Pegged/wiki/

а если выпилить druntime, и gc впридачу — кина не будет.

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

хотя druntime можно обкоцать, как например в xomb OS.

anonymous ()

После того как узнал что у D ажно две «стандартные» библиотеки, понял что это мертворождённое поделие.

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

После того как узнал что у D ажно две «стандартные» библиотеки, понял что это мертворождённое поделие.

Вот у C их полтора десятка реализаций. Все они отличаются и большинство не соответствуют даже стандарту C99, не говоря уж о C11. Что ж, C --- мертворождённый язык?

Или 2 это мало?

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

если программист может закодить то же поведение несколькими if-ами?

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

И зачем ради этого расширять синтаксис языка,

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

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