Ответ на »сообщение 854« (Андрей Хохлов)
___________________________

А так ли все просто? Если есль работающая система и в ней существуют экземпляры какого-то класса, как его перезагрузить не нарушив работу системы?

Конечно не просто. Естественно перед тем как выгрузить модуль нужно выгрузить всех его клиентов (в широком смысле).

скажем в Java-реализации (класс~модуль)

Class - это не модуль. Не буду ничего доказывать ибо надоело, просто приведу пример. Пусть есть два класса А и Б, и они друг с другом тесно связаны (например, объект класса А агрегирует объекты класса Б и, наоборот, объект класса Б агрегирует объекты класса А). Загрузить и выгрузить можно только оба класса А и Б одновременно, но не по очереди. Следовательно модулем является некая сущность являющаяся объединением классов А и Б, но не каждый из них по отдельности.

Здесь было много разговоров по поводу IDE и назывались BlackBox, XDS и Pow!. Но это ли самое главное? Тот же Вирт (давно конечно, персоналок тогда не было) использовал всего лишь Pascal-P, который в отличие от BB не был черным ящиком.
В консоли и make ничего плохого нет и они могут быть проще иной IDE, просто надо объяснить что есть что (может даже и в JCL можно разобраться, мне правда когда это было нужно не удалось). Я не против IDE, но всем перечисленным предпочел бы обычный редактор и строчный компилятор.

И второе. Правильно ли начинать обучение с языка высокого уровня? Все-таки машина исполняет код, а ЯВУ это уже абстракция и не факт что очень простая. Не есть ли более естественна последовательность код-ассемблер-ЯВУ? Это не значит, что надо долго задерживаться на первых двух уровнях (это мало кому понадобится), но написать "Hello, World!" несложно на любом из них.

P.S. Насчет кода - это мой домысел. Я никогда не преподавал. Однажды такое предложение было, но в силу очевидных причин я отказался.

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

Ответ на »сообщение 851« (Сергей Губанов)
___________________________
>>>Модули для того и нужны, что их можно динамически из программной системы выгружать/перезагружать.

Если бы модули были нужны только для этого, их бы не было ни в Модуле, ни в Аде,  ни в сотне других языков.

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

Ответ на »сообщение 851« (Сергей Губанов)


Да потому что не все пишут программные системы.
Модули для того и нужны, что их можно динамически из программной системы выгружать/перезагружать.
Классы/типы выгрузить/перезагрузить нельзя, а модули можно.
Тем кто пишет монолитные программы ничего динамически выгружать/перезагружать не надо, вот им модули не нужны.


А так ли все просто? Если есль работающая система и в ней существуют экземпляры какого-то класса, как его перезагрузить не нарушив работу системы?

Здесь могу ошибиться но такое впечатление, что в эталонной реализации J2EE (Sun One App Server) замена компонентов (EJB или сервлетов) на ходу выполняется, но это нарушает работу клиентов, использующих заменяемые объекты. По идее этого могло бы и не быть если хранить предшествующие версии кода.

Второе. И класс и модуль можно считать единицами структуры проекта и для монолитных систем это тоже не бессмысленно. Другое дело, что скажем в Java-реализации (класс~модуль), вложенные классы (тесно связанные с объемлющим классом, т.е. хранящие ссылку на экземпляр оного) после компиляции имеют некоторую самостоятельность
и при определенных ограничениях могут заменяться отдельно друг от друга.

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

Как я пришел к Оберону

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

Дело было в конце 1980-х годов (то ли осень 1988 г., то ли 1989 г. -- не могу точно вспомнить). На одной из встреч советской рабочей группы по Модуле-2 ее руководитель Дмитрий Михайлович Сагателян (сейчас он живет в Америке), поддерживавший постоянный контакт с проф. Виртом, познакомил нас с новыми публикациями: в июле 1988 г. в авторитетном журнале Software – Practice and Experience вышло сразу две статьи Вирта: "From Modula to Oberon" и "The Programming Language Oberon".

Для меня в то время (да и сейчас) Вирт -- это знак качества. Поэтому любая его работа заслуживала пристального внимания. Я тогда был увлечен Модулой (собственно, с письменного перевода Programming in Modula-2 для себя и начал осваивать на практике технический английский). Работал на ней к тому времени не один год и получал колоссальное удовольствие. То, что нужно. Особенно после опыта работы с Фортранами, Бейсиком, Паскалем, ассемблерами, Си и Смоллтоком.

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

Убран FOR -- это был шок. Тишина в зале. Непонимающее переглядывание. Не может быть! Да, убран. Ладно, поняли, что это еще требуется переварить. Потом пошли вариантные записи, типы и т.п. А что взамен? Какое-то там расширение записи. Плюс все это пока только на бумаге, в теории. Компилятора доступного нет. Когда будет и на каких машинах – не ясно. В общем, сделал для себя вывод -- экспериментальный язык, но поживем -- увидим.

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

Занял выжидательно-наблюдательную позицию. А тем временем, Модула свои высоты только укрепляла как в моем сознании, так и на мировой арене:  на подходе был ISO-стандарт для продвижения в индустрию, на руках -- приличные системы программирования, причем уже для ПК. Полным ходом у нас в МАИ шли работы по разработке своего компилятора Modula-3. Все более активно стали в нашем поле зрения появляться материалы и софт по Аде и C++. Лишний раз убеждался -– Модула-2 на фоне всего этого выглядит просто жемчужиной.

После поездки осенью 1994 г. в Германию, в Ульм на конференцию JMLC (Joint Modular Language Conference) начался у меня новый этап приглядывания к Оберону. Привез по линии института несколько систем, букет компиляторов, библиотеки. Плюс классную рабочую станцию DEC Alpha с компиляторами Оберона-2 и Модула-2 для отличной операционки OpenVMS (спасибо Гюнтеру Дотцелю).

Попробовал систему Oberon (она была тогда уже в двух "диалектах" -- V4 и System 3). Забавно, но как-то уж очень игрушечно. Раза три брался за то, чтобы наладить технологическую цепочку компиляции-запуска модулей. Напоролся на уйму граблей. Начертыхался. Кое-чего в конце концов добился, но ждал-то совсем другого. Сделал вывод -- такую вещь самостоятельно даже при большой мотивации осваивать тяжело. Отложил в сторону до лучших времен.

Следующий раз за Оберон взялся уже после знакомства с Juice (миниатюрная Oberon-машина для браузеров). По-моему, это было в начале-середине 1996 г. Вот это вещь! На фоне Java выглядело потрясающе (да и сейчас очень даже). Опять-таки -- сделал Микаэль Франц, с диссертацией которого по динамической кодогенерации познакомился еще в Ульме с подачи Дотцеля. Списался с Францем и немного с ним сдружился (он звал к себе в аспиранты в свой университет в пару к Томасу Кистлеру, но из России даже во имя большой цели я уезжать не собирался).

Поскольку в Juice технологическая цепочка написания Оберон-аплетов была завязана на Oberon System 3 (Франц все годы отвечал за Mac'овскую реализацию Оберона), пришлось еще раз возвращаться к освоению системы. На этот раз все было не так напряжно. А когда освоил -- оценил и саму систему. Причем, чем дальше изучал и пробовал, тем больше восхищался. Да это же кладезь премудрости. И куда я раньше-то смотрел?

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

Какой из всего этого вывод? Путь к Оберону долог, не прост. Требуется нечто, что по-настоящему зацепит человека, даст ему приличную мотивацию, заставит преодолевать все трудности освоения и понимания простоты Оберона. Мне повезло. Зацепило. Но мог ведь пройти мимо.

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

Невольно вспоминаешь известное изречение Эрика Шмидта (того самого, что был президентом Novell, затем в годы раскрутки Java -- главным техническим директором Sun, сейчас -- ген. директор Google, член Национальной инженерной академии США). В середине 1990-х Шмидт сказал: "Даже таксисты знают: Java -- это класс!" И тогда же: "Когда вы произносите слово "Java", то, что бы ни скрывалось за ним, на первый план выступают позитивные аспекты фирменного названия. Вы чувствуете: это нечто солидное, люди возбуждаются, стремятся приобщиться". Ну а теперь, добавлю от себя, даже домохозяйки знают: Google -- это наше всё!

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

Ответ на »сообщение 851« (Сергей Губанов)
___________________________
>>>Модули для того и нужны, что их можно динамически из программной системы выгружать/перезагружать.

Если бы модули были нужны только для этого, их бы не было ни в Модуле, ни в Аде,  ни в сотне других языков.

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

Например, ведь не все согласны с необходимостью отдельной конструкции для модуля. Тот же Мейер, например. Почему?

Да потому что не все пишут программные системы.
Модули для того и нужны, что их можно динамически из программной системы выгружать/перезагружать.
Классы/типы выгрузить/перезагрузить нельзя, а модули можно.
Тем кто пишет монолитные программы ничего динамически выгружать/перезагружать не надо, вот им модули не нужны.

И вообще, я скоро уже тресну это объяснять каждый раз :-(

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

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

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

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

Точно.

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

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

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