OberonCore

Библиотечная функция как средство повысить надежность (раз уж о ней зашла речь).

Еще один филолог. Ключевое слово должно быть коротким. Описание языка разъясняет все подробно.



И где ты там увидел "without exceptions"? Дальше, если тебе интересно, можешь во всех подробностях перевести слово "FOR" или слово "DO".

Ууууууу... Тяжело.

Форт - классный язык. Серьёзно. Вот только одна беда у него было в своё время. Стандарта не было.

Это язык обработки строк, предок Perl'а. Интересное отличие -- backtracking.

Это и все, что понимается под марковскими языками?

Vlad, по поводу "выпрыгивания" - дело в конечном счете не в нем самом, а в том, что для любого алгоритма посложнее линейного посика "выпрыгивание" является индикатором, лакмусовой бумажкой, что алгоритм выстроен неудачно. Если в процессе построения алгоритма вдруг нужен брейк - это сигнал к тому, чтобы еще раз все выверить и переписать. Прокрутив всю совокупность условий и инвариантов.
"Попрыгучий" алгоритм вообще не поддается формальному верификации. С другой стороны, формальная верификация вещь громоздкая и слабоприменимая задним числом; удобен именно формальный синтез, когда обоснование прокручивается в уме до написания кода. С третьей стороны, при формальном синтезе невозможно получить алгоритм с бреком. С какой стороны не верти - не нужен брейк в базовых циклах.
Вполне разумно в промышленном языке держать отдельную конструкцию с явным прерыванием, как в КП LOOP - EXIT - END. Однако нужна она крайне редко, преимущественно в сложном коде обработки системных событий и т.п. Мне лично понадобилась всего раза 4 на моей памяти...

Я бы Компутерре особо доверять не стал.
Они же никогда не слыхали про марковскую парадигму. Только про функциональную. Вот и приткнули. Впрочем, я тоже с Рефалом знаком только в воспоминании о докладе разработчика году в 82м в МГУ на семинаре по символической алгебре. В Белоруссии хотели процессор сделать. Мое воспоминание -- что там марковость заложена. И скорее всего, это синтетический язык.

Мало работают -- так новую парадигму себе в голову привить -- дело нетривиальное. Посмотрите вон на функциональную. Помню, что научиться строить алгоритмы для SCHOONSCHIPа было не вдруг.

Марковские цепи -- из математической статистики.
А тут "алгорифмы Маркова".
Марковых было больше одного.

Лакмусовая бумажка - это вложенные циклы и if'ы. Flat is better than nested (c) Tim Peters. Не говоря уже о вложенных циклах с невообразимыми условиями только для того, чтобы вовремя "выпрыгнуть".



У меня дежавю, что именно ты это уже говорил, а обосновать (применительно к break) не смог. Впрочем это не так важно. Сколько своих программ лично ты формально верифицировал (которые без break)? Если ноль, то практическая ценность возможности формальной верификации (даже если предположить, что она и проще для программы без break) стремится к нулю. А вот читаемость - вещь вполне осязаемая и непосредственно связанная с количеством допускаемых багов. И я тебе могу привести кучу примеров (начиная с пресловутого foreach), где break или return намного нагляднее и читабельнее флажков и т.п. в условиях циклов.

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

Я не пишу ни одного цикла, не прокрутив в уме его обоснование и совокупность условий на него. При таком стиле кодирования количество ошибок в алгоритмике стремится к нулю, а уверенность в надежности серьезно повышается. 70% циклов кода укладываются в несколько базовых алгоритмических схем с WHILE, вот причина держаться в этих рамках, вместо ваяния индивидуальных велосипедов с FOR-BREAK для каждого случая, пусть и более коротких.

Тем не менее, такой стиль не является формальной верификацией. И какое отношение к нему имеют break/return - не понятно (понятно только твое личное убеждение, что break/return тебе мешают).



Я тут еще подумал... Возможно такой стиль неявно диктуется отсутствием в языке аналогов finally и деструкторов. Отсюда параноидальное стремление иметь одну точку выхода из блока.

Кроме того, поскольку отсутствие локальных переменных все равно вынуждает тащить внутренности цикла "наверх", то и появление этих перемнных в условии цикла не кажется таким страшным.

Это статья самого автора Рефала
http://offline.computerra.ru/2001/402/10900/

Такой стиль называется формальным синтезом - т.к. сначала строится обоснование, а затем код. Дает тот же эффект, что верификация, но при этом не увеличивает время на кодирование (у меня при таком стиле написания выход кода ~2,5-3 тыс. строк за месяц, и то при не совсем полном рабочем дне. При этом код вообще не содержит ошибок, связанных с построением циклов.)

Наличие одного входа - одного выхода связано с тем же самым, код становится понимаемым и читаемым. Ничего не стоит понять те же пресловутые "вложенные циклы и ифы", когда действует правило одного выхода, и программист просто вынужден работать в рамках фиксированных алгоритмических схем. Если эти схемы знать, то каждый WHILE читается как единое целое, как будто тот же самый библиотечный вызов. А написание 90% кода превращается из "искусства", которое можно постичь только набиванием руки и опытом, в формальный процесс. У меня бывшие двоечники после месяца занятий сейчас самостоятельно выводят, к примеру, базовые алгоритмы сортировки (т.е. они получают только словесное описание принципа, без образца реализации) - с мелком на доске и сразу правильно, да еще и способны убедиться в этой правильности.

Ты можешь его называть как угодно, однако корректность программы он не гарантирует.



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



Неправда. Я видел такой код в ББ. Он ужасен



Фиксированные алгоритимические схемы - звучит круто. Однако я видел на что это похоже в коде



Опять неправда. Код уже приводился. WHILE выглядит как ненужный мусор, по сравнению с библиотечным вызовом.



Да-да, наколбасить 100 строк формального кода вместо 10 читабельных - это то, к чему должен стремиться каждый програмист.

Спор в конечном счете ни к чему не приведет.
Ты судишь по себе и по многолетней ПРИВЫЧКЕ алгоритмировать - и алгоритмировать определенным образом, отсюда субъективность оценок и сравнений. Когда уже прошел тернистый путь по всем граблям и сам не преподаешь, то чувство "что по сути хорошо, что по сути плохо" сильно притупляется.

Мне приходится еще и все время сталкиваться с образованием либо с ПО-лабателями провинциального уровня. И я вижу, что народ не умеет алгоритмировать вообще. Любой алгоритм сложнее простого полного прохода для них превращается в клепание методом подбора и долгое гоняние в отладчике с подгонкой-подклепкой кусков. И что показательно - наблюдая из-за плеча за ходом "работы", можно увидеть примерно одно и то же: сначала пишется FOR от начала до конца. Затем долго соображается, чё делать дальше. Потом лепятся кучи IF с выпрыгиванием BREAK-ом. Затем долгая ругань типа "ну почему оно опять работать не хочет". Затем - дежучер.
Тех, кого когда-то учили программировать по тому же Кушниренко, на основе строгих схем, сразу выделяет из толпы на порядок большая грамотность.

По поводу "примеров жуткого кода на ББ" - мы когда-то это обсуждали, про куски синт. разбора строк. Такова селяви, что обработка текста в императиве всегда выглядит коряво в любом языке, тут ничего не попишешь. На то и есть высокоуровневые библиотеки - для ББ есть и регулярные выражения, и разборщики Babel/Cocor, так что не проблема

Согласен с Ильей. Систематическое программирование привить важнее, чем манипуляции с компиляторами и оптимизацией.
А можно где-то это почитать в электронном виде? Всегда есть место для самосовершенстования.

У меня электронной версии нет. Про сами книжки обсуждалось в соседней ветки про исполнители...

Специально для Vlad.

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

Спасибо за внимание



В смысле написал его через foreach, например?



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



Поверь, что коллега (тем более старший), глухой к чужим аргументам и не способный доказать свою правоту, ему тоже не нужен (если только испытуемый не тот самый "тупой кодер"). Ты так и не предоставил аргументы за WHILE vs foreach.