Ответ на »сообщение 2507« (Руслан Богатырев)
___________________________
что, на Ваш взгляд, в решении на КП выглядит тяжеловатым, излишне изобилующим деталями, вызывающим желание переделать (спрятать детали реализации). Я весь внимание...
Странно что вы не заметили. Наш взгляд уже был показан...размером в 63 строчки. :))
И решение на КП на наш взгляд излишне изобилует жонглированием локальным состоянием чуть ли не в каждой строчке программы.
Я уже об этом говорил. Илья сказал что многокоратное присваивание перемеых там используется только в процедурах ввода/вывода но никак не в логике программы. Однако я привел пример 2 центральных процедур именно логики где эти переменные так и мелькают. Опровержения (может пока) не получил.

Ответ на »сообщение 2508« (AVC)
___________________________
Если уж, Jack, Вы на самом деле хотите увидеть разницу, то обратите внимание, что Java не поддерживает "старое доброе процедурное программирование".


Поддерживает, поддерживает. Все в одном файле "классе". Все процедуры видят все данные, которые задекларированны как поля одного класса "Программа"
К неудобству того что в начале программы обязательно надо писать class main - легко привыкается.

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


Вы меня не поняли AVC. Я о том и говорю. Не нужны ни ООП, ни модульность, ни компонентность.

<...>

ФЯ именно в обучении дают преимущество. В том плане что прививают грамотный подход НЕЗАВИСИМО от размера задачи. Прививают ПРИВЫЧКУ к декомпозиции, модуляризации, упрятыванию всего лишнего внутрь, взаимодействия через жесткие и скупые интерфейсы функций (входные параметры, выходные значения)


Это совсем другое дело. :)
Эта мысль действительно заслуживает обдумывания и обсуждения.
Если ФЯ на самом деле дают преимущество в обучении (хотелось бы получше разобраться в этом вопросе), то, конечно, постановка вопроса о ФЯ как первом (или хотя бы втором) языке программирования абсолютно обоснована.

Ответ на »сообщение 2508« (AVC)
___________________________
Естественно, что для игрушечных задач, для которых достаточно процедурного программирования, используется именно процедурное программирование.

Вы меня не поняли AVC. Я о том и говорю. Не нужны ни ООП, ни модульность, ни компонентность.
То есть решение Илья принял ВЕРНОЕ.
В этом и проблема. Для того чтобы понять пользу и необходимость всех этих механизмов нужно столкнуться с задачей довольно большого масштаба. Где ? Где столкнуться ? В школьном курсе ? Несерьезно. В реальной жизни ?
Кому ? Студентам у который программирование всего лишь факультативный предмет ?
Получается что вы меняете VB или java на оберон из самых лучших побуждений, а результат нулевой. Разницы никакой. Получается что все эти правильные и нужные механизмы не имеют никакой возможности развернуться и показать свою правильность и нужность ... в школьной среде.
Да ладно черт с ним с возможностью показать (и доказать) свою нужность и полезность.
Что хуже всего, что практика которую получают студенты, вот эти вот маленькие задачи в которых им приходится принимать ВЕРНОЕ решение НЕ использовать ничего из того чему их учили, доказывает им ()пусть и ложно) что МОЖНО обойтись без всего этого. Что это будет даже ЛЕГЧЕ и БЫСТРЕЕ и УДОБНЕЕ.
Таких ведь потом переделать гораздо труднее.

ФЯ именно в обучении дают преимущество. В том плане что прививают грамотный подход НЕЗАВИСИМО от размера задачи. Прививают ПРИВЫЧКУ к декомпозиции, модуляризации, упрятыванию всего лишнего внутрь, взаимодействия через жесткие и скупые интерфейсы функций (входные параметры, выходные значения)

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

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

Ни одного типа класса не описано. Никакой модульностью и не пахнет. Старое доброе процедурное программирование. А ведь это не новичек писал :))
Это писал человек продвигающий здесь "идеи оберона" которые вроде бы должны давать какую то разницу с дельфми или java. К сожалению в коде этой задачи разницы этой так и не обнаружилось.

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

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

А Руслан на радостях не разглядел :))

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

Но вот что интерено так это то что Руслан даже не подозревает что в устах этих профессоров "java" означает не конкретный язык а целое семейство языков, подход.
К этому семейству относятя и паскаль и оберон.

Да-да, а также Алгол-68, ПЛ/1, C++ и т.д. и т.п. Это надо еще умудриться всех поставить на одну доску. Что имели в виду американские профессора -- ведомо им одним. Я же привел их слова с целью привлечь внимание к тому факту, что наконец-то американцы прилюдно (опубликовано в центральном американском издании) начинают беспокоиться о том, что преподавание ИТ в сфере их высшего образования, мягко говоря, ущербно. Что не преподают они фундаментальные вещи, не дают  препарирование исполнения программы (ассемблер). А то, что они восстали против "Java", так это потому IMHO, что оскомину она уже в американских университетах всем набила. Любят они из одной крайности в другую бросаться. Но язык-то по сути ни при чем (Java или что другое). Надо просто владеть предметом программирования и уметь это владение донести до студенческой аудитории, а не учить языку (видимо, кто-то был не очень внимателен, читая мои сегодняшние сообщения, а жаль, я-то думал, что-то дойдет).

Ни одного типа класса не описано. Никакой модульностью и не пахнет. Старое доброе процедурное программирование. А ведь это не новичек писал :))
Это писал человек продвигающий здесь "идеи оберона" которые вроде бы должны давать какую то разницу с дельфми или java. К сожалению в коде этой задачи разницы этой так и не обнаружилось.

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

Руслан вот тут приводил слова некоторых американских преподов, по поводу того что преподавать студентам java это преступление. Полностью согласен с этим утверждением, сам не раз заявлял подобное.
Но вот что интерено так это то что Руслан даже не подозревает что в устах этих профессоров "java" означает не конкретный язык а целое семейство языков, подход.
К этому семейству относятя и паскаль и оберон.
Для того чтобы это осознать достаточно посмотреть на задачи, которые решают школьники и студенты. Задачи эти маленькие (может за исключением курсового проекта). И в задачах этих школьники, даже те кто 5-ки по программированию получил не используют ни ООП, ни модульность. По существу разницу между кодом одной и той же задачи написанной студентами на java, паскаль или оберон - под лупой не разглядишь.
Не верите мне ? Посмотрите на код олимпиадной задачи на обероне, приведенный здесь совсем недавно:
http://forum.oberoncore.ru/viewtopic.php?t=409

Ни одного типа класса не описано. Никакой модульностью и не пахнет. Старое доброе процедурное программирование. А ведь это не новичек писал :))
Это писал человек продвигающий здесь "идеи оберона" которые вроде бы должны давать какую то разницу с дельфми или java. К сожалению в коде этой задачи разницы этой так и не обнаружилось.

То есть в классе перед учителем, все такие умненькие, ООП там, модульность, "кластерно-модульное" программирование и все такое. Оценку получили, перешли к практике без надзирателя над головой, и вот уже отброшены в сторону все эти ненужные (да, без кавычек) навороты. И на том же самом обероне пишется код, ничем не отличающийся от кода ни visual basic :))

Так будет ли разница если перейти от java к оберону в обучении студентов ? Даже если и будет то только на словах, чтобы оценку получить. А на практике... ну вы видели :))

Будет ли разница если преподавать программирование на лиспе (схеме) или даже хаскеле ?
Несомненно. Причем даже на самых маленьких программах.

Именно это и имели в виду те американские преподы. Они показывали пальцем на MIT с его курсом SICP.
А Руслан на радостях не разглядел :))

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

Хорошо, если с ООП всё ясно, то какие же возможности ФП, не пересекающиеся в то же время с возможностями ИП и ООП (т.е. традиционно характерные именно для ФП), есть в Оберонах?
И насколько удобно и естественно для типичного оберонщика они реализованы?

Списки, кортежи, атомы представимы через "ссылочные" записи (порождаемые в динамике). Разница в том, что в Обероне "модели" собираются из конструктора, а в ФП -- готовые модели. Процедуры-функции, а также ссылки на функции (процедурные типы, процедурные поля, процедурные переменные) дают возможность выстраивать композицию. Ссылки, возможно, удобнее заменить на идентификаторы-строки (т.е. ввести регистрацию с фиксацией реального адреса процедуры с ее "именем"). Это основа, от которой можно отталкиваться. И для этого каких-то сверхусилий (вроде моего примера с имитацией динамических функций через сети Петри) не требуется. Все практически в лоб, без фокусов.

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

Мое глубокое убеждение, которое я вынес еще со времени проекта интеграции Модулы-2, Лиспа и Пролога 20-летней давности -- не надо все впихивать в один язык. Равно как и пытаться создавать межъязыковое взаимодействие вообще -- на все случаи и времена. Лучше выбрать базис языков в "ортогональных" парадигмах и наладить их взаимодействие через делегирование управления и обмен сущностями (не всеми, а пригодными для "экспорта-импорта"). Взаимодействие может быть достаточно глубокое -- вплоть до возможности автоматического расширения ран-тайма другими языками (как я делал в случае введения в Пролог-машину новых встроенных предикатов, реализованных на Модуле-2). В этой схеме централизация работы (выбор головного и вспомогательных языков) диктуется задачей/проектом и предпочтениями команды исполнителей.

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

Хорошо, если с ООП всё ясно, то какие же возможности ФП, не пересекающиеся в то же время с возможностями ИП и ООП (т.е. традиционно характерные именно для ФП), есть в Оберонах?

Уточняющий вопрос.
Насколько я понял, из крупных идей к ФП относятся:
1) отсутствие побочных эффектов и все возможные следствия этого факта;
2) принадлежность функций к числу объектов первого рода (лямбды и т.д.).
Не забыл ли я о чем-нибудь столь же существенном, как и эти два пункта?

>>>И насколько удобно и естественно для типичного оберонщика они реализованы?

Вы нам льстите.
Где Вы видели типичного оберонщика? ?)

Ответ на »сообщение 2501« (Руслан Богатырев)
___________________________

ИП в одеждах  МП (в контексте Оберонов) -- это объединение возможностей ФП и ООП (не всех, а существенных) без "жесткости" ограничений ФП и ООП.

Хорошо, если с ООП всё ясно, то какие же возможности ФП, не пересекающиеся в то же время с возможностями ИП и ООП (т.е. традиционно характерные именно для ФП), есть в Оберонах?
И насколько удобно и естественно для типичного оберонщика они реализованы?