TypeScript Native (AOT) Compiler

сколько стандартов с/с++ поддерживают актуальные компиляторы одновременно?

а жалобы, что поддержку c89 нужно срочно набрить ибо сложно, слышал?

а жалобы, что gcc9 стал сильно больше в размерах, чем gcc4?

я вот тоже не слышал, очевидно всех всё устраивает. а ведь спецификации крестов куда более внушительные, чем у js

Я могу попробовать ответить на вопросы, если кому все же интересна эта тема…

Каковы успехи проекта спустя несколько месяцев после пре-альфы? Есть ли подвижки, что нового, как оцениваешь перспективы, не планируешь ли бросить?

Успехи:

1. компилятор уже может компилировать сложный код. (можно глянуть в test папку там, где-то 310 тестов (и это только вершина айсберга)

2. «Генерики» доделал. вот такой код работает «let sum = [1, 2, 3].reduce((s, v) => s + v, 0)». Несмотря на простоту кода под капотом это достаточно сложный код, который требует «генерики» и определение типов для специализации функций.

3. есть пример как объединить код с TypeScriptCompiler и С++ код. в "TypeScriptCompiler\docs\how\cmake_vulkan". Т.е. есть базовый пример vulkan и WinApp код на TypeScript.

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

5. перспектива достаточно хорошая т.к. большинство кода уже компилируется есть даже await/async.

6. Следующее по плану — это «геренили-лямбды» и «import», улучшение GC, и все - компилятор готов. Компилятор походу будет долго в альфе пока не сможет компилировать ну относительно большой и сложный код. проблема с этим что все TS проекты это JS код, который больше ориентирован на динамический код. А мой компилятор не позволяет использовать динамику (я так решил) что буду компилировать только тот код, который не требует «run-time» информации в коде.

Раскрутка компилятора это традиционный способ доказательства его работы. Планируется ли в будущем переписать компилятор на TypeScript?

Видел автора на govnokod.ru

Все видели. Он там и пиарился до того, как опубликовали статьи на хабре\опенете.

нет не планирую. т.к. LLVM дает хорошую функциональность. Так же кол-во времени и ресурсов на это минимум. Поэтому будет имплементация только очень важных и нужных частей.

Появились ли у твоего проекта пользователи, дающие обратную связь? Как оцениваешь их количество?

Что с контрибьюторами? Кто-то присоединился к проекту после того, как ты о нем заявил?

Как ты сам оцениваешь степень сложности для стороннего разработчика влиться в проект?

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

Ну и как же оно станет популярным без фронтенда?

есть даже await/async.

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

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

2. пока никто не проявил желания как-то помогать…

3. сложности для стороннего разработчика есть, но самые сложные участки разработки уже сделаны.

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

а какой фронтенд был у D? или Rust?

предлагали деньги за ускорение заработки (чего я не мог дать)

Много предлагали? Не было предложений или околотого на полную ставку работать только над компилятором за зарплату?

Ну так популярен то electron...

нет не много

Понял.

Ну, будут новости, релизы, оформляй в топик и пости в специальный раздел https://www.linux.org.ru/news/

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

Прикольная штука. Как вы пришли к этому, что было бы круто запилить вот такой продукт? :)

Я правильно понимаю, что это получается эдакий электрон, только без HTML, CSS и браузера?

это получается эдакий электрон, только без HTML, CSS и браузера?

Нет, это проект вообще из другой плоскости. Электрон - это рантайм управляемый скриптовым языком. Сабж - это ahead-of-time компилятор статически-типизированного суперсета js в исполняемый машинный код.

Почему на С++, а не на TypeScript?

Вау, преальфа!

забыл про кол, святую воду, соль и известь :)

Я даже не спрошу, почему ты не спрашиваешь «почему не на rust?»

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

А-а-а, понял. Это не очередное надмножество.

Не, ты не понял. Все компиляторы должны быть написаны на rust :) И в итоге все языки не нужны, только божественная и безопасная растишка :) Ты что, против прогресса? :)

Ээээ... Т.е. PostScript - никчёмный язык? Ну и не знаю, существует ли компилятор пролога, написанный на прологе...

Не, ты не понял. Все компиляторы должны быть написаны на rust :) И в итоге все языки не нужны, только божественная и безопасная растишка :) Ты что, против прогресса? :)

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

Ээээ… Т.е. PostScript - никчёмный язык? Ну и не знаю, существует ли компилятор пролога, написанный на прологе…

Я про полноценные языки программирования. Ты меня ещё про компилятор CSS на CSS спроси.

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

это потому что не на rust написан :) Смотри с чем он согласен TypeScript Native (AOT) Compiler (комментарий) (я вот не согласен, но сам факт :))

сколько стандартов с/с++ поддерживают актуальные компиляторы одновременно?

а жалобы, что поддержку c89 нужно срочно набрить ибо сложно, слышал?

а жалобы, что gcc9 стал сильно больше в размерах, чем gcc4?

я вот тоже не слышал, очевидно всех всё устраивает. а ведь спецификации крестов куда более внушительные, чем у js

Справедливости ради и жалобы есть и поддерживают не всё.

Например, текущий Visual C++ поддерживает только С++14 и новее.

И есть просьба в Visual C++ 2025 поднять минимальную версию до С++20, но это ещё должны одобрить менеджеры…

И да, если бы было можно забить на поддержку старых версий стандартов, то это бы сделали и в gcc и в clang…

Я про полноценные языки программирования. Ты меня ещё про компилятор CSS на CSS спроси.

Так CSS Тьюринг полный. Так что тут уточнять нужно нормально, а не просто накидывать.

Т.е. PostScript - никчёмный язык?

нет, PostScript – не никчёмный. можно запилить анимацию.

вообще, если ты понимаешь суть форта (например, читал книгу Лео Броуди про структурное программирование «Форт как образ мышления») – то легко понимаешь суть постскрипта.

постскрипт это форт со сборкой мусора, строками, словарями (хеш-таблицами), на котором легко и невозбранно можно запилить разновидность ООП, например, как это реализовано в Display PostScript (с си коллбеками).

в целом, на постскрипте можно писать вполне себе цельные программы. например, нечто про литературное программирование есть целиком на постскрипте == ibis.ps (примерно там же, где реализация Display PostScript :luser-dr00g, там например).

• pcomb – парсер комбинаторы на PostScript

• xpost – альтернативная реализация интерпретатора PS (альтернативная GhostScript-у), ещё он где-то рядом пытался Display PostScript интерпретатор писать

• mandelbrot.ps – сабж

• debug.ps – отладчик ps на ps

• pstut – ps tutorial

• ibis.ps – аналогично lout, scribe, tex

ps-wasm

lout (который похожий на tex, только 3.5 Мб бинарник и ~30Мб с метриками шрифтов вместо 1+Gb для tex/latex) – в основном написан на postscript в функциональном стиле.

addfont – конвертация TTF шрифтов в PS Type1 (хотя есть и Type42,unicode – например ttf2pscid2).

ps-HTTPD – веб-сервер на PostScript advent_of_code_2021 на ps

в общем, ps – полноценный язык программирования. Factor немного более функциональный про монады ооп в стиле clos и комбинАторы, но и ps (или display postscript) вполне нечего.

psutils – библиотеки на ps

оконная система NeWS или тут , NeXT (на Objective C со SmallTalk моделью ООП), backbone – там были/есть реализации Display PostScript

кстати, в сайте автора NeWS, в статьях вот тут есть например описание метацикличного интерпретатора дисплюй постскрипта на нём самом

HyperLook, я щитаю – была вообще бомба, очень продвинутая библиотека виджетов на DPS.

заметь, что любое приложение могло распечатать скриншот на DPS, редактировать ресурсы в запущенном приложении, копипастить диалог как виджет в ресурсы объектов объектно-ориентированного Display PostScript.

даже SimCity на этом вот написали.

Ну и не знаю, существует ли компилятор пролога, написанный на прологе…

разумеется, существует. более того, он (метациклический интерпретатор пролога на прологе) гораздо проще чем лиспа!!

если ты изучишь сайт Markus Triska, https://www.metalevel.at/ – там ты невозбранно отыщешь желаемое.

например, про метациклические интерпретаторы

интерпретаторы более других языков – не сильно сложнее, alzint, lisprolog

ты спрашивал про компиляторы – но компиляторы на прологе пишутся не сильно сложнее, например читай про DCG грамматики для парсера DCGprimer , читай про tist

у того же SWI-Prolog есть реализация емакса на прологе, пакетного менеждера.

кажется и LLVM привязки тоже есть. что-то вроде wasm генерации вроде бы тоже было, по крайней мере аналог jupyter notebook для swi prolog точно есть.

хотя с реализациями WAM vm машины на лиспе или схеме ещё проще интегрировать что-то с чем-то, через лисп. но в целом, и реализация лиспа на wam тоже есть.

метапрог диаграммный, finomaton/ – рисовалка конечных автоматов на tcl/tk, c экспортом в ps/pdf/tex/metapost.

эх, Шалыто со SWITCH-технологиями на вас нет! а то давно бы уже написали метапрог дисплейпостскриптовый, невозбрано достигнув желаемого.

а то переизобретают хипстоту какую-то вместо действительно нужных технологий, того же Display PostScript например. или ядра LogicMOO на прологе.

разумеется, существует. более того, он (метациклический интерпретатор пролога на прологе) гораздо проще чем лиспа!!

метациклический интерпретатор лиспа на лиспе – 11 строк «сам на себе»

метациклический интерпретатор пролога на прологе – от 4 строчек.

кстати, ты будешь смеяться. но кажется я где-то видел реализацию Display PostScript на JS, через WASM, кажется.

тормозит, разумеется – в отличие от честной standalone реализации отдельного дисплюй сервера.

вот её бы и AOT конпелятором было бы отконпелировать не грешно

немного про InterPress, конкурента PostScript

а вот например про формат Scribe – дальше есть например лисповый skribilo на GNU Guile, и/или Common Lisp реализации с вариацией разметки на основе S-выражений.

ссылка взята отсюда: ibis.ps – судя по мануалу в ibis.pdf, ibis.ps поддерживает разновидность разметки Scribe.

ну прям какой-то метапрог метацикличный, сам на себе. литературно-грамотный.

только на форте, ну то есть – постскрипте.

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

то есть, это занятная компактная реализация вроде troff/ groff/neatroff + PIC, только на чистом постскрипте.

постскрипт это форт со сборкой мусора, строками, словарями (хеш-таблицами), на котором легко и невозбранно можно запилить разновидность ООП, например, как это реализовано в Display PostScript (с си коллбеками).

а формат PDF если читать спецификации – это бинарная база данных, на основе словарей и метаданных.

на этом, теоретически, можно было бы запилить эдак невозбранно штуку для Display PDF , аналогичную апплетам на яве. ну или wasm апплетам на жаваскрипте.

то есть: хранить .exe файлы бинарники в pdf-ах, и сразу бинари исполнять, декодируя из промежуточных форматов.

линкер бы в такие бинарные PDF заметно упростился бы.

а кстати, если читать спецификацию PDF 1.4 и выше, с поддержкой JavaScript форм и валидаций.

там можно было полноценные JS объекты в PDF бинари запихнуть. или аналог флеша с ActionScript-ом запилить.

или некоторый условный метапрог метациклический, сам на себе

также воистену удивительно, что взлетели вариации реализаций жопоскрипта, а не какая-нибудь Kaleida ScriptX

про Scribe и MINCE, реализацию клона емакс со встроенной разметкой Scribe

portable MINCE: pmince

у него в репозиториях также много других исторических артефактов вроде NeXT DPS сервера или емакса v18 под NeXT DPS

жму/линукс здесь при том, что

Time-bomb Reid agreed to insert a set of time-dependent functions (called «time bombs») that would deactivate freely copied versions of the program after a 90-day expiration date. To avoid deactivation, users paid the software company, which then issued a code that defused the internal time-bomb feature.

Richard Stallman saw this as a betrayal of the programmer ethos. Instead of honoring the notion of «share-and-share alike», Reid had inserted a way for companies to compel programmers to pay for information access.[9]

то есть, жмотство автора изначального Scribe сподвигнуло Столмана на реализацию своего форка Texinfo.

подозреваю, что жмотство авторов драйвера для принтера – тоже, возможно, завязано было на какой-то проприетарный PDL. а не только какой-то HDL и описание RTL.

что и сподвигло Столмана косвенно на проект GNU.

вот читаю например про сравнение Interpress и PostScript. а рядом есть такой интересный CPDS и некоторый «DDL: A Language to Describe Documents», Imagen Corporation 8/86 – судя по правой колонке таблицы со сравнениями, всем лучше их обоих трёх.

так почему об этом PDL мы толком ничего не знаем, кроме его названия? PDF по ссылке тоже не проясняет.

… занятная это штука – цифровая археология

test.mss – да, это он. Scribe, как он есть.

craft The Craft of Text Editing –or– Emacs for the Modern World

ого… сколько прошло времени уже с момента начала…