2.
Darklight
27
20.10.21 10:40
Сейчас в теме
Прочитал и подумал - зачем?
Ведь в программировании исходники играют далеко не самую важную роль. Куда важнее библиотеки платформы, и конечный код, непосредственно исполняемый платформой (правда у Python или JavaScript его - увы нет - там да - нужна трансляция - это проблема данных языков, хотя для JavaScript можно транслировать "asm.js " или в "WASM", а ещё есть байткод V8; на самом деле и Python тоже есть байткод)
Для решения кросс-платформенных задач есть LLVM и промежуточный язык IR - тут нужно отдельно писать бакэнд/фронтэнд компиляторы.
Увы LLVM не очень хорошо подходит для платформ с управляемой памятью, и для стековых виртуальных машин.
Куда правильнее было - развивать идею LLVM - сделать усовершенствованный IR - более высокоуровневый (как MS IL) - который далле уже можно было бы эффективно декомпилировать в байткод целевых платформ (а не в исходники).
Самое интересное - это как решается вопрос управление памятью. Ведь все названные ЯП (кроме С++) являются языками с менеджером памяти, а JavaScript и Python - ещё и ЯП с динамической типизацией.
Это всё, конечно можно обобщить - но встаёт тогда третий важный вопрос - что будет в итоге с производительностью.
С++ используют - когда нужна высокая производительность - наврядли результирующий код будет ей удовлетворять.
Боюсь - проблем будут и в других результирующих исходниках. А JavaScript и Python и так не обладают высокой производительностью
И последнее. Что-то я в исходном синтаксисе (приведённого примера) ничего особенного не замети - типичный C# - да, возможно где-то есть отличия: что-то просто недореализовано (синтаксис C# очень насыщенный фишками), возможно где-то что-то добавлено (для поддержки совместимости с разными ЯП) - но я не стал бы говорить, что Ć - это новый ЯП, скорее просто диалект C#.
Не буду говорить, что это плохо. C# - мощный язык. Хотя мне он не совсем нравится - как раз из-за наследия С++ - которое полностью перешло и в Ć.
Уж лучше бы Kotlin развивали. У него уже есть и компиляция в Java и в Native машинный-код, и трансляция в JavaScript. Не так уж сложно туда же добавить трансляцию в Python и в .NET IL.
Но это всё-равно не сделает код кросс-платформенным (по среде исполнения) - всё-равно всё упрётся в разные библиотеки - а раз так - какой в этом смысл?
Если уж делать новый ЯП - то делать его революционным - чтобы в нём было что-то что привносит существенную пользу в процесс разработки в процесс исполнения.
Вот как я пропагандирую делать ЯП императивно-декларативным - чтобы на нём описывать лишь обобщённые алгоритмы (не вникая в детали реализации инструкций и функций той или иной платформы и её библиотек) - а уже умный AI -компилятор должен понять что реально нужно сделать - и сгенерировать соответствующий код под целевую платформу обладая знаниями о доступных библиотеках на этой целевой платформе! В том числе проведя его глубокую оптимизацию и , если надо, распараллеливание, и клиент-серверную адаптацию.
Это не простая задача - совмещающая в себе и машинное обучение и алгоритмы оптимизации и параллельного исполнения. Это достойная задача для развития ЯП второй половины XXI века