Как и любой программист, я одновременно и мечтаю, и страшно бо | Стой под стрелой
Как и любой программист, я одновременно и мечтаю, и страшно боюсь момента, когда начну писать свой язык программирования. Но язык — не библиотека, спешки не любит, поэтому идеи для него я собираю неспеша. Вот некоторые из них.
Во-первых, это явно будет не язык, а полный стек разработки. Сборка, управление зависимостями, деплой, мониторинг — все будет встроено сразу. Чтобы можно было написать десять сточек бизнес-логики, нажать кнопку и получить работающее приложение сразу, а не нанимать на месяц девопса. Просто потому что по-другому мы уже пробовали и по-другому не работает.
Почти наверняка этот язык не будет соревноваться с C или Rust, потому что — а смысл? Эти языки уже есть и задачи свои решают. Хочется пробовать то, чего еще нет.
Во-вторых, он будет интернет-ready. То есть каждая функция будет иметь уникальный во всем мире идентификатор и зависимости будут тоже per function. Как js-пакет из одной функции типа is-color-red, только без вот этого вот кошмарного оверхеда на деплой и обслуживание. Написал import tonsky/str-concat; и у тебя сразу эта функция доступна.
Ну и иммутабельно это все будет, конечно. Нужно что-то поправить — выпускай новую функцию. Иначе не взлетит.
В-третьих, понятно, свой редактор. С одной стороны «код — это текст» я конечно уважаю и понимаю, что еще ни один язык с кастомным редактором не взлетел. Но с другой стороны, столько вещей, которые тупо нельзя сделать, если жить в предположении, что кто угодно может как угодно в любой момент изменить ваш исходник внешними средствами.
Самое простое — CRDT-based версионирование. На плоских файлах тупо не делается, а выгоды сулит огромные. Посимвольный blame, например, гарантированный автоматический мерж (и анмерж), ну и понятно Google Docs-лайк коллаборация.
Другая моя давняя мечта — картинки в комментариях. Многие вещи ГОРАЗДО проще нарисовать, чем описать словами, однако текстовость файлов мешает. Как минимум редактор диаграмм надо будет точно встроить. Прикиньте — рисовать нормально, а не ASCII-графикой?
Разные шрифты, чтобы можно было, например, выделить болдом что-то важное. Но тут надо будет подумать, как не дать слишком много контроля программистам, потому что с визуальным вкусом могут быть вопросики.
Ну и наконец можно будет сделать красиво. Нормальные юникодные операторы (π, ≠, ¬, ∧, ∨) вместо этой дурацкой псевдографики >>=, типографские кавычки для строк (да, открывающая и закрывающая кавычки будут разными!). Табы, опять же, убрать. Как и пробелы Выравнивание сделать семантическим, а не захардкоженным десятью нажатиями на самую длинную клавишу на клавиатуре.
Возможно, социальные фичи типа комментариев от других людей и таск трекинга прям в коде. А почему нет? У писателей это все есть, у дизайнеров есть, причем для них это сделали программисты. А сами себе мы почему не можем сделать то же самое?
В-четвертых, мнгновенная реакция. На все — изменения, импорт зависимостей, сборку, деплой. Никакого ожидания «пока скомпилируется». Да, возможно, какая-то часть перформанса останется на полу, но оставшейся, я уверен, хватит с головой.
Ну и REPL, конечно, куда без него. «Редактирование наживую». Перезапускать программу, чтобы тупо посмотреть, правильно ли ты там что-то поменял — ну, такое. Удовольствие для терпеливых.
В-пятых, база данных будет прямо в стандартной библиотеке. Потому что она ну все равно нужна всем, а настраивать, подключать, сериализовывать-десериализовывать, конвертировать между реляционным и объектным представлением... Я лично устал. Не вижу смысла.
Представляете, в каком светлом мире мы бы жили, если бы в линуксе каждый сервис не хранил свой конфиг в уникальном как снежинка текстовом формате, а пользовался бы единой SQL-базой? Углеродный след раза в три бы уменьшился по всей планете, а освободившиеся админы связали бы каждому живущему человеку по два шарфика за это время.
А, ну и массивы будут индексироваться с единицы, конечно же. Или нет. Пока не решил.
Короче, как видите, работы много, так что я пойду и дальше мечтать. Привет.
