Comments 115
Еще чуть-чуть и будет CoffeeScript.
В функциональных языках в принципе нет понятия "присвоения".
От JS усталости помогает https://elm-lang.org/
А Elm конечно шикарный и очень похож на Una. Отличие в том, что у Elm собственная стандартная библиотека, коллекции и синтаксис, а Una все же плотно интегрирована в JavaScript.
Идея хороша. Запомню как концепцию для DSL.
Получилось действительно лаконично, есть некоторая система (вот эта вот симметрия разных стрелочек довольно прикольная).
Не факт, однако, что замена ключевых слов на ASCII-арт делает код более человекочитаемым. В человеческих языках наличествует избыточность, и она нужна как раз для улучшения распознавания.
Интересная идея с разнонаправленными стрелками, но как-то всё это сложно. Хочется ещё проще язык.
Подход к синтаксису похож на тот, что я описывал тут: https://habr.com/ru/post/503240/
Как быть без finally, если он нужен?
Ну и если вам интересно пообсуждать языковые концепции, то заглядывайте к нам в телеграм: https://t.me/lang_idioms
В этом плане, взятый за основу Lisp далеко не самый лучший пример для подражания.
Например:
(defun square (x)
(* x x))
Всё же куда наглядней как-то так:
function perimeter
> @width float64
> @height float64
> @zoom float64
< mult
2
@zoom
sum
@width
@height
Любой перенасыщенный длинными инструкциями язык станет легко читать, если привыкнуть к обилию в нём длинных инструкций ;)
(defun our-member (obj lst)
(if (null lst)
nil
(if (eql (car lst) obj)
lst
(our-member obj (cdr lst)))))вот так:
defun our-member (obj lst)
if (null lst)
nil
if (eql (car lst) obj)
lst
our-member obj (cdr lst)Ну и меня смущает, что в ваших примерах = z (calculate x y) форматируется как:
= z calclulate
x
yХотя по всей логике это должно выглядеть как-то так:
= z calculate
x
yПотому что в лиспе (= z (calculate x y) как раз бы форматировалось так:
(= z (calculate
x
y)Потому что иначе нарушена логика. Ну а в остальном — удачи вам и вашему проекту, буду надеяться, что у вас все получится и вы не забросите проект.
В Una одна таба или два пробела уже задают вложенный блок, поэтому можно не бояться создавать глубоко вложенные деревья кода. Это вряд ли верно с точки зрения качества и читаемости, но возможность такая есть.
(= z (calculate)
x
y)В целом согласен, что при очень массивном коде это будет выглядеть не очень, просто привычки дают о себе знать
На самом деле быстро привыкаешь, что элементы с отступом относятся не к первому элементу, а к последнему на строке с меньшим отступом.
Преимущество тут ещё в том, что изменение кода в одной строке не приводит к сдвигу всех последующих, что приводит к лишним конфликтам при слиянии веток.
хорошая среда для лиспа сама будет выравнивать тебе все строчки
Речь про системы контроля версий, а не про автоформатирование.
у лиспа в основе функциональное программирование
Это не так.
Речь про системы контроля версий, а не про автоформатирование.
Ну тут не разбираюсь, спорить не стану.
Это не так.
В смысле не так? Лисп — мультипарадигмальный язык, но функциональная часть явно преобладает даже в common lisp, не говоря о scheme и других диалектах. Конечно, на макросах можно даже ООП построить, а в CL есть goto, но это не отменяет того, что изначально вообще через лямбды писали
Лисп изначально проектировался как функциональный язык программирования с отдельными императивными чертами, введёнными из соображений удобства практического использования.
Вообще любой императивный язык тогда можно назвать "функциональным с императивными чертами". ФП от ИП отличает именно что отсутствие "императивных черт".
И, опять же, нет, вы возвели все в абсолют, большинство языков императивные с чертами функционального.
Емнип в Хаскеле всю эту императивщину можно запретить и только тогда он становится ФП.
Вот никак не пойму, почему многим нравятся синтаксисы без скобок. Как по мне, это очень усложняет язык:
- перенос кода ломает табуляцию;
- выровнять код автоматически невозможно, поскольку табуляция имеет смысл;
- дебажить куда труднее, кроме проблем с табуляцией появляются проблемы из-за размытости синтаксиса. Как в том же хаскеле, где забытый аргумент функции = проблема с типами, как и практически любая другая ошибка.
- нотация через точку дает возможность легко просмотреть API объектов и классов, в языках без этого приходится каждый раз обращаться к документации;
А какие преимущества? Пара сэкономленных символов и некое эстетичное удовлетворение?
= numbers :: 1 2 3
= incrementedNumbers numbers.map (-> number (+ number 1))
Но из-за правил порядка применения операторов следующую функцию через точку мы уже вызвать не сможем. То есть вот так сделать нельзя:
(numbers.map (-> number (+ number 1))).filter (-> number (> number 1))
Потому что мы в таком случае не сможем разбить функцию, передаваемую в map, на несколько строк с помощью индентации.
В целом, главное преимущество в таком синтаксисе действительно эстетическое удовольствие от созерцания кода, не отягощенного лишним синтаксисом.
Возиться с закрывающими скобками, особенно, если их много разного типа ))}}]}})))
Читать тяжело. Куча видов стрелок только сбивает с толку. И в чем выгода от написания переменной справа от "равно", а не слева? a = 1 гораздо более привычная запись, чем = a 1.
Lisp вы зря взяли за основу, его читать невозможно.
Также, функции в JS надо объявлять словом function, а не const, так читабельнее, чем эта мешанина из стрелок. В function x() уже по первому слову понятно, что перед нами функция.
Также, какой поехавший придумал импортировать css-файлы в JS? ЧТо-то я не припомню, чтобы правила ECMAScript позволяли импортировать CSS-файлы. Надо писать по правилам языка JS, а не по правилам транспилятора, которые меняются каждые полгода.
import './index.css'
и webpack подключит стили.
Это и есть ненормально. Надо писать по стандартам ECMAScript, а не на каком-то придуманном авторами webpack птичьем языке. Абсолютно дурацкая фича. Если уж на то пошло, то CSS и JS файлы должны подключаться из HTML-шаблона, а не из псевдо-яваскрипт файла.
Ох… Ну не знаю. Выглядит странно конечно, особенно пример с реактом еще чуток и можно без обфускатора обойтись. Какие-то четверные скобки. Если представить большой проект в таком стиле, как-то становится не по себе
Нет никакой "интуитивной понятности". Есть только привычки. Не стоит выдавать свои привычки за объективные свойства обсуждаемого предмета. И уж тем более не стоит в приличном обществе выпячивать на всеобщее обозрение свою неспособность эти привычки менять.
Однако это не слишком удобная запись во многих случаях.
- Когда используется много разных операторов легко напортачить с приоритетами.
- Из-за неуверенности в приоритетах и для упрощения чтения приходится расставлять излишнее число скобок.
- Парсить инфиксную нотацию существенно сложнее и медленнее.
- Неконсистентность синтаксиса между вызовами функций и инфиксными операторами.
- Практически невозможно расширять набор стандартных операторов вклиниваясь в иерархию приоритетов.
- Когда читаешь сложное выражение приходится запоминать первый операнд и лишь потом узнаёшь для какого действия он предназначен.
- Оператор может быть лишь 1 и 2 арным. Префиксная нотация позволяет делать операторы произвольной арности.
Главная проблема классической инфиксной записи (отсутствующая во всех альтернативных нотациях) — необходимость учёта приоритета операций. Но инфиксная запись привычнее, а для любого альтернативного варианта надо переучиваться. И отторжение вызывает не сама запись, а необходимость ломать устоявшиеся привычки.
P.S. В 1984 году в МГУ давали и префиксную, и постфиксную нотации. И это не дичь, а элементарные базовые знания, необходимые во многих разделах программирования — начиная с символьных вычислений и компиляторов.
«Понятность» — это про кол-во усилий, требуемых на чтение записи выражения. И стандартная инфиксная нотация — при наличии опыта использования альтернативных нотаций — в этом безусловно проигрывает.
Кстати, если школьнику в начале тех же 1980-х попадал в руки советский программируемый калькулятор, он очень быстро понимал, насколько постфиксная запись удобнее для вычислений, чем инфиксная. И для этого совсем не надо было учиться на ВМК.
Любая «понятность» — это результат обученияНикакие обучение не может уменьшить объём дополнительной информации, которую необходимо держать в уме в процессе «понимания». И чем больше этот объем, тем сложнее «понимание». А для инфиксной нотации этот объём существенно больше, чем для альтернативных нотаций.
При наличии опыта, много что удобнее. Люди даже машинные коды читают как книгу.Забавная демагогия. Машинные коды всегда будут читаться медленнее ассемблера — в силу более сложного процесса анализа информации.
да потому что там по факту сразу на асме программирование шлоВы либо не понимаете, о чём идёт речь, либо опять занимаетесь демагогией. Программируемые калькуляторы куда чаще использовались именно как калькуляторы — для ручных вычислений. И я говорю именно об удобстве ручных вычислений.
не потому что так человеку удобнее и проще а потому что микропроцессору это удобнееОшибаетесь, удобнее именно человеку: не надо тратить время и силы на учёт приоритетов операций и расстановку скобок.
Но тем неменее не реализована постфиксная запись в Си. Не задумывались почему?Потому, что любой язык программирования отражает личные вкусы его авторов. Не существует объективной причины использовать именно инфиксную нотацию.
всмысле clojurescript?
clojurescript.org/reference/javascript-api
www.verypossible.com/insights/clojurescript-and-javascript-interoperability-a-comprehensive-guide
интеграция есть вроде, насколько это бесшовно не знаю
А что получилось? Почти любая субд сейчас его поддерживает.
К сожалению — почти любая кухарка. У SQL очень низкий порог входа. Из-за этого очень много запросов, написанных "аналитиками" или людьми не понимающими СУБД или людьми далёкими от инженерной/разработческой культуры.
Как следствие много запросов а) неправильных по сути, но выдающие правильный результат в данной ситуации б) правильных по сути, но плохих для СУБД, в) написанных так, что их прочитать и понять можно только под тяжёлыми наркотиками, г) сгенерированных программами.
А на это накладывается отвратительная модель типов и практики проектирования ЯП середины прошлого века (тут я могу написать с десяток пунктов от имен идентификаторов до отсутствия модульности). Добавим сверху врождённую проблему почти любой СУБД — повсеместную мутабельность, конкурентность доступа, глобальность и необъятность состояния, неидемпотентность DDL (да, но в этом и суть СУБД). Полирнуть сверху тем, что РСУБД, реляционная теория и SQL — это три очень разные темы и вбить окончательный гвоздь тем, что его модель одинаково плохо мэтчится с моделями как "классических" "императивных" ЯП (C/C++/C#/Java), так и "продвинутых" "стремящихся к декларативности" ЯП (напр. Haskell).
Но есть еще нюанс. SQL, как я выше сказал, не только легко пишется "домохозяйками", но и выполняется близко к массивным объёмам данных, а из-за этого часто (отвратительный) код, написанный на SQL будет эффективнее, чем код на других ЯП.
Это приводит к тому, что у коммерческих потребителей (банки, шманки) образовались мегатонны этого кода. У 100% топ-30 банков РФ ключевые mission critical расчётные блоки написаны на SQL (T-SQL, PL/SQL, PL/pgSQL и т.п.). Миллионы, если не миллиарды строк. Их не отрефакторить, не выкинуть, не отмасштабировать, не структурировать. Да и даже новых перспективных идей ЯП для СУБД вроде как не видно на горизонте или, как минимум, я о них не знаю (Tutorial D "нещитова", конечно). Cтартапики фигачут микросервисную архитектуру, PhD придумывают Haskell/Scala/Coq/Agda, AWS/Google/MS строят облака в облаках, а триллионы долларов считаются всё теми же SELECT/INSERT/UPDATE/DELETE.
Вот и выходит, что SQL — это новый COBOL. Только другого масштаба.
Я с 2012-2013 надеюсь, что придёт новый Христос супергений, который соединит СУБД и современные наработки теории ЯП: функциональную парадигму, сильные системы типов, проверки завершаемости, встренную асинхронность и ленивость, отсутствие непредсказуемых побочных эффектов, повышение декомпозируемости, переиспользуемости и модульности и вот всё это. Но, кажется, что даже потребности в этом остальные пока не видят.
Наболело. Уфф. Dixi.
надеюсь, что придёт, нет, не придёт.новый Христоссупергений, который соединит СУБД и современные наработки теории ЯП
И тут есть три факта:
1. SQL — вообще не язык программирования. Это язык запросов. DDL вообще о другом — он меняет среду исполнения (и тут есть замечательный возможности… например, адаптивная модификация структуры хранения и кода, отвечающего за работу с данными).
2. ЯП в СУБД есть, но это T-SLQ, PL/SQL и т.п., и решают они специфические задачи вполне хорошо. Их «недостатки» связаны как раз с областью применения. И да, ФП там тоже есть, и много чего ещё…
3. Ну вот не нужен в СУБД ЯП общего назначения. Там нужно то, что будет эффективно данные обрабатывать. И все особенности тамошних языков вызваны потребностью выполнять в секунду тысячи вычислительных транзакций в условиях конкурентного доступа к данным.
Не нравится РСУБД — есть другие подходы. У каждого свои плюсы и минусы.
SQL — вообще не язык программирования.
Сложно оспорить, потому что, видимо у нас разные определения и источники. Википедия считает, что ЯП. Дейт считает, что ЯП. ISO/ANSI формулируют, что это database language, но программисты пишут на расширениях SQL (T-SQL, PL/SQL), а не на голом SQL (ISO/IEC 9075: год). К тому же лично я не знаю ни одной сколько-либо полной имплементации этого стандарта (ближе всех Oracle), а сам стандарт реально безумное лоскутное одеяло фантазий и фич нескольких вендоров (процентов на 70 — Oracle). Вычислительно SQL даже в части запросов с рекурсивными CTE тьюринг-полный, есть система типов, есть control flow, процедуры и функции так что это ходит как утка и крякает, как утка.
DDL это просто часть SQL (как стандарта, так и расширений). Про "адаптивную модификацию структуры хранения и кода" я не понял. Приведите пример, что имелось в виду.
ЯП в СУБД есть, но это T-SQL, PL/SQL и т.п., и решают они специфические задачи вполне хорошо
Да я как раз и пишу, что нифига они хорошо не решают. Производительно — да, решают. Лаконично (по сравнению с другими) выражаются запросы — да, пожалуй, это существенное преимущество. Управляющие и структурные конструкции — примитивные (и это то, почему язык быстро осваивается), но сам язык удивительно нецелостный и разнородный.
Про ФП в SQL и его расширениях впервые слышу. Дайте пример, пожалуйста.
Ну вот не нужен в СУБД ЯП общего назначения.
Ну во-первых я не говорю, что ЯП должен быть "общего назначения". Наоборот, скажу, что ЯП общего назначения, даже самые передовые проигрывают в манипуляциях с данными языку SQL.
А во-вторых, да-да-да, совсем не нужен. А потом кода становится миллионы строк, программистов больше пары десятков, постоянных сущностей в БД 100к и ОПА — каждое прикосновение — боль.
Не нравится РСУБД — есть другие подходы.
- Мне не нравится, когда смешивается понятие РСУБД и SQL. Идея РСУБД мне нравится (хотя она тоже хромая на обе ноги, но её можно, наверное вылечить).
- SQL — это не "Р". Дедушка Дейт тоже так считает. Кодд тоже так считал.
- Интересует, какие есть эффективные в разработке и эксплуатации "другие подходы", какие там языки (запросов и программирования, если их делить)?
Да, даже в SQL-92 были добавлены процедуры, но из нельзя написать на ANSI-SQL, реализации есть именно в вендорских расширениях. И вот эти расширения уже можно рассматривать как ЯП.
Адаптивная модификация… Это у меня был такой эксперимент. Не знаю, делает ли ещё кто так… Но, если вкратце, была система без заранее определённой доменной модели. Для хранения данных сделали объектно-атрибутное хранение (объект — название/тип атрибута — значение атрибута). Новые типы объектов и модификация списка атрибутов происходят на лету, но по мере увеличения количества данных падает производительность. А т.к. вся работа и так сделана была через хранимки, была написана процедура оптимизации, которая по статистике решала, что надо вынести в обычные таблицы. И эта процедура создавала таблички, переносила данные, меняла код вспомогательных процедур, генерящих динамические запросы. Тот ещё мутант, но работало прикольно.
Про ФП в SQL. Речь про всякие T-SQL и PL/SQL, где есть функции, которые могут быть чистыми в терминах ФП. Это, в свою очередь, очень помогает оптимизатору. Ну и оконные функции тоже сюда можно отнести. Да, это не полноценные ФП-языки, но тем не менее.
кода становится миллионы строк, программистов больше пары десятков, постоянных сущностей в БД 100кплохой код можно написать на любом языке.
Мне не нравится, когда смешивается понятие РСУБД и SQLМне тоже не нравится, но вот в чём фокус. Почти одинаково глупо работать с РСУБД без SQL и применять SQL без РСУБД.
Про другие подходы. Есть же много всякого. Document-oriented database, графовые БД, системы распределённых вычислений и т.д.
плохой код можно написать на любом языке.
Но на некоторых просто невозможно писать хороший.
То, что SQL не язык программирования, следует из его названия («язык структурированных запросов»).
По названию я тогда должен предположить, что Java и Kotlin это острова, а не ЯП? Неудачное разделение. Как мне понять, где вы провели границу, между ЯП и не ЯП? Мои критерии.
- на языке пишут программы для вычислительной техники (хранимку в 100к строк и витиеватой логикой сложно не назвать программой) и это его основное назначение
- вычислительно полный
- язык должен задавать алгоритмическую последовательность действий компьютера (возможно лениво и декларативно, асинхронно и параллельно выполняющуюся, но всё-таки), т.е. в каком-то смысле есть control flow
- есть система типов
И вот эти расширения уже можно рассматривать как ЯП.
И вот на них и пишутся тонны кода.
И эта процедура создавала таблички, переносила данные, меняла код вспомогательных процедур, генерящих динамические запросы. Тот ещё мутант, но работало прикольно.
Да, это мутант и это не прикольно. Такие штуки очень сложно поддерживать, они прибиты гвоздями к вендору СУБД, это сложно масштабируется и еще сложнее обеспечить консистентность и параллельную работу в среде высокой конкурентной нагрузки на запись.
Код, который генерирует код или развитые средства шаблонизации (что на самом деле близко) — обыденность и в других областях, но в современных ЯП это делается несколько более элегантно.
Про ФП в SQL.
Про ФП, наверное, нельзя говорить пока функции не 1st class objects. Ну хотя бы функциональный тип чтобы был. То, что некоторые функции не имеют побочных эффектов и возвращают детерминированное значение, и это позволяет применить оптимизацию — это вообще не ФП.
плохой код можно написать на любом языке.
Но на T-SQL невозможно написать хороший код (если мы говорим о крупных проектах). На PL/SQL и на PL/pgSQL можно написать код чуть лучше, но не очень хочется сейчас уходить в детализацию различий сортов отходов жизнедеятельности.
Почти одинаково глупо работать с РСУБД без SQL и применять SQL без РСУБД.
Тем не менее, я не готов смешивать обсуждение языка SQL и "реляционности", т.к. слово "реляционные" в этих "Р"СУБД — исторически сложившаяся маркетинговая уловка. Хотя есть еще много СУБД, которые сложно назвать реляционными, но в том или ином виде SQL там есть. Но, ОК, я понял, что для вас "БД с SQL" и "РСУБД" синонимы.
Про другие подходы. Есть же много всякого. Document-oriented database, графовые БД, системы распределённых вычислений и т.д.
Дайте, пожалуйста, список примеров систем/платформ учета на этих подходах. ERP или ABS какие-нибудь или что-то подобное?
где вы провели границу, между ЯП и не ЯПтут всё просто. SQL задуман как язык запросов, а не программирование. Оное появилось там позже и отдельно от вендоров не существует именно языка программирования SQL (насколько я знаю).
они прибиты гвоздями к вендору СУБДБД с бизнес-логикой и так прибита к вендору. Лично я вообще не сторонник писать сложную логику в СУБД (кроме, собственно, запросов).
А мой мутант был хорош тем, что был сокрыт за публичным АПИ, и его работа никак не влияла на этот АПИ. А вот если ходить мимо — то да, могли быть сюрпризы. Но и не говорю, что это очень уж хорошо :)
пока функции не 1st class objects.Конечно, там нет полноценного функционального языка, хотя есть элементы функциональной парадигмы.
T-SQL невозможно написать хороший код (если мы говорим о крупных проектах)А вот тут просто надо знать меру. Я видел и хорошие и плохие варианты и на T-SQL и на PL/SQL. И это даже не сильно зависело от размера. Гораздо больше это зависело от архитектуры и качества разработки.
есть еще много СУБД, которые сложно назвать реляционными, но в том или ином виде SQL там естьа есть примеры, где SQL вне РСУБД лучший выбор, а не дань традиции?
для вас «БД с SQL» и «РСУБД» синонимыНет, не так. Но я считаю SQL наиболее удобным для запросов к данным РСУБД.
список примеров систем/платформ учета на этих подходахМного их. К примеру: Hadoop, Apache Ignite
Человекочитаемость
Лаконичность
Внутренняя непротиворечивость
Чистота и красота
Открываем Википедию
Язык для человека, а не для компьютера.
Просто, но не слишком просто.
Принцип наименьшей неожиданности
Ортогональность важна, но естественность важнее.
Следовать простым и строгим правилам, но не доходить до педантизма.
Также это все есть в питоне.
А еще огромная проблема вашего языка — в нем мало плюшек и сахара для программиста. Да, это вопрос времени, но добавьте туда столько плюшек, сколько их в том же питоне — вы получите второй джаваскрипт, только лиспнутый на всю голову.
def addition(n):
return n + n
numbers = (1, 2, 3, 4)
result = map(addition, numbers)
print(list(result))
Возникает множество вопросов:
- Почему функция map, примененная к листу, возвращает не лист, а итератор? Это противоречит самому смыслу маппинга
- Почему лямбда функция (одна из самых частоиспользуемых конструкций в любом языке) записывается не стрелочкой как во всех языка, а через слово отдельное слово lambda?
Так она и принимает на вход итератор вроде. Лист — лишь частный случай итерируемой коллекции.
map(x => x, container) == container
А если функция принимает list, а возвращает iterable — это очень странно и неудобно.
Это называется полиморфизм. То, что вы функции передаёте — это вовсе не обязательно то, что она принимает. А возвращает map то, что принимает, а не то, что вы ей передали.
Про различие аргументов и параметров я писал тут в самом начале: https://habr.com/ru/post/477448/
map(a, filter(b, map(c, smth_list)))Если в этом smth_list у вас 10**10 значений, то языку будет неободимо хранить в памяти smth_list, map1, filter, map2, то есть, в 4 раза больше значений. Поэтому же range(10**7) не занимает 100мб памяти, просто это будет бессмысленно.
Затем, у вас есть объект ТаблицаЗакупкиЗапасныхДеталей (либо другое извращение, которое всегда возникает в хоть сколько-нибудь серьезных проектах), который создается исключительно из словаря с определенными ключами, и вы кидаете эту таблицу в map. В итоге вы получаете ошибку, тк при попытке создать ТаблицуЗакупкиЗапасныхДеталей вы получаете не исключительныт из словарь с определенными ключами, а нечто другое.
В конце концов, ваш fuction_for_map не обязательно будет возвращать те же данные, что и получает, может, вы в мапе просто хотите получить 3 поля всех моделек из вашего queryset таблицы в 20 полей, кто ж вас знает. И питон не гадает, что вы там хотите, он говорит «ты взрослый человек, делай что хочешь, но и вся ответственность пусть лежит исключительно на тебе».
Про лямбды сам Гвидо сказал: «я против лямбд, а включил их просто потому что мне принес полностью готовый код для ни другой программист».
П.с. Сам я, наверное, ни разу не пользовался мапами и фильтрами, тк лично для меня удобнее вещи типа
[get_first_field(item) for item in item_table]
[item for item in item_table if item['is_mutable']]
Во-первых, с повсеместной ленивостью мы получаем foldl, который потом стыдливо прикрываем его жадным братом foldl'. Во-вторых, все равно во всем мире, где не стремятся избежать успеха любой ценой, всегда есть два варианта: greedy (map) и lazy (по-разному). В питоне это что-то типа iterators.imap, в руби — .lazy.map, в эликсире — Stream.map.
Ну и синтаксический сахар с list comprehension, которые ваш оппонент продемонстрировал в конце — ленивый.
Сам я, наверное, ни разу не пользовался мапами и фильтрами
… Потому что использовать их в питоне неудобно даже чисто синтаксически и это не даёт ровным счётом никакого выигрыша в производительности. В нормальном языке подобные конструкции использовать, напротив, удобнее, чем закостыленные выражения для частых вещей.
Вот в Haskell, например:
map getFirstField itemTable
filter isMutable itemTable
К примеру, в общем проекте одному нравится отступы с 2 пробелами, другому с 4, одному со скобочками другому без, одному if в одной строчке, другому в разных, кто то хочет; на конце, кто-то нет и тд.
И, наверное, можно гораздо дальше пойти вплоть до отображения в виде этого Una или чем-то подобном, при неизменном стандартном коде js в общем репозитории.
Может уже есть такие плагины для VS Code. Кто-нибудь видел?
const screenLeft as byte = radius
const screenTop as byte = radius
const screenRight as ushort = screenWidth - radius
const screenBottom as ushort = screenHeight - radiusКак среда должна поступать в таких случаях, когда язык позволяет писать эти выражения на нескольких строках?
Конкретно по приведённым строкам, тут например можно указать редактору, чтобы выравнивал по самым длинным названиям.
Код читают и пишут не только в IDE. И это вряд ли изменится.
Короче движение есть, но разнонаправленное.
Субъективная у вас конечно "человекочитаемость", все эти лесенки, стрелочки. По мне так, наоборот, читаемость, это когда операнд сам по себе говорит что он делает, читаешь в слух и осмысленные предложения получается сразу. А тут сиди запоминай в какую сторону стрелочки рисовать.
Покажи тот же jsчеловеку, который вообще поверхностно знаком с программированием, он уже сможет приблизительно понять, что происходит. Где функция, где цикл. Покажи ваш язык и… в общем спорно
читаешь в слух и осмысленные предложения получается сразу
И получается, внезапно, AppleScript. Правда из-за такой многословности он и не взлетел толком, ибо в полноценном софте не будешь писать строчки на пол-экрана типа tell MyLibrary to tell object sharedInstance to tell WebClient to fetch content of URL myUrl.
Ну и у японцев есть подобные языки, по типу Nadesiko или MIND, в которых весь код является чисто текстом на слегка структурированном японском. Но японский — он сам суть тот же Форт, только самозародившийся.
Успехов с регулярками :)
Я правильно понял, что ваш язык можно использовать как эксперимент, но в случае чего, можно прогнать транслятор и получим тот же js, который однозначно будет рабочим и читаемым? Это нужно как аргумент, чтобы в случае чего малой кровью отказаться от Una (как страховка, так сказать)
Как писал один мой знакомый:
каждый проггер в своей жизни должен написать лексер, парсер, компилятор, линкер, и выкинуть это нахуй
Зачем вообще нужен новый ЯП, если единственное, что он даёт — новый синтаксис? Где интересная семантика?
Почти уверен, что не взлетит в промышленном масштабе, но в вашем Uno достаточно много интересных идей, доведённых до хоть какой-то реализации. И это реально круто.
А прочтение статьи побуждает задуматься о некоторых моментах для других DSL.
Как я устал от JavaScript и создал свой собственный язык программирования