Dlang - нужно ли?

можно разделить, можно даже писать код с заголовочными файлами .di, как в плюсах

dlangui

умерло, есть форк beamui, он же atell

несерьезно, ну в багтрекере любое тело тыкнуть, н.р.

https://issues.dlang.org/show_bug.cgi?id=13123

bearophile_hugs 2014-07-13 16:07:27 UTC
dmd 2.066beta3 compiles this code:


void foo() nothrow
in {
    throw new Exception(null);
} body {
}
void main() {}

Jonathan M Davis 2016-10-12 21:59:13 UTC
This is still a problem.

обратите внимание на даты. оно еще открыто.

или в рантайм части багтрекер посмотреть, та еще малина https://issues.dlang.org/buglist.cgi?component=druntime&list_id=220148&product=D&resolution=---

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

1. Долгосторой2 классная «тема для поболтать». И это основное применение языка. Правила болтовни такие: нужно говорить только приятные вещи, которые от тебя хотят услышать. Никому не противоречить. Не упоминать про неприятные, сложные, спорные моменты. И вообще не важно, имеет ли сказанное хоть какое-то отношение к реальности.

2. Для разработки коммерческих приложений он не подходит совсем. Он до сих пор не объявлен стабильным, это значит, что написанный, проверенный, вылизанный код временами приходится переписывать. Это неприемлемо для production. Стабильности от языка ожидать не следует, потому что его создатель обещал это сделать еще когда существовал более длительный долгострой - C++0x. Но с тех пор и C++ стандартизировали и понаделали кучу языков со множеством более интересных возможностей (поэтому, все кому было интересно не только поиграться с фичами, но и получить практически полезный результат с D2 ушли). Кроме того, у D2 нет инфраструктуры, IDE, а главное разработчиков.

3. Для хобби-проектов он слегка подходит. Но тут есть дилемма. Ты либо можешь использовать маргинальный нестабильный полудохлый язык для своего хобби-проекта, при этом ты не сможешь использовать написанный код в production (потому что не бывает production на D2) и все потраченное время не даст тебе никакого полезного опыта. Либо можешь взять Rust/Go/Kotlin или любой другой язык и играться с фичами на нем, получая и опыт и навыки и код, который можно переиспользовать. В результате, чтобы писать на D2 нужно быть довольно странным.

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

Нанимать людей на рынке - тут да, но того же плюсовика и сишника перетащить на D если не очень, то достаточно легко.

Ты сам пробовал искать? Нашел? Или понаделал из сишников?

В общем почти со всем согласен насчет сырости языка, но люди как-то быстро стали забывать что фактически только последние 5 - 10 лет C++ компиляторы не такие сырые и глючные, а раньше это была скорее норма для С++. И на этом вполне писали продуктион код, и даже на таком эталоне глючности как С++ builder.

и даже на таком эталоне глючности как С++ builder

Не ну ненадо обобщать. билдер это кусок самизнаетечего. С остальными как-то жили, были известные проблемы и воркэраунды к ним.

Ну так и с D можно точно также жить.

В общем почти со всем согласен насчет сырости языка, но люди как-то быстро стали забывать что фактически только последние 5 - 10 лет C++ компиляторы не такие сырые и глючные, а раньше это была скорее норма для С++.

Лет 10 назад у D2 был шанс. Сейчас нет. И сейчас не пишут на древних глючных компиляторах 10-ти летней давности. Есть современные инструменты.

Тут вот yetanother уже несколько лет рассказывает про использование D.

Насколько я помню этого чувака по теме «В GCC завезут D», он притащил D в проект, где даже нет компилятора на production платформе. Но для него это «нюанс», потому что на localhost их аж 3. От него сбежала вся команда, новых разработчиков, как я понял, он так и не нашел (хотя искал и утверждает, что легко переучить сишников). Судя по тому, как он гордится тем, что половина проекта - это сериализация на метапрограммировании, именно ради этого все и затевалось. В C++ это делается кодогенерацией, потому что нет рефлексии. Например, на libTooling или CppAST, но этот вариант, конечно, не вариант - тут нужен D.

Ах, да, на production нет компилятора, поэтому существуют параллельно два проекта: один на D, другой на C++. И код переносится вручную (т.е. завтра делаем релиз - не вариант)!!! Представь, разрабатываешь ты пару месяцев код на D, а затем для релиза вручную переносишь изменения за последние два месяца на C++. А как же сериализация? Ее и на C++ надо как-то делать или уже не надо? В результате на production оказывается проект на C++, написанный в идеоматическом стиле D человеком, который предпочитает писать на D...

Ты до сих пор считаешь, что это удачный пример применения D в production? Кстати, в той теме он так и не ответил, в какой конторе работает (не верю, что в коммерческой). Моя версия была либо ВУЗ, либо госконтора.

И еще кстати, что будет с проектом, если это чувак из него уйдет? Классный такой job security и возможность пилить велосипед одновременно.

Ты до сих пор считаешь, что это удачный пример применения D в production?

У каждого свой production. И не у всех код в продакшене живет годами.

Например, те же ВУЗы берут разовые заказы на какую-нибудь наукоемкую лабуду. Типа рассчитать прочность такой-то конструкции в таких-то условиях. Срок заказа — ну пусть пару месяцев от силы. Потом все, что было сделано расчетного для этого заказа, вероятно, просто уйдет в корзину.

Сделать такую одноразовую работу проще на каком-нибудь D или Fortran-е, чем на C или C++.

Или какой-нибудь стартап, который пилит-пилит MVP и никак выпилить не может. Склепать что-то работающее на D может быть быстрее и проще, чем на C++, Rust-е или Go. А если все равно потом выбрасывать и пилить что-то другое, то качество компилятора D как-то не на первом месте будет.

Классный такой job security и возможность пилить велосипед одновременно.

Легко можно взять чистый C, наговнякать в нем мегатонну кода в стилле Эдди, без комментариев в коде и без тестов. Это обеспечит job security еще лучше, чем применение D. Или C++ с Boost-ом.

Если не ошибаюсь, в D, как и в Java/C#, принято не разделять классы на объявление и реализацию, писать всё в куче? Вот это, честно говоря, бесит. В C++ я посмотрел на объявление класса, увидел его визитную карточку. Жаль, что в новых языках от этого отказываются.

Есть такое, согласен. Иногда проскакивало такая мысль. В D можно сгенерировать интерфейсный вариант модуля с помощью ключа компилятора - т.е. компилятор сам отбросит тела модулей и функции и сформирует только их декларации. Но на практике я никогда этим не пользовался.

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

Ну сам язык еще разрабатывался с упором на быструю компиляцию.

Из гуев качественнее всего GtkD, я думаю. Там никаких проблем нет. С Qt сложнее, нормальных биндингов, насколько я знаю, так и нет. dlangui довольно развитый, но ничего не скажу про него. Для моих целей не очень подходит ни Gtk, ни Qt, ни dlangui. Использую в итоге imgui - у меня довольно специфические задачи, да и гуй только для отладки нужен, поэтому оказалось проще свое запилить.

Ты сам пробовал искать? Нашел? Или понаделал из сишников?

Пробовал. Нашел. Не делал.

Ты сам пробовал искать? Нашел? Или понаделал из сишников?

Пробовал. Нашел. Не делал.

«Нашел» это ты про того первого, кто от тебя сбежал, или ты потом еще кого-то нашел? Как долго искал? Какие задачи он выполняет (или он тоже сбежал)? Какой ник на ЛОРе?

Я себе совсем не представляю человека, который согласился разрабатывать на D. А уж с твоим workflow (писать на D и переписывать на C++)...

А почему три файла? Какой третий? (хедер, сппишник, ???)

У каждого свой production. И не у всех код в продакшене живет годами.

Про yetanother ты утверждал, что у него проект пишется годами.

Например, те же ВУЗы берут разовые заказы на какую-нибудь наукоемкую лабуду. Типа рассчитать прочность такой-то конструкции в таких-то условиях. Срок заказа — ну пусть пару месяцев от силы. Потом все, что было сделано расчетного для этого заказа, вероятно, просто уйдет в корзину.

Сделать такую одноразовую работу проще на каком-нибудь D или Fortran-е, чем на C или C++.

Такой проект напишут на Java/Kotlin(JRE). D там не будет. Если у тебя нет реальный примеров, то это галимая теория, не подтвержденная практикой.

P.S. Я так и не понял, считаешь ли ты разработку на D с переписыванием на C++ нормальным workflow?

Какой ник на ЛОРе?

А что это, собственно, даст? Даже если он здесь есть

Про yetanother ты утверждал, что у него проект пишется годами.

Пруф или не было.

Такой проект напишут на Java/Kotlin(JRE).

Вычислительный код на Java/Kotlin? Да вы знаете толк в извращениях.

Я так и не понял, считаешь ли ты разработку на D с переписыванием на C++ нормальным workflow?

В такой формулировке нет. Но у меня есть сомнения в том, что так кто-то делает, верить вам на слово оснований нет.

Такой проект напишут на Java/Kotlin(JRE). D там не будет.

Там будет питон (и пофиг, что считает неделями). А что за мода везде упоминать котлин?

Пруф или не было.

Забыл уже что сам написал?

Тут вот yetanother уже несколько лет рассказывает про использование D.

Или ты думаешь он про разные проекты рассказывает?

Я так и не понял, считаешь ли ты разработку на D с переписыванием на C++ нормальным workflow?

В такой формулировке нет. Но у меня есть сомнения в том, что так кто-то делает, верить вам на слово оснований нет.

Можешь спросить у него самого. А еще он это писал в теме про фронтэнд D в Gcc9. Он там писал, что для production платформы нет компилятора и что он пишет проект на D и что переносит код вручную. Я тогда предположил, что именно для ручного переноса кода он и нанял разработчика, который от него сбежал. yetanother ушел в несознанку.

Вот тут yetanother утверждает, что под production, таки, нет компилятора и он вручную переносит код. Далее начинает гнать пургу, что его пратформа amd64, под которую аж 3 компилятора (ага, на localhost).

Забыл уже что сам написал?

Нет.

Тут вот yetanother уже несколько лет рассказывает про использование D.

Или ты думаешь он про разные проекты рассказывает?

Не важно, что я думаю. Важно, что я не утверждал, что у yetanother долгосрочные проекты на D. Так что нехрен свои фантазии выдавать за мои слова.

Какой ник на ЛОРе?

А что это, собственно, даст? Даже если он здесь есть

Разработкой на D могут заниматься два типа людей. Фанатики, которые тащат его везде, а затем из пальца высасывают аргументы, почему именно так и нужно делать. И люди, у которых столько опыта, что для карьеры больше не надо и они могут работать в любом проекте на любом языке. Могут быть, конечно, и исключения из любого правила.

Ни один другой разумный разработчик не станет писать на D - это вредно для карьеры. Если я пишу на C++ или Java через пару лет, меняя работодателя я напишу в резюме, что у меня +2 года опыта на C++ или Java, я получил опыт работы с такими-то библиотеками и фреймворками, реализовал такой-то проект.

В случае разработки на D, если я про него напишу в резюме, то рекрутер положит его в стопку «неадекваты и фрики», т.е. в корзину или в низ стопки, потому что такой опыт никому не нужен и непонятно, зачем ты его приобретал. Можно, конечно, написать, что я разрабатывал на C++ или Java, и девочка-рекрутер не распознает. Но так как реального опыта я не получил, то на техническом собеседовании это всплывет. Таким образом, разрабатывая на D ты теряешь квалификацию и время, которое можно потратить на получение знаний, навыков и опыта работы с более востребованными технологиями. Именно по этой причине разработчика на D найти нереально и никакой сишник не станет переходить из своей ниши на маргинальный полумертвый язык.

Если yetanother реально нашел очередного неудачника, который разгребает рутину в его чудо-проекте с workflow пишем проект на D, отлаживаем, переписываем на C++, отлаживаем, повторяем итерацию, то я хочу, чтобы он делал это осознанно. Т.е. понимал, что за глупость он творит со своим временем жизни. И осознавал, что опыт разработки на D вреден для карьеры. Всегда есть шанс, что какой-то зеленый неудачник студент по своей неопытности на такое согласился. В таком случае, я хочу, чтобы он осознал ситуацию, в которой оказался и действовал сознательно.

Не важно, что я думаю. Важно, что я не утверждал, что у yetanother долгосрочные проекты на D. Так что нехрен свои фантазии выдавать за мои слова.

Если ты утверждаешь, что человек несколько лет пишет про проекты на D, то либо это один проект на несколько лет, либо разные, возможно, более короткие.

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

Анонимным надмозгам остается только пожелать читать то, что написано:

Тут вот yetanother уже несколько лет рассказывает про использование D.

Здесь есть утверждение только о том, что yetanother рассказывает.

Не нужно мне приписывать утверждения о том, что yetanother делает и как он это делает.

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

А почему три файла? Какой третий? (хедер, сппишник, ???)

Forward declaration: foo.h, foo_fwd.h, foo.cpp

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

Проект, в котором я участвую, написан на С и С++, ему точно больше 10 лет, ближе к 20. Писался под разные ОСи и платформы для разных продуктов с разными требованиями. Со всеми вытекающими. Один из подпроектов, которым я занимаюсь персонально, представляет собой вычислительный модуль, который получает данные в бинарном виде и в таком же виде возращает результат. Внутри сложная логика и нетривиальная математика. С точки зрения программиста, код не сложный, вся сложность в предметной области. Приходится много эксперементировать и много кода потом выбрасывается, а в продукт в итоге идут считанные строки (иногда в силу изменений/ дополнений в ТЗ изменения получаются большими, но это было пару раз, в основном изменения в коде небольшие). Когда меня позвали в проект, можно было использовать только С++98 по требованиям заказчика. Команду это более чем устраивало и не было даже основания предполагать, что это изменится в ближайшее время. Поэтому прототип, тесты и внутренние инструменты были написаны на D, поскольку уже были некоторые наработки у меня. Еще раз подчеркиваю - прототип, тесты и внутренние инструменты. Сам модуль всегда был на плюсах. В начале на С++98, сейчас С++11. Использование D значительно сокращает время в моем случае. Например, мне не нужно использовать какие-то внешние инструменты типа libtooling или CppAST, что упрощает разработку (не нужен дополнительный этап при сборке), требования к разработчику (не нужно знать libtooling или CppAST - достаточно знать язык) и снижает затраты на инфраструктуру (не нужны лишние зависимости, их обновления и т.д.), а также сопровождение продукта(нет необходимости отслеживать, что внешняя тулза по прежнему подцепляет нужные исходные данных и пишет результат куда нужно). А я отвечаю за все стороны жизни этого модуля, от чтения научных статей на эту тему до поддержки ci pipeline, причем всего проекта, а не только своего подпроекта. И что такое инфраструктура как код я знаю не понаслышке - намучался с этим я в свое время достаточно, сейчас из ansible опускаю/подымаю всех сборщиков и настраиваю со всеми зависимостями одним скриптом. Так что что такое лишняя зависимость и почему не стоит бежать на последнюю версию супермегакрутой библиотеки я знаю не со слов. Ну это я в сторону отвлекся. Поскольку я часто модифицирую структуры данных, рефлексия в D просто незаменима. Банальнейший пример - я часто добавляю/убираю/модифицирую поле в структуре данных и вывожу ее во время эксперимента в стандартный вывод просто командой `writeln(foo);`. Компилятор D выводит все без каких-либо действий с моей стороны. На плюсах мне бы пришлось перегружать оператор вывода в поток, писать boiler plate разный. А если тело оператора в заголовочном файле, то будет пересобираться весь код, который зависит от него. Либо надо будет только из-за оператора вывода в поток заводить .cpp файл и прописывать его в системе сборки. И вот приходится либо ждать пересборки половины подпроекта на каждый чих пока ты эксперементируешь или продумывать нюансы, которых в D просто нет. Использовать дебаггер не вариант потому что в эксперименте интересно поведение алгоритма в разрезе времени. Теоретически можно gdb скрипты использовать для этого использовать, я это точно пробовал, но на практике это не прижилось у меня, но почему - сейчас не помню. Также очень удачным для прототипирования и рефакторинга оказалось что в D нет косвенного разыменования указателя - если я изменил тип-значение на тип-указатель на дишной стороне практически не нужно ничего делать. На плюсовой стороне - нужно заменить "." на "->" и наоборот.

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

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

Большая часть дишного кода это тесты и внутренние инструменты, плюсовая часть намного меньше. Нет никакой разработки на D и потом переписывание всего на плюсы, что это за бред? Есть разработка на D, по ее результатам вносятся дополнительные изменения в плюсовую часть. Изменений на дишной стороне просто несоизмеримо больше чем на плюсовой и только небольшая часть из них переносится на плюсовую часть.

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

Так что аноним, я в недоумении, отчего у тебя такой негатив по поводу более чем удачного примера применения D. Может дышать глубже попробуешь? Ах да, контора у нас коммерческая, но рынок не массовый и рабочий процесс у нас, скажем так, специфический.

Хотя я уверен, в силу твоей ангажированности, дорогой анонимус, ты опять переврешь мои слова в пользу твоего единственно истинного мнения что и я, и D - оба неудачники. Ну и хрен с тобой. Может ты свои проблемы проецируешь, откуда я знаю? Людей неадекватныx знаешь сколько? Без обид только.

З.Ы. про сбежавшую команду и то, что я, как ты понял, новых разработчиков так и не нашел - я посмеялся. Естественно, внутреннюю кухню я никому раскрывать не буду, тем более тебе. Но вкратце - ты далек от истины.

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

О, я уже соскучился по тебе, мой персональный хейтер!

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

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

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

Один из подпроектов, которым я занимаюсь персонально, представляет собой вычислительный модуль, который получает данные в бинарном виде и в таком же виде возращает результат. Внутри сложная логика и нетривиальная математика. С точки зрения программиста, код не сложный, вся сложность в предметной области. Приходится много эксперементировать и много кода потом выбрасывается, а в продукт в итоге идут считанные строки (иногда в силу изменений/ дополнений в ТЗ изменения получаются большими, но это было пару раз, в основном изменения в коде небольшие).

Я себе это вижу так, есть прототип на D, где идет разработка и production на C++. Разработав очередной алгоритм рассчета ты его вручную переносишь из D в C++. Как тут можно обойтись несколькими строчками, мне не понятно. Более того, в той теме, на которую я ссылался, ты сам утверждал, что такой перенос бывает довольно трудоемким. Если убрать прототип на D и писать сразу на C++, то таких сложностей совсем не будет.

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

Тут ты пытаешься доказать, что притащить в проект отдельный язык, это проще, чем использовать кодогенератор для C++ на основе CppAST. В альтернативной реальности, в которой, похоже ты находишься и в которой без D ну никак не обойтись, это, возможно, так и есть. Кстати, кодогенератор можно не тащить в production и использовать только на машине разработчика, включая сгенерированные файлы в репозиторий. Так делают с bison, например. В проект включают файлы как исходные для бизона, так и то, что он сгенерировал.

А я отвечаю за все стороны жизни этого модуля, от чтения научных статей на эту тему до поддержки ci pipeline, причем всего проекта, а не только своего подпроекта.

Да ты - Герой! Тебе приходится разбираться с прикладной областью и, даже, заниматься непрерывной интеграцией. Читать статьи и разбираться с предметной областью приходится всем разработчикам, кроме тех, что по 10 лет сидят на одном легаси проекте. CI настраивают при отсутствии выделенного DevOps тоже все.

Поскольку я часто модифицирую структуры данных, рефлексия в D просто незаменима.

Ты либо это можешь делать на D с его рефлексией, либо кодогенерацией на C++ и тогда не придется вручную переносить код из прототипа на D в C++. Но в твоей альтернативной реальности без D никак и ты будешь из пальца высасывать аргументы, почему по другому нельзя. Кстати, в языках с рефлексией, кодогенерацию тоже используют.

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

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

Также очень удачным для прототипирования и рефакторинга оказалось что в D нет косвенного разыменования указателя - если я изменил тип-значение на тип-указатель на дишной стороне практически не нужно ничего делать. На плюсовой стороне - нужно заменить "." на "->" и наоборот.

Ааа, ну это все меняет.

Нет никакой разработки на D и потом переписывание всего на плюсы, что это за бред? Есть разработка на D, по ее результатам вносятся дополнительные изменения в плюсовую часть.

Цитирую себя же:

Представь, разрабатываешь ты пару месяцев код на D, а затем для релиза вручную переносишь изменения за последние два месяца на C++.

Так что научись читать, а не слушать голоса у себя в голове. И кстати, что с сериализацией в плюсовой части? Она все еще нужна или уже нет?

Так что аноним, я в недоумении, отчего у тебя такой негатив по поводу более чем удачного примера применения D. Может дышать глубже попробуешь?

Базар фильтруй.

Ах да, контора у нас коммерческая, но рынок не массовый и рабочий процесс у нас, скажем так, специфический.

Это такая, где 95% бюджета идет из госбюджета? Но ты же не скажешь название, чтобы каждый сам смог сделать выводы...

З.Ы. про сбежавшую команду и то, что я, как ты понял, новых разработчиков так и не нашел - я посмеялся. Естественно, внутреннюю кухню я никому раскрывать не буду, тем более тебе. Но вкратце - ты далек от истины.

Я тебе задал конеретные вопросы: нанял ли ты людей в свою команду для работы над кодом, связанным с D и чем они занимаются. Ты, по сути, не ответил из чего я делаю вывод, что ты до сих пор работаешь один. По теме, на которую я давал ссылку, я понял, что от тебя ушел разработчик и на тот момент ты был один, а значит, замены не нашел. Мне было интересно, какова ситуация на текущий момент. Я написал выше, что разработка на D вредна для карьеры, а, значит, ни один разумный разработчик на такое не пойдет. А на проект, где нужно вручную переносить код из прототипа на D в C++ production вообще никто не пойдет. Но это теория, хотел узнать, какова практика. Судя по отсутствию ответа и «которым я занимаюсь персонально» - ты до сих пор работаешь в одиночку.

P.S. Включи мозги, и пойми, что если ты уходишь от ответа, то это тоже ответ. В том числе и муть в стиле «ты далек от истины» без конкретики.

Есть разработка на D, по ее результатам вносятся дополнительные изменения в плюсовую часть.

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

Он же вообще примитивный

Скорее квадратно-гнездовой. Тем и хорош. Тем и плох.

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

Мое мнение такое:

• ни в комментарии в старой теме,
• ни в развернутом комментарии yetanother в этой теме

нет достаточной для меня информации, чтобы делать какие-то выводы.

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

Соответственно, если есть надобность время от времени менять данные параметры/коэффициенты, то нужно знать их новые значения. А для получения этих значений может потребоваться создание и обкатка целей кучи дополнительных моделек (т.е. проведения целой кучи вычислительных экспериментов). И вот эта дополнительная работа запросто может выполняться на любом другом языке. Будь то D, Python+nympy, MathLab/Matematica или еще что-то.

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

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

Соответственно, если есть надобность время от времени менять данные параметры/коэффициенты, то нужно знать их новые значения. А для получения этих значений может потребоваться создание и обкатка целей кучи дополнительных моделек (т.е. проведения целой кучи вычислительных экспериментов). И вот эта дополнительная работа запросто может выполняться на любом другом языке. Будь то D, Python+nympy, MathLab/Matematica или еще что-то.

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

Если бы анонимус, ты задал вопрос, почему используется не Питон в моем случае - это был бы конструктивный вопрос. Но ты куда то полез на личности, на особенности конкретного проекта. Все это говорит о твоей предвзятости. У тебя нет цели ответить на вопрос топик стартера. Ты уже для себя все давно решил и просто хейтишь здесь. В любом проекте есть какие-то свои особенности, но ты пытаешься выставить проект, в котором я участвую, в неудачном свете и обосновать это использованием D. Уход разработчиков также объясняешь этим же. Что за хрень ты несешь? Вот ушел человек, которому не понравился git workflow у нас - он категорически не хотел делать rebase своей ветки перед слиянием в develop. При этом код у человека адекватный на гитхабе, по нужной тематике. Звучит странно, но это реальный случай. Но как можно связать его уход и этот топик?

Постой, анонимус, а тебя часом не Леша зовут? Причем не Алексей, а именно Леша? Это бы все объяснило)

С другой стороны, намного удобнее когда все в одном месте.

При написании кода (а ещё точнее, в момент заведения нового поля/метода) — да. При сопровождении — нет.

Когда ты открываешь программу, которую последний раз правили год назад, и с большой вероятностью это делал другой человек, нужен «взгляд сверху»: что делает класс. Не отдельная функция setSepulka(), а класс в целом. И вот тут «селёдка под шубой» в стиле C#/Java начинает дико раздражать.

Ситуацию в ряде случаев могут спасти интерфейсы, но не везде они применяются, да и не всегда нужны.

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

Когда ты открываешь программу, которую последний раз правили год назад, и с большой вероятностью это делал другой человек, нужен «взгляд сверху»: что делает класс. Не отдельная функция setSepulka(), а класс в целом. И вот тут «селёдка под шубой» в стиле C#/Java начинает дико раздражать.

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

И вот тут «селёдка под шубой» в стиле C#/Java начинает дико раздражать.

Любая IDE тебе покажет нормально. Все же умеют сворачивать/разворачивать определения методов.

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

А какие есть редакторы/IDE, понимающие синтаксис D? Не просто цветовыделяющие, а именно способные свернуть его методы?

А какие есть редакторы/IDE, понимающие синтаксис D? Не просто цветовыделяющие, а именно способные свернуть его методы?

VSCode умеет это делать. Да я думаю и другие редакторы тоже. Я раньше сидел на sublime_text3, он мне нравился больше чем VSCcode как редактор, но в последнем есть встроенный терминал и я в итоге на него перешел, так как люблю командную строку. Для поддержки D я установил плагин Dlang от Laurent Tréguier. Есть к нему замечания, но меньше чем к code-d от WebFreak на котором я долго сидел до этого. code-d на мой взгляд довольно раздутый и от этого не очень качественно работает, у него даже не сразу понятно какая версия новее. Его автор претендовал на звание автора лучшего плагина для поддержки D с оплатой в 3000 долларов от DLang Foundation, но на мой взгляд он не тянет на это. Как-то сыро у него и раздуто все, хотя так парень толковый по общению в инетах. При этом по факту оба эти плагина под капотом используют один и тот же стек - dformat, dfmt и т.д. Но реализации разные.

А какие есть редакторы/IDE, понимающие синтаксис D? Не просто цветовыделяющие, а именно способные свернуть его методы?

Давно уже D не трогал, но раньше под оффтопик был весьма годный Visual D. Сейчас посмотрел, жив и вполне развивается, https://rainers.github.io/visuald/visuald/StartPage.html и вполне полноценное IDE https://rainers.github.io/visuald/visuald/Features.html .

Здесь Но, похоже, при всем богатстве выбора, кроме Dexed, выбирать особо нечего - большинство IDE не активны год и более.

Здесь Но, похоже, при всем богатстве выбора, кроме Dexed, выбирать особо нечего - большинство IDE не активны год и более.

Да просто автор dexed позаботился об обновлении вики, а остальное никто не обновляет. Тут просто нет обновления. VisualD активно разрабатывается и очень качественная, но только под оффтопик. Нет упоминания про VSCode, под sublime_text3 тоже был плагин. Mono-D была шикарной в свое время, но потом API поменялся, а автор перетаскивать не захотел. DDT тоже заброшен давно, я как-то юзал его. Но впечатление от Эклипса у меня конечно не очень. Плагин для IDEA разрабатывается, но темпы не очень.

В sublime есть терминал через плагин, лол.

Мне нравится, но дальше pet-project применения (лично для себя) не нашёл пока.

DlangIDE предположительно ( https://github.com/buggins/dlangide ).

Нда. Одно проприетарное, другое на вебне, третье, которое ниже посоветовали, только под винду. Посмотреть, что ли, в сторону DlangIDE действительно...

принято не разделять классы на объявление и реализацию, писать всё в куче?

Так везде же есть (ide, продвинутые редакторы) «список символов», и там указанны методы, функции итд из открытого файла. Зачем тебе вообще D?) Лучше уж lazarus...

неа, его обновлять надо, у DCD изменился API и теперь в автокомплит выпадает все, т.е. вместо завершения названия функции вставляется ее полное описание с документацией областью видимости и модулем в котором она объявлена.

Если хочешь попробовать что-то действительно интересное, а не то же *овно, но в новой обёртке - бери Ocaml/ReasonML. Особенно в разрезе «вебни».