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

По результатам проверки ОБЭП (неудачной для ОБЭП), в технаре было принято решение о переводе обучения программированию с DOS+Windows+QBASIC на Linux+FPC :-)
Про QBASIC - я когда приходится в пед. среде ликбез по Линуху делать - на вопросы "А есть ли там Бейсик?", намеренно замалчиваю и говорю, что "нет, г..на-с не держим-с" :-)

Ответ на »сообщение 3802« (Владимир Лось)
___________________________

Уже давно пора, как в том анекдоте: "анекдот номер 265 - ха-ха-ха" - на каждый типовой вопрос отправлять на номер ответа или инициирующего обсуждение сообщения...

FAQ бы заделать на основе всех этих обсуждений :-)
И в него и посылать... "А идите-ка вы в FAQ!" :-) :-)

По результатам проверки ОБЭП (неудачной для ОБЭП), в технаре было принято решение о переводе обучения программированию с DOS+Windows+QBASIC на Linux+FPC :-)

... И, кстати, - с Праздником всех!

( Особливо - хаёвцев! ;о) )

Кто много говорит - не знает, кто знает - много не говорит. (с) умные (хитрые?) китайцы
Сколько можно воду в ступе толочь?
Уже давно пора, как в том анекдоте: "анекдот номер 265 - ха-ха-ха" - на каждый типовой вопрос отправлять на номер ответа или инициирующего обсуждение сообщения...

Третья по счёту важнейшая ветка свелась к мерянью... и "кручению перед микрофонами"...

Пока что, относительно поговорки "собака лает - караван идёт", оберон-сообщество - не в роли каравана...

Жаль.

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

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

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

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

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

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

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

Если задействовать верифицирующий подход, то мы получаем двойной контроль -- реализация (MODULE) обкладывается с двух сторон: INTERFACE под контролем верификатора и DEFINITION под контролем компилятора. Сам по себе верификатор есть простой специализированный компилятор.

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

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

P.S. Обсуждавшийся ранее контроль способа/характера передачи параметра тоже есть прерогатива подобного верификатора.

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

Мне нужно ощущать каждый винтик относящийся к моей конкретной задаче, а общие места вроде гуев я предпочитаю использовать стандартные

Конечно, инженерное конструирование на Оберонах -- это разумеется, сплошное обгуивание. На что они еще годны-то?

Специализация и кооперация все-таки магистральный путь прогресса.

Особенно, если эти магистрали на краю оврага на насыпном грунте и прикрыты только что положенным асфальтом.

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

Одно другому не мешает. За отчуждение отвечают интерфейсы, а ощущение винтиков -- как в интерфейсах, так и в реализации. Где тут противоречие? Или мне померещилось, что его усмотрели?

Ответ на »сообщение 3797« (Руслан Богатырев)
___________________________
>>>А вот если человек хочет ощущать своими руками каждый винтик своего инженерного творения, видеть и понимать, как этот часовой механизм работает, Обероны ему очень близки.
То говорят, что Оберон способствует безболезненному отчуждению наработок, т.е. их свободному использованию другими программистами, то говорят, что Оберон позволяет "ощущать каждый винтик". Куды бедному крестьянину податься :(
Когда я начинал программировать каждый винтик приходилось делать самому - писали и драйверы нестандартной аппаратуры и ГУИ и т.д.
Честно говоря, ностальгии не испытываю. Когда то смотрел фильм про хирурга: делает он что-то суперсложное, потом вдруг бросает инструмент, говорит "можно зашивать" и уходит. Такая зависть взяла :)
Мне нужно ощущать каждый винтик относящийся к моей конкретной задаче, а общие места вроде гуев я предпочитаю использовать стандартные. Специализация и кооперация все-таки магистральный путь прогресса.

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

вот вопрос: неужели при наличии нормальной среды(фреймворка) использования О для прикладных задач было бы неразумным?

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

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

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

Американцы в 1960-е годы сломали через колено Алгол-60. Алан Перлис (первый лауреат премии Тьюринга, президент ACM) приложил к этому немало усилий. Он же опубликовал гнусный пасквиль на роль математики в программировании. В конце 1960-х годов Европа была в шаге от объединения с СССР в сфере компьютеростроения (по линии ICL), но вполне конкретные лица ради своего собственного благополучия (или внезапного помутнения рассудка) путем подковерной борьбы добились худшего варианта и для страны, и для Европы и для мира в целом. Плоды той преступной глупости (если не сказать резче) все мы пожинаем до сих пор.