LINUX.ORG.RU

Язык D включен в коллекцию компиляторов GNU (gcc 9)

 


3

7

GCC 9.1 будет первым стабильным релизом с поддержкой GDC.

Его выход ожидается приблизительно в конце первого квартала 2019 г.

Код для поддержки GDC включает библиотеку libphobos (D run-time library) и фреймворк для тестов D2.

Поддержка D потребовала внесения изменений в приблизительно 1 миллион строк кода.

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



Проверено: jollheef ()
Ответ на: комментарий от grem

Ещё у них на странице утверждение «невероятно быстрый».

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

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

Ещё у них на странице утверждение «невероятно быстрый».

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

Тут нужно уточнить, что это написано у Rust, а не у D. В сообществе D хайпа нет, это именно сообщество технарей.

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

То есть массовости написания проектов на rust нет и в ближайшем будущем не ожидается. Да и утверждать что у них популярнее, ничем не подтвердив, странно

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

Пример Clojure это оспаривает.

Не оспаривает. Вообще-то, Closure не Lisp, так как имеет свой оригинальный способ типообразования. Но это к спору не относится. Относится то, что Closure работает в виртуальной машине Java , поэтому имеет доступ к обширной библиотеке классов JDK, из кода на Closure легко вызывать код на Java и наоборот. Это преимущество по сравнению с любым замкнутым в себе вариантом Lisp, и придаёт на который смысл использованию Closure - часть Программы, которую неудобно писать на Closure, можно писать на Java. С другой стороны, для программирования на Closure желательно некоторое знание Java.

Аналогично, рассматривая D и Rust, я обращаю внимание на то, как код на них сочетается с кодом на C/C++ (чтобы использовать библиотеки и программы, которых в D и Rust нет).

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

Рич в презентации кложи обосновал свой тезис: пилить свой рантайм сейчас пагубная затея: много сил уйдёт на разработку лисапеда, а делать батарейки будет некогда (да и особо некому), cffi он тоже не рассматривает как выход из положения, разумнее обосноваться на мажорных платформах типа jvm и clr (и транспиляции в js конечно).

Closure не Lisp, так как имеет свой оригинальный способ типообразования

Чем этот способ оригинален? Что аж создаёт такое отличие.

желательно некоторое знание Java.

Да не особенно на самом деле. Но углубиться в jvm стоит очень даже.

C/C++

Кресты отдельный язык, никогда не понимал этой моды перечислять и через слеш.

как код на них сочетается

Сочетается, только заголовки задолбаешься портировать на D.

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

Ещё до него фирма Microsoft придумала COM - способ проектирования программы на основе компонентов, клторый вообще не предусматривал наследования. C++ тогда уже был, но не годится для этого

Не путай мелкое с мягким - C++ был, но стандартного ABI C++ на платформе Шindoшs не было (и только со смертью всяких Борландов и появлением VS2017 появилась надежда)

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

Ну, а D, написанный умниками непонятно для кого

Для кого как раз-таки понятно. Была компания Digital Mars, у них был компилятор C++, но сделать его быстрым и полностью соответствующим стандарту они не осилили, т.к. язык сложный. И они сделали свой язык с б/ш. Потом это увидел Александреску и начал реализовывать на нем свои самые изощренные фантазии

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

Lisp - язык функционального программирования

Примерно настолько же насколько Python. Тоже конкуренцию никому составить не может?

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

Т.е. Haskell тоже не успешен?

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

Ах, вот оно в чём дело. У Партизана слишком сильная путаница в терминах. Все языки на скобках у него называются «Lisp», C и C++ - это тоже одно и то же под названием «C/C++». Отсюда и все проблемы и споры.

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

Для кого как раз-таки понятно. Была компания Digital Mars, у них был компилятор C++, но сделать его быстрым и полностью соответствующим стандарту они не осилили, т.к. язык сложный. И они сделали свой язык с б/ш. Потом это увидел Александреску и начал реализовывать на нем свои самые изощренные фантазии

Ха, юноша, ну ты явно из этих молодых и прытких. Как их? Хипстеры, что ли? Смузи пьешь, да? Плюсовый компилятор от Digital Mars в свое время был впереди планеты всей. Не осилили, лол. Там и был то один автор. И люди, которые в курсе реальных событий отдают ему должное на реддите в комментариях, в отличие от тебя невежды, пытающегося тут слово замолвить. Его компилятор был первый плюсовый компилятор, который плюсы в машинный код сразу собирал. Все остальные плюсовые компиляторы на тот момент генерировали сишный код и уже его компилировали в машинный код. И компилятор у него был один из самых быстрых, если не самый. Так что выдыхай бобер, что ты там куришь.

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

С++ и Fasm.
Fasm

Кстати, а в чем киллерфичи перед TASM?
Борманы со своим режимом IDEAL тогда очень годный асм запилили, прямо даже Ц менее прост и прозрачен. Даже сахар для объектов был.

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

C и C++ - это тоже одно и то же

Неужели?

Ну читай сам:

рассматривая D и Rust, я обращаю внимание на то, как код на них сочетается с кодом на C/C++ (чтобы использовать библиотеки и программы, которых в D и Rust нет).

По мнению Партизана «сочетать D с C» и «сочетать D с C++» - одна и та же задача.

Lisp неперспективен, не является заменой для C/C++

По мнению Партизана, «замена C» и «замена C++» должна быть одним и тем же языком.

Или я что-то не так в его словах понимаю?

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

Авторы D и Rust предлагают их для замены С/С++.

Я осознаю, что говорю банальнщину, но приходится.

C и C++ - два разных языка, с разными областями применения. Да, синтаксис примерно похож, но не более того.

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

Это тот же самый код, который бы нужно было поддерживать и в компиляторе. Все ровно то же самое. Только ты можешь эту тулзу запустить когда тебе нужно. Когда у тебя есть время на это. И в этой тулзе можно сделать такие проверки, которые в компилятор включать не будешь.

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

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

Итого: относительно медленную тулзу мы запускаем постоянно; относительно быстрый компилятор мы гоняем не просто так, а с пачкой юнит-тестов. В чем профит упрощённого синтаксиса, допускающего нелепые ошибки человека и быстрого компилятора, эти ошибки пропускающего?

…Поэтому все в синтаксис ты не затащишь и нужен определенный компромисс.

Знаете, Ваш пример про

сделать_все_зашибись()
носит демагогический характер.

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

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

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

Авторы D и Rust предлагают их для замены С/С++

Авторы D и Rust напоминают Моську, которая лает на слона :)
bonta

Это правда :) Но аффтары Nim напоминают той Моськи какашку, которая лает на Моську :-D

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

Ну да, я собственно про Ним пошутил

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

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

Осилил в конце концов Common Lisp
«Писал на нём все наколенные поделки»

поздравляю. вообще-то, Лисп всегда позиционировался как язык, программы на котором должны писать *программы*, а не люди.

Быстрота и лёгкость разработки лучше чем у D, а достаточная оптимальность от задачи к >задаче меняется.

это неверно. достаточно просто посмотреть, насколько быстро исправляются ошибки и недочёты в лисп (и аналогах) программах, а «их есть» в некотором количестве. ведь иногда годами баги висят. писать легко. понять написанное и поддержать — сложно.

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

Я попросил вас указать преимущества D перед Rust. А вы начали отнекиваться.

бессмысленный вопрос. Раст и Ди --- языки с очевидно разными базовыми целями, что бы там не говорила хайпующая публика. Раст --- попытка получить максимально безопасный код, задав максимально строгие правила на этапе рпоектирования. Ну, хорошо. Для драйверов и крайне ответственного кода (хотя, чем хуже Ада?) — отлично, ждём, пока взлетит.

Писать на Расте *всё* --- не кажется хорошей идеей. Зубодробительный синтаксис в хакерском стиле --- прикольно, но имхо, очень быстро станет слишком дорого (трудоёмкость!).

Ди --- максимально необременительная (простая) разработка при сохранении *достаточной* надёжности кода и возможно полном сохранении преимуществ нативного, компилируемого кода. Для достижения этой цели пришлось отказаться от напластований C++ и в большой степени, совместимости с С++.

Так понятно?

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

Lisp неперспективен,

гм

не является заменой для C/C++

ну да

и вообще не нужен.

ядра каких систем компьютерной алгебры написаны на чём-то другом, чем липсоиды? просто интересно.

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

вообще-то, Лисп всегда позиционировался как язык, программы на котором должны писать *программы*, а не люди.

[citation needed]

Серьёзно, с чего ты это взял? Дай хоть ссылку на источник такого странного мнения.

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

Нет, не тащит в рантайм абсолютно ничего.

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

Рефлексии времени выполнения в D очень мало.

но есть и её надо поддерживать

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

С плюсами сравнительно плохо. Прямой совместимости (в стандартных компиляторах, на >>сегодня) нет. Возможны биндинги. Появился ещё один подход, основанный на >>препроцессоре.

Прямая совместимость как раз есть, но она хуже в сравнении с Си.

Хм. как быть с вызовом деструкторов?

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

Фанат Haskell-а мог бы спросить, на чём написано ядро системы расстановки ферзей.

Но специально для вас заглянул в Google - на чём написана GNU Octave. Оказалось, на C++.

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

Ди ровно настолько же высокооптимальный.

в теории, да.

но ведь для получения полноценной, не урезанной, Ди — программы, требуется (по крайней мере, сейчас) существенно больше влинкованного (в т.ч. библиотечного) кода. Да ещё пока ещё вызывающий известные нарекания сборщик мусора...

Это существенное граничное условие.

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

Может я тебя неправильно понял?

Из этого утверждения

Лисп всегда позиционировался как язык, программы на котором должны писать *программы*, а не люди.

можно сделать вывод, что люди не должны писать программы на лиспе.

любая книга по лиспу времён хайпа ИИ

То есть, в любой книге по лиспу времён хайпа ИИ написано, что люди не должны вручную писать программы на лиспе? А на чём же тогда там предлагают писать программы, которые будут писать программы на лиспе?

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

alias this

Костыль. На сколько я понимаю изначально придуманный для структур, когда ВНЕЗАПНО > оказалось, что людям нужно наследование в структурах.

возможно. но не только. слишком уж волшебная мантра.

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

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

Лисп всегда позиционировался как язык, программы на котором должны писать
*программы*, а не люди.

можно сделать вывод, что люди не должны писать программы на лиспе.

неправильно понял.

Люди должны написать лисп — программу, которая будет писать саму себя (на Лиспе, конечно).

Метод барона Мюнхгаузена (бутстрапинг).

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

Хайп ИМ происходит сейчас .

всегда происходит какой-нибудь хайп.

Пишут на обычных языках. Больше всего на Python, а для скорости используются >вычисления в GPU, преимущественно CUDA.

А это не ИИ. Это бум подгоночных моделей, правильность работы которых принципиально недоказуема (впрочем, я дилетант, зуб давать не буду :)

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

Забавно, что MATHLAB is a computer algebra system
Если же имелся в виду MATLAB, то он (как и octave, соответственно) ни разу не «системы > компьютерной алгебры».

Забавно, да.

Matlab == Matrix Laboratory.

в русской традиции CAS — прежде всего, символьные вычисления.

поправьте, коли не прав, люды добры-яяя

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

Я был уверен, что D-шный рантайм тащит с собой только аналог C++ного RTTI. И в этом

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

плане расходы в run-time будут сравнимы.

наверное. но этого кода тупо МНОГО. а это не всегда хорошо...

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

неправильно понял.

Ok. Тогда поясни, ты Gentooshnik'а одобряешь или осуждаешь, за то, что он «осилил в конце концов Common Lisp» чтобы писать на нём «наколенные поделки» (вместо D, насколько я понимаю).

Люди должны написать лисп — программу, которая будет писать саму себя (на Лиспе, конечно).

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

anonymous ()