Stodin DSL

Повторное изобретение ним ( https://nim-lang.org/ )?

Повторное изобретение ним

Не, тут другой подход.

1. Ним претендует на замену C++ (хоть и компилируется в него). Он сложен и постоянно изменяется. Стодин примитивен и если потребуется реализовывать сложные сущности (шаблоны, иерархии абстрактных классов и т.д.) то потребуется подключение файлов с кодом на C++. Зато примитивность обеспечивает стабильность.

2. Грубо говоря, Ним является гибридом Паскаля и Питона. Стодин является гибридом Ассемблера и Питона.

3. У Ним есть сборщик мусора (говорится, что его можно отключить, но сложно спрогнозировать как при этом будут работать библиотеки). Стодин по причине примитивности просто не требует сборки мусора (этим занимаются библиотеки).

В целом же я делал язык, простой для машинного анализа, чтобы, например, автоматически генерировать тесты (полностью автоматом не выйдет, наверное, но проанализировать ветвления и побочные эффекты можно, а это уже упростит задачу). Ним, насколько я знаю, себя не ограничивает.

tool for accelerating the development of C++ programs

Kill it with fire.

В данной теме представляю для обсуждения язык программирования, созданный с использованием принципов разработки предметно-ориентированных языков (по книге Мартина Фаулера). Ссылка на проект языка: https://github.com/kupriyanov-sn/StodinDSL
Язык называю DSL только по методу разработки и по синтаксису. По возможностям он близок к языкам общего назначения. При этом, по лаконичности он близок к Python, хотя и статически типизированный. Назначение языка - ускорение разработки небольших проектов на C++.

Если целевая задача DSL — это выполнение курсовой работы по IT-специальности, то такая постановка смотрится вполне симпатично. В противном случае здесь упомянут набор логически связанных, но по сути бессмысленных тезисов — я сам лично такие писал «потому что надо». К счастью, то время пришло, и теперь мне не нужно ни на кого ссылаться и не нужно применять именованные методики.

«Небольшой проект на C++» является очень широкой сферой, потому нельзя говорить про какую-то специфичность.

Форму описания языку, подобному C++, можно придумывать разную, и это не будет никак решать фундаментальных проблем этого языка. Например, кому-то нравятся скобки для блоков, а кто-то хочет писать «begin...end». Это, на самом деле, ничтожный фактор, намного менее значимый, чем применение безопасных массивов. Однако же, если язык скатывается до конструкций «for a in 12;99;1», то всё чаще возникают ситуации, когда человек теряет контроль за структурой программы. Даже класических for-циклах C/C++ есть опорные элементы — это даже не столько точка с запятой, сколько объявление переменной с присваиванием, условие, и инкремент. В конструкции «for a in 12;99;1» уже нет никакого присваивания, условия, и глазу не за что зацепиться.

Такое стремление к формальному уменьшению числа символов привело тот же Haskell к появлению синтаксического значения у пробела в конце строки, то есть, нечитаемый символ является полновесным оператором. Это приближает язык к таким эзотерическим штукам, как MUMPS, Whitespace, и, в итоге. Brainfuck. Из этого списка MUMPS реально применялся, и причиной было то, что текст программы на MUMPS был компактнее, чем скомпилированный машинный код. Сейчас уже компьютерные накопители давно уже меряются мегабайтами, потому необходимости так извращаться давно нет, а читаемость программы меряется не плотностью символов, а именно скоростью ее чтения человеком, не знающим эту программу заранее. И я не вижу, чем твой язык упрощает читаемость. При этом по уровню абстракций язык находится где-то на уровне C/C++/Pascal, так что я вообще не вижу смысла в его создании.

К тому же, зачем придумывать собственные зарезервированныq идентификатор, вроде «mref», когда уже в широком применении находятся привычные многим «var» и «let»?

Нельзя судить о языке по одному маленькому примеру. Согласен, что документацию в формате odt никто читать не будет. Я перевёл её в html, но Github выводит код документа вместо самого документа. Придётся с этим Markdown повозиться.

К тому же, зачем придумывать собственные зарезервированные идентификаторы, вроде «mref», когда уже в широком применении находятся привычные многим «var» и «let»?

Вместо var и let используется просто звёздочка. mref и cref не для этого. Данные ключевые слова нужны для определения переменных и константных ссылок в аргументах функции. В общем случае, заголовок функции пишется в три строчки.

Даже в приведённом примере есть конструкция типа:

a b answer @get_multi_question

Здесь на самом деле нет возврата трёх переменных. Возврата переменных у меня вообще нет. Здесь идёт изменение трёх переменных-аккумуляторов. Если поставить переменные справа функции, то их изменить будет нельзя, они станут константными аргументами.

И вообще, в языке нет возврата данных (исключением можно считать обращение по индексу в массиве). Это сделано не столько для удаления мешанины из возвращаемых значений и ссылок в заголовках функции, сколько для чейнинга, который в языке распространён на всё, включая операторы.

Именно в этом особенность, а не в исключении скобок. Скобки отпали сами за ненадобностью (есть редкие случаи, когда они могут пригодиться, типа инициализации массива массивов, но я ими пренебрёг).

Форму описания языку, подобному C++, можно придумывать разную, и это не будет никак решать фундаментальных проблем этого языка.

Я не берусь решать фундаментальные проблемы C++.

Однако же, если язык скатывается до конструкций «for a in 12;99;1», то всё чаще возникают ситуации, когда человек теряет контроль за структурой программы.

Можно спорить на счёт читаемости, но это вкусовщина, как сказали выше. Я не совсем понял, что такое «контроль за структурой программы», но если говорим о гибкости, то приведённая форма - это только одна из форм for. Всего их примерно 9:

for
for 0
for 1
for n
for *i in 10;0;-1
for *i @uint in 10;0;-1
for *a in v
for *a in b c d
for *b @bool in b @some_func c

В данном смысле язык близок к go.

При этом по уровню абстракций язык находится где-то на уровне C/C++/Pascal, так что я вообще не вижу смысла в его создании.

Нет. Язык намного примитивнее C++/Pascal и по уровню абстракций не дотягивает до них. Как это ни странно, смысл создания именно в этом.

Я как-то пытался исследовать, какие есть инструменты для статического и динамического анализа в разных языках. Что-то адекватное есть только для си и ассемблера. Есть какие-то примитивные утилиты для анализа кода Python, C# и даже C++ (возможно, среди коммерческих есть и не примитивные). Проблема здесь в двух вещах:

1. Сложность языков типа C++ ставит титаническую задачу перед создателем анализатора.
2. Постоянная изменяемость языков приводит к быстрому устареванию и к усложнению анализаторов.

То есть идём на встречу компьютеру, не забываю и о людях. Выше говорят, что моё упрощение мешает читаемости. Но я думаю, что это дело привычки. Чейнинг приближает код к естественному языку, поэтому проблем быть не должно.

Вместо var и let используется просто звёздочка. mref и cref не для этого

Ага, то есть, всё-таки экономим буквы.

Здесь на самом деле нет возврата трёх переменных. Возврата переменных у меня вообще нет. Здесь идёт изменение трёх переменных-аккумуляторов. Если поставить переменные справа функции, то их изменить будет нельзя, они станут константными аргументами
И вообще, в языке нет возврата данных (исключением можно считать обращение по индексу в массиве). Это сделано не столько для удаления мешанины из возвращаемых значений и ссылок в заголовках функции, сколько для чейнинга, который в языке распространён на всё, включая операторы.

Не вижу существеного отличия от передачи по ссылкам, помимо отличия формы.

Я не совсем понял, что такое «контроль за структурой программы», но если говорим о гибкости, то приведённая форма - это только одна из форм for. Всего их примерно 9:
В данном смысле язык близок к go

К фортрану:

do i = 1, 20 
   print*, i      
end do

i = 1
do
     print*, i
     if (i >= 20) exit
     i = i + 1
end do

Напоминаю, что фортрану уже больше 60 лет, и он был самым первым языком высокого уровня. С тех пор много чего нового появилось. В частности, ранний фортран имел вот такие циклы:

do 20 i = 10, 1, -2
         write(*,*) 'i =', i
20  continue

Нет. Язык намного примитивнее C++/Pascal и по уровню абстракций не дотягивает до них. Как это ни странно, смысл создания именно в этом

«Сделано не нами». Тот же паскаль очень приятно парсить, и я не знаю, почему тебе он не понравился.

Ага, то есть, всё-таки экономим буквы.

Если учесть, что прототипом был Python, то добавляем. Но упрек мог бы быть принят, если бы экономия ломала читаемость. Иначе экономия - это хорошо.

Не вижу существеного отличия от передачи по ссылкам, помимо отличия формы

Переменную, которую возвращают по ссылке в C++, например, я не могу тут же отдать другой функции. У себя я могу написать:

a b c @some_func_1 @some_func_2 @some_func_3

и функции последовательно применятся ко всем трём переменным. Могу написать так:

a; b; c @some_func_4 @some_func_5 @some_func_6

тогда функции будут применяться по очереди к одной из переменных.

Это я только часть возможностей по применению цепочек привёл. Они распространяются не только на переменные-аккумуляторы, но и на аргументы.

Про циклы в фортране. Может и похожи. Это же не значит автоматом, что они плохи.

Тот же паскаль очень приятно парсить, и я не знаю, почему тебе он не понравился.

Поверю, что парсить приятно. Но при создании программ многословность после программирования на C++, а уж тем более Python начнёт быстро раздражать.

Вообще, идея своего языка у меня возникла, когда мне надо было переписывать программу с Python на C++ для ОС uCLinux, в котором на тот момент не было питона, а если бы и был, то по быстродействию не прошёл бы, так как и C++ еле справлялся. Если уж C++ меня после питона раздражал многословностью, то что говорить о паскале. Ну и отсутствие stack trace, отсутствие перехвата деления на ноль и переполнения тоже не радовали.

По теме «сделано не нами». Когда я изучал OCaml, то пришёл к выводу, что это лучший из питонов со статической типизацией (они вообще не родственники, но было такое ощущение). Но у OCaml есть свои проблемы.

Если учесть, что прототипом был Python, то добавляем. Но упрек мог бы быть принят, если бы экономия ломала читаемость. Иначе экономия - это хорошо

Я как раз писал о том, что иначе экономия не значит почти ничего, потому что уже часов через десять программист начнет на автомате интерпретировать даже «LetsDeclare», ровно как и на автомате его писать по необходимости. Особенно если есть редактор с подсветкой.

Переменную, которую возвращают по ссылке в C++, например, я не могу тут же отдать другой функции. У себя я могу написать:
a b c @some_func_1 @some_func_2 @some_func_3
и функции последовательно применятся ко всем трём переменным.

В паскале аналогичная конструкция пишется так:

some_func_1(a, b, c);
some_func_2(a, b, c);
some_func_3(a, b, c);

Сложнее ли это, чем предложено тобой? А если я захочу сделать:

some_func_1(a, b, c);
some_func_2(a, b, d);
some_func_3(a, b, e);

? На мой взгляд, сам факт необходимости передавать одни же параметры по функциям говорят об избыточности разбиения на функции. Собсна, в твоих примерах я почти не вижу цепочек вызовов функций.

Про циклы в фортране. Может и похожи. Это же не значит автоматом, что они плохи

Я описал конкретно, почему они плохи, это ошибка, которую уже делали и забыли. Но ты ее возродил. Такого синтаксиса циклов нет ни в го, ни в питоне, ни вообще каком-либо современном языке. Что, кроме всего прочего, порождает усложнение привыкания человека, который пришел с другого языка. В питоне вообще нет числовых циклов как таковых, там для подобных целей применяется функция «range». которая имеет фортраноподобные аргументы.

Поверю, что парсить приятно. Но при создании программ многословность после программирования на C++, а уж тем более Python начнёт быстро раздражать

Как начнет, так и закончит. Более актуальными проблемами Паскаля являются, например, необходимость объявлять переменные строго до тела процедуры, что заставляет прыгать по коду в больших процедурах, необходимость дублировать одни и те же параметры процедуры в интерфейсе и реализации, чего не было изначально в Модуле Вирта и что появилось из-за возникновения перегрузки функций (одно имя при разных параметрах), и в итоге терминальной стадией рака это стало в Object Pascal, где попытка менять класс приводит к необходимости постоянно прыгать между началом и серединой модуля, что не является обязательной формой ни в смолтоке, ни в крестах, ни в жаве (в хронологическом порядке). В итоге лично для меня самой популярной функцией IDE стала возможность прыгать между объявлением и реализацией.

Если уж C++ меня после питона раздражал многословностью, то что говорить о паскале. Ну и отсутствие stack trace, отсутствие перехвата деления на ноль и переполнения тоже не радовали

Стэки есть и в крестах в отладочных сборках. А отсутствие обработки деления на ноль и переполнения — да, это специфичная для всего семейства сей беда, в паскале эти проверки есть.

Когда я изучал OCaml, то пришёл к выводу, что это лучший из питонов со статической типизацией (они вообще не родственники, но было такое ощущение). Но у OCaml есть свои проблемы

Почему-то я не чувствую у тебя окамля. Питон в индустрию пришел на замену лиспу, к слову, и сами лиспы начали перенимать систему типов от ML, в отличие от питона, чья типизация ближе к лисповой, — потому у меня не поворачивается называть окамль чем-то близким к питону, как C++ не близок к питону и как окамль не близок к башу.

Вообще, я бы советовал вместо окамля изучать более современные вариации ML, например, F# или ReasonML.

Про экономию больше нет смысла спорить - по второму кругу пошло. Значит каждый остаётся при своём мнении.

Такого синтаксиса циклов нет ни в го, ни в питоне… В питоне …для подобных целей применяется функция «range». которая имеет фортраноподобные аргументы.

В питоне range используется не только в цикле, поэтому он там имеет смысл. У меня такое только в цикле, поэтому range я убрал. В принципе, можно внести range. Будет так:

for *a @int in a @range 1 10 1

Подобная форма для for у меня уже есть (range нет, вместо него произвольная функция), так что будет уменьшение числа форм цикла. Это менее красиво, чем в питоне, но надо подумать.

Про паскаль я не понял, что это было: реклама или антиреклама?

Стэки есть и в крестах в отладочных сборках.

Не нашёл такого в g++. Может какие-то флаги нужны?

Почему-то я не чувствую у тебя окамля.

Потому что его там нет. Я его вспомнил потому как заявляется, что для него есть хорошие анализаторы кода.

До F# может когда-нибудь руки дойдут, всё-таки там должна быть нормальная стандартная библиотека (может всё богатство .Net, я не разбирался). Но так как конструкции из него постепенно переползают в C#, то скорее F# ко мне придёт, чем я к нему.

В любом случае, в F#, во-первых, используется .Net и сборщик мусора. Соответственно, он не для всех задач подходит. Во-вторых, такие языки написаны инопланетянами для инопланетян. Соответственно, по 8 часов, например, на нём писать затруднительно.

Про паскаль я не понял, что это было: реклама или антиреклама?

Я здесь ничего не продаю.

Стэки есть и в крестах в отладочных сборках.

Не нашёл такого в g++. Может какие-то флаги нужны?

https://stackoverflow.com/questions/77005/how-to-automatically-generate-a-sta...

До F# может когда-нибудь руки дойдут, всё-таки там должна быть нормальная стандартная библиотека (может всё богатство .Net, я не разбирался). Но так как конструкции из него постепенно переползают в C#, то скорее F# ко мне придёт, чем я к нему

Оба языка транслируются в один и тот же байткод CLR, так что взаимопроникновение фич неудивительно.

В любом случае, в F#, во-первых, используется .Net и сборщик мусора. Соответственно, он не для всех задач подходит. Во-вторых, такие языки написаны инопланетянами для инопланетян. Соответственно, по 8 часов, например, на нём писать затруднительно

В индустрии сейчас F# довольно широко используется.

Я здесь ничего не продаю.

Предлагать использовать Паскаль и тут же начинать его критиковать как-то странно.

Stack trace в g++ как всегда оригинален. Требуется заполнить весь код функцией backtrace(), либо прикручивать стороннюю библиотеку. Не этого я ожидал. Ну хоть что-то.

В индустрии сейчас F# довольно широко используется.

В hh.ru 7 вакансий в России против 3120 на C#. И то в 4 из 7 вакансиях про F# на всякий случай написали, а программировать придётся на C#.

Эта статистика показывает, что есть в мире какой-то процент гениев. Мне то что с того? Я обычный человек.

Ну и чтобы подытожить тему и ответить на некоторые вопросы, которые я игнорировал, приведу эту ссылку из темы про переход со второго питона на третий: Python Image Library и ее разработчики совсем все О_О? (комментарий)

В данном сообщении Pravorskyi спрашивает:

…я против использования старого неподдерживаемого софта/библиотек на публичных серверах. Но если это оффлайновое ПО, которое просто выполняет свои задачи для пользователя, то что мешает ему выполнять их дальше, кроме как принудительное ломание userspace?

Соответственно, «оффлайновое ПО, которое просто выполняет свои задачи» нельзя писать на питоне. Сегодня там ввели паттерн-матчинг, а завтра скажут, что это полумера без введения многострочных лямбд, для введения которых всем надо переходить на питон 4.

С другой стороны, для написания такого ПО на C++ требуется ресурсы, которых нет у, например, физика, математика и т.п., который реализует утилиту, нужную небольшому числу людей. Соответственно, тут нужен инструмент соответствующий критериям:

1. Простой.
2. Неизменяемый (очень редко изменяемый).
3. И раз мы уж говорим от математиках, физиках и близких к ним инженерах, то и о быстродействии забывать нельзя.

Теоретически, этим критериям соответствует Фортран. Значит буду в его сторону смотреть, заодно пытаясь embedded зацепить. Там тоже изменения не очень приветствуют, а необходимость в простом языке появляется, так как переход от всяких 8051 и PIC-контроллеров на ARM делает C не таким уже удобным инструментом для разработки.

Ок, вернусь когда будут наработки по библиотекам, связанным с обозначенными областями.

Как физик и прикладной математик хочу заметить, что уже дцать лет локальным стандартом у нас является связка питон (для интерфейса) + С++;-) Прямо вот сейчас занимаюсь прикручиванием интерфейса на третьем питоне к одному расчетному пакету.

У фортрана проблемы с выразительностью для чего то сложного + его мало кто сейчас знает.

Редко изменяемая утилита должна тем не менее кем то поддерживаться. Пройдет некоторое время и она протухнет просто потому что изменятся флаги компиляции например.

Я лет 20 назад писал утилиту для реализации интерфейсов приложений численного моделирования, еще под винду. На плюсах, со своим DSL, правда я таких слов тогда не знал. А потом перешел на линукс и на глаза попался питон… и я понял что Гвидо успел первым;-)

О, Genie переизобрели. Только собирается в плюсы.

Но ведь в питоне уже есть типизация.

Но это не типизация. Сравни хотя бы:

$ python3
Python 3.8.3 (default, May 14 2020, 11:03:12) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def quack(what: int) -> float:
...     return "quack" + what
... 
>>> quack(" string")
'quack string'

вот с этим:

$ racket
Welcome to Racket v7.6.
> (define/contract (quack what)
      (-> (and/c integer? (lambda (i) (> i 0))) inexact?)
      (+ 0.01 what))
> (quack "string")
; quack: contract violation
;   expected: integer?
;   given: "string"
;   in: an and/c case of
;       the 1st argument of
;       (-> (and/c integer? ???) inexact?)
;   contract from: (function quack)
;   blaming: top-level
;    (assuming the contract is correct)
;   at: readline-input:1.18
; [,bt for context]
> (quack -1)
; quack: contract violation
;   expected: ???
;   given: -1
;   in: an and/c case of
;       the 1st argument of
;       (-> (and/c integer? ???) inexact?)
;   contract from: (function quack)
;   blaming: top-level
;    (assuming the contract is correct)
;   at: readline-input:1.18
; [,bt for context]
> (quack 2.1)
; quack: contract violation
;   expected: integer?
;   given: 2.1
;   in: an and/c case of
;       the 1st argument of
;       (-> (and/c integer? ???) inexact?)
;   contract from: (function quack)
;   blaming: top-level
;    (assuming the contract is correct)
;   at: readline-input:1.18
; [,bt for context]
> (quack 2)
2.01

И второй пример ещё не настоящий Typed Racket, который можно достать.

Пройдет некоторое время и она протухнет просто потому что изменятся флаги компиляции например.

Флаги компиляции - недостаточная причина. Причина будет, если, например, поменяется требование по точности или быстродействию.

и я понял что Гвидо успел первым

Это так. Но он успел сразу во многих областях. И эти области тянут язык в ту сторону, в которую им надо.

Не совсем понял что подразумевается под интерфейсом. Если это графический интерфейс, то какой? Из того, что было сказано выше, получается, что полагаться в обсуждаемом случае можно только на tkinter, чтобы зависеть от изменений в ПО только одних авторов.

Флаги компиляции - недостаточная причина.

Вполне достаточная. Я делал make и все работало, теперь я делаю make и оно не работает.

Не совсем понял что подразумевается под интерфейсом.

Под интерфейсом понимается возможность написать пусковой файл на питоне. Иногда это сопровождается прикручиванием интерфейса командной строки. GUI для задач численного моделирования ненужен, если не говорить о вьюверах, но это отдельная история.

GUI бывает нужен когда софт отчуждается и передается инженерам которые не умеют программировать, а умеют только мышкой тыкать в диалог. Но это уже третья история, и да - тут Tkinter может помочь.

Согласен, что документацию в формате odt никто читать не будет. Я перевёл её в html, но Github выводит код документа вместо самого документа. Придётся с этим Markdown повозиться.

У гнутых проектов документация в texinfo, генерируется html вразбивку и сшитый, да ещё и pdf. И info-документы, да.

Я делал make и все работало, теперь я делаю make и оно не работает.

Можно пример для проекта на чистом C или C++? Какие флаги поменялись и к чему это привело.

Про интерфейс командной строки непонятно. В питоне есть cmd для этого, например, но не настолько же он уникален, чтобы питон прикручивать. Или я чего-то не понимаю?

Ещё хочу спросить, чем закончилась история с Python Imaging Library? Перешли на Pillow?

Дорогой Анонимус, отсутствие проверки типов в рантайме не является необходимым требованием для наличия статической типизации в языке. Если ты не проверил программу на питоне тайпчекером и запустил в интерпретаторе – ССЗБ. Тайпскрипт, например, тоже похожим образом работает (репортит ошибки, но код всё равно генерит).

Вообще в чём проблема-то? ТСу же не лень запустить свой компилятор, значит и тайпчекер запустить было бы не лень.

Можно пример для проекта на чистом C или C++? Какие флаги поменялись и к чему это привело.

Там флаги конпелятора делают из warning error.

Можно пример для проекта на чистом C или C++? Какие флаги поменялись и к чему это привело.

например когда -fPIC появился мне пришлось менять флаги компиляции, пользователи этого не заметили. А так бы они сидели в печали и смотрели в монитор, потому что make многие не знали.

Про интерфейс командной строки непонятно. В питоне есть cmd для этого, например, но не настолько же он уникален, чтобы питон прикручивать.

1. сам пусковой файл на питоне уже является интерфейсом

2. правильно написанный пусковой файл автоматом предоставляет CLI, причем юзеру для этого почти ничего не надо делать - используется monkey patch и свои библиотеки на основе интроспекции. В итоге из ком.строки можно не только менять параметры расчета но и запускать серии расчетов. Cmd я не использую.

Ещё хочу спросить, чем закончилась история с Python Imaging Library? Перешли на Pillow?

Нет, и не в ближайшие три месяца точно, нет времени. Впрочем похоже я вообще другим путем пойду;-)

Дорогой Анонимус, отсутствие проверки типов в рантайме не является необходимым требованием для наличия статической типизации в языке.

Ну так тебе и сказали за Typed Racket, где эта проверка уже не совсем в рантайме.

Если ты не проверил программу на питоне тайпчекером и запустил в интерпретаторе – ССЗБ. Тайпскрипт, например, тоже похожим образом работает (репортит ошибки, но код всё равно генерит).

Это называется динамической типизацией. Если есть типизация, но её можно не использовать, значимость такой типизации резко падает до нуля.

Ну так тебе и сказали за Typed Racket

Мой поинт в том, что ТСу вместо изобретения уродливого питона с типизацией стоит взять обычный питон с типизацией. Я бы не сказал, что скобочная дристня лучше (критерии: комьюнити, тулинг, читаемость).

Если есть типизация, но её можно не использовать, значимость такой типизации резко падает до нуля.

Ни одна система типов не спасёт тебя от логических ошибок и код неизбежно сопровождается тестами, которые тоже можно не запускать. Ценность тестов тоже ноль? Конечно нет. В любом случае всегда есть тулинг, который делает какую-то вспомогательную работу и добавить туда вызов тайпчекера ничего не стоит (CI, IDE - нутыпонел™). Я уж не говорю, что ТС пишет в блокноте++ и запуск его компилятора не интегрирован никуда. А для питона есть IDE, где типы проверяются во время написания кода. Где он быстрее ошибки типизации будет находить?

Мой поинт в том, что ТСу вместо изобретения уродливого питона с типизацией стоит взять обычный питон с типизацией.

Обычный и так уродлив, хуже него только васик. Ну, может, js+php.

обычный питон с типизацией

Мы уже поняли, что она не энфорсится, а значит, у нас осталась динамическая типизация с никому не нужными комментариями в функциях.

Я бы не сказал, что скобочная дристня лучше (критерии: комьюнити, тулинг, читаемость).

Так как

Обычный и так уродлив, хуже него только васик.

, то твой аргумент инвалид. Поехали. Вместо комьюнити кучка анскильных хипстеров, не осиливших энфорсинг типизации, преемственность версий и многопоточность. Даже кредо своё продали, судя по нововведениям.

тулинг

Тулинга ноль, не считая костылей в виде пипа. Костыли, впрочем, нужны только потому, что на совместимость регулярно забивают. Впрочем, если языку нужен тулинг, значит, пора на жабку.

читаемость

На пару порядков выше, особенно исходя из примера про т.н. типизацию. Ящитаю, выдержанный в едином стиле синтаксис без разночтений и альтернатив — верх простоты и читаемости. А уж многострочные лямбды гораздо читаемей хаков вида lambda :[action(),action2()][1]

Да даже взять comprehensions: в питоне их масса и всё равно они не покрывают те же строки. А всё потому, что те, кто пользуются comprehension’ами, не укладывают в голову то, что должно делаться парой функций.

В том же питоне шлёпают синтаксис на каждый чих. Ну и зачем мне перл, который говорит, что он не перл?

CI, IDE - нутыпонел™

А для питона есть IDE, где типы проверяются во время написания кода.

Ясно, свидетель IDE вылез. Сорян, проблемы IDE меня как-то не касаются.

Внимание, вопрос: чем такая «типизация» отличается от комментариев и docstring’ов? Ничем. Ну сойдётся оно у тебя в ide. Ну потешил ты свои мозги. А дальше-то что? Где практическая польза, которая у тех же тестов хотя бы может быть?

Мой поинт в том, что ТСу вместо изобретения уродливого питона с типизацией стоит взять обычный питон с типизацией.

Поинт понятный, но для меня бессмысленный. Там где питон уместен, мне вполне и динамическая типизация подходит. Я же нацеливаюсь на области, где до недавнего времени и C++ был избыточен. Если нужна работа в реальном времени, например, то языки со сборщиком мусора не подходят. Там, где ОЗУ измеряется мегабайтами, интерпретатор будет занимать бесценное место, если влезет.

Другое дело, что я пытался прощупать где бы ещё мой язык мог пригодиться. Предполагал, что оффлайн утилиты. Может какие-то небольшие игрушки. Но пока меня убеждают, что в данной области перспектив нет.

Анон, судя по твоему посланию, ты читаешь невнимательно (или тралишь тупостью, хз). Я даже курсивом выделил некоторые вещи, а ты продолжаешь топить как будто этого не было.

Так что изложу мысль кратко: я предложил вариант, как ТСу сделать с теми же усилиями более полезный продукт.

О чём тут спорить?

Ясно, ты включил шланга.

Если нужна работа в реальном времени

Но тебе она не нужна, так?

языки со сборщиком мусора не подходят

Сборщик мусора это часть рантайма, а не языка. Ничто не запрещает тебе сделать компилятор питона в C++ с подсчётом ссылок как в свифте. Это точно не сложнее твоего текущего проекта, зато тулинг есть (тулинг это не только пип, как считает анон выше, а ещё и всякие IDE, раннеры для CI, тайпчекеры и т.д.)

Там, где ОЗУ измеряется мегабайтами, интерпретатор будет занимать бесценное место.

Ну, сделай компилятор в С++ как я написал выше. Вместо своей либы сделай либу для типизированного питона. Вообще не понятно как ты в своём языке памятью управляешь. Если не хочешь сборщик мусора и подсчёт ссылок, то могу предложить костыль в виде метода __exit__() на объектах.

Я же нацеливаюсь на области, где до недавнего времени и C++ был избыточен.

«Был избыточен» – то есть сейчас уже не избыточен, получется. Что за области такие?

где бы ещё мой язык мог пригодиться.

О чём и речь. Язык есть, а области, где он нужен, – нет. Следовательно, сделан он был не для решения задач, а для закрепления материала из книги. Соответственно, область применения – иллюстрация к самой книге.

Но тебе она не нужна, так?

Моя программа должна выдать сигнал на работу внешнего устройства через единицы миллисекунд после поступления сигнала с датчика. Иногда даже спустя доли миллисекунд.

Ничто не запрещает тебе сделать компилятор питона в C++ с подсчётом ссылок как в свифте. Это точно не сложнее твоего текущего проекта

Ничего себе «не сложнее». Ты переоцениваешь мои возможности.

Вообще не понятно как ты в своём языке памятью управляешь.

Никак. Контейнеры сами очищаются по деструктору, а других возможностей выделить память вне стека не предусмотрено.

то есть сейчас уже не избыточен, получется. Что за области такие?

embedded низкоуровневый. Раньше контроллерами типа 8051 обходились вполне, сейчас производители от них уходят в пользу ARM-микроконтроллеров (не путать с процессорами). Соответственно, если раньше даже без ОС обходились, то сейчас и их внедрять начали (включая даже всякие урезанные линуксы).

Язык есть, а области, где он нужен, – нет.

Применял я микроконтроллер Silabs C8051F120. Хороший микроконтроллер, периферия богатая, частота 100 МГц. Производитель снял его с производства. Аналогов с такой частотой и периферией нет, да если и есть, то никто не гарантирует, что их тоже не снимут с производства. Надо переходить на ARM. А там уже достаточно мощи для C++, а значит и моего DSL. Сразу писать для микроконтроллеров не эффективно, поэтому пока для ПК пишу прототип.

embedded низкоуровневый памятью управляешь […] никак

Если честно, я всё равно не понимаю, как твой язык без ручного управления памятью будет полезен там, где памяти мало.

Допустим, ты хочешь занять нишу между сишкой для микроконтроллеров и го для пекарен. Ну, ты сам сказал, что микроконтроллеры сейчас делают мощные, с урезанныами линуксами, а слабые не делают. Значит, через 5 лет, когда ты закончишь девелопить, твою нишу окончательно вытеснят «микроконтроллеры» нового поколения с полноценными линуксами и щедрой оперативкой, где можно будет писать на го и питоне. Недальновидно получается.

«микроконтроллеры» нового поколения с полноценными линуксами и щедрой оперативкой, где можно будет писать на го и питоне

Какие влажные мечты.

При управлении памятью вручную (если не говорим про какие-то хитрые аллокаторы) выигрыш больше в предсказуемости момента освобождения памяти, а не в размере занимаемой памяти. Контейнеры типа std::vector почти не занимают лишней памяти и освобождаются в деструкторе при выходе из функции в которой были созданы. Экономно и предсказуемо.

Значит, через 5 лет … «микроконтроллеры» нового поколения с полноценными линуксами и щедрой оперативкой, где можно будет писать на го и питоне

Ну линуксы там излишество, обычно пихают какой-нибудь RTOS. Питон и го жирные, Rust вроде бы используют уже. Но Rust сырой. Лучше я буду C++ использовать с небольшой надстройкой.

Значит, через 5 лет

Да, забыл прогноз прокомментировать. Это всё-таки промышленность, там так быстро ничего не меняется.

Ну, какая разница. Главное, что ниша маломощных мк сокращается, а не растёт.

Про нишу трудно предсказывать. Те же 8051 и PIC не совсем вымерли, а остались там где требуется крошечный размер и малое потребление, типа мышкой управлять. Могут и STM32 в какой-то нише долго ещё прожить.

В любом случае, если ниша есть, то туда может прийти Rust или D. Поэтому одной теоретической низкой требовательности к ресурсом может быть недостаточно. Это я понимаю. Поэтому надо к языку прибавлять дополнительные инструменты, типа анализаторов и генераторов тестов, которые мне будет сделать проще, так как сам язык намного проще.

Кроме того, меня радует понимание того, что в большинстве случаев программа на моём языке будет раза в полтора меньше по числу символов, чем программа на Rust или D. Можно даже проверить если кому не лень. У меня есть программа-угадайка для заучивания английских слов: https://github.com/kupriyanov-sn/StodinDSL/tree/master/examples/guesser

В принципе, программа небольшая, имеет прототип. Можно было бы сравнить с Rust или D. Я сравнивал с Python (при чём в нём я использовал готовый cmd для ввода с консоли). По символам вышло примерно одинаково.

Можно было бы сравнить с Rust или D.

Нашёл проект: https://github.com/cedelmaier/primeSieveProjects Разработчик решает задачу «решето Эратосфена» на разных языках, с применением примерно одних названий для переменных и функций (решения подглядывает отсюда: http://rosettacode.org/wiki/Sieve_of_Eratosthenes , но там нет единообразия).

Реализовал на своём языке (выложено в примерах). Посчитал количество символов для трёх функций (eratosthenes, iprimes2, primes235) без комментариев и символов конца строки. Для Nim сделал отступ 4 пробела для единообразия (автор использует 2 пробела). Go и Java жульничают, табы используют. Тоже заменил на 4 пробела. Результаты вышли такие:

python 1419 stodin 2193 nim-4 2241 d 2298 rust 2460 go 2660 java 2855 c 2944

Тест, конечно, очень грубый (примеры программ 5-летней давности, опыт автора мне неизвестен, математические формулы везде будут примерно одинаковы). Так как stodin скобок не имеет, то приходилось вводить дополнительные переменные для длинных формул, поэтому я думал, что он будет в конце списка. Ну fill для массивов (как в Java) нет пока в библиотеке.

Согласен, пример на си странный. Но в любом случае, си останется на уровне джавы. Раст чуть ниже будет.

Но моя цель была в другом - сравнить свой язык с Растом и Ди. Если Раст «жульничал»,то мне даже лучше.

Почему в одном случае пробелы есть, а в другом нет

жульничал

Чел перфоманс сравнивал, а не длину программ. В длине всё равно победит GolfScript.

А вообще глупо брать за основу код какого-то нонейма с тремя хеллоу-ворлдами.

Если хочешь оценить синтаксис, то используй научный подход https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D0%BF%D0%B5%D1%80%D1%82%D0%BD%D0%BE%D0%B5_%D0%BE%D1%86%D0%B5%D0%BD%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

Экспертная оценка - субъективный подход, особенно в данном случае. Код нонейма же хоть и очень грубо, но подтвердил теоретические рассуждения.

Сравнение с гольфскриптом не принимаю. Я, например, считаю, что мой код читаемее данного кода на расте, например. Питон тоже тут хитровывернутый. А самая читаемая - джава, которую я взял за образец при написании своего примера. Правда, в третьей фунции что-то не заработало. Пришлось по другим примемерам править.

… примемерам

Каюсь.
Тоже часто «косячу».
Плачу горькими слезами, но прав на исправление поста - нет.

Владимир

Владимир в теме отметился. Жизнь прожита не зря.

Да, соревнование по краткости - это не главное. Надо написать что-то большее, чем хелловорлд. Тогда по полезности мой язык обойдёт один из приведённого списка.

Владимир в теме отметился. Жизнь прожита не зря.

В чем концепт вашего языка программирования?

Жизнь дается всего один раз, и прожить ее надо так, чтобы не было мучительно больно за бесцельно прожитые годы

PS: Хорошее заслуживает похвалы, а плохое - нет.

Владимир

… In addition, structures that do not have nested structures and containers (except string) can be initialized with a list of values at the stage of creating a variable

Хотел было спросить имеется ли возможность инициализации сложных структур …
Реализация не скажу что сложная, но нюансов много.
У меня /в частности/ возможна инициализации сложных структур в run-time в нескольких вариантах:

 - а-ля 1С;  

 - C++;  

 - extended C++  
   Для некоторых дочерних структур могут отсутствовать данные для инициализации, ...

Владимир

Я не совсем ясно представляю, что значит «концепт», поэтому просто изложу идеи, которые держу в голове, при создании языка. В общем-то это тестовая площадка для проверки редко используемых техник программирования, а также для проверки необходимости популярных. Приведу список:

1. Цепочки (оно же паровоз), которые обычно используются во встроенных DSL. Я подробно уже расписывал в теме, чем мои цепочки лучше классических.

2. Упрощённая модель управления памятью. Смысл в том, что если не использовать ФП и изощрённые техники ООП, типа инверсии зависимости, то будет достаточно только переменных в стеке, а также контейнеров типа std::vector, std::map, std::string, которые сами выделяют и освобождают нужную им память.

3. Связан с пунктом 2. В популярных языках широко распространено явления, которое я называю GOTO данных. То есть лапша из ссылок одного класса (структуры) в другой и обратно. Это встречается не только у новичков, а и, например, у любителей модной сейчас концепции «инверсия данных». Я хочу проверить, что будет, если обрубить эту возможность, убрав ссылки везде, оставив их только в аргументах функции. Агрегации нет, есть только композиция. Если потребуются деревья, то можно использовать, например, массив структур, которые могут содержать такой массив.

4. Связано с пунктом 2. В функциях нет возвращаемых значений. Вместо этого используется удобный доступ к ссылкам в аргументах функции. В функциях же используются только изменяемые и неизменяемые ссылки. Это упрощает синтаксис.

5. ООП и шаблонов почти нет, за исключением тех, что есть в стандартной библиотеке и внешнем C++ коде. Классы и шаблоны - довольно сложные техники программирования, сильно усложняющие поддержку кода при неправильном использовании. Поэтому я в синтаксисе языка убрал создание классов и шаблонов, оставив только использование внешних.

6. Характеристические тесты, создаваемые автоматом. Для рефакторинга рекомендуют использовать юнит-тесты. Но на них обычно нет времени, да и нужен опыт, чтобы понимать, как их создать. Поэтому предполагается создать генератор характеристических тестов, которые будут использоваться для контроля изменений при рефакторинге. Не уверен, что осилю, но язык создавался с учётом этой задачи. Это ещё одна из причин, почему пришлось отказаться от классов и шаблонов.

Хотел было спросить имеется ли возможность инициализации сложных структур

Нет. Только для простых, либо инициализация для сложных по умолчанию. Плата за отсутствие скобок.

Нет. Только для простых, либо инициализация для сложных по умолчанию. Плата за отсутствие скобок.

А ссылки, работа с памятью, … ?

Владимир

Нет ссылок кроме как в функциях и через использование массивов и словарей. Работу с памятью считаю unsafe. Отдельный режим для unsafe не стал делать, ибо думаю, что он не нужен, когда есть простая возможность подключать код C++.

Кстати, если ещё актуально, документация на русском: https://github.com/kupriyanov-sn/StodinDSL/blob/master/readme_rus.md

При этом, она, естественно, не переводная, а оригинал.

Нет ссылок кроме как в функциях и через использование массивов и словарей.

Защиты от «дурака» нет.
Да и не возможно разработать компилятор в котором «дурак» не написал бы «дурацкую» программу.

Алгоритмы часто и густо создают объекты.
Как можно такие алгоритмы реализовать без возможности работы с памятью?

Владимир

Если требуется полиморфизм, то будет проблема. Иначе память выделяется через контейнеры. Создавайте объектов одного типа сколько надо.

Про инициализацию сложных структур. Можно вместо скобок на отступах реализовать. Но пока потребности нет.