DM>Я тут недавно на современный Swift смотрел, вот он реально выглядит как такое усреднение с выбором всего хорошего и отбрасыванием плохого. И ООП есть, и традиционные для ФП фишки вроде алгебраических типов, паттерн матчинга, тайпклассов/трейтов, при этом вместо GC встроенный подсчет ссылок. Памяти ест мало, работает быстро. Вполне себе кандидат.
а если в сторону более формальных языков смотреть?
горюю о печальном состоянии Dafny и о том, что ничего сравнимого по дружественности так и не запилили.
или я ошибаюсь?
Здравствуйте, vsb, Вы писали:
vsb>Я всё равно считаю, что ООП не нужно. Пишу на Java и ООП использую раз в год. Для раза в год можно и ручками сымитировать что надо. Тем более, что в Rust и сахар для виртуальных методов есть, это не C, где надо таблицы забивать указателями вручную.
Во приведенных 4 поп. языках оно есть и активное используется, причем реализовано все примерно одинаково. Так же и в том же C++ есть и активно используется.
Здравствуйте, Alekzander, Вы писали: A>А ещё позже я познакомился с такой точкой зрения, что теория вычислений (включающая в себя программирование) это, по сути, изучений следствий ограничения математики законами физики. (Что вычислимо, а что нет, и пр.) Короче говоря, широко распространённая запись программного кода символами это совсем не случайность.
Да, программирование будущего наверняка не будет записью математической логики, по крайней мере, в большинстве своём. Я, напротив, про более визуальное (если не изобретут нейро-интерфейс и тогда будет "нейральное" восприятие) оформление кода.
Здравствуйте, Евгений Музыченко, Вы писали:
A>>Интерфейсам на vtbl нужно заполнение vtbl. Данные типа, доступные в рантайме, им не нужны. (Конечно, кроме гуида, имени библиотеки, разных флагов и пр. )
ЕМ>Для чего "интерфейсам на vtbl" могло бы потребоваться перечисленное?
Ты теперь и шутки охраняешь?
Перечисленные мною вещи являются условно-полезными. Гуиды можно применить для паттерна "грани" (в терминологии COM — QueryInterface). Имя библиотеки и её автора можно показать юзеру в диалоге "О плагине". Версию можно использовать для борьбы с version hell. Хотя всё это вещи прекрасно обходимые, и решаемые через добавление соответствующих методов.
Но даже на их фоне информация в рантайме о том, что сиплюсплюсный объект, скрывающийся за указателем, был получен в результате наследования от interface, от abstract class или вообще ни от чего, является феноменально бесполезной.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>Здравствуйте, korvin_, Вы писали:
A>>>В C++ интерфейсы это про vtbl. В C# и Java интерфейсы это про данные типа, доступные в рантайме. Интерфейсам на vtbl нужно заполнение vtbl. Данные типа, доступные в рантайме, им не нужны. (Конечно, кроме гуида, имени библиотеки, разных флагов и пр. )
_>>Какие данные типа.
A>Type.IsInterface.
Здравствуйте, Sinclair, Вы писали:
S>И вот нам надо убедиться, что а) реализация корректно реализует заявленную state machine
Эквивалентность двух детерминированных конечных автоматов проверить легко — минимизируешь оба и сравниваешь. ))
Т.е., вот у вас есть формальное описание автомата (можно даже на языке регулярных или расширенных регулярных выражений по Холмскому, не которые Перловые) — порождай из него эталонный минимальный автомат, затем минимизируй пространство состояний и входных/выходных сигналов реализованного автомата и сравнивай с эталоном.
Для сравнения оба автомата должны быть реализованы по одной и той же схеме — Милли или Мура.
S>б) вторая сторона тоже корректно реализует свою часть протокола.
Тестирование детерминированных автоматов как "черных" ящиков производится через цепочки воздействий (цепочки т.н. "символов"), составляющих допустимые цепочки "грамматики", т.е. когда автомат ходит по допустимым состояниям. Ну и по-классике, позитивные и негативные тесты, чтобы удостовериться, что автомат правильно реагирует на недопустимые последовательности воздействий.
Т.е., если речь о ДКА, его всегда можно описать через эквивалентный парсер некоей регулярной грамматики (по Холмскому).
Если поведение алгоритма невозможно описать эквивалентным ДКА, а, скажем, необходим будет более общий автомат, например, с магазинной памятью, то, в зависимости от вида описания состояний, необходимо будет выбрать одну из КС-техник реализации автомата. На сегодня тотально рулят LR(k)-техники, или более общий из них GLR.
Здравствуйте, novitk, Вы писали:
N>В этом и проблема — в Swift не ХМ, как и в Скале.
ХМ — это наиболее общий алгоритм вывода и наиболее слабый — плохо подходит в случае перегрузки обычных операторов языка, не подходит напрямую для ООП.
Но его запросто дополняют и продолжают врать, что это ХМ, хотя там уже полно дополнений и ограничений, где типы выводятся к ближайшему общему предку (в Немерле аналогично) и т.д.
Скорее, грамотней говорить просто об автовыводе типов через унификацию в некоем наборе правил этой унификации, а не ссылаться на конкретно ХМ.
Здравствуйте, Shmj, Вы писали:
S>C++ вроде хорош, но большое легаси. И от легаси не уйти — оно всегда будет просачиваться. Хотя в последние версии добавили и умные указатели и пр. — это уже как бы довесок. Вот если бы они изначально делали язык по этим принципам, не заботясь о совместимости — было бы намного лучше.
Мне вот интересно, что мешает в 2024-м году для плюсов сделать нормальную систему сборки, нормальную модульность, с репозиториями и версиями. И имея эту модульность сделать нормальную УДОБНУЮ библиотеку алгоритмов, пофиг что не совместимую, но чтоб можно было с комфортом писать на этом новые приложения. А то я конечно не сильно слежу, но такое впечатление что с библиотеками и системами сборки все сейчас примерно как 30 лет назад.
Здравствуйте, elmal, Вы писали:
E>Мне вот интересно, что мешает в 2024-м году для плюсов сделать нормальную систему сборки, нормальную модульность, с репозиториями и версиями. И имея эту модульность сделать нормальную УДОБНУЮ библиотеку алгоритмов, пофиг что не совместимую, но чтоб можно было с комфортом писать на этом новые приложения. А то я конечно не сильно слежу, но такое впечатление что с библиотеками и системами сборки все сейчас примерно как 30 лет назад.
Бюрократия мешает и искусственно созданные грабли, которые жалко бросить и тяжело поддерживать.
S>>C++ вроде хорош, но большое легаси. И от легаси не уйти — оно всегда будет просачиваться. Хотя в последние версии добавили и умные указатели и пр. — это уже как бы довесок. Вот если бы они изначально делали язык по этим принципам, не заботясь о совместимости — было бы намного лучше. E>Мне вот интересно, что мешает в 2024-м году для плюсов сделать нормальную систему сборки, нормальную модульность, с репозиториями и версиями.
Ох уж эти меньшинства блэт. Вот почему Сшники не приходят на Go-форумы и не орут — уберите ваши гребаные модули, хотим инклудники как как в сишечке! А вот эти вот прут... со своим уставом...
Как много веселых ребят, и все делают велосипед...
Здравствуйте, elmal, Вы писали:
E>Мне вот интересно, что мешает в 2024-м году для плюсов сделать нормальную систему сборки, нормальную модульность, с репозиториями и версиями. И имея эту модульность сделать нормальную УДОБНУЮ библиотеку алгоритмов, пофиг что не совместимую, но чтоб можно было с комфортом писать на этом новые приложения. А то я конечно не сильно слежу, но такое впечатление что с библиотеками и системами сборки все сейчас примерно как 30 лет назад.
Ну вот QT-библиотеки вроде норм, но платные иногда.
Здравствуйте, elmal, Вы писали:
E>И имея эту модульность сделать нормальную УДОБНУЮ библиотеку алгоритмов, пофиг что не совместимую, но чтоб можно было с комфортом писать на этом новые приложения.
Это прекрасно можно сделать и не имея никакую модульность.
А ответ описывается анекдотом: "Нет спроса — нет завоза".
Ровно 16 лет назад состоялся последний релиз https://reason.io/index.htm. Но к тому времени все, кому нужны были удобства, уже разбежались по джавам и дотнетам. Остались мутанты, которым чем страшнее, тем лучше. Чтобы профаны в их коде не могли разобраться. Плюс вот тут выше есть пример, как упёртые сишники не понимают, зачем лямбды. Сам понимаешь, каким спросом у них будет пользоваться суб-библиотека типа LINQ, если её включить в стандарт. (А ведь тоже можно написать без изменений синтаксиса!)
Но лично я, конечно, многое бы отдал, чтобы написанное тобой стало реальностью. Язык хороший, просто около двадцати лет им занимаются очень плохие люди.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Что-то точно есть теперь, но в подробности не погружался.
N>собирается в ~static linking ехе? если да, то размер helloworld.exe?
Теперь собирается! Сейчас получилось на линуксе собрать. Если обычный нестатический helloworld занимает 17 КБ (но ссылается на пачку .so), то при сборке с ключом --swift-sdk x86_64-swift-linux-musl получается бинарник, про который ldd говорит "not a dynamic executable", т.е. полностью статический, и он размером... 42 МБ! Пипец, конечно.
Здравствуйте, elmal, Вы писали:
E>А то я конечно не сильно слежу, но такое впечатление что с библиотеками и системами сборки все сейчас примерно как 30 лет назад.
К нам приходят с большим опытом Питона, подключают для С++ чаще всего Conan (реже vcpkg), используют в своих рамках, не жалуются на особую сложность. Если что-то не работает из коробки — зовут меня. Так что за 30 лет изменения всё таки есть, да.
Здравствуйте, vsb, Вы писали:
vsb>Тут возникает проблема с тем, что современный ИИ, показывающий интересные результаты, обучался на огромных массивах готового кода. У меня нет уверенности, что получится сделать ИИ, показывающий похожие результаты с языком, на котором никто ничего не написал.
Кстати, сейчас всё чаще используют RAG, когда к нейронке просто подключают внешнюю базу знаний, а также агентов. И контекст всё больше увеличивают. То есть никто не мешает нейросеть сначала чуть дообучить на новом языке, скормить синтаксис языка с примерами в виде промта, потом дать возможность вызова компилятора и анализатора ошибок. Может и сработать
)
