Оберон в образовании.

[valexey]

О простоте… Ну вот взять «Построение компиляторов» – книжка конечно замечательная для тех кто начинает разбираться в синтаксическом анализе и компиляторах вообще, но есть одно но – эта книжка, по сути описание построения эдакого слегка навороченного компиляторного Hello World'a. Ей ни в коем случае нельзя ограничиваться (если хочется реально быть не профаном в области компиляторов), иначем может сложиться ложное впечатление, что всё просто, а это не так. В результате, когда встанет реальная задача даже не компиляции, а просто парсинга языка с грамматикой чуть посложнее (а это почти любой язык, не обязательно программирования), человек зайдет в тупик.

Но как введение в компиляторы, книжка конечно замечательная.

[Илья Ермаков]

(Я начинал с Ахо, Ульмана - "драконьей книги" - и с Ульмана, Хопкрофта "Введение в теорию автоматов, языков и вычислений").

Речь-то не о профанации, а о простоте абстрагирующей, которая выделяет и фокусируется на самом существенном. А детали не отбрасываются, они просто вытесняются ниже, на специализированные уровни или вообще в "справочный уровень".

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

Вопрос выбора: тратить ли умственные силы на освоение и борьбу со сложностью, или тратить их на придумывание способа в очередной раз сложности избежать? Обычно затраты бывают сопоставимы. Но вот в будущем на сложное решение будут "тикать проценты", на простое - нет.

[valexey]

Можно и пример существенной и совершенно не решаемой ИТ-шниками по-нормальному задачи:
- организация персонального пространства работы с информацией для пользователя.
Всё, что наворачивают программёры, делается совершенно без понимания специфики умственной работы людей и того, как её надо поддерживать софтом.

А ещё программисты, очень плохо рисуют, моделируют одежду, вышивают крестиком и совсем безобразно кладут асфальт.

Программист НЕ ДОЛЖЕН планировать взаимодействие человека и машины. Также эту задачу ни в коем случае нельзя поручать дизайнерам. К сожалению это понимают очень и очень не многие. В большенстве контор это делают или программисты, или дизайнеры (сложно сказать в каком из случаев результат ужасней).

[Илья Ермаков]

Шикарный пример из области компиляции: для нормального модульного языка не нужна глобальная таблица имён, в таблицах имён не бывает много элементов. Поэтому применяется простой связный (максимум самоупорядочивающийся) список.
Все наработанные "потом и кровью" способы организации символьных таблиц (хоть на деревьях, хоть на хэшах), про которые столь много пишется в классических томах по компиляции, стали просто не нужны в задаче компиляции современного языка.

[Илья Ермаков]

А ещё программисты, очень плохо рисуют, моделируют одежду, вышивают крестиком и совсем безобразно кладут асфальт.

Программист НЕ ДОЛЖЕН планировать взаимодействие человека и машины.

Вопрос тонкий, да.
Но всё же: программист - очень общая сфера деятельности. Примерно сопоставимая с понятием "инженер-конструктор". Подмножество инженеров-конструкторов, которые конструируют не материальные, а программные системы.

Так вот. Мы же не считаем, что инженер-конструктор должен быть просто "сферическим конём в вакууме". Кораблестроитель всё знает о кораблях, авиаконструктор - о самолётах. Они ЗНАЮТ, как сделать хороший корабль, они анализируют потребности, а не ждут точной постановки задачи от моряков или лётчиков.

[valexey]

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

"Делить диф. уравнения на линейные и не линейные, всё равно что делить весь мир на бананы и не бананы".
Ты пробовал на Coco/R сгенерировать парсер для языка сложнее Оберона например? Впрочем, и с реальным Обероном (не тем который в oberon report'e, а тем который реально используется) там возникают проблемы. Приходится прибегать к хакам.

Теперь внимание вопрос – что лучше, использовать решение на Coco/R, обвешанное как новогодняя ёлка хаками, или же использовать решение на каком-нибудь Parsec'e без хаков?

[Geniepro]

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

Ох, ну давайте не будем впутывать сюда богословие-мировозрение. От этого только вред.
Конкретно в Вашем случае вред от этого в том, что Вы стали неправильно относиться к термину "монада" -- видимо, монадология Лейбница Вам мерещится...

[Илья Ермаков]

Ох, ну давайте не будем впутывать сюда богословие-мировозрение. От этого только вред.

Мировоззрение само собой впутывается, когда идёт речь об ответственности профессионала за свою деятельность. Что ж Вы хотите.
Понятно, что удобно и выгодно наслаждаться своей "креативностью", не думая об окружающих и о завтрашнем дне.

[valexey]

А ещё программисты, очень плохо рисуют, моделируют одежду, вышивают крестиком и совсем безобразно кладут асфальт.

Программист НЕ ДОЛЖЕН планировать взаимодействие человека и машины.

Вопрос тонкий, да.
Но всё же: программист - очень общая сфера деятельности. Примерно сопоставимая с понятием "инженер-конструктор". Подмножество инженеров-конструкторов, которые конструируют не материальные, а программные системы.

Так вот. Мы же не считаем, что инженер-конструктор должен быть просто "сферическим конём в вакууме". Кораблестроитель всё знает о кораблях, авиаконструктор - о самолётах. Они ЗНАЮТ, как сделать хороший корабль, они анализируют потребности, а не ждут точной постановки задачи от моряков или лётчиков.

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

C ПО в точности то же самое. Только вот в софт-индустрии пока не до конца сложились традиции и специализация/разделение ролей при построении оного софтверного продукта. Да даже классификация софт-продуктов ещё не устоялась, до сих пор новые типы появляются. (наврятли команда построившая хороший сухогруз быстро и качественно сможет построить военный истрибитель, а от программистов зачастую требуют именно этого, отсюда и беды)

[Илья Ермаков]

Ты пробовал на Coco/R сгенерировать парсер для языка сложнее Оберона например? Впрочем, и с реальным Обероном (не тем который в oberon report'e, а тем который реально используется) там возникают проблемы. Приходится прибегать к хакам.

Теперь внимание вопрос – что лучше, использовать решение на Coco/R, обвешанное как новогодняя ёлка хаками, или же использовать решение на каком-нибудь Parsec'e без хаков?

Нет, я руками писал обычно. И не имею широкого опыта в сфере компиляторов (только узкий, типа Рефала).
Да и просто не очень интересны мне компиляторы, работаю по middleware в основном.

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

[valexey]

Ещё один пример упрощения: считаю, что давно пора сокращать языковые поиски и идти дальше. Акцентироваться на архитектурах, компонентах, решениях времени выполнения... Взяв за языковую основу простую базу, а за способ программирования компонент - "тупой" подход объектно-ориентированных каркасов, а не всяких там специализаций этапа компиляции. Это диктуется простой логикой - любые изменения и эксперименты на уровне систем времени выполнения проводятся на порядок быстрее и дешевле, чем изменения на уровне языков.

Решения времени исполнения плохи тем. что они… Во время исполнения. Это снижает надежность. То что может быть проверено на этапе компиляции, должно быть проверено на этапе компиляции. Вообще я сейчас на ObjC пишу, потом как-нибудь отпишусь о впечатлениях, там оно как раз всё из себя трушно-оопшное, сплошная динамика (время исполнения, да) и прочие радости. Предварительный вердикт этой динамике -- в динамике много проще лепить костыли, поэтому динамика народу нравится.

Между прочим подавляющее большенство программистов языками не заморачиваются. Пишут на одном-двух языках и горя не знают. Например какой-нибудь VB. Или там тот же C++. Или 1С. И проблемой выбора языка не озадачиваются вообще. Спокойно сидят и лепят так всеми тут любимые горы мусора :-)

[igor]

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

Отсюда вывод: и разработчики сухогруза, и разработчики военного истребителя - сами должны быть хорошими программистами.

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

[valexey]

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

Отсюда вывод: и разработчики сухогруза, и разработчики военного истребителя - сами должны быть хорошими программистами.

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

ААА!!! Вы смешали оба примера :-)
Разработчик сухогруза (инженер) плохо построит истрибитель. Даже если там программисты вообще не нужны (они тут никоем боком вообще). И наоборот.

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

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

[Валерий Лаптев]

О простоте… Ну вот взять «Построение компиляторов» – книжка конечно замечательная для тех кто начинает разбираться в синтаксическом анализе и компиляторах вообще, но есть одно но – эта книжка, по сути описание построения эдакого слегка навороченного компиляторного Hello World'a. Ей ни в коем случае нельзя ограничиваться (если хочется реально быть не профаном в области компиляторов), иначем может сложиться ложное впечатление, что всё просто, а это не так. В результате, когда встанет реальная задача даже не компиляции, а просто парсинга языка с грамматикой чуть посложнее (а это почти любой язык, не обязательно программирования), человек зайдет в тупик.

Но как введение в компиляторы, книжка конечно замечательная.

Человек, который реально столкнется с задачей написания компилятора ИМХО обязан отличить введение от фундаментального труда. Если он этого не соображает, то нефиг ему за решение подобных задач браться - все равно не сделает...

[Валерий Лаптев]

Можно и пример существенной и совершенно не решаемой ИТ-шниками по-нормальному задачи:
- организация персонального пространства работы с информацией для пользователя.
Всё, что наворачивают программёры, делается совершенно без понимания специфики умственной работы людей и того, как её надо поддерживать софтом.

А ещё программисты, очень плохо рисуют, моделируют одежду, вышивают крестиком и совсем безобразно кладут асфальт.

Программист НЕ ДОЛЖЕН планировать взаимодействие человека и машины. Также эту задачу ни в коем случае нельзя поручать дизайнерам. К сожалению это понимают очень и очень не многие. В большинстве контор это делают или программисты, или дизайнеры (сложно сказать в каком из случаев результат ужасней).

1. Программисты и не такое умеют! Я рисовал очень хорошо - был факультетским художником. Вышивал крестиком еще в 3-м классе - получалось прекрасно. Вместо асфальта клали бетон - весьма неплохо. А теперь я собираю тумбочки, умею сготовить пожрать (например, пельмени - с нуля), могу делать ремонт квартиры, сантехники и электроприборов. Еще и на трех музыкальных инструментах играю. Моделировать одежду сам не пробовал, но моя сестра-программистка просто КЛАССНО это делает и зарабатывает себе на хлеб с маслом... Так что программеры - самый креативный народ в мире...
2. Кто должен планировать? Вообще-то мы тут сталкиваемся с беспрецедентной ситуацией. Ничего подобного ранее не было. И что имеем? Проецирование реализованных ранее подходов на экран: кнопочки, переключатели, списки для выбора и т.п. Даже Раскин - не очень  далеко ушел. А нужна НОВАЯ МЕТАФОРА.