Новый язык программирования мечты. Полёт фантазии

В образовательных целях и как хобби, я в свободное время проектирую свой кустарный процессор. Сейчас нахожусь на этапе создания простейшего языка программирования, который будет преобразовываться в ассемблер. Столкнулся с тем, что все мои "гениальные" идеи разбиваются о реальность - в старом добром Си это сделано уже лучше и оптимальнее некуда Ничего лучше Си для генерации Ассемблер команд никогда не придумают. А если нужно еще и ООП, синтаксических сахарок и STL, то ничего лучше С++ никогда не придумают.

И ничего лучше RISC ISA в чисто техническом плане тоже не придумать, поэтому буду переделывать и переименовывать свои ассемблер инструкции на стандартные для Risk-V.

Ну в общем все тлен, и новый велосипед никогда не придумают, ведь у текущего уже есть и круглые колеса и переключатель передач, и даже звоночек с катафотом. Конкурентные преимущества языков программирования сейчас кроются только в "средах": в социальных или комерс комьюнити, которые создают, продвигают и поддерживают специальные библиотеки и документации для любого чиха и пука, разные удобные IDE, коучей, курсы и т.д. Чисто технически уже давно любой язык можно и компилировать и интерпретировать во вкладке браузера, запускать любую программу на любом ЯП на любой ос, лишь бы юридически было ок. И сконвертить одно в другое с ИИ - раз плюнуть.

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

0

Сообщение от Shamil1 Вы не обратили внимание, что в ООП языках появляется всё больше и больше ФП возможностей?

Все популярные языки общего назначения мультипарадигменные сейчас.

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

0

Сообщение от Noname2331 переписываю на том же ЯП, но через последовательные линейные процедуры

То есть, переписываете в функциональном (ФП) стиле?

0

Сообщение от Shamil1 То есть, переписываете в функциональном (ФП) стиле?

Всяких for и лапши добавил для вызова функций вместо этой одной страшной змеи .map.filter.filter.any и все стало так просто

0

Сообщение от Noname2331 вместо этой одной страшной змеи

эта "страшная змея" не является отличительной чертой функционального подхода

В ООП языках (иногда) используют такой же подход ("флуент интерфейс")
В ФП языках (иногда) пишут построчно:
y = f x
z = g y
...

Обычно автор выбирает тот вариант, который ему (субъективно) кажется более удобным.

Есть ещё такой вариант:
x |> f |> g
(x передаётся в f, результат передаётся в g)
и такой:
g <| f <| x

0

Сообщение от Shamil1 эта "страшная змея" не является отличительной чертой функционального подхода

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

0

Сообщение от Noname2331 На тру фп яп я так и не смог ничего путного написать, трудно дается.

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

Если смущают змеи, то не используйте их (пока не появится такое желание). Пишите по одному вызову функции в одной строке.

1

Сообщение от Shamil1 Эта "косметика" сильно влияет на производительность разработки. Примеры описания и использования функции map в с++ 20: .. На других ЯП:

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

Предлагаю проверить/сравнить то же "мапирование" на реальной задачке (ее достаточную простоту гарантирую )

0

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

Это правда. Пример из личного опыта: в команде разработки все мучались с одной легайси функцией на 1000 строк кода с кучей побочных эффектов в виде обращения к БД и постоянным ростом количества аргументов, добавляли новые и новые заплатки. Пока не пришел понимающий бизнес человек сверху, который отказался слушать нытье прогеров и просто приказал применить вместо этого говна формулу пропорции дробей из 6 класса математики. Типа "если x/a=b/c то x=ab/c", метод бабочки. И все стало хорошо

Вот интересно, а чем функциональный ЯП конкретно помогает в этом, в чем профит? Эти математические формулы можно применять в любой парадигме, чем синтаксические ограничения ФП помогут, если прогер тупо не понимает бизнес логики, не видит связи с простой математической формулой? Сдается мне, если не понимать сути бизнес процессов и не знать математики, можно и на чистых функциях без побочек наворотить всякого в отрыве от реальности... Еще хуже будет, чем с побочками и на ООП или даже на ассемблере.

0

Сообщение от Igor3D Но пример слишком/чрезмерно прост чтобы делать какие-то выводы о производительности.

На всякий случай уточню: речь идёт о производительности программиста (скорости чтения/написания программы).

Сообщение от Igor3D Предлагаю проверить/сравнить то же "мапирование" на реальной задачке (ее достаточную простоту гарантирую )

Можно сравнить.

Сообщение от Noname2331 чем функциональный ЯП конкретно помогает в этом, в чем профит?

Во-первых, позволяет скрыть ненужные технические детали.
Переход от Ассемблера к Си позволяет писать "for(int i = 0; i < len; i++) doSomething(arr[i]);". Тем самым скрываются технические детали (метки, условные переходы и т.п.) и уменьшается вероятность забыть изменять счётчик.
Переход от Си к Haskell позволяет писать "map doSomething". Тем самым скрываются технические детали (цикл, счётчик и т.п.).

Во-вторых, делает код более кратким. Это (при опыте) позволяет быстрее разобраться в коде. Особенно, если рассматриваемый кусок кода умещается на одном экране.

В-третьих, более краткий код позволяет создавать новые типы везде, где они нужны (чего обычно не станут делать программисты на C++ или C#).
Например, в программе есть класс Документ со свойством Название. Каждый метод, использующий название, будет начинаться с проверки, что Название не пустое, и длина не превышает максимально разрешенный размер. А когда для определения нового типа нужен не отдельный файл, а одна строка, то естественно сделать тип НазваниеДокумента (содержит строку, гарантированно удовлетворяющий всем требованиям), значением свойства Название и входным параметром функций будет не Строка, а НазваниеДокумента.

В-четвёртых, размеченное объединение чаще лучше подходит по смыслу, чем иерархия классов.
Пример на haskell (с размеченными объединениями):
Пример на typescript (с размеченными объединениями):
Пример на C#:
И это с новыми record, добавленными из функциональных языков. А так бы пришлось писать 3 класса.
Но самое неприятное в этом коде - это случай default в switch. По (бизнес) логике мы туда не можем попасть, а по синтаксису - можем и должны предусмотреть. И это не только лишний (не соответствующий бизнес логике) код, но и отсутствие ошибок компиляции при добавлении ещё одной альтернативы "public record Loading() : Result".

0

Сообщение от Noname2331 В образовательных целях и как хобби, я в свободное время проектирую свой кустарный процессор. Сейчас нахожусь на этапе создания простейшего языка программирования, который будет преобразовываться в ассемблер. Столкнулся с тем, что все мои "гениальные" идеи разбиваются о реальность - в старом добром Си это сделано уже лучше и оптимальнее некуда Ничего лучше Си для генерации Ассемблер команд никогда не придумают. А если нужно еще и ООП, синтаксических сахарок и STL, то ничего лучше С++ никогда не придумают.

в далекие времена все делалась с точностью до наоборот

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

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

3. из опкода и машинных команд получался ассе́мблер
Язы́к ассе́мблера (англ. assembly language, разг. ассе́мблер) — представление команд процессора в виде, доступном для чтения человеком.
Язык ассемблера, или просто ассемблер — низкоуровневый язык программирования, использующий мнемоники, инструкции и операнды для представления машинного кода. Это улучшает читаемость при сохранении полного контроля над машинными инструкциями.

а уже потом всякие языки высокого уровня.

так что вы начали строить дом с крыши

0

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

Сообщение от Nname100 так что вы начали строить дом с крыши

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

0

Сообщение от Noname2331 нужен ЯП более высокого уровня для такого, даже самый примитивный ускорит разработку кратно

макро ассемблер разновидность ассемблера

макросы являются кирпичами для строительства ЯП

0

Сообщение от Nname100 макро ассемблер разновидность ассемблера макросы являются кирпичами для строительства ЯП

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

Пока что у меня получается ЯП, который представляет собой JSON с массивом, где каждый элемент - это как-бы одна строка кода, команда и операнды. Типа

[
['add16', 'адрес1', 'адрес2', 'адрес3'],
['cmp', 'адрес4', 'адрес3'],
]

И отдельно есть объект, где хранится описание адресов. Что-то вроде: адрес1 - 16 битное число, значит следующие 16 бит нельзя занимать, бронируется 2 ячейки адреса сразу (значит команда 1 выдаст ошибку еще при компиляции), и еще куча настроек есть.

0

все как-то сложно

для таких вещей есть регистры
если шина 8 бит то и рег 8 битные
на апп уровне это защелки

и все операции происходят в них

add r1,r2

либо
add r10,r12
adc r11,r13

add сумм
adc c переносом
пара r10,r11 типо 16бит

мнемонику взял с avr

инкремент на aпп счетчик прямой
дискремент на aпп счетчик обратный

inc r1

dec r1

регистр в счетчик и слк

звчем велосипед изобретать полно литературы

0

Сообщение от Nname100 все как-то сложно для таких вещей есть регистры

Что тут сложного? Сознательно отмел load&store архитектуру. Если производительность не волнует вообще, нахрен нужен этот регистр и вообще 2+ разных видов памяти? Пусть будет одна примитивная память, триггер можно реализовать хоть на колбах с водой - либо есть в сосуде вода, либо нет.

И нахрен этот слк пока что, все асинхронно и последовательно будет, в самом простом варианте.

0

Сообщение от Noname2331 нахрен нужен этот регистр и вообще 2+ разных видов памяти?

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

0

Сообщение от Nname100 дело в том что не ВЫ первый идете по этому пути . и чего только не было Ваши рассуждения близки с фон Нейманом

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

Кстати, может посоветуете что-то для обучения. Я обучался на компьютерной игре, где надо воссоздать с нуля MOS 6502 процессор (это на приставке Денди такой) + прошел (прослушал) современный университетский курс по архитектуре процессоров. Хочется что-то еще узнать.

0

Сообщение от Shamil1 Например, в программе есть класс Документ со свойством Название. Каждый метод, использующий название, будет начинаться с проверки, что Название не пустое, и длина не превышает максимально разрешенный размер. А когда для определения нового типа нужен не отдельный файл, а одна строка, то естественно сделать тип НазваниеДокумента (содержит строку, гарантированно удовлетворяющий всем требованиям), значением свойства Название и входным параметром функций будет не Строка, а НазваниеДокумента. В-четвёртых, размеченное объединение чаще лучше подходит по смыслу, чем иерархия классов. Пример на haskell (с размеченными объединениями): Haskell 1 2 3 4 data Result = Success String | Error String handle :: Result -> IO () handle (Success dataStr) = putStrLn dataStr handle (Error errorStr) = putStrLn errorStr

Не понял ни задачу, ни, тем более, реализацию. Наверно по умолчанию Документ именуется именем файла (хз в каком фолдере), но возможны и кастомные имена. Если так, я бы делал примерно
Не вижу здесь проблем, особенно "идейных"

Вот пример мелкой но практической задачи. Заметим что даже такие не сводятся к "голой технике"

0

Еще интересен момент по поводу библиотек. Многие программы написанные на одном языке используют по сути одни и те же библиотеки базовые. А смысл их дублировать в каждый проект (питону привет). И вот что лучше - у каждого проекта своя база или одна на всех? А если она единая - то надо как то грамотно интегрировать ее в ОС.

0

Сообщение от Enifan Еще интересен момент по поводу библиотек. Многие программы написанные на одном языке используют по сути одни и те же библиотеки базовые. А смысл их дублировать в каждый проект (питону привет). И вот что лучше - у каждого проекта своя база или одна на всех? А если она единая - то надо как то грамотно интегрировать ее в ОС.

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

0