Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 388
Астрологи объявили неделю Оберона. Количество языкосрача в комментах утраивается.
Извините.
Извините.
Посмотрел код — глаза вытекли. Не знаю теперь вот, куда деваться.
Доктор сказал «В морг.», значит, в морг.
Код – это просто ад. Надо давать студентам как пример того, как никогда не нужно писать код.
И это при том, что на работе приходится часто иметь дело с Oberon-2, т. е. глаза более-менее привыкшие.
И это при том, что на работе приходится часто иметь дело с Oberon-2, т. е. глаза более-менее привыкшие.
В то время, как в Цюрихе будут давать студентам новый курс Вирта, вы будете говорить, чтобы они так не делали. Интересно рассуждаете. Не поделитесь размышлениями о коде?
То есть присутствуют люди, которые считают главных по информатике в Ethz глупыми, а Оберон — отрицательным примером для студентов?
Нет, присутствуют люди, которые считают, что приведенный пример кода плох.
Оценить код Н. Вирта, вот это дело. Не каждый день бывает.
Берем список правил из Макконелла и плохие запахи из Фаулера и оцениваем. Абсолютно беспристрастно по выработанным сообществом разработчиков и описанным вышеупомянутыми авторами принципам.
И одно уже именование переменных выдает типичный «академический код», написанный человеком никогда не участвовашем в разработке реального продукта.
И одно уже именование переменных выдает типичный «академический код», написанный человеком никогда не участвовашем в разработке реального продукта.
Это точно! Не уедут они далеко с переменными n и N.
Посмотрел код, глазам стало больно. Очень похоже на примеры из книг серии «как не надо писать код».
Удивительно что эти люди (уже не первый раз) говорят об уменьшении количества ошибок в коде. Смотря на ихние советы и примеры — похоже на саботаж.
Удивительно что эти люди (уже не первый раз) говорят об уменьшении количества ошибок в коде. Смотря на ихние советы и примеры — похоже на саботаж.
Мне кажется, что все три аккаунта — это один и тот же человек. Уж слишком стиль изложения и образ мысли совпадают.
Возможно (вообще их четверо: kisybi, OberonForGood, oberon87 и akastargazer). Тоже заметил что все аппелируют к одной и той же цитате «язык должен быть максимально простым но не проще» и дальше утверждают что оберон — это и есть тот самый язык, а когда просишь обосновать — начинают переводить тему, говорить «рынок ничего не понимает» и приводить в примеры сниппеты говнокода. Еще забавно что все начали активность примерно в одно время.
Скорее некий препод и его студенческая секта.
Демагогия, переходы на личности, аппеляции к авторитетам и вера в «непогрешимость оберона» без понимания сути вопроса…
Точно, студенты, у которых бомбануло.
Демагогия, переходы на личности, аппеляции к авторитетам и вера в «непогрешимость оберона» без понимания сути вопроса…
Точно, студенты, у которых бомбануло.
Когда мы увидим Ваш проект уровня Системы Оберон, тогда и посмотрим, где саботаж, а где просто вы тренируетесь в острословии.
А ошибок на весь проект сколько, уже посчитали?
А ошибок на весь проект сколько, уже посчитали?
По мне — так весь код в приведенном выше файле — одна сплошная ошибка, ибо читать его невозможно. Одно это чего стоит:
Кстати об ошибках — вот тут уже и косяк, qb на NIL проверяется, а pl — нет, а при этом pl — это указатель который может быть нулевым, и нигде выше по методу не гарантируется что он будет не нулевым.
VAR pl, pr, p, qb, qe: Piece; org, end: LONGINT;qb.f? pl.off? voff? Серьезно? Это продакшн код или первые шаги школьника изучающего программирование? Я, помню, писал такой код в школе примерно первые пару лет после того как купил первую книжку по программированию.
IF (qb # NIL) & (qb.f = pl.f) & (qb.off = pl.off + pl.len) & (qb.fnt = pl.fnt) & (qb.col = pl.col) & (qb.voff = pl.voff) THEN
Кстати об ошибках — вот тут уже и косяк, qb на NIL проверяется, а pl — нет, а при этом pl — это указатель который может быть нулевым, и нигде выше по методу не гарантируется что он будет не нулевым.
На Обероне это просто работает. Я и сам так пишу. Впрочем, происхождение Ваших оценок понятно, а как мы убедились, личное мнение комментатора самое верное.
Это не мое исключительное личное мнение, это базовые правила написания хорошего кода, о которых говорится в любой более-менее известной книге по написанию хорошего кода, которые есть практически в каждом гайде и которые используются повсеместно. Работать оно будет хоть на обероне, хоть на любом другом языке, компилятору на это пофиг, вот только люди читать и разбираться в этом будут гораздо дольше. С null'ом тоже ошибку не выкинет? Или все ошибки написанные на обероне — это не ошибки а фичи?
Гайды важны, но не стоит забывать что они не для Оберона изначально написаны.
Да не важно какой язык, qb.voff = pl.voff — нечитаемо вне зависимости от языка.
Код написан настолько безобразно, что даже автор вероятно через год не сможет разобрать его.
Код написан настолько безобразно, что даже автор вероятно через год не сможет разобрать его.
Вы джавист?
Нет. Вообще не вижу как это может влиять на тот факт что код по ссылке — безобразен?
Я приведу еще один пример:
Еще к «безошибочности»:
О чем все это говорит?
Те кто пишут говнокод — будут писать его на любом языке.
Те кто пишут говнокод — будут делать ошибки на любом языке.
Ну и кроме того — язык в принципе не может уберечь от 99% ошибок, потому что они языко-независимы.
Я приведу еще один пример:
PROCEDURE SetWidth*;Что такое S.i? И почему он может быть от 1 до 6?
VAR S: Texts.Scanner;
BEGIN GetArg(S);
IF (S.class = Texts.Int) & (S.i > 0) & (S.i < 7) THEN Graphics.SetWidth(S.i) END
END SetWidth;
Еще к «безошибочности»:
PROCEDURE Backup (VAR name: ARRAY OF CHAR);Если входящая строка более 32 символов — что будет? Будет ошибка, потому что массив выделяется на 32 элемента внутри. А если строка 28 символов или более но меньше 32 — то метод просто молча ничего не делает.
VAR res, i: INTEGER; ch: CHAR;
bak: ARRAY 32 OF CHAR;
BEGIN i := 0; ch := name[0];
WHILE ch > 0X DO bak[i] := ch; INC(i); ch := name[i] END;
IF i < 28 THEN
bak[i] := "."; bak[i+1] := «B»; bak[i+2] := «a»; bak[i+3] := «k»; bak[i+4] := 0X;
Files.Rename(name, bak, res)
END
END Backup;
О чем все это говорит?
Те кто пишут говнокод — будут писать его на любом языке.
Те кто пишут говнокод — будут делать ошибки на любом языке.
Ну и кроме того — язык в принципе не может уберечь от 99% ошибок, потому что они языко-независимы.
S.i это аккумулятор для пользовательского целочисленного параметра при вызове команды? Я просто код не видел еще, исхожу из того, что вы дали. А как еще назвать?
Второй кусок тоже неясно, чем вам не понравился, ведь явно написано, ЕСЛИ длина меньше 28, единственное на что вы можете жаловаться, это на отсутствие комментария с пояснением.
Второй кусок тоже неясно, чем вам не понравился, ведь явно написано, ЕСЛИ длина меньше 28, единственное на что вы можете жаловаться, это на отсутствие комментария с пояснением.
Вы правда ошибки не видите? Если длина больше 28 но меньше 32 — код ничего не делает. Я вызываю метод Backup а он не делает то, что обязуется делать по своему названию. А если больше 32 символов — вообще упадет с исключением доступа к памяти или подобным, что тоже совершенно странно.
А с чего вы взяли что S.i — это аккумулятор? Я вот думаю что это 14, потому что Si — Silicon — 14й элемент в периодической таблице. А может это сокращение от iterator?
А с чего вы взяли что S.i — это аккумулятор? Я вот думаю что это 14, потому что Si — Silicon — 14й элемент в периодической таблице. А может это сокращение от iterator?
Я просто код не видел еще, исхожу из того, что вы дали. А как еще назвать?Вот в этом и суть — чтобы понять то что делает строчка в методе — надо залезть еще посмотреть кучу окружающего кода, а код должен быть самодокументируемым, посмотрел на метод — понял что он делает на базовом уровне. Это должно быть очевидно из названия метода, названия параметров и тела метода, из контекста можно привязать еще название класса, но никак мне не нужно лезть в дебри чтобы понять что такое S.i.
Вы можете называть свои переменные, как вам угодно. Код на обероне все равно останется надежным, хоть с длинным хоть с коротким именем.
И да, возможно, процедура Backup просто не обязана работать всегда, это личное дело автора. Все равно она будет работать так, как он задумал. Упадет — поправит. Непонятно, с чего вы взяли, что это влияет на надежность языка и его свойств по реализации алгоритмов? Впрочем, чего это я.
И да, возможно, процедура Backup просто не обязана работать всегда, это личное дело автора. Все равно она будет работать так, как он задумал. Упадет — поправит. Непонятно, с чего вы взяли, что это влияет на надежность языка и его свойств по реализации алгоритмов? Впрочем, чего это я.
Вы можете называть свои переменные, как вам угодно.
То есть читаемость и поддерживаемость больше не имеют значения?
Код на обероне все равно останется надежным,
Что лично вы вкладываете в понятие «надежность» в этой фразе?
Алё, гараж, это код не мой, все ошибаются, а процедура явно не очень важна. А накидать проблемных мест любой может, см. статью про Яист. Просто одни это сделали своей основной деятельностью, штатные эксперты-критики, а другим просто не до того.
Я лишь говорю о том, что код на Обероне работает так, как его написали. Надежно передавая ваши мысли машине. Вот написал автор процедуру, и она будет работать. Алгоритмическая часть передается обероном точно, а уж что там за алгоритм, можете рассуждать сколько влезет.
Плюс Оберон еще и понятен всем подряд. Даже джавистам.
Я лишь говорю о том, что код на Обероне работает так, как его написали. Надежно передавая ваши мысли машине. Вот написал автор процедуру, и она будет работать. Алгоритмическая часть передается обероном точно, а уж что там за алгоритм, можете рассуждать сколько влезет.
Плюс Оберон еще и понятен всем подряд. Даже джавистам.
Надежно передавая ваши мысли машине. Вот написал автор процедуру, и она будет работать. Алгоритмическая часть передается обероном точно,
Точно или надежно?
That aside, что вы понимаете под точностью передачи алгоритмической части, и почему вы считаете, что Оберон передает алгоритмическую часть точнее других языков? (или вы этого не считаете?)
А что же тогда «надежность языка»? Если он не помогает избегать ошибок — то в чем это преимущество, которое вы тут расписываете?
Вообще, вы сейчас делаете странную вещь, лезете в новую для вас экосистему со своим набором правил. Я не говорю, что они все не работают, но вы не доказали их применимость. А уж основное преимущество вашей позиции в том, что остальным просто лень лезть в кишки ядра линукс или jvm и искать там недостатки.
что остальным просто лень лезть в кишки ядра линукс или jvm и искать там недостатки.Так там есть недостатки, я же не утверждаю что язык на котором я пишу — магическим образом снижает количество ошибок, не требует отладки и прочие ереси, которые тут расписывают оберонщики. Конечно есть недостатки в любом более-менее большом проекте, это очевидно. Создание безошибочного кода (а точнее понижение вероятности ошибок до определенного уровня который можно считать «принебрежимо малым») — это очень долго и дороге, вне зависимости от языка.
но вы не доказали их применимость.Т.е. на обероне не надо писать разборчивый код? Эти вещи не зависимы от языка.
Извините, пожалуйста, я дурак, который пока не понимает сути оберона.
Вы не могли бы мне рассказать на простом примере, в каком месте семантика оберона отличается от семантики любого другого статически-типизованного язык программирования?
Ну, например, чем if в обероне отличается от if в C# и почему обероновская конструкция надежнее?
Или на примере for. Или любой семантической конструкции, которую вы посчитаете хорошим примером.
Еще раз прошу обратить внимание на то, что я говорю про семантику.
Вы не могли бы мне рассказать на простом примере, в каком месте семантика оберона отличается от семантики любого другого статически-типизованного язык программирования?
Ну, например, чем if в обероне отличается от if в C# и почему обероновская конструкция надежнее?
Или на примере for. Или любой семантической конструкции, которую вы посчитаете хорошим примером.
Еще раз прошу обратить внимание на то, что я говорю про семантику.
Например, у них циклы без break и continue то есть по заголовку while можно однозначно определить, при каких условиях он завершится, не лазя в тушку
Ну как сказать… в Обероне-07 есть цикл Дейкстры, там заголовком не обойдешься. И его анализ головой не так уж прост.
Я имел ввиду, что есть такие циклы, а не, что все они такие.
while(!done)
{
...
if (...)
{
done = true;
}
...
}
Цикл завершится когда done. Толку от этого? И к тому же отсутствие continue и break порождает дополнительную вложенность, что не есть хорошо.
Отсутствие break гарантирует, что после цикла условие цикла будет ложным. А так как условие это expression, в циклах на обероне реализуется подход, который в свое время так хотели сишники, но не получили, подход, при котором в теле цикла в идеале только счетчик или пустота(для итераторов). А это уже ведет к тому что формула в условии может быть верифицирована при чтении.
Вы не понимаете что break — это выражение логики? Уберите break из синтаксиса и в условии while появится переменная bool done, break заменится на done = true, а в теле появятся дополнительные if(!done), да, после цикла переменная будет равна true, но только толку от нее уже не будет. Или появится while (!done && condition) вместо while(condition), все равно в конце цикла значение condition будет для вас неизвестным. И еще охватите дополнительные ошибки из-за того что надо будет писать if'ы и тем самым увеличивать цикломатическую сложность. Оно нужно?
PS. Почему вы появились в топике сразу как только заблокировали oberon87 и kisybi? Мы правы и это просто еще один виртуал?
PS. Почему вы появились в топике сразу как только заблокировали oberon87 и kisybi? Мы правы и это просто еще один виртуал?
Уважаемый, вы сейчас демонстрируете, как бы это помягче выразиться, легкое недопонимание того, как правильно применять циклы, то есть, демонстрируете понимание их сути, вот что с вами форыч сделал.
Например, есть статья oberoncore.ru/wiki/%D0%BF%D0%B0%D1%82%D1%82%D0%B5%D1%80%D0%BD%D1%8B_%D1%86%D0%B8%D0%BA%D0%BB%D0%BE%D0%B2 (в ней еще ссылки, тоже сходите почитать)
Если вы отвлечетесь от форыча и break, то заметите, что автор статьи строит циклы таким образом, чтобы ни дублирования не было, ни выхода из середины. Как ему это удается, ведь вы же только что сказали, что цикломатическая сложность, два флага, куча IF? Тут вы слегка облажались, конечно. И это, заметьте, только один вид циклов, с предусловием. С постусловием в два раза круче будет.
Например, есть статья oberoncore.ru/wiki/%D0%BF%D0%B0%D1%82%D1%82%D0%B5%D1%80%D0%BD%D1%8B_%D1%86%D0%B8%D0%BA%D0%BB%D0%BE%D0%B2 (в ней еще ссылки, тоже сходите почитать)
Если вы отвлечетесь от форыча и break, то заметите, что автор статьи строит циклы таким образом, чтобы ни дублирования не было, ни выхода из середины. Как ему это удается, ведь вы же только что сказали, что цикломатическая сложность, два флага, куча IF? Тут вы слегка облажались, конечно. И это, заметьте, только один вид циклов, с предусловием. С постусловием в два раза круче будет.
То, что по вашей ссылке, называется «итератор». И вы не поверите, но foreach (по крайней мере в C#) внутри работает именно так.
ru.wikipedia.org/wiki/%D0%98%D1%82%D0%B5%D1%80%D0%B0%D1%82%D0%BE%D1%80
Покажите мне, пожалуйста, цикл по элементам коллекции коллекций (т. н. jagged array) с выходом из цикла по простому условию.
ru.wikipedia.org/wiki/%D0%98%D1%82%D0%B5%D1%80%D0%B0%D1%82%D0%BE%D1%80
Покажите мне, пожалуйста, цикл по элементам коллекции коллекций (т. н. jagged array) с выходом из цикла по простому условию.
Человек приводит в пример пару циклов и объявляет что вот такие паттерны есть а других циклов быть не может. Ну это совершенно ничего не доказывает. Есть вполне хорошие гайды, есть примеры как не надо делать, в том числе — где не надо ставить break. Если цикл простой и с break выглядит лаконичнее — пишем с break. Если нет — пишем без.
Иногда код ложится на семантику for/foreach, тогда писать через while — не особо красиво
А с for без break будет:
сравните с:
Я сразу избавился от забот об индексации, об инкременте индекса, о введении каких-либо дополнительных переменных.
Примеры конечно несколько упрощены, т.к. в данном случае вообще нужно писать:
Иногда код ложится на семантику for/foreach, тогда писать через while — не особо красиво
int i = 0;
while(i < something)
{
var currentListElement = someList[i];
...
i++;
}
А с for без break будет:
for (int i = 0; i < something && stayInLoop; i++) { ... }сравните с:
foreach(var currentListElement in someList)
{
if (IsThisTheElementImLookingFor(currentListElement))
{
result = currentListElement;
break;
}
}
Я сразу избавился от забот об индексации, об инкременте индекса, о введении каких-либо дополнительных переменных.
Примеры конечно несколько упрощены, т.к. в данном случае вообще нужно писать:
var result = someList.FirstOrDefault(IsThisTheElementImLookingFor);Ага, нет выхода из середины. Зато:
«Правильное применение циклов», говорите?
- в «полном проходе» дублирование «первой» и «следующей» ситуации
- в «линейном поиске» две проверки «конца ситуаций»
«Правильное применение циклов», говорите?
Мы правы и это просто еще один виртуал?
Да
Надо называть не done, а более конкретно:
Тогда понятнее смысл цикла
while(!found && I.moveNext())
{
...
Found = ...
If(found)
{
....
}
...
}
Тогда понятнее смысл цикла
Так я об этом и говорю — проблема не в break или continue. Написать непонятно можно и без них, и с ними можно написать понятно. То, что делает break должно быть понятно из контекста данного метода, в котором есть цикл. Если есть break — значит он не в конце цикла, значит он заставляет цикл пропустить какие-то инструкции, значит если его убрать — образуется новый if, возможно не один. Есть гайды как писать код, в нормальном коде абсолютно понятно что и как делают break и continue. Если человек пишет while на два экрана, так что не разберешь — так проблема тут совсем не в break.
Если есть break — значит он не в конце цикла, значит он заставляет цикл пропустить какие-то инструкции, значит если его убрать — образуется новый if, возможно не один.
И это нормально — кусок который не всегда будет выполняться будет выглядеть вложенным и отделен от остального. В конец итерации цикла всегда можно будет вставить кусок кода, который будет гарантированно выполняться. Рассуждать про свойства цикла будет проще.
Кстати, этот самый цикл Дейкстры есть в каждом втором коде на эрланге, записанный в виде хвостовой рекурсии и паттерн-матчинга.
Для меня было открытием, что оказывается, это цикл Дейкстры.
Для меня было открытием, что оказывается, это цикл Дейкстры.
>>> Вообще, вы сейчас делаете странную вещь, лезете в новую для вас экосистему со своим набором правил
Ооо. С такой агрессией вы в свою секту адептов много не наберёте
Ооо. С такой агрессией вы в свою секту адептов много не наберёте
А вы прям считали процент? Или просто так красиво соврали?
По своему опыту сужу. Ошибки связанные с языком это в большинстве — ошибки удаления объектов (компенсируемые сборщиком мусора), частично ошибки работы со строками и индексами массивов (компенсируются объектами строк и массивами со встроенной длиной) и подобное.
Например null reference exception — это не ошибка языка, даже если в языке запретить null и указатели вообще — эта ошибка получит просто другое имя, т.к. это семантическая ошибка обращения к несуществующему элементу. Уберите указатели и эта ошибка просто превратится в обработку элемента-«пустышки», если логика кода этого не предусматривает — это так же приведет к ошибкам. Я сейчас не припомню даже когда последний раз видел ошибку именно свойственную языку а не ошибку в логике которая могла бы появиться в любом языке.
Например null reference exception — это не ошибка языка, даже если в языке запретить null и указатели вообще — эта ошибка получит просто другое имя, т.к. это семантическая ошибка обращения к несуществующему элементу. Уберите указатели и эта ошибка просто превратится в обработку элемента-«пустышки», если логика кода этого не предусматривает — это так же приведет к ошибкам. Я сейчас не припомню даже когда последний раз видел ошибку именно свойственную языку а не ошибку в логике которая могла бы появиться в любом языке.
Про NRE не соглашусь: в большинстве случаев это именно ошибка вида «не учел, что тут объекта может не быть». И язык позволяет уменьшить количество таких ошибок почти до нуля — достаточно убрать null из языка. Тогда невозможно будет забыть, что работаешь с оберткой.
С чего это? Как раз будет просто другая ошибка — обертка будет обрабатываться как обычный объект. Если в ней будет где-то целочисленный 0 на который делят — получим ошибку деленя на 0, а то и хуже — можем получить ошибочные данные или сохранять пользовательский документ в пустоту.
Обертка (Maybe/Option) имеет другой тип. Нельзя разделить на Option[Int]. Нельзя вызвать метод myMethod у Option[Item].
В том же котлине компилятор просто не позволит использовать Item? как Item если в коде нет гарантии на то, что Item? — не null (а Item? — другой тип).
В том же котлине компилятор просто не позволит использовать Item? как Item если в коде нет гарантии на то, что Item? — не null (а Item? — другой тип).
Так будут делить на myIntValueOption.Value без проверок как сейчас делят на myObject.MyIntValue без проверки на null. Т.е. проблема остается. Хотя все эти проблемы относительно легко выявить статическим анализом, если не совсем какой-нибудь хитро-запущенный случай.
Value — это из C# же? Нет там нормальных Option значений, а на то, что есть, без слез не взглянешь.
Да, к сожалению, сейчас только Maybe не позволяет стрелять себе в ногу. Но и остальные не позволяют забыть. Как я уже писал большинство NRE в моей практике из-за того, что кто-то забыл проверить.
И все выстрелы в ногу вычищаются анализатором. В той же scala достаточно запретить через scalaStyle вызов get на Option, в котлине — notNull, в java — тоже get. Это уже можно сделать и это уже активно применяется.
Да, к сожалению, сейчас только Maybe не позволяет стрелять себе в ногу. Но и остальные не позволяют забыть. Как я уже писал большинство NRE в моей практике из-за того, что кто-то забыл проверить.
И все выстрелы в ногу вычищаются анализатором. В той же scala достаточно запретить через scalaStyle вызов get на Option, в котлине — notNull, в java — тоже get. Это уже можно сделать и это уже активно применяется.
Я ниже ответил. В данном случае ошибки просто переносятся из одной области в другую. Можно городить защитные механизмы для предотвращения ошибки, но эти защитные механизмы сами являются кодом и сами могут содержать ошибки. Можно обязать проверять на != null перед каждым обращением к объекту, но никто не гарантирует что в ветке else этой проверки (которую теперь придется писать) будет корректная обработка — что по сути ошибка той же природы, только вынесенная в другое место.
И в третий раз: подавляющее большинство NRE — не из-за неправильно обратобки случая с null, а из-за того, что человека забыл, что тут может быть null.
Это мне напоминает спецификатор throws — была точно такая же история. Люди забывали что метод может выкинуть исключение X. Решение казалось бы простое — давайте заставим всех явно каждый раз обращать на это внимание, или добавляем исключение в throws или обрабатываем. Итог? Никто не захотел работать с overhead'ом, вызванным этим спецификатором. И толку от этого небыло, просто перехватывали все подряд исключения и забивали. Т.е. формально ошибка в том виде в котором она была — исчезла, но по факту она просто перетекла в другие виды ошибок. Здесь то же самое. Если вы обяжете всех везде каждый раз работать с проверками — вы наплодите кучу других ошибок. Точно так же как забывали проверить на null будут забывать что в метод могут передать null и все проверки окажутся бесполезными. Процент исходных ошибок уменьшится — но он перетечет в другие. При этом NRE — замечательная ошибка, потому что она обнаруживаемая, она не портит данные в тихую, не сохраняет файл в пустоту и т.д. (а именно в эти типы ошибок перетечет NRE если пытаться полностью вычистить его из языка). Кроме того NRE проверяется статическим анализатором на ура, в то время как ошибки в которые он превратится если его убрать — тяжело обнаружимы.
Гораздо лучше когда язык позволяет в тупую делать обнаружимые ошибки, потому что попытки избавиться от этих ошибок скорее всего приведут к тому что вместо них появятся ошибки которые тяжело обнаружить (может их и будет меньше, но время на поиск и исправление таких ошибок многократно выше). Опять же возрастет сложность кода.
Гораздо лучше когда язык позволяет в тупую делать обнаружимые ошибки, потому что попытки избавиться от этих ошибок скорее всего приведут к тому что вместо них появятся ошибки которые тяжело обнаружить (может их и будет меньше, но время на поиск и исправление таких ошибок многократно выше). Опять же возрастет сложность кода.
throws — неудобное переизобретение Validation. Были бы удобные механизмы для работы с Validation — использовались бы (но это был бы уже другой язык). Там, где, например в scala, используется Validation никто его не игнорирует.
Разница между обнаружением NRE и не компилируемостью Option только в том, что NRE обнаружится уже только в рантайме. А уж какие средства будут использованы для устранения NRE и для написания компилируемого кода с Option — зависит от программиста. И там и там можно наговнокодить одинаково.
Вычисление же NRE статическим анализатором — это что-то новенькое. разве что при помощи Null/@NotNull, что является неудобным переизобретением Option, как throws — неудобное переизобретение Validation. Со всеми теми же минусами.
Про сложность кода: если есть null, то любое поле может быть null, любой параметр может быть null и любое возвращаемое значение может быть null — куда уж больше сложность?
Разница между обнаружением NRE и не компилируемостью Option только в том, что NRE обнаружится уже только в рантайме. А уж какие средства будут использованы для устранения NRE и для написания компилируемого кода с Option — зависит от программиста. И там и там можно наговнокодить одинаково.
Вычисление же NRE статическим анализатором — это что-то новенькое. разве что при помощи Null/@NotNull, что является неудобным переизобретением Option, как throws — неудобное переизобретение Validation. Со всеми теми же минусами.
Про сложность кода: если есть null, то любое поле может быть null, любой параметр может быть null и любое возвращаемое значение может быть null — куда уж больше сложность?
подавляющее большинство NRE — не из-за неправильно обратобки случая с null, а из-за того, что человека забыл, что тут может быть nullИли забыл захватить нужный лок и получил data race. NPE вылетает редко, но метко.
см также github.com/dotnet/roslyn/issues/1648
(пре-скриптум: простите, сначала не дочитал, что написал senia %)
КМК, проблема null не в том, что он есть, а в том, что он неотличим от нормальных ссылок и поэтому его легко забыть обработать. Пусть будут пустышки, главное, чтобы если логика кода их почему-то не предусмотрела, это бы не компилилось. Тут, например, помогают мои любимые опциональные типы, которые нынче есть и в приснопамятном яисте, тьху, расте.
КМК, проблема null не в том, что он есть, а в том, что он неотличим от нормальных ссылок и поэтому его легко забыть обработать. Пусть будут пустышки, главное, чтобы если логика кода их почему-то не предусмотрела, это бы не компилилось. Тут, например, помогают мои любимые опциональные типы, которые нынче есть и в приснопамятном яисте, тьху, расте.
Если вы сделаете это не компилящимся — вам придется выкинуть из языка динамические массивы, да и со статическими работать будет очень сложно. Ровно как и возникнет проблема инициализации объектов. И даже это не поможет. Все равно в конструкторах по умолчанию, например, будут заполнять все поля самодельными «пустышками», и это по определению не будет отличимо от реальных объектов. Просто потому что ошибка сама происходит не от null'ов или подобных абстракций, а от того что существует «неинициализированное» состояние объекта. И ничто не удержит программиста от написания этого состояния самостоятельно в дефолтном конструкторе. Причем в этом случае разбухнет логика и ошибок может стать даже больше потому что станет гораздо больше различных обвязок.
Избавиться можно только от ошибок не зависящих от логики и предметной области. Например удаление объектов из памяти как таковое (т.е. не касающееся прочей логики деструктора) — это особенность работы с железом, при бесконечной памяти оно было бы не нужно. И даже тут мы все равно меняем ошибки (ручного удаления объектов) на проблемы производительности или утечки памяти (проблемы, связанные с непониманием работы GC).
Избавиться можно только от ошибок не зависящих от логики и предметной области. Например удаление объектов из памяти как таковое (т.е. не касающееся прочей логики деструктора) — это особенность работы с железом, при бесконечной памяти оно было бы не нужно. И даже тут мы все равно меняем ошибки (ручного удаления объектов) на проблемы производительности или утечки памяти (проблемы, связанные с непониманием работы GC).
Вам обязательно нужны такие низкоуровневые инструменты как массивы? Мне — крайне редко.
В большинстве случаев меня интересует только контракт на коллекцию (включая сложность операций), а не конкретная реализация коллекции.
Про конструкторы по умолчанию я вас, похоже, не понял. Достаточно либо убрать возможность обратиться к объекту в неинициализированном состоянии — immutable объект. Либо в явном виде отделить инициализируемое состояние от неинициализируемого (через Option).
Да, устранение NRE не устранит все ошибки, но оно снизит количество ошибок. И в четвертый раз: подавляющее большинство NRE происходит не из-за того, что программист не знает как обработать случай null, а от того, что он не знает/забывает, что в данном случае может быть null, так как на уровне языка любой объект в любом месте может быть null.
В большинстве случаев меня интересует только контракт на коллекцию (включая сложность операций), а не конкретная реализация коллекции.
Про конструкторы по умолчанию я вас, похоже, не понял. Достаточно либо убрать возможность обратиться к объекту в неинициализированном состоянии — immutable объект. Либо в явном виде отделить инициализируемое состояние от неинициализируемого (через Option).
Да, устранение NRE не устранит все ошибки, но оно снизит количество ошибок. И в четвертый раз: подавляющее большинство NRE происходит не из-за того, что программист не знает как обработать случай null, а от того, что он не знает/забывает, что в данном случае может быть null, так как на уровне языка любой объект в любом месте может быть null.
а от того, что он не знает/забывает, что в данном случае может быть nullКогда вы каждый раз слышите в кино предупреждение «выключите звук на мобильнике» — вы его начинаете просто игнорировать. И чем чаще вы туда ходите тем больше гарантии что на предупреждение вы не будете проверять телефон. Так же и здесь — человек точно так же будет забывать и будет машинально писать обертку, как будто все хорошо. В итоге вместо 10 NRE получите 5 трудноуловимых ошибок. Предупреждения хороши когда они осознанно обрабатываются — например при запуске стат. анализатора (и то не 100% гарантия). Но разменивать такую замечательно обнаружимую ошибку как NRE на что-то более опасное — смысла нету.
Вот проблема именно в «каждый раз». При наличии null все может быть null. Именно поэтому возникает NRE — если все может быть null и все проверить невозможно, то забывают проверять даже то. что надо.
В случае же с Option null нет. А Option может быть только то, что имеет тип Option. И таких мест. как выясняется, довольно мало.
И что такое «машинально писать обертку» в случае с Option? Машинальных действий при работе с Option всего 2:
1. getOrElse — аналог ?? для null. Если существует применимое значение по умолчанию (заметьте, относительно null ничего не изменилось).
2. map/flatMap, если значения по умолчанию нет.
Всё остальное — не «машинальные» действия.
В случае же с Option null нет. А Option может быть только то, что имеет тип Option. И таких мест. как выясняется, довольно мало.
И что такое «машинально писать обертку» в случае с Option? Машинальных действий при работе с Option всего 2:
1. getOrElse — аналог ?? для null. Если существует применимое значение по умолчанию (заметьте, относительно null ничего не изменилось).
2. map/flatMap, если значения по умолчанию нет.
Всё остальное — не «машинальные» действия.
семантическая ошибка обращения к несуществующему элементу
Это ошибка того, что не разделяются nullable и не nullable — по умолчанию считается что метод может возвратить null и это никак не контроллируется. Посомтрите например на kotlin и на проект введения не nullable ссылок на объекты в C# 7:
Вы явно декларируете ссылку как не nullable и тогда нельзя присвоить туда nullable без специальных приседаний — компилятор контроллирует.
Сэр Тони Хоар называет введение null ошибкой на миллиард долларов
www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
Да, в этом полностью согласен. Может не так ясно выразил мысль выше. Если будет nullable и не nullable ссылки — это будет акцентом, и будет смещать внимание на то что «а вот эта ссылка не nullable, а почему? надо проверить». Если же все будут не nullable то это будет просто восприниматься как ограничение (или особенность) языка и акцента не будет.
Ввести опционально не nullable ссылки было бы полезно.
Ввести опционально не nullable ссылки было бы полезно.
По поводу Backup. Она предназначена для обработки имён ограниченной длины, причём в рамках определённого контекста, где как раз и делается охрана этих самых имён. Сама процедура Backup делает ровно то, что необходимо, но не больше. Контекст уже предполагает правильность имён, поэтому нет смысла наворачивать лишнее мясо в коде. Но охрана длины всё же стоит, потому что Files.Rename жёстко завязана на длину.
Процедура Backup не универсальная, причём скрытая от клиентов модуля. Смысл, который я описал, легко можно понять, бросив короткий взгляд на исходник.
Но вы подняли крик про говнокод, не вникая, о чём идёт речь. Как обычно. Хабра-экспертиза, my ass. С последующими вселенскими выводами, конечно.
Процедура Backup не универсальная, причём скрытая от клиентов модуля. Смысл, который я описал, легко можно понять, бросив короткий взгляд на исходник.
Но вы подняли крик про говнокод, не вникая, о чём идёт речь. Как обычно. Хабра-экспертиза, my ass. С последующими вселенскими выводами, конечно.
Борис, ты не прав.
Метод называется Backup, на 28 проверяет, а если больше 32 — вылетает, так уж определитесь или не проверять совсем или проверять по человечески. Фиксированный массив на 32 — тоже шикарно. Как и +4, +8 и прочее в коде работающим со структурами там далее (удачи с портированием на другую разрядность).
Я уж не говорю о безобразнейшем копировании строк, которое не то что в принципе не безопасно, а еще и руками реализовано каждый раз.
Я уж не говорю о безобразнейшем копировании строк, которое не то что в принципе не безопасно, а еще и руками реализовано каждый раз.
Ну вот, а покажешь каллиграфически оформленный код на Аде, будут жаловаться, что можно уснуть, пока допишешь.
Сеймур Крэй мог надиктовать по телефону бутлоадер своего суперкомпьютера.
А Никлас Вирт всю жизнь тренировался на однобуквенных идентификаторах и достиг совершенства в самообфускации.
Дзен же.
Вначале были горы букв и реки строк. Потом горы перестали быть горами, а реки реками. И наконец, снова горы стали горами, а реки реками.
А Никлас Вирт всю жизнь тренировался на однобуквенных идентификаторах и достиг совершенства в самообфускации.
Дзен же.
Вначале были горы букв и реки строк. Потом горы перестали быть горами, а реки реками. И наконец, снова горы стали горами, а реки реками.
Здесь следует учитывать несколько факторов.
Имена переменных в Обероне — не «бесплатны» — они хранятся в объектных файлах и используются например в трапах, где выводятся стек вызовов и значения и имена локальных переменных и аргументов.
Так что это может использоваться, в том числе, и для отладки, ибо вся информация есть.
Во вторых, следует учитывать железо, на котором Вирт начинал программировать, его ограничение по памяти и и.п., кроме того дедушка Вирт явно увлекается ассемблером, что ествественно накладывает отпечаток на код.
К слову, ровно такой код я видел в программах на других языках.
Что касается проверки указателя, то подозреваю, что там никогда не может быть NIL
Имена переменных в Обероне — не «бесплатны» — они хранятся в объектных файлах и используются например в трапах, где выводятся стек вызовов и значения и имена локальных переменных и аргументов.
Так что это может использоваться, в том числе, и для отладки, ибо вся информация есть.
Во вторых, следует учитывать железо, на котором Вирт начинал программировать, его ограничение по памяти и и.п., кроме того дедушка Вирт явно увлекается ассемблером, что ествественно накладывает отпечаток на код.
К слову, ровно такой код я видел в программах на других языках.
Что касается проверки указателя, то подозреваю, что там никогда не может быть NIL
> Имена переменных в Обероне — не «бесплатны»
Экономить на длине имён переменных — это каменный век. Нормальные компиляторы уже давным давно умеют делать бинарные файлы так, что отладочная информация не загружается при нормальном выполнении программы. А компилятор Оберона ещё не научился?
> Во вторых, следует учитывать железо, на котором Вирт начинал программировать, его ограничение по памяти
Кто нибудь, отберите уже у Вирта его старый ZX Spectrum и подарите ему нормальную машину, чтобы он перестал паниковать, когда его программа выходит за предел 48K.
Экономить на длине имён переменных — это каменный век. Нормальные компиляторы уже давным давно умеют делать бинарные файлы так, что отладочная информация не загружается при нормальном выполнении программы. А компилятор Оберона ещё не научился?
> Во вторых, следует учитывать железо, на котором Вирт начинал программировать, его ограничение по памяти
Кто нибудь, отберите уже у Вирта его старый ZX Spectrum и подарите ему нормальную машину, чтобы он перестал паниковать, когда его программа выходит за предел 48K.
Я не являюсь фанатиком Оберона (например вот тут мы с Kemet'ом долго и нудно спорим на тему чуда портирования ОС Оберон за два выходных: habrahabr.ru/post/258993/#comment_8440659 ), но поскольку я немного в теме (лет 8-9 наверно уже как), то таки имею кое-что сказать про «старый ZX Spectrum». :-)
Итак, Вирт в Project Oberon 2013 слепил не просто операционку, или там язык, а еще и компьютер на FPGA целиком. Слеплено это дело на Spartan-3 (стоило это дело порядка 100 баксов) с использованием в качестве ОЗУ тамошней SRAM. SRAM'a там 1 мегабайт (из которых часть используется под видеопамять). В изначальной рабочей станции (Ceres) же когда Вирт делал первоначальную версию Оберона в 1989 году по естественным причинам также было что-то около 1-2 Мб ОЗУ.
В этом компьютере (на FPGA, 2013 год), в процессоре, нет MMU, а также нет и прерываний. Таким образом классическая пошаговая отладка там, мягко говоря, затруднительна (напомню, что поскольку этот процессор модель для изучения, он должен быть максимально простым и вполне обозримым в плане размеров), впрочем как и, например, вытесняющаяя многозадачность.
Поэтому даже в 2015 году отобрать у Вирта его «старый ZX Spectrum» не представляется возможным — он сам его сделал и вот как раз совсем недавно :-)
Единственное что возможно — это перенести его на какую-то новую платку с FPGA (благо повод имеется — Spartan-3 выведен из продажи), где будет больше ОЗУ. Но тут нюанс — на SDRAM (которой бывает МНОГО — десятки мегабайт! иногда сотни!) перейти будет проблематично в данном проекте: с одной стороны самому писать на верилоге модуль для работы с SDRAM (его обновления и так далее) — это существенно увеличить объемы исходников компа и их сложность, кроме того после этого остро встанет проблема процессора — у процессора Вирта нет конвеера, поэтому он будет бОльшую часть времени просто простаивать. С другой стороны, использовать готовый модуль (которые тем же Xilinx'ом предоставляются) для работы с SDRAM тоже нельзя — это противоречит духу проекта :-) Абсолютно все части компа должны быть как на ладони и понятно как работают.
А дешевых плат с большими объемами SRAM я лично не встречал :-( Собственно даже на альтеру DE2-115 просто так не перетащить: там просто так не сделать 32битную адресацию для SRAM (без потери производительности).
Если есть предложения как можно было бы наименее болезненным способом нарастить память у Оберон-компа — велком! Может совместными усилиями и придумаем что. ;-)
Итак, Вирт в Project Oberon 2013 слепил не просто операционку, или там язык, а еще и компьютер на FPGA целиком. Слеплено это дело на Spartan-3 (стоило это дело порядка 100 баксов) с использованием в качестве ОЗУ тамошней SRAM. SRAM'a там 1 мегабайт (из которых часть используется под видеопамять). В изначальной рабочей станции (Ceres) же когда Вирт делал первоначальную версию Оберона в 1989 году по естественным причинам также было что-то около 1-2 Мб ОЗУ.
В этом компьютере (на FPGA, 2013 год), в процессоре, нет MMU, а также нет и прерываний. Таким образом классическая пошаговая отладка там, мягко говоря, затруднительна (напомню, что поскольку этот процессор модель для изучения, он должен быть максимально простым и вполне обозримым в плане размеров), впрочем как и, например, вытесняющаяя многозадачность.
Поэтому даже в 2015 году отобрать у Вирта его «старый ZX Spectrum» не представляется возможным — он сам его сделал и вот как раз совсем недавно :-)
Единственное что возможно — это перенести его на какую-то новую платку с FPGA (благо повод имеется — Spartan-3 выведен из продажи), где будет больше ОЗУ. Но тут нюанс — на SDRAM (которой бывает МНОГО — десятки мегабайт! иногда сотни!) перейти будет проблематично в данном проекте: с одной стороны самому писать на верилоге модуль для работы с SDRAM (его обновления и так далее) — это существенно увеличить объемы исходников компа и их сложность, кроме того после этого остро встанет проблема процессора — у процессора Вирта нет конвеера, поэтому он будет бОльшую часть времени просто простаивать. С другой стороны, использовать готовый модуль (которые тем же Xilinx'ом предоставляются) для работы с SDRAM тоже нельзя — это противоречит духу проекта :-) Абсолютно все части компа должны быть как на ладони и понятно как работают.
А дешевых плат с большими объемами SRAM я лично не встречал :-( Собственно даже на альтеру DE2-115 просто так не перетащить: там просто так не сделать 32битную адресацию для SRAM (без потери производительности).
Если есть предложения как можно было бы наименее болезненным способом нарастить память у Оберон-компа — велком! Может совместными усилиями и придумаем что. ;-)
Кстати, мне пока не удалось обнаружить в Project Oberon 2013 подтверждение того, что имена локальных идентификаторов где-то хранятся.
Не можешь подсказать где именно эта информация находится в обеъктном файле? Вот его структура:
Ну или какой эксперимент произвести, чтобы убедиться в правдивости твоих слов.
Результаты моих личных исследований и экспериментов говорят об обратном — размер объектного файла (*.rsc) никак от именований локальных переменных не зависит.
Вот тестовый модуль:
Размер объектника получается у данного модуля всегда 320 байт. вне зависимости от того, сколько букв t в названии переменной, то есть зовется она t, или же ttttttttttttttttttttt.
Таким образом получается, что названия локальных переменных в Обероне все же бесплатны.
Или я что-то делаю не так?
Кроме того, в Обероне также нет возможности (по крайней мере я такой возможности не обнаружил) посмотреть при трапе стек или кучу. Если укажешь на таковую возможность, буду весьмя благодарен.
При трапе лишь указывается место в исходнике где трап произошел.
PS. Да, на слово я не верю, все и всегда стараюсь проверять экспериментально. Особенно если я могу это сделать. В случае с обероном я могу. Сори :-)
Не можешь подсказать где именно эта информация находится в обеъктном файле? Вот его структура:
CodeFile = name key version size
imports typedesc varsize strings code commands entries ptrrefs fixP fixD fixT body "O".
imports = {modname key} 0X.
typedesc = nof {byte}.
strings = nof {char}.
code = nof {word}.
commands = {comname offset} 0X.
entries = nof {word}.
ptrrefs = {word} 0.Ну или какой эксперимент произвести, чтобы убедиться в правдивости твоих слов.
Результаты моих личных исследований и экспериментов говорят об обратном — размер объектного файла (*.rsc) никак от именований локальных переменных не зависит.
Вот тестовый модуль:
MODULE Test;
IMPORT Files, Texts, Oberon;
PROCEDURE P*;
VAR
W : Texts.Writer;
file : Files.File;
t : INTEGER; (* длину названия именно этой переменной будем варьировать *)
BEGIN
Texts.OpenWriter(W);
file := Files.Old("Test.rsc");
Texts.WriteInt(W, Files.Length(file), 6);
Texts.WriteInt(W, 123, 6); (* число 123 будем менять, чтобы убедиться, что у нас запущена новая версия модуля *)
Texts.Append(Oberon.Log, W.buf);
END P;
END Test.
Размер объектника получается у данного модуля всегда 320 байт. вне зависимости от того, сколько букв t в названии переменной, то есть зовется она t, или же ttttttttttttttttttttt.
Таким образом получается, что названия локальных переменных в Обероне все же бесплатны.
Или я что-то делаю не так?
Кроме того, в Обероне также нет возможности (по крайней мере я такой возможности не обнаружил) посмотреть при трапе стек или кучу. Если укажешь на таковую возможность, буду весьмя благодарен.
При трапе лишь указывается место в исходнике где трап произошел.
PS. Да, на слово я не верю, все и всегда стараюсь проверять экспериментально. Особенно если я могу это сделать. В случае с обероном я могу. Сори :-)
Во-первых, а почему вы не использовали хоть как-то переменную, длину названия которой варьируете? А то наверняка компилятор не совсем дурак, неиспользуемые переменные просто игнорирует.
Зачем вообще была эта t, можно же было изменять длину названия, скажем, переменной W?
Во-вторых, я уверен, что в объектном файле есть какое-нибудь выравнивание. То есть, если речь об одной переменной, то из одного символа у неё название или из десяти — никакой разницы, возможно, нет, если выравнивается всё по «параграфу» в 256 байт. Для надёжной проверки надо взять исходник с двумя десятками переменных и менять имена их всех.
Ну и ещё можно сравнивать сами объектные файлы: если что-то изменяется, кроме времени сборки и номера версии, значит, значит, это связано с именами переменных.
Зачем вообще была эта t, можно же было изменять длину названия, скажем, переменной W?
Во-вторых, я уверен, что в объектном файле есть какое-нибудь выравнивание. То есть, если речь об одной переменной, то из одного символа у неё название или из десяти — никакой разницы, возможно, нет, если выравнивается всё по «параграфу» в 256 байт. Для надёжной проверки надо взять исходник с двумя десятками переменных и менять имена их всех.
Ну и ещё можно сравнивать сами объектные файлы: если что-то изменяется, кроме времени сборки и номера версии, значит, значит, это связано с именами переменных.
Размер бинаря — 320 байт, соответственно все выровнить по 256 не выйдет. Да и формат хорошо описан (в книжке, которуя я например читал) и там нет выравнивания по 256.
Нет, Виртовский компилятор не выкидывает, насколько я знаю, неиспользуемые переменные.
Сравнить объектные файлы несколько сложнее конечно — писать придется несколько больше (а чтобы это на персоналке проверить, нужно файлы на персоналку еще как-то передать). Но я попробую для чистоты эксперимента :-)
О результатах отпишусь чуть позже.
Нет, Виртовский компилятор не выкидывает, насколько я знаю, неиспользуемые переменные.
Сравнить объектные файлы несколько сложнее конечно — писать придется несколько больше (а чтобы это на персоналке проверить, нужно файлы на персоналку еще как-то передать). Но я попробую для чистоты эксперимента :-)
О результатах отпишусь чуть позже.
Итак, я проделал ряд экспериментов. Для этого модифицировал код следующим образом:
Программа подсчитывает сумму байт в объектнике (простейшая чексумма), а также смотрит какой объем файла объектника. В лог выдает: file_size flag sum, где flag это число для контроля того, что у нас модуль нужной версии загружен (это сделано, чтобы избежать человеческого фактора при тестировании).
Пример вывода: 432 0 32948.
Что будем менять: будем менять длину имени переменной t (2 варианта: t и t01234), будем менять длину переменных s012345678901234567890123456789 и u012345678901234567890123456789 (короткие варианты соответственно s и u), также посмотрим что будет, если этих двух переменных не будет вовсе.
При тестировании каждый вариант теста будем запускать 2 раза — с flag=0 и flag=1. Чтобы убедиться, что мы нигде не налажали.
Итак, результаты:
Итого, можно уверенно сделать следующие выводы, что:
Также можно осторожно предположить, что объем объектника не зависит от числа локальных переменных (если они не инициализируются (в том числе неявно, компилятором) и не используются).
Желающие могут попробовать воспроизвести мои результаты. У вас все для этого есть. Ну, заодно и оцените каково программировать код в Project Oberon 2013 ;-)
PS. И я посмотрел — в Project Oberon 2013 действительно удалена глава 12.9 посвященная посмертной отладке и инспекции стека и кучи. Таким образом Вирт посчитал возможность в случае падения приложения её хоть как-то отладить, лишней. Оберон стал еще проще :-)
MODULE Test;
IMPORT Files, Texts, Oberon;
PROCEDURE P*;
VAR
W : Texts.Writer;
file : Files.File;
r : Files.Rider;
t : INTEGER;
b : BYTE;
s012345678901234567890123456789, u0123456789012345678900123456789 : INTEGER; (* 2 *)
BEGIN
Texts.OpenWriter(W);
file := Files.Old("Test.rsc");
Files.Set(r, file, 0);
Texts.WriteInt(W, Files.Length(file), 6);
Texts.WriteInt(W, 0, 6); (* число 0 будем менять, чтобы убедиться, что у нас запущена новая версия модуля *)
t := 0;
WHILE ~r.oef DO
Files.ReadByte(r, b);
t := t + b;
END;
Texts.WriteInt(W, t, 6);
Texts.Append(OBeron.Log, W.buf);
Files.Close(file);
END P;
END Test.
Программа подсчитывает сумму байт в объектнике (простейшая чексумма), а также смотрит какой объем файла объектника. В лог выдает: file_size flag sum, где flag это число для контроля того, что у нас модуль нужной версии загружен (это сделано, чтобы избежать человеческого фактора при тестировании).
Пример вывода: 432 0 32948.
Что будем менять: будем менять длину имени переменной t (2 варианта: t и t01234), будем менять длину переменных s012345678901234567890123456789 и u012345678901234567890123456789 (короткие варианты соответственно s и u), также посмотрим что будет, если этих двух переменных не будет вовсе.
При тестировании каждый вариант теста будем запускать 2 раза — с flag=0 и flag=1. Чтобы убедиться, что мы нигде не налажали.
Итак, результаты:
t , s012... , u0123... : 432 0 32948
t , s012... , u0123... : 432 1 32949
--
t01234, s012... , u0123... : 432 0 32948
t01234, s012... , u0123... : 432 1 32949
--
t01234, - , - : 432 0 32932
t01234, - , - : 432 1 32933
--
t01234, s , u : 432 0 32948
t01234, s , u : 432 1 32949
Итого, можно уверенно сделать следующие выводы, что:
- Содержимое объектного файла никак не зависит от именования локальных переменных процедур
- Как и ожидалось, в зависимости от литерала flag'а (0 или 1) у нас сумма может увеличиваться на 1
- Компилятор Оберона (писанный Виртом для Project Oberon 2013) не выбрасывает неиспользуемые локальные переменные
Также можно осторожно предположить, что объем объектника не зависит от числа локальных переменных (если они не инициализируются (в том числе неявно, компилятором) и не используются).
Желающие могут попробовать воспроизвести мои результаты. У вас все для этого есть. Ну, заодно и оцените каково программировать код в Project Oberon 2013 ;-)
PS. И я посмотрел — в Project Oberon 2013 действительно удалена глава 12.9 посвященная посмертной отладке и инспекции стека и кучи. Таким образом Вирт посчитал возможность в случае падения приложения её хоть как-то отладить, лишней. Оберон стал еще проще :-)
Из этого теста один вывод: по крайней мере, для этого компилятора переменные можно называть нормально, а не t, s, и так далее. Длина имени влияет на восприятие программистом (упрощает), но никак не влияет на результат компиляции, и следовательно улучшит качество кода без каких-либо компромиссов.
Впрочем, я бы такое сказал и в случае, если бы имена переменных хранились. Это упростило бы программирование и отладку, а два мегабайта в системе, занятые длинными именами переменных, в основном стоят очень дёшево. А где не дёшево, там мегабайтов не наберётся, но там зато килобайты стоят недорого.
Впрочем, я бы такое сказал и в случае, если бы имена переменных хранились. Это упростило бы программирование и отладку, а два мегабайта в системе, занятые длинными именами переменных, в основном стоят очень дёшево. А где не дёшево, там мегабайтов не наберётся, но там зато килобайты стоят недорого.
Да. То есть в данном конкретном проекте, Project Oberon 2013 и далее, использование коротких невнятных названий переменных, лепление множества statement'ов на одну строку ничем не оправданы.
То есть это можно объяснить тем, что Вирт так привык делать, что он бОльшую часть кода позаимствовал из Project Oberon 1989, где это еще на что-то влияло, и так далее. Но факт остается фактом — Project Oberon 2013 от такого стиля кодирования автора сильно страдает. Проект оказывается неоправданно сложным для восприятия того, кто его будет изучать (например студента), более того, есть шанс, что человек посмотрит на это дело, и решит что именно так и есть правильно (и я это уже наблюдал — некоторые оберонщики именно в таком стиле и пишут, сейчас. В 2015 году. В винде например).
Конечно если бы Вирт переписал код с нормальными идентификаторами, и с нормальным форматированием кода, то те метрики которые он приводит вначале книжки (про то, сколько там строчек кода в системе, какой объем исходников, какое все мелкое и компактное получилось) несколько испортились бы. По моим оценкам, они стали бы хуже процентов на 30.
Таким образом, я бы стал рекомендовать эту книжку и ОС для обучения только либо после того, как код в ней будет приведен к нормальному стилю кодирования (рефакторинг rename + автоформатирование), либо только как часть курса «учимся разбираться и рефакторить древний говнокод». Иначе Project Oberon 2013 может нанести больше вреда чем пользы.
То есть это можно объяснить тем, что Вирт так привык делать, что он бОльшую часть кода позаимствовал из Project Oberon 1989, где это еще на что-то влияло, и так далее. Но факт остается фактом — Project Oberon 2013 от такого стиля кодирования автора сильно страдает. Проект оказывается неоправданно сложным для восприятия того, кто его будет изучать (например студента), более того, есть шанс, что человек посмотрит на это дело, и решит что именно так и есть правильно (и я это уже наблюдал — некоторые оберонщики именно в таком стиле и пишут, сейчас. В 2015 году. В винде например).
Конечно если бы Вирт переписал код с нормальными идентификаторами, и с нормальным форматированием кода, то те метрики которые он приводит вначале книжки (про то, сколько там строчек кода в системе, какой объем исходников, какое все мелкое и компактное получилось) несколько испортились бы. По моим оценкам, они стали бы хуже процентов на 30.
Таким образом, я бы стал рекомендовать эту книжку и ОС для обучения только либо после того, как код в ней будет приведен к нормальному стилю кодирования (рефакторинг rename + автоформатирование), либо только как часть курса «учимся разбираться и рефакторить древний говнокод». Иначе Project Oberon 2013 может нанести больше вреда чем пользы.
Кстати, из моих экспериментов также можно сделать вывод, что в объектнике нигде нехранится ни номер сборки который бы инкрементировался со временем при неизменном интерфейсе модуля, ни дата/timestamp сборки.
Целый эксперимент, с табличкой — у кого-то слишком много свободного времени ;)
> Таким образом Вирт посчитал возможность в случае падения приложения её хоть как-то отладить, лишней. Оберон стал еще проще
Это же очевидно! Программы на Обероне просто не могут упасть. Они сразу работают после первой-же успешной компиляции.
> Таким образом Вирт посчитал возможность в случае падения приложения её хоть как-то отладить, лишней. Оберон стал еще проще
Это же очевидно! Программы на Обероне просто не могут упасть. Они сразу работают после первой-же успешной компиляции.
Слишком много свободного времени, это в комментах переливать из пустого в порожнее на протяжении 100500 комментов ссылаясь на авторитетов и на отсутствие личного опыта у аппонентов :-)
А тут — провел эксперимент, установил факт, и всё :-) Экономия кучи времени.
На самом деле многие утверждения, звучавшие во всех тих обероновских обсуждениях могут быть опровергнуты (либо не опровергнуты) экспериментом.
А тут — провел эксперимент, установил факт, и всё :-) Экономия кучи времени.
На самом деле многие утверждения, звучавшие во всех тих обероновских обсуждениях могут быть опровергнуты (либо не опровергнуты) экспериментом.
Алексей, не стоит упирать на число 2013 в названии Project Oberon 2013 — коду в этом проекте более 20-ти лет.
Поэтому ещё раз повторяю, глянь исходники проектов на других языках, относящимся к этому времени, и часто увидишь то же самое.
Имена локальных переменных и формальных параметров есть в A2, BlackBox, Native Oberon/ETH Oberon.
Если в текущем учебном проекте такого нет (сейчас(lа и в ближайшие 2-3 недели) проверить не смогу, то Вирт следовал простому правилу, сделать, как можно проще для обучения — есть основная концепция выдачи отладочной информации, минимальная, но полностью понятная. Впрочем он многое упростил в этой редакции.
Но это никак не отменяет моих слов, что в Оберон Системах хранятся и выдаются в трапах и имена локальных переменных ( также параметров ) и их значения.
В принципе, можно всё это посмотреть в обычном hex-редакторе — эмулятор же доступен
Поэтому ещё раз повторяю, глянь исходники проектов на других языках, относящимся к этому времени, и часто увидишь то же самое.
Имена локальных переменных и формальных параметров есть в A2, BlackBox, Native Oberon/ETH Oberon.
Если в текущем учебном проекте такого нет (сейчас(lа и в ближайшие 2-3 недели) проверить не смогу, то Вирт следовал простому правилу, сделать, как можно проще для обучения — есть основная концепция выдачи отладочной информации, минимальная, но полностью понятная. Впрочем он многое упростил в этой редакции.
Но это никак не отменяет моих слов, что в Оберон Системах хранятся и выдаются в трапах и имена локальных переменных ( также параметров ) и их значения.
В принципе, можно всё это посмотреть в обычном hex-редакторе — эмулятор же доступен
Поэтому ещё раз повторяю, глянь исходники проектов на других языках, относящимся к этому времени, и часто увидишь то же самое.
Ок. Глянул. Глянул в те исходники той группы рузработчиков, у которой Вирт неоднократно заимствовал идеи и черпал вдохновение, без этой группы разработчиков никогда у Вирта оберона бы не случилось. Впрочем черпал идеи у них не он один. Я говорю о Xerox Park.
Итак, вот код 1981 года (то есть за 8 лет до релиза первого оберона, и за 6 лет до начала его написания, то есть тогда Оберона еще и в проекте не было). Язык программирования тут конечно же Mesa:
VerbalizeFtpError: PUBLIC PROCEDURE [ftpError: FtpError, message: STRING] =
BEGIN
-- Note: Appends message to string.
-- append message to string
SELECT ftpError FROM
IN CommunicationError => VerbalizeCommunicationError[ftpError, message];
IN CredentialError => VerbalizeCredentialError[ftpError, message];
IN FileError => VerbalizeFileError[ftpError, message];
IN DumpError => VerbalizeDumpError[ftpError, message];
IN MailError => VerbalizeMailError[ftpError, message];
IN ClientError => VerbalizeClientError[ftpError, message];
IN ProtocolError => VerbalizeProtocolError[ftpError, message];
IN InternalError => VerbalizeInternalError[ftpError, message];
ENDCASE => VerbalizeUnidentifiedError[ftpError, message];
-- IN UnidentifiedError
END;
И вот еще:
RemoveDeviceFromChain: PUBLIC ENTRY PROCEDURE [network: Network] =
BEGIN
tail: Network ← firstNetwork;
IF useCount > 0 THEN
BEGIN
DriverDefs.GetPupRouter[].removeNetwork[network];
DriverDefs.GetOisRouter[].removeNetwork[network];
network.deactivateDriver[];
END;
IF state = ready THEN UnlockCode[network.interrupt];
IF firstNetwork = network THEN firstNetwork ← network.next
ELSE
BEGIN
UNTIL tail.next = network DO tail ← tail.next; ENDLOOP;
tail.next ← network.next;
END;
-- network.index is not updated. It is used only to collect Gateway statistics.
END;
И более-менее нормальное форматирование, и нормальные именования переменных, и даже коментарии в коде.
Желающие могут покопать код тут: xeroxalto.computerhistory.org/Ibis/AltoGateway
Алексей, не стоит упирать на число 2013 в названии Project Oberon 2013 — коду в этом проекте более 20-ти лет.
Сергей, я люблю точные формулировки, иначе легко ошибиться. То о чем ты выше говорил для Оберона образца 2013 года просто не действительно. Я знаю эту систему (да-да, 2013 года), ты её не знаешь, как показала практика. Нельзя говорить о оберонах вообще когда рассматривается данный конкретный представитель. Ну нельзя. Иначе я могу сказать что и в Си-системах информация о именах переменных также в бинаре содержатся — это будет иметь ровно ту же степень истинности что и твое высказывание.
Если в текущем учебном проекте такого нет (сейчас(lа и в ближайшие 2-3 недели) проверить не смогу, то Вирт следовал простому правилу, сделать, как можно проще для обучения — есть основная концепция выдачи отладочной информации, минимальная, но полностью понятная.
Да… То есть если Вирт хранит имена переменных в бинаре, то это конечно потому, что он заботится о том, чтобы было проще программировать, чтобы можно было посмотреть состояние системы после краха и понять в чем дело, это избавляет От необходимости пошаговой отладки! Круто! Вирт молодец!
Если Вирт НЕ хранит имена переменных и нет возможности инспекции состояния системы после краха, то Вирт просто следует принципу максимальной простоты. Вирт снова молодец!
Предлагаю сюда добавить также, что и стиль кодирования Вирта тоже прекресен именно потому, что он становится легко переносим между этими двумя концепциями — даже если мы будем сохранять имена переменных в бинаре, то это будет минимальный оверхед из за стиля программирования Вирта. Вирт и тут молодец!
Похоже что бы Вирт не делал всегда найдется объяснение почему Вирт в этом случае молодец, а все остальные, мейнстримщики, просто не понимают глубину его мысли :-)
Честное слово, лучше бы он просто по нормальному отрефакторил свой код — одно это уже СИЛЬНО снизило бы сложность системы для изучения. При том что объем бинарников никак бы не изменился.
Они на Обероне не писали, надо полагать.
Всегда задавался вопросом, почему Pascal-like коды всегда изобилуют одбуквенными идентификаторами, обилием однострочников. Это же как сложно сопровождать, читать, изучать.
Мне кажется, это пошло из академической среды, в формулах все величины обычно одной буквой обозначают.
Надо отрефакторить математику…
Надо отрефакторить математику…
Как это ни странно, в математике вообще не мешает. Но там есть очень крепко устоявшиеся традиции, какими буквами что может обозначаться; кроме этого, одну букву быстрее написать руками, чем десять.
Оставьте её в покое.
Оставьте её в покое.
В математике, когда заканчиваются буквы, начинают играть со шрифтами. То жирный, то под-над-чёркивания, то вообще готический.
Скажите спасибо, что в обероновской IDE переменные не различаются по шрифтам. А то был бы адок!
Скажите спасибо, что в обероновской IDE переменные не различаются по шрифтам. А то был бы адок!
В IDE как раз отличаются (традиционной подсветки синтаксиса там традиционно нет, но ЗАТО есть возможность ручками задать стиль, цвет и шрифт любой букве или идентификатору, или еще чему-то, в общем также как скажем в MS Word). Но компилятор, по крайней мере пока, это не различает :-)
Это, кстати, еще один пункт холиворов в оберон-сообществе с 2005 года примерно (особенно в сочетании с использованием пропорционального шрифта вместо моноширинного) :-)
Велком ту оберон ворлд! Он местами чудес полон, да и жители весьма своеобразны и разнообразны ;-)
Это, кстати, еще один пункт холиворов в оберон-сообществе с 2005 года примерно (особенно в сочетании с использованием пропорционального шрифта вместо моноширинного) :-)
Велком ту оберон ворлд! Он местами чудес полон, да и жители весьма своеобразны и разнообразны ;-)
Я в курсе про боевую раскраску, потому и упомянул :)
Мега-срач про «синтаксический оверхед» на RSDN уже был, вроде всё утихло, но тут снова заверте.
Мега-срач про «синтаксический оверхед» на RSDN уже был, вроде всё утихло, но тут снова заверте.
Кстати, я знаю, как задёшево реализовать различение стиля компилятором.
Нужно просто кодировать стиль в манглированном имени. Например,
это, на самом деле,
где $tag$ и $_tag$ — вкл-выкл того или иного стиля.
Нужно просто кодировать стиль в манглированном имени. Например,
VAR
x: REAL;
x: COMPLEX;
x, x1: Vector;
это, на самом деле,
VAR
x: REAL;
$i$x$_i$: COMPLEX;
$b$x$_b$$sub$1$_sub$: Vector;
где $tag$ и $_tag$ — вкл-выкл того или иного стиля.
хорошо, я поменяю формулировку
в математике есть сильная традиция, какие глифы что обозначают
некоторые конечно можно перепутать, но опять же традиция, что те глифы, которые похожи, в одних формулах никогда не встречаются
в математике есть сильная традиция, какие глифы что обозначают
некоторые конечно можно перепутать, но опять же традиция, что те глифы, которые похожи, в одних формулах никогда не встречаются
Простите за оффтоп, но вступление повеселило!
Я сам хотел поблагодарить автора за положительное настроение. На самом деле, эта часть взята из выступления А. Райкина — Борьба с проклятой. Если что, в интернете есть несколько версий, но мне именно нравится эта (запись живого выступления).
Простите, что поддержал ваш оффтоп. Думал кому-нибудь пригодится.
Простите, что поддержал ваш оффтоп. Думал кому-нибудь пригодится.
Большое спасибо за статью! Наконец-то стало примерно понятно, как это всё работает. В других статьях про Oberon понять суть сложнее, а здесь отлично разжёвано.
Концепция интересная, лично мне напомнила Plan9 и Inferno (даже гифка напомнила местный текстовый редактор Acme) — чрезвычайно просто построенные системы, в то же время модульные и легко расширяемые. На мой взгляд, исходный код в них выглядит попроще. Не отрицаю, что у меня в голове могут мешаться понятия «простота» и «привычность».
Концепция интересная, лично мне напомнила Plan9 и Inferno (даже гифка напомнила местный текстовый редактор Acme) — чрезвычайно просто построенные системы, в то же время модульные и легко расширяемые. На мой взгляд, исходный код в них выглядит попроще. Не отрицаю, что у меня в голове могут мешаться понятия «простота» и «привычность».
Мне тут коллеги одну полезную нагрузочку дали. Я быстренько с вами проведу беседу о вреде избирательной слепоты, поскольку с нею, проклятою, в нашей индустрии не совсем благополучно. Значит, перво-наперво, прежде чем с нею бороться, с нашим общим врагом – слепотой проклятой, давайте мы как следует обсудим и изучим примеры того, что не видит сообщество, чтобы наверняка знать, как оно может быть на самом деле.
Потому что трудно проводить беседу о борьбе с избирательной слепотой. Может быть так, – беседу закончим. Прямо приступим к борьбы с ею. Ведь у нас…(заплетающимся языком), одно должны помнить – все мы, как один, должны мы все бороться. Должны с ею, как один. Должны мы все … бороться, один должны как. Мы все…Без этого говнеца статья бы смотрелась куда более прилично. А так впечатление становится негативным, к сожалению.
Правильно ли я понимаю, что нет разделения на kernelspace и userspace? Доступен ли модуль SYSTEM для прикладных программ?
Также остаётся вопрос, почему работа с SYSTEM.GET/SYSTEM.SET является безопасной, а работа с указателями в Си — нет. Чем SYSTEM.SET отличается от
*p = q?Правильно ли я понимаю, что нет разделения на kernelspace и userspace?
Да
Доступен ли модуль SYSTEM для прикладных программ?
Да
SYSTEM хоть и встроенный, но все же модуль, а значит можно регламентировать его использование. Хотя самому Вирту это ни к чему.
Конечно, в метод, написанный Виртом, никто и никогда не передаст невалидное смещение. Они не посмеют!
А насчёт регламентировать — точно так же можно регламентировать в использование raw pointers в виде рекомендаций (что, если не ошибаюсь, делается в MISRA C) или требований языка (как в вашем любимом яисте, яве или C#).
А насчёт регламентировать — точно так же можно регламентировать в использование raw pointers в виде рекомендаций (что, если не ошибаюсь, делается в MISRA C) или требований языка (как в вашем любимом яисте, яве или C#).
Что-то мне приведенные цитаты напомнили Выбегалло. Сильно так напомнили…
Я, может быть, крайне неправ, но таки напишу. Вдумчивое чтение прекратил на фразе «Главный негативный фактор это забытие, которому бизнес предал источник своих успешных концепций.» Задумался, так может, это в источнике концепций что-то не так, и это что-то не позволило бизнесу (в широком понимании) взять не только концепции, но и систему в целом?
В конце концов, код, написанный для Ubuntu может быть перенесён и в Debian, а написанный для Android код ядра Linux в итоге помогает другим мобильным ОС на базе Linux. Это только из известных всем примеров.
Чего я не замечаю? В чём моя избирательная слепота?
В конце концов, код, написанный для Ubuntu может быть перенесён и в Debian, а написанный для Android код ядра Linux в итоге помогает другим мобильным ОС на базе Linux. Это только из известных всем примеров.
Чего я не замечаю? В чём моя избирательная слепота?
Увы, не всегда код из ubuntu без голдовства можно перенсти в mandriva или opensuse. А в Debian переносится хорошо, потому как основан на нем.
Подавляющее большинство бизнесспроектов основано на части готовых решений, требующих максимальной поддержки при минимальных затратах. Попросту говоря, для того, что бы какая то конкретная реализация пошла в использование надо вложить немалые деньги.
Описанная модульная структура очень сильно напоминает структуры, формируемые Java. В разработку и продвижение Java сначало не хило вложилась Sun microsystems, пока пупок не надорвала. Теперь не хило такой гигант как Oracle вкладывается. Может ли Вирт похвастаться такими спонсорами? Сомневаюсь. Хотя очень вероятно, что предложения все таки были, но видимо на кабальных условиях.
Подавляющее большинство бизнесспроектов основано на части готовых решений, требующих максимальной поддержки при минимальных затратах. Попросту говоря, для того, что бы какая то конкретная реализация пошла в использование надо вложить немалые деньги.
Описанная модульная структура очень сильно напоминает структуры, формируемые Java. В разработку и продвижение Java сначало не хило вложилась Sun microsystems, пока пупок не надорвала. Теперь не хило такой гигант как Oracle вкладывается. Может ли Вирт похвастаться такими спонсорами? Сомневаюсь. Хотя очень вероятно, что предложения все таки были, но видимо на кабальных условиях.
Вы просто ищете под фонарем. Историю не знаете, как оно там было в 90-х, не помните. Побеседуйте с Никитой Липским из Эксельсиор Джет, с Русланом Богатыревым, с Недорей, которого тут отправили в глубокий минус они вам раскажут, как оно было и какой ценой досталось текущему поколению, и где там место оберона было.
И опять понеслось… «Да вы не знаете, мы же своей кровью, а вы тут! Тьфу на вас!»
Если вы спросите меня, я могу сказать, что Оберон-система концептуально очень крутая вещь, я бы даже сказал гениальная вещь! И между прочим, бизнес еще не все концепции (за 30 лет!) смог переварить. Свой трибут Оберон-системе я изложил в выступлении здесь — devday.ru/report/22.
Но все комментарии здесь, тем не менее, по делу. Главная беда Оберон-системы, что она была сделана крайне непрофессионально, как изнутри, так и снаружи. Да, Вирт писал говнокод, его студенты, которые работали над этим проектом писали говнокод, и вся система была с гусями. Именно, поэтому мой науч.рук., упомянутый выше, Недоря решил в свое время написать коммерческий (читай профессиональный) вариант Оберон-системы — Мифрил (над которой я тоже успел поработать, в том числе успел внедрить на одно предприятие).
Но при этом молодеже здесь надо учесть, что большинству кода в Оберон-системе — 20+ лет. Тогда просто не было всех этих современных «практик», «методологий», и т.п. «Все было впервые и вновь» (хотя парное программирование было). Вы посмотрите на POSIX или Win API из тех же времен — это же тоже ад и п… ц! Особенно Win API — поубивал бы всех, кто это придумал в Microsoft во главе с Гейтсом.
Да что там в Microsoft, знаете как мне сейчас стыдно за исторически первый код в упомянутом выше проекте Excelsior JET, написанный мной 19 лет назад (на том же языке Оберон)! Это же говнокодище чистой воды! Мне приходиться закрывать лицо руками, когда я его показываю студентам. Но при этом он живет и работает. Вот недавно туда добавлял поддержку Java 8 (плакал, но добавлял — применил правда пару «практик» и код стал чуть лучше). Но в свое оправдание могу сказать, что за последние лет 10 в этом моем коде, не было найдено серьезных ошибок. При этом при поддержке Java 8, мы нашли 2 доисторических бага (до существования Java) в коде, написанными людьми очень успешными сейчас в редмонде и силиконовой долине (один работает в упомянутом выше Microsoft).
Но все комментарии здесь, тем не менее, по делу. Главная беда Оберон-системы, что она была сделана крайне непрофессионально, как изнутри, так и снаружи. Да, Вирт писал говнокод, его студенты, которые работали над этим проектом писали говнокод, и вся система была с гусями. Именно, поэтому мой науч.рук., упомянутый выше, Недоря решил в свое время написать коммерческий (читай профессиональный) вариант Оберон-системы — Мифрил (над которой я тоже успел поработать, в том числе успел внедрить на одно предприятие).
Но при этом молодеже здесь надо учесть, что большинству кода в Оберон-системе — 20+ лет. Тогда просто не было всех этих современных «практик», «методологий», и т.п. «Все было впервые и вновь» (хотя парное программирование было). Вы посмотрите на POSIX или Win API из тех же времен — это же тоже ад и п… ц! Особенно Win API — поубивал бы всех, кто это придумал в Microsoft во главе с Гейтсом.
Да что там в Microsoft, знаете как мне сейчас стыдно за исторически первый код в упомянутом выше проекте Excelsior JET, написанный мной 19 лет назад (на том же языке Оберон)! Это же говнокодище чистой воды! Мне приходиться закрывать лицо руками, когда я его показываю студентам. Но при этом он живет и работает. Вот недавно туда добавлял поддержку Java 8 (плакал, но добавлял — применил правда пару «практик» и код стал чуть лучше). Но в свое оправдание могу сказать, что за последние лет 10 в этом моем коде, не было найдено серьезных ошибок. При этом при поддержке Java 8, мы нашли 2 доисторических бага (до существования Java) в коде, написанными людьми очень успешными сейчас в редмонде и силиконовой долине (один работает в упомянутом выше Microsoft).
Говнокод есть везде, явная претензия здесь в взаимоисключающих параграфах. Ярые оберонщики здесь утверждают что на обероне любой код — конфетка и можно писать без отладки и все работает само, но когда смотришь на код — все эти ванильные возгласы рушатся в прах.
А так говнокод есть везде, иногда потому что сильно старый код, а иногда просто потому что так было выгоднее, проще наговнокодить и сделать быстрее, и тогда к моменту как конкуренты выпустят хороший код — у вас уже будет третий релиз, учитывающий все хотелки пользователей и оптимизированный под реалии жизни, чем собственно бизнес и выиграет.
А так говнокод есть везде, иногда потому что сильно старый код, а иногда просто потому что так было выгоднее, проще наговнокодить и сделать быстрее, и тогда к моменту как конкуренты выпустят хороший код — у вас уже будет третий релиз, учитывающий все хотелки пользователей и оптимизированный под реалии жизни, чем собственно бизнес и выиграет.
Вы сильно искажаете факты. Никто и никогда не утверждал, что на обероне ЛЮБОЙ код конфетка. Интерпретация графика Свердлова (см. «Арифметика синтаксиса») говорит о том, что оберон-way направлен в сторону минимизации ошибок — на входе в абсолютный вычислитель. Я про это говорю постоянно и когерентно. Стремление к минимизации ошибок совсем не то же, что абсолютное отсутствие ошибок. Но вы как-то странно искажаете суть, не могу понять почему. Может, я как-то не так выражаю свои мысли.
Минимизация не говорит о том, что на обероне ошибок не бывает.
Мой опыт не говорит о том, что на обероне ошибок не бывает, мой опыт говорит о том, что жёсткость оберон-подхода заставляет писать аккуратно сразу.
А если вы пишете аккуратно сразу, то вам отладчик уже по большей части не нужен, это тоже особенность оберон-подхода. Специально для вас повторяю — я не говорю о том, что я не делаю ошибок на обероне. Я говорю о том, что у меня в силу особенностей применяемого инструмента период отладки алгоритма сильно укорачивается. И я не говорю о том, что отладчик совсем не нужен — он не нужен по большей части, а его наличие только расслабляет (сюрприз! я знаю, что такое пошаговые отладчики и я пользовался ими много лет).
Речь идёт о том, что вот есть такой оберон-way. Он так устроен, такие особенности. Есть такая история. Интересно заглянуть туда и понять, почему оберонщики первыми оказывались там, куда майнстрим доползал спустя многие годы. А сообщество почему-то это воспринимает как надругательство над устоями майнстрима или дурацкий троллинг. Жуть какая.
Минимизация не говорит о том, что на обероне ошибок не бывает.
Мой опыт не говорит о том, что на обероне ошибок не бывает, мой опыт говорит о том, что жёсткость оберон-подхода заставляет писать аккуратно сразу.
А если вы пишете аккуратно сразу, то вам отладчик уже по большей части не нужен, это тоже особенность оберон-подхода. Специально для вас повторяю — я не говорю о том, что я не делаю ошибок на обероне. Я говорю о том, что у меня в силу особенностей применяемого инструмента период отладки алгоритма сильно укорачивается. И я не говорю о том, что отладчик совсем не нужен — он не нужен по большей части, а его наличие только расслабляет (сюрприз! я знаю, что такое пошаговые отладчики и я пользовался ими много лет).
Речь идёт о том, что вот есть такой оберон-way. Он так устроен, такие особенности. Есть такая история. Интересно заглянуть туда и понять, почему оберонщики первыми оказывались там, куда майнстрим доползал спустя многие годы. А сообщество почему-то это воспринимает как надругательство над устоями майнстрима или дурацкий троллинг. Жуть какая.
А я вам говорю, что stateless-код и функциональщина позволяет писать код с еще меньшим количеством ошибок.
В обероне нет first-class functions, а это сразу говорит о том, что писать на обероне правильные stateless код значительно сложнее, чем, например, в более древнем чем оберон лиспе.
При том, что мне так никто и не может объяснить в чем состоит «жесткость» оберон-подхода и чем семантика его синтаксиса отличается от семантики еще кучи языков и как она помогает избегать ошибок.
Вы можете выдать что-нибудь кроме «В обероне простой синтаксис и поэтому программисты на нем допускают меньше ошибок»? Что за oberon-way? В чем его суть?
В обероне нет first-class functions, а это сразу говорит о том, что писать на обероне правильные stateless код значительно сложнее, чем, например, в более древнем чем оберон лиспе.
При том, что мне так никто и не может объяснить в чем состоит «жесткость» оберон-подхода и чем семантика его синтаксиса отличается от семантики еще кучи языков и как она помогает избегать ошибок.
Вы можете выдать что-нибудь кроме «В обероне простой синтаксис и поэтому программисты на нем допускают меньше ошибок»? Что за oberon-way? В чем его суть?
Ну вот, теперь и вы заклеймили себя как фанат функциональщины и для евангелистов обертона любые ваши суждения потеряли объективность.
Почему вы об этом не спросили до того, как слить человеку карму? Кажется, в фильме Жмурки был эпизод, когда герой сначала выстрелил человеку в голову, а потом сказал, что хотел в руку. Вот и современный ИТ так же, сначала делает, а потом вопросы задает.
А почему вы сразу не начали с объяснения в чем суть oberon-way? Почему аудитория должна вытягивать из вас информацию?
То есть, сам виноват?
Обвинение жертвы применимо в том случае, когда есть преступление или насилие. А здесь нет ни того, ни другого, есть использование изначально заложенных в сообщество механизмов.
Насилие это всегда в каком-то смысле возможность контролировать чужую деятельность или бездеятельность. Когда пацаны приходят в тред с криком «Опять оберонщик запостил очередную хрень» и минусуют, это и есть контроль. Вас много, вы сила. Ну и далее по тексту. Можно за людей не считать. Такое тоже бывает.
К слову, возможности минусовать у меня нет. Да и когда была, я этим механизмом не пользовался.
Я просто написал несколько комментариев, которые запустили процесс регуляции.
Я просто написал несколько комментариев, которые запустили процесс регуляции.
Так спрашивали, и неоднократно.
До или после? Это не сегодня началось, зачем врать-то?
До, до. Я же и просил рассказать (не дословно про Oberon way).
И что, вас не устроил ответ и вы нажали минус? Или что, обидели вас?
Ответ меня не устроил, но минус я не нажимал. У меня и нажималки-то такой до вчерашнего вечера не было.
Ну нажали бы, какая разница.
Очевидно, мне есть разница, раз я не нажимаю. А если вам нет разницы, так что ж вы об этом так возмущаетесь-то?
Если вкратце, голосование показывает, что Вы выбрали верную сторону. Поэтому нажали лично вы или не вы, плотность огня такая, что говорить с вами становится невозможно, да еще и тренд в беседе развился в задавание вопросов не по теме и возмущение нежеланием отвечать.
Ну то есть не важно, кто и что пишет, и кто и как минусует или плюсует, но всем скажем, что все минусуют, и поэтому ни с кем ни о чем говорить не будем (точнее, будем говорить только на удобные темы).
Крутой подход, чо.
Крутой подход, чо.
Зайдите на страницу /comments и посмотрите. Потом вверху на цифру с кармой. Но это так, техническая часть.
И потом, показательно, что я говорю о вещах, идущих наперекор вашим критериям оценки, и этот аккаунт получает ущерб. Сразу начинается разбор полетов, мета-спор о терминах, обсуждение моей личности и прочее хамство. Ну а вы под всем этим соусом убеждаетесь, что в ответах собеседника ересь и дальше свою линию гнете. Ну и вот результат, у вас своя линия, у меня своя. Ни о чем не договорились, над Обероном пошутили, над кодом поныли, болтами померялись. Надеюсь, кто-нибудь хоть Оберон начал изучать, чтобы меня личными примерами уязвить, а то все болтология одна про «код вытеки глаза» и прочее выискивание недостатков.
И потом, показательно, что я говорю о вещах, идущих наперекор вашим критериям оценки, и этот аккаунт получает ущерб. Сразу начинается разбор полетов, мета-спор о терминах, обсуждение моей личности и прочее хамство. Ну а вы под всем этим соусом убеждаетесь, что в ответах собеседника ересь и дальше свою линию гнете. Ну и вот результат, у вас своя линия, у меня своя. Ни о чем не договорились, над Обероном пошутили, над кодом поныли, болтами померялись. Надеюсь, кто-нибудь хоть Оберон начал изучать, чтобы меня личными примерами уязвить, а то все болтология одна про «код вытеки глаза» и прочее выискивание недостатков.
Система голосов на хабре не учитывает, кто за что. Поэтому я не могу судить — именно вы мне минусов накидали или кто-то другой.
Обезличенный Хабр (см. οχλος) накидал, и всё тут. Обезличенный Хабр не хочет меня слышать. Вы лично хотите, а обезличенный Хабр не хочет. Я тоже хотел бы вам ответить — в срок, но οχλος не хочет, чтобы я отвечал в срок. Тут код хотят? Замечательно, кто-то хочет, а οχλος не хочет получить от меня код.
Ну и раз такое дело, то, как говорится, давай до свидания. У меня карма -15, я уже почти что окончательный изгой, поэтому считаю вполне этичным снять с себя весь конструктив до исчерпания запаса кислорода :)
Хотите, приходите в oberon@conference.jabber.ru, или на oberoncore.ru — там можно общаться. Здесь — не дают, что поделать. Сам виноват. Охлократия, она такая.
Обезличенный Хабр (см. οχλος) накидал, и всё тут. Обезличенный Хабр не хочет меня слышать. Вы лично хотите, а обезличенный Хабр не хочет. Я тоже хотел бы вам ответить — в срок, но οχλος не хочет, чтобы я отвечал в срок. Тут код хотят? Замечательно, кто-то хочет, а οχλος не хочет получить от меня код.
Ну и раз такое дело, то, как говорится, давай до свидания. У меня карма -15, я уже почти что окончательный изгой, поэтому считаю вполне этичным снять с себя весь конструктив до исчерпания запаса кислорода :)
Хотите, приходите в oberon@conference.jabber.ru, или на oberoncore.ru — там можно общаться. Здесь — не дают, что поделать. Сам виноват. Охлократия, она такая.
Вы ответите наконец такому простому быдлу как мне на мои вопросы? Или вы только выеживаться умеете?
Вместо этого комментария вы могли написать ответ или выложить код. И заработать кучу плюсов в карму для продолжения дискуссии.
Кстати, читаем в википедии: «Охлократия — вырожденная форма демократии, основанная на меняющихся прихотях толпы, постоянно попадающей под влияние демагогов.»
Я тут кроме как от оберонщиков никакой демагогии не видел. И вижу, что «толпа» ни за какими демагогами не идет. Наоборот, вас нещадно минусуют.
Поэтому, дорогой мой, прекращайте вые@ываться.
Вместо этого комментария вы могли написать ответ или выложить код. И заработать кучу плюсов в карму для продолжения дискуссии.
Кстати, читаем в википедии: «Охлократия — вырожденная форма демократии, основанная на меняющихся прихотях толпы, постоянно попадающей под влияние демагогов.»
Я тут кроме как от оберонщиков никакой демагогии не видел. И вижу, что «толпа» ни за какими демагогами не идет. Наоборот, вас нещадно минусуют.
Поэтому, дорогой мой, прекращайте вые@ываться.
сам-виноват.txt
Ну, я может совсем дурак, но я кое-чего не понимаю.
У вас там на счетчике на данный момент — 181 комментарий.
Вы потратили дикое количество времени на детский выпендреж.
Соответственно, я делаю простой вывод — ответов на наши вопросы у вас нет, а сюда вы пришли ради дурацкого самоутверждения. Профессионалы так себя не ведут.
У вас там на счетчике на данный момент — 181 комментарий.
Вы потратили дикое количество времени на детский выпендреж.
Соответственно, я делаю простой вывод — ответов на наши вопросы у вас нет, а сюда вы пришли ради дурацкого самоутверждения. Профессионалы так себя не ведут.
На вопросы в стиле «вы можете выдать что-нибудь кроме» возможно отвечать только когда задающий подобные резкости научится сдерживать обороты :) Выдают в кассе, а я вам не касса.
Здесь тон задаёт толпа, а не вы и не я.
Здесь тон задаёт толпа, а не вы и не я.
Понимаете ли, в чем дело… кода от вас не было и тогда, когда с кармой все было хорошо.
Более того, мне вот интересно. Я писал oberon87, а отвечаете вы, причем ровно в тех выражениях, как если бы писали вам. Нельзя не задуматься.
Более того, мне вот интересно. Я писал oberon87, а отвечаете вы, причем ровно в тех выражениях, как если бы писали вам. Нельзя не задуматься.
Скорее пожалуйтесь администрации и забаньте двойников навсегда. Тогда исчезнут все поводы для задумывания.
Только я — это я.
А минусовать меня начали ещё до сливания кармы, доминанты охлоса проявились в полной мере почти сразу. Отсюда легко сделать вывод, что именно код не нужен, а нужен лишь повод.
Это подтвердилось на примере с процедуркой Backup. Назвали её говнокодом и нашли несуществующую ошибку — получив плюсы. Мои возражения получили минуса. Потому что есть тренд обструкции.
Тут говорить не о чем. Толпа определяет, что здесь хорошо, а что нет.
Насчёт же ваших вопросов, скажу вот что. Когда вам показывают обход массива на обероне, называя это обходом коллекции, и вам это не фонит, то тут надо понять, что коллекция по определению не массив.
Зачем мне вам показывать код обхода коллекции, когда у нас с вами так сильно различаются представления о коллекции en.wikipedia.org/wiki/Container_(abstract_data_type)?
Зачем мне приводить какой-то код, когда люди видят какие-то ошибки там, где их нет?
Я говорю об этом не для того, чтобы обидеть, а чтобы показать условия возникновения confirmation bias. Вы в моём коде увидите что-то своё, исходя из каких-то своих внутренних представлений о вещах, начнёте мне возражать, а поскольку возражения в тренде, получите плюсы просто по линии обструкции, а я по той же линии получу минусов, просто за здорово живёшь.
Только я — это я.
А минусовать меня начали ещё до сливания кармы, доминанты охлоса проявились в полной мере почти сразу. Отсюда легко сделать вывод, что именно код не нужен, а нужен лишь повод.
Это подтвердилось на примере с процедуркой Backup. Назвали её говнокодом и нашли несуществующую ошибку — получив плюсы. Мои возражения получили минуса. Потому что есть тренд обструкции.
Тут говорить не о чем. Толпа определяет, что здесь хорошо, а что нет.
Насчёт же ваших вопросов, скажу вот что. Когда вам показывают обход массива на обероне, называя это обходом коллекции, и вам это не фонит, то тут надо понять, что коллекция по определению не массив.
Зачем мне вам показывать код обхода коллекции, когда у нас с вами так сильно различаются представления о коллекции en.wikipedia.org/wiki/Container_(abstract_data_type)?
Зачем мне приводить какой-то код, когда люди видят какие-то ошибки там, где их нет?
Я говорю об этом не для того, чтобы обидеть, а чтобы показать условия возникновения confirmation bias. Вы в моём коде увидите что-то своё, исходя из каких-то своих внутренних представлений о вещах, начнёте мне возражать, а поскольку возражения в тренде, получите плюсы просто по линии обструкции, а я по той же линии получу минусов, просто за здорово живёшь.
A fixed-size table (or array) is usually not considered a collection because it holds a fixed number of items, although tables/arrays commonly play a role in the implementation of collections. Variable-sized arrays are generally considered collections, and fixed-size arrays may likewise considered a collection, albeit with limitations
По факту даже в джаве они отделены друг от друга, хотя казалось бы, джава просто родила все что можно было обсуждать про «коллекции» в том смысле, в котором их понимает большинство не сильно рефлексирующих людей.
PS, отвечал выше, извините. Кстати, отвечу тут, теперь некорректно считать виртуала виртуалом, ведь других учетных записей подконтрольных одному лицу не осталось. Думаю, админы так специально сделали, чтобы подержать посещаемость интересных Оберон-срачей подольше. Ведь охлос должен отдавать энергию подольше и побольше.
PS, отвечал выше, извините. Кстати, отвечу тут, теперь некорректно считать виртуала виртуалом, ведь других учетных записей подконтрольных одному лицу не осталось. Думаю, админы так специально сделали, чтобы подержать посещаемость интересных Оберон-срачей подольше. Ведь охлос должен отдавать энергию подольше и побольше.
Ок давайте использовать термин «обход контейнера»
«охлос», похоже, сразу понял, что вы программировать не умеете, и даже оберон свой толком не знаете (и чем он отличается от компонент-паскаля), не говоря уже о оберон-системе
худо-бедно ответить на вопрос про процедуру Backup смог только akastargazer спустя пол-дня, а до этого мы видели кучу бреда вида «вы что, не видите, что тут написано Х!» в ответ на «почему тут написано Х, это не ошибка?».
«охлос» всё это время поддерживал с вами дискуссию, надеясь, что хоть что-то за душой у вас всё-таки есть. И сейчас ещё надеется, хотя после трёх дней дискуссий уже почти отчаялся
В принципе, вы даже изредка показываете хоть что-то мало-мальски вменяемое, там, форматированный код, который хотя бы не выглядит как говно (хотя вопросы и к нему есть, ну и иллюстрации возможностей языка тут нет — паскаль как паскаль).
Отчего же из вас просто клещами приходится тянуть то, что должно быть в статье и чем вы были как раз должны размахивать, вместо бахвальства «да оберон используют на атомных станциях»? Да если там такой код, как в примерах в статье, я категорически против атомной энергетики!
худо-бедно ответить на вопрос про процедуру Backup смог только akastargazer спустя пол-дня, а до этого мы видели кучу бреда вида «вы что, не видите, что тут написано Х!» в ответ на «почему тут написано Х, это не ошибка?».
«охлос» всё это время поддерживал с вами дискуссию, надеясь, что хоть что-то за душой у вас всё-таки есть. И сейчас ещё надеется, хотя после трёх дней дискуссий уже почти отчаялся
В принципе, вы даже изредка показываете хоть что-то мало-мальски вменяемое, там, форматированный код, который хотя бы не выглядит как говно (хотя вопросы и к нему есть, ну и иллюстрации возможностей языка тут нет — паскаль как паскаль).
Отчего же из вас просто клещами приходится тянуть то, что должно быть в статье и чем вы были как раз должны размахивать, вместо бахвальства «да оберон используют на атомных станциях»? Да если там такой код, как в примерах в статье, я категорически против атомной энергетики!
Вы увидели только то, что хотели.
Охлос-то да, сразу всё понял, и сделал выводы. Лично я дискуссии не увидел. Дискуссия — это когда стороны ведут равнозначное общение. Вы — мне, я вам. А когда одна сторона затыкает другой рот, это — не дискуссия. «Ты — молчи, а говорить будем мы» (см. правила хабра), разве это дискуссия?
Кто вам рот затыкал? Вас просили: покажите код! Вы его показали. Спустя три дня. Десяток примеров. Два топика, тысяча комментариев, десять примеров говнокода, кроме одного примера.
Просили объяснить: вот мы видим говнокод, а вы утверждали, что язык побуждает писать аккуратно. Как это вообще согласуется? И тут вы утверждаете, что мы ничего не понимаем.
Конечно, «охлос» сделал выводы, что перед нами — два школьника-фанатика (один из которых под тремя аккаунтами), которые вчера учили паскаль, а потом увидели оберон, который как паскаль, и решили, что раз его в школе не учат, то вот он, Тот Самый Главный Язык. И эти школьники, которые циклы друг от друга отличить не могут и не знают, что такое «цикл с выходом из середины», пытаются учить «охлос» как ему надо жить.
Я тоже дискуссии не увидел, потому, что вы ни сами на вопросы не отвечаете, ни задать их не можете.
Просили объяснить: вот мы видим говнокод, а вы утверждали, что язык побуждает писать аккуратно. Как это вообще согласуется? И тут вы утверждаете, что мы ничего не понимаем.
Конечно, «охлос» сделал выводы, что перед нами — два школьника-фанатика (один из которых под тремя аккаунтами), которые вчера учили паскаль, а потом увидели оберон, который как паскаль, и решили, что раз его в школе не учат, то вот он, Тот Самый Главный Язык. И эти школьники, которые циклы друг от друга отличить не могут и не знают, что такое «цикл с выходом из середины», пытаются учить «охлос» как ему надо жить.
Я тоже дискуссии не увидел, потому, что вы ни сами на вопросы не отвечаете, ни задать их не можете.
Когда вам показывают обход массива на обероне, называя это обходом коллекции, и вам это не фонит, то тут надо понять, что коллекция по определению не массив.
По какому определению?
Зачем мне приводить какой-то код, когда люди видят какие-то ошибки там, где их нет?
Вам не приходит в голову, что ситуация может быть ровно обратной — вы не видите ошибок там, где они есть?
Вы спорите не с неорганизованной «толпой». Вы пытаетесь спорить с рынком. А у рынка, в отличии от толпы, есть свойство — он берет и использует все что может принести деньги. Вы говорите что этот код — не говнокод а оберон может снизить число ошибок и принести прочие плюшки. Иными словами — вы говорите что на этом можно заработать из разряда «вот оно — бери и зарабатывай». Если бы это было так — рынок бы уже это взял, просто потому что есть конкуренция, не возьмет компания А, возьмет компания Б, выиграет на этом и обскочет А. Но реалии жизни в чем? В том что вы не признаете что говнокод — это говнокод, ошибки называете фичами, а факт того что оберон никому не нужен называете заговором рынка. И да, до сих пор во всех постах ни один из 4х аккаунтов (не знаю уж сколько людей там, но явно не 4) не ответил на простой вопрос — конкретно по фактам — каким образом получается более надежный код? С примером желательно. Но нет же, проще спорить и уходить от темы чем ответить на вопрос.
А вот тут не соглашусь.
Рынок — эволюционная система, развивающаяся небольшими итерациями, крупные сдвиги парадигм случаются нечасто и не вдруг, а большинство принципиально новых™ достижений отличаются от предыдущих нескучными обоями. С одной стороны, это даёт стабильность, уменьшает риски, позволяет развиваться экстенсивно, переводить количество в качество и задавливать массой, если надо. С другой — обладает классическими проблемами таких систем, вроде ловушки локальных экстремумов, когда невозможно сделать радикальное изменение, которое в дальней перспективе принесёт ощутимый профит, потому что в ближней придётся перестрадать. Вне рынка есть множество замечательных и интересных языков и технологий, множество из которых действительно приносят плюшки вроде повышения выразительности и надёжности (и если нужно, я действительно могу это обосновать, и даже с кодом); и если бы в них влить хотя бы малую долю того, что пошло на развитие и распространение, скажем, джавы, вышла бы конфетка. Но такую тушу разом не сдвинешь, и те из них, кто действительно добился успеха, обычно хотя бы поначалу и частично мимикрируют под своих предшественников. Если нельзя развиваться скачками, приходится делать это мелкими шажочками, окольными путями, но не боясь далеко укатиться после неудачных вложений. Всё как в природе, и это нормально.
Рынок — эволюционная система, развивающаяся небольшими итерациями, крупные сдвиги парадигм случаются нечасто и не вдруг, а большинство принципиально новых™ достижений отличаются от предыдущих нескучными обоями. С одной стороны, это даёт стабильность, уменьшает риски, позволяет развиваться экстенсивно, переводить количество в качество и задавливать массой, если надо. С другой — обладает классическими проблемами таких систем, вроде ловушки локальных экстремумов, когда невозможно сделать радикальное изменение, которое в дальней перспективе принесёт ощутимый профит, потому что в ближней придётся перестрадать. Вне рынка есть множество замечательных и интересных языков и технологий, множество из которых действительно приносят плюшки вроде повышения выразительности и надёжности (и если нужно, я действительно могу это обосновать, и даже с кодом); и если бы в них влить хотя бы малую долю того, что пошло на развитие и распространение, скажем, джавы, вышла бы конфетка. Но такую тушу разом не сдвинешь, и те из них, кто действительно добился успеха, обычно хотя бы поначалу и частично мимикрируют под своих предшественников. Если нельзя развиваться скачками, приходится делать это мелкими шажочками, окольными путями, но не боясь далеко укатиться после неудачных вложений. Всё как в природе, и это нормально.
Так если бы оберон появился условно «вчера» — я бы не стал упомянать рынок. Я бы просто говорил о том что аргументы какие-то слабенькие и неправдивые (про почти не нужность отладки, низкое число ошибок и то что пишется все с почти первого раза). Но оберон появился не вчера, не позавчера и не 10 лет назад, первая версия появилась еще до моего рождения, а последняя появилась раньше чем многие другие распространенные языки. Крутого сдвига парадигмы я не вижу, это тот же императивный код, нет каких-то супер серьезных отличий. Выкинули 90% синтаксического сахара — так никто и не мешает на том же C# писать без всего этого синтаксического сахара. Я согласен с тем что рынок не меняется в одночасье, но если он не принял что-то за несколько десятилетий в такой динамичной области как IT, то вероятность того что он примет — крайне мала.
Я согласен с тем что рынок не меняется в одночасье, но если он не принял что-то за несколько десятилетий в такой динамичной области как IT, то вероятность того что он примет — крайне мала.
Развитие рынка идёт по спирали, то что маловероятно на этом витке, вполне вероятно на следующем. Самые яркие примеры — NoSQL и тонкие клиенты.
Да нет у вас никакого кода. И понимания, что такое «коллекция» у вас нет. И спрашивал про них я, а не lair.
Иначе, я не вижу реальных причин такого поведения.
Про охлос я тоже умею говорить.
И диагнозы ставить. Вот вам ваш — ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%94%D0%B0%D0%BD%D0%BD%D0%B8%D0%BD%D0%B3%D0%B0_%E2%80%94_%D0%9A%D1%80%D1%8E%D0%B3%D0%B5%D1%80%D0%B0
Иначе, я не вижу реальных причин такого поведения.
Про охлос я тоже умею говорить.
И диагнозы ставить. Вот вам ваш — ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%94%D0%B0%D0%BD%D0%BD%D0%B8%D0%BD%D0%B3%D0%B0_%E2%80%94_%D0%9A%D1%80%D1%8E%D0%B3%D0%B5%D1%80%D0%B0
что жёсткость оберон-подхода заставляет писать аккуратно сразу.Так где пруфы то? Я пока вижу что можно свободно писать говнокод, чем и пользуются. А как он заставляет писать аккуратно — не понятно ни разу.
Кстати вот он habrahabr.ru/post/212887
Я со своей избирательной слепотой никак не могу разглядеть в обероне, например, замыкания. Каковые есть в лиспе, например, хренналиард лет.
И никак не пойму, чем мне сейчас должен помочь прототип ОС, которую разработал Вирт в качестве proof-of-concept?
И никак не пойму, чем мне сейчас должен помочь прототип ОС, которую разработал Вирт в качестве proof-of-concept?
Простой механизм замыканий на стеке?
А зачем мне их реализовывать на стеке?
Благо в обероне сборщик мусора есть, не?
На совсем крайний случай есть разные выриации спагетти-стека, которые вам до кучи еще и continuations дадут.
Благо в обероне сборщик мусора есть, не?
На совсем крайний случай есть разные выриации спагетти-стека, которые вам до кучи еще и continuations дадут.
Посмотрел бы Вашу реализацию.
Вообще, тема расширений Оберона раскрыта в проекте Еберон на гитхабе. Там и хост подходящий — js и браузер, расширяй не хочу.
Вообще, тема расширений Оберона раскрыта в проекте Еберон на гитхабе. Там и хост подходящий — js и браузер, расширяй не хочу.
Смотрите, никто не мешает, с поправкой на на то что это экспериментальный интерпретатор:
github.com/corvusalba/my-little-lispy/blob/master/src/CorvusAlba.MyLittleLispy.Runtime/Closure.cs
Тупо и в лоб, копирование ссылки на фрейм в котором создано замыкание.
Подозреваю, что в современном мире в котором в «настоящем» стеке хранят фрейм-поинтеры, что-то подобное реализуется и на более низком уровне.
github.com/corvusalba/my-little-lispy/blob/master/src/CorvusAlba.MyLittleLispy.Runtime/Closure.cs
Тупо и в лоб, копирование ссылки на фрейм в котором создано замыкание.
Подозреваю, что в современном мире в котором в «настоящем» стеке хранят фрейм-поинтеры, что-то подобное реализуется и на более низком уровне.
А я думал, вы на Обероне напишете.
Извините, не имею чести писать на Обероне и до сегодняшнего дня даже не знал, что он кому-то нужен.
Тем не менее, я посмотрел код по вашей ссылке.
Судя по github.com/vladfolts/oberonjs/blob/master/src/ob/Scope.ob стек там реализован почти так же как и у меня.
Соответственно, ровно ничего не мешает добавить в github.com/vladfolts/oberonjs/blob/master/src/ob/Procedure.ob ссылку на внешний скоуп, аналогично тому, как это происходит в моем интерпретаторе.
Тем не менее, я посмотрел код по вашей ссылке.
Судя по github.com/vladfolts/oberonjs/blob/master/src/ob/Scope.ob стек там реализован почти так же как и у меня.
Соответственно, ровно ничего не мешает добавить в github.com/vladfolts/oberonjs/blob/master/src/ob/Procedure.ob ссылку на внешний скоуп, аналогично тому, как это происходит в моем интерпретаторе.
Принцип адресации переменных аналогичен тому, который у вложенных функциий, которыми замыкания и являются.
В Delphi, начиная с 2009, статический анализатор выделяет одни локальные переменные на стеке, а другие — на куче, при вхождении в область кода, которая их использует. В принципе, если в теле метода есть несколько замыканий, использующих несвязанные переменные, то можно делать несколько таких объектов. Как точно сделано в последней версии, не знаю. Для значений–замыканий действует счетчик ссылок, и сами эти значения ссылаются на объекты в памяти с теми локальными переменными, которые им нужны, тоже считая ссылки. И что–то похожее сделано в Blocks в Objective-C 2.0 (2009 г.), только переменные, которые можно изменять в блоке, нужно помечать ключевым словом, а непомеченные переменные будут доступны только как const, скопированные при создании экземпляра замыкания. В языке Ада, начиная с 2005, замыкания есть, но только нисходящие, поэтому нет счётчика ссылок. Теоретически компилятор мог бы хранить нисходящее замыкание в виде двух указателей код–данные, но в AdaCore похимичили и обошлись одним указателем на динамически сгенеренный код. Не знаю всех подробностей реализации, но сделано корректно, без TLS каких–нибудь. Делал функцию, которая сначала бурит рекурсией стек на несколько кадров, а потом считает число Фибоначчи, вызывая замыкания из засевших на стеке предыдущих экземпляров себя. Работает.
Ничего из этого мне не кажется чем–то особо сложным. Сопоставимо со сложностью разработки компилятора.
Не буду утверждать, что сильно нужна такая возможность. В некоторых стилях написания кода нужна, а в зелёнопоточных (кажется, Active Oberon именно такой) вместо лапши коллбеков может быть обмен сообщениями по каналу. Вот когда нет ни того, ни другого, тогда, конечно, у избалованного современными языками программирования программиста получается фрустрация от невозможности найти что–то привычное на привычном месте.
В Delphi, начиная с 2009, статический анализатор выделяет одни локальные переменные на стеке, а другие — на куче, при вхождении в область кода, которая их использует. В принципе, если в теле метода есть несколько замыканий, использующих несвязанные переменные, то можно делать несколько таких объектов. Как точно сделано в последней версии, не знаю. Для значений–замыканий действует счетчик ссылок, и сами эти значения ссылаются на объекты в памяти с теми локальными переменными, которые им нужны, тоже считая ссылки. И что–то похожее сделано в Blocks в Objective-C 2.0 (2009 г.), только переменные, которые можно изменять в блоке, нужно помечать ключевым словом, а непомеченные переменные будут доступны только как const, скопированные при создании экземпляра замыкания. В языке Ада, начиная с 2005, замыкания есть, но только нисходящие, поэтому нет счётчика ссылок. Теоретически компилятор мог бы хранить нисходящее замыкание в виде двух указателей код–данные, но в AdaCore похимичили и обошлись одним указателем на динамически сгенеренный код. Не знаю всех подробностей реализации, но сделано корректно, без TLS каких–нибудь. Делал функцию, которая сначала бурит рекурсией стек на несколько кадров, а потом считает число Фибоначчи, вызывая замыкания из засевших на стеке предыдущих экземпляров себя. Работает.
Ничего из этого мне не кажется чем–то особо сложным. Сопоставимо со сложностью разработки компилятора.
Не буду утверждать, что сильно нужна такая возможность. В некоторых стилях написания кода нужна, а в зелёнопоточных (кажется, Active Oberon именно такой) вместо лапши коллбеков может быть обмен сообщениями по каналу. Вот когда нет ни того, ни другого, тогда, конечно, у избалованного современными языками программирования программиста получается фрустрация от невозможности найти что–то привычное на привычном месте.
Замыкания, очевидно, были признаны ненужной функциональностью.
Не помешала бы небольшая справка по коду. Лично я мысленно споткнулся на коде:
Что делает оператор #?
Еще, это, конечно, субъективно, но мне кажется, что код КРИЧИТ НА МЕНЯ. Оберон обращает внимание на регистр ключевых слов? Или это просто вкус у автора кода такой странный?
WHILE p # T.trailer DOЧто делает оператор #?
Еще, это, конечно, субъективно, но мне кажется, что код КРИЧИТ НА МЕНЯ. Оберон обращает внимание на регистр ключевых слов? Или это просто вкус у автора кода такой странный?
Что делает оператор #?
Это не равно (ака !=)
Еще, это, конечно, субъективно, но мне кажется, что код КРИЧИТ НА МЕНЯ. Оберон обращает внимание на регистр ключевых слов? Или это просто вкус у автора кода такой странный?
Обращает внимание.
Рекомендую при таких непонятках обращаться к документу про язык Оберон, он короткий, www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.Report.pdf
Должен признать, что после документации на С (которая чудовищна как по объему, так и по формулировкам), этот документ читается довольно приятно.
Раз уж зашла речь — скажите, а есть ли в Обероне такое понятие — «неопределенное поведение»?
Раз уж зашла речь — скажите, а есть ли в Обероне такое понятие — «неопределенное поведение»?
В репорте — нет. По факту — есть (репорт не покрывает всего что нужно покрыть, например что будет при целочисленном делении на 0, что будет при разименовыании NIL, что будет если NEW не сможет выделить память, и так далее — таких мест много и они в репорте не описаны).
Вот это уже хуже. А можно посмотреть полную спецификацию на язык?
Более подробного описания чем Oberon report — нет. Подробнее бывают только описания конкретных реализаций языка в разных системах и компиляторах.
Более того, Project Oberon 2013 использует на самом деле несколько другой диалект языка, не тот который в репорте описан. Поэтому чтобы собрать код из Project Oberon его приходится портировать под компилятор реализаующий то, что описано в Oberon report.
Поэтому язык Оберон сам по себе представляет в принципе меньший интерес, чем проект целиком. (точнее Оберон-язык представляет интерес, но не для прикладного программиста)
Более того, Project Oberon 2013 использует на самом деле несколько другой диалект языка, не тот который в репорте описан. Поэтому чтобы собрать код из Project Oberon его приходится портировать под компилятор реализаующий то, что описано в Oberon report.
Поэтому язык Оберон сам по себе представляет в принципе меньший интерес, чем проект целиком. (точнее Оберон-язык представляет интерес, но не для прикладного программиста)
Неопределённое поведение очень легко создать на высоком уровне.
Например, пишем функцию binary_search, у которой сказано:
«предусловие: исходный массив отсортирован строго по возрастанию; тщательные проверки в рантайме не делаются, ради производительности; нарушение предусловия ведёт к неопределённому поведению».
Мы не специфицируем, что именно должна делать реализация этой функции, если не сможет диагностировать нарушение предусловия.
Равно как не специфицируем тонкости алгоритма (например, в какую сторону округляем индекс медианы).
Возможно, что на небольших массивах вместо бинарного включаем линейный поиск.
Таким образом, даже на одном кривом наборе данных дебажная и релизная сборки, или сборки разных версий библиотеки, могут вести себя по-разному.
Ну и понятно, что GIGO приобретёт характер лавины.
Невыполненное постусловие является невыполненным предусловием следующего за ним кода, а там, глядишь, и до форматирования диска недалеко.
Например, пишем функцию binary_search, у которой сказано:
«предусловие: исходный массив отсортирован строго по возрастанию; тщательные проверки в рантайме не делаются, ради производительности; нарушение предусловия ведёт к неопределённому поведению».
Мы не специфицируем, что именно должна делать реализация этой функции, если не сможет диагностировать нарушение предусловия.
Равно как не специфицируем тонкости алгоритма (например, в какую сторону округляем индекс медианы).
Возможно, что на небольших массивах вместо бинарного включаем линейный поиск.
Таким образом, даже на одном кривом наборе данных дебажная и релизная сборки, или сборки разных версий библиотеки, могут вести себя по-разному.
Ну и понятно, что GIGO приобретёт характер лавины.
Невыполненное постусловие является невыполненным предусловием следующего за ним кода, а там, глядишь, и до форматирования диска недалеко.
Лучше чем предыдущие статьи про Оберон, которые были здесь. Спасибо.
А что, не надо доказывать? Это не принято? Иногда кажется что да, и правда у вас не принято доказывать, только интеллигентно оскорблять. И потом непонятно, я Вам мешаю писать на Обероне или что?
Куриосити конечно пример, однако ж беспилотники тоже летают.
Куриосити конечно пример, однако ж беспилотники тоже летают.
Тогда вам стоит написать компилятор, который не позволит давать переменным и другим сущностям имена меньше скольки-то там символов. Вот раздолье для стайлгайдов.
Для джавистов это единственный выход.
Для джавистов это единственный выход.
В индустрии ИТ, как и на хабре, есть много смешных и несуразных расхождений между красивыми декларируемыми принципами и суровой жесткой реальностью. В обероне такое расхождение устранено, насколько это возможно. Он угрюмый и прямолинейный, что в описании, что в реализации.
А на хабре подобное расхождение проявляется примерно так: переход на личности это нехорошо, и по идее, умные люди должны следовать хорошему тону и не делать так, а они делают, и получают одобрение. Расхождение интерфейса и реализации. Нужно знать детали реализации этого сообщества, поэтому красивые абстрактные положения, которые вы описываете свою прекрасную и правильную индустрию ИТ и языки со курлибрекетами, вырождаются, протекают, и ничего кроме смеха не вызвают.
А на хабре подобное расхождение проявляется примерно так: переход на личности это нехорошо, и по идее, умные люди должны следовать хорошему тону и не делать так, а они делают, и получают одобрение. Расхождение интерфейса и реализации. Нужно знать детали реализации этого сообщества, поэтому красивые абстрактные положения, которые вы описываете свою прекрасную и правильную индустрию ИТ и языки со курлибрекетами, вырождаются, протекают, и ничего кроме смеха не вызвают.
Хорошая идея!
Если в одной области видимости больше пяти однобуквенных идентификаторов или десяти двухбуквенных — в сад, все в сад!
Надо посмотреть, как пишутся расширения pc-lint'ов всяких.
А если кто начнёт хакать и писать identifierA, identifierB, identifierC, ..., identifierZ — то будем сравнивать в префиксном и суффиксном деревьях!
Если в одной области видимости больше пяти однобуквенных идентификаторов или десяти двухбуквенных — в сад, все в сад!
Надо посмотреть, как пишутся расширения pc-lint'ов всяких.
А если кто начнёт хакать и писать identifierA, identifierB, identifierC, ..., identifierZ — то будем сравнивать в префиксном и суффиксном деревьях!
Никто не доказывает, что «на обероне не может быть ошибок», успокойтесь. Это побочный эффект охлократии, когда все галдят и стучат по веткам, то суть разобрать сложно.
Всегда с интересом читаю статьи про языки программирования.
Общеупотребительные языки описываются довольно равномерно: есть статьи, которые ругают за недостатки, и есть которые хвалят за достоинства. А уж комментарии к ним позволяют понять, что и достоинства и недостатки не такие уж и ярко выделяющиеся на фоне остальных языков.
Новые языки, обычно воспеваются в статьях, а в комментариях, как правило, идёт поиск целевой области применения.
Вымирающие языки описываются авторами которые любят эти языки. И часто эта любовь слепа. Но не обязательно в плохом смысле. Просто автор или не может объективно сравнить с другими языками, или, не может нормально объяснить, преимущества. И в комментариях справедливо начинается выяснение чем же так пленил его этот язык. Ведь выглядит ужасно(всё заглавными буквами), выглядит непонятно(названия переменных хуже не придумаешь — меньше чем одну букву для имени взять просто нельзя), выглядит быдлокодом… Но для автора, пленённого каким-то свойством языка, это не важно и он просто отмахивается от таких претензий. В результате, и плюсы языка не понятны, и минусы смотряться гипертрофированными.
Общеупотребительные языки описываются довольно равномерно: есть статьи, которые ругают за недостатки, и есть которые хвалят за достоинства. А уж комментарии к ним позволяют понять, что и достоинства и недостатки не такие уж и ярко выделяющиеся на фоне остальных языков.
Новые языки, обычно воспеваются в статьях, а в комментариях, как правило, идёт поиск целевой области применения.
Вымирающие языки описываются авторами которые любят эти языки. И часто эта любовь слепа. Но не обязательно в плохом смысле. Просто автор или не может объективно сравнить с другими языками, или, не может нормально объяснить, преимущества. И в комментариях справедливо начинается выяснение чем же так пленил его этот язык. Ведь выглядит ужасно(всё заглавными буквами), выглядит непонятно(названия переменных хуже не придумаешь — меньше чем одну букву для имени взять просто нельзя), выглядит быдлокодом… Но для автора, пленённого каким-то свойством языка, это не важно и он просто отмахивается от таких претензий. В результате, и плюсы языка не понятны, и минусы смотряться гипертрофированными.
Хотел написать суть, а написал ощущения. Попробую исправиться:
Оберон ничем не лучше и ничем не хуже других языков программирования, он просто ещё один язык. У него есть сильные и слабые стороны, область применения, примеры систем/приложений. Надеюсь авторы в конце концов напишут статьи именно об этом.
Оберон ничем не лучше и ничем не хуже других языков программирования, он просто ещё один язык. У него есть сильные и слабые стороны, область применения, примеры систем/приложений. Надеюсь авторы в конце концов напишут статьи именно об этом.
И вот вопрос для любителей Оберона, чем он лучше ещё более древнего MUMPS?
О да. cast misha_shar53
устроим баттл между сторонниками оберона и mumps :)
Ну что можно сказать по результатам всех этих статей про Оберон…
Конечно, такие олдскульные системы имеют свое олдскульное очарование. Конечно, хорошо когда есть разнообразие, когда есть альтернативные ОС и языки. И конечно, хорошо что есть люди, которые этим занимаются.
С тезисом о том, что из-за малого количества языковых фич программы якобы получаются надежнее, я конечно же не согласен. В языке есть все небезонасные фичи — такие как указатели например, значит уровень надежности у него такой же как у Си. И уж конечно отсутствие цикла foreach не делает язык безопаснее:)
У меня есть свое видение, каким должен быть язык программирования, и оберон скорее антипример. Но единственное что пожалуй стоит взять из оберона — это модульность, не как реализацию а как идею скорее. Во всяком случае это то, чего реально не хватает в С/С++.
Конечно, такие олдскульные системы имеют свое олдскульное очарование. Конечно, хорошо когда есть разнообразие, когда есть альтернативные ОС и языки. И конечно, хорошо что есть люди, которые этим занимаются.
С тезисом о том, что из-за малого количества языковых фич программы якобы получаются надежнее, я конечно же не согласен. В языке есть все небезонасные фичи — такие как указатели например, значит уровень надежности у него такой же как у Си. И уж конечно отсутствие цикла foreach не делает язык безопаснее:)
У меня есть свое видение, каким должен быть язык программирования, и оберон скорее антипример. Но единственное что пожалуй стоит взять из оберона — это модульность, не как реализацию а как идею скорее. Во всяком случае это то, чего реально не хватает в С/С++.
А чем эта модульность так уж принципиально отличается от модульности в виде динамических библиотек С/С++? Точка входа есть, динамическая загрузка в память, поиск и выполнение процедур есть, что тоже реализуется библиотечными вызовами линкера. С++ даже метаинформацию кодирует за счет name mangling.
Единственно, хэш зависимостей, который, по сути, убивает всю суть модульности, если я правильно ее понимаю тут. Т.е. обновился модуль, интерфейс его остался прежним, хэш изменился, а наша программа отказывается почему-то с ним работать, хотя причин для этого никаких нет.
Единственно, хэш зависимостей, который, по сути, убивает всю суть модульности, если я правильно ее понимаю тут. Т.е. обновился модуль, интерфейс его остался прежним, хэш изменился, а наша программа отказывается почему-то с ним работать, хотя причин для этого никаких нет.
Вот, да. Только хотел задать вопрос про версионность модулей, и вы меня опередили.
Вы не знаете ничего про алгоритм формирования кэша, но уже начинаете нести откровенную ложь про него.
Я имею в виду скорее отсутствие модульности в самом языке, и необходимость использовать архаичную систему инклудов. DLL — это фича операционной системы, от языка тут может потребоваться только поддержка (возможно библиотечная), реализация уже есть во всех ОС.
У меня препод в универе был фанат Оберона, даже написал его компилятор в JVM. В то время мне Оберон показался несколько ограниченной копией Паскаля, к тому же без x86 рантайма. В любом случае, что бы ни говорили, Оберон — это академический язык и всегда таким останется. Чтобы сделать индустриальный язык, нужно «завлечь» пользователя возможностями, сладостями и спецэффектами: поменьше писанины, меньше ограничений и идеологий, вместить в себя все моднючие фичи и парадигмы, цепляться. Также точно глубокий фильм со смыслом никогда не станет кассовым.
Мне кажется что самая большая беда Оберона в том что он не приносит никаких новых концептуальных идей по сравнению с другими языками. Я не отрицаю версии, что именно он лег в основу Java, хотя и сомневаюсь в столь однозначных параллелях, но это не делает Оберон уникальным. Если на то пошло, то почти все концепции были впервые реализованы в Lisp и Smalltalk. Вот и получается что никакого интереса перехода на Оберон как бы и нет. Все чем он может похвастаться, это компактность описания синтаксиса, но и здесь его переплюнет тот же Форт. А если упирать на надежность, то уж лучше на какой-нибудь Eiffel посмотреть, больше идей принесет.
Закрыв глаза на качество кода, меня заинтересовало это
Например я считаю что будущее (к сожалению не близкое) развитие языков програмирования, компиляторов и операционных систем, благодаря постоянному повышению требований к энергопотребления конечных устройств, например интернета вещей, именно в сторону программируемой логики или даже воплощению в железе прямо с завода.
Н. Вирт решил дополнить свою систему еще одним компонентом — своим вариантом языка для программирования FPGA, который был назван Lola.тоесть код может быть сконвертирован в verilog? Весь? Можно красивый пример типа помигать лампочкой? Вывести текст на экран? Игру тетрис?
Например я считаю что будущее (к сожалению не близкое) развитие языков програмирования, компиляторов и операционных систем, благодаря постоянному повышению требований к энергопотребления конечных устройств, например интернета вещей, именно в сторону программируемой логики или даже воплощению в железе прямо с завода.
Я могу только показать вам описание языка и менее формальное описание его применения. Вирт сделал его компилятор в системе Оберон, но компилятор портировать на любой другой язык будет легко.
А пример кода я могу показать не очень «красивый», например четырехбитный счетчик
MODULE Counter0 (IN clk: BIT; OUT d: [4] BIT);
REG R: [4] BIT;
BEGIN
R := {R.3 ^ R.3 & R.2 & R.1 & R.0, (*R.3*)
R.2 ^ R.2 & R.1 & R.0, (*R.2*)
R.1 ^ R.1 & R.0, (*R.1*)
~R.0}; (*R.0*)
d := R
END Counter0.
www.inf.ethz.ch/personal/wirth/Lola/index.html
А пример кода я могу показать не очень «красивый», например четырехбитный счетчик
MODULE Counter0 (IN clk: BIT; OUT d: [4] BIT);
REG R: [4] BIT;
BEGIN
R := {R.3 ^ R.3 & R.2 & R.1 & R.0, (*R.3*)
R.2 ^ R.2 & R.1 & R.0, (*R.2*)
R.1 ^ R.1 & R.0, (*R.1*)
~R.0}; (*R.0*)
d := R
END Counter0.
www.inf.ethz.ch/personal/wirth/Lola/index.html
Уважаемые, kisybi, oberon87, OberonForGood, akastargazer.
А давайте прекратим заниматься демагогией, тем более мы с вами видимо читали немножко разный набор книг и имеем разный опыт в промышленной разработке. Вместо этого, проведем эксперимент, как положено «в науке» — возьмем более-менее приличную по размеру задачу, и вы ее реализуете на Обероне. А я ее реализую, например, на C#. А кто-нибудь еще реализует на своем любимом языке программирование.
А потому выставим реалиазации на суд и анализ общественности, пусть рынок рассудит, что лучше читается и что надежнее работает.
А давайте прекратим заниматься демагогией, тем более мы с вами видимо читали немножко разный набор книг и имеем разный опыт в промышленной разработке. Вместо этого, проведем эксперимент, как положено «в науке» — возьмем более-менее приличную по размеру задачу, и вы ее реализуете на Обероне. А я ее реализую, например, на C#. А кто-нибудь еще реализует на своем любимом языке программирование.
А потому выставим реалиазации на суд и анализ общественности, пусть рынок рассудит, что лучше читается и что надежнее работает.
Ты под «приличного размера» что имеешь в виду? Алгоритм (тот же TSP, тут же беспилотники недалеко летали?)? Простое приложение (телефонный справочник)? Сложное приложение (иик)?
А мне все равно если честно. Вон, выше тетрис упоминали. В нем и структуры данных, и алгоритмы.
На голых алгоритмах, имхо, сложно показать некоторые особенности языков, хотя можно и их.
На голых алгоритмах, имхо, сложно показать некоторые особенности языков, хотя можно и их.
почему бы просто не написать интерпретатор мини-лиспа? и просто и интересно.
Именно. Так можно сравнить сколько боли и крови потребует реализация этого правила :)
Это не совсем честная задача, так как я ее уже реализовал и успел засветить реализацию в этой теме в ветке про замыкания ;)
Правда, если подпишется кто-то еще с каким-либо еще ЯП, то можно взять за основу набор тестовых примеров, которые должны работать — github.com/corvusalba/my-little-lispy/tree/master/examples
Правда, если подпишется кто-то еще с каким-либо еще ЯП, то можно взять за основу набор тестовых примеров, которые должны работать — github.com/corvusalba/my-little-lispy/tree/master/examples
Боюсь, тогда фанаты лиспа победят с огромным отрывом, написав repl-цикл в одну строчку.
Кстати, хорошая задача.
(транспорт только лучше определить; я за HTTP, GET-запрос, логин/пароль в query string, ответ статус-кодом 204/401).
(транспорт только лучше определить; я за HTTP, GET-запрос, логин/пароль в query string, ответ статус-кодом 204/401).
Давайте тогда уж STUN сервер. RFC на всех один, ТЗ составлять не надо.
Хорошо, когда есть сетевой стек стандартной либы от Microsoft или Oracle. Можно выбирать задачки по вкусу и перспективности. Шулер из вас так себе.
А для Оберона за все дцать лет его существования никто не написал стандартного модуля сетевого стека?
Т.е. послать UDP пакет и получить UDP пакет для Оберона слишком сложно?
для js фреймворков вот такой вариант есть todomvc.com
Саморегуляция тут известно как работает, поэтому нет, пожалуй, джавистам и плюсовикам я на суд идти не собираюсь. Если интересно, вы с другом, который вам тыкает, можете реализовать такой проект, как описан в статье.
Вот, Система Оберон есть, реализуйте такую на C# и потом посмотрим. Не забудьте сами реализовать компилятор для C# и еще язык типа верилога. В общем, этапы я расписал в статье.
Вот, Система Оберон есть, реализуйте такую на C# и потом посмотрим. Не забудьте сами реализовать компилятор для C# и еще язык типа верилога. В общем, этапы я расписал в статье.
А, ну то есть мне даже вариант задачи нельзя выбрать. Неплохо, неплохо.
То есть, вы боитесь что сможете доказать «тупым джавистам», что ваш код хорош?
Не проблема, тут в комментариях появился pjBooms на которого вы же и ссылались как на авторитета.
Я не против если он тоже будет в жюри.
А иначе получается, что вы в принципе не можете подтвердить свое мнение на счет языков программирования и сразу сливаетесь как начинается разговор о чем-то реальном.
По поводу «системы Оберон»: ну вот вам такой же академический проект на C# — ru.wikipedia.org/wiki/Microsoft_Singularity
Не проблема, тут в комментариях появился pjBooms на которого вы же и ссылались как на авторитета.
Я не против если он тоже будет в жюри.
А иначе получается, что вы в принципе не можете подтвердить свое мнение на счет языков программирования и сразу сливаетесь как начинается разговор о чем-то реальном.
По поводу «системы Оберон»: ну вот вам такой же академический проект на C# — ru.wikipedia.org/wiki/Microsoft_Singularity
Пацанский ход.
На самом деле я уже все себе доказал, а на хабре у меня не та цель, которую вы тут себе придумали. Если хотите, берите любую мою библиотеку, из последних, например JSON парсер и делайте такой же, как умеете, а потом сравнивайте. Мне неинтересно это.
Короче, у Вас длиннее. ;)
На самом деле я уже все себе доказал, а на хабре у меня не та цель, которую вы тут себе придумали. Если хотите, берите любую мою библиотеку, из последних, например JSON парсер и делайте такой же, как умеете, а потом сравнивайте. Мне неинтересно это.
Короче, у Вас длиннее. ;)
Где ваш парсер можно посмотреть?
Так и не снизошли до моей скромной персоны, не видать мне парсера. Рылом не вышел.
Я так понимаю, что это тот самый парсер. А вот тут обсуждение оного.
Цикл Дейкстры есть, я спокоен.
Самое забавное, что в КП (а Компонентный Паскаль не может называться обероном, согласно www.math.bas.bg/bantchev/place/oberon/oakwood-guidelines.pdf (см. 1.3 Use of the name Oberon ), ибо он не реализует Oberon или Oberon-2 (они модифицировали язык обратно не совместимым образом) нет цикла Дейкстры. Он есть только в последних ревизиях Оберона от Вирта.
Соответственно пишущие на КП не могут говорить, что они имеют опыт написания кода на Обероне :-)
Соответственно пишущие на КП не могут говорить, что они имеют опыт написания кода на Обероне :-)
Вообще-то может, так как отвечает указанному требованию, ибо реализует язык оберон-2. и даже часть экосистемы, модули In, Out и т.д.
Э? Кто кого реализует? Кто на ком стоял? ;-)
Поясню подробно, по пунктам:
Тот факт, что компилятор которым вы пользуетесь умеет еще и другой язык, не дает вам права говорить, что вы пишете и на другом языке тоже (если вы пишете преимущественно только на одном из этих двух языков).
Приведу пример: компилятор gcc это тоже не один компилятор, а множество компилятором в общей инфраструктурой. Компилирует множество языков. Например написав gcc -c main.cpp оно соберет мне С++ программу, а написав gcc -c hello.adb соберет программу на Аде. Но сам факт использования мною gcc в качестве компилятора не дает мне права говорить, что я пишу и на Аде и на С++. Если я пишу на С++, значит я пишу на С++, какой бы компилятор я ни использовал, и сколько бы языков этот компилятор ни поддерживал.
Поясню подробно, по пунктам:
- Есть язык Компонентный Паскаль. Это самостоятельный язык, получившийся из языка Оберон-2 после его существенной модификации под требования которые возникли при написании среды BlackBox. Модификации были таковы, что Компонентный Паскаль обратно не совместим с Обероном-2, и с Обероном оригинальным тоже не совместим (то есть модуль писаный на Обероне или Обероне-2 не соберется компилятором который умеет компилировать только компонентный паскаль)
- Есть компиляторы компонентного паскаля. Мне их известно два с половиной (половина — это не вполне доделаный компилятор для микроконтроллера 8051): GPCP (https://gpcp.codeplex.com) и компилятор входящий в состав BlackBox (http://blackboxframework.org). GPCP умеет компилировать только КП. Компилятор же в BlackBox имеет два режима, и в одном режиме может компилировать только КП, а в другом режиме только Оберон-2, таким образом это два компилятора в одном. Но это ничего не меняет
Тот факт, что компилятор которым вы пользуетесь умеет еще и другой язык, не дает вам права говорить, что вы пишете и на другом языке тоже (если вы пишете преимущественно только на одном из этих двух языков).
Приведу пример: компилятор gcc это тоже не один компилятор, а множество компилятором в общей инфраструктурой. Компилирует множество языков. Например написав gcc -c main.cpp оно соберет мне С++ программу, а написав gcc -c hello.adb соберет программу на Аде. Но сам факт использования мною gcc в качестве компилятора не дает мне права говорить, что я пишу и на Аде и на С++. Если я пишу на С++, значит я пишу на С++, какой бы компилятор я ни использовал, и сколько бы языков этот компилятор ни поддерживал.
What's New in Component Pascal?
Except for some minor points, Component Pascal is a superset of Oberon-2. Compared to Oberon-2, it provides several clarifications and improvements. This text summarizes the differences. Some of the changes had already been realized in earlier releases of the BlackBox Component Builder, all of them are implemented for Release 1.3 and higher.
The language revision was driven by the experience with the BlackBox Component Framework, and the desire to further improve support for the specification, documentation, development, maintenance, and refactoring of component frameworks.
То есть CP это расширение Оберона-2, но если их не использовать, получится Оберон. Учитывая общую тенденцию импрувментов Оберона, КП — это Оберон в той же степени, в какой и АО.
Послушайте, Алексей, ваша позиция в оберон-сообществе известна. Если сейчас вы решили выразить ее и собрать лайков, то вы хотя бы говорите всю правду, а не смешивайте известные факты, и ваши домыслы.
А то там уже отдельные умники делают далеко идущие выводы из ваших, скажем так, выдумок.
Except for some minor points, Component Pascal is a superset of Oberon-2. Compared to Oberon-2, it provides several clarifications and improvements. This text summarizes the differences. Some of the changes had already been realized in earlier releases of the BlackBox Component Builder, all of them are implemented for Release 1.3 and higher.
The language revision was driven by the experience with the BlackBox Component Framework, and the desire to further improve support for the specification, documentation, development, maintenance, and refactoring of component frameworks.
То есть CP это расширение Оберона-2, но если их не использовать, получится Оберон. Учитывая общую тенденцию импрувментов Оберона, КП — это Оберон в той же степени, в какой и АО.
Послушайте, Алексей, ваша позиция в оберон-сообществе известна. Если сейчас вы решили выразить ее и собрать лайков, то вы хотя бы говорите всю правду, а не смешивайте известные факты, и ваши домыслы.
А то там уже отдельные умники делают далеко идущие выводы из ваших, скажем так, выдумок.
Если их (расширения) не использовать, то Оберона тоже не получится. Получится что-то похожее, но не совместимое с Обероном.
Есть код на Обероне, или Обероне-2, чтобы его перенести на КП нужно его портировать. Есть код на КП, чтобы его собрать на компиляторе Оберона его тоже надо портировать. Да, работы будет меньше чем при попытке собрать код на Си компилятором КП, значительно меньше, но она будет.
Это говорит о том, что это таки РАЗНЫЕ языки.
Поясню на примере: вот есть язык такой Objective-C, вот он (в отличие от например С++) действительно является чистым надмножеством С. Но, однако, даже если я пишу на ObjC постоянно и много, это таки не дает мне права говорить что я имеют богатый опыт написания кода на Си. Просто потому, что при написании проекта на чистом Си будут использоваться другие подходы к проектированию, использоваться будут другие практики нежели при написании на ObjC. Если мне нравится писать на Си, не значит что мне понравится писать на ObjC, равно как и наоборот.
Далее, вот есть язык swift — прямой потомок ObjC. То есть имеем C->ObjC->Swift. Так вот, если я пишу на swift это тем более не дает мне права говорить что я пишу на Си.
При переходе с КП на Оберон (для пущего эффекта пусть это будет Оберон пследней ревизии, а не Оберон-2) ломка будет покруче, чем при переходе от ObjC на Си.
Маленький пример: в КП (да и в старом-старом Обероне, от 1990 года) можно создавать массивы с неизвестной на этапе компиляции длины (то есть аналог int* foo = new int[N]). В последней ревизии Оберона этого уже нет. Можно только массивы с известной длиной на этапе компиляции (int* foo = new int[100500];). И подобных отличий там куча. И это требует других подходов как к проектированию, так и к написанию кода.
PS. Но конечно же те, кто называют Оберон паскалем еще больше не правы. Оберон это таки не паскаль. И даже не модула. И не Ада. Оберон это Оберон.
Есть код на Обероне, или Обероне-2, чтобы его перенести на КП нужно его портировать. Есть код на КП, чтобы его собрать на компиляторе Оберона его тоже надо портировать. Да, работы будет меньше чем при попытке собрать код на Си компилятором КП, значительно меньше, но она будет.
Это говорит о том, что это таки РАЗНЫЕ языки.
Поясню на примере: вот есть язык такой Objective-C, вот он (в отличие от например С++) действительно является чистым надмножеством С. Но, однако, даже если я пишу на ObjC постоянно и много, это таки не дает мне права говорить что я имеют богатый опыт написания кода на Си. Просто потому, что при написании проекта на чистом Си будут использоваться другие подходы к проектированию, использоваться будут другие практики нежели при написании на ObjC. Если мне нравится писать на Си, не значит что мне понравится писать на ObjC, равно как и наоборот.
Далее, вот есть язык swift — прямой потомок ObjC. То есть имеем C->ObjC->Swift. Так вот, если я пишу на swift это тем более не дает мне права говорить что я пишу на Си.
При переходе с КП на Оберон (для пущего эффекта пусть это будет Оберон пследней ревизии, а не Оберон-2) ломка будет покруче, чем при переходе от ObjC на Си.
Маленький пример: в КП (да и в старом-старом Обероне, от 1990 года) можно создавать массивы с неизвестной на этапе компиляции длины (то есть аналог int* foo = new int[N]). В последней ревизии Оберона этого уже нет. Можно только массивы с известной длиной на этапе компиляции (int* foo = new int[100500];). И подобных отличий там куча. И это требует других подходов как к проектированию, так и к написанию кода.
PS. Но конечно же те, кто называют Оберон паскалем еще больше не правы. Оберон это таки не паскаль. И даже не модула. И не Ада. Оберон это Оберон.
Вот репозиторий: bitbucket.org/oberoncore/yson
Для нормального просмотра исходников понадобится BlackBox (исходники не в текстовом виде, а в формате документов BlackBox — расширение odc, не путать с форматом документов openoffice): blackboxframework.org
Для нормального просмотра исходников понадобится BlackBox (исходники не в текстовом виде, а в формате документов BlackBox — расширение odc, не путать с форматом документов openoffice): blackboxframework.org
Исходники не в текстовом виде — это прощай контроль версий? Всё настолько запущено?
Сейчас вам напишут, что контроль версий не нужен.
Оно ж на битбакете. Контроль версий есть, диффов нет
Ой, не представляете насколько вы близки к истине. :-)
Помнится несколько лет шли дебаты на тему того, нужно ли оно, или же это мейнстримовый заскок очередной.
В том числе приводилась такое мнение, что контроль версий нужен только если в коде хаос, непонятно кто за какой модуль отвечает (просто потому, что язык какой-то некошерный используется, типа С++ и модулей нет вовсе!!1), а вот если модули распределены по членам комады, у каждого модуля свой интерфейс. Модуль пишется по спецификации и сразу корректно, то и система контроля версий не нужна.
Если спецификация меняется, то модуль старый просто выбрасывается, и пишется новый (тоже быстро, целиком и сразу работает). Модули — это такие черные коробочки (BlackBox'инки такие, ага), монолитные и не делимые.
Строгость оберона способствует аккуратности написания кода и проектированию системы!
Вот примерно такие доводы приводились. И они таки еще в силе в среде оберон-сообщества. Хотя, безусловно, есть и движение за систему контроля версий, люди понимают зачем оно нужно и как с этим работать. Поэтому производится адаптация инструментария под это дело.
PS. И да, это еще одна дисциплина спец. олимпиады в оберон-сообществе: срачик на тему должены ли исходники храниться в бинарном, или же таки текстовом виде. Он периодически возникал и затухал и вновь возрождался на протяжении всех 10 лет моего участия в этом деле. За текст — высказывалось возможность использовать богатый набор готовых тулзов сторонних, использовать систему контроля версий и так далее. За бинарь — возможность раскрашивать текст как угодно, применять стили, выделять семантически значимые куски исходника, вставлять в исходник дополнительные материалы иллюстрирующие происходящее (простейший случай — вставить в исходник картинку со схемой работы алгоритма например, или примером результата работы) и так далее. А текст… Это в мейнстриме от нищеты мышления и косности восприятия!
Как-то так ;-)
Помнится несколько лет шли дебаты на тему того, нужно ли оно, или же это мейнстримовый заскок очередной.
В том числе приводилась такое мнение, что контроль версий нужен только если в коде хаос, непонятно кто за какой модуль отвечает (просто потому, что язык какой-то некошерный используется, типа С++ и модулей нет вовсе!!1), а вот если модули распределены по членам комады, у каждого модуля свой интерфейс. Модуль пишется по спецификации и сразу корректно, то и система контроля версий не нужна.
Если спецификация меняется, то модуль старый просто выбрасывается, и пишется новый (тоже быстро, целиком и сразу работает). Модули — это такие черные коробочки (BlackBox'инки такие, ага), монолитные и не делимые.
Строгость оберона способствует аккуратности написания кода и проектированию системы!
Вот примерно такие доводы приводились. И они таки еще в силе в среде оберон-сообщества. Хотя, безусловно, есть и движение за систему контроля версий, люди понимают зачем оно нужно и как с этим работать. Поэтому производится адаптация инструментария под это дело.
PS. И да, это еще одна дисциплина спец. олимпиады в оберон-сообществе: срачик на тему должены ли исходники храниться в бинарном, или же таки текстовом виде. Он периодически возникал и затухал и вновь возрождался на протяжении всех 10 лет моего участия в этом деле. За текст — высказывалось возможность использовать богатый набор готовых тулзов сторонних, использовать систему контроля версий и так далее. За бинарь — возможность раскрашивать текст как угодно, применять стили, выделять семантически значимые куски исходника, вставлять в исходник дополнительные материалы иллюстрирующие происходящее (простейший случай — вставить в исходник картинку со схемой работы алгоритма например, или примером результата работы) и так далее. А текст… Это в мейнстриме от нищеты мышления и косности восприятия!
Как-то так ;-)
Мне это напоминает МММ. «Все все платится» потому что «Всем все платится».
И Оберон способствует аккуратности написания кода, потому что оберон способствует аккуратности написания кода.
Собственно, что мешает класть конфиг с любыми стилями в текстовом виде рядом с текстовым же исходником? Зачем для этого бинарник?
Что мешает вставлять картинки и выделять значимые куски исходника так как это делает Кнут в своем «литературном программировании»?
Если модуль — черная коробочка, то где поддержка версионности модулей?
Что делать если мне нужен модуль сразу в нескольких версиях? Простой пример — я использую сторонний модуль новой версии и при этом у меня есть еще один сторонний модуль, который использует первый, но более старой версии. Вся модульная система тут же ломается?
Собственно, это только характеризует оберон-сообщество с не очень хорошей стороны.
Подозреваю, что состоит оно в основном из выходцев из академической среды, очень плохо понимающих реальные задачи и проблемы индустрии. Парадокс блаба как он есть, только в совсем смешном варианте.
И Оберон способствует аккуратности написания кода, потому что оберон способствует аккуратности написания кода.
Собственно, что мешает класть конфиг с любыми стилями в текстовом виде рядом с текстовым же исходником? Зачем для этого бинарник?
Что мешает вставлять картинки и выделять значимые куски исходника так как это делает Кнут в своем «литературном программировании»?
Если модуль — черная коробочка, то где поддержка версионности модулей?
Что делать если мне нужен модуль сразу в нескольких версиях? Простой пример — я использую сторонний модуль новой версии и при этом у меня есть еще один сторонний модуль, который использует первый, но более старой версии. Вся модульная система тут же ломается?
Собственно, это только характеризует оберон-сообщество с не очень хорошей стороны.
Подозреваю, что состоит оно в основном из выходцев из академической среды, очень плохо понимающих реальные задачи и проблемы индустрии. Парадокс блаба как он есть, только в совсем смешном варианте.
И Оберон способствует аккуратности написания кода, потому что оберон способствует аккуратности написания кода.
Ну, в общем то да. Это очень смахивает на религию, и/или секту.
Собственно, что мешает класть конфиг с любыми стилями в текстовом виде рядом с текстовым же исходником? Зачем для этого бинарник?
А я думал про это. Не выйдет по одной простой причине — если стиль задается с точностью позиционирования до символа (буквы). Соответственно в файле стилей будет что-то вроде списка пар:
{range1 : {color1, style1}},
{range2 : {color2, style2}},
...
так вот, как только кто-то поменяет исходник (например открыв его в каком-нибудь nano, или вообще в онлайн-редакторе в на github), но забудет поменять (предварительно пересчитав) все range в файле стилей, то все, привет-приплыли. Все оформление съедет.
То есть это просто так не лечится.
Что мешает вставлять картинки и выделять значимые куски исходника так как это делает Кнут в своем «литературном программировании»?
Картинки это один из самых простых вариантов того, что там в документе может быть. Там еще могут быть програмные исполняемые модули интерактивные например. Ну то есть по сложности задача упихивания в текстовый формат, примерно как задача придумать адекватный редактируемый текстовый формат для ms-word документа в который внедрено еще и всякое OLE-образное.
Но оговорюсь — этим всем (бинарными исходниками) особенно густо страдает именно что BlackBox (и его поклонники), с ЯП Компонентный Паскаль. В Виртовской же Оберон-системе все попроще и там в основном таки текст.
В дальнейшем развитии оберонов — в A2 (ранее — Bluebottle), перешли на xml там где это нужно, а там где не нужно (а оно в основном не нужно) спокойно используют plain text. Поэтому с версионностью там все норм. И пишут там немного в другом, нежели Вирт. стиле. Вот, посмотрите: svn.inf.ethz.ch/svn/lecturers/a2/trunk/source
Впрочем, в A2 и язык другой — Active Oberon, который более фичаст нежели Оберон.
Если модуль — черная коробочка, то где поддержка версионности модулей?
Что делать если мне нужен модуль сразу в нескольких версиях? Простой пример — я использую сторонний модуль новой версии и при этом у меня есть еще один сторонний модуль, который использует первый, но более старой версии. Вся модульная система тут же ломается?
Вообще, по моему мнению, одна из проблем оригинального Оберона и BlackBox в том, что by design одновременно может быть загружена только одна версия модуля. Один инстанс модуля, если угодно. Это частенько мешает.
Собственно, это только характеризует оберон-сообщество с не очень хорошей стороны.
Подозреваю, что состоит оно в основном из выходцев из академической среды, очень плохо понимающих реальные задачи и проблемы индустрии. Парадокс блаба как он есть, только в совсем смешном варианте.
Не, там много разномастного народа. В том числе довольно сильно обиженного из за чего-то на мейнстрим (разные причины). А академическая среда там не представлена представителями Computer Science (я говорю про рускоязычное сообщество сейчас, и то, которое активно общается на тематических форумах обероновских), в основном это физики-математики.
Как-то так.
У меня же к оберону свой интерес — мною движет, как обычно, чистое любопытство :-) Нарыть ковыряя Оберон можно многое, при желании и при любви ковыряться в старых документах. Бывают интересные находки. О чем я и постараюсь написать :-)
Собственно, система для математиков-физиков с форматированием, лайвкодингом и в общем-то всеми перечисленными вами фичами уже есть — Mathematica. И язык там по природе своей функциональный и похож на Лисп, что по идее гораздо ближе физикам, и уж точно позволяет писать более надежный код.
Ну, там есть свои нюансы. Например для части физиков важна например скорость работы написанного числодробильного метода. Поэтому слоупочно крутящий циклы матлаб не всегда подходит например (векторизацию никто конечно не отменял, но не все к ней сводится). Особенно если метод новый, уникальный и не сводится к предыдущим.
Насколько я понимаю у математики те же проблемы будут (хотя судя по julialang.org у математики все лучше с производительностью чем у матлаба). А вот тот же КП скомпилируется в машкот и более-менее быстро исполнится (хотя фортран или современный С++ его конечно сделает).
Так что в принципе, кое-где кое-когда для подобных вещей применение BlackBox'а даже оправдано. Его собственно и используют некоторые ученые в России.
Распределенные вычисления тоже делаются на нем вполне.
Насколько я понимаю у математики те же проблемы будут (хотя судя по julialang.org у математики все лучше с производительностью чем у матлаба). А вот тот же КП скомпилируется в машкот и более-менее быстро исполнится (хотя фортран или современный С++ его конечно сделает).
Так что в принципе, кое-где кое-когда для подобных вещей применение BlackBox'а даже оправдано. Его собственно и используют некоторые ученые в России.
Распределенные вычисления тоже делаются на нем вполне.
Ну, я же про матлаб и векторизацию и написал :-) Сам на нем пишу по работе (у нас стартап, так что и на матлабе писать надо, и приложение под IOS, и код для сервера, так что каждый и жнец и жрец и на трубе игрец). Что-то там можно сделать очень производительным (и с автоматическим распараллеливанием), а что-то нет (приходится на С++ писать модуль).
Вообще, в науке нет какого-то единого инструмента на все случаи жизни, Марков (http://macroevolution.livejournal.com/ ) вон вообще на VisualBasic for Excel писал обработку экспериментов например :-)
Поэтому даже BlackBox вполне себе применяется и некоторыми весьма успешно. Помню Иван Денисов демонстрировал автоматизированный лабораторный журнал на базе BlackBox — действительно весьма удобно получилось.
Вообще, в науке нет какого-то единого инструмента на все случаи жизни, Марков (http://macroevolution.livejournal.com/ ) вон вообще на VisualBasic for Excel писал обработку экспериментов например :-)
Поэтому даже BlackBox вполне себе применяется и некоторыми весьма успешно. Помню Иван Денисов демонстрировал автоматизированный лабораторный журнал на базе BlackBox — действительно весьма удобно получилось.
О, раз вы в теме — а как в Обероне принято разруливать совместимость структур при перезагрузке модуля?
Поясняю — вот есть Эрланг, с тем же самым hot code reload. В новой версии модуля поменялась некая внутренняя структура, функции скмпилированы в рассчете на нее, а в памяти осталась висеть структура предыдущей версии. После перезагрузки вызов функции из новой версии модуля предсказуемо вызовет ошибку. Есть некоторые пути для миграции формата стейта, чтобы избежать этого, но они не сказать, что сильно удобны.
Так вот, как с этим в Обероне?
Поясняю — вот есть Эрланг, с тем же самым hot code reload. В новой версии модуля поменялась некая внутренняя структура, функции скмпилированы в рассчете на нее, а в памяти осталась висеть структура предыдущей версии. После перезагрузки вызов функции из новой версии модуля предсказуемо вызовет ошибку. Есть некоторые пути для миграции формата стейта, чтобы избежать этого, но они не сказать, что сильно удобны.
Так вот, как с этим в Обероне?
Ну, насколько я знаю, там есть варианты для конвертации в текст и что-то на тему плагинов к системам контроля версий делалось.
Но вот в данном конкретном случае — таки да.
Но вот в данном конкретном случае — таки да.
А какая у вас цель на хабре?
Привить отторжение к языку?
Аргументы (и наезды) противников я не одобряю, но понимаю. А ваши ответы если где и присутствуют, то вызывают больше вопросов и ещё наездов. И я не понимаю даже, что вы хотите объяснить.
Привить отторжение к языку?
Аргументы (и наезды) противников я не одобряю, но понимаю. А ваши ответы если где и присутствуют, то вызывают больше вопросов и ещё наездов. И я не понимаю даже, что вы хотите объяснить.
Кроме меня на эту тему никто не пишет, отсюда и куча вопросов, так как в других местах люди годами ее обсуждают, а вы тут за день все решили. При этом никаких статей про такое я давно на хабре не припомню, про фундаментальные основы, и тому подобное. Считается, что все все знают чтоли?
Видимо люди придумывают как что-то сделать. Придумать что-то это сложный процесс. А вот понять что-то придуманное — гораздо проще.
«Сложно объяснить — просто. Просто объяснить — сложно.» У вас не получается доходчиво объяснить, почему то, что комментаторы записывают в минусы или не является минусами или несущественно. У вас не получается доходчиво объяснить, почему плюсы — действительно плюсы.
Я вас в какой-то мере понимаю. Как я писал в этой теме — мне очень нравиться MUMPS. А у него есть тяжёлое наследие — криптоMUMPS и программисты как только увидят эту его часть, сразу убегают. Вот ссылка на мой комментарий habrahabr.ru/company/jelastic/blog/166845/#comment_5910677 посмотрите, не являясь программистом на MUMPS, я честно пытаюсь решить на MUMPS придуманную не мной задачу. Да, результат не достигнут, т.к. адепт SQL не стал ничего делать, но я приложил усилия, что бы показать, где он там не прав(может он и прав, но не смог этого продемонстрировать). А от любителей оберона ответы по смыслу «сам дурак».
Попробуйте отвечать на вопросы примерами кода, ведь мантра «компактное описание языка = отсутствие ошибок» не всегда работает.
«Сложно объяснить — просто. Просто объяснить — сложно.» У вас не получается доходчиво объяснить, почему то, что комментаторы записывают в минусы или не является минусами или несущественно. У вас не получается доходчиво объяснить, почему плюсы — действительно плюсы.
Я вас в какой-то мере понимаю. Как я писал в этой теме — мне очень нравиться MUMPS. А у него есть тяжёлое наследие — криптоMUMPS и программисты как только увидят эту его часть, сразу убегают. Вот ссылка на мой комментарий habrahabr.ru/company/jelastic/blog/166845/#comment_5910677 посмотрите, не являясь программистом на MUMPS, я честно пытаюсь решить на MUMPS придуманную не мной задачу. Да, результат не достигнут, т.к. адепт SQL не стал ничего делать, но я приложил усилия, что бы показать, где он там не прав(может он и прав, но не смог этого продемонстрировать). А от любителей оберона ответы по смыслу «сам дурак».
Попробуйте отвечать на вопросы примерами кода, ведь мантра «компактное описание языка = отсутствие ошибок» не всегда работает.
Ни разу не попытка взять «на понт».
Всего лишь попытка экспмериментальным методом выяснить состоятельность ваших аргументов. К сожалению, похоже, что вы сами уже понимаете их несостоятельность.
Если вам неинтересно, то зачем вы столько времени в нескольких статьях пытаетесь кому-то что-то доказать?
Я вашему виртуалу в соседней статье уже писал — вы выходите с набором спорным утверждений на публику и требуете чтобы публика сама их проверяла. Зачем? Читателям заняться больше нечем?
Всего лишь попытка экспмериментальным методом выяснить состоятельность ваших аргументов. К сожалению, похоже, что вы сами уже понимаете их несостоятельность.
Если вам неинтересно, то зачем вы столько времени в нескольких статьях пытаетесь кому-то что-то доказать?
Я вашему виртуалу в соседней статье уже писал — вы выходите с набором спорным утверждений на публику и требуете чтобы публика сама их проверяла. Зачем? Читателям заняться больше нечем?
Ну как же не попытка, если там у вас слова про страх и слив.
А мои аргументы вы даже перечислить не сможете, не то что выяснить состоятельность. Подумайте только, вы тут такой пришли и за час все поняли, а люди годами думают, и не поняли. Насколько же вы себя считаете лучше их?
Поэтому уточню, мне неинтересно то, что вы предложили, потому что вы расставляете фигуры, чтобы выиграть, а не чтобы выяснить что-то про Оберон. А писать статьи да, это интересно. Вот обратите внимание на статью про троичный компьютер, про интерпретатор Оберона на go. Хорошо, что статьи тут сохраняются. Много людей прочитает про Оберон.
Если хотите поговорить об этом, приходите в xmpp:oberon@c.j.r, а то тут у меня запас свободы слова быстро заканчивается, и видимо, на это основной расчет.
А мои аргументы вы даже перечислить не сможете, не то что выяснить состоятельность. Подумайте только, вы тут такой пришли и за час все поняли, а люди годами думают, и не поняли. Насколько же вы себя считаете лучше их?
Поэтому уточню, мне неинтересно то, что вы предложили, потому что вы расставляете фигуры, чтобы выиграть, а не чтобы выяснить что-то про Оберон. А писать статьи да, это интересно. Вот обратите внимание на статью про троичный компьютер, про интерпретатор Оберона на go. Хорошо, что статьи тут сохраняются. Много людей прочитает про Оберон.
Если хотите поговорить об этом, приходите в xmpp:oberon@c.j.r, а то тут у меня запас свободы слова быстро заканчивается, и видимо, на это основной расчет.
Я как минимум задал вопросы про семантику и про версионность модулей. Ответов не получил
Аргументов кроме, «begin лучше чем фигурные скобочки» я особо не увидел. То что программы на обероне стабильнее у вас доказать не получилось, провести эксперимент вы не хотите…
Так что говорите за себя, пожалуйста.
Вчера много гуглил про оберон, никаких реальных преимуществ не увидел — еще один виртовский академический нежизнеспособный язык с устаревшей семантикой.
Собственно, я прошу еще раз — прекращайте демагогию. Хотите, чтобы вам поверили — давайте проведем эксперимент. Считаете себя умнее сообщества? Ну, извините, за такое самомнение надо отвечать делами, что у вас пока не получается.
P.S. не с того аккаунта комментарий написали, oberon87 в соседней теме пишет ;)
Аргументов кроме, «begin лучше чем фигурные скобочки» я особо не увидел. То что программы на обероне стабильнее у вас доказать не получилось, провести эксперимент вы не хотите…
Так что говорите за себя, пожалуйста.
Вчера много гуглил про оберон, никаких реальных преимуществ не увидел — еще один виртовский академический нежизнеспособный язык с устаревшей семантикой.
Собственно, я прошу еще раз — прекращайте демагогию. Хотите, чтобы вам поверили — давайте проведем эксперимент. Считаете себя умнее сообщества? Ну, извините, за такое самомнение надо отвечать делами, что у вас пока не получается.
P.S. не с того аккаунта комментарий написали, oberon87 в соседней теме пишет ;)
Это были не вопросы, а ошибочные утверждения. Мне нельзя указывать на ошибочные утверждения? Или сообщество не ошибается?
И опять пример неверного утверждения, «стабильность программ на Обероне» это фраза без наличия в ней смысла, так как стабильность зависит от кучи других вещей, помимо алгоритма, записанного в Обероне. В целом, это называют экосистемой.
Собственно, всё что я сказал на ваше предложение остается в силе. Заходить в серьезный разбор полетов с такими предпосылками типа «еще один виртовский академический нежизнеспособный язык с устаревшей семантикой» я не собираюсь. Так, потрепаться в комментах вместо работы, да, можно.
А этот аккаунт уже не работает, вашими стараниями. Теперь вы можете невинно пошутить по этому поводу, смайлик поставить. Вы победитель.
И опять пример неверного утверждения, «стабильность программ на Обероне» это фраза без наличия в ней смысла, так как стабильность зависит от кучи других вещей, помимо алгоритма, записанного в Обероне. В целом, это называют экосистемой.
Собственно, всё что я сказал на ваше предложение остается в силе. Заходить в серьезный разбор полетов с такими предпосылками типа «еще один виртовский академический нежизнеспособный язык с устаревшей семантикой» я не собираюсь. Так, потрепаться в комментах вместо работы, да, можно.
А этот аккаунт уже не работает, вашими стараниями. Теперь вы можете невинно пошутить по этому поводу, смайлик поставить. Вы победитель.
Ткну пальцем — habrahabr.ru/post/258727/#comment_8434249
Где там ошибочные утверждения и утверждения вообще?
Ну кроме того, что я — дурак, который чего-то не понимает.
Где там ошибочные утверждения и утверждения вообще?
Ну кроме того, что я — дурак, который чего-то не понимает.
Я просто продемонстрирую, как выглядит беседа с моей стороны.
Я пишу:
В спрашиваете в ответ:
Я говорю про экосистему, вы про семантику.
Вы правда хотели спросить именно это? Может Вас отвлекли на работе, я не знаю, но семантику с экосистемой перепутать. И так каждый раз, я вам про Ваню, а вы мне про баню.
Я пишу:
Вообще, вы сейчас делаете странную вещь, лезете в новую для вас экосистему со своим набором правил. Я не говорю, что они все не работают, но вы не доказали их применимость.
В спрашиваете в ответ:
Вы не могли бы мне рассказать на простом примере, в каком месте семантика оберона отличается от семантики любого другого статически-типизованного язык программирования?
Я говорю про экосистему, вы про семантику.
Вы правда хотели спросить именно это? Может Вас отвлекли на работе, я не знаю, но семантику с экосистемой перепутать. И так каждый раз, я вам про Ваню, а вы мне про баню.
Очень просто, правила хорошего тона от Макконнела применимы ко всем языкам с близкой семантикой и никак не зависит от экосистемы. Поэтому вопрос и задан про семантику. С целью показать применимость правил.
Или вы хотите сказать, что осмысленное именование переменных — это требование экосистемы?
Ну так напишите нам код и покажите какие в экосистеме оберона есть правила хорошего тона, идиомы, паттерны и чем они лучше тех, что знаем мы. А то вы уже совсем превратились в иллюстрацию поговорки «П@здеть — не мешки ворочать». Потратить столько времени на болтовню, вместо того чтобы код показать? Может вы вообще код писать не умеете, а?
Или вы хотите сказать, что осмысленное именование переменных — это требование экосистемы?
Ну так напишите нам код и покажите какие в экосистеме оберона есть правила хорошего тона, идиомы, паттерны и чем они лучше тех, что знаем мы. А то вы уже совсем превратились в иллюстрацию поговорки «П@здеть — не мешки ворочать». Потратить столько времени на болтовню, вместо того чтобы код показать? Может вы вообще код писать не умеете, а?
Мне не нравится код без форматирования в комментах. Форматирование отключают за минусовую карму => я не размещаю в комментах код (кроме исключительных случаев). Все просто. А еще мне лень ходить в gist, поэтому кода не будет.
У этого вашего аккаунта плюсовая карма.
Ну и почему вам тогда не лень писать комментарии?
Ну и почему вам тогда не лень писать комментарии?
Я правильно понимаю, что вы и kisybi — один человек?
Минуту. Я неоднокрано за последние пару дней видел заявления, что в Обероне вроде бы и форматировать код необязательно, он и так читается, и даже шрифт можно использовать пропорциональный, какое уж тут форматирование. Что именно я неправильно понял?
Вы все правильно поняли, но мне нравится вот так
а не вот так
вот так
а не вот так
не вот так
И что вам мешает? Карма в плюсе — разметка доступна.
В сумме — в глубоком минусе. И продолжает падать. Но вы не стесняйтесь. Вы же отказались беседовать там, где нет проблем с такими вещами. Значит вам тут хорошо. Как там в известной кричалке «Мы здесь власть».
«Там» — это где? В джаббере, которого у меня, например, нет уже года 3-4? Благодарю покорно.
И как в джаббере вообще форматиовать код, раз уж для вас форматирование кода столь важно, а в gist вам лень?
Ну и да, еще до ссылки на джаббер я признан абсолютно необъективным, так что зачем со мной вообще разговаривать?
И как в джаббере вообще форматиовать код, раз уж для вас форматирование кода столь важно, а в gist вам лень?
Ну и да, еще до ссылки на джаббер я признан абсолютно необъективным, так что зачем со мной вообще разговаривать?
Да, верхний первый вариант гораздо лучше. Именно так меня учили форматировать код на Паскале в школе и университете, и такой код я легко читаю, несмотря на несколько (сходных) операторов в одной строке и так далее.
Но ещё меня учили, что магические константы — зло, они должны быть объявлены как CONST и в выражениях должны присутствовать символьные имена. Я про ваши 22, 23, 24, 21, 20 — что это всё такое?
Здесь и моноширинный шрифт облегчил бы жизнь. Например, в конце два почти одинаковых выражения w := SHORT() и h := SHORT() — если в одном из них опечатка, её было бы гораздо легче видеть, потому, что визуально сравнивать две выровненных строки проще.
Непонятно, зачем писать area := h; area := area * scaleW; вместо просто area := h * scaleW; (и ещё дважды подобное встретилось ниже). Это как-то уменьшает вероятность ошибки? По мне так наоборот.
Но ещё меня учили, что магические константы — зло, они должны быть объявлены как CONST и в выражениях должны присутствовать символьные имена. Я про ваши 22, 23, 24, 21, 20 — что это всё такое?
Здесь и моноширинный шрифт облегчил бы жизнь. Например, в конце два почти одинаковых выражения w := SHORT() и h := SHORT() — если в одном из них опечатка, её было бы гораздо легче видеть, потому, что визуально сравнивать две выровненных строки проще.
Непонятно, зачем писать area := h; area := area * scaleW; вместо просто area := h * scaleW; (и ещё дважды подобное встретилось ниже). Это как-то уменьшает вероятность ошибки? По мне так наоборот.
Хабрахабр — не для клонов. НЛО будет блокировать виртуалов, их создателей и тех, кто об этом думает.habrahabr.ru/info/help/rules
Мое мнение, что Оберон был все-таки сделан «проще, чем нужно». В нем недостает ряда языковых конструкций из-за чего код на нем выглядит много хуже, чем аналогичный на Java/C# и никак не безопасней. Хотя конечно компилятор в 2000 строк — этим не каждый язык может похвастаться. Но я не считаю, что за простоту компилятора должен платить программист.
Также я не считаю, что за простоту реализации пользователького интерфейса системы должен платить конечный пользователь, который должен очень сильно постараться, чтобы тупо растянуть окошко как ему надо.
Также я не считаю, что за простоту реализации пользователького интерфейса системы должен платить конечный пользователь, который должен очень сильно постараться, чтобы тупо растянуть окошко как ему надо.
Вы просто луч света в этом тёмном царстве Оберона. Интересно, как это так получилось, что все эти адепты на вас ссылаются, но при этом пишут вещи, прямо противоположные тем, что читаем у вас?
Про качества языка — они утверждают, что Оберон — совершенство, но никак не
и foreach у них — лишняя конструкция, а по вашему мнению в нём
И рынок у них ничего не понимает, в то время как вы
Извините, что я так с наездом, но почему так? Почему все оберонщики не такие, как вы?
Про качества языка — они утверждают, что Оберон — совершенство, но никак не
Оберон был все-таки сделан «проще, чем нужно»
и foreach у них — лишняя конструкция, а по вашему мнению в нём
недостает ряда языковых конструкций из-за чего код на нем выглядит много хуже, чем аналогичный на Java/C# и никак не безопасней
И рынок у них ничего не понимает, в то время как вы
не считаю, что за простоту компилятора должен платить программист
не считаю, что за простоту реализации пользователького интерфейса системы должен платить конечный пользователь
Извините, что я так с наездом, но почему так? Почему все оберонщики не такие, как вы?
Divide et impera.
Еще valexey тоже оберонщик, который вам понравится.
Еще valexey тоже оберонщик, который вам понравится.
Очевидно же — все люди разные.
А этих фриков, сбежавших с ЛОРа, наверное, даже за людей не стоит считать.
А этих фриков, сбежавших с ЛОРа, наверное, даже за людей не стоит считать.
Продолжайте ваше интересное рассуждение.
Выглядит, как будто я «наткнулся на комментарий, написанное в котором мне нравится, и поэтому считаю его правильным». В общем, смысл исказился.
Люди разные, на самом деле об Обероне у меня нет своего мнения, но по итогам обсуждения именно высказанное pjBooms мнение мне кажется более близким к истине. Это был этакий крик души, «среди них есть нормальные люди!»
Люди разные, на самом деле об Обероне у меня нет своего мнения, но по итогам обсуждения именно высказанное pjBooms мнение мне кажется более близким к истине. Это был этакий крик души, «среди них есть нормальные люди!»
Охлократия предсказуемо сваливается в бытовой <небудуназывать>изм с привычным делением на людей и не-людей :)
Так вы ж первые начали с делением на тех кто «понимает оберон» и «джавистов с сишниками».
Вы же понимаете, что оберонщики не предлагали считать или не считать джавистов кем-либо, кроме джавистов (некоторые из них даже оберонщики), и Вы не сможете процитировать что либо в свою защиту.
Ошибаетесь. Срач начался примерно с момента лихого наскока сишников в стиле «си не пробовал, не мужЫк», крутой распальцовки на тему «от BEGIN вытекают глаза» и прочего ИТ-бабуинства. Это конформно, поэтому привлекает плюсы, а оппонентам сыплются минуса, показывая, кого хотят слушать, а кого нет.
Уже даже призыв не считать оберонщиков людьми в плюсе, а ответ в минусе, что как бы намекает на тенденции в сообществе.
Я понимаю, что минусуют дети, не изучавшие в школе даже циклы, а конструктивно общаться хотят совсем другие. Но что поделать, минуса выражают мнение сообщества в целом, а не отдельных людей.
Охлократия, она такая.
Уже даже призыв не считать оберонщиков людьми в плюсе, а ответ в минусе, что как бы намекает на тенденции в сообществе.
Я понимаю, что минусуют дети, не изучавшие в школе даже циклы, а конструктивно общаться хотят совсем другие. Но что поделать, минуса выражают мнение сообщества в целом, а не отдельных людей.
Охлократия, она такая.
Блин.
Ребят вы написали уже несколько десятков комментариев, а я так и недождался ответа на вопрос про семантику. Вот отсюда и минусы, потому что вместо конструктива начинает литься хамство.
Код давайте, бабуины.
Ребят вы написали уже несколько десятков комментариев, а я так и недождался ответа на вопрос про семантику. Вот отсюда и минусы, потому что вместо конструктива начинает литься хамство.
Код давайте, бабуины.
Уже даже призыв не считать оберонщиков людьми в плюсе
Не «оберонщиков», а конкретных фриков.
Как человек, сказавший «все понятно — вы на си и крестах не писали.» — habrahabr.ru/post/258391/#comment_8428583 — в топике про Rust, не могу промолчать.
«си не пробовал, не мужЫк» было сказано не мной — habrahabr.ru/post/258391/#comment_8428597, не надо передергивать.
Я вообще на эрланге пишу и не имею за плечами ни одного заметного проекта на С. Не надо приписывать мне чужих слов и смыслов, порожденных чужими комплексами.
«си не пробовал, не мужЫк» было сказано не мной — habrahabr.ru/post/258391/#comment_8428597, не надо передергивать.
Я вообще на эрланге пишу и не имею за плечами ни одного заметного проекта на С. Не надо приписывать мне чужих слов и смыслов, порожденных чужими комплексами.
Да просто не надо смотреть на внешние проявления, а «зрить в корень». Концептуально Оберон очень хорош, все концепции, которые в него вложил Вирт — правильные, начиная с «делай как можно проще, но не проще чем нужно». К сожалению в Обероне упор на первую часть этого знаменитого высказывания, но если этому принципу не следовать, то мы имеем горы этого ынтырпрайзного г… на, в которое запихивают все, что только можно. К примеру нам в саппорт недавно пожаловалась одна крупная американская компания (типо нашего 1С), у них приложение на 700M — судя по содержимому они туда запихали пол Мавена! Я вообще не понимаю, как у них там может что-то может ворочиться! К сожалению редкий ентерпрайз программист следует принципу «делай как можно проще». При этом принцип KISS (keep it simple, stupid) вполне такая мэйнстримовая методология программирования.
Или возьмем Обероновские модули. Важным их свойством является не только, что их можно динамически загружать, но и отгружать, а соответственно безболезненно перегружать!
Я тут недавно общался с одним своим хорошим знакомым ентерпрайзчиком, и он жаловался, что главная проблема Java сейчас — это hotswap — то есть перегрузка изменившихся классов в живом приложении. Она в ХотСпоте очень плохо работает, поэтому все развлекаются через JRebel, который тоже ни фига не работает. А в Обероне такой проблемы не было! Код любого модуля (кроме корневых) можно было на лету поменять! Поэтому там был реальный Live coding, который в промышленных системах есть только для языков с динамической типизацией, то есть за счет отказа от статической типизации, со всеми вытекающими. Во Обероне же строгая типизация!
Что-то подобное Оберновским модулям на Java можно реализовать, только если грузить каждый класс, отдельным загрузчиком. Что вообще говоря адский оверхед. Я кстати, так и сделал в своей попытке реализовать что-то подобное Оберон-системе на Java — github.com/pjBooms/The-Nothing-System. Но это конечно минимальный прототип, стоит в этом прототипе начать классам друг друга импортировать и начнется такой нехилый computer science, как выгрузить класс по середине циклических зависимостей (кто кстати хочет поразвлекаться и доказать тем самым, что Java рулит — добро пожаловать, жду pull реквесты).
В промышленном же виде для перегрузки модулей есть пока только OSGi (очень крупные модули), но на него все, просто реально все, матерятся кто имел дело в реальном продакшене!
И вообще в Обероне не было не live coding'a. Твоя программа и Оберон-система — это одно целое. Любое программирование в Оберон системе — это расширение системы. Нельзя было к примеру «запустить программу», можно было только расширить систему.
То есть ты всегда находишься в своей собственной программе и развиваешь ее. Эта концепция до промышленных программистов так и не дошла!
Или возьмем REPL, который так нравится Ruby/Python и прочим хипстер программистам. Концепция «команды» в Обероне, очень похожа, но (потенциально) гораздо более мощная, чем REPL. То есть это фактически это тот же REPL, только выполненные кусочки кода не исчезают в истории команд, а остаются там, где ты их написал, и ты их можешь в любой момент вызвать кликом мыши (отредактировав входные параметры, если что). На такой очень простой концепции можно вообще весь UI приложения в обычном текстовом редакторе набить (и UI в ранних версии Оберона, так собственно и был сделан).
Когда я в первый раз увидел Java, мне там все понравилось кроме одной вещи. В Оберон-системе в корне иерархии объекта, есть метод Handle, который принимает абстрактный Message. То есть любому объекту Оберон-системы (которые кстати спокойно все сериализовались), можно было послать любое сообщение и он мог его обработать или нет. То есть, вопрос какая объектная модель лучше Simula или Smalltalk там просто не стояла, были реализованы обе, и вся система асинхронна и event-driven по умолчанию.
Мне реально жаль, что в java.lang.Object нет метода handle.
Кроме того, в корне иерархии была возможность добавлять динамические атрибуты к объекту. То есть сам Оберон — со строгой типизацией, но элементы динамической типизации были встроены в базисные классы.
И в конце концов, я реально считаю, что GUI нужно рисовать в GUI builder, а не описывать в виде программного кода или на языке разметки. В Обероне GUI можно было только рисовать. То что в промышленном программировании до сих пор не сделали внятного GUI билдера, которым можно пользоваться — это позор! То что все трахаются с разметкой и Internet Explorer'ом — это дичайший фэйл промышленного программирования.
Короче, суть этой басни такова, что в промышленном мире программирования пока не найдено «золотое сечение». B Оберон система — это просто маленький пример, стоящий с обратной стороны, показывающий, что все может быть по другому, чем вы привыкли. Никто вас не заманивает в секту «царства Оберона» и не призывает начать программировать на Обероне. Но тем не менее, я считаю, что каждому будет полезно потрогать эту систему для общего развития, чтобы задуматься как те реально клевые фичи Оберона донести до мейнстрима и дотянуть до production quality. Чтобы вместе достичь гармонии и просветления :).
Или возьмем Обероновские модули. Важным их свойством является не только, что их можно динамически загружать, но и отгружать, а соответственно безболезненно перегружать!
Я тут недавно общался с одним своим хорошим знакомым ентерпрайзчиком, и он жаловался, что главная проблема Java сейчас — это hotswap — то есть перегрузка изменившихся классов в живом приложении. Она в ХотСпоте очень плохо работает, поэтому все развлекаются через JRebel, который тоже ни фига не работает. А в Обероне такой проблемы не было! Код любого модуля (кроме корневых) можно было на лету поменять! Поэтому там был реальный Live coding, который в промышленных системах есть только для языков с динамической типизацией, то есть за счет отказа от статической типизации, со всеми вытекающими. Во Обероне же строгая типизация!
Что-то подобное Оберновским модулям на Java можно реализовать, только если грузить каждый класс, отдельным загрузчиком. Что вообще говоря адский оверхед. Я кстати, так и сделал в своей попытке реализовать что-то подобное Оберон-системе на Java — github.com/pjBooms/The-Nothing-System. Но это конечно минимальный прототип, стоит в этом прототипе начать классам друг друга импортировать и начнется такой нехилый computer science, как выгрузить класс по середине циклических зависимостей (кто кстати хочет поразвлекаться и доказать тем самым, что Java рулит — добро пожаловать, жду pull реквесты).
В промышленном же виде для перегрузки модулей есть пока только OSGi (очень крупные модули), но на него все, просто реально все, матерятся кто имел дело в реальном продакшене!
И вообще в Обероне не было не live coding'a. Твоя программа и Оберон-система — это одно целое. Любое программирование в Оберон системе — это расширение системы. Нельзя было к примеру «запустить программу», можно было только расширить систему.
То есть ты всегда находишься в своей собственной программе и развиваешь ее. Эта концепция до промышленных программистов так и не дошла!
Или возьмем REPL, который так нравится Ruby/Python и прочим хипстер программистам. Концепция «команды» в Обероне, очень похожа, но (потенциально) гораздо более мощная, чем REPL. То есть это фактически это тот же REPL, только выполненные кусочки кода не исчезают в истории команд, а остаются там, где ты их написал, и ты их можешь в любой момент вызвать кликом мыши (отредактировав входные параметры, если что). На такой очень простой концепции можно вообще весь UI приложения в обычном текстовом редакторе набить (и UI в ранних версии Оберона, так собственно и был сделан).
Когда я в первый раз увидел Java, мне там все понравилось кроме одной вещи. В Оберон-системе в корне иерархии объекта, есть метод Handle, который принимает абстрактный Message. То есть любому объекту Оберон-системы (которые кстати спокойно все сериализовались), можно было послать любое сообщение и он мог его обработать или нет. То есть, вопрос какая объектная модель лучше Simula или Smalltalk там просто не стояла, были реализованы обе, и вся система асинхронна и event-driven по умолчанию.
Мне реально жаль, что в java.lang.Object нет метода handle.
Кроме того, в корне иерархии была возможность добавлять динамические атрибуты к объекту. То есть сам Оберон — со строгой типизацией, но элементы динамической типизации были встроены в базисные классы.
И в конце концов, я реально считаю, что GUI нужно рисовать в GUI builder, а не описывать в виде программного кода или на языке разметки. В Обероне GUI можно было только рисовать. То что в промышленном программировании до сих пор не сделали внятного GUI билдера, которым можно пользоваться — это позор! То что все трахаются с разметкой и Internet Explorer'ом — это дичайший фэйл промышленного программирования.
Короче, суть этой басни такова, что в промышленном мире программирования пока не найдено «золотое сечение». B Оберон система — это просто маленький пример, стоящий с обратной стороны, показывающий, что все может быть по другому, чем вы привыкли. Никто вас не заманивает в секту «царства Оберона» и не призывает начать программировать на Обероне. Но тем не менее, я считаю, что каждому будет полезно потрогать эту систему для общего развития, чтобы задуматься как те реально клевые фичи Оберона донести до мейнстрима и дотянуть до production quality. Чтобы вместе достичь гармонии и просветления :).
Спасибо! Возможно это лучший текст по Оберону на хабре! (Не думаете написать про него статью или цикл статей?)
Сразу появляется желание узнать больше (например как handle соотносится со статической типизацией).
С одним только не соглашусь: GUI builder. Когда я перешел с WinForms (рисование GUI) на WPF (декларативное описание GUI) мне показалось, что я попал из ада в рай. С тех пор я абсолютно уверен, что описание GUI может быть только декларативным и очень жалею, что JavaFX медленно развивается.
Сразу появляется желание узнать больше (например как handle соотносится со статической типизацией).
С одним только не соглашусь: GUI builder. Когда я перешел с WinForms (рисование GUI) на WPF (декларативное описание GUI) мне показалось, что я попал из ада в рай. С тех пор я абсолютно уверен, что описание GUI может быть только декларативным и очень жалею, что JavaFX медленно развивается.
WinForms — это описание UI программным кодом, а не рисование GUI. Конечно разметка — это большой шаг вперед, перед описанием GUI в программном коде. Под рисованием GUI, я имел в виду рисование в редакторе мышкой (как в Delphi). Дизайнером. Большинство GUI билдеров 90-х, нулевых как раз порождали программный код, что делало их практически бесполезными — как только код начинал модифицироваться руками, обратно в билдер он уже не всегда лез. Сейчас билдеры порождают текст на языке разметке (если для UI библиотеки есть язык разметки), что тоже шаг вперед (если не считать HTML, где из-за браузерного ада, UI билдеры не WYSIWIG, а значит не работают). В Обероне же GUI мог быть только нарисрован в редакторе и потом сохранен на диск по средством сериализации входящих в GUI объектов. Код к нему прицеплялся метасредствами (через тот же механизм команд). Сам GUI нельзя было редактировать программистами как исходный текст: GUI концептуально был просто документом, наподобие PSD. Любой GUI в Оберон-системе можно было начать в любой момент редактировать. Представляете, что вы сейчас берете какой-нибудь Фотошоп и удаляете из него половину того, что вам не нужно или добавляете ровно то что вам нужно простым движением мыши (плагины конечно есть много где, но это немного не то)? А в Обероне так можно было делать с любым гуем! Или представляете какой был бы ад дизайнерам, если бы они вместо того чтобы рисовать картинки в Фотошопе, сидели бы в тектовом редакторе и «размечали» бы свои картинки? Ровно это сейчас очень часто происходит в ГУЙ строительстве: есть специально обученные верстальщики, которые из дизайнерских макетов пытаются наверстать что-то похожее. Почему дизайнер сразу не может нарисовать GUI? Зачем нужен этот промежуточный слой верстальщиков с очень странными скилами?
В Обероне же GUI мог быть только нарисрован в редакторе и потом сохранен на диск по средством сериализации входящих в GUI объектов.
Это примерно WinForms и есть. Да, сохраняется это в некий файл с синтаксисом C#, но по факту туда обычно не лазят.
Что же касается «без верстальщика». Это сработает на простых формах, на которых роль верстальщика и так не существенна и не отнимает у разработчика много времени. На чем-то сложном это уже не срабатывает. Чтобы разметить даже банальную таблицу со сложным содержимым колонок дизайнеру бы пришлось знать слишком много условностей. В итоге за дизайнером придется переверстывать, то зачастую сложнее верстки с нуля.
Но есть еще и динамические формы, вид которых сильно зависит от отображаемых данных. Тут без возможности описания GUI из кода не обойтись. В том же WPF проделана великолепная работа, чтобы отсрочить страшный момент (всякие DataTemplate), но и там мне приходилось создавать GUI исключительно из кода (полная динамика GUI). И все это должно еще быстро работать даже с учетом всех новомодных эффектов (а без них никуда — не тот user experience, программа выпадает из общего стиля windows и теряет привлекательность).
На мой взгляд верстка от дизайнера — прекрасная, но совершенно нежизнеспособная абстракция.
>> дизайнеру бы пришлось знать слишком много условностей.
Вот это должно стать частью его профессии. Знать про всякие условности. Если вы на данный момент в силу разных обстоятельств знаете больше его, не означает, что он не может с этим справится.
>>Но есть еще и динамические формы, вид которых сильно зависит от отображаемых данных.
Разумеется динамику надо делать кодом. Здесь весь вопрос, что описывать кодом. Вы можете дать дизайнеру специальный layout manager, который будет расставлять контролы в зависимости от отображаемых данных, при этом спихнув на него стилизацию контролов, спец-эффекты и прочее. Или вообще изготовить отдельный контрол для данной предметной области предоставив дизайнеру необходимые ручки для того, чтобы он его сделал хорошо выглядящем.
Мой поинт в том, что программист не должен заниматься двиганием контролов на пискель вверх/вбок, следить за антиалиасингом, выравниванием и прочим. Он должен писать программы.
>>На мой взгляд верстка от дизайнера — прекрасная, но совершенно нежизнеспособная абстракция.
Может быть. По хорошему, надо за такими как вы внимательно последить, когда вы начинаете программировать GUI, чтобы понять, что из этого процесса от вас отделить, а что оставить. Короче, мне кажется, тут есть поле для исследований.
Вот это должно стать частью его профессии. Знать про всякие условности. Если вы на данный момент в силу разных обстоятельств знаете больше его, не означает, что он не может с этим справится.
>>Но есть еще и динамические формы, вид которых сильно зависит от отображаемых данных.
Разумеется динамику надо делать кодом. Здесь весь вопрос, что описывать кодом. Вы можете дать дизайнеру специальный layout manager, который будет расставлять контролы в зависимости от отображаемых данных, при этом спихнув на него стилизацию контролов, спец-эффекты и прочее. Или вообще изготовить отдельный контрол для данной предметной области предоставив дизайнеру необходимые ручки для того, чтобы он его сделал хорошо выглядящем.
Мой поинт в том, что программист не должен заниматься двиганием контролов на пискель вверх/вбок, следить за антиалиасингом, выравниванием и прочим. Он должен писать программы.
>>На мой взгляд верстка от дизайнера — прекрасная, но совершенно нежизнеспособная абстракция.
Может быть. По хорошему, надо за такими как вы внимательно последить, когда вы начинаете программировать GUI, чтобы понять, что из этого процесса от вас отделить, а что оставить. Короче, мне кажется, тут есть поле для исследований.
Спасибо за ваш комментарий.
Тем не менее, чем все это лучше Лиспа в котором все это уже было задолго до Оберона? И есть сейчас во вполне реальных коммерчесских проектах? Я про модули, live coding итд если что.
>И в конце концов, я реально считаю, что GUI нужно рисовать в GUI builder, а не описывать в виде программного кода или на языке разметки. В Обероне GUI можно было только рисовать.
Отдельный очень спорный вопрос.
Тем не менее, чем все это лучше Лиспа в котором все это уже было задолго до Оберона? И есть сейчас во вполне реальных коммерчесских проектах? Я про модули, live coding итд если что.
>И в конце концов, я реально считаю, что GUI нужно рисовать в GUI builder, а не описывать в виде программного кода или на языке разметки. В Обероне GUI можно было только рисовать.
Отдельный очень спорный вопрос.
Лисп как минимум не статически типизированный. И лично моё: при всей моей любви к SICP я физически не могу читать такое вложение скобочек.
Clojure — клевая, мне нравится. Но чистый ФП — это очень на любителя. Лучше, хуже — я про это не говорю.
Кстати в Clojure на JVM можно перегрузить модуль? Как это там делается? Интересны подробности
Кстати в Clojure на JVM можно перегрузить модуль? Как это там делается? Интересны подробности
Да, ровно так же как и в любом лиспе с динамическим рантаймом.
К комментарию retran добавлю, что можно ещё и java-модули средствами OSGi или любой другой модульной системы (например jboss modules).
Ну, у меня все же есть что возразить:
1) по поводу безболезненной перезагрузки модулей (то есть миграции например на новую версию модуля) — в Обероне она не безболезненная и можно словить в некоторых ситуациях трап (например когда модуль выгружен, но объекты типа который описан в данном модуле еще где-то в системе находятся и их кто-то дергает, или если процедурная переменная где-то сохранена и эту процедуру будут вот сейчас вызывать). То есть это не безболезненно.
Действительно безболезненно и по уму это сделано в erlang'e. То есть отличие в этом аспекте erlang'a от Оберона (оберон-системы, не языка конечно же) примерно как расстояние статически линкующегося Си до Оберон-системы.
Если вы еще erlang на эту тему не пробовали, очень советую попробовать. Посмотрите как там сделана версионность модулей например, и как происходит миграция с одного кода на другой прямо во время работы продакшн-системы.
2) В языке Оберон у RECORD'ов (ака объектов) нет базового типа (аля Object в java), следовательно там и никакого Handle нет и быть не может.
3) В языке Оберон (именно Оберон, а не Оберон-2) в принципе нет понятия методов (то есть связанных с типом процедур).
1) по поводу безболезненной перезагрузки модулей (то есть миграции например на новую версию модуля) — в Обероне она не безболезненная и можно словить в некоторых ситуациях трап (например когда модуль выгружен, но объекты типа который описан в данном модуле еще где-то в системе находятся и их кто-то дергает, или если процедурная переменная где-то сохранена и эту процедуру будут вот сейчас вызывать). То есть это не безболезненно.
Действительно безболезненно и по уму это сделано в erlang'e. То есть отличие в этом аспекте erlang'a от Оберона (оберон-системы, не языка конечно же) примерно как расстояние статически линкующегося Си до Оберон-системы.
Если вы еще erlang на эту тему не пробовали, очень советую попробовать. Посмотрите как там сделана версионность модулей например, и как происходит миграция с одного кода на другой прямо во время работы продакшн-системы.
2) В языке Оберон у RECORD'ов (ака объектов) нет базового типа (аля Object в java), следовательно там и никакого Handle нет и быть не может.
3) В языке Оберон (именно Оберон, а не Оберон-2) в принципе нет понятия методов (то есть связанных с типом процедур).
1) Ok, спасибо
2) В Обероне нет, в Оберон-системе корень был, от кторого все наследовались. Можно было не наследоваться, но это не приветствовалось. И у этого корня Handle был.
3) Да, все моделировали методы процедурными типами и полями объекта. Конечно, это больше похоже на function в JavaScript, но тем не менее все старались, чтобы это было похоже на методы. Лично я больше работал с Мифрилом, который был написан на Оберон-2, соответственно методы там были, и был метод Handlе. В Оберон систему я в основном лазил, чтобы подглядеть какую-нибудь идейку и реализовать ее в Мифрил.
2) В Обероне нет, в Оберон-системе корень был, от кторого все наследовались. Можно было не наследоваться, но это не приветствовалось. И у этого корня Handle был.
3) Да, все моделировали методы процедурными типами и полями объекта. Конечно, это больше похоже на function в JavaScript, но тем не менее все старались, чтобы это было похоже на методы. Лично я больше работал с Мифрилом, который был написан на Оберон-2, соответственно методы там были, и был метод Handlе. В Оберон систему я в основном лазил, чтобы подглядеть какую-нибудь идейку и реализовать ее в Мифрил.
В эрланге тоже не все так уж хорошо — levgem.livejournal.com/430319.html
и вот продолжение, я как-то упустил — levgem.livejournal.com/445158.html
В промышленном же виде для перегрузки модулей есть пока только OSGi (очень крупные модули), но на него все, просто реально все, матерятся кто имел дело в реальном продакшене!Это исключительно вопрос того, как народ их напилил. Сам по себе OSGi на уровне модулей описан в самом начале спеки и довольно прост, единицей импорта/экспорта является package, который может состоять и из маленького количества классов (как и рекомендуется). Как никто не мешает и в обероне делать крупные модули, так и в яве — никто не мешает делать мелкие модули. Оверхед на сборку и управление зависимостями будет и там, и там (например, при изменении api модуля).
А вот с динамической загрузкой-выгрузкой начинается развлечения, где уже играют сервисы, всякие extender'ы (как для spring dm и blueprint), что делает технологию более тяжелой и неповоротливой, к сожалению.
Задолго до Оберона концепцию программы как расширения среды презентовал Smalltalk. Но почему-то идея так и не прижилась. Может быть потому что размер «Блокнота» в таком варианте стремился к размеру «Офиса»? Эта концепция хороша в замкнутой экосистеме где среда фактически сливается с ОС и все программы только в ней и существуют. Но как отдельное приложение это не рационально и зачастую неудобно.
А недостатки динамической перезагрузки модулей в Java это не проблемы языка или архитектуры платформы, это проблемы реализации. Можно подумать в Обероне не к чему придраться…
А недостатки динамической перезагрузки модулей в Java это не проблемы языка или архитектуры платформы, это проблемы реализации. Можно подумать в Обероне не к чему придраться…
Да, конечно в Обероне, нет особо ничего нового, как собственно и в Java, кроме возможно лозунга «Делай как можно проще», который тоже в общем-то Эйнштейну принадлежал.
По поводу Smalltalk и Oberon есть одна довольно интересная история.
Известный факт, что Джобс стырил идею своего Мака у XEROX Parc, а потом уже Гейтс стырил у Джобса.
Так вот, мало кто знает, что после того как Джобс посетил XEROX Parc, туда наведался с дружественным визитом Вирт с Гуткнехтом и провели они там год в гостях. А кроме Smalltalk у XEROX тогда была еще система Cedar с языком Mesa. Гуй Оберона — это во многом калька с системы Cedar, а Mesa — это язык со статической типизацией, в отличии от Smalltalk (догадайтесь на что больше похож Оберон на Mesa или Smalltalk). Тогда в XEROX были реально два лагеря: одни за динамическую типизацию, другие за статическую, то есть этот современный срач по этому поводу тоже из XEROX перекочевал. Но все это XEROX хозяйство гонялось на мэйнфреймах и было жутко тяжеловесное.
И вот чудо: всем этим парням — Джобсу, Гейтсу и Вирту пришла практически одновременно в голову одна и та же идея: сделать что-то похожее на то, что есть у XEROX, но только для простых людей. А для этого им нужно было облегчить по максимуму все концепции от туда (упопсить). Лучше всего с задачей облегчения, как ни странно, справился Вирт, который сделал максимально легковесную систему, при этом ему удалось впитать лучшее из Mesa/Cedar и Smalltalk, и сохранить в лучшем виде дух этих систем. Но с задачей «упопсения», конечно намного лучше справились Джобс с Гейтсом, которые к тому моменту уже имели опыт промышленного программирования и бизнеса. Вирт же никогда бизнесом не занимался и production quality — это ниже его достоинства: для него главное концепт, а не обертка и качество реализации.
>>Может быть потому что размер «Блокнота» в таком варианте стремился к размеру «Офиса»?
А так сейчас в общем-то и делают! В десктопах очень популярна концепция RCP — Rich Client Platform (Eclipse RCP, Netbeans RCP). Там любой блокнот размером с Офис, при этом стартует этот блокнот, ой как не быстро! Здесь проблема, что проектировались Eclipse и Netbeans изначально без этой простой SmallTalk концепции в голове, а было бы большое счастье если бы эта концепция там была бы изначально, RCP программирование ой как бы облегчилось! Но опять же здесь есть проблема с отгрузкой в Java, без которой концепт нормально не работает.
>>А недостатки динамической перезагрузки модулей в Java это не проблемы языка или архитектуры платформы,
>>это проблемы реализации
Не согласен. В Java hotswap — это вообще опциональная фича для JVM, которая может быть, а может не быть и существует она там вообще только для отладки. Соответственно, как она может быть реализована в JVM не описано в спеке даже в общих чертах. А фича корневая, чтобы ее сделать по уму, однозначно надо менять JVM спецификацию, собирать лучшие умы JVM строения, JCP и прочее.
По поводу Smalltalk и Oberon есть одна довольно интересная история.
Известный факт, что Джобс стырил идею своего Мака у XEROX Parc, а потом уже Гейтс стырил у Джобса.
Так вот, мало кто знает, что после того как Джобс посетил XEROX Parc, туда наведался с дружественным визитом Вирт с Гуткнехтом и провели они там год в гостях. А кроме Smalltalk у XEROX тогда была еще система Cedar с языком Mesa. Гуй Оберона — это во многом калька с системы Cedar, а Mesa — это язык со статической типизацией, в отличии от Smalltalk (догадайтесь на что больше похож Оберон на Mesa или Smalltalk). Тогда в XEROX были реально два лагеря: одни за динамическую типизацию, другие за статическую, то есть этот современный срач по этому поводу тоже из XEROX перекочевал. Но все это XEROX хозяйство гонялось на мэйнфреймах и было жутко тяжеловесное.
И вот чудо: всем этим парням — Джобсу, Гейтсу и Вирту пришла практически одновременно в голову одна и та же идея: сделать что-то похожее на то, что есть у XEROX, но только для простых людей. А для этого им нужно было облегчить по максимуму все концепции от туда (упопсить). Лучше всего с задачей облегчения, как ни странно, справился Вирт, который сделал максимально легковесную систему, при этом ему удалось впитать лучшее из Mesa/Cedar и Smalltalk, и сохранить в лучшем виде дух этих систем. Но с задачей «упопсения», конечно намного лучше справились Джобс с Гейтсом, которые к тому моменту уже имели опыт промышленного программирования и бизнеса. Вирт же никогда бизнесом не занимался и production quality — это ниже его достоинства: для него главное концепт, а не обертка и качество реализации.
>>Может быть потому что размер «Блокнота» в таком варианте стремился к размеру «Офиса»?
А так сейчас в общем-то и делают! В десктопах очень популярна концепция RCP — Rich Client Platform (Eclipse RCP, Netbeans RCP). Там любой блокнот размером с Офис, при этом стартует этот блокнот, ой как не быстро! Здесь проблема, что проектировались Eclipse и Netbeans изначально без этой простой SmallTalk концепции в голове, а было бы большое счастье если бы эта концепция там была бы изначально, RCP программирование ой как бы облегчилось! Но опять же здесь есть проблема с отгрузкой в Java, без которой концепт нормально не работает.
>>А недостатки динамической перезагрузки модулей в Java это не проблемы языка или архитектуры платформы,
>>это проблемы реализации
Не согласен. В Java hotswap — это вообще опциональная фича для JVM, которая может быть, а может не быть и существует она там вообще только для отладки. Соответственно, как она может быть реализована в JVM не описано в спеке даже в общих чертах. А фича корневая, чтобы ее сделать по уму, однозначно надо менять JVM спецификацию, собирать лучшие умы JVM строения, JCP и прочее.
Айтишникам всего мира пора бы уже скинуться и поставить памятник в честь XEROX.
Есть подозрение, что этот прекрасный легковесный концепт Вирта останется легковесным, только оставась концептом. Если его развить до уровня бизнес-приложения, он во многом потеряет свою легковесность.
Так, скажем, есть куча прекрасных языков программирования (я имею ввиду промышленные), в том смысле, что сам по себе язык простой и понятный. Но как только мы доходим до реальных задач, начинает требоваться стандартная библиотека, и вот как бы она ни была хорошо написана — она не может быть легковесной, легко осваиваемой и так далее просто потому, что там очень много реализовано функций. И вместе с ней перестаёт быть легковесным и сам язык, этакой вот «механизм набора массы» а-ля Хиггс.
Так, скажем, есть куча прекрасных языков программирования (я имею ввиду промышленные), в том смысле, что сам по себе язык простой и понятный. Но как только мы доходим до реальных задач, начинает требоваться стандартная библиотека, и вот как бы она ни была хорошо написана — она не может быть легковесной, легко осваиваемой и так далее просто потому, что там очень много реализовано функций. И вместе с ней перестаёт быть легковесным и сам язык, этакой вот «механизм набора массы» а-ля Хиггс.
Но все это XEROX хозяйство гонялось на мэйнфреймах и было жутко тяжеловесное.
У XEROX Park было три лагеря: lisp, smalltalk, mesa. Cedar является результатом их совместной работы и консенсуса.
При этом lisp'овцы работали на мейнфреймах, а smalltalk и mesa, а в последствии и Cedar — это уже все было уже на персоналках (ака рабочих станциях).
То есть никаких мейнфреймов.
Согласен с предыдущим оратором, напишите, пожалуйста, нормальную статью про Оберон! А то реально эти корявые поделия, которые имеем сейчас, даже не намекают на то, что там может быть что-то интересное.
Чтобы продолжить неделю Оберона на Хабре? Можно попробовать, подумаю…
Хорошая идея, но сейчас вам начнут задвигать про оплату.
Ещё было бы хорошо определить, кто именно и как будет оценивать.
Можно, к примеру, взять на RosettaCode задачу, не реализованную на C# и Oberon. Не знаю, можно ли сделать пересечение подмножеств задач автоматически, поэтому так:
Tasks not implemented in C sharp
Tasks not implemented in Oberon-2
Ещё было бы хорошо определить, кто именно и как будет оценивать.
Можно, к примеру, взять на RosettaCode задачу, не реализованную на C# и Oberon. Не знаю, можно ли сделать пересечение подмножеств задач автоматически, поэтому так:
Tasks not implemented in C sharp
Tasks not implemented in Oberon-2
возьмем более-менее приличную по размеру задачу, и вы ее реализуете на Обероне
Они отказались привести код, который аналогичен двум или трем строчкам на Haskell, вряд ли можно ожидать что они постратят свое врем на приличную по размерам задачу.
Создаётся впечатление, что у оберонщиков это профессиональное. Другое обсуждение, другой человек, а формулировки всё те же.
Имхо, среди всех паскалеподобных языков наиболее перспективный, современный и несущий в себе много нового из других языков — это SPARK. В отличие от Оберона, этот язык имеет как и большую коммерческую ценность, так и большой кусок инноваций. Ну и в тренде увеличения «безопасности написания программ».
И его зелёнопоточная модификация Sparkel, которая среди зелёнопоточных языков программирования примечательна тем, что зелёные потоки создаются не только явно, но и неявно поперёк любой синтаксической конструкции, допускающей это. Вот только в текущей реализации я там не увидел библиотек для HTTP, а сам не готов тратить время на прикручивание, а так бы портировал некоторые скрипты с node.js.
Друзья и недруги, начиная с треда habrahabr.ru/company/flprog/blog/257611 комментарии и статьи про Оберон наполняли информационное пространство Хабрахабра. Разведка боем прошла успешно, а отрицательный результат — тоже результат.
Сейчас можно с уверенностью сказать, что по совокупности всех мнений, реакция на Оберон у сообщества отрицательная. В малой окрестности времени люди могут сказать, что это вина тупых школьников фанатиков адептов секты Вирта, которые ничего не понимают, не являются профессионалами и всё-всё говорят неверно и не истинно. Очевидно, такие абсолютные суждения имеют мало общего с реальностью и призваны в основном оправдать последствия своих необдуманных действий по откровенной травле инакомыслящих. Подробнее данные эффекты описывает статья «Обвинение жертвы» в Википедии.
Я в своем общении с оппонентами на этом и других ресурсах я часто сталкиваюсь с тем, что люди не стремятся понять других людей. Мало сомневаются в истинности своего высказывания. Часто нарушают правила приличий, скрыто или явно нарушая эмоциональное равновесие в беседе. Так, с какого-то момента мои комментарии на хабре оцениваются строго негативно. Из чего я делаю вывод, что мои слова не доходят до адресата. Я не склонен обвинять в этом кого-то лично.
Но я всё же настаиваю, что оппоненты раз за разом прилагали все усилия, чтобы понять меня не так как того хотелось бы мне. Возможно, их личные амбиции или призма профессионального восприятия мешала спокойно воспринимать информацию в моих комментариях. И это можно было бы преодолеть, но для этого мне не хватило бронересурса трех аккаунтов, даже с учетом того, что некоторые люди стремились поднимать мою карму хотя бы для сохранения возможности отвечать всем без ограничений. Спасибо им. Я не увидел попыток мирно, без оскорблений и передергиваний, без подмены контекста и ложных сравнений выяснить положительные и отрицательные стороны Оберон-парадигмы — любой найденный недостаток раздувался до вселенских масштабов, любое заявленное преимущество придавалось постмодернистскому сомнению.
В то же время, я заметил стабильный кластер пользователей, для которых негативная оценка Оберона раз за разом становилась опорной точкой рассуждений. Я считаю, что высказывания типа «Всем понятно, что Оберон примитивное говно, потому что там нет замыканий» хоть и имеют право на существование, ставят автора комментария и поддерживающих его людей вне рамок разумной беседы, являя собой пример примитивной манипуляции мнением наблюдателей. На эту тему в конференции xmpp:oberon@conference.jabber.ru даже существовал макрос у говорящего бота (написанного, кстати, на КП, одном из потомков Оберона), то есть эта тема стала мемом задолго до того, как хабражители в очередной раз его из себя породили. Это наводит меня на мысль о концептуальных различиях мировоззрения определенный слоев населения, занятых в ИТ-индустрии. Конечно, возможность преодоления этих различий зависит от обоюдного желания сторон.
Сторонники Оберона подвергались всем возможным нападкам, получали ответные комментарии с явным нарушением правил сообщества. Эти комментарии, даже самые бессмысленные колкости получали стабильные плюсы, что может сигнализировать о том, что деятельность по нападкам именно на сторонников Оберона была систематической. Да, действительно, есть некоторые участники на Хабре, с которыми мы пересекались ранее в других обстоятельствах, возможно конфликтных. Это стоит учитывать при оценке объективности их мнения, ведь люди известны своей неспособностью отделить личные отношения от профессиональной деятельности. Контролировать других участников дискуссии у нас возможности нет. Отдельный интерес представляют люди, которые знают Оберон и критикуют его с той или иной целью. Эти люди так же известны в Оберон-сообществе, их мнение может совпадать с мнением большинства и они будут получать одобрение, но к их словам стоит относиться внимательно, ведь они знают аргументы обеих сторон и говорят ровно то, что им нужно для одобрения.
Отдельные интересующиеся участники беседы возможно могли сформировать негативное отношение к теме после прочтения комментариев самых активных противников Оберона. Таким людям остается только порекомендовать сохранять бдительность и внимательно следить за подменой понятий и прочими уловками. В последующих статьях мы постараемся рассматривать Оберон с другой стороны, но личное отношение большинства к теме Оберона и к авторам не должно мешать восприятию статей.
Возможно, всё это неправда и я просто тупой школьник. Но тогда вы все тупое бездумное стадо и все эти обсуждения были только одним — войной за сохранение паритета мейнстрим-языков программирования и зарплат их фанатов и адептов.
Мир вам.
P.S. Заходите на конференцию Оберона, если не боитесь потерять свой кармабронежилет.
Сейчас можно с уверенностью сказать, что по совокупности всех мнений, реакция на Оберон у сообщества отрицательная. В малой окрестности времени люди могут сказать, что это вина тупых школьников фанатиков адептов секты Вирта, которые ничего не понимают, не являются профессионалами и всё-всё говорят неверно и не истинно. Очевидно, такие абсолютные суждения имеют мало общего с реальностью и призваны в основном оправдать последствия своих необдуманных действий по откровенной травле инакомыслящих. Подробнее данные эффекты описывает статья «Обвинение жертвы» в Википедии.
Я в своем общении с оппонентами на этом и других ресурсах я часто сталкиваюсь с тем, что люди не стремятся понять других людей. Мало сомневаются в истинности своего высказывания. Часто нарушают правила приличий, скрыто или явно нарушая эмоциональное равновесие в беседе. Так, с какого-то момента мои комментарии на хабре оцениваются строго негативно. Из чего я делаю вывод, что мои слова не доходят до адресата. Я не склонен обвинять в этом кого-то лично.
Но я всё же настаиваю, что оппоненты раз за разом прилагали все усилия, чтобы понять меня не так как того хотелось бы мне. Возможно, их личные амбиции или призма профессионального восприятия мешала спокойно воспринимать информацию в моих комментариях. И это можно было бы преодолеть, но для этого мне не хватило бронересурса трех аккаунтов, даже с учетом того, что некоторые люди стремились поднимать мою карму хотя бы для сохранения возможности отвечать всем без ограничений. Спасибо им. Я не увидел попыток мирно, без оскорблений и передергиваний, без подмены контекста и ложных сравнений выяснить положительные и отрицательные стороны Оберон-парадигмы — любой найденный недостаток раздувался до вселенских масштабов, любое заявленное преимущество придавалось постмодернистскому сомнению.
В то же время, я заметил стабильный кластер пользователей, для которых негативная оценка Оберона раз за разом становилась опорной точкой рассуждений. Я считаю, что высказывания типа «Всем понятно, что Оберон примитивное говно, потому что там нет замыканий» хоть и имеют право на существование, ставят автора комментария и поддерживающих его людей вне рамок разумной беседы, являя собой пример примитивной манипуляции мнением наблюдателей. На эту тему в конференции xmpp:oberon@conference.jabber.ru даже существовал макрос у говорящего бота (написанного, кстати, на КП, одном из потомков Оберона), то есть эта тема стала мемом задолго до того, как хабражители в очередной раз его из себя породили. Это наводит меня на мысль о концептуальных различиях мировоззрения определенный слоев населения, занятых в ИТ-индустрии. Конечно, возможность преодоления этих различий зависит от обоюдного желания сторон.
Сторонники Оберона подвергались всем возможным нападкам, получали ответные комментарии с явным нарушением правил сообщества. Эти комментарии, даже самые бессмысленные колкости получали стабильные плюсы, что может сигнализировать о том, что деятельность по нападкам именно на сторонников Оберона была систематической. Да, действительно, есть некоторые участники на Хабре, с которыми мы пересекались ранее в других обстоятельствах, возможно конфликтных. Это стоит учитывать при оценке объективности их мнения, ведь люди известны своей неспособностью отделить личные отношения от профессиональной деятельности. Контролировать других участников дискуссии у нас возможности нет. Отдельный интерес представляют люди, которые знают Оберон и критикуют его с той или иной целью. Эти люди так же известны в Оберон-сообществе, их мнение может совпадать с мнением большинства и они будут получать одобрение, но к их словам стоит относиться внимательно, ведь они знают аргументы обеих сторон и говорят ровно то, что им нужно для одобрения.
Отдельные интересующиеся участники беседы возможно могли сформировать негативное отношение к теме после прочтения комментариев самых активных противников Оберона. Таким людям остается только порекомендовать сохранять бдительность и внимательно следить за подменой понятий и прочими уловками. В последующих статьях мы постараемся рассматривать Оберон с другой стороны, но личное отношение большинства к теме Оберона и к авторам не должно мешать восприятию статей.
Возможно, всё это неправда и я просто тупой школьник. Но тогда вы все тупое бездумное стадо и все эти обсуждения были только одним — войной за сохранение паритета мейнстрим-языков программирования и зарплат их фанатов и адептов.
Мир вам.
P.S. Заходите на конференцию Оберона, если не боитесь потерять свой кармабронежилет.
войной за сохранение паритета мейнстрим-языков программирования и зарплат их фанатов и адептов.
Вы это серьезно, про зарплаты?
начиная с треда habrahabr.ru/company/flprog/blog/257611
Забавно, что в треде про Smalltalk в поведении пары пользователей из Оберон-сообщества видны все те же шаблоны (и даже выражения), в которых эти же пользователи впоследствии обвиняют своих оппонентов по дискуссиям про Оберон.
Все гораздо проще.
Оберон не предлагает чего-либо нового или интересного. Статическая типизация, близость к железу? Берите С. Горячая замена кода? Берите Эрланг или Смоллтолк. Какой аспект не возьми: всегда найдется язык, в котором это реализовано гораздо лучше.
При этом язык разработан человеком, который не работает в индустрии, и не понимает её потребностей. Да-да, человек, который пишет так, не в состоянии понять, что же нужно тысячам программистов, получающих за свой код зарплату. C, C++, Ruby, Erlang — они были созданы программистами для программистов, и они дают то, что нужно программистам. Кем написан Оберон? Ученым. Для кого? Точно не для программистов.
И тут появляетесь вы. Начинаете откровенно форсить язык, который слабее других, без каких-либо доказательств того, что он лучше или хотя бы представляет интерес. Огребаете совершенно заслуженные минусы. И тут же обвиняете людей в «систематических нападках». Не было никаких нападок, был унылый форсинг унылого языка и заслуженное противодействие.
Оберон не предлагает чего-либо нового или интересного. Статическая типизация, близость к железу? Берите С. Горячая замена кода? Берите Эрланг или Смоллтолк. Какой аспект не возьми: всегда найдется язык, в котором это реализовано гораздо лучше.
При этом язык разработан человеком, который не работает в индустрии, и не понимает её потребностей. Да-да, человек, который пишет так, не в состоянии понять, что же нужно тысячам программистов, получающих за свой код зарплату. C, C++, Ruby, Erlang — они были созданы программистами для программистов, и они дают то, что нужно программистам. Кем написан Оберон? Ученым. Для кого? Точно не для программистов.
И тут появляетесь вы. Начинаете откровенно форсить язык, который слабее других, без каких-либо доказательств того, что он лучше или хотя бы представляет интерес. Огребаете совершенно заслуженные минусы. И тут же обвиняете людей в «систематических нападках». Не было никаких нападок, был унылый форсинг унылого языка и заслуженное противодействие.
Вот вы и подтвердили мой тезис про обструкцию. Открытое признание всегда лучше скрытых увёрток :)
А то, понимаешь, «самоорганизующееся сообщество», «холакратия», куртуазное выканье с минусом за пазухой… Оказывается, всё гораздо проще — бабуины защищают поляну от посягательств со стороны.
А то, понимаешь, «самоорганизующееся сообщество», «холакратия», куртуазное выканье с минусом за пазухой… Оказывается, всё гораздо проще — бабуины защищают поляну от посягательств со стороны.
Вашими словами, «Вы видите что хотите увидеть». Вы как-то не приметили, что в настоящем же обсуждении есть положительные отзывы и просьбы написать нормальную статью о языке. Ваша слепота чрезвычайно избирательна, а речи шаблонны: «скобки, скобки, оберон, надёжность, школьники, охлос, моя карма, охлос, скобки, нападки, оберон». Мне аж захотелось облако слов сделать из комментариев — займусь на досуге.
Надеюсь, мы ещё увидим хорошие статьи о языке.
Прощайте.
Надеюсь, мы ещё увидим хорошие статьи о языке.
Прощайте.
Ну, если уж говорить о передёргиваниях и жертвах, то:
Апелляция к очевидности
Бревно в глазу
Избирательная слепота™
В прочих постах замечены пп. 1, 8, 10, 35, 51, 58 (например, про свойства оберона), 2, 3 (ответы на уточнения про свойства оберона), 5 (про быдломейнстрим и слепоту), 6 (про коллекции), 7, 23 (про свойства всяких языков), 9 (про коньяк и дурное дело), 12 (про чистый код), 13, 30, 55 (self-descriptive), 17, 53 (про успешную разведку), 26 (про достижения Вирта), 42 (про примеры кода) из кодекса правил демагога. </зануда-моде off>
Я знаю, что все хороши. Поэтому было много попыток прекратить демагогию и поговорить о конкретике, но вот что-то не заладилось-с. Остаётся только флеймить.
Очевидно, такие абсолютные суждения имеют мало общего с реальностью и призваны в основном оправдать последствия своих необдуманных действий по откровенной травле инакомыслящих
Апелляция к очевидности
я часто сталкиваюсь с тем, что люди не стремятся понять других людей. Мало сомневаются в истинности своего высказывания. Часто нарушают правила приличий, скрыто или явно нарушая эмоциональное равновесие в беседе
Бревно в глазу
Я не увидел попыток мирно, без оскорблений и передергиваний, без подмены контекста и ложных сравнений выяснить положительные и отрицательные стороны Оберон-парадигмы
Избирательная слепота™
В прочих постах замечены пп. 1, 8, 10, 35, 51, 58 (например, про свойства оберона), 2, 3 (ответы на уточнения про свойства оберона), 5 (про быдломейнстрим и слепоту), 6 (про коллекции), 7, 23 (про свойства всяких языков), 9 (про коньяк и дурное дело), 12 (про чистый код), 13, 30, 55 (self-descriptive), 17, 53 (про успешную разведку), 26 (про достижения Вирта), 42 (про примеры кода) из кодекса правил демагога. </зануда-моде off>
Я знаю, что все хороши. Поэтому было много попыток прекратить демагогию и поговорить о конкретике, но вот что-то не заладилось-с. Остаётся только флеймить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проект «Оберон 2013»