Триада языков программирования

12

Проверка, можно ли использовать Rust в качестве языка нижнего уровня для сборочного программирования, к сожалению, закончилась отрицательным результатом. Перефразируя анекдот: я не хочу так, как может этот месье. Или более серьезно, программируя на Rust я вынужден больше думать о том, как выразить свою мысль на языке, а не о том, как сделать то, что я делаю.

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

Поясню, почему я рассматриваю Rust и не рассматривал, например, Go, хотя Go сам по себе очень хорош.

На мой взгляд, если смотреть на создание программ с философского уровня, нам нужна триада языков:

  • язык нижнего уровня (не низкого, а нижнего из трех) – условно системный,
  • язык среднего уровня – условно прикладной
  • и скриптовый язык – язык-клей

Системный – должен требовать мало ресурсов, и, не использовать сборку мусора (типа Rust). Естественно, должен быть очень надежным.

Прикладной, вроде Go.

Про «язык-клей» надо объяснить – два первых языка нужны для разработки компонент, из которых собираются программы. Сборка (изготовление) программ – это не программирование, это другой процесс, как это сейчас и сделано в среде разработке «Вир».

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

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

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

Возвращаясь к Rust – идейно это очень важный язык, по крайней мере, с точки зрения работы с памятью. Хотя не менее интересны и его предшественники, например, Cyclone.

Но напрямую Rust я не могу использовать. Мне нужен гораздо более простой язык, который я называю ассемблер-1 (А1), где слово «ассемблер» намекает на сборку (ассемблирование) и на то, что это язык нижнего уровня. В А1 много беру из Go и Rust.

Простенький пример на а1 (из тестов компилятора):

фн «Проверка индексации»(строка: &[] цел16 ): цел32 {

1 → и: цел32

завершить строка[и] ? цел32

}

12 комментариев


  2. Как одно из решений:
    Оберон-7
    Компонентный Паскаль
    Компонентный Паскаль с целевыми расширениями (например, в КП _УЖЕ_ встроен скриптоподобный интерпретатор команд)

    Ответить

  3. Поскольку рассматриваете еще и IoT, базовым языком должен быть embedded C, без вариантов.

    nim-lang.org не щщупали?

    Ответить

    1. Язык, который мы сейчас делаем, нацелен на мобильные устройства (телефоны, часы, планшеты, cars, колонки) + smart TV. IoT мы не рассматриваем в качестве основной цели. Возможно, что high-end IoT тоже можно будет программировать, но если нет, то никто не огорчиться.

      «embedded C» — почему? Вот например, эти ребята: https://www.toitware.com/ считают иначе. И я думаю, что их точка зрения имеет право на существование.

      Ответить

    2. > Поскольку рассматриваете еще и IoT, базовым языком должен быть embedded C, без вариантов.

      Ой, вот только не надо такие смелые заявления делать. Оберон-07 прекрасно на STM32 с 256к памяти вертится и я доволен как слон. Для меня это прекрасный вариант.

      Ответить

  4. Повторюсь из ВК: не рассматривали язык на базе Smalltalk или Self в качестве языка верхнего уровня, возможно с акторными расширениями?

    Ответить

  5. А не стоит ли посмотреть на Пролог или лучше Picat, и использовать исключительно метапрограммирование?

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

    представление программ — в виде объектных графов, или фреймов [Марвин Мински], причем не только «исходного кода», а вообще представление знаний о решаемом наборе проблем (рабочая смесь [Тыугу]).

    для такого языка верхнего уровня первичным функционалом является не ООП, а pattern matching и выполнение правил преобразования, которым на вход подаются заматченные куски графа знаний

    как пример, создаем в системе новый проект «HelloWorld для телефона», и система начинает елозить по своему доменному графу знаний, выбирает целевой язык (Java, C++ NDK..), подбирает куски исходного кода которые подходят под решение задачи, и склеивает их между собой.

    Ответить

    2. Что-то Вы любите предлагать какие-то сложные варианты. Современное программирование так не работает. Всё должно быть просто, понятно и самое главное сопровождаемо. Пролог потому и помер (вместе со Смолтоком) — чёрт ногу сломит.

      Ответить

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *