Ответ на »сообщение 845« (учитель информатики)
___________________________

Присматриваюсь к Оберону. Хочется понять, почему простой язык мало используют. Это немного странно.

Действительно. Кажется странным. Если простой язык, то почему не притягивает, а отталкивает? А если притягивает, то почему это не выражается в чем-то осязаемом: распространении, количестве проектов, числе Оберон-программистов и т.п.?

Очень хороший вопрос. Вы зрите прямо в корень.

Постараюсь разбить свой ответ на две части. Краткую и развернутую. Начну с краткой. Развернутую приведу позже.

Простота формы не есть простота содержания. И в этом смысле язык Оберон совсем даже не прост. Очень не прост. Но простота формы нередко подчеркивает глубину содержания.

Сложность -- проще. Почему? Люди привыкли к готовым рецептам, сценариям (поведения, мышления). Мы консервативны по своей природе. А простота -- пугает. За ней либо пустота, либо такая глубина, что может захватить дух.

Прийти к простоте сложно. А чтобы понять "чужую" простоту, нужна огромная работа.

Разговор сосредоточился на возможности применения Оберона в образовании.
Это важная тема, и она полностью соответствует назначению форума "Информатика-21".
Вместе с тем, мы (временно?) потеряли форум "Мысли об Обероне".
Обсуждение языка (и Оберон-технологии в целом) тоже нужны.
ИМХО, именно отсутствие общего понимания Оберон-подхода воспрепятствовало (пока) созданию библиотеки: мы "выдохлись" на выборе варианта языка.
Соглашусь все же с Сергеем Перовским - Оберон не так прост, как кажется. :)
В одной книге (кажется, "Стили и методы программирования") наткнулся на понятие "призрака" - сущности, непосредственно не отображаемой с помощью ЯП, но необходимой для понимания программной системы.
Вот и хотелось бы поговорить о "призраках Оберона". :)
Частично все это обсуждалось.
Например, Руслан Богатырев писал о модульности, как о вероятном преимуществе Оберона перед современными языками, где модуль совпадает с классом.
Но хотелось бы большего.
Например, обсуждения отсутствующих в Обероне конструкций (тех же дженериков) и потенциальных достоинств и недостатков их включения в язык.
Возможно, не стоит все время оглядываться на Вирта?
Резюмирую сказанное: ИМХО, надо сделать доступным для обсуждения то, что обычно остается в наших дискуссиях невысказанным, скрытым (или принятым на веру).
Например, ведь не все согласны с необходимостью отдельной конструкции для модуля. Тот же Мейер, например. Почему? Хорошо бы разобраться.
Тогда, ИМХО, и с библиотекой не будет таких затруднений.
А то и правда для Оберона останется только одно применение - в образовании. :(

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

Значит, помогать им надо. Особенно в нашей сфере.

Присматриваюсь к Оберону. Хочется понять, почему простой язык мало используют. Это немного странно.

Лекция проф. Бертрана Мейера (ETH) в С.-Петербурге

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

---

28 марта 2006 г. профессор Бертран Мейер Ученым советом СПбГУ ИТМО избран Почетным доктором университета. На встрече 2 июня 2006 г. состоятся вручение докторского диплома и мантии, а также лекция профессора Б.Мейера.

2 июня 2005 года (пятница). В 285 аудитории Санкт-Петербургского государственного университета информационных технологий, механики и оптики состоится встреча с профессором Бертраном Мейером (Швейцария). Начало встречи в 15 часов. Приглашаются все желающие. Для прохода в университет из других университетов и организаций необходим паспорт.

Адрес: Кронверкский проспект, д. 49; вход со стороны Саблинской ул., проезд до станции метро Горьковская.

---

Профессор Бертран Мейер (Bertrand Meyer), один из авторитетнейших специалистов в области программирования в мире.

В 1974 г. закончил Политехническую школу (Ecole Polytechnic) в Париже. В этом же году получил степень магистра по Computer Science в Стэнфордском университете. Степень доктора получил в 1985 г. в университете Анри Пуанкаре (Нанси). С 1983 по 1986 гг. – приглашенный профессор в университете Калифорнии.
В 2003 г. Б. Мейер стал преемником Никлауса Вирта, сменив его на посту заведущего знаменитой кафедры Software Engeneering в швейцарском Eidgenoessische Technische Hochscshule (ETH) – в Высшей Политехнической школе в Цюрихе. Одновременно он возглавляет в ETH факультет Computer Science.
В 1985 г. он разработал язык Eiffel, который наиболее полно отразил концепцию объектно-ориентированного программирования. Под его руководством разработаны компиляторы для этого языка и объектно-ориентированная среда разработки программных проектов, доступная практически на всех платформах. В 2005 г. принят и опубликован международный стандарт этого языка.

В 1978 г. вышла (в соавторстве) первая книга Б. Мейера Методы программирования, переведенная в 1982 г. на русский язык. В 1988 г. Б. Мейер опубликовал книгу Object-Oriented Software Construction, переведенную на ряд иностранных языков. В книге, в частности, подробно описываются метод повышения надежности программных систем, названный «проектирование по контракту». В 1997 г. появилось второе издание этой книги, которое в 2005 г. было опубликовано на русском языке под названием Объектно-ориентированное конструирование программных систем.

Последние 25 лет на большинстве известных международных конференциях выступал в качестве приглашенного докладчика. Является издателем журнала Journal of Object Technology. За заслуги перед программистским сообществом в 2005 г. стал первым лауреатом премии Дала-Нигарда, учрежденной в честь создателей первого объектного языка программирования Simula.

Ответ на »сообщение 842« (Сергей Перовский)
___________________________

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

Это верно. Оберон может выделяться на фоне остальных языков как в computer science, так и в software engineering.

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

В программной инженерии Оберон -- это уже не язык программирования (даже не programming-in-a-large). Оберон-технология, включающая в себя наработанные Оберон-решения (а не просто язык), -- это фундамент, основа архитектуры больших систем. Как и на чем реализована Оберон-технология в конкретном проекте -- другой вопрос. Диктуется практической целесообразностью. Хоть на C. Это другое мышление, другое восприятие программных систем. Но вот это донести до людей очень сложно. Стереотипы и сиюминутность берут свое.

Ответ на »сообщение 841« (Руслан Богатырев)
___________________________
>>>Вчерашнего студента надо очень сильно переучивать. Он, как правило, имеет большие претензии на оплату и условия труда, не умея при этом ни работать в коллективе, ни заниматься промышленным программированием.
Сегодняшнего студента тоже приходится регулярно ставить на место :)
"Какой еще курс промышленного программирования, мы все тут крутые программисты"
"Ладно, к следующему разу напишите систему резирвирования авиабилетов"
"Так это много человеко месяцев работы"
"Так вас тут целый поток, так что у вас человеко год до следующего четверга, время пошло".
Я все о том же: Оберон проявляет свои качества на больших проектах. А для работы над большими проектами, даже учебными, нужно много других знаний и навыков, кроме языка программирования.

Ответ на »сообщение 840« (Сергей Перовский)
___________________________

Школьный учитель преподает вещи, освоенные им самим еще в школе. Он может сосредоточится на том, как эффективнее донести эти знания. Вот только результаты не радуют :(
Значит, помогать им надо. Особенно в нашей сфере.

Возвращаясь к Оберону, все таки это скорее инструмент для ВУЗов и, может быть, отдельных школ. В этом смысле он является "идеальной единой платформой для систематического преподавания основ программирования".
Я бы уточнил: для отдельных вузов и отдельных школ. Не надо замахиваться на все. Декларировать, конечно, можно. Но реально -- идти не революционным, а эволюционным путем.

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

С его освоения можно начинать готовить профессиональных программистов. А обучать ему КАЖДОГО человека, это все таки перебор.
Да, каждого -- явно противопоказано. Но с чего начинать готовить профессиональных программистов? Со школы? С вуза? И там, и там такая задача не ставится. Вчерашний школьник в компаниях не нужен. Вчерашнего студента надо очень сильно переучивать. Он, как правило, имеет большие претензии на оплату и условия труда, не умея при этом ни работать в коллективе, ни заниматься промышленным программированием.

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

С учетом претворения в жизнь наполеоновских планов захвата Россией большой доли (несколько миллиардов долл. в год) мирового рынка разработки заказного ПО и реалий современной экономики понадобится принципиально перестроить подготовку кадров. Так что рано или поздно (если брать перспективу в 5-10 лет) у нас появится достаточно приличное количество ПТУ, где будут готовить программистов. Называться они будут конечно иначе, не так обидно. Тренинг-центры или как-то еще. Но сути это не меняет. Индустрии все больше нужны дешевые рабочие руки. А слушатели нынешних краткосрочных ликбезных курсов ИТ-компаниям нужны в последнюю очередь. Все чаще можно слышать голоса относительно 1/2-летних курсов, где был бы технический английский и заточка под конкретную специализацию. Таких наши компании-лидеры в сфере разработки ПО готовы сразу брать в штат.

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

Ответ на »сообщение 833« (AK)
___________________________
>>>Просто имею опыт общения с преподавателями технических ВУЗов - они отзываются о педагогике с крайним пренебрежением. То, что человек достиг успеха в какой-либо области, не означает, что он автоматически хороший педагог. Для трансляции опыта нужно организовывать учебную деятельность согласно закономерностям дидактики. Но когда заниматься дидактикой тому же Дейкстре, например, если он занимается своей специализацией?
Одному Гуслейну Гуслее за то, что он понимает в болезнях, другому Гуслейну Гуслее за то, что он понимает в девушках (с).
Преподаватели ВУЗов имеют дело с гораздо более сложными предметами, чем школьные. Профессор - это человек, знающий что-либо лучше всех в мире. Для поддержания этого состояния требуется все его время. Можно поставить вместо него педагога, но результат будет хуже. Во всяком случае, я счастлив, что учился у профессиональных ученых, а не профессиональных педагогов.
Школьный учитель преподает вещи, освоенные им самим еще в школе. Он может сосредоточится на том, как эффективнее донести эти знания. Вот только результаты не радуют :(  Постоянно идут разговоры о перегруженности школьников. Объем знаний, необходимых человеку в современном мире растет, это понятно. А вот эффективность преподавания (результат усилий педагогов - теоретиков) за ним явно не успевает.
Возвращаясь к Оберону, все таки это скорее инструмент для ВУЗов и, может быть, отдельных школ. В этом смысле он является "идеальной единой платформой для систематического преподавания основ программирования". С его освоения можно начинать готовить профессиональных программистов. А обучать ему КАЖДОГО человека, это все таки перебор.

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

Развивая тему насчет Pow! и подъездных путей к Оберонам, можно прийти к следующему:

1. Сделать из Pow! основную точку знакомства с Оберонами на платформе Win32.
2. "Причесать" Pow! под две редакции (на русском языке): учебную (EE, Education Edition) и легкую (LE, Light Edition), сохраняя полную английскую с исходниками (FE, Full Edition).
3. За счет проектируемой стандартной библиотеки Оберона подготовить миграцию исходников с Оберон/Оберон-2 в Компонентный Паскаль.
4. Наладить магистральное направление миграции -- с Pow! в BlackBox и побочную ветвь -- с Pow! в XDS и в ETH Oberon.
5. Education Edition пополнить готовыми наборами задач (Шень и др.) с решениями на Обероне.

Pow! LE подавать как легкую Java -- очень компактная среда, простая установка, простая работа, простой ООП-язык, с которого легко перейти в Java через КП/BlackBox или напрямую.

P.S. Pow! создавался в университете Кеплера в Австрии под рук. проф. Мессенбека, автора языка Оберон-2.

Ответ на »сообщение 802« (Дмитрий)
___________________________

Неоднократно выплывал вопрос "Что делать?".

А Вы подсказали довольно интересную мысль. Проблема "последней мили" для Оберона известна. Есть те, кто хотел бы попробовать Оберон с минимальной головной болью. Кто хотел бы быстро и просто получить результат в виде понятного EXE или EXE с DLL.

Есть несколько рабочих инструментов:

1. ETH Oberon (целая ОС, надо изучать, терпения может не хватить)
2. BlackBox (очень своеобразна, нестандартна для большинства)
3. XDS (напоминает эпоху DOS, многим вообще не нужно высокое качество генерируемого объектного кода)
4. GPCP/Eclipse (это ж сначала ставить Eclipse, а потом ковыряться там с GPCP - долго)
5. JOB (нет IDE, командная строка, нужна Java)
6. OO2C (это ж еще требует целого GNU-хозяйства, да еще для Windows отдельные проблемы)

А что-то мы забыли про Pow! -- http://www.fim.uni-linz.ac.at/pow/Pow.htm
Попробуйте. Интересно мнение общественности. Если проблемный сборщик, так исходники есть -- можно поправить.

Сразу убивает нескольких зайцев.

1. Начальное знакомство с Обероном.
2. Интеграция с другими инструментами (достаточно прозрачная)
3. Нет заморочки на формат исходников -- обычный текстовый файл
4. Генерация EXE -- в лоб, размер маленький
5. Unicode -- проблема, но вроде вполне решаемая с приемлемыми затратами.

А уж после Pow! новичку можно заниматься конкретизацией/специализацией. Кому BlackBox, кому XDS, кому что еще.