Для той частной задачи, о которой я говорил в посте, это, может быть, и подошло бы. Но во-первых, не находите ли вы странным, что элементарная задача проверки типов решается в итоге такой внушительной связкой инструментов? Там, где по характеру задач уже нужен другой язык (вероятно, статически типизированный), мы продолжаем загромождать Python свойствами, ему совершенно чуждыми.
А во-вторых, Umka всё же претендует скорее на нишу Lua и Wren, нежели Python. В качестве встраиваемого языка Python слишком тяжёл.
И даёт «Hello World» на 2 Мб? Не всегда это приемлемо. Да и вообще, не замечал какой-то особой быстроты компиляции в Go — ни на своей машине, ни в plagyround'е.
This checking can happen statically (at compile time), dynamically (at run time)
Так что Umka именно статически типизированный язык, в отличие от Lua. Именно этим Lua мне и не угодил: он откладывает проверку типов до начала исполнения программы.
Не очень понял, какой язык я штукатурю. Go? Но ниша совершенно другая, другие и ценности. Я полагаю, статическая типизация полезна во всём, кроме программ в 10 строчек, и её отсутствие практически во всех скриптовых языках удивляет. Дискуссии, на которые я ссылаюсь, заставляют думать, что не меня первого посетило это удивление.
Видимо, вы имеете в виду перенос под LLVM. Вероятно, можно, но зачем? Я хотел иметь маленький и необременительный встраиваемый язык. Go уже и так существует (с весьма громоздким runtime'ом, зашитым в исполняемый файл).
В своё время мне сказали, что «чудо-процедура» быстрее честного рекурсивного спуска. Наверное, в Паскале, где 4 приоритета операций, это не сильно сказывается, а вот в C, где их, кажется, 17, всё гораздо серьёзнее.
Впрочем, я в своём компиляторе делаю обычный рекурсивный спуск. Даже Фабрис Белляр в его знаменитом TCC не стал заморачиваться и сделал то же самое. Хотя ему вообще пришлось всю грамматику C вручную переписывать под рекурсивный спуск, потому что в «официальном» виде она для этого непригодна.
Я бы сейчас дорого дал, чтобы понять, как рекурсивным спуском и без AST изящно разобрать цепной вызов методов. Я у себя добавил к selector'ам скобки с аргументами. Но вышла неприятность. Синтаксис классического Паскаля отлично ложится на семантику: designator всегда означает адрес, factor — значение, а переход от designator'а к factor'у — просто разыменование. Однако когда появляются методы, то они могут вернуть адрес, а могут и просто число. В первом случае это вроде бы designator, а во втором — только factor.
Любопытно, что и в этой книжке есть ошибки. Например, в таблице 7 указано, что MSVC возвращает вещественный результат в целочисленных регистрах. А он это делает через регистр FPU.
Не помогло бы. stdcall отличается от cdecl только ответственностью за очистку стека. Оба соглашения вполне однозначны, пока речь идёт о простейших типах и указателях, и оба погружаются в одинаковый хаос, когда дело касается передачи и возвращения структур.
А, вы предлагаете создать с нуля всю индустрию IT! Благое пожелание. Но если вы пересчитаете эти миллиарды (не миллионы) строк кода в человеко-годы труда, вы, наверное, испугаетесь. Я думаю, выйдет задача лет на 50-60 — то есть именно столько, сколько на самом деле и развивается программирование. А главное, уязвимости всё равно останутся: во-первых, люди по-прежнему несовершенны и допускают ошибки, а во-вторых, есть среди них и те, кто намеренно весь свой талант бросает на поиск и эксплуатацию уязвимостей.
Можно, но это всегда некий намёк на ограниченность того высокоуровневого языка, который мы выбрали. Хотелось бы оставаться в рамках этого языка и иметь под рукой всё, что нужно.
Не совсем понял, что именно вы предлагаете сделать «без оглядки на всякие там Си». Сейчас любой новый язык программирования или компилятор должен уметь взаимодействовать с C, поскольку на C написаны миллиарды строк кода. Кто этого не сумеет — тот точно останется за бортом. Посмотрите, сколько усилий для налаживания взаимодействия приложили, например, разработчики Питона или Go.
Другое дело, что лично мне следовало бы сделать AST и впредь не «переворачивать» стек. Но это лишь одна частная проблема. Все остальные останутся как есть.
А ваш собственный проект сейчас в какой стадии? Если что, здесь в хабе «Компиляторы» много народу с собственными языками и трансляторами (я в их числе). Для вдохновения пошерстите эти публикации. Если вы только начинаете заниматься этой темой, то для более фундаментальной подготовки почитайте классиков (я начинал с гениальной в своей простоте книги Compiler Construction Никлауса Вирта, но может быть, для вас это уже пройденный этап).
Истории выдающихся деятелей, увы, слишком часто вводят в заблуждение: читатель вечно недооценивает степень исключительности этих историй. В истории Безоса (или Маска, или Джобса — кого угодно) не заложено никакого рецепта успеха, применимого для всех остальных. Безусловно, для успеха необходимо решение общезначимой проблемы. Однако если брать за ориентир самого себя, то очень легко ошибиться в оценке масштаба проблемы: касается ли она одного, или сотни, или миллиона человек? Известные лично мне неудачи стартапов были, в конце концов, связаны именно с этой ошибкой: проблему десятка человек воображали проблемой тысяч.
Общезначимость проблемы, решённой Amazon, для меня очевидна. Общезначимость проблемы, решаемой вашим языком, весьма туманна. Нигде даже не было чётко сформулировано, что это за проблема. Обратите внимание: все восхищены вашим мужеством, все признают за вами талант (и я в том числе — мой голос под вашим постом), однако почти никто не заявил, что его проблема наконец решена. Моя — точно не решена, хотя мне очень хотелось бы видеть удобный высокопроизводительный статически типизированный компилируемый язык для математических расчётов.
Пока самые сомнительные для меня решения касаются именно удобства (на вопрос о производительности можно будет ответить только позже и с цифрами в руках):
В дизайне вашего языка — конструкция rules: судя по практике её употребления в самом компиляторе, это очень громоздкий и многословный способ указывать типы аргументов функции.
В компиляторе и среде — поставка программы в виде исходника на C: компилируемый язык мне нужен именно затем, чтобы не носить с собой повсюду компилятор.
В своё время Бертран Расселл говорил о ценности философии: философия нужна не человечеству — философия нужна человеку. К хобби-проектам применимо то же самое. Чтобы преподнести человечеству что-то полезное из области IT, придётся первым делом освоить массу готовых библиотек и фреймворков: если это компиляторы — то LLVM, если игры — какой-нибудь Unity 3D, если нейросети — PyTorch или TensorFlow. Иначе продукт неконкурентоспособен. С течением времени эти библиотеки всё усложняются и дают всё меньше шансов прикоснуться к сути вещей. Я не занимаюсь разработкой игр, но, кажется, сейчас можно сделать игру с хорошей физикой, даже не понимая, что такое тензор инерции и как решать дифференциальные уравнения. А ведь потребность в понимании сути остаётся! Но это потребность конкретного человека, а не человечества — и вот этот человек берётся за свой «ненужный» проект. Не знаю, согласится ли со мной автор публикации (кажется, его амбиции простираются дальше), но моя мотивация всегда была именно такой.
Впечатлён вашей историей. Сам пережил в юности ощущения, подобные вашим, и магия рождения исполняемого файла из пены исходников когда-то заставила приняться за собственный компилятор. Как и вы, восхищался Паскалем, недоумевал по поводу C и мечтал об «идеальном языке». Понятие «идеальности» со временем трансформировалось, теперь самым близким к идеалу кажется Go, так что мой Паскаль постепенно стал приобретать его привкус. Однако самое большое удовольствие я находил в том, чтобы каждый байт моего компилятора был мне как родной, поэтому я с самого начала рассматривал компиляцию только в машинный код — без LLVM IR, C и ассемблера. Я смотрю на свою работу только как на любительскую и потому готов простить себе весьма скверный уровень оптимизации.
Тем не менее, очень хотелось бы вам пожелать получить более фундаментальную подготовку и найти работу, достойную ваших способностей, чтобы ваша история была светлее «Моих университетов» Горького. Увы, любительские проекты почти никогда не получают отклика публики, соразмерного тем усилиям, которые вложил автор. Они — вещь глубоко личная, интимная, а признание в профессиональной среде приходится заслуживать чем-то другим.
А во-вторых, Umka всё же претендует скорее на нишу Lua и Wren, нежели Python. В качестве встраиваемого языка Python слишком тяжёл.
Так что Umka именно статически типизированный язык, в отличие от Lua. Именно этим Lua мне и не угодил: он откладывает проверку типов до начала исполнения программы.
Впрочем, я в своём компиляторе делаю обычный рекурсивный спуск. Даже Фабрис Белляр в его знаменитом TCC не стал заморачиваться и сделал то же самое. Хотя ему вообще пришлось всю грамматику C вручную переписывать под рекурсивный спуск, потому что в «официальном» виде она для этого непригодна.
Я бы сейчас дорого дал, чтобы понять, как рекурсивным спуском и без AST изящно разобрать цепной вызов методов. Я у себя добавил к
selector'ам скобки с аргументами. Но вышла неприятность. Синтаксис классического Паскаля отлично ложится на семантику:designatorвсегда означает адрес,factor— значение, а переход отdesignator'а кfactor'у — просто разыменование. Однако когда появляются методы, то они могут вернуть адрес, а могут и просто число. В первом случае это вроде быdesignator, а во втором — толькоfactor.Другое дело, что лично мне следовало бы сделать AST и впредь не «переворачивать» стек. Но это лишь одна частная проблема. Все остальные останутся как есть.
Общезначимость проблемы, решённой Amazon, для меня очевидна. Общезначимость проблемы, решаемой вашим языком, весьма туманна. Нигде даже не было чётко сформулировано, что это за проблема. Обратите внимание: все восхищены вашим мужеством, все признают за вами талант (и я в том числе — мой голос под вашим постом), однако почти никто не заявил, что его проблема наконец решена. Моя — точно не решена, хотя мне очень хотелось бы видеть удобный высокопроизводительный статически типизированный компилируемый язык для математических расчётов.
Пока самые сомнительные для меня решения касаются именно удобства (на вопрос о производительности можно будет ответить только позже и с цифрами в руках):
rules: судя по практике её употребления в самом компиляторе, это очень громоздкий и многословный способ указывать типы аргументов функции.Тем не менее, очень хотелось бы вам пожелать получить более фундаментальную подготовку и найти работу, достойную ваших способностей, чтобы ваша история была светлее «Моих университетов» Горького. Увы, любительские проекты почти никогда не получают отклика публики, соразмерного тем усилиям, которые вложил автор. Они — вещь глубоко личная, интимная, а признание в профессиональной среде приходится заслуживать чем-то другим.
Удачи вам!