Ответ на »сообщение 3633« (Руслан Богатырев)
___________________________
>>>но я за то, чтобы программист при этом мог всегда пойти самостоятельно, без костылей IDE (нет ее, сломалась, в "ремонте", сняли с производства и т.д. и т.п.).
Костыли как-то обидно и не очень адекватно...
Давайте заменим на автомобиль :)
Надо ежедневно тренироваться в беге - вдруг придется обойтись без машины (нет ее, сломалась, в "ремонте", сняли с производства и т.д. и т.п.)
Конечно полезно, кто спорит. Но скорости разные и навыки требуются разные.
Наивно сравнивать носильщика с водителем грузовика - может быть носильщик более "правильный" с теоретической точки зрения и более надежный, но перспектив в борьбе с автотранспортом не имеет.
Вот если рассуждать о постановке задачи, куда и что везти, то тут водила преимущества не имеет, в этом смысле Вы правы по поводу доски и мела.

Ответ на »сообщение 3632« (Сергей Перовский)
___________________________
>>>А вот модули в Дельфи скорее напоминают отделы одной организации.

Не всегда. Разве Вы не пользуетесь сторонними библитеками?

>>>И оформлять визу для визита в соседнюю комнату представляется безумным расточительством.

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

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

Модули в Обероне действительно напоминают независимые государства.
А вот модули в Дельфи скорее напоминают отделы одной организации.
И оформлять визу для визита в соседнюю комнату представляется безумным расточительством.

Верно подмечено. Это лишний раз говорит о том, что если язык поддерживает концепцию модуля, то совсем не значит, что он может быть вне всякого сомнения причислен к языкам МП. Модули модулям рознь. Причем (и это очень важно) даже не технологически, а концептуально. Вот мы нащупали совместными усилиями еще один источник недопонимания, построенного на ложных стереотипах (что модуль -- просто некое средство управления пространствами имен). В Обероне (Модуле-2) модуль -- основа основ, главный строительный материал. В том же Delphi (да и Haskell) -- это вспомогательная вещь. Поэтому ей и уделяется меньше внимания, меньше изучают, меньше теоретических познаний и опыта модульной композиции/декомпозиции, знания плюсов (и минусов!) работы с модулями. Есть и хорошо.

Модульную декомпозицию лучше разбирать на примерах (лучше даже заметных по значимости и масштабам программных проектов -- стоит по кирпичикам раскладывать и изучать устройство той же системы Oberon, благо и книги отличные есть, и все исходники, и она куда меньше UNIX). Не в системе дело -- это практически продолжение идей книг Д.Пойа, только с большей конкретикой в отношении МП. Помнится, писал в свое время популярную статью, где пробовал разобрать в деталях подходы к этому, используя в качестве иллюстрации Оберон-2: "Золотой треугольник" http://www.europrog.ru/paper/triangle.pdf

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

Что касается IDE, то их влияние на язык несомненно.
Если бы нам приходилось высекать исходный текст на камне, то ценились бы языки с наименьшим числом букв в программе.

Отчуждение -- вот ключевое здесь слово.

Я хотел обратить внимание на то, что "смычка города и деревни" -- языка и IDE -- приводит к проблемам с отчуждением (по территории, времени, обстановке, людям). Язык может быть жестко заспецифицирован (и зафиксирован во времени, как Оберон образца 1990 г.), а среда -- практически никогда (море документации и постоянные изменения приводят к тому, что каждому приходится самому выстраивать в голове свою "спецификацию" IDE). Если бы еще IDE было само по себе, это ничего, но оно пронизывает реализацию языка и опутывает программиста морем "удобств". Люди садятся на наркотическую иглу, сами этого подчас не замечая.

Хороший язык совсем не отвергает наличие хорошей среды. Не стоит думать, что сторонники Модулы-2 и Оберона -- эдакие аскеты по "бедности". Уж, слава Богу, в отношении TopSpeed-линейки и того же Clarion времен его технологического расцвета (после переноса на компиляторы TopSpeed и переписывании системы на Модулу-2) "звоночков" и "гудочков" было столько, сколько Delphi тогда и не снилось (да и сейчас, думаю, в некоторых моментах по-прежнему не снится). Но не было зависимости от среды, поскольку была другая школа и была реальная "поли-платформность". Это подталкивало к поиску своих подходов к технологической независимости от платформ и "чихов" производителей.

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

Лично я категорический противник переноса центра тяжести мышления на IDE вместо абстрактных моделей и языка. С той же Модулой-2 (Обероном) я могу работать в текстовом редакторе без какого-либо напряга и дискомфорта. Более того, раньше такая культура воспитывалась (было много разных архитектур, разных машин, разных ОС, а сейчас для большинства -- WintelAMDLinux). Лучшей начальной школой программирования для себя я считаю программирование на Паскале с мелом в руке у доски (в начале 1980-х были проблемы с доступом не то, что к ПК, а вообще к компиляторам Паскаля на мэйнфреймах и мини-компьютерах). При том, что те же Фортран и Си были много доступее, и практической работы (самостоятельной) на них было несоизмеримо больше. Мел и доска заставляют сначала думать, а потом делать. Сегодня это кажется дикостью. Но на самом деле в этом самоограничении огромная сила. А сегодня поколение школьников не знает, что такое логарифмическая линейка и не может производить несложные вычисления ни в уме, ни в столбик. Извините за резкость, но мы растим поколение интеллектуально ампутированных людей с надеждой на то, что костыли (разумеется, самые лучшие, круче даже, чем у твоего приятеля) их всегда выручат.

Я не против подсветки синтаксиса, не против всяких наворотов, облегчающих жизнь программиста, но я за то, чтобы программист при этом мог всегда пойти самостоятельно, без костылей IDE (нет ее, сломалась, в "ремонте", сняли с производства и т.д. и т.п.). Чтобы он ушел от наркотической зависимости. Именно поэтому меня не смущает выделение служебных слов в Обероне большими буквами, а также принудительный квалифицированный импорт. Более того, он существенно помогает. Когда Гуткнехт интересовался моим мнением по этому вопросу относительно нижнего регистра служебных слов в Zonnon (и не только у меня, просто ему хотелось принять взвешенное решение) -- категорически высказывал свое несогласие. Но у него перевесило желание быть поближе к мэйнстриму, что видно в общем-то и по раздутости Zonnon, хотя идеи там заложены интересные.

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

Ответ на »сообщение 3631« (Руслан Богатырев)
___________________________
Образ с визами очень показателен.
Модули в Обероне действительно напоминают независимые государства.
А вот модули в Дельфи скорее напоминают отделы одной организации.
И оформлять визу для визита в соседнюю комнату представляется безумным расточительством.
Может быть имело бы смысл иметь инструмент для выявления коллизий, хотя я ошибок, основанных на них не помню. Были пару раз проблемы с версиями модулей, пришлось в этом смысле несколько повысить дисциплину.
Дело опять таки в уровне сложности программ (не путать с уровнем сложности задач).
Что касается IDE, то их влияние на язык несомненно.
Если бы нам приходилось высекать исходный текст на камне, то ценились бы языки с наименьшим числом букв в программе.
При работе с бумагой, полезны указатели на номера страниц.
В текстовом редакторе потребуются указатели на модули(файлы).
IDE предоставляет в наше распряжение "гипертекст", где любой идентификатор является ссылкой на свое описание. Естественно, предпочтительный синтаксис языка будет другим.
Вы пытаетесь сравнивать синтаксис языков без учета этого фактора, что не совсем корректно.

Небольшое технологическое резюме по обсуждению, в которое оказались вовлечены три языка: Haskell, Delphi и Оберон (КП). Надеюсь, не очень вас запутаю :)

Камнем преткновения стал механизм импорта модулей. Напомню, что в языке Оберон допускается только (принудительно) т.н. квалифицирующий (лучше так, чем "квалифицированный") импорт (qualified import), который требует:
1. Обязательного указания импортируемого модуля в списке импорта.
2. Любое использование импортируемого идентификатора (сущности) всегда префиксировать именем соответствующего источника заимствования.

При этом существует средство синонимизации (алиасинг) модулей, когда в списке импорта можно устанавливать соответствие реального (внешнего) имени и используемого (внутреннего) имени. Эдакая "партийная кличка", псевдоним. Это позволяет:
1. Сокращать/изменять длинные и неудобные имена (с точки зрения автора импортирующего модуля).
2. Статически коммутировать разные реализации, соответствующие одному интерфейсу (чтобы переключиться статически на другой модуль, достаточно просто изменить реальное имя для соответствующего псевдонима).

В принципе и все.

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

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

Однако, практика использования языка и анализ самого Вирта и его коллег выявил проколы такой схемы неквалифицирующего импорта.

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

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

3. Для построения интеллектуальной линковки (smart linking, особенно в ней преуспела компания JPI/TopSpeed) как таковой помощи программиста в явном перечислении "виз" не требовалось. Автоматически проще разобраться с тем, что реально заимствуется, чем верить на слово программисту (хотя нюансы есть).

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

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

Ситуация с неквалифицирующим импортом в Haskell и др. языках (в отличие от Модулы-2) усугубляется еще и возможностью указания одного только имени модуля, без четкого перечисления заимствованных сущностей. Это приводит к понятийным проблемам при изучении чужого модуля в отрыве от исходной обстановки (нет других исходников, другие настройки среды, другая среда и т.п.). Информация потеряна. Этот случай и имел место при изучении мной варианта решения задачи ACM на Хаскеле.

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

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

P.S. Относительно возможных "улучшений" Оберона. Если немного пофантазировать, то можно обнаружить, что в принципе при заимствовании можно было бы ограничивать полномочия "приезжих" (импортируемых сущностей), например, для некоторых импортируемых переменных в данном модуле устанавливать ограничение на изменение (присваивание, т.е. как константы), для процедур -- на выставление на них ссылок (присваивание их имен процедурным переменным) и т.д. Это усложнило бы компилятор, хотя дало бы дополнительные средства "самоограничения" для управления сложностью создаваемых систем (на что и направлен Оберон). Идеальный вариант -- принудительно квалифицирующий импорт, но не просто с указанием в декларации IMPORT одного только имени импортируемого модуля, а еще и с приведением для него списка всех импортируемых из него сущностей и их режима использования в данном модуле (т.е. "визы" в полном виде: из какой страны прибывает,  рабочая виза, бизнес-виза, туристическая и т.п.). Сам список может составляться (жестко контролироваться) автоматически внешними средствами (системой программирования, IDE).

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

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

1. Непонимание/игнорирование некоторых технологических преимуществ Оберона.
2. Неприятие чужого опыта в случае отсутствия острой необходимости в нем в настоящем.
3. Восприятие представителей Оберон-сообщества как людей, навязывающих свои взгляды.

Первый пункт преодолевается не так просто -- понадобится убрать за скобки эмоции и сосредоточиться на конструктивном анализе средств языка программирования. Нужно что-то кому-то когда-то или не нужно -- вопрос следующего уровня по отношению к технологиям и их сопоставлению. Второй пункт понятен, непонятно только нежелание людей изучать и анализировать чужой опыт (мне была бы понятна реакция – "это точно лучше, но мне сейчас просто не нужно", но на пратике она выглядит совсем иначе). Причем опыт безусловно сильных команд (те же ETH Zurich и Xerox PARC) и мэтров программирования. Последний пункт (восприятие навязчивости) объясним не только излишней активностью сторонников Оберона (в самом деле, и чего им лезть со своим уставом в чужой монастырь): Оберон -- крайне неудобная вещь в современном мире. При всех своих недостатках (уж сколько раз о них говорено, как и о том, что это не серебряная пуля) он покушается на благополучие людей, которым выгодно работать на сложных языках, сросшихся со сложным инструментарием, и делать запутанные по своей сложности системы. Плыть по течению мэнйстрима, либо спонсируемых лидерами мэйнстрима побочных вещей. Языки, инструменты и системы стимулированы к постоянным правкам/модификациям, чтобы новыми сложностями/проблемами затмить предыдущие. Все это проистекает из понятных вещей: интеллектуальные и финансовые вложения программистов и компаний в познание/освоение сложностей порождает защитную реакцию своих "инвестиций", которая приводит к эффекту "голого короля" по Г.-Х.Андерсену. Будет время, перечитайте тьюринговскую лекцию Тони Хоара "Старые платья императора" (1980): http://www.europrog.ru/classics.html

Если средств языка недостаточно, как известно, подключаются "подпорки/костыли" в виде внешних средств системы программирования (СП, IDE). В этом случае можно обсуждать уже реализацию языка в рамках данной СП. Если кому-то не требуется нечто более совершенное, это не означает, что оно таковым (с его точки зрения) не является. Это означает, что у человека просто нет в этом потребности, либо что он не понимает важности данного технологического совершенства (никого не хочу обидеть, тот же Дейкстра не без язвительности говорил, что есть на свете вещи, которые ему постичь не дано -- это в отношении бесед с Хоаром в начале 1970-х о том, что такое ООП).

К сожалению, границу между языком и системой программирования (СП) многие давно перестали делать. Это печально. Важно разделять спецификацию (язык) и его конкретную реализацию.  Рынок привел к тому, что тем компаниям, которые зарабатывают на системах программирования, крайне выгодно постоянно изменять язык и саму СП. В противном случае очень трудно обеспечить себе выживание. На чем-то надо зарабатывать. Если источник доходов -- инструментарий, то он должен постоянно изменяться (совсем не обязательно совершенствоваться!), причем не с технологической точки зрения, а чтобы вынудить потребителя заплатить деньги за новую версию. Если компания полностью контролирует язык программирования (в данном случае речь о Borland и Delphi), то соблазн постоянных "новаций" ради извлечения прибыли очевиден. Если такие "новации" ведутся на протяжении четверти века, можно себе представить, во что они в результате выливаются. Не хочу, чтобы воспринимали эти слова в штыки. Просто думайте и рассуждайте. Для потребителей определенной защитой от такого произвола служит стабилизация языка программирования и отделение ее от реализации (СП). На это направлен  и процесс стандартизации (международной и национальной). Вирт предпочитал многолетнему труду "прозаседавшихся" в комитетах авторскую стандартизацию: язык закреплялся в течение первых 2-3 лет опытной эксплуатации, после чего изменения могли вноситься лишь путем создания нового языка, с новым именем, новым окружением и для новых задач.

Те, кто многие годы работает на Delphi, должен помнить историю и мотивацию ее появления. Если кратко: после выхода классического Паскаля (версии 1970 г. с ООП и 1972 г. без ООП) главным мотором продвижения Паскаля в массы стали американцы (система UCSD Pascal, ставшая одной из "штатных" операционок на IBM PC в первый год его выпуска). UCSD Pascal (группа проф. Кена Боулеса) был создан в отрыве от Модулы-2 и в основе его исполняющей среды лежали проработки P-машины ETH Zurich (Вирта его коллег).  Основные работы над UCSD Pascal шли в период 1974-1980 гг. Turbo Pascal появился как авторская разработка Андерса Хейльсберга, первоначально выполненная  для компьютера Nascom-2 (на базе Zilog Z80, компьютер вышел в декабре 1979 г.). Она называлась Blue Label Software Pascal. После встречи с основателем Borland Филиппом Каном (1986) Хейльсберг переписал компилятор для CP/M и MS-DOS, так появился Compas Pascal (затем и датский PolyPascal). Эта работа и была залицензирована и положена в оcнову Turbo Pascal. Таким образом появились два конкурента -- американская Borland и датская PolyData (вторую американцы довольно быстро задавили). Связующим звеном компаний был Нильс Йенсен (являвшийся вице-президентом Borland). Для красоты была придумана легенда относительно того, как проныра Кан был учеником Вирта (полная чушь, Вирт во избежание спекуляций на подобную тему специально размещал на своей странице список своих учеников -- а не просто слушателей).

Сама Borland (первоначальная, европейская) была основана в 1981 г. Нильсом Йенсеном, Оле Расмусеном и Могенсом Гладом (Niels Jensen, Ole Rasmussen, Mogens Glad) в Копенгагене. Американская Borland (после того, как Кан и датчане ударили по рукам) была образована в 1983 г. и ее первым флагманским продуктом был компилятор Хейльсберга, который стали затачивать под конкуренцию с UCSD (позаимствовав многие вещи). На этом Кан и решил наваривать деньги: ведь только-только появился IBM PC, где позиции Microsoft в области СП была невпечатляющими, а переиграть UCSD было делом посильным. Дальше шло в режиме "давай-давай". Вирт в 1979 г. уже подготовил отчуждаемую версию СП для Модулы-2 (для PDP-11 с ОС RT-11). Но в мир товаров народного потребления пробилась цепочка UCSD-Turbo, в основу которой закладывались коммерческие интересы, а не совершенство технологий. Это привело к серьезному конфликту между Каном и Йенсеном. Последний, возмущенный тем, что подготовленную к выпуску Turbo Modula-2 Филипп Кан запретил пускать на рынок (чтобы не забить Turbo Pascal), вышел из компании и основал JPI (Jensen & Partners International). Кое-что об этом я уже писал: http://www.osp.ru/pcworld/2001/04/161427/
Затем она была переименована в TopSpeed (с центром производства в Англии), где и была выпущена одна из лучших линеек компиляторов для процессоров семейства x86: Assembler, Modula-2, Pascal, C/C++, Ada (последний в плавание, по-моему, так и не вышел). Потом Брюс Баррингтон, борясь с Borland (Delphi) и Microsoft (Visual Basic), купил TopSpeed для своего Clarion, после чего все окончательно похоронилось (хотя жизнь Clarion с компилятором Modula-2 после отхода от дел Баррингтона еще теплится в SoftVelocity). Так американцы совместными усилиями похоронили идеи европейцев (кстати, соотечественников все того же Ганса Христиана Андерсена).

В 1995 г. Кан покинул Borland, а сама компания в тот же год взяла курс на полное сращивание языка со средой (СП). Главное было достичь такого уровня визуального программирования для связки UI + базы данных, чтобы победить Visual Basic. Но победить не удалось, хотя существенно потеснить -- да. Заодно и растоптать своей массой Clarion (PowerBuilder оказался поживучей).

Для тех, кто многие годы работал на Delphi, имеет смысл знать эту поучительную историю, равно как и историю работ Вирта и, сопоставляя, оценивать достижения с позиций мотивации (и компетентности) авторов и исполнителей. Единственным и главным достижением Delphi, на мой взгляд, было то, что он сумел сохранить в народных массах элементы Паскаль-культуры, хотя и поправ при этом исходные идеи во имя "золотого тельца". Вообще Паскаль (классический),  Модула-2 (классическая) и Оберон (классический) отражают интересную и плодотворную эволюцию идей Алгола-60.

Резюме. Тем, кто считает себя поклонником Паскаль-культуры, имеет смысл глубоко изучать всю эту линейку языков, включая виртовский Algol-W, а также причины размежевания с работами над Алгол-68 Дейкстры, Хоара и Вирта, а также "примкнувшего" к ним (отошедшего от них) Наура. Изучать, почему американская ветвь программирования задавила европейскую, поставив ее под свой контроль. Почему вместо обсуждения задач и подходов к ним, мы (что в образовании, что на производстве) все чаще вынуждены постоянно изучать и переизучать языки, растворившиеся в IDE, равно как и сами эти "костыли/подпорки". Почему, наконец, в области програмирования вовсю действует свой закон Мура: http://www.computer-museum.ru/histsoft/ober_esp.htm

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

Из личного опыта...
Очень удобно использовать WinAos для программирования под Bluebottle.
http://bluebottle.ethz.ch/winaos/
Я практически всё пишу в WinAos из-за удобства, периодически тестируя в Bluebottle.
В общем WinAos - система довольно адекватная соответствующим версиям Bluebottle.

Спасибо!
Я, к моему стыду, не знал про WinAos... :(

Из личного опыта...
Очень удобно использовать WinAos для программирования под Bluebottle.
http://bluebottle.ethz.ch/winaos/
Я практически всё пишу в WinAos из-за удобства, периодически тестируя в Bluebottle.
В общем WinAos - система довольно адекватная соответствующим версиям Bluebottle.
Замечаются некоторые особенности довольно редко...
Например, чуть по другому работает сеть через виндовские сокеты...
Функция AosUDP.Receive должна сразу (или с заданной задержкой в миллисекундах) возвращать результат (принятый пакет или ничего), а в WinAos останавливает выполение пока не прийдёт таки очередной пакет. С протоколом TCP тоже могут быть особенности.
Ну и взаимодействие с железом может быть проблематичным... Perfomance Monitor в WinAos не работает. WMPartitions туда же...
Всем успехов в программировании под Bluebottle!