Comments 66
А зачем? Если для души, то ок.
Если для серьезного использования, то нужна причина. Каждый язык популярен не просто так, а потому что он лучше других в какой-то области
"Кастомный синтаксис" — это так себе преимущество. И что значит "кастомный"? Прям совсем уникальный? А если не совсем, то это, само по себе, не отличительный признак.
Подобие Forth?
Уже было нечто подобное для .NET. Назывался язык Nemerle. У него одно время даже было довольно большое комьюнити (http://nemerle.org). Выше концепта так по большому счету и не взлетел. Не всем нужен кастомный синтаксис. Далеко не всем.
Компилятор не умеет считать «по головам»?
Не зайдёт. Как можно напрягаться программировать, когда язык почти каждой строкой предлагает тебе расслабиться?
Честно говоря, выглядит, как клон MSIL. Влияние сильно чувствуется.
Вообще, многие хобби-проекты мало чем отличаются друг от друга; зачастую авторы занимаются откровенной вкусовщиной и много времени уделяют каким-то совсем уж малозначимым вещам, в итоге всё это небольшие вариации на тему одного и того же. Чтобы язык получил распространение, нужно в него добавить какую-то фишечку.
Что я понимаю под фишечкой: напр. у меня вот давно зреет идея хобби-проекта, где на уровень языка были бы внедрены вещи вроде bounded contexts, application layers (проверка нарушения слоев в компайл-тайме, например), dependency injection, multitenancy (изоляция памяти между тенантами) и прочие энтерпрайзные штуки. Совр. мэйнстримовые языки поддерживают такое на уровне фреймворков, было бы интересно попробовать перенести это на уровень рантайма в качестве эксперимента. Реализовать можно, но не хватает времени
В Rust такой фишкой является уникальное управление памятью, в Go — горутины и каналы, и.тд.
Что значит "кастомный синтаксис"? Возможность строить свои DSL? Это уже было бы интереснее.
Ну вот ваш пример про main это как раз то, что я писал выше про вкусовщину/малозначимые вещи. Опытному программисту скорее интересны семантика и тулинг, чем просто синтаксис. А новичок вряд ли пойдет пробовать непопулярный эзотерический язык. Добавьте в проект уникальную фишку, которая не является ещё одной вариацией синтаксиса. Удачи вашему проекту.
Это когда уже которое поколение программистов набив шишки пытается заставить всех кодить одинакого. Если для души — то круто, саморазвитие. Но со стороны перспективы, пока что — недостатки выдаваемые за преимущества
Прежде чем продолжать рекомендую ознакомиться с другими подобными статьями и комментариям к ним:
Relax'у всего лишь полтора месяца, а он уже такое может. Он будет развиваться еще долго. Но даже сейчас можно писать простенькие консольные программы.
Почти ничего, если это, конечно, не учебный язык. Моя лаба по реализации компилятора тоже такое умела.
А зачем?
Зачем в 2к21 писать свой бекенд? Возьмите LLVM. Генерируйте MSIL, если так хотите VM. Возьмите бекенд от gcc. Генерируйте C код, в конце концов.
Нельзя самостоятельно догнать такие крупные решения по производительности, увы.
Вспомнилось: ещё в студенчестве, в 90х, был одногруппник, который мечтал создать нечто вроде расширяемого ассемблера на котором можно было бы свои структуры и т.п. писать. То есть супер-расширяемый. Так же по планам было в 2000х низвергнуть С и остальные языки, чтобы все писали только этом конструкторе :) Но что-то не выстрелило. Хотя, насколько помню он проект довольно быстро свернул. Хотя звучало грандиозно.
Этому миру нужно больше языков программирования!!! Больше!!! С кастомным и нескучным синтаксом! И чтобы один и тот же loop можно было написать 100500 способами! Чтобы олимпиадники соревновались за сколько букав они напишут этот код.
ЗЫ теперь попросите гугл или фейсбук запилить какой-нибудь проект на релаксе — дальше хомячки сами подтянутся. Качество, так то, вторично.
Например так в одном решении примера:
: triangle ( n — )
1+ 1 do
cr i 0 do [char] * emit loop
loop;
5 triangle
*
**
***
****
*****
Можно ли будет в этом языке грабить корованы?
Оно очень похоже на wat представление WebAssembly.
(func (param i64) (result i64)
local.get 0
i64.eqz
if (result i64)
i64.const 1
else
local.get 0
local.get 0
i64.const 1
i64.sub
call 0
i64.mul
end)
Мне вот интересно, зачем автора минусуют почти в каждом комменте. Человек с энтузиазмом разрабатывает свой проект, реализует задумки, наступает на грабли и получает опыт. Это же здорово.
Потому что нет возможности минусовать администрацию.
Очередной новый язык на Хабре, очередное линчевание новичка сообществом, а админы не почешутся. Можно ведь попытаться направить очередного экспериментатора в специальный хаб, например. Или инструкцию выдать со стандартными вопросами про язык, шаблон.
Ты и комментатор ниже ошиблись веткой, да? Если нет, то его ответ отвечает на вопрос.
Заглядывал на compiler.su?
Мне не понравилась, что в начале не указана цель создания нового языка — а без этого язык выглядит очередным велосипедом, а статья производит негативное впечатление. А так против новичков и их велосипедов ничего не имею против.
Лично я минусовал по двум причинам:
— в надежде, что человек задумается «а почему минусуют, что не так?»
— однообразные комментарии, похожие на копипасту слов из статьи и соседних своих же комментариев.
«Критикуя предлагай»: Гораздо лучше найти наиболее близкий по духу/идее/итд проект и помогать его развитию. И с точки зрения достижения результата (этим будет пользоваться кто-то еще), и с точки зрения получения опыта, и с точки зрения разобраться, и с еще кучи других аспектов, вплоть, до улучшения мира в целом.
Но я не понимаю вашего вопроса «зачем?». Ровно как и не понимаю зачем вообще создавать новый язык в 2021 году.
Язык — это инструмент. Зачем еще один инструмент, ни из статьи ни из ответов не понятно.
Поэтому простой короткий вывод — не зачем. И простая короткая рекомендация — прежде чем делать что-то совсем новое, попробуйте разобраться с чем-то, что уже используют люди. У всего есть недостатки, и того, что open source, есть возможность недостатки исправить. Это гораздо более достижимая цель, которая даст гораздо больше общей пользы, чем убить кучу сил и времени на новое, никому ненужное произведение.
Если только ограничиваться крошечными пулл-реквестами в существующие проекты, и не создавать чего-то действительно своего, далеко это не приведет в плане профессионального роста. Главное, чтобы был напарник для код-ревью (желательно более опытный), чтобы не застрять в собственном информационном пузыре.
Велосипедостроение — двигатель прогресса.
«но есть нюанс».
Я бы сказал, что в общем случае — нет. Можно сделать 100500 велосипедов, так ничему и не научиться. А в тяжелом случае, еще разбить себе лоб, в ходе испытаний очередной кривой самоделки.
Двигатель прогресса — человек, который разобрался в теме лучше/глубже, чем все, кто брался за эту тему до него. На мой взгляд, не принципиально, он смог это только за счет целеустремленности или посмотрел на задачу с нового ракурса. Важно, что сделал лучше.
Главное, чтобы был напарник для код-ревью (желательно более опытный), чтобы не застрять в собственном информационном пузыре
Допустим. Как найти опытного напарника на ревью реализации нового языка?
ой, подождите… Если отправить пулл-реквест в уже существующий проект, его обязательно кто-то посмотрит, и скорее всего, это будет более опытный разработчик?
Не спорю, что пулл-реквесты в существующие проекты — хорошая идея. Но и категоричное "делать собственные проекты — пустая трата времени" удивляет.
Оглянитесь вокруг — есть много, нет МНОГО языков. Популярные, можно пересчитать по пальцам на руках. За каждым из них — большая история, и если переводить в человеко-часы, вообще сложно оценить.
Посмотрите молодые (5-6 лет) растущие языки, с чего они начинались, и на каких усилиях они растут. Всё это, если не прямо сейчас, то очень скоро начнет «давить» не энтузиазм начинателя нового языка.
Начинать новый проект языка — лучший способ просрать (простите) весь энтузиазм. Что может быть хорошего, когда человек выкидывает свой самый ценный ресурс — время?
Тут поподробнее. Написание своего языка это очень хороший практический пример для новичка, т.к. затрагивается большое число тем из CS; заставляет задуматься о структуре проекта, т.к. есть делимые части (фронтенд/ бэкенд, токенайзер/лексер/парсер, рантайм/компайлтайм) а это уже заставляет задуматься в сторону архитектурных вопросов. При этом есть поле для творчества (можно добавить в язык экспериментальных интересностей). И в итоге можно получить удовлетворение в том плане, что язык юзабельный и в принципе может решать реальные задачи.
Лично я минусовал по двум причинам:
— в надежде, что человек задумается «а почему минусуют, что не так?
Не думаю, что это так работает. По крайней мере, не для всех. Именно такие минусы и убивают энтузиазм.
Наверное, это у меня такая проф.деформация, и слишком много по жизни приходилось копаться в чужом коде, который вроде работает в каких-то частных случаях, но выглядит отвратительно, что если через год-два-три изменяются требования, то возникает вопрос — нам действительно будет дешевле модифицировать «вот это»?
затрагивает большое число тем CS— это основная проблема для новичка. Это как «можно сделать хорошо, быстро, недорого — выбирайте любые два». В случае новичка — будет чудо, если у него получится хотя бы одному из трех требований удовлетворить. Поэтому, я убежден (никому не навязываю, но считаю важным озвучить) — если основная цель «научиться. разобраться, понять» — нужно взять уже что-то хоть в каком-то виде цельное-живое-рабочее, брать по «одной теме CS», и модифицировать это самое живое рабочее, разбираясь, почему границы между бекенд/фронтенд в этом случае провели именно так, почему лексер именно так написан, почему грамматика такая, когда их вон сколько разных?
При таком подходе, шансы того, что хоть в какой-то теме получится разобраться гораздо выше, чем если перед глазами десяток тем, и любой шаг вправо/влево, ломает весь мир.
Не думаю, что это так работает. По крайней мере, не для всех. Именно такие минусы и убивают энтузиазм.А как это работает? Если человеку хочется писать код, хочется, что бы код запускался — ему не нужен Хабр, ему вообще никто не нужен.
Как только возникает мысль кому-то рассказать — это один из способов получить какой-то взгляд со стороны. Вот такой взгляд со стороны получен.
Добро пожаловать в реальный мир
Наверное, это у меня такая проф.деформация
Вполне возможно. Например, программирование может быть просто хобби (повод поучиться, поразмышлять и найти единомышленников), необязательно рассматривать каждый проект как очередной недоделанный мвп-высер, который нужно срочно в продакшн (поэтому нет времени на все эти ваши велосипеды). Проекту необязательно уходить в прод, иначе не было бы такого понятия, как research project.
В целом, соглашусь, что для совсем зеленого новичка полезно участвовать в уже существующих проектах. Но если уже какой-то опыт набран, не вижу никакой проблемы начать делать собственный проект, оглядываясь на примеры из похожих проектов. Это очень ценный опыт разработать полный стек системы с нуля, дает очень глубинные, не поверхностные знания, и прививает некоторую самодисциплину. Опыт на собственных ошибках ценнее опыта чужого. Если взять автора статьи, видно, что он сильно вдохновлен MSIL/.NET. Т.е. у него уже есть перед глазами пример "как делать правильно", исходный код открыт.
Еще есть такой момент, что да, с одной стороны, человек может тратить время, выдавая очевидную ересь, и даже не знать об этом. С другой стороны, если у человека вообще нет опыта в "пробе пера" с нуля без оглядки на чужие готовые решения/шаблоны (в других проектах), в любой нетривиальной ситуации такой человек попадет в замешательство (шаблона-то нет!), и такой человек вряд ли будет выдавать новые интересные инженерные решения. Но, возможно, это и не каждому дано. Поэтому не судите да не судимы будете :)
Человек написал статью на популярном ресурсе — для меня это означает, что попросил обратную связь. Я эту обратную связь ему даю, да и вы, по сути делаете то же самое.
Это очень ценный опыт— «опыт, это то, что ты получаешь, вместо того, что хотел». Применяя к текущей ситуации — хотел сделать супер-пупер инструмент, а получил опыт.
Опыт на собственных ошибках ценнее опыта чужого.— кроме тех случаев, когда собственная ошибка приводит к гибели.
Применяя к текущей ситуации — «гибели» заметного количества времени и сил, вложенных в такой проект.
Мой вывод на основе той информации что я вижу простой: свой проект в текущем виде остановить, найти наиболее близкий по вкусу живой проект и прикладывать усилия туда.
Если цель проекта в первую очередь «получить опыт», то участие в живом проекте, позволит достингуть этой цели меньшими затратами, с высокой вероятностью опыт будет «более полезный».
В качестве бонуса будет то самое необязательное «проект в проде», откуда можно будет зачерпнуть очередную порцию энтузиазма на следующий проект.
Продолжение пиления своего велосипеда, я оцениваю, как тупиковый сценарий — начальных запал иссякнет, в обмен на это будет кучка разрозненных знаний вида «нахватался по верхам» и выгорание.
Ребят, а может человек как-нибудь сам, без вас разберётся на что он будет тратить своё время?
«опыт, это то, что ты получаешь, вместо того, что хотел». Применяя к текущей ситуации — хотел сделать супер-пупер инструмент, а получил опыт.
Опыт — это любая практика. Я не хотел сделать супер-пупер инструмент, я хочу его сделать. Статья была написана 2 месяца назад, всё это время релакс развивался.
Я не хотел сделать супер-пупер инструмент, я хочу его сделать.
Обычно люди делают инструмент для решения какой-то задачи. Какие задачи с использованием вашего языка будет решать лучше (проще, удобнее, приятнее, итд), чем с использованием любого другого уже существующего языка?
Новый язык программирования — Relax