Ремесло программиста

Объявление

форум на движке phpBB доступен для тестирования
www.strategia.space
www.strategia.space/forum/
по предложению Лиса - канал на Matrix - #remdev:matrix.org

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Ремесло программиста » Общие вопросы » Язык программирования АЛФОР


Язык программирования АЛФОР

Сообщений 1 страница 30 из 46

1

Мало кто знает, что с давних времён Владимир Кладов разрабатывал свой язык, но я когда-то запомнил, и, почему-то мне кажется, под названием "Astral",
которого позже я уже никогда не видел, если вообще не подвела память.

Так совпало, что ковыряясь в веб-архиве после сноса тем с ruscomp'a, в очередной раз в голове это всплыло и обнаружил:
https://web.archive.org/web/20150801204 … ladov.org/

А внизу там написано следующее:

Clavier - спецификация языка программирования, который я пытаюсь разработать.
Цель создания этого языка - получить инструмент разработки максимально надежных, устойчивых, безотказных (и в то же время, достаточно быстро работающих) программ. Так же преследуется цель получить в том числе и отсутствие какой-либо зависимости от платформы: предполагается изготавливать не прямой компилятор для каждой платформы, а компилятор, формирующий код на одном из языков программирования, таких как C, C#, Java, Pascal, ...

Собственно это было оно:
https://web.archive.org/web/20150218193 … IER_RU.htm
В конце упоминается даже вопрос локализации кода.

Тогда по названию СLAVIER уже отыскал:
http://clavier.link/index_RU.htm

Язык программирования AL-IV

Слежу с конца декабря, т.е. получается, почти с самого начала его выкладывания.
Дело движется:

16.03.2017 - новая версия 0.53

Исходники открыты (sourceforge).

Чуть позже в какой-то ностальгической теме по малым размерам программ вспомнил библиотеку KOL
и на форуме мастеров делфи узнал про переезд сайта автора (там же он ссылается, что занят AL-IV),
тогда откопал немного предистории:

"Простой" безопасный платформенно-независимый язык императивного объектного программирования SOL (Safe Objective Language)
Версия 22 (17 января 2008 г.):

https://web.archive.org/web/20090902141 … ammer1.htm
Тут видно, что была версия 2010 года под тем же названием, но самой страницы нет:
https://web.archive.org/web/20130716025 … author.htm

2

Ух ты, какая новость и какое исследование! Да, я помню, что Владимир Кладов начинал было разрабатывать свой язык, но плотно не следил. Новость очень интересная, с удовольствием ознакомился с материалами -- сколько смог.

Взглянул на сам язык. По ощущениям он похож на Оберон и Nim. На последний -- подходами к регистрозависимости и константным функциям. Но... написан на C#. Я разочарован. Он еще и транспилятор...

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

3

Freeman написал(а):

транспилятор

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

Freeman написал(а):

По самому языку свое неполиткорректное мнение пока высказывать не хочу


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

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

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

4

Он еще и транспилятор...

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

5

MihalNik написал(а):

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

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

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

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

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

6

Freeman написал(а):

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

Это просто мало кому нужно вообще, кроме разработчиков/производителей самих машин непосредственно за кодогенерацию никто доплачивать не будет.

Freeman написал(а):

с одной стороны транспилируемый язык кагбэ "ненужен"

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

Отредактировано MihalNik (2017-03-19 23:45:36)

7

MihalNik написал(а):

Это просто мало кому нужно вообще, кроме разработчиков/производителей самих машин непосредственно за кодогенерацию никто доплачивать не будет.

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

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

8

Freeman написал(а):

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


Википедия не в курсе про специальный язык для транспиляторов:
https://en.wikipedia.org/wiki/Source-to-source_compiler
https://en.wikipedia.org/wiki/Language- … cification

Вы же не XSLT с XML имеете в виду?
"Xslt is a general purpose transform tool which can be used between many different technologies, to create such a derivative code pipeline"

Отредактировано Лис (2017-03-20 05:36:53)

9

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

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

10

http://clavier.link/index_RU.htm

Я пока не понял, в чём смысл языка.

11

У кого-нибудь есть связь с автором? Его бы сюда позвать... Вроде нашёл, отправил письмо. Не знаю, правильный ли адрес.

Я бы хотел заслушать, как автор предполагает реализовать объект "двусвязный список". Мне кажется, проблематично с его подходом к владению. Т.е. реализовать можно, а эффективно реализовать (чтобы удаление известного узла имело сложность О(1) - пока не вижу как). Может быть, автор прояснит.

12

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

Надеюсь, автор смотрел на haxe, который подобен в том смысле, что он транслируется в несколько разных других языков. Другой подобный проект - stella.

13

budden написал(а):

Я пока не понял, в чём смысл языка.

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

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

С точки зрения разработки Кантора

Не вижу никакого смысла связываться с архитекурно архаичной VCL или идеологически чуждой Qt, какие бы хорошие абстракции над ними не стояли. Кроме того, что касается VCL (и FCL) в развитии Кантора есть "секретный пункт", который позволит сделать всё на порядок лучше, нежели простая транспиляция.

14

budden написал(а):

Я бы хотел заслушать, как автор предполагает реализовать объект "двусвязный список". Мне кажется, проблематично с его подходом к владению. Т.е. реализовать можно, а эффективно реализовать (чтобы удаление известного узла имело сложность О(1) - пока не вижу как).

А в чём ты видишь проблему с двусвязным списком? У него же есть "слабые указатели". В одну сторону список связываем сильными указателями, в другую - слабыми.

15

III.1.c, ПРАВИЛО

"В частности, объект не может ссылаться на объекты своего класса."

16

budden написал(а):

"В частности, объект не может ссылаться на объекты своего класса."

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

17

Я бы сказал, что это или _утечка_ памяти, или удаление будет не О(1). Оба варианта неприемлемы для ЯП общего назначения.

18

ПОтому что мы либо не убиваем удаляемый элемент, а лишь удаляем его из цепочки ссылок - это утечка памяти.
Либо мы убиваем удаляемый элемент.

Но владелец (сам объект список) должен как-то знать все объекты, которыми он владеет и из них выбрать именно тот объект, который мы хотим удалить. Хотя тут я слегка вру - мы можем как раз использовать для этого двусвязный список, который написан уже на базовом ЯП и не подчиняется ограничениям АЛФОРа.

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

Итак, внезапно, любой объект потяжелел на целых три указателя.

Вывод: всё же можно сделать удаление ценой О(1), хотя получится существенно дороже, чем традиционный (небезопасный) двусвязный список.

Придумываем следующий каверзный вопрос.

Отредактировано budden (2017-05-15 20:26:42)

19

budden написал(а):

дороже, чем традиционный (небезопасный)

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

20

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

21

Ну, может, не десятка, но тройка - запросто.

22

Автор пока отказался участвовать в нашем форуме. Ну ладно, может ещё надумает :)

23

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

24

Вы как-то не похожи на целевую аудиторию. Я бы тоже не стал:

MihalNik написал(а):

Там где были поставлены ясные цели (концепт, AL-IV) - есть программы, есть сопроводительная документация, но что делали бы их разработчики тут?

Я думаю, для них найдётся куча более людных мест. Форум из дюжины человек? Серьёзно?

Freeman написал(а):

мне вежливые отписки прислали. Кагбэ намекает.

Где-то там на Канторовых системах чёрным по-белому написано, что автор не будет за кем-то лично бегать.

Список делается просто: размещение дин. массивом с элементами (или ссылками на них), в которых есть пара чисел - номер пред. и след.

25

Это уже похоже на разговор, если сделать вам небольшую скидку. Автор АЛФОРа написал примерно то же самое: не нужны списки, когда есть массивы. Тогда такой вопросик: мы строим очень большой список, добавляя в него элементы по одному. Массив периодически переполняется и его нужно перевыделять. Сколько стоит в реальной жизни (допустим, под Windows) перевыделение массива? Ожидаю ответ в терминах О(), где размер списка стремится к "безконечности".

Отредактировано budden (2017-05-17 21:37:00)

26

Лис писал:

В качестве целевого языка (в который генерировать код из EBNF-правил) настойчиво предлагают AL-IV. Хотелось бы чтобы кто-нибудь его не только разрекламировал, но и описал как начинать пользоваться языком AL-IV.

http://clavier.link/index_AL-IV_start_RU.htm

AL-IV:   Как начать программировать

P.S.: статья написана довольно давно, поэтому надо см. историю изменений, особенно в плане выдачи конечных исходников и поддержки платформ (например, там ещё не указан С++, а он есть).

Текущее состояние проекта (июнь 2017):

готовы компиляторы с AL-IV в C#, С++, Delphi32/Free Pascal и Java;
имеется возможность создания консольных приложений;
готова библиотека визуальных компонентов, позволяет создавать приложения с графическим интерфейсом для Windows, на Java для десктопных сред (Windows, Linux, MacOS, ...).
имеется поддержка OpenGL.

27

в нём ключевые слова - английские. Зачем он нам такой?

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

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

budden написал(а):

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

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

Оффтопик про разработчика другого ЯП

по запросу "stella" гугл почему-то выдал язык программирования Factor, разработанный "нашим" Славой Пестовым:

Трудовую карьеру начал в Google, в настоящее время работает в Apple в качестве одного из разработчика языка программирования Swift

28

Как самим автором когда-то рассматривался вопрос локализации (из вебархива ранних версий, на 4 сен 14-го года):

IV. 4. Локализация

IV. 4. a. Локализация приложения

Локализация приложения - это, прежде всего, перевод ее интерфейса на язык пользователя.
Сюда входит перевод текстовых сообщений и модификация графики, содержащей текстовые сообщения и символику, адаптированную к определенной языковой и культурной среде.
Для эффективной локализации приложения во многих случаях достаточно обеспечить механизм, замещающий строчные константы набором соответствующих значений непосредственно в момент выполнения.
Даже если замещать следует графические ресурсы, они тоже должны иметь строковые имена: их замещение автоматически вызовет замещение графических, звуковых, анимационных и т.п. ресурсов, зависящих от языка пользователя.
Для этого компилятору указывается соответствующая опция "необходима поддержка динамической локализации строк".
При ее включении ВСЕМ строчным константам сопоставляются уникальные идентификаторы.
Обращением к системной функции translateApplication приложение выполняет замещение всех строчных "констант" новыми значениями из внешнего файла.
Обратная функция untranslateApplication позволяет выгрузить текущий набор таких констант вместе с идентификаторами.
При таком подходе адаптацию приложения к требуемому языку вполне сможет выполнить пользователь приложения.
Со стороны разработчика требуется установить только одну опцию компилятора и выполнить вызов translateApplication либо один раз в начале работы программы, либо по команде пользователя.
IV. 4. b. Локализация кода

Допускается использовать использовать имена переменных и функций, записанных произвольными символами внутри апострофов.
Так же, произвольные символы могут использоваться для именования типов данных (их имена всегда записываются в угловых и фигурных скобках).
Если такие именования используются в коде, то:
в список "штрафов" модуля должно быть включено определение LANGUAGE=xx, где xx - двухбуквенное наименование национального языка, использующегося для таких именований;
в список "штрафов" модуля должно быть включен модификатор UNTRANSLATABLE, если есть хотя бы одно имя, для которого нет хотя бы краткого именования латинскими буквами;
каждое такое имя в обязательном порядке должно содержать хотя бы один краткий синоним на английском языке;
кроме имен из произвольных символов внутри апострофов, могут использоваться имена типов в фигурных и угловых скобках (кроме тех символов ASCII, которые не считаются разрешенными для использования в таких именах для обычных - английских имен);
кроме того, такие имена не должны содержать символов '<', '>', '{', '}', '[', ']', '(', ')', ',' и символов апострофов - в никаких случаях - как в апострофах, так и в угловых и фигурных скобках.
IV. 4. c. Локализация ключевых слов

Для локализации ключевых слов не требуется особых правил самого языка.
Для этого достаточно наличие текстового редактора, который по заданному словарю будет уметь переводить ключевые слова с английского языка на заданный при отображении кода.
И автоматически заменять введенные слова на национальном языке в английские, в соответствии с контекстом.
В текстовом файле, содержащем код, ключевые слова должны сохраняться в английском написании.
Пример (так "русифицированный" код может выглядеть при его просмотре в окне специального редактора):
ФУНКЦИЯ 'Число_фибоначчи' | 'Фибоначчи' | Fib (
        <цел> n) ================> <длин целое>
    <вещ> 'Фи' | Fi = (1 + 5.'корень')/2
    ВЕРНУТЬ ===================>(
           'Фи' ^ n / 5.'корень').'длин целое'
Хранение этого кода в текстовом файле:
FUNCTION 'Число_фибоначчи' | 'Фибоначчи' | Fib (
         <цел> n) ===============> <длин целое>
    <вещ> 'Фи' | Fi = (1 + 5.'корень')/2
    RETURN =====================>(
          'Фи' ^ n / 5.'корень').'длинное целое'

29

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)

30

Павиа написал(а):

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

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

не учитывает культурный слой выходного языка.

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

Павиа написал(а):

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

Не увидел там словарика, в котором можно их просто поменять :D (а у Utkin'a в В-1 можно было поменять, но код не генерировало - везде засада :crazy: ), т.е. лень их выписывать, но если серьёзно - автор где-то там писал, что пока с национальными названиями "играться" не стоит, хотя м.б. из-за сырости версий так было. А вообще интересна сама идея такой межплатформенности и архитектура её реализации, поэтому в основном следил за историей. Зачем спешить, если он ещё активно делается?
Мне НЕ нравится его синтаксис в целом (но другие не лучше, в "культурном плане" - вообще никакие), а нравятся идеи и некоторые подходы. Хотя синтаксически новой оказалось только одна мелкая полезная штучка, но и это уже хорошо.
А прежде чем пытаться переводить, нужно полностью прочитать весь исходный код. Объём-то немалый.
А ещё прежде - попробовать пере|написать какую-нибудь программку, посмотреть на работоспособность, посмотреть на то, как в целом поменялся синтаксис, сравнить с тем, что не нравилось на исходном языке.

Павиа написал(а):

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

Вот пока её там и нет, как и некоторых других задуманных вещей.


Вы здесь » Ремесло программиста » Общие вопросы » Язык программирования АЛФОР