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

У всего есть своя цена, в отличии от Go'шного его реализация потребляет меньше системных ресурсов.

У Касперского и хаскел используется. Кто из них популярнееа том числе с их проекте?

раст, это очевидно, там не дураки

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

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

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

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

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

Вы, конечно, правы. Каждый из нас в чём-то прав.

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

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

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

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

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

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

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

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

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

C/C++

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

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

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

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

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

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

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

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

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

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

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

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

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

А на Расте все из каропки работает что ли?

С++ и Fasm.

ICC, CMake, CLion.

Остальное нинужно!!!

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

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

На русте на пробовал. Может попробую как-нибудь.

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

Неужели?

С++ и Fasm.
Fasm

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

Главное что он не зашкварен мерзким at&t синтаксисом.

Скорость компилятора обратно пропорциональна качеству сгенерированного машинного кода.

Главное что он не зашкварен мерзким at&t синтаксисом.

Это-то да.

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

Неужели?

Ну читай сам:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

сделать_все_зашибись()

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

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

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

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

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

Скорость компилятора прямо пропорциональна качеству дизайна языка.

Ну да, я собственно про Ним пошутил, т.к. слышал от авторов и сообщества любителей Ним такое утверждение нескромное :)

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

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

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

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

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

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

Вообще-то, у авторов популярных языков программирования были и другие цели, кроме разгона ветхого компьютера.

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

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

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

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

Так понятно?

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

гм

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

ну да

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

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

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

[citation needed]

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

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

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

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

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

Серьёзно,

абсолютно

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

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

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

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

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

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

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

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

в теории, да.

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

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

GNU Octave. Оказалось, на C++.

Октава — не есть система компьютерной алгебры (символьные вычисления --- не её конёк).

Ещё посмотрел в Google, на чём написана коммерческая программа Mathlab. Оказалось, на C, C++, Java. На этом моё усердие в поисках ответа на ваш вопрос кончилось.

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

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

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

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

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

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

alias this

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

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

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

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

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

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

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

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

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

Mathlab

Забавно, что MATHLAB is a computer algebra system created in 1964 by Carl Engelman at MITRE and written in Lisp.

Если же имелся в виду MATLAB, то он (как и octave, соответственно) ни разу не «системы компьютерной алгебры».

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

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

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

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

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

Забавно, да.

Matlab == Matrix Laboratory.

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

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

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

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

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

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

А разве у D run-time рефлексия, а не compile-time рефлексия?

ну таки трошки-же есть?

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

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

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

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