- да, да, - https://github.com/web-standards-ru/dic … issues/186

При чём тут неполикорректность? Рефкаунтинг мёртв. Посмотрим, посмотрим на borrowing.

У меня критерий простой - исходники могу собрать в своей Calculate Linux?
Да - годный язык (Кумир, 1Скрипт, Яр).
Нет - негодный язык (Глагол, Кантор)

Отредактировано Лис (2017-03-19 15:48:24)

С транспилятором вопрос неоднозначный: с одной стороны транспилируемый язык кагбэ "ненужен", но с другой -- позволяет быстро вывести язык в народ и продемонстрировать его идеи, если они есть. Что ни говори, а разработка годного кодогенератора в машкод для языка сложнее Оберона не под силу разработчику-одиночке. Не нужно также забывать, что даже Андерс Хейлберг занимается, по сути, разработкой транспилятора.

Раньше я боялся транспиляторов и разработку транспилятора считал недостойной настоящего разработчика ЯП. Мое мнение поменял Nim. Своим примером он показывает, насколько важны идеи и внутреннее представление языка, позволяющие легко реализовывать новые оконечники ("бэкенды"). С точки зрения концепций в Nim нет ничего особенного, -- так, несколько прикольных идей на грани вкусовщины, а в целом звезд с неба не хватает. Тем не менее, работающая реализация, и оп -- язык уже в миру.

Думаю, что Кантор ничуть не хуже Nim в плане концепций, и быстрый вывод его в мир в виде транспилятора репутации не повредит. Наоборот, благодаря своим возможностям даже в виде транспилятора Кантор сможет делать такие выкрутасы, которые кажутся невозможными. Тут главное -- не стремиться к результату ради пускания пыли в глаза, как предлагали мне некоторые "инвесторы", а по-честному развивать проект, делая свое дело.

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

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

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

Вспомнить можно. Но какую именно сегоднюшнюю трасляцию вы имеете в виду?

Что касается кодогенерации она не сложная. Но по числу строк, у меня, она занимает столькоже сколько и парсер.

Я тоже не понял. Не вижу в языке какой-то стержневой концепции и/или критической массы нововведений, заставляющей бросить всё и писать на нем.

Помимо этого, если язык позиционируется как транспилируемая метасистема (как Haxe), не обозначено или не акцентировано самое главное — идеология поддержки чужих библиотек, то есть метапрограммирования. К примеру, я хочу сделать метапрограмму над VCL, Qt и wxWidgets. Что мне делать? Полагаться на стандартную библиотеку языка? Как расширять ее? Как добавлять поддержку других библиотек, скажем SDL или чего-то из JavaScript? Где уровень абстракции?

это не проблема, что гарантии имеют цену.

"Не он один". Борис Файфель (homelisp.ru, язык HomeLisp) и Юрий Копнин (visual-t.ru, язык Дизель-паскаль) тоже мне вежливые отписки прислали. Кагбэ намекает.

Затем, что генерировать код под разные платформы - трудоёмко. Сейчас в AL-IV порядка полусотни тысяч строк.
Почему генерация намного сложнее синтаксического разбора? Потому что это игра по чужим правилам.
Если бы пугливый Лис ранее читал сообщения внимательно
(перенёс первоначальные обсуждения из скрытого раздела, а то он его теперь не читает, т.к. требуется вход),
то знал бы и про ключевые слова.

В любой задаче нужно расставлять порядок полезности:
Лучше ли обрусить один язык под разные платформы или для каждой обрусить свой или обрусить один уже работающий под разные платформы или генерировать код в него из новорусского ЯП?
А как обеспечить доступность полученных исходников, если изначально участники знают разные языки?

Неплохо было бы иметь некоторое сравнение. Про Haxe в русской вики, также гугл находит несколько статей на хабре (там пара десятков по тегу), а про stella на русском языке - нет.

MihalNik
Кстати, а почему вы ещё не русифицировали ваш AL-IV, там же всего нечего ключевых слов менее 80 штук?

Есть такая маленькая фирма IBM - всего три буквы.  Так вот ещё до создания первого персонального компьютера эта фирма имела филиалы в более чем 50 странах мира. И поставляла механически машины для обработки статистических данных, в том числе выборные машины.
Так вот эта фирма потратила кучу средств на локализацию и родила не одну технологию. И прочитать про их технологии можно на их нем сайте. (Такой дурацкий поиск)
К чему это я - таблица, а вернее словарь эта первая идея которая приходит.  Но увы не последняя. Потому что перевод, а вернее локализация сложнее так как требует учитывать культурную среду.

Посмотрел я AL-IV. Первый и основной недостаток этого переводчика в том что он не учитывает культурный слой выходного языка. К примеру отсутствует проверка типов. Так же целый тип привязывается к целевому компилятору. Это значит что неизбежны ошибки диапазонов.
Ещё приоритеты операторов в том же Си и Delphi разные. И культура писать в Си++ для ввода вывод используются <<, >> в Delphi это read, write, format.

Прерывание цикла на каждом 65536 круге идея дурацкая. Лучше чем сигналы UNIX, и точно лучше чем параллельность в Си++14. Я бы асинхронность сделал через сигнала/слоты как в Qt. И
А для параметризованных циклов обязательно emit any.

Отредактировано Павиа (2017-06-25 20:12:17)