Здравствуйте, Shmj, Вы писали:
S>Вот взять популярные языки — C#, Java, Dart, TypeScript даже.
S>По сути они мало чем друг от друга отличаются. Ну разве что в Dart и TypeScript другая концепция работы с многопоточностью, а так отличаются в мелочах лишь.
Ты перечислил 4 языка, которые (1) из семейства Си-подобных языков с классами (2) с автоматическим управлением памятью и сборкой мусора (3) компилируются не в машинные коды, а во что-то промежуточное, что потом или интерпретируется или JIT-ится.
Ну, довольно не удивительно, что они чем-то похожи
S>Основной минус этих языков — слишком большое расходование памяти (хотя C# позволяет и управлять памятью напрямую — все библиотеки то построены на GCC).
Язык не может расходовать память. Память расходует программист.
S>И убеждать себя или других что ООП не нужно — глупо. Все популярные языки из 4-ки выше его содержат и примерно в одинаковой реализации, концепции те же самые. Нужно, еще как нужно.
Это из серии, что опрос среди пользователей интернета показал, что 100% населения используют интернет.
Здравствуйте, Shmj, Вы писали:
S>C++ вроде хорош, но большое легаси. И от легаси не уйти — оно всегда будет просачиваться. Хотя в последние версии добавили и умные указатели и пр. — это уже как бы довесок. Вот если бы они изначально делали язык по этим принципам, не заботясь о совместимости — было бы намного лучше.
Мне вот интересно, что мешает в 2024-м году для плюсов сделать нормальную систему сборки, нормальную модульность, с репозиториями и версиями. И имея эту модульность сделать нормальную УДОБНУЮ библиотеку алгоритмов, пофиг что не совместимую, но чтоб можно было с комфортом писать на этом новые приложения. А то я конечно не сильно слежу, но такое впечатление что с библиотеками и системами сборки все сейчас примерно как 30 лет назад.
Здравствуйте, Shmj, Вы писали:
S>Что-то усредненное из этого можно назвать идеальным ЯП для среднего человека. S>Итого. Идеальный язык мне представляется как Rust, но с полноценным ООП и ...
Я тут недавно на современный Swift смотрел, вот он реально выглядит как такое усреднение с выбором всего хорошего и отбрасыванием плохого. И ООП есть, и традиционные для ФП фишки вроде алгебраических типов, паттерн матчинга, тайпклассов/трейтов, при этом вместо GC встроенный подсчет ссылок. Памяти ест мало, работает быстро. Вполне себе кандидат.
шмыга-балабол нафлудивший килотонны мусорного бреда на форуме за, без малого 20 лет
так и не изучивший не одного языка
сидит и вбрасывает очередной висер про идеальный язык
это прям как про пельмешки, которые по силе мысли должны обкатываться в сметане и прыгать в рот
Здравствуйте, novitk, Вы писали:
DM>> современный Swift
N> Он чем-то от C# отличается кроме нативной поддержки ADT? refcounting GC & llvm AOT это про рантайм.
Там вместо ООПшных интерфейсов — протоколы, подобные multiparameter type classes из хаскеля или traits из Раста. Когда можно свой интерфейс/трейт придумать и уже существующие чужие типы объявить, что они ему соответствуют, и как именно. И есть то, что хаскель называет existential types, а раст — dyn traits, когда передается "точно не знаю что, но оно умеет вот в этот интерфейс". Можно иметь "список хреней, умеющих то-то", причем это необязательно классы с общим предком, вообще не классы могут быть. Функция может возвращать разные неродственные типы, если они один протокол реализуют, такое вообще мало где есть.
Нет привычных исключений, но есть внешне похожие на них способы возвращать и передавать дальше ошибку, похоже на то, что в Zig.
Параметры у функций по умолчанию иммутабельны. Даже если передаешь объект с мутирующими методами, функция, куда передал, не сможет их вызвать. Нужно или явно разрешить мутирующий доступ, объявив параметр inout и передавая его как &x, или функция может сделать локальную копию, и мутировать ее, а оригинальный объект при этом не изменится.
Довольно неплохо сделаны optional types, которые на первый взгляд похожи на nullable, но на самом деле ближе к ФП-шным Maybe / option — они нестятся, потому Int? и Int?? это разные типы с разной информацией.
Есличо, я только на прошлой неделе взялся опять на свифт смотреть и написал на нем ровно одну программу на 200 строчек.
N>Как с tooling в win/linux?
Что-то есть и работает, я на линуксе как раз играюсь. Поставил пакет swift-bin и вперед.
N>в vscode LSP рабочее?
Хз. Но в Helix'e LSP сразу подцепился и как-то работает — автокомплит, ошибки, все такое.
N>jupyter kernel?
Хз.
N>Что с пакетным менеджером, типа nuget/cargo? В репо библиотеки должны быть под платформу или пакетный менеджер их при установке адаптирует? Там оно все к МаcOS не привязано?
Какой-то есть свой. Кроме компилятора swiftc там есть команда swift, которая как раз рулит процессом, умеет создавать проекты, качать зависимости, собирать всё и т.д. https://swiftpackageindex.com/ показывает больше 7к пакетов.
N>Байндинг к C++?
Хз.
N>собирается в ~static linking ехе? если да, то размер helloworld.exe?
По умолчанию helloworld — маленький бинарник (16 КБ), но ссылающийся на кучку .so, в сумме мегов 20 они.
Если скомпилить swiftc -static-executable hey.swift -o hey, то получается 9 МБ, полностью статичный, но не работает.
Пишут, что в Swift 6 будет работать нормально, пока что нужно с бубном поприседать.
Вот взять популярные языки — C#, Java, Dart, TypeScript даже.
По сути они мало чем друг от друга отличаются. Ну разве что в Dart и TypeScript другая концепция работы с многопоточностью, а так отличаются в мелочах лишь.
Что-то усредненное из этого можно назвать идеальным ЯП для среднего человека. Экзотику типа Haskell оставим гениям, коих не много. А вот самое идеальное, максимально понятно, к чему пришло человечество — некий усредненный язык из этих.
Основной минус этих языков — слишком большое расходование памяти (хотя C# позволяет и управлять памятью напрямую — все библиотеки то построены на GCC).
Rust и ООП
Вроде попытались сделать Rust, который и без легаси и памятью позволяет управлять. Но там нет самого главного, что есть в 4-ке лидеров — полноценного ООП с понятным наследованием и простой реализацией ООП-паттернов. Как-то его можно делать через одно место + макросы (к примеру, чтобы не делать override всех функций а только тех, которые нужны) — но не оно
И убеждать себя или других что ООП не нужно — глупо. Все популярные языки из 4-ки выше его содержат и примерно в одинаковой реализации, концепции те же самые. Нужно, еще как нужно.
C++
В C++ есть ООП можно сказать даже избыточное — есть private, protected и public -наследование, есть множественное наследование. Зато нет ключевых слов для интерфейсов и абстрактных классов, хотя это полезно (в 4-ке лидеров это есть).
C++ вроде хорош, но большое легаси. И от легаси не уйти — оно всегда будет просачиваться. Хотя в последние версии добавили и умные указатели и пр. — это уже как бы довесок. Вот если бы они изначально делали язык по этим принципам, не заботясь о совместимости — было бы намного лучше.
Итого. Идеальный язык мне представляется как Rust, но с полноценным ООП и отсутствием макросов. Т.е. макросы могут быть, но не системные — т.к. это весьма усложняет. В 4-ке лучших языков нет особенной привязки к макросам или вообще их нет.
Здравствуйте, Shmj, Вы писали:
S>По сути они мало чем друг от друга отличаются. Ну разве что в Dart и TypeScript другая концепция работы с многопоточностью, а так отличаются в мелочах лишь.
Так вы просто не стем сравниваете, сравните с erlan, apl, sql, vhdl, lisp
S>Что-то усредненное из этого можно назвать идеальным ЯП для среднего человека.
Для среднего человека вая ЯП "нафиг не нужон"
S>Итого. Идеальный язык мне представляется...
Идельный для чего?
Здравствуйте, Shmj, Вы писали:
A>>Причём тут интерфейсы. В чём была бы польза от ключевого слова abstract для классов в C++? >>>В C++ есть [...]. Зато нет ключевых слов для ... абстрактных классов, хотя это полезно
S>Ладно, не так выразился — точнее будет сказать — спец. механизм для интерфейсов, отличающий их от абстрактных классов — и невозможность потом добавить в интерфейс реализацию.
А ЭТО тебе зачем понадобилось? Какое такое плохое зло случится, если ты добавишь в готовый интерфейс реализацию?
Если это будет реализация НЕвиртуальной функции, для любого, кто имплементировал ранее такой интерфейс, ничего не изменится. Если он работает на уровне указателей, с поздним связыванием, то сможет даже не перекомпилировать свой код. А если у него зависимость от хедера с описанием интерфейса, то его код гарантировано скомпилируется и гарантировано будет работать как надо. Просто будешь сидеть как дурак с мудацким интерфейсом, содержащим реализацию невиртуальной функции.
Если это будет реализация виртуальной функции (вместо =0), для любого, кто имплементировал ранее такой интерфейс, ничего не изменится. Если он работает на уровне указателей, с поздним связыванием, то сможет даже не перекомпилировать свой код. А если у него зависимость от хедера с описанием интерфейса, то его код гарантировано скомпилируется и гарантировано будет работать как надо. Вот если он, увидев появившуюся реализацию, решит схалявить и выкинуть свою, то... интерфейс просто превратится в абстрактный класс. И ничего плохого, опять же, не случится.
А ещё интерфейс это часть контракта, он пишется один раз, очень внимательно, и потом меняется как можно реже, в идеале — никогда. Так что, я бы сказал, это очень надуманная проблема: гарантировать невозможность добавить в интерфейс реализацию. Я многие годы писал на C++/COM. От реализации диспинтерфейсов руками до самописной рефлексии на интерфейсах. И такой проблемы просто нет. Есть проблема, если ты пишешь реализации для позднего связывания и ваш контракт не устоялся, то всё постоянно крашится из-за того, что кто-то не обновился. Но после стабилизации интерфейса проблемы заканчиваются. Даже если тупой джун добавит туда реализацию, да. А если связывание не позднее, если обе стороны, вызывающая и вызываемая, пишутся на основе одного хедера, то сам факт успешной компиляции снимает проблемы.
Я думаю, что необходимость эксплицировать абстрактные классы и интерфейсы вытекает из работы с типами в рантайме (в частности, их инстанцирования). А в крестиках такой необходимости нет.
Но я, возможно, ошибаюсь, и ты мне сейчас объяснишь, зачем гарантировать "невозможность потом добавить в интерфейс реализацию" на C++?
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, vsb, Вы писали:
vsb>Вот эту программу компилятор Swift откомпилировать не может и падает с ошибкой
У меня не падает. Показывает реальную ошибку в коде. И если написать код нормально, то компилируется все мгновенно и работает.
Я читал, что из-за того, что они разрешили overloading и пытаются с ним типы выводить, это приводит к тормозам компиляции. Но сам пока ничего такого не наблюдал, моя программа компилируется супербыстро.
vsb>это никак не исправить, это by design
Если чуть строже язык сделать, убрать кое-какие неоднозначности/оверлоадинг, наверняка можно исправить. Вон в OCaml, Haxe, Elm тот же Хиндли-Милнер вывод типов, и все очень быстро типизируется и компилируется.
Здравствуйте, D. Mon, Вы писали:
DM>Если чуть строже язык сделать, убрать кое-какие неоднозначности/оверлоадинг, наверняка можно исправить. Вон в OCaml, Haxe, Elm тот же Хиндли-Милнер вывод типов, и все очень быстро типизируется и компилируется.
В этом и проблема — в Swift не ХМ, как и в Скале. Скрестить ужа (знакомые ООП фишки) и ежа (вывод типов и implicits за конечное время) пока не получается. Это по мнению Одерски, который в type theory собаку сьел.
Здравствуйте, Sinclair, Вы писали: S>А тут оказывается уже по соседству есть что-то подобное.
А, не, отбой тревоги. Это не те дроиды, которых мы ищем.
У нас протокол — это именно что протокол, соглашение о порядке отправки и приёма сообщений.
Пытаемся решить проблему выразительности интерфейсов. Типа, что файл надо сначала открыть, потом можно из него произвольное количество раз читать, потом надо его закрыть (после чего читать нельзя).
И вот нам надо убедиться, что а) реализация корректно реализует заявленную state machine, и что б) вторая сторона тоже корректно реализует свою часть протокола. И некоторая алгебра над протоколами, которая должна проверять, что некая суперпозиция нескольких протокольных ролей является конформным расширением над некоей заданной протокольной ролью.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Privalov, Вы писали:
P>Фортран и Кобол чем не устраивают? Софт на них работает десятилетиями. Переносится между платформами без особых усилий. Что ещё надо? переносимость фортрана это сказки, иногда оно сделано так что перенести не возможно и будет работать только на избранных компиляторах.
Здравствуйте, Alekzander, Вы писали:
A>Насколько я в курсе, это расширение, которое Microsoft добавил в VC++ ради C++/CLI, и так оно там и осталось. Поэтому и "бы". А если я ошибаюсь и это часть языка, то просьба дать ссылку куда-нибудь в районе cppreference.com.
Господин Музыченко 30 лет живет в уютном мире Windows и компиляторов от Microsoft. Поэтому то, что есть в VC++ для него есть и в C++.
Здравствуйте, Went, Вы писали:
L_G>>Характеристики, которые будут оптимизироваться при разработке такого языка — это его 1) человеко-читаемость и 2) выразительность — по этим показателям он может значительно обогнать существующие ЯП. W>Почему-то мне кажется, что идеальный ЯП вообще не должен символами записываться. Это наследие древности рано или поздно должно уйти, хотя вряд ли это случится скоро.
У меня в школе была учительница математики (м.учительница), которая требовала исключительно символьной записи теорем. С кванторами (∀, Ǝ), конъюнкциями (∧), импликациями (⇒) и т.д. Запись доказательства выглядела примерно так:
А ∈ α ∧ B ∉ α ⇒ a ≡ c
Меня это жутко бесило. Я ей приносил цитаты из Герона, где он ставил и решал задачи гекзаметром, и требовал доказать, что такая запись чем-то хуже.
А потом я вырос и познакомился с теоремой о неполноте, диагональном аргументе, и прочей метаматематике. Оказалось, м.учительница была права. В математике без символов делать нечего, и этому есть объяснение.
А ещё позже я познакомился с такой точкой зрения, что теория вычислений (включающая в себя программирование) это, по сути, изучений следствий ограничения математики законами физики. (Что вычислимо, а что нет, и пр.) Короче говоря, широко распространённая запись программного кода символами это совсем не случайность.
И, кстати, программистский способ символьной записи (плоский, с сокращёнными алфавитами и т.п.) лично мне нравится гораздо больше математического. Одна из причин, по которой мне всегда нравилось программирование и никогда не нравилась математика.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
S>>C++ вроде хорош, но большое легаси. И от легаси не уйти — оно всегда будет просачиваться. Хотя в последние версии добавили и умные указатели и пр. — это уже как бы довесок. Вот если бы они изначально делали язык по этим принципам, не заботясь о совместимости — было бы намного лучше. E>Мне вот интересно, что мешает в 2024-м году для плюсов сделать нормальную систему сборки, нормальную модульность, с репозиториями и версиями.
Ох уж эти меньшинства блэт. Вот почему Сшники не приходят на Go-форумы и не орут — уберите ваши гребаные модули, хотим инклудники как как в сишечке! А вот эти вот прут... со своим уставом...
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Alekzander, Вы писали:
S>>Зато нет ключевых слов для ... абстрактных классов, хотя это полезно
A>Чем полезно? Что тебя не устраивает в абстрактности, выводимой из отсутствующих методов?
Вообще, не понятно, чем так уж полезны ключевые слова.
Вот, например, в Go есть ключевое слово new с семантикой, напоминающей привычную. Но только это не ключевое слово, а встроенная функция. Программист может определить свою функцию new, она будет иметь приоритет в соответствующем скопе. Ключевое слово тут не очень-то нужно.
Более того, даже int в Go — не ключевое слово, а встроенный тип (семантикой, аналогичной Сишному int-у). Можно определить свой тип с таким же именем, опять же, он будет иметь приоритет над встроенным в соответствующем скопе.
В целом, в Си могло бы быть точно так же, и в любом наследнике Си.
Здравствуйте, D. Mon, Вы писали:
DM>Я тут недавно на современный Swift смотрел, вот он реально выглядит как такое усреднение с выбором всего хорошего и отбрасыванием плохого. И ООП есть, и традиционные для ФП фишки вроде алгебраических типов, паттерн матчинга, тайпклассов/трейтов, при этом вместо GC встроенный подсчет ссылок. Памяти ест мало, работает быстро. Вполне себе кандидат.
Быстро посмотрел wiki. Он чем-то от C# отличается кроме нативной поддержки ADT? refcounting GC & llvm AOT это про рантайм.
Здравствуйте, Shmj, Вы писали:
A>>Чем полезно? Что тебя не устраивает в абстрактности, выводимой из отсутствующих методов?
S>А вдруг я забыл добавить?
"Отсутствующий метод" в данном контексте это не дырка в декларации класса, а pure virtual function, т.е. метод, маркированный при помощи = 0;. Например, void foo() = 0;.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
DM>Я тут недавно на современный Swift смотрел, вот он реально выглядит как такое усреднение с выбором всего хорошего и отбрасыванием плохого. И ООП есть, и традиционные для ФП фишки вроде алгебраических типов, паттерн матчинга, тайпклассов/трейтов, при этом вместо GC встроенный подсчет ссылок. Памяти ест мало, работает быстро. Вполне себе кандидат.
Здравствуйте, Alekzander, Вы писали:
A>"Отсутствующий метод" в данном контексте это не дырка в декларации класса, а pure virtual function, т.е. метод, маркированный при помощи = 0;. Например, void foo() = 0;.
Вот в Dart, C#, Java и TS — интерфейс и абстрактный класс — всегда разные сущности. А абстрактном классе так же могут быть все методы без реализации и это, по сути, полный аналог интерфейса. Однако же разница в идее (хотя иногда эту идею портят, как в последних версиях C#).
Делаешь LLM для генерации в несколько более узкую LLM2
Делаешь LLM для генерации из языка LLM2 в еще более узкую LLM3
и уже потом LLM для генерации из LLM3 в CLI/прочийбайткод
Ну а дальше скармливаешь результат конпелятору
Сейчас пробуют в основном делать прямо из LLM в змия образно говоря байткод, но получается фигня
Здравствуйте, Shmj, Вы писали:
A>>"Отсутствующий метод" в данном контексте это не дырка в декларации класса, а pure virtual function, т.е. метод, маркированный при помощи = 0;. Например, void foo() = 0;.
S>Вот в Dart, C#, Java и TS — интерфейс и абстрактный класс — всегда разные сущности. А абстрактном классе так же могут быть все методы без реализации и это, по сути, полный аналог интерфейса. Однако же разница в идее (хотя иногда эту идею портят, как в последних версиях C#).
Причём тут интерфейсы. В чём была бы польза от ключевого слова abstract для классов в C++?
>В C++ есть [...]. Зато нет ключевых слов для ... абстрактных классов, хотя это полезно
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, SkyDance, Вы писали:
SD>Мне тоже понравился. Но не взлетит, т.к. Apple...
Кто-нибудь мне может обьяснить, что в нем нового чего нет в С#, Котлине или Скале. Или после GoLang "Только АOT, JIT не нужен!" считается "крутой" фичей?
Здравствуйте, Alekzander, Вы писали:
A>Причём тут интерфейсы. В чём была бы польза от ключевого слова abstract для классов в C++? >>В C++ есть [...]. Зато нет ключевых слов для ... абстрактных классов, хотя это полезно
Ладно, не так выразился — точнее будет сказать — спец. механизм для интерфейсов, отличающий их от абстрактных классов — и невозможность потом добавить в интерфейс реализацию.
Здравствуйте, SkyDance, Вы писали:
SD>Мне тоже понравился. Но не взлетит, т.к. Apple...
Он уже лет 10 как летит, куча народу где-то его используют (под iOS в основном, видимо), тысячи библиотек уже понаписали. В наш век ни один язык не может так "взлететь", чтобы всех повытеснить. Но при этом масса языков появилась и спокойно кем-то используются, разговоры про "взлет" давно уже бессмысленны. Берешь язык и пишешь. Кто-то вон игры на Beef-lang выпускает, кто-то профессионально на D пишет (как я), кто-то на хаскеле и т.д.
N>Кто-нибудь мне может обьяснить, что в нем нового чего нет в С#, Котлине или Скале.
Ничего.
Основное достоинство заключается не в том, что есть, а в том, чего нет — многих лет всяческого легаси и прочей обратной совместимости.
N>Или после GoLang "Только АOT, JIT не нужен!" считается "крутой" фичей?
А это вообще к языку имеет отдаленное отношение. Деталь реализации рантайма.
Я всё равно считаю, что ООП не нужно. Пишу на Java и ООП использую раз в год. Для раза в год можно и ручками сымитировать что надо. Тем более, что в Rust и сахар для виртуальных методов есть, это не C, где надо таблицы забивать указателями вручную.
Идеального языка я не знаю. В нём должен быть GC и исключения. При этом он должен быть минималистичен и достаточно прост. В целом что-то вроде Java 1.4, пожалуй, максимально близко к идеальному языку из того, что я видел в этом мире, хотя и не совсем то.
Здравствуйте, D. Mon, Вы писали:
S>>Что-то усредненное из этого можно назвать идеальным ЯП для среднего человека. S>>Итого. Идеальный язык мне представляется как Rust, но с полноценным ООП и ...
DM>Я тут недавно на современный Swift смотрел, вот он реально выглядит как такое усреднение с выбором всего хорошего и отбрасыванием плохого. И ООП есть, и традиционные для ФП фишки вроде алгебраических типов, паттерн матчинга, тайпклассов/трейтов, при этом вместо GC встроенный подсчет ссылок. Памяти ест мало, работает быстро. Вполне себе кандидат.
Swift — полное дерьмо, которое сделали идиоты. Они сделали язык, который принципиально невозможно скомпилировать быстро. Там на простейших выражениях компилятор падает с таймаутом и это никак не исправить, это by design.
let firstName = "aaesalamanca"
let age = 27
let message = "Hello, " + firstName + "! You're " + age + " years old."
Вот эту программу компилятор Swift откомпилировать не может и падает с ошибкой "The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions"
Это какой-то позор.
Естественно это не надуманный пример, это сплошь и рядом, от этого любой проект собирается очень долго, IDE тормозит и падает и тд.
Здравствуйте, D. Mon, Вы писали:
DM>Там вместо ООПшных интерфейсов — протоколы, подобные multiparameter type classes из хаскеля или traits из Раста. Когда можно свой интерфейс/трейт придумать и уже существующие чужие типы объявить, что они ему соответствуют, и как именно.
Damn, надо срочно его изучить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, D. Mon, Вы писали:
DM>>Там вместо ООПшных интерфейсов — протоколы, подобные multiparameter type classes из хаскеля или traits из Раста. Когда можно свой интерфейс/трейт придумать и уже существующие чужие типы объявить, что они ему соответствуют, и как именно. S>Damn, надо срочно его изучить.
Как скалист, где все это добро есть лет так 15, недавно перешедший на C#, отсутствие type classеs довольно легко обойти адаптерами и расширителями.
А вот отсутствие ADT(aka "discriminating unions") достает. OneOf конечно неплохой костыль, но не 100% кайф. В F# оно есть, но для простого народа он слишком "другой" и не очень ясен вопрос поддержки.
Спасибо.
Как с tooling в win/linux?
в vscode LSP рабочее?
jupyter kernel?
Что с пакетным менеджером, типа nuget/cargo? В репо библиотеки должны быть под платформу или пакетный менеджер их при установке адаптирует? Там оно все к МаcOS не привязано?
Байндинг к C++?
собирается в ~static linking ехе? если да, то размер helloworld.exe?
Здравствуйте, Shmj, Вы писали:
S>Итого. Идеальный язык мне представляется как Rust, но с полноценным ООП и отсутствием макросов. Т.е. макросы могут быть, но не системные — т.к. это весьма усложняет. В 4-ке лучших языков нет особенной привязки к макросам или вообще их нет.
Фортран и Кобол чем не устраивают? Софт на них работает десятилетиями. Переносится между платформами без особых усилий. Что ещё надо?
Здравствуйте, Shmj, Вы писали:
S>Что-то усредненное из этого можно назвать идеальным ЯП для среднего человека.
Средним ЯП для среднего человека. И этот язык уже есть — называется Java. Для совсем средних людей есть Python. Все остальные языки — некий компромисс между возможностями и рисками/требованиями к программисту.
Здравствуйте, SkyDance, Вы писали:
SD>Ничего. SD>Основное достоинство заключается не в том, что есть, а в том, чего нет — многих лет всяческого легаси и прочей обратной совместимости.
В Scala3 или Котлин легаси еще меньше. Да и в C# "legacy" в основном в библиотеке и не слишком мешает жить.
Идеальный язык программирования по синтаксису будет подмножеством естественного языка (например, английского) с четкой формализацией (исключающей неоднозначности).
И он будет в гораздо большей степени высокоуровневым и декларативным, чем нынешние языки, по сути он будет языком для написания технического задания. Это, конечно, не исключает низкоуровневых императивных возможностей всего инструментального набора. (Будут ли императивные конструкции считаться частью того же языка, или это будет отдельным языком — скорее вопрос терминологии. Думается, будет удобнее их разделить.)
С этим плотно связан еще один вопрос: каким должен быть идеальный компилятор?
Идеальный компилятор будет не просто вываливать сообщения об ошибках — он будет вести диалог на естественном языке, задавая правильные вопросы, позволяющие устранить все возникшие неоднозначности, подсказывая человеку о том, что он вероятно забыл и предлагая от себя возможно важные дополнения (что-то из этого можно будет отключить в настройках). В общем, обычный компилятор будет обёрнут в ИИ-чат. И именно такой компилятор позволит эффективно использовать максимально декларативный язык и ускорить время разработки программы.
К тому же, такой ИИ-компилятор сможет обучать начинающего программиста практически "с нуля".
Но про компилятор — это отвлечение от темы. Обсуждаем язык:
Характеристики, которые будут оптимизироваться при разработке такого языка — это его 1) человеко-читаемость и 2) выразительность — по этим показателям он может значительно обогнать существующие ЯП.
Можно поспорить о том, будут ли людей, использующих подобный язык (+чат-компилятор), по-прежнему называть программистами, но вряд ли стоит сомневаться в экономической эффективности такого подхода.
Здравствуйте, vsb, Вы писали:
vsb>Я всё равно считаю, что ООП не нужно.
Совершенно согласен. Нужен не OOP, а хороший adhoc polymorphism, желательно с multiple dispatch. Решения в Хаскеле и Julia на эту тему есть, те же type classes.
К сожалению нет удовлетворительного решения по auto-complete UI на первый параметр. Тут подумалось, а может просто сделать "сахар"(ака lowering):
x.f(y, z) => f(x, y, z)
Возможно такое даже есть где-нибудь в Хаскел пространстве.
Здравствуйте, novitk, Вы писали:
N>Как скалист, где все это добро есть лет так 15, недавно перешедший на C#, отсутствие type classеs довольно легко обойти адаптерами и расширителями. N>А вот отсутствие ADT(aka "discriminating unions") достает. OneOf конечно неплохой костыль, но не 100% кайф. В F# оно есть, но для простого народа он слишком "другой" и не очень ясен вопрос поддержки.
Не, я не про type classes. Сейчас на основной работе мы активно изобретаем язык, который крутится как раз вокруг протоколов, а не интерфейсов.
А тут оказывается уже по соседству есть что-то подобное.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, L_G, Вы писали:
L_G>Идеальный язык программирования по синтаксису будет подмножеством естественного языка (например, английского) с четкой формализацией (исключающей неоднозначности). L_G>И он будет в гораздо большей степени высокоуровневым и декларативным, чем нынешние языки, по сути он будет языком для написания технического задания. Это, конечно, не исключает низкоуровневых императивных возможностей всего инструментального набора. (Будут ли императивные конструкции считаться частью того же языка, или это будет отдельным языком — скорее вопрос терминологии. Думается, будет удобнее их разделить.)
L_G>С этим плотно связан еще один вопрос: каким должен быть идеальный компилятор? L_G>Идеальный компилятор будет не просто вываливать сообщения об ошибках — он будет вести диалог на естественном языке, задавая правильные вопросы, позволяющие устранить все возникшие неоднозначности, подсказывая человеку о том, что он вероятно забыл и предлагая от себя возможно важные дополнения (что-то из этого можно будет отключить в настройках). В общем, обычный компилятор будет обёрнут в ИИ-чат. И именно такой компилятор позволит эффективно использовать максимально декларативный язык и ускорить время разработки программы. L_G>К тому же, такой ИИ-компилятор сможет обучать начинающего программиста практически "с нуля".
L_G>Но про компилятор — это отвлечение от темы. Обсуждаем язык: L_G>Характеристики, которые будут оптимизироваться при разработке такого языка — это его 1) человеко-читаемость и 2) выразительность — по этим показателям он может значительно обогнать существующие ЯП.
L_G>Можно поспорить о том, будут ли людей, использующих подобный язык (+чат-компилятор), по-прежнему называть программистами, но вряд ли стоит сомневаться в экономической эффективности такого подхода.
Тут возникает проблема с тем, что современный ИИ, показывающий интересные результаты, обучался на огромных массивах готового кода. У меня нет уверенности, что получится сделать ИИ, показывающий похожие результаты с языком, на котором никто ничего не написал.
Здравствуйте, L_G, Вы писали: L_G>Характеристики, которые будут оптимизироваться при разработке такого языка — это его 1) человеко-читаемость и 2) выразительность — по этим показателям он может значительно обогнать существующие ЯП.
Почему-то мне кажется, что идеальный ЯП вообще не должен символами записываться. Это наследие древности рано или поздно должно уйти, хотя вряд ли это случится скоро.
Здравствуйте, Sinclair, Вы писали:
S>Не, я не про type classes. Сейчас на основной работе мы активно изобретаем язык, который крутится как раз вокруг протоколов, а не интерфейсов. S>А тут оказывается уже по соседству есть что-то подобное.
Если type class не интересны, не очень понятно, где ты увидел разницу с интерфейсами того же C#. ИМХО гвоздь именно в периферии: extensions/type classes, union types, mutable и т.д.
Здравствуйте, kov_serg, Вы писали:
_> переносимость фортрана это сказки, иногда оно сделано так что перенести не возможно и будет работать только на избранных компиляторах.
Я лично переносил проект на фортране с ЕС на PC. Работало в ОС ЕС 6.1, СВМ ЕС (ПДО), MS DOS, MS DOS с DOS Extender, OS/2, Windows различных версий. Компиляторы IBM и MS Fortran. У NDP и Watcom нам что-то не понравилось. Ну и я потом на Сях несколько вставок сделал, MS C и MS Fortran оказались хорошо совместимы.
Здравствуйте, Sinclair, Вы писали:
S>Пытаемся решить проблему выразительности интерфейсов. Типа, что файл надо сначала открыть, потом можно из него произвольное количество раз читать, потом надо его закрыть (после чего читать нельзя). S>И вот нам надо убедиться, что а) реализация корректно реализует заявленную state machine, и что б) вторая сторона тоже корректно реализует свою часть протокола. И некоторая алгебра над протоколами, которая должна проверять, что некая суперпозиция нескольких протокольных ролей является конформным расширением над некоей заданной протокольной ролью.
DSL нужен. C# не супер для этих целей, но если вы на dotnet, МSFT делает же всякие blazor/razor. Скала сильно лучше и позволяет делать приличный внутренний DSL, но менять tech stack я бы не стал. Ну или к Владу за Nitro-й
Что касается, где бы стырить идею спеков и алгебры, которые вам нужны, то тут я
Здравствуйте, novitk, Вы писали: N>DSL нужен.
Вот DSL мы и пилим. N>C# не супер для этих целей, но если вы на dotnet, МSFT делает же всякие blazor/razor.
Не, там основатели не верят в управляемые платформы. Так что — суровый натив, плюс мультиагентная среда исполнения с гарантиями доставки и восстановления после сбоев. N>Скала сильно лучше и позволяет делать приличный внутренний DSL, но менять tech stack я бы не стал.
Ну, тут пока что основная проблема — именно что в семантике. Ковыряем потихонечку.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>У нас протокол — это именно что протокол, соглашение о порядке отправки и приёма сообщений. S>Пытаемся решить проблему выразительности интерфейсов. Типа, что файл надо сначала открыть, потом можно из него произвольное количество раз читать, потом надо его закрыть (после чего читать нельзя).
vsb>Тут возникает проблема с тем, что современный ИИ, показывающий интересные результаты, обучался на огромных массивах готового кода. У меня нет уверенности, что получится сделать ИИ, показывающий похожие результаты с языком, на котором никто ничего не написал.
Язык и компилятор для него наверняка будут сделаны без применения ИИ / LLM. Думается, их преимущества могут оказаться значительными сразу.
Поначалу "чат" предполагался как интерфейсная часть компилятора, основная задача которой — сухую суть ошибок компиляции переформулировать максимально понятным человеку языком и сразу предлагать варианты их решения. На первом этапе это можно сделать и на эвристиках, а по мере накопления данных для обучения переделать на LLM (если будет смысл вообще).
Конечно, многим сразу захочется использовать в работе уже привычную функцию ИИ-чата — принимать на входе фразы на человеческом языке и выдавать код на ЯП — но это уже другая его функция. И действительно, отсутствие массивов готового кода для обучения отодвигает возможность реализации этой функции дальше в будущее.
Со временем может стать совсем хорошо: если начинающий программист просто "говорит по человечески", ИИ-чат, угадывая смысл, поправляет его, в результате совместных усилий получается текст на ЯП (на экране перед глазами человека). Так человек будет запоминать все отличия языка программирования от естественного и постепенно научится сразу говорить/писать корректные фразы на ЯП — так-то оно быстрее будет! Но это именно для функции обучения нужен такой ИИ-чат.
А мастеру программирования ИИ-чат поможет едва ли: он будет сразу думать на ЯП и печатать/диктовать почти готовый код. Ему ведь не надо для этого помнить наизусть кучу библиотечных функций — только ключевики и предметную область программы, а синтаксис языка — и вовсе родной, ну почти.
Текущая функция ИИ-чата — переводить краткие ТЗ (на человеческом языке) в длинные простыни императива (с большой вероятностью сочинить полный бред) — с новым языком должна перейти к компилятору: разворачивать НЕПРОТИВОРЕЧИВОЕ ТЗ в императив может и должна строгая логика (без LLM)!
Здравствуйте, novitk, Вы писали:
DM>>Если чуть строже язык сделать, убрать кое-какие неоднозначности/оверлоадинг, наверняка можно исправить. Вон в OCaml, Haxe, Elm тот же Хиндли-Милнер вывод типов, и все очень быстро типизируется и компилируется.
N>В этом и проблема — в Swift не ХМ, как и в Скале.
И там, и там ХМ, просто с наворотами/расширениями.
N>Скрестить ужа (знакомые ООП фишки) и ежа (вывод типов и implicits за конечное время) пока не получается. Это по мнению Одерски, который в type theory собаку сьел.
Потом эту тему еще много раз по-разному пинали, видимо, одного идеального подхода нет. Из недавних интересных подходов — algebraic subtyping Долана, см. например MLscript.
Здравствуйте, Alekzander, Вы писали:
A>Причём тут интерфейсы.
Дык, непосредственно.
A>В чём была бы польза от ключевого слова abstract для классов в C++?
Почему "бы"? В VC++ давным-давно есть и abstract, и __abstract. Очень способствует унификации определений как интерфейсного (абстрактного) класса, так и его реализации, чтобы не выписывать "= 0" при каждой функции интерфейса.
Здравствуйте, Евгений Музыченко, Вы писали:
A>>В чём была бы польза от ключевого слова abstract для классов в C++?
ЕМ>Почему "бы"? В VC++ давным-давно есть и abstract, и __abstract. Очень способствует унификации определений как интерфейсного (абстрактного) класса, так и его реализации, чтобы не выписывать "= 0" при каждой функции интерфейса.
Мне очень понравился диалог на эту тему на StackOverflow.
— Могу ли я использовать ключевое слово abstract при объявлении класса?
— Да, конечно можете. К сожалению, ваша программа после этого перестанет компилироваться.
Прямо какое-то армянское радио.
Насколько я в курсе, это расширение, которое Microsoft добавил в VC++ ради C++/CLI, и так оно там и осталось. Поэтому и "бы". А если я ошибаюсь и это часть языка, то просьба дать ссылку куда-нибудь в районе cppreference.com.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
S>>Ладно, не так выразился — точнее будет сказать — спец. механизм для интерфейсов, отличающий их от абстрактных классов — и невозможность потом добавить в интерфейс реализацию. A>Но я, возможно, ошибаюсь, и ты мне сейчас объяснишь, зачем гарантировать "невозможность потом добавить в интерфейс реализацию" на C++?
Это позволяет разделить работу проектировщика архитектуры и девелоперов/реализаторов.
В C++ в принципе концепция — интерфейс это h-файл, по сути. Который включает в себя еще много всякого. Как бы это легаси ломает простую концепцию.
Здравствуйте, Alekzander, Вы писали:
A>Насколько я в курсе, это расширение, которое Microsoft добавил в VC++ ради C++/CLI, и так оно там и осталось.
Да, сперва добавил abstract в CLR, а затем — __abstract и __interface в обычный режим C++. Я активно пользуюсь.
Еще они давно добавили compiler-supported type traits. Но адекватной условной компиляции так и не сделали, так что во всем этом мало смысла без остальной шаблонной магии.
Здравствуйте, so5team, Вы писали:
A>>Насколько я в курсе, это расширение, которое Microsoft добавил в VC++ ради C++/CLI, и так оно там и осталось. Поэтому и "бы". А если я ошибаюсь и это часть языка, то просьба дать ссылку куда-нибудь в районе cppreference.com.
S>Господин Музыченко 30 лет живет в уютном мире Windows и компиляторов от Microsoft. Поэтому то, что есть в VC++ для него есть и в C++.
Так и я тоже. Некоторые из этих расширений для поддержки интерфейсов кажутся мне весьма полезными. Например, __uuidof.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, so5team, Вы писали:
S>Господин Музыченко 30 лет живет в уютном мире Windows и компиляторов от Microsoft. Поэтому то, что есть в VC++ для него есть и в C++.
Не, господин Музыченко краем уха слышал, что бывают какие-то другие платформы и компиляторы, у него есть даже пара версий GCC, и он иногда ходит на godbolt.
А пример с VC++ показателен тем, что расширения, однажды введенные разработчиками компилятора для собственных нужд, нередко становятся стандартом де-факто. И в стандарты C++ что-то притащили из бывших локальных расширений от Borland, MS и GNU.
Здравствуйте, Shmj, Вы писали:
S>>>Ладно, не так выразился — точнее будет сказать — спец. механизм для интерфейсов, отличающий их от абстрактных классов — и невозможность потом добавить в интерфейс реализацию. A>>Но я, возможно, ошибаюсь, и ты мне сейчас объяснишь, зачем гарантировать "невозможность потом добавить в интерфейс реализацию" на C++?
S>Это позволяет разделить работу проектировщика архитектуры и девелоперов/реализаторов.
S>В C++ в принципе концепция — интерфейс это h-файл, по сути. Который включает в себя еще много всякого. Как бы это легаси ломает простую концепцию.
А что изменится, если ты опишешь интерфейс не в .h-файле, а в модуле? Или даже просто на бумажке? И будешь реализовывать интерфейс в классе, глядя на бумажку?
В C++ интерфейсы это про vtbl. В C# и Java интерфейсы это про данные типа, доступные в рантайме. Интерфейсам на vtbl нужно заполнение vtbl. Данные типа, доступные в рантайме, им не нужны. (Конечно, кроме гуида, имени библиотеки, разных флагов и пр. )
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>В C++ интерфейсы это про vtbl. В C# и Java интерфейсы это про данные типа, доступные в рантайме. Интерфейсам на vtbl нужно заполнение vtbl. Данные типа, доступные в рантайме, им не нужны. (Конечно, кроме гуида, имени библиотеки, разных флагов и пр. )
Здравствуйте, korvin_, Вы писали:
A>>В C++ интерфейсы это про vtbl. В C# и Java интерфейсы это про данные типа, доступные в рантайме. Интерфейсам на vtbl нужно заполнение vtbl. Данные типа, доступные в рантайме, им не нужны. (Конечно, кроме гуида, имени библиотеки, разных флагов и пр. )
_>Какие данные типа.
Type.IsInterface.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>Интерфейсам на vtbl нужно заполнение vtbl. Данные типа, доступные в рантайме, им не нужны. (Конечно, кроме гуида, имени библиотеки, разных флагов и пр. )
Для чего "интерфейсам на vtbl" могло бы потребоваться перечисленное?
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Господин Музыченко 30 лет живет в уютном мире Windows и компиляторов от Microsoft. Поэтому то, что есть в VC++ для него есть и в C++.
ЕМ>Не, господин Музыченко краем уха слышал, что бывают какие-то другие платформы и компиляторы, у него есть даже пара версий GCC, и он иногда ходит на godbolt.
Так давно известно, что господин Музыченко не видит дальше своего манямирка.
ЕМ>А пример с VC++ показателен тем, что расширения, однажды введенные разработчиками компилятора для собственных нужд, нередко становятся стандартом де-факто. И в стандарты C++ что-то притащили из бывших локальных расширений от Borland, MS и GNU.
Но есть нюанс: когда что-то включается в язык (вроде [[likely]]), то это перестает быть расширением. А до того это именно что расширение, которого нет в C++. И тем, кто пишет под несколько платформ, с этим приходится считаться. Но в вашем манямирке этого, очевидно, нет.
Здравствуйте, so5team, Вы писали:
S>тем, кто пишет под несколько платформ, с этим приходится считаться.
Знаете, я об этом как-то смутно догадывался. Но я не считаю, что следует стремиться к тому, чтобы любой код всегда был готов к работе на любой, даже заранее неизвестной, платформе.
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 не ХМ, как и в Скале.
ХМ — это наиболее общий алгоритм вывода и наиболее слабый — плохо подходит в случае перегрузки обычных операторов языка, не подходит напрямую для ООП.
Но его запросто дополняют и продолжают врать, что это ХМ, хотя там уже полно дополнений и ограничений, где типы выводятся к ближайшему общему предку (в Немерле аналогично) и т.д.
Скорее, грамотней говорить просто об автовыводе типов через унификацию в некоем наборе правил этой унификации, а не ссылаться на конкретно ХМ.
Здравствуйте, elmal, Вы писали:
E>Мне вот интересно, что мешает в 2024-м году для плюсов сделать нормальную систему сборки, нормальную модульность, с репозиториями и версиями. И имея эту модульность сделать нормальную УДОБНУЮ библиотеку алгоритмов, пофиг что не совместимую, но чтоб можно было с комфортом писать на этом новые приложения. А то я конечно не сильно слежу, но такое впечатление что с библиотеками и системами сборки все сейчас примерно как 30 лет назад.
Бюрократия мешает и искусственно созданные грабли, которые жалко бросить и тяжело поддерживать.
Здравствуйте, 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, когда к нейронке просто подключают внешнюю базу знаний, а также агентов. И контекст всё больше увеличивают. То есть никто не мешает нейросеть сначала чуть дообучить на новом языке, скормить синтаксис языка с примерами в виде промта, потом дать возможность вызова компилятора и анализатора ошибок. Может и сработать
