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

Работает у нас в фирме студент Сережа, толковый парень. Он сказал, что не научился бы сам программировать, если бы начинал не с Бейсика, а с Оберона. (И это после того, как сам похвалил BlackBox за ПРОСТОТУ!)

Очень показательный случай. Чтобы понять, что Оберон отличается простотой, надо сначала накушаться сложности.

Как справедливо заметил Сергей Перовский, приверженцы Оберона по большей части знают не один язык программирования. Добавлю, что многие из них пришли к Оберону не напрямую через Паскаль -- Modula-2, а после работы с другими языками. Значит, дорожка ведет к Оберону от сложного к простому, к обобщению и абстрагированию.

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

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

Ответ на »сообщение 755« (Как слышно? Прием!)
___________________________

Да нет, сложность сама по себе кому она нужна?

Ну что Вы, есть те, кому это куда более интересно, нежели лаконичность и минимализм. Обратите внимание: в России в университетах (ННГУ и НГУ) интересен Zonnon, но не Оберон и не Компонентный Паскаль.

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

Кроме того, если нужно подготовить научную работу, конкурентноспособную на зарубежных конференциях, то Zonnon в .NET -- это смотрится, а какой-то Оберон в Win32 или Linux -- нет. При этом Zonnon может выступать и как объект исследований и как инструмент исследований. Это, конечно, если речь идет об ИТ-дисциплинах. Для других это не столь важно.

Если говорить о фрилансерах, то опять-таки Zonnon привлекает "крутизной", прежде всего, молодежь. Честно говоря, меня несколько озадачило количество обращений к материалам по Zonnon на сайте Oberon2005. А он там ходит в лидерах. Понятно, что компилятор сырой, что серьезные проекты делать на нем многие опасаются, но тянутся-то именно туда. Хотя очевидно, что язык совсем другой весовой категории, нежели Оберон.

Я про то, например, что помощь надо структурировать, выдавать
в первую очередь FAQ, определения, а не вываливать всё подряд.

Так это, пардон, не сложность языка. А справочная поддержка. Но здесь надо определиться. Если речь идет конкретно о Компонентном Паскале в BlackBox, то есть неплохая документация Oberon microsystems, которая переведена на русский язык. Появился хороший центр поддержки в лице Metasystems. Вопрос времени и выявления подобных потребностей.

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

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

1. Новая библиотека специально для BlackBox.
2. Библиотека для унификации в рамках Component Pascal (включая работу в BlackBox/Win32, BlackBox/Linux и GPCP/.NET, GPCP/JVM).
3. Унификация (миграция) среди языков Oberon(-2) и Component Pascal и соотв. систем программирования для разных платформ.

Элементарно схлопывание процедур в тексте. Разметка,
закладки и т.п. общеизвестные вещи.

Это пожелания к IDE. А насколько это критично? Как Вы себе примерно представляете нынешнюю аудиторию того же BlackBox (как я понял, о нем речь) в количественном выражении и насколько такие украшательства изменят ее в перспективе?

Что и правда всё равно?
И почему он один такой замечательный, что ему не нужна ни RAD ни IDE?
Или язык в свободном полёте - это и есть мифическая простота?

Хороший вопрос. Визуализация интерфейса -- широкое понятие, потому и решил уточнить. Если речь идет о совершенно стандартном современном интерфейсе IDE -- это одно. Если о визуальном программировании -- совсем другое. Для последнего случая роль языка реализации минимальна. И тогда непонятно, зачем нужен собственно Оберон. Если речь идет о приведении визуального интерфейса IDE к некоему привычному виду -- другое дело. Но здесь еще раз повторю свой вопрос о том, насколько именно это критично и может повлиять на количественное изменение аудитории.

Вон товарищ к лучшему тренеру по теннису ведёт дитя, а не в лапту играть. А почему школьники с Обероном должны получить жёваный мякиш в тряпочке?

Так давайте определимся: нужна хорошая IDE для детишек или IDE для взрослых дядей и тетей (это далеко не одно и то же)?

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

Вспоминается, с чего вообще началась здесь дискуссия. Речь шла о популярности/непопулярности Оберона. Рискую вызвать очередную бурю негодования, но все же спрошу: а зачем нужна Оберону популярность? Наверное, не ради популярности. Так для чего?

Ответ на »сообщение 752« (Руслан Богатырев)
___________________________
>>> Нужна сложность и крутизна?

Да нет, сложность сама по себе кому она нужна?
Я про то, например, что помощь надо структурировать, выдавать
в первую очередь FAQ, определения, а не вываливать всё подряд.
Библиотеки модулей организовать и даже скорее придумать чёткий
способ организации с жёсткими, а потому простыми правилами для всех
как компоненты в Дельфи. Больше работы с мышью, а не с клавиатурой.
Меньше работы с текстами, больше утилит, примочек, которые на себя
берут рутину. Элементарно схлопывание процедур в тексте. Разметка,
закладки и т.п. общеизвестные вещи. Всё то, что помогает и упрощает
работу за счёт собственной сложности.

>>> Не все ли равно, что будет подложено под визуализацию:
>>> Delphi, C++, C#, Java, Ada? И зачем здесь нужен Оберон?

Что и правда всё равно?
И почему он один такой замечательный, что ему не нужна ни RAD ни IDE?
Или язык в свободном полёте - это и есть мифическая простота?

Вон товарищ к лучшему тренеру по теннису ведёт дитя, а не в лапту играть.
А почему школьники с Обероном должны получить жёваный мякиш в тряпочке?
В Блекбоксе в тюториале у калькулятора нет кнопки "равно". Вот я и говорю -
небрежение к мелочам.

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

Судя по бурной истерике, которую закатили Ваши уважаемые оппоненты (в особенности ув. Руслан Богатырёв), Ваш вопрос попал в точку.

Забавно, что _ЭТИ_ люди действительно считают себя возвышенными интеллигентами и носителями Идей (возможно, несколько навязчивых) в серой среде программистского быдла.

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


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

Интересно, а что это за такие абстракции в языке Оберон, которые отсутствуют в Delphi и при этом сложны для школьника?

Ответ на »сообщение 750« (Как слышно? Прием!)
___________________________

Оберон будет популярен, когда станет СЛОЖНЫМ, обретёт инфраструктуру
и когда получит, прости Господи, интуитивно понятный визуальный интерфейс.


Нужна сложность и крутизна? Есть достаточно сложный Оберон. Называется Zonnon. Встроен в VS 2003 (по крайней мере, так заявлено для последней сборки от 14 апреля). Инфраструктура самая что ни на есть модная -- Microsoft .NET.

Насчет интуитивно понятного визуального интерфейса -- а какая роль в такой среде отводится собственно языку реализации? Не все ли равно, что будет подложено под визуализацию: Delphi, C++, C#, Java, Ada? И зачем здесь нужен Оберон?

Ответ на »сообщение 747« (AVC)
___________________________
>>>Неправильную хватку потом изменить трудно.
Поэтому Оберон прижился в университетах - там есть Тренер, которому слепо доверяют.
А посмотрите на теннисистов самоучек - никто из них "правильно" ракетку не держит, потому, что неудобно. Сколько не говори, что с таким хватом в мастера никогда не выйти, ему нужно сейчас выиграть у приятеля, а не через десять лет у первой ракетки мира.
Если человек не готов мыслить в абстракциях Оберона, для него это единообразие чуждо. Оно предназначено для обуздания сложности, а он с этой сложностью никогда не сталкивался.
Я поддерживаю продвижение Оберона в ВУЗах, на базе хорошей математической подготовки. Но в школе это можно сделать только при полной изоляции от других языков. Написать программульку на Питоне или Дельфи очень просто, зачем пыхтеть над Обероном.

Причина "непопулярности Оберона" в том, что имеет место быть следующее.

1. Недостаточное внимание к выразительным средствам, небрежение к "фенечкам".
А без притока новичков не будет дела. Одними гуру Беломорканал не выкопаешь :)
Посмотрите на скриншот разработчика трезвым взглядом. Зачем цветной монитор?
Можно чёрно-зелёный.

2. Компонентный Паскаль долго защищали от низкого "компонентокидания".
То, что составляет огромный плюс Дельфи (огромная база VCL) пока не грозит
Обер-семейству.

3. Язык в мифологии непропорционально выпирает над средой разработки.
В результате удачные находки из других сред здесь в зачаточном состоянии
и берутся с неохотой в силу табу.

Оберон будет популярен, когда станет СЛОЖНЫМ, обретёт инфраструктуру
и когда получит, прости Господи, интуитивно понятный визуальный интерфейс.

PS
По обеим ссылкам "Сервер не найден".

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

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

Рекомендую взглянуть на работы по этому направлению небезызвестного австралийского QUT, где развивают Component Pascal: http://plas.fit.qut.edu.au/generics/

А заодно -- на Functional Mini Component Pascal (FMCP). http://plas.fit.qut.edu.au/generics/mcp/Default.aspx

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


1. Брендинг

Бренд Oberon (Оберон) оказывается помощнее других (BlackBox, Компонентный Паскаль, Bluebottle, Zonnon) и наиболее точно отражает само технологическое направление, заложенное Виртом и его коллегами. Следовательно, продвигать и развивать все направление разумнее под единым мощным брендом, который надо еще формировать.


2. Позиционирование языка

В действительности под маркой Оберона объединяются несколько языков, из которых можно выделить Oberon, Oberon-2, Component Pascal, Active Oberon и Zonnon. Из них наиболее активно используется сейчас Component Pascal (в рамках BlackBox). Этот диалект Оберона создавался в Oberon microsystems как ответ на выход Java и представлял собой ревизию канонического Оберона Никлауса Вирта применительно к возможностям промышленного применения. История создания Оберона, появление и роль Component Pascal дают основание позиционировать язык как Java light (по аналогии с Coca-Cola light), т.е. как особую облегченную версию языка Java.


3. Целевая аудитория

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

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

Так сложились обстоятельства, что в отношении Оберонов фрилансеры оказались "вне игры", тогда как именно здесь и кроются основные ресурсы развития. Дальнейшие рассуждения ориентируются именно на эту аудиторию.



С учетом опыта ранее предпринятых шагов по продвижению Оберонов в России можно дать такие рекомендации:


A. Отказ от прямого противостояния с конкурентами

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


B. Отказ от продвижения Оберонов как языков промышленного программирования

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



Итак, если рассматривать ставку на Java-сближение Оберонов, то видятся такие возможности:

1. Оберон (Component Pascal) как язык проще Java, функционально эквивалентен и может быть использован для быстрого макетирования.

2. Оберон за счет своего дизайна и продуманного симбиоза средств модульного и объектно-ориентированного программирования позволяет управлять сложностью целевого софта лучше своих конкурентов, при этом он не посягает на роль и место Java, являясь полезным дополнением.

3. Оберон имеет реализации (разные по качеству и особенностям применения), позволяющие его прямое использование в Java-среде (GPCP Plugin for Eclipse, Canterbury Oberon-2, JOB). Из них наиболее перспективным является GPCP и продвижение в Eclipse.

4. При ставке на сближение с миром Java и ориентации на макетирование основными инструментами в Win32 и Linux остаются BlackBox, XDS и OO2C. При этом BlackBox имеет преимущества при использовании в качестве средства быстрого макетирования, XDS -- при доведении (оптимизации макета), OO2C – при необходимости кросс-разработки и погружения целевого софта в чужеродные среды (за счет трансляции в ANSI C). Одним из ключевых моментов такого подхода является унификация работы с Component Pascal в BlackBox и GPCP.

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


Что касается Bluebottle и Zonnon -- это исследовательские работы, которые при определенных условиях могут быть использованы в реальной практике. Однако, скорее всего, они полезны с точки зрения продвижения Оберонов как яркие работы, способные захватить (но не удержать) первичный интерес аудитории.

Как известно, одним из привлекательных аспектов софта является его альтернативность. Если он позиционируется как альтернатива (особенно одиозным, мусоленным-перемусоленным инструментам), то это создает предпосылки для возникновения у массовой аудитории первичного интереса, который далее необходимо закреплять. Самое опасное здесь -- обман ожиданий. Быстрое макетирование и позиционирование Оберонов как языков класса Java light позволяет свести такую опасность к минимуму.

Паскалевская природа Оберонов -- дополнительный аргумент для тех, кто вынужден в силу сложившейся ситуации с Borland искать альтернативу Delphi, в том числе и в мире Java.

Основное для Оберонов -- это контроль над сложностью. В этом их главное достоинство. Это и надо прежде всего в них выделять.