Всем доброго времени суток.
В статьях про Оберон часто упоминается применение Оберона в программировании спутников, ГЭС, АЭС и так далее. Суровые промышленные программные комплексы. Конечно, хотелось бы иметь реальные примеры кода для каждого случая, но это не всегда возможно, и поэтому складывается впечатление, что никаких продуктов как бы нет. Для исправления этой ситуации сегодня хотелось бы рассказать о программировании беспилотников на Обероне.
Так как я сам никогда с БПЛА не работал, а микроконтроллер только для мигания светодиодом использовал (с помощью Оберона, конечно), я попросил рассказать о своей работе активного участника сообщества Оберон-разработчиков в России. Его зовут Александр.
Далее по тексту А. — Александр, O. — oberon87
O.: Пару слов о твоей работе.
А.: Я работаю в фирме, которая занимается разработкой беспилотных летательных аппаратов, и пишу программы для систем автоматического управления самолётами. Самолёты применяются, в основном, для аэрофотосъёмки.
O.: Почему именно Оберон, ведь на рынке есть куча микроконтроллеров и языков (в основном Си)?
А.: Нам важна надёжность бортовых программ.
Программы ранних систем автоматического управления (в 2000-х годах и ранее) выполнялись на микроконтроллерах MCS 51 и были написаны на языках программирования Pascal и Assembler с использованием компилятора EmbeddedPascal. MCS 51 в то время был выбран из-за своей популярности.
Но постепенно ресурсов микроконтроллера стало не хватать, компилятор содержал ошибки (которые обходили использованием ассемблера) из-за сложности архитектуры MCS 51, появились новые микроконтроллеры и компилятор фирмы Astrobe, и с 2010 года мы стали писать программы на языке программирования Oberon под микроконтроллеры NXP LPC2000. <...> Еще одно отличие новой системы от предыдущей в том, что новая основана на использовании более дешёвых и компактных датчиков, которых раньше не было.
Архитектура ARM проще, чем MCS 51, и язык программирования Oberon проще, чем Pascal, но всё равно в реализации компиляторе Astrobe были ошибки, которые постепенно находили и исправляли.
Вообще-то я даже использую не все возможности языка языка Oberon — не пользуюсь динамической памятью и сборщиком мусора.
Ещё я не люблю синтаксис языка C.
O.: Что использовал, как происходит написание кода в обероне, насколько это легко/трудно?
А.: Как я уже писал, нам важна надёжность бортовых программ. Использование простого языка программирования помогает писать надёжные программы. Oberon как раз таким и является, он таким и был задуман. Компилятор тоже должен быть надёжным. То есть по возможности тоже простым. Для того, чтобы компилятор был простым, должен быть простым язык программирования и целевая архитектура. Такой архитектурой является RISC.
В 2014 году я написал свой компилятор Oberon для современных микроконтроллеров с архитектурой ARMv7-M (Cortex-M4F) на основе компилятора Oberon->RISC из Project Oberon Никлауса Вирта, и программа для новой системы автоматического управления была написана с его использованием.
Компилятор написать было несложно, потому что он уже был написан (и потому, что в нем правильное разделение функций на фронтэнд и бэкенд), и мне нужно было всего лишь переписать компилятор заднего плана (кодогенератор) и написать компоновщик. А так как язык программирования простой и архитектура ARMм7-M простая, то это не заняло много времени. Для того, чтобы написать компилятор, мне потребовалось только изучить архитектуру ARMv7-M и некоторые особенности современных микроконтроллеров (STM32 и LPC) для написания компоновщика.
При написании системных модулей для микроконтроллеров NXP использовал User Manual, для STM32 — Reference Manual и datasheet. Документация у NXP мне понравилась больше, чем у ST Microelectronics. Для понимания неоднозначных мест в Reference Manual пришлось смотреть исходники библиотек Keil.
Когда я писал компилятор, я сам допустил несколько ошибок, но быстро их нашёл и исправил по мере написания программы автопилота, которую сразу же испытывал на программно-аппаратной модели. Одна ошибка из-за невнимательности (указал не тот регистр в качестве параметра при генерации одной из инструкций), две из-за того, что пришлось оптимизировать одно место, и это изменение потребовало изменение в другом месте кодогенератора, а сразу об этом я не догадался. И ещё две три ошибки были найдены в оригинальном компиляторе (одна наверное была сделана из-за невнимательности, две другие были однотипными).
После того как я написал компилятор, нужно было ещё написать базовые системные модули для поддержки микроконтроллеров – для настройки ядра (ФАПЧ) и для работы с периферией. Это тоже было несложно сделать.
O.: Можешь привести пример кода?
А.: Не нашёл ничего такого, что можно привести в пример. Ну, вот, простая целочисленная реализация фильтра НЧ:
O.: Спасибо за информацию.
Как можно увидеть из интервью, для того чтобы начать работу с Обероном и повысить надежность своих продуктов, не нужно ничего, кроме желания. Каждый этап разработки настолько прост, что даже писать о нем нечего.
Пейте морковный сок!
Используйте Оберон для микроконтроллеров!
P.S. и не забудьте посетить сайт российского Оберон-сообщества для дополнительной информации
В статьях про Оберон часто упоминается применение Оберона в программировании спутников, ГЭС, АЭС и так далее. Суровые промышленные программные комплексы. Конечно, хотелось бы иметь реальные примеры кода для каждого случая, но это не всегда возможно, и поэтому складывается впечатление, что никаких продуктов как бы нет. Для исправления этой ситуации сегодня хотелось бы рассказать о программировании беспилотников на Обероне.
Так как я сам никогда с БПЛА не работал, а микроконтроллер только для мигания светодиодом использовал (с помощью Оберона, конечно), я попросил рассказать о своей работе активного участника сообщества Оберон-разработчиков в России. Его зовут Александр.
Далее по тексту А. — Александр, O. — oberon87
O.: Пару слов о твоей работе.
А.: Я работаю в фирме, которая занимается разработкой беспилотных летательных аппаратов, и пишу программы для систем автоматического управления самолётами. Самолёты применяются, в основном, для аэрофотосъёмки.
O.: Почему именно Оберон, ведь на рынке есть куча микроконтроллеров и языков (в основном Си)?
А.: Нам важна надёжность бортовых программ.
Программы ранних систем автоматического управления (в 2000-х годах и ранее) выполнялись на микроконтроллерах MCS 51 и были написаны на языках программирования Pascal и Assembler с использованием компилятора EmbeddedPascal. MCS 51 в то время был выбран из-за своей популярности.
Но постепенно ресурсов микроконтроллера стало не хватать, компилятор содержал ошибки (которые обходили использованием ассемблера) из-за сложности архитектуры MCS 51, появились новые микроконтроллеры и компилятор фирмы Astrobe, и с 2010 года мы стали писать программы на языке программирования Oberon под микроконтроллеры NXP LPC2000. <...> Еще одно отличие новой системы от предыдущей в том, что новая основана на использовании более дешёвых и компактных датчиков, которых раньше не было.
Архитектура ARM проще, чем MCS 51, и язык программирования Oberon проще, чем Pascal, но всё равно в реализации компиляторе Astrobe были ошибки, которые постепенно находили и исправляли.
Вообще-то я даже использую не все возможности языка языка Oberon — не пользуюсь динамической памятью и сборщиком мусора.
Ещё я не люблю синтаксис языка C.
O.: Что использовал, как происходит написание кода в обероне, насколько это легко/трудно?
А.: Как я уже писал, нам важна надёжность бортовых программ. Использование простого языка программирования помогает писать надёжные программы. Oberon как раз таким и является, он таким и был задуман. Компилятор тоже должен быть надёжным. То есть по возможности тоже простым. Для того, чтобы компилятор был простым, должен быть простым язык программирования и целевая архитектура. Такой архитектурой является RISC.
В 2014 году я написал свой компилятор Oberon для современных микроконтроллеров с архитектурой ARMv7-M (Cortex-M4F) на основе компилятора Oberon->RISC из Project Oberon Никлауса Вирта, и программа для новой системы автоматического управления была написана с его использованием.
Компилятор написать было несложно, потому что он уже был написан (и потому, что в нем правильное разделение функций на фронтэнд и бэкенд), и мне нужно было всего лишь переписать компилятор заднего плана (кодогенератор) и написать компоновщик. А так как язык программирования простой и архитектура ARMм7-M простая, то это не заняло много времени. Для того, чтобы написать компилятор, мне потребовалось только изучить архитектуру ARMv7-M и некоторые особенности современных микроконтроллеров (STM32 и LPC) для написания компоновщика.
При написании системных модулей для микроконтроллеров NXP использовал User Manual, для STM32 — Reference Manual и datasheet. Документация у NXP мне понравилась больше, чем у ST Microelectronics. Для понимания неоднозначных мест в Reference Manual пришлось смотреть исходники библиотек Keil.
Когда я писал компилятор, я сам допустил несколько ошибок, но быстро их нашёл и исправил по мере написания программы автопилота, которую сразу же испытывал на программно-аппаратной модели. Одна ошибка из-за невнимательности (указал не тот регистр в качестве параметра при генерации одной из инструкций), две из-за того, что пришлось оптимизировать одно место, и это изменение потребовало изменение в другом месте кодогенератора, а сразу об этом я не догадался. И ещё две три ошибки были найдены в оригинальном компиляторе (одна наверное была сделана из-за невнимательности, две другие были однотипными).
После того как я написал компилятор, нужно было ещё написать базовые системные модули для поддержки микроконтроллеров – для настройки ядра (ФАПЧ) и для работы с периферией. Это тоже было несложно сделать.
O.: Можешь привести пример кода?
А.: Не нашёл ничего такого, что можно привести в пример. Ну, вот, простая целочисленная реализация фильтра НЧ:
MODULE IntRC;
(* Alexander Shiryaev, 2015.01 *)
TYPE
RC* = RECORD
rc*, n*: INTEGER
END;
PROCEDURE Init* (VAR rc: RC; x, n: INTEGER);
BEGIN
rc.rc := LSL(x, n);
rc.n := n
END Init;
PROCEDURE Set* (VAR rc: RC; x: INTEGER);
BEGIN
rc.rc := LSL(x, rc.n)
END Set;
PROCEDURE ASR1 (x, n: INTEGER): INTEGER;
BEGIN
IF x > 0 THEN INC(x, LSL(1, n - 1)) END
RETURN ASR(x, n)
END ASR1;
PROCEDURE Update* (VAR rc: RC; x: INTEGER): INTEGER;
PROCEDURE ASR2 (x, n: INTEGER): INTEGER;
BEGIN
IF x > 0 THEN INC(x, LSL(1, n) - 1) END
RETURN ASR(x, n)
END ASR2;
BEGIN
rc.rc := rc.rc + ASR2(LSL(x, rc.n) - rc.rc, rc.n)
RETURN ASR1(rc.rc, rc.n)
END Update;
PROCEDURE Get* (rc: RC): INTEGER;
BEGIN
RETURN ASR1(rc.rc, rc.n)
END Get;
END IntRC.O.: Спасибо за информацию.
Как можно увидеть из интервью, для того чтобы начать работу с Обероном и повысить надежность своих продуктов, не нужно ничего, кроме желания. Каждый этап разработки настолько прост, что даже писать о нем нечего.
Используйте Оберон для микроконтроллеров!
P.S. и не забудьте посетить сайт российского Оберон-сообщества для дополнительной информации
michael_vostrikov
Как-то слишком многословно…
Areldar
Undefined behavior в сдвигах
monah_tuk
Немного неточно: правый сдвиг отрицательного числа — определяется реализацией, но сути дела не меняет.
Кстати, а как обстоят дело со сдвигами знаковых в Обероне?
oberon87 Автор
Есть разделение на арифметический и логический сдвиги.
monah_tuk
Чёрт, лево-право перепутал. Прошу прощения.
michael_vostrikov
Так суть же не в этом. Можно отдельно функцию lsl() определить. Я к тому, что
многобуквмного дополнительных слов и названий переменных. Ну и регистр символов постоянно меняется.lair
Все-таки, хотелось бы понять, чем код на Обероне надежнее кода на (вставьте сюда ваш язык для программирования под МК).
Пока я увидел только аргументацию «простой код, простая целевая архитектура, простой компилятор, мало места для ошибок». Но это ведь «мало места для ошибок в компиляции», а насколько защищен от ошибок сам код?
oberon87 Автор
По определению H. Вирта «программы — это алгоритмы + структуры данных». Алгоритмы должны быть непротиворечивые, а структуры данных — достаточные для выражения предметной области.
Чтобы записать алгоритм нужен язык, язык должен быть непротиворечивым, чтобы алгоритм получился точно такой, как вы хотите. Точности могут мешать как недостающие примитивы, так и излишние примитивы. В этом и весь секрет надежности. Баланс между абстрагированностью языка и его близостью к железному исполнителю.
Вирт кстати тоже делал беспилотник. Только вертолет. www.inf.ethz.ch/personal/wirth/projects.html (Ctrl-F, helicopter).
lair
То есть предметная область выражается только структурами данных? То, что язык не противоречив, еще не означает, что алгоритм получится такой, как я хочу: если в языке нет нужного мне алгоритмической конструкции, алгоритм будет отличаться.
Собственно, тут мы и упираемся в понятие уровня абстракции. На каком уровне вы хотите выражать свой алгоритм? (понятно, что этот «уровень» неформализуем, нет «первого», «второго» и так далее). Но, скажем, если моя бизнес-логика оперирует терминами «для каждого земельного участка с площадью более пятисот га послать уведомление», то я и хочу писать алгоритм в этих терминах, а не в терминах «получи объект, проверь, что получение успешно, если успешно, то проверь, что площадь более 500 га, если больше, то пошли уведомление».
На основании чего можно объективно сделать вывод, какой уровень лучше?
oberon87 Автор
Я же сказал, что программы это алгоритмы и структуры данных. Только структуры данных да, могут описать статические объекты этого мира. Структуры данных для описания структуры объектов окружающего мира, алгоритмы для выражения их поведения. Объекты, поведение, ничего не напоминает?
Таким образом Вирт придумал выражать реальность.
А алгоритмы императивных ЯП вообще сводятся к нескольким базовым вещам, арифметика, логика, процедурная декомпозиция, ветвление, цикл. Вроде ничего не забыл. Все это в обероне есть, и в общем-то набор шлифовался десятилетиями.
А так как этот набор тьюринг-полный и не вырожденный, как брейнфак, то я вам отвечаю, что ваша бизнес-логика будет выражена на Обероне в виде, близком к общепринятому в ООП-подходе виду. Но на Обероне. Минимумом средств. А работать будет точно так же. В этом и цель. Ну и еще лапши поменьше будет, объявления всякие никто не смешает с вашим кодом.
А лучше или нет, как же мы поймем? Я не говорил, что будет лучше, я говорил, что будет порядок в объявлениях и не будет лишнего в синтаксисе.
lair
Под «минимумом средств» вы понимаете минимум кода, минимум усилий, или что-то третье?
Выше вы говорите о том, что надежность Оберона в том, чтобы алгоритм был точно такой, как я хочу. Что вы вкладываете в это понятие «точности»? Правильно ли я понимаю, что достоинство Оберона в том, что он передает мой алгоритм «точнее», чем другой язык?
oberon87 Автор
Минимум средств это минимум языковых средств. Мы же про язык говорим.
lair
А в чем выигрыш для разработки от того, что используется минимум языковых средств?
Ну и да, оставшиеся два вопроса тоже небессмысленны.
oberon87 Автор
Профит в том, что мне не приходится «портировать» свои решения на Оберон, они на нем работают нативно. В других экосистемах это слегка не так. Но измерять это я не берусь. Я уверен, сотни умных людей пишут более эффективный код чем я на любом языке. Но нам нужны сотни тысяч людей, пишущих код эффективно. Средний уровень, типа меня.
lair
Что вы понимаете под «портировать решения на Оберон»? Я привык считать, что это означает, что у вас есть код, который вы запускаете на той или иной платформе. В этом смысле мои решения не надо портировать на C#, потому что они на нем написаны; и в этом смысле это вообще пустой аргумент.
Вероятно, вы имеете в виду что-то другое. Что?
Не связано ли это с тем, что вы пытаетесь писать на этих языках так, как вы раньше писали на Обероне?
oberon87 Автор
Я же не зря взял в кавычки. Это я так описывал процесс переноса алгоритма, который я придумал, из моей головы в исходный код. Формулирование, если хотите более точное слово.
А пишу я так, как прочитал в книжках по программированию, там на самом деле учат писать так, как потом я писал на Обероне. Совпадение? Не думаю.
lair
А кто писал эти книжки по программированию, если не секрет?
Потому что вот я пишу так, как пишут в (вероятно, других) книжках по программированию, и у меня нет проблемы расхождения моего внутреннего языка и языка, используемого в C#/F# (со вторым хуже, но я его и знаю хуже).
Вот возьмем мой пример задачи выше (он, в принципе, концептуально эквивалентен примеру задачи с телефонной книгой из соседнего поста). Его решение (за вычетом единиц измерения и параллелизма) на F# выглядит вот так:
На C# — вот так:
В обоих случаях, как можно видеть, описание алгоритма очень близко к описанию задачи. Вы считаете, что алгоритм может быть передан более точно? Если да, то не могли бы вы объяснить, в чем состоит эта «большая» точность, и как должен выглядеть этот алгоритм?
oberon87 Автор
Дейкстра вот хорошие книги писал.
lair
Вы почему-то снова проигнорировали практическую часть комментария.
Я не сомневаюсь в том, что Дийкстра писал хорошие книги, я сомневаюсь в том, что это единственно правильные и хорошие книги.
oberon87 Автор
Ну слушайте, учитывая что большую часть работы алгоритма делает библиотечная функция Where, а сам код скорее функциональный, чем императивный, то алгоритм в Обероне будет такой.
lair
Вы считаете, что Обероновский код передает алгоритм более точно? Если да, то не могли бы вы объяснить, в чем состоит эта большая точность?
oberon87 Автор
1) Однострочник заменен на то, чем он реально является — процедурой с одним аргументом, возвращающей результат.
2) Вы сами управляете циклом обхода результата, что позволяет контролировать процесс с вашей стороны.
Ну и в целом, разные парадигмы, сравнивать трудно. Я поставлен вашей задачей в условия, удобные для С#, с его плюшками. На Обероне оно выглядело бы иначе. Возможно. Но этот этюд я оставлю Вам.
senia
Вообще-то нет. Этот однострочник может являться еще и параллельной обработкой в множестве потоков (и еще много чем). В случае с WHILE такая возможность потеряна.
Это не есть хорошо. Вместо предметной области вы занимаетесь деталями реализации, причем прибиваете их намертво.
Причем в вашем коде есть метод Select, который полностью противоречит вашим утверждениям. Я бы понял если бы его не было и вы использовали IF внутри цикла, но вы этого не делаете. Это еще и непоследовательность подхода.
oberon87 Автор
Я не хочу переписывать еще и Select, в оригинальном коде он просто есть, как и в моем.
И потом, параллельная обработка это настолько неявная штука, что можно отдельную статью писать. Я сказал сразу, что функциональщину подсовывать это слегка не комильфо. Пишите на хаскелле, зачем оберон брать.
senia
Проблема в том, что ваш код уже не последователен. Он уже смешивает парадигмы. Вы описываете обертон как чистый и минималистичный язык, но ваши же примеры крайне далеки от подобной чистоты.
Я предпочитаю ФП. Любой мой код будет в функциональном стиле по умолчанию. Нет ФП задач, есть ФП решения.
oberon87 Автор
Напомню, что функциональщина требует больше факторов, чем просто передача указателя на процедуру. Так что пока все в рамках обычного структурного программирования. Точно так же туда можно было передать объект-фильтр, но этого объекта не было в исходной задаче.
А ваши предпочтения мне неинтересны.
senia
В исходной задаче вообще ничего не было про реализацию. И про ФП там тоже ничего не было. Так почему вы свой непоследовательный подход оправдываете тем, что вам «подсовывают функциональщину»?
lair
Вообще-то, в приведенных мной отрывках кода в обоих случаях употребляется именно функция с одним аргументом, возвращаяющая результат. Так что вы заменили не что-то на функцию, а анонимную функцию на именованную. Какой от этого выигрыш? Почему это точнее передает алгоритм (не его реализацию, а именно алгоритм)?
Это не имеет отношения к точности передачи, это потенциальные возможности. Разве нет?
Я могу переписать этот же код на скале, на js — вас не удивляет, что задача, которая практически один в один взята из ТЗ, предоставленного заказчиком, хорошо ложится на четыре мейнстрим-языка, и плохо ложится на Оберон?
И что за «разные парадигмы»? На C# код императивный, на F# — гибридный (потому что есть побочные эффекты). Какая парадигма у Оберона? Я думал, что императивная. Я ошибался?
И. Самое главное.
(есть разница в реализации полного обхода, но ее тоже можно повторить, если очень надо)
oberon87 Автор
По факту, пока все ваши претензии свелись к набору плюшек от Microsoft, форычи, кложуры и filter. Как и всегда, ну реально, годами одно и то же.
lair
Да при чем тут набор плюшек от MS? Использованная функциональность ни разу не языко-специфична, это совершенно типовой набор, который есть в большей части современных языков программирования (кстати, ни одного замыкания там нет, где вы его нашли?).
И понимаете, мой вопрос был банально в том, что следует считать точностью передачи алгоритма? Почему вы считате, что приведенные мной примеры передают алгоритм недостаточно точно?
oberon87 Автор
А что, однострочники не захватывают локальные переменные? Ну ладно, значит просто анонимка. Напридумывают всякого, запоминай потом.
А вообще да, можно еще долго спорить о том, что алгоритмически правильнее, форыч или цикл с предусловием.
senia
С вами никто не хочет спорить о том что правильнее. У вас хотят узнать чем же обертон лучше.
Пока вы привели только 1 пример кода, но и тот мало того, что смешивает алгоритм и реализацию, но еще и непоследователен в этом. Это не помогает читателям понять преимущества обертона.
oberon87 Автор
Особенно когда код оценивает фанат функциональщины. Вы же не думали, что я буду ваши комментарии и оценки считать объективными?
senia
Ну мы же нянчимся с фанатом обертона.
К слову о «фанатах»: очень большая часть моего кода написана в чисто императивном стиле на pl/sql. Более того, там даже милые вашему сердцу procedure/begin/end. И со своего опыта я вам скажу: ваш код на обертоне плох даже с точки зрения императивного подхода. Когда я увижу хороший императивный код на обертоне — попытаюсь оценить сам язык. Пока видел только плохой.
oberon87 Автор
Вы свою роль в этом шоу определяете не совсем верно.
senia
Так поделитесь своим видением ролей в данном шоу, не томите!
lair
Ни в одном из приведенных примеров — нет. Собственно, то, о чем вы пишете, не называется «однострочник», нет такого термина ни в том, ни в другом языке.
А мне не важно, что «алгоритмически правильнее», мне важно, что точнее передает задачу. Ведь вы же именно так изначально озвучили преимущество Оберона: он позволяет записать точно тот алгоритм, который я хочу. Я озвучил, какой алгоритм я хочу — теперь мне интересно понять, почему предложенная мной запись (даже две) записывают его «неточно».
oberon87 Автор
Вот, с этого и надо было начинать, Вам неважно. Вы всегда так пишете, и понятие о правильности алгоритмов у вас соответствующие. Что же вы собрались оценивать? И как?
lair
А если вы не заметили, я с этого и начал: «Что вы вкладываете в это понятие «точности»»?
А понятие о правильности алгоритмов у меня стэнфордские: алгоритм должен быть доказуемо корректным (или, если он недетерминированный, иметь доказуемую вероятность корректности) и иметь доказуемое время выполнения (детерминированное или вероятностное).
senia
Вообще-то lair просто повторил ваш код на другом языке.
Он продемонстрировал, что «как на обертоне» на C# писать вполне можно и это будет не хуже, чем на обертоне, раз уж вы считаете такой код лучшим.
На C#/Java/Scala так не пишут из-за огромного количества минусов этого подхода (первый из них — смешение алгоритма и его реализации), но писать так можно.
oberon87 Автор
Ну об этом и речь, если можно писать нормальные алгоритмы на обычном Обероне за три копейки, а за пять можно еще и метод ForEach описать, чтобы вы не так сильно приставали к WHILE (хотя внутри все равно в 99% случаев будет WHILE), то зачем нужны все эти Java/C#
А про скалу вообще смешно, на JPoint такого порассказали, я чуть со стула не упал. Впрочем, мы же тут разумно беседуем, как-нибудь в другой раз расскажу.
senia
К тому времени когда вы напишете все методы вроде ForEach, которые позволят вам наконец выражать в коде высокоуровневый алгоритм, а не его частную реализацию, вы получите хоть какую-то экосистему. Эта экосистема будет заведомо хуже экосистемы любого мейнстримного ЯП. И код ваш будет хуже, чем код на мейнстримном ЯП. Но его хотя-бы можно будет читать без крови из глаз (в отличии от того, что вы уже привели).
Мейнстрим же уже предоставляет экосистему, которую не нужно писать самому и удобные средства развития этой экосистемы. Затем он и нужен.
Ну а про скалу я вас с удовольствием послушаю.
senia
Странно. Если есть метод `Select`, принимающий процедуру, то почему нет аналогичного метода `ForEach`? Тогда бы не пришлось упоминать `res.This()` и `res.Next()`, которые совершенно не относятся к предметной области.
Как-то так (обертона я не знаю):
И даже если такого метода нет, то стоило бы его написать хотябы в виде
oberon87 Автор
Алгоритмические экзерсисы не входили в мои планы, тему можно полировать до бесконечности, я лишь показал, что Оберон выражает все что нужно.
senia
Все, что нужно, выражает любой тьюринг-полный язык. Вопрос в том как он это выражает.
oberon87 Автор
Ок, ваше решение на брейнфаке ждать? Или вы хотели сами меня брейнфаком упрекнуть? Что вы совсем за людей собеседников не считаете?
senia
Я лишь демонстрирую, что ваш аргумент про «все что нужно» не корректен.
Также я пытаюсь показать вам, что даже на обертоне ваш код стоило бы написать последовательнее. Правда тогда бы он превратился в копию кода на C# с явным именованием фильтрующего и отправляющего сообщения методов.
oberon87 Автор
Нет, мой аргумент корректен, мой код это доказательство. Его достаточно.
А то, что вы весь алгоритм описали более сложными примитивами ничего не меняет. Только скрывает от вас реальное положение дел. А вы потом мне рассказываете какую-то откровенную лажу про то, как оно на самом деле. Да вы сами не знаете. Это же скрыто и неявно.
lair
Еще в голову пришло:
Не означает ли это, что ваш «словарный запас» совпадает со «словарным запасом» Оберона? Предположим, что это так, и окей, вам повезло — но что делать тем людям, которые используют другую терминологическую базу (пример я приводил выше).
Почему вы считаете, что совпадение терминологической базы конкретного программиста и конкретного языка — это признак надежности языка в целом, а не этого языка в руках конкретного программиста?
oberon87 Автор
Мой словарный запас совпадает со структурным программированием. Оберон тоже с ним совпадает. А что делать людям, которые занимаются программированием, но не понимают, что оно структурное по самому своему происхождению и по своей сути, я не знаю. Дейкстру почитать можно. Привести мысли в порядок. Я же понимаю, что все умные люди, но ума же должно хватать и на рефлексию, а не только на паттерны и парадигмы. Образовательные программы я придумывать не умею. Вот в школах надо изучать такое, пока мозг «живой». Информатика-21, и так далее.
lair
Ну то есть получается, что
Так? Или я что-то неправильно понял?
oberon87 Автор
Вы спросили, что делать людям, которые не знают чего-то, я ответил — изучить.
Про правильность речи не было. Вы скатываете беседу в красиво оформленное оскорбление. Остановитесь.
lair
Я не спрашивал, что делать люди, которые чего-то не знают, я спрашивал, что делать людям, чей словарный запас не совпадает с Обероновским. Например, он может быть шире — и людям, которые используют Оберон, приходится принудительно обеднять свой лексикон. Вы считаете, что это правильно?
oberon87 Автор
Набор базисных векторов может быть сколь угодно сложным, но упростить его в реальном трехмерном пространстве можно до трех векторов. Если люди много слов знают, еще не значит, что у них под разными словами не одно и то же скрыто. Еще путаться начнут. Basic English, слышали о таком? Вот, Оберон, Basic Imperative.
lair
Вот только Basic English плохо подходит для написания художественной литературы.
oberon87 Автор
А у нас тут не кружок юных литераторов.
lair
У нас тут кружок юных программистов. И точно так же, как не стоит писать на Basic English лирическую поэму, возможно, не всякую программу стоит писать на Oberon.
oberon87 Автор
Вам никто не навязывает.
lair
Мне утверждают, что Оберон лучше (надежнее, безопаснее, проще, понятнее) другого языка программирования (причем без указания границ применимости). В рамках метафоры это эквивалентно утверждению, что Basic English лучше для любого текста, чем любой другой английский язык.
oberon87 Автор
Утверждают допустим не совсем то, что вы проинтерпретировали, но все же, вам не навязывают сам язык, вы же должны сами к нему расположиться или нет. Если принципиально не желаете этого делать, ваше право, но тогда ведь вас не убедить вообще никогда.
lair
Понимаете ли, в чем дело… я всегда с интересом ищу инструменты, которые лучше подходят под мои задачи, чем те, которые я уже использую (потому что ни один инструмент не идеален). А тут мы видим инструмент, для которого заявлены «надёжность [....] минимальный период отладки [...] вы занимаетесь исключительно задачей». Это ли не те качества, которых мы ищем в языке программирования? Соответственно, теперь мне интересно, насколько эти утверждения совпадают с действительностью.
oberon87 Автор
Я считаю, это мое мнение, проверенное моим практическим применением оберона длительное время, что Оберон точнее переводит мои решения в действия компьютера.
Конечно, кроме языка есть еще набор паттернов проектирования. И практическая работа со стандартной библиотекой и рантаймом. Однако, так как они написаны на Обероне, я считаю, что Оберон точно так же точно выразил решения авторов этих библиотек и фреймворков.
Вот, как видно из интервью, не я один такой.
Сейчас когда я пишу на джаве го дарте js и т.д. я вижу, как мои решения приходится модифицировать под те или иные особенности экосистемы. В обероне такого не было. Возможно, это связано с образом мысли, но тут мы выходим на мировоззренческие вопросы, а они не для этого треда.
retran
>> Только структуры данных да, могут описать статические объекты этого мира.
Это неправда.
en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs
oberon87 Автор
«Только» в смысле «Когда структуры данных одни, без алгоритмов».
retran
И это тоже неправда.
oberon87 Автор
Это в SICP написано? Алгоритмы и структуры данных против SICP, давайте проголосуем за правду.
retran
Нет.
В книжке Вирта, если мне не изменяет память, написано, что ни тип данных ни тем более структура данных не может быть определена без базовых операций над ней. А вот под алгоритмами Вирт понимает уже не «поведение структур данных» как в вашем комментарии, а алгоритмы сортировки, поиска итд.
Ровно то же написано еще в нескольких книжках по алгоритмам которые я когда-то читал.
Кстати, книжка Ахо, Хопкрофта, Ульмана с похожим названием ЗНАЧИТЕЛЬНО лучше.
А описать объекты реального мира можно функциями и даже построить данные из функций. Ну если конечно у вас есть замыкания, которые вам не нужны. И вот про это уже SICP.
К слову, Вирт не придумал НИЧЕГО кроме нескольких языков с паршивой даже по тем временам семантикой. И типы данных, и структуры данных, и структурное программирование как таковое придумал далеко не он.
oberon87 Автор
Вы все же приведите цитату Вирта про это.
А ваши слова про семантику это вообще смех, это вам в соседний тред, где язык Яист и прочие юмористические этюды.
retran
Вас в гугле забанили? Первая же глава в книжке «Алгоритмы + Структуры данных = Программы».
Прошу прощения, статью про Яист я дропнул где-то на первой четверти.
Считать, что языки отличаются именно синтаксисом… Я даже не знаю как это прокомментировать.
lair
Слушай, до меня, кажется, дошло. А мы тут, случайно, не на триггер старого срачика «европейская vs американская школа» наступили?
retran
Ты про «Дейкстра против Америки» и Алгол?
lair
Как минимум про первое.
retran
У меня есть некоторые сомнения в том, что топикстартеры в курсе.
Это типичное «наш уважаемый гуру нам так сказал и мы поверили, а аргументировать не умеем».
oberon87 Автор
Про европейскую школу? Или про что? А почему сомнения?
oberon87 Автор
Конкретную цитату про то, что высказывание «одни только структуры данных могут описать статические объекты этого мира» неверно.
retran
А можно мне перед этим цитату ПОДТВЕРЖДАЮЩУЮ ваше утверждение?
Ведь как принято в академической среде, к которой вы скорее всего имеете отношение.
Выходишь на защиту — подтверди источниками.
А свое я могу подтвердить легко. snilit.tspu.ru/uploads/files/default/virt.pdf — страницы 18-19, почитайте.
oberon87 Автор
Вам знаком смысл слова «конкретный»? Или у вас избирательная слепота и вы не заметили это слово?
oberon87 Автор
Моя вот
Очевидно, что автор утверждает о существовании объектов и данных, при этом алгоритмы еще не введены. Далее вводится понятие структурированных данных и операций с ними, а уже затем алгоритмов.
retran
Ну вот.
«Далее вводится понятие структурированных данных и операций с ними.»
А я о чем?
Вы выше пишете о том, что структурированные данные бывают без поведения, теперь сами себя опровергаете.
oberon87 Автор
Я о том, что данные описывают объекты, и только потом с ними можно выполнять действия. А можно и не выполнять, и поведение в этом смысле пропадает.
oberon87 Автор
Конкретную цитату ждать или вы уже все для себя выяснили?
retran
Стоп-стоп-стоп.
Во-первых, ваша цитата ваше утверждение не доказывает.
Во-вторых, это вы опровергаете Вирта, а не он вас, поэтому в его книжке, которая скорее всего старше вас, прямого ответа на ваше утверждение быть не может.
Тот текст, которому противоречит ваше утверждение я вам скинул, а дальше это уже ваше бремя доказывать что вы правы.
oberon87 Автор
То есть это вы сказали, что я не прав, а я отбиваться должен? :)
А вы неправы в том, что я не прав. Это уже ваше бремя доказывать, что вы правы.
retran
Нет, вы не должны отбиваться. Вы должны защищать утверждение с которым вы вышли на публику.
Представьте, выходит студент на защиту диплома и говорит: «Я изобрел бесконечный двигатель». А ему говорят — «Докажите тогда.». А он в ответ: «Нет, это вы доказывайте, что я не прав.».
Ну вот, вы выступили с заявлением, которое противоречит принятой теории типов. Обосновывайте.
Смешно же?
oberon87 Автор
Единственное, что я могу еще вам сказать, так как вы не можете даже процитировать место, в котором текстом говорится что-то противоречащее моим словам, я предполагаю, что мы не сошлись словарями. А это разговор еще на неделю, каждое важное слово определить.
Так что ваши слова не подтверждены цитатой, а мои не доказаны, вы не мой оппонент на защите, а я не ваш студент, поэтому спор считаю бесцельным.
retran
Избирательная слепота похоже не лечится, извините.
Рекомендую, все таки как-то повнимательнее читать комментарии и книги.
Аргументировать свою позицию вы отказались.
Ну ок, слив засчитан.
oberon87 Автор
Вы так забавно засчитываете победу самому себе. Вот бы наши так в футбол играли.
retran
А еще можно посмотреть определение из теории типов, о которой Вирт не может не знать.
ru.wikipedia.org/wiki/%D0%A2%D0%B8%D0%BF_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
aTwice
И снова о вкусах…
oberon87 Автор
Не сомневаюсь, что даже среди адептов Си есть люди, которые солидарны с Александром. Но кактус сладок, видимо.
shushu
Похоже, плохих программистов будут засталять писать в аду на обероне…
oberon87 Автор
Почему? И что такое «плохой» программист?
poxu
Почитал статью, посмотрел на код. Судя по статье это Оберон это офигенно. Ну собственно когда человек написал компилятор, который сам и использует, оно неудивительно. Думаю он очень хорошо понимает что делает и зачем он это делает.
У меня только один вопрос. Про код. От капса ни у кого глаза не вытекают? PROCEDURE, WHILE, INTEGER и всё такое? Или это я один смотрю и думаю сколько всего пришлось печатать с зажатым шифом, или упаси господи капслоком?
oberon87 Автор
Капс лично я научился применять в виде визуальных маркеров для глаз. Поэтому программы я пишу без подсветки синтаксиса.
В сообществе часто случались размышления, почему сам Вирт так держится за капс, мнений было много, но я сам встречал цитату Вирта о том, что он оставил капс для компилятора и опасных системных вещей, чтобы человек обращал на это внимание.
Сам я проблем с печатью никогда не испытывал, руки программиста могут печатать что угодно, это же профессиональный навык.
poxu
Номер раз — человеческий мозг распознаёт подсветку на порядок лучше символов. Если вы конечно не носитель редкой мутации, которая позволяет распознавать символы.
Номер два — для того, чтобы напечатать что-то капсом надо либо одной рукой держать шифт и печатать, либо (что привычнее тем, кто печатает вслепую) чередовать руки с шифтами, либо надо нажать капслок и отжать капслок после окончания печати. Всё это раздражает. Шифты зажимать для написания частвовстречающихся конструкций языка раздражает особенно сильно. Но капслок у меня, например, перемаплен на контрол, так что альтернативы шифтру нет.
oberon87 Автор
Не стану гадать, мутант я или нет, может быть я вообще не разбираю символы. Просто пятна разной площади. А по поводу капса тут могут быть какие-то решения. Кажется, в школьной версии был автокапсователь
poxu
Узнать не мутант ли вы можно посмотрев на две картинки вот тут olegart.ru/wordpress/2011/02/25/3229. Увы, такая мутация очень маловероятна, хотя кто знает.
У меня создаётся впечатление, что достоинства, которые вы находите у Оберона это те же самые достоинства, которые обычно приписывают Си. То есть оно хорошо транслируется непосредственно в машинную архитектуру, не прячет детали и простое как чугунный лом. Я правильно понимаю?
monah_tuk
У Си нету сборщика мусора. Хотя в проекте выше выделения памяти в куче и сборщик и не используются.
poxu
Нету. Но аргументы за похожи.
Filippok
hh.ru/search/vacancy?text=%D0%BE%D0%B1%D0%B5%D1%80%D0%BE%D0%BD&area=1
Шах и мат.
oberon87 Автор
Эту песню не задушишь, не убьешь.
northbear
Это клуб троллей и школьников, которые вечно ищут работу. Зря вы взялись им рассказывать про Oberon… ))
Уверен, для них новость, что есть класс программистов, которых на headhunter'е не нанимают… )))
Расслабьтесь и не кормите их. Не вы первый, кого эти орлы тут заминусовали…
NeoCode
У вас там процедура ASR2 вложенная (nested) в процедуру Update. А скажите, происходит ли захват переменных? Доступны ли локальные переменные Update из ASR2, и сохранятся ли они, если из Update вернуть адрес ASR2?
oberon87 Автор
Вложенная процедура доступна только из того скоупа, в который она вложена. И ее собственный скоуп возникает при вызове и исчезает после вызова. В прежних версиях Оберона был возможен доступ к переменным внешнего скоупа, сейчас Вирт это убрал. На простом стеке, насколько я знаю, достаточно трудно сделать нормальные кложуры, да и зачем.