Comments 33
Это вы Lisp изобретаете, или скорее даже Racket.
Да нет, здесь "изобретение" по круче:
https://habr.com/ru/articles/942134/comments/#comment_28773432
:)
Что гибко будет - это да, хорошо. Оборотная стороны - будет более сложно и медленно. Еще интересно почему этого еще нет в индустрии в предложенном автором варианте? Может на это есть веские причины?..
Если кратко, то суть статьи можно выразить фразой:
Шуруп, забитый молотком, держит крепче, чем гвоздь, завёрнутый отвёрткой.
Но что-то мне подсказывает, что лучше или гвоздь забить молотком, или (наверное ещё лучше) шуруп завернуть отвёрткой.
---
Если переходить к деталям, то в семействе компиляторов gcc есть возможность подключать плагины, которые могут втащить новые свойства, добавить ключевые слова (атрибуты и т.д.). Т.е. с идеей "давайте добавим" автор слегка опоздал.
НО, по-моему, этим всем очень редко пользуются, т.к. это может быть сродни изучению нового языка.
Причём такого нового "языка", на который нет ни стандарта, ни внятной документации. Этот "язык" неизвестен никому, кроме пары-тройки человек. И конструкции этого "языка" могут поменяться одним днём. ОДНИМ ДНЁМ, КАРЛ! Кто захочет учить и использовать такой язык для продакшена? Вот для развлечения или хобби (или курсовой работы) - самое оно.
Причём проблема изменений языка - она очень тяжёлая. Например, если вспомнить довольно популярный язык программирования Python, то V2 и V3 это уже разница.
Поэтому, может следовать по принципу "мамы всякие нужны, мамы всякие важны"?: есть разные языки - пусть и будут. Да и новые появляются.
Главный вопрос - а зачем? Чтобы у группы не взаимосвязанных языков был похожий синтаксис. Ну так синтаксис вторичен, главное как раз семантика, которая будет отличаться. Причем отличается не от языка к языку а внутри любой комбинации любого варианта этого языка. По итогу получите бесконечное количество языков каждый со своими правилами но со сходными синтаксисом что есть проблема. И какой в этом смысл? Приходить в компанию и каждый раз учить новую вариацию одного и того же языка?
ЯП уже есть, какие есть. Какие выжили, такие и нужны. Не получится никакой генной инженерии и игры в Бога, только жестокая природа.
Выше уже написали - Вы изобретаете Racket. Наверно, комментирующему казалось, что после этого Вы бегом поскачете разбираться что Racket такое. А я так не думаю, поэтому напишу что известно про Racket.
Идея самоизменяемого языка, она же идея DSL (Domain Specific Language) хороша до тех пор, пока над проектом не начинает работать группа людей. Когнитивная нагрузка от изучения языка и чтения элегантного текста на нём, о написании даже не говорим, оказывается выше, чем от чтения корявого текста на общеизвестном языке. Отсюда понятно, почему Racket и DSL вообще - нишевые решения.
Универсального языка на все случаи жизни нет и быть не может не только потому, что есть группа (не)товарищей стремящаяся наплодить языков поболе согласно максиме о разделении и властвовании, но и потому, что случаи жизни сильно разные. Когнитивная нагрузка от игнорирования ненужных особенностей языка, каковая неизбежно возникает в языке, универсальном не через построение DSL, оказывается выше, чем от необходимости при переходе к новым задачам изучать новый язык, и выше, чем от необходимости приспосабливать уже изученный язык к той задаче, для которой он подходит не зидеально.
Так оказалось давно и многократно - другой Природы у нас для Вас нет, об идее забываем. Кстати, практическая возможность решить задачу на каком-либо языке, кроме вырожденных случаев типа написания ОС реального времени для встраиваемой системы, определяется и не задачей, и не языком, а наличием подходящих библиотек. Поэтому на практике JavaScript и Python - языки поуниверсальнее всех остальных.
... практическая возможность решить задачу на каком-либо языке, кроме вырожденных случаев типа написания ОС реального времени для встраиваемой системы, определяется и не задачей, и не языком, а наличием подходящих библиотек.
Вы пропускаете, как мне кажется, очень важный аспект. Да, традиционный подход к созданию приложений основывается на библиотеках (содержащих функции и классы). Но язык программирования, как таковой, это операторы языка, это его синтаксис. Перекладывание ответственности на библиотеки приводит к тому, что все заняты написанием библиотек (на все случаи жизни), а сам язык развивается мало. Каждый язык характеризуется своими изобразительными средствами. Когда мы изучаем Python, то мы сталкиваемся с генераторами и итераторами и тем, как за кулисами всех процессов стоят замыкания и ООП. И это всё описывается вполне определённым синтаксисом. Однако, если мы хотим решать какие-то специфические задачи, то у нас должен быть и подходящий синтаксис. Из-за того, что все пишут библиотеки, множество языков программирования становятся мало отличимыми друг от друга универсальными монструозными конструкциями. Кому ,что ближе, тот на чём и пишет. Ну и, если библиотека подходящая есть. Но! Вы можете представить себе язык программирования, где нет числовых вычислений? А язык, предназначенный исключительно для описания компонентов? В этом смысле, управляемость синтаксиса (возможность изменять его под конкретную задачу) может оказаться хорошим подспорьем. Было бы. например, более понятно, если бы можно было бы ввести в язык оператор SORT, который по своему смыслу должен приводить к сортировке некоторого списка (массива). Подход, основанный на библиотеках заставляет нас выбирать конкретную реализацию алгоритма сортировки (то есть — конкретный алгоритм). А нам важнее указать только то, что определённый массив должен быть отсортирован. Выбор конкретного метода может зависеть от контекста. Более того, можно представить себе, что ОС, имея описание алгоритма обработки на некоем универсальном=обобщённом языке программирования, предоставит пользователю план выполнения этого обобщённого алгоритма, подставляя для каждого такого оператора свою реализацию. И всё это вместо плясок с шаблонами в разного рода языках программирования.
И ещё. В теория программирования описывается способ разработки ПО, когда сама программа, сначала проектируется на одном языке программирования, а реализуется, фактически, на другом языке программирования. Думаю, очень важно осознать тот факт, что многие проблемы проектирования и реализации ПО проистекают из-за того, что всё делается в рамках единственного языка программирования, когда в одном пространстве имён располагаются и классы исходных вычислительных объектов, и и классы компонентов (как визуальных, так и невизуальных), так и классы конечной реализации, относящиеся к предметной области. Всё-таки, правильное программирование основано на чётком разделении всех задач и применении, по сути, трёх различных языков программирования.
Не-не, тут вопрос философский: почему до сих пор нет универсального языка программирования, потому что у каждого человека модель мира (всего сущего) в голове своя -- нет общей модели мира, известной каждому. Поэтому каждый автор языка строит его в соответствии со своим внутренним пониманием модели. Получаются языки каждый на свой манер. С другой стороны, космонавтика до недавнего времени не была частью модели мира. Сначала создали спутниковую космонавтику, и она стала частью модели мира. Потом создали пилотируемую космонавтику, потом станционную и т.д. Вывод: чем более универсальный язык будет создаваться, тем более полную модель мира можно описать с его помощью. Это процесс итерационный. Где-то в будущем они должный сойтись. Как говорилось в одном советском фильме: поживем -- увидим.
Достаточно кратко и точно подмечено)
Такой язык уже есть, просто о нём никому не известно (кроме нескольких человек).
Универсальный язык мышления (для программирования синтетически-разумных образов) - ЯП, над которым я работаю уже очень давно; в его основе один тип данных - идея и единственный способ представления любых данных (в т.ч. и программ) - цифровой мысле-образ (необычный ориентированный граф сплетенный из идей). Для программирования на этом языке определены несколько базовых команд, которые не привязаны к какому-либо синтаксису и семантике. В языке нет зарезервированных слов и даже символов. Даже понятия чисел и операций над ними выводятся с нуля, как и любые другие абтракции.
По сути, как ты написал - каждый, кто будет писать на нем программы, будет выражать мысль своим уникальным образом, характерным только для его образа мышления. При этом, за счет использования общих базовых конструкций и принципов построения цифровых мысле-образов - такую программу сможет прочитать и понять любой, кто знаком с этим ЯП.
Как автор этого языка могу сказать что на нем можно описать любую модель мира, какой бы она не была: логичной (нелогичной), изощрённой и противоречивой, меняющейся на 100% рантайм и т.п. Все что сможете вообразить)
Захотелось вдруг прокоментировать.., не удержался..)
Один язык с известной, фиксированной структурой и синтаксисом порой приходится годами доводить до стабильного состояния. Подозреваю, что язык, в который каждый кому не лень будет закидывать новых возможностей, будет настолько полон багов, что окажется просто непригоден для продакшена.
Самое интересное, что самое интересное начинается с первых строк статьи:
Языки можно поделить на две большие группы: предметно-ориентированные языки (aka DSL) и языки общего назначения (ЯОП). DSLи точно можно назвать инструментами, так как они по определению решают конкретную задачу. С языками общего назначения все несколько сложнее. ЯОПы имеют...
Если ввести в поисковик: https://yandex.ru/search/?text=что+такое+ЯОП
то выйдут десятки страниц с определением ЯОП как:
Языково-ориентированное программирование (ЯОП) — парадигма программирования, заключающаяся в разбиении процесса разработки программного обеспечения на стадии разработки предметно-ориентированных языков (DSL) и описания собственно решения задачи с их использованием.
https://ru.wikipedia.org/wiki/Языково-ориентированное_программирование
Первой будет ссылка ссылка на Википедию, второй - на эту статью на Хабре: Зачем ЯОП? Зачем Racket? https://habr.com/ru/articles/445822/
То есть ЯОПы это и есть DSL-и (по определению).
Поэтому возникают резонные вопросы:
насколько автор воообще осведомлён в вопросах, о которой он взялся писать?
что имеют в виду плюсующие статью?
Скриншот на память:
Вы путаете языки общего назначения и языково-ориентированное программирование. Буквы те же, смысл разный. Вот в английском не так :)
https://en.m.wikipedia.org/wiki/General-purpose_language
https://en.m.wikipedia.org/wiki/Language-oriented_programming
Да нет, это автор статьи путает. DSL - специальный язык под задачу (sql, например). Язык общего назначения - который приемлемо решает любую задачу (на питоне хорошо писать сервисы, окей писать игры и геморрно делать реляционные базы, но допустимо). ЯОП - парадигма, что давайте не будем на языке общего назначения решать задачу, а лучше выделим суть задачи и напишем для неё dsl (возможно, внутренний), который щёлкнет её как орешек.
Ну, я не плюсовал/не минусовал ни статью, ни карму. И если бы автор назвал язык общего назначения "ЯОН" или "универсальный язык" - вопросов бы не было. Но "ЯОП" и "язык общего назначения" - это общепринятые в индустрии термины. С диаметрально противоположными значениями (все это знают). И спользовать один такой термин вместо другого - далеко не лучшая идея. Тем более в технической статье с обзором языков и их парадигм. Отсюда - сомнения.
спасибо, что указали на неточность. Исправил ЯОП на ЯПОН (Язык Программирования Общего Назначения). Помню сокращение ЯПОН мне не понравилось, захотел другое использовать, но что-то заклинило. Согласен, "ЯОП" тут вообще не к месту
Слышал на forth можно писать как угодно. Можно даже сэмулировать любой язык и даже есть forth процессоры)
Я автор SP Forth 4, там как раз был применен так называемый peephole оптимизатор, быстро работал и код был неплохого качества. Ну на форте да можно написать любой dsl прямо внутри форта и пользоваться им. Например грамматики языков Lex yacc были просто форт словами. Да и ООП библиотек было штук 5 с разным синтаксисом. Эх давно это было...
Несмотря на то, что автор говорит дельные вещи, моё виденье этой проблемы всегда было диаметрально противоположным. Мы должны создавать не один общий язык, а несколько узкоспециализированных DSL для каждой значимой области.
Я делаю такой вывод на основе следующего наблюдения: в подавляющем количестве областей популярным является только один язык
Например:
PHP - backend
JS/TS - frontend
Python - скрипты и машинное обучение
C/Rust - высоко-оптимизированные подпрограммы
C++ - разработка игр
Чем обусловлена популярность PHP в разработке backend? Библиотеками и инструментами для работы с сетью и вёрсткой, встроенными в язык. Чего стоит только нативный web-server, запускающийся одной командой из коробки.
А чем обусловлена популярность C/Rust в разработке высоко-оптимизированного кода? Возможностью языка напрямую работать с памятью и иметь прозрачность при компиляции в ассемблер.
Таким образом, если мы идём по пути "универсального языка", то у нас 2 варианта:
Мы запихиваем все фичи прямо в язык. Он будет из коробки работать для любой области, но из-за этого язык раздуется до неприличных размеров. Синтаксис языка, необходимый для поддержки одной фичи, может мешать программистам, которым не нужны эти фичи. Например, работа со строками в C/Rust будет вызывать негодование у backend разработчиков
Мы создаём минималистичный язык. Он ничего не умеет из коробки, но мы пишем на него модули для каждой области (это LISP и то, что предлагает автор). Но из-за этого мы получаем кучу диалектов и модулей/библиотек, каждая из которых решает одни и те же проблемы разными способами. После чего эти библиотеки будут собираться в Framework'и. И вот мы уже выбираем не язык, а Framework. Мы пришли к той же проблеме
Вы когда-нибудь задумывались, почему у языка существуют framework'и? Потому что этот язык недостаточно специфичен. И framework'и решают эту проблему. А замечали ли вы, что framework'и создают настолько специфичные знания, что их приходится учить как отдельный DSL? Если нет, то вспомните React / Vue / Svelt для JavaScript или Laravel для PHP, и вы точно согласитесь с этим утверждением.
Интуитивно мы понимаем, что для комфортной работы нам нужны DSL. И мы пишем свои надстройки поверх языка, которые в итоге получаются хуже, чем если бы мы сразу разработали язык с узкоспециализированным синтаксисом.
Поэтому высокоуровневой стратегией здесь будет не создание универсального расширяемого языка. Нам следует идентифицировать значимые области, идентифицировать потребности разработчиков и самые частые UseCase'ы, и в последствии разработать для каждой области удобный DSL с нужным синтаксисом и фичами.
Навернуть абстракций до жопы, а потом оптимизировать в три прохода. А чего бы сразу оптимально не написать? Модно писать расширяемый во все стороны код, который не надо править, а просто дописывать изменения. Но нафига, если это не нужно?
Так это же java... :) - там и модульность и байткод и на с++ можно допиливать и вообще яп, на котором можно все...
Все так, если заменить слово Java а C#.
Ну так то да. Там часть текста про проверку по типам была. Её в таком виде делать смысла нету для статически типизированных языков. Ну а лаконичность и максимальную гибкость даст Kotlin, так как в случае чего может и в JS, и в JVM компилиться)
C# это исторически язык, который делался в качестве конкурента java, и, как по мне, он всё ещё гораздо хуже. Ещё больший разрыв можно почувствовать, если попытаться сравнить C# с вышеназванным Kotlin.
C# это исторически язык, который делался в качестве конкурента java, и, как по мне, он всё ещё гораздо хуже. Ещё больший разрыв можно почувствовать, если попытаться сравнить C# с вышеназванным Kotlin.
Не понятно зачем делать такие выводы если очевидно что с языком Вы не очень то знакомы.
C# лучше чем Java
Java до сих пор не имеет структур что является большой ошибкой так как они используются для оптимизации
Итак, какие задачи языка мы имеем на данный момент? ЯП должен:
иметь возможность расширять свои frontend, middle-end, backend
иметь простой API для расширения
поддерживать большинство парадигм (функциональное, декларативное программирование)
Было уже - Nemerle. Был убит MS-oм по причине угрозы зоопарку MS языков из-за эмуляции любых языков (в теории, С# по факту) простыми макродирективами. среди прочего поддерживал программирование как отступами так и скобками, отложенную типизацию, ..
Мое видение универсального языка программирования