Опубликован релиз DMD 2.111, эталонного компилятора для языка D. Код компилятора распространяется под свободной лицензией BSL (Boost Software License). Поддерживаются системы Linux, Windows, macOS и FreeBSD...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63029
А где С--?
С-- уже давно существует
Мана-мана.
Дык, и я об этом.
Сдох 20 лет назад.
Ну, т.е. за всё время так ничего реально используемого и не написали. И не "переписали".
> Новое ключевое слово "__rvalue", позволяющее реализовать move-семантику
> Добавлено placement-выражение "new" для инициализации указанным значением (без GC)Решили изобрести С++ заново?
Точнее увидев как плох C++ решили сделать заново хороший ООП язык с си подобным синтаксисом. Кого ужасает C++ переходите на D.
Когда-то заинтересовался D, но тогда у D не было своей GUI библиотеки и похоже нет и поныне так что осталось на уровне интереса.
В 2015 году уже были упоминания про gtkd и как писать там гуй. Или вы про другое?
Это было еще ранее в 2012-13 годах
Ну у go и раста тоже с гуём всё плохо - либо биндинги к gtk/qt, либо "на-те-канвас в нём и рисуй", но тем не менее...
У Go есть нативный Fyne, а у Rust есть Slint
Я не видел библиотек именно на самом D, тем более под Linux, а не Windows
Использовать биндинги... Ну, проще уж писать на C++ или C в таком случае.
Кажется, автор HTMLayout что-то писал на D в нулевых. Сейчас сходу не нашёл, только биндинги к HTMLayout, так что могу и ошибаться. Но если писал, то показательно, к сожалению для языка.
Вот тут он на кывте отписывался: https://rsdn.org/forum/philosophy/1152810.all
Было 20 лет назад
Благодарю! Да, там и читал. Harmonia GUI framework for D. Теперь вспомнил.
у раста есть только биндинги к qt от kdab. не бывает никаких slint, это всё для маленьких детей
egui, iced, tauri, slint, dioxus desktop и другие, названия которых уже забыл. И всё перечисленное - это не биндинги к QT.
Qt, не QT. Пиши правильно.
Dlangui из нативного.
Были еще несколько нативных библиотек, но они до релизных версий как-то не дошли (вроде dtk от Animous)
С каких это пор биндинги стали чем-то плохим?! Тушеночная невеста нас всех разоблачила.
Я думаю проблема в реализации биндинга и его поддержки.
> Использовать биндинги... Ну, проще уж писать на C++ или C в таком случае.В огороде бузина, а у лентяев какая-то ахинея в голове. Как байндинги соотносятся с С++!?!?
У людей есть Ди. Нужен гуй - там полно либ, включая нативные на Ди. Всё остальное - отмазки.
Уж на Go этого добра просто завались. И нативного и уникального, и Tk, и gtk, и qt и Win32 GUI API. И мультиплатформенного и не мультиплатформенного.
> Уж на Go этого добра просто завались. И нативного и уникального, и
> Tk, и gtk, и qt и Win32 GUI API. И мультиплатформенного
> и не мультиплатформенного.Да на Ди тоже самое
> Когда-то заинтересовалсяИнтересно, с тех пор хотя бы одну GUI утилиту на другом языке написали? А то бывает такое, что вроде бы и нужны либы, а по факту нет. Просто страх такой иррациональный.
Вот тебе "утилита" - целая IDE на ГУЙ-библиотеке, тоже написанной на Ди.
https://github.com/buggins/dlangide
Гуйня была у Ди всегда, но увы - большинство было только "обёрткой" над чужими поделиями. Но я в жизни не поверю, что тебя остановило только это. Напиши ХОТЬ ЧТО-ТО на Ди и покажи, где ты упёрся в ГУЯх в невозможность дальше двигаться.
Похоже, мастер метапрограммирования Александреску сбежал от экспертов, полагающих Си++ ООП языком.
Далеко убежал?
В поисковик беги. Там найдёшь и С--, и кто такой Александреску.
ну и где он теперь со свими положениями? помню, его выкупил фейсбук и он исчез навсегдавроде бы было от него ещё полтора клона бустовых либ на плюсах
Он в нвидиа сейчас
Продолжает выступать на конфах вроде тоже
Вот после него фейсбук и стал Мета наверно.
Дело было так:
- Андре-ей, у нас тут метапрогра-а-аммы!
- Уже бегу
Напиши компилятор с ООП-языка на ООП-языке. Или просто конечный автомат.
Я написал транслятор Рефал как просто КА, так какой-то эксперт бегал тут неделю с криками "goto это плохо!"А эксперимент с ООП-языком что нам даст?
В ООП парадигме нет не только goto, но там нет и стека -- все переменные только в куче или в статической памяти.
Вопрос был, что нам даст написание мной компилятора. Так сказать, обоснование для просьбы.
На что переходить, если ужасает ООП?
> На что переходить, если ужасает ООП?На ФП тогда наверное - F# или Ocaml
Ocaml - ObjectiveCaml
Объекты там примерно как в Плюсах - где-то немножко сбоку.
Но уважающий себя плюсплюсник без объектов не обходится.
> Но уважающий себя плюсплюсник без объектов не обходится.Уважающий себя "плюсплюсник" не будет хамить Степанову и Ли.
Смоллток. Он как бы ООП, но с _правильным_ ООП!
> На что переходить, если ужасает ООП?Для начала, ознакомиться с возможными вариантами. Более-менее систематизировано https://intuit.ru/studies/professional_retraining/941/course...
Внимание!
Не воспринимайте то, что дано ниже, как шаблоны! За шаблонами идите по другим адресам.
Если у Вас появляется много структурных или (не дай Бог) неструктурных переходов либо все время приходится присваивать значения признакам, а затем их проверять, посмотрите, нельзя ли выделить модуль в автоматном стиле.
Если Вы начинаете думать о задаче как о вычислении (не обязательно над числами), пользуйтесь структурным программированием.
Если Вы намерены переложить понравившуюся Вам нечисленную (например, алгебраическую, топологическую или логическую) теорему в алгоритм для решения Вашей задачи, подумайте о функциональном стиле.
Если у Вас каждое следующее значение требует немногих данных, но различные значения обращаются к одним и тем же, даже не пытайтесь программировать рекурсивно, рекурсивное описание можете сохранить в качестве документации к программе, а саму программу пишите в терминах циклов и массивов.
Если данные строго подразделяются на ветви, используемые разными последующими значениями, часто лучше писать рекурсивно.
Если Вы начинаете смотреть на данные как на активные единицы, которые взаимодействуют между собой, воспользуйтесь объектно-ориентированным программированием.
Если в предыдущем случае объекты в том виде, как они предоставляются современными системами программирования, не подошли, воспользуйтесь каким-либо пакетом7 для организации квазипараллельной работы в условном времени и программируйте от событий.
Если Вам нужно преобразовывать сложные структурированные тексты в другие тексты, не поленитесь воспользоваться Рефалом (или новым языком сентенциального конкретизационного программирования, если он уже появится к тому времени, когда Вы будете это читать).
В частности, если исходные данные или конечный результат имеет формат символьного файла, совершенно неудобоваримого для стандартных процедур ввода/вывода используемой Вами основной системы программирования, пишите препроцессоры или постпроцессоры на Рефале (либо, в крайнем случае, на Perl).
Если Вы путаетесь в многочисленных условиях, когда удача либо неудача порою проявляется после нескольких попыток и неясно, куда нужно вернуться, посмотрите, нельзя ли проверку условий запрограммировать на языке Prolog8 (или на новом языке сентенциального унификационного программирования, если он уже появится к тому времени, когда Вы будете это читать).
Не смог ты удержаться Рефал порекламировать. И даже возможно есть за что, но к сожалению, он не подходит для решения реальных задач реального мира. Палиндромами дело в реальности не ограничивается. В реальности нужно не только вычислять, но ещё и дёргать внешние сервисы через интернет. Как на Рефале прочитать файл с AWS S3 или совместимого хранилища?
Там 10 (ДЕСЯТЬ) если. Если кто-то их не заметил, он никак не сможет "прочитать файл с AWS S3 или совместимого хранилища". Скорее всего, ужасают его не первые две буквы из "ООП".
Не надо так болезненно реагировать на очевидные и неоспоримые недостатки Рефала, а именно абсолютную неприменимость для решения задач реального мира. Я вот всякие эзотерические реализации лиспов люблю, но советовать кому-то в интернете ими пользоваться точно не стал бы. Как и не стал бы делать скоропостижных выводов о том кого какие буквы пугают. Мир чуть разнообразнее, чем десять если.
Если реагировать не надо, значит не реагируй. Там достаточно других вариантов, зачем цепляться к непонятному?
Затем же, зачем ты про него пишешь при любом удобном случае. Другие варианты не вызывают удивления. Рефал — не непонятный, а бесполезный для решения реальных задач, не надо путать! — вызывает.
Попробую ещё раз. Если ты не знал о других вариантах (в том числе функциональщине) и не знал, когда применимо ООП, а кода нет (от чего и вызывало ужас), то Рефал не виноват в этом. Что ты на нём зациклился?
> Рефал не виноват в этом. Что ты на нём зациклился?Хочешь я за него отвечу? Не он зациклился на Рефале, а ты. И виноват в этом не Рефал, а ты.
Можно наковырять десятки DSL, типа Рефала, которые лучший выбор для какого-то узкого класса задач (или по-крайней мере заявляют о себе, что они лучший выбор). Но про Рефал ты говоришь, а про SQL, допустим молчишь. Как так вышло?
А я скажу тебе как: это реклама. Создаётся инфоповод чтобы привлечь внимание, и туда впихивается что-то смутно-быть-может релевантное для целей рекламы. И даже если ты видишь это как-то иначе, то именно так это видят те, кто читает.
Беда твоей гипотезы в том, что слово "Рефал" первый в этой ветке написал не я. В моём сообщении оно скопировано и идёт где-то в конце текста. Удивительно, как вообще ту портянку дочитали. Твою я вот не дочитал. ;)
>> Новое ключевое слово "__rvalue", позволяющее реализовать move-семантику
>> Добавлено placement-выражение "new" для инициализации указанным значением (без GC)
> Решили изобрести С++ заново?Ну, оно, если склероз мне не изменяет, одно время и позиционировалось, как "c++ done right" - но, судя по всему, норот так и не понял, зачем ему ещё одна (пусть даже и лудшая) c++ при наличии первой с её накопленным объемом кода...
Тут как обычно. Сначала сделали то что делать было нельзя категорически - сборщик мусора.Когда большинство библиотек стало на это ориентироваться. Стали пропагандировать сборку без сборщика мусора.
Сейчас х.з. но раньше в итоге была неудобоваримая каша.
Сейчас вот у новомодных языков модно новую такую же ошибку совершать, лепить то что точно нельзя делать - СВОЙ пакетный менеджер. А потом пытаться доказать что и без него писать можно.
Сборщик мусора это плюс языка.
Перф когда надо - можно делать, но часто он далеко не везде нужен.
Пакетный менеджер уже стандарт для почти всех языков - без него выглядит архаично.
>Сборщик мусора это плюс языка.Если без него нельзя обойтись - то это минус, жирнющий минус, в некоторых случаях даже "гвоздь в крышку гроба". Нельзя костыль называть плюсом, разве если ты маркетолог.
>>Сборщик мусора это плюс языка.
> Если без него нельзя обойтись - то это минус, жирнющий минус, в
> некоторых случаях даже "гвоздь в крышку гроба". Нельзя костыль называть плюсом,
> разве если ты маркетолог.Но обойтись без него можно - и конечно же все кто полноценно используют Ди легко это делают там где это нужно
Другой вопрос - что поскольку уровень программистов на Ди достаточно высокий - они еще и отлично понимают как устроены оптимизации, cache-locality, auto vectorization и прочие техники и где это нужно, а где и нет.
Но тут конечно только с опытом знания приходят - это не просто направо-налево кричать "если ГЦ - это гвоздь в крышку гроба" - там думать уметь надо ;)
> "если ГЦ - это гвоздь в крышку гроба" - там думать уметь надо ;)Вот именно из-за того что думать умет надо - это и есть гвоздь в крышку гроба.
Ибо большинство до этого этапа не дойдет.
Можно и не думать
Код будет работать - просто может быть не очень быстро
> Но обойтись без него можно - и конечно же все кто полноценно используют Ди легко это делают там где это нужноПопробуйте использовать стандартную библиотеку без gc.
Надо будет в следующую новость это добавить)
Потому что этот тезис уже оскомину набилИдея простая : если вы делаете что-то такое крутое и кастомное, что вам не подходит ГЦ, то и стандартная библиотека вам не помощник.
Реализации в стандартной библиотеке сделаны чтобы быть гибкими для разных подходов стандартного применения (с ГЦ).
Поэтому для задач где Гц не подходит - вам в любом случае нужно будет делать своё.
И так все и делают что в Ди, что в других языках.
Фейсбук и Гугл сделали свои C++ библиотеки.Недавний терминал Ghostly от создателя Хошикорп - откройте исходники и обнаружите что он реализовал свои data structures для его проекта.
Хм, действительно. Претензия снимается.
Так-то D хороший язык, для автоматизации обработки данных в реальном времени когда-то использовал. Теперь вот думаю снова к нему вернуться.
Прогать на D одно удовольствие, конструкции понятны с первого взгляда, не напрягают.
> Сейчас вот у новомодных языков модно новую такую же ошибку совершать, лепить то что точно нельзя делать - СВОЙ пакетный менеджер. А потом пытаться доказать что и без него писать можно.А какая альтернатива? Каждому пакету пытаться пробиваться в репозитории debian/rhel/archlinux/...?
А кто их туда пустит, пока их никто не использует? А кто их будет использовать пока их нельзя нормально поставить?Писать свои скрипты скачивания зависимостей, и в итоге каждому проекту изобретать свой пакетный менеджер?
Делать свой "не-пакетный-менеджер", как golang, и в итоге получить пакетный менеджер, но хуже?
Вендорить все зависимости, чтобы потом требовалось изобретать непонятную мешанину инструментов для аудита, которые из директории вендорнутых файлов будут определять версии пакетов, и проверять что в сравнении с апстримом в вендорнутую библиотеку не добавили дыр?
> Тут как обычно. Сначала сделали то что делать было нельзя категорически -
> сборщик мусора.Ээээт же ж не "better c", который "системный", а "better cpp", который "аппликушечный" - чем там сборщик мусора-то помешал?
> Сейчас вот у новомодных языков модно новую такую же ошибку совершать, лепить
> то что точно нельзя делать - СВОЙ пакетный менеджер. А потом
> пытаться доказать что и без него писать можно.Не, ну можно конечно на "системный" надеяться - тока в двух самых популярных системах, которые генерируют 99% выручки по пользовательскому, как минимум, софту - оного просто нет.
> а "better cpp", который "аппликушечный" - чем там сборщик мусора-то помешал?Тем, что C# уже есть?
Runtime to the moon
> Runtime to the moonА как же его AoT-компиляция?
>> а "better cpp", который "аппликушечный" - чем там сборщик мусора-то помешал?
> Тем, что C# уже есть?Не, шарпей это "better java", которая получена вот нифига не добавлением GC к C++...
> лепить то что точно нельзя делать - СВОЙ пакетный менеджер. А потом пытаться доказать что и без него писать можно.Не вижу в этом проблемы. Пакетный менеджер должен быть, быть один и позиционироваться как: "must have, но если очень хочется, то и без него, но не стоит". Вообще идеально, если так же дела будут обстоять и с системой сборки. А то сейчас в C++ всё это та ещё дичь: два пакетных менеджера и добрый десяток систем сборки. Влезаешь и не знаешь, как это друг с другом связать. От этого ещё и сами пакетные менеджеры усложнены.
> одно время и позиционировалось, как "c++ done right"В эту ловушку кто только ни попадал, но даже в случае головокружительного успеха всё равно получалась всего лишь более быстрая лошадь.
>> одно время и позиционировалось, как "c++ done right"
> В эту ловушку кто только ни попадал, но даже в случае головокружительного
> успеха всё равно получалась всего лишь более быстрая лошадь.Диалектический переход количества-в-качество еще никто не отменял )))
> Диалектический переход количества-в-качество еще никто не отменял )))Я отменяю.
>> Диалектический переход количества-в-качество еще никто не отменял )))
> Я отменяю.Вааау! Вот я с Гегелем и познакомился :)
>>> одно время и позиционировалось, как "c++ done right"
>> В эту ловушку кто только ни попадал, но даже в случае головокружительного
>> успеха всё равно получалась всего лишь более быстрая лошадь.
> Диалектический переход количества-в-качество еще никто не отменял )))Это не закон, а чушь, на которую купятся лишь незнакомые с термодинамикой друзья Энтропии.
>Это не закон, а чушь, на которую купятся лишь незнакомые с термодинамикой друзья Энтропии.Это как раз закон, и причём именно он определяет саму сущность "термодинамики". "Мало частиц"=классическая механика, "много частиц"=термодинамика. Сами частицы те же самые, но законы качественно иные.
>>Это не закон, а чушь, на которую купятся лишь незнакомые с термодинамикой друзья Энтропии.
> Это как раз закон, и причём именно он определяет саму сущность "термодинамики".
> "Мало частиц"=классическая механика, "много частиц"=термодинамика. Сами частицы те же
> самые, но законы качественно иные.Итак, эксперт готов рассказать, замкнута ли система, где работает так называемый "закон", придуманный предпринимателем Энгельсом?
Не только не отменял, но и не наблюдал в дикой природе, а это куда важнее любых гипотез.
Есть среда для быстрой разработки на С++ под названием ROOT. Там и твоя интерпретация, и gui.Есть также сборщик мусора для С++, boehm gc.
Это очень хорошо, но ведь новость про Дишку.
Левая новость
> Есть среда для быстрой разработки на С++ под названием ROOT. Там и
> твоя интерпретация, и gui."ROOT is a software framework for data analysis and I/O", чтобы не подсаживаться на матлаб и не слезать на питон. Оно хорошо, если на нём 20-30 лет сидеть, а сейчас зачем начинать?
Вы знали, что это изобретение Андрея Александреску и Герба Саттера, которое они бросили и ушли на пенсию?
Вообще-то, изобретение Уолтера Брайта. А Александреску позже присоединилися.
А Саттер до сих пор возглавляет ISO C++ и ни на какую пенсию не ушёл, хотя и свалил из микрософта
Всё, что нужно знать о D:С 2008 года есть такой мерзкий баг:
https://issues.dlang.org/show_bug.cgi?id=2043После затяжной войны на истощение Уолтер нот соу Брайт в 2022 наконец закрыл баг, но не потому что починил код, а как дубликат этого бага:
https://issues.dlang.org/show_bug.cgi?id=23136Что с ним, спросите вы? В 2024 этот баг переехал на Github:
https://github.com/dlang/dmd/issues/18108... и на этом пока всё.
"Это не баг — это фича"©.
В Go только в одном из последних релизов уломали пофиксить "фичу" (что-то там достаточно фундаментальное было на таком поведении завязано). При том что ресурсов в Go как бы немного побольше вбухано.Немного жаль, конечно, что гугл выбрал именно го под соответствующие задачи (не иначе как из-за названия). Но, что имеем…
* И да, D на моей памяти пытался в 200х рубить бабло на продаже компиллятора. Не осознав, что "тактика слегка поменялась".
Я из функциональщины пользуюсь только лямдами. Поэтому, для меня это ваще не проблема.
что-то модно, что-то вечно.
в свое время решительно так стал изучать Ди2. Даже переписал часть C#-кода для работы с dbf. Осталась как консольная читалка полей. В целом хорош, но для малознакомого с си и вообще компиляцией из исходников не смог преодолеть психологический барьер когда надо было разбираться с ошибками компиляции. Вообще есть достойная замена OBERON BlackBox Core
Они правда медленно развиваются в плане поддержки x86_64. Для среды все еще требуются гтк 32 битные. Уникальность его в том что они синтаксически очень хорош. Лучше не видел (F# в чем то близок).
Модульный. Сборки автономных приложений получаются минималистичными в отличии от того же дотнета несмотря на все старания. хотя возможно это потому что у них модули малофункциональные. Ну и опять же экосистема в зачаточном состоянии. Пока подходит только для встроек и обработки данных (ученым). Ну или уже оставаться всем на си. Чем он плох? ну или зиг. последний кстати уверенно набирает обороты
Странно, что Component Pascal не взлетел, когда в России столько поклонников Вирта. Под Windows этот BlackBox Component Builder имел графическую библиотеку и вроде бы вообще всё нужное. Под Linux небось и половину не перенесли за 20 лет?
Так эта, есть же русский Обберон. На ём даже Русскую ОСь пишут.