Ответ на »сообщение 5795« (Jack Of Shadows)
___________________________

Ответ на »сообщение 5789« (Geo)
___________________________
Недооценивать новые преимущества, опасаясь новых недостатков - это обрекать себя на вымирание в худшем случае или вытеснение в лучшем.

Просто новые преимущества надо вводить наиболее экономным и компактным путём. А для этого надо семь раз отмерить. Чего в сумасшедшей гонке в индустрии мало у кого получается.
И посмотрите - сколько сменилось технологий у МС и кануло в лету, и никто про них уже и не вспомнит... Потому что вспоминать нечего (как тот же COM). А Оберон не только не стареет спустя 17 лет, но наоборот - даёт новые идеи и, несомненно, будет развиваться.

Ответ на »сообщение 5789« (Geo)
___________________________
Обычный меч тоже не теряет своих свойств от попадания в болото.

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

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

Оберонщики же панически боятся новых недостатков (как реальных так и надуманных), совершенно не обращая внимания на новые преимущества.

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

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

Ответ на »сообщение 5791« (Как слышно? Приём!)
___________________________
>>> Foreach неприятен в сложных случаях именно своей инкапсуляцией.
>>> Про 1..7 это лихо.
Вообще-то я хотел показать не то, как просто обойти список с помощью foreach, а то, как легко писать тот код, который будет применяться к каждому элементу.
А вот чтобы этот код было просто писать, необходимо некоторый вид лексического замыкания, либо функций высшего порядка.
Например, в Обероне нет ни того, ни другого, поэтому с помощью процедур foreach хоть сэмулировать и можно, но мороки с этим будет столько, что пользоваться этим никто не будет...

>>> Как всегда, простота примера создает сложность с восприятием проблемы.
>>> А вот если список это перечисление цветов, например, то не понятно:
>>> будет при foreach упомянут, скажем, фисташковый цвет.
>>> Что в списке? Each, а вот что "each" в это входит?
>>> Если список был введён рядом или он в голове - хорошо, а если он экспортируется извне?
А это смотря в каком языке. Вот в функциональных языках нет foreach, но зато можно написать map, которая делает тоже самое:

map f [] = []
map f (x:xs) = f x : map f xs

И где здесь огромная скрытая сложность?

Ответ на »сообщение 5791« (Как слышно? Приём!)
___________________________
>>>А вот если список это перечисление цветов, например, то не понятно: будет при foreach упомянут, скажем, фисташковый цвет.
>>> ...
>>> Если список был введён рядом или он в голове - хорошо, а если он экспортируется извне?
А зачем Вам знать, есть ли в полученном извне списке фисташковый цвет? Ваша задача -- обработать каждый элемент полученного списка определденным образом.

... Или список меняется в процессе работы программы.
Тогда each, это на какой момент each?
Другое дело, когда Вы работаете с программами в которых состояний нет ...

Ответ на »сообщение 5778« (AVC)
___________________________
>>> Начинайте всегда с нуля, идите до Count-1

Это называется борьба с избыточной сложностью :)

>>>Жалобно спрашивает "единичку вычитать?"

Вся заморока от того, что очень авторитетный дядя постановил считать с нуля,
а не с естественной единицы.
На самом деле естественным будет цикл от 1 до Count,
а вот индекс массива (увы!) надо уменьшать на 1 (respect to djadja).

FOR хорош естественным антициклином - там счётчик. Плюс простота восприятия.
Счётчик внутри цикла не должен быть writeble, в языках, где это иначе - ляп.

Foreach неприятен в сложных случаях именно своей инкапсуляцией.
Про 1..7 это лихо.
Как всегда, простота примера создает сложность с восприятием проблемы.
А вот если список это перечисление цветов, например, то не понятно:
будет при foreach упомянут, скажем, фисташковый цвет.
Что в списке? Each, а вот что "each" в это входит?
Если список был введён рядом или он в голове - хорошо, а если он экспортируется извне?

Ответ на »сообщение 5789« (Geo)
___________________________

Ответ на »сообщение 5785« (info21)
___________________________
>>> Избыточная сложность есть уязвимость
Дело за малым: определить понятие "избыточная сложность". Для этого, как я понимаю, нужно определить необходимую сложность. Определения пока в обсуждении не нашел.

Это моя вина.
Я хотел (и хочу) дать такое определение, но мысли разбегаются. :(
Конечно, относительно легко было бы дать определение сложности исходя из мер, предпринимаемых для борьбы с ней (divide et impera и т.д.).
Но цель была -- дать независимое определение, чтобы потом применять его для сравнительной оценки разных языков программирования и программистских методологий.

Ответ на »сообщение 5785« (info21)
___________________________
>>> Избыточная сложность есть уязвимость
Дело за малым: определить понятие "избыточная сложность". Для этого, как я понимаю, нужно определить необходимую сложность. Определения пока в обсуждении не нашел.

Обычный меч тоже не теряет своих свойств от попадания в болото.

Ответ на »сообщение 5771« (Jack Of Shadows)
___________________________

Ответ на »сообщение 5770« (Stargazer)
___________________________
Спросите у расстрелянных самураев.

Вы любите пример с самураями.
А вот другой пример - перед первой мировой войной считалось, что роль кавалерии будет сведена до роли "ездящей пехоты". Однако русские кавалерийские части (казаки и гвардия) получили столь хорошую выучку (с учётом ошибок Русско-японской армию перед новой войной подготовили безупречно), что постоянно атаковали конным строем - и побеждали. Атаковали пехоту в окопах, стреляющие батареи, на азиатском фронте - турецкую пехоту в гору по обледеневшему склону. И брали выучкой и духом.
В то же время ни одна армия Европы так и не провела ни одной успешной атаки в конном строю - части просто не были готовы к решению таких боевых задач.

Это к вопросу о роли обучения и возможности подготовить "миллионы спецназовцев". Вот с Хаскеллем, как и с С++, их точно не подготовишь, слишком инструмент сложен, учить придётся долго - и то досконального понимания и уверенности не будет.

Ответ на »сообщение 5777« (Jack Of Shadows)
___________________________

Ответ на »сообщение 5776« (AVC)
___________________________
В foreach все эти лишние, ненужные, не того уровня детали, упрятаны под капот.

И всё бы хорошо... Да вот берут его бедного - и прямо по капоту кувалдой... break-ом...