Ответ на »сообщение 3491« (Илья Ермаков)
___________________________

В целом это обсуждение еще раз показывает разницу между мышлением специалистов, "заточенных" под разные задачи. У Вас, по-видимому, четко выраженное математическое мышление. А мы (я, Руслан, AVC...) - технари-системщики :-)

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

а я системщик с мат. мышлением :))

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

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

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

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

C++ паразитировал на Си, который в сфере не ПК-попсы (извините за резкость), а профессионалов имел в середине 1980-х годов очень высокий авторитет. Связки C/C++ как таковой, увы, не было.

связка заключается в том, что можно взять с-шную программу и продолжить развивать её на С++. не забывайте, что программы не пишутся с нуля, а развиваются. то же самое в сфере изучения языка

Ответ на »сообщение 3492« (Булат Зиганшин)
___________________________

можно тогда ожидать от вас сравнения Оберон не только с С++, но и с objc/c#/erlang?

Сравнения по каким критериям и по какой методике? Боюсь, мы все чаще сравниваем бананы с попугаями. :)

Сравнивать нужно по четким параметрам либо абстрактно (вообще, чисто теоретически, computer science) на небольших задачах (как из того же ACM ICPC), детально разбирая на этой узкой колее возможности, либо, что еще лучше, на конкретных практических проектах (software engineering; заказчик, сроки, квалификация исполнителей, наличествующие ресурсы, риски и т.п.). Каким бы ни был один язык лучше по отношению к другому, но если даже взять одного программиста (знающего, скажем, два языка -- "лучший" и "худший"), то в случае большей практики и собственных индивидуальных предпочтений чисто психологического характера в ряде случаев на худшем языке он сделает лучше. И ничего ту нет удивительного.

Да и как Вы будете сравнивать по таким субъективным критериям, как clarity и readability? Я говорю, что синтаксис Оберона много лучше Си, а другие -- ерунда, чушь. Ну поговорили и разошлись...

В программировании, увы, по большей части есть субъективизм, мнения, но не факты и не знания. Идет это еще с 1960-х годов, когда науку подменили ремеслом, даже не поставив ей скромного надгробья.

Ответ на »сообщение 3470« (Кубаныч)
___________________________

Ответ на »сообщение 3466« (Илья Ермаков)
___________________________

Здравствуйте. Прошу прощения за оффтопик.
Я потерял свой пароль от Вашего форума.
Можете подсказать, как в StdTables.Table

1. Закрашивать фон отдельно выбранных ячеек ?
2. Автоматически регулировать ширину столбца по длине
  самого длинного текста ?

С уважением,


Пришлите, пожалуйста, письмо на bb16[собака]oberoncore.ru - администратор вышлет Вам новый пароль!
По поводу StdTables - я очень давно не работал с ГУЕвыми приложениями, сейчас не помню, к сожалению...
Стоит спросить у народа на нашем форуме - кто-нибудь точно знает.

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

Насчет местечковости -- упрек не по адресу


можно тогда ожидать от вас сравнения Оберон не только с С++, но и с objc/c#/erlang? всё-таки на мой взгляд, C++ сейчас хорош только в том случае, когда во главу угла ставится скорость и только скорость

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

Ответ на »сообщение 3466« (Илья Ермаков)
___________________________
это, конечно, удобно...
Но опять же, можно реализовать и традиционными методами, пусть даже и с перекомпиляцией, да и то не обязательной...
Тут воэникает такая тонкая грань между гибкостью и надёжностью... А о формальной корректности даже и речи быть не может, имхо...
Почему не может? Я что, напрасно приводил аналогии с "железом"? Здесь полная, 100%-параллель - модули и коммутация по строго фиксированным, типизированным разъемам-интерфейсам. Электронщики вот как-то имеют полную формальную корректность, а здесь нельзя? :-)
Контракты, предусловия, постусловия могут налагаться не только на статический интерфейс модуля, но и на шины и разъемы. Т.е. если к верифицированной системе динамически подключается модуль, который отдельно также верифицирован на соблюдение контрактов той шины, к которой подключается, то система с новым модулем также остается формально соответствующей контрактам. При внедрении же неверифицированного модуля надежность системы, естественно, понижается (на сколько - зависит от того, в какое "кольцо защиты" вводится модуль).

Надежность может быть обеспечена 100%. Я уже раза три повторил, что при необходимости модуль может проследить, кто к нему обратился. Это - не проблема. (Т.е., если не поняли... Например, в BlackBox с моим SP4 процедура A.УстановитьРазъем может обратиться к спец. сервису модуля Mem и получить исчерпывающий ответ, КЕМ она вызвана - какой процедурой какого модуля. Если этот вызывающий модуль не имеет права на выполнение запроса, например - на перекоммутацию разъема, он "получит по шее"... Технически для Mem это обходится одним шагом раскрутки стека и последующим запросом к базе символьной информации Kernel).



А если сервис не так прост, чтобы A мог его самостоятельно предоставить?

Это решается и без всякой "инверсии" экспорта - стандартными механизмами - задача разбивается на подзадачи и только А знает, какие модули эти подзадачи решают...
Делегаты, конечно, могут быть удобны, но всё-таки это опасно...

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

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

В целом это обсуждение еще раз показывает разницу между мышлением специалистов, "заточенных" под разные задачи. У Вас, по-видимому, четко выраженное математическое мышление. А мы (я, Руслан, AVC...) - технари-системщики :-)

В целом, чем больше размышляю над модульными концепциями, тем больше понимаю, что это на сегодняшний день единственная методология, позволяющая надежное системное и инфраструктурное программирование. А ваше противопоставление ФП/ИП - это другой план, другой уровень - уровень алгоритмики, а не архитектуры.
А ахилесова пята ООП в этом смысле - как раз-таки многократно обсуждавшаяся концепция "объект - и модуль, и экземпляр типа данных". Не говоря даже об очевидном преимуществе явного синтаксического разделения сфер ответственности, можно отметить, что ограничение модульных языков на единственность модуля очень важно для грамотного и надежного проектирования, поскольку заставляет разработчика четко разделять сущности модели проблемной области и сущности конструируемой системы. Потоки данных, обрабатываемые системой, могут существовать во множественном числе, они "информационны", их дублирование ничего не стоит, они могут строиться на любых абстракциях высших порядков.
Сама техническая система - единственна, она не может перемешиваться в своих структурах с обрабатываемыми данными, она должна быть в некотором роде "материальна", в своей архитектуре - буквально "физически" осязаема, а не эфемерна. Таким образом мы добиваемся надежности и контроля над сложностью систем.

кстати, доклад по истории хаскела, который там будут читать - http://research.microsoft.com/~simonpj/papers/history-of-haskell/history.pdf

Ответ на »сообщение 3485« (Булат Зиганшин)
___________________________

во сторой половине 80-х было по 5-10 компиляторов си, паскаля и модулы-2. ада и другие языки не были так хорошо представлены

Во второй половине 80-х насчитывалось примерно пять лет с момента появления IBM PC. Т.е. Вы говорите о ситуации только на рынке ПК и за заре его массового производства.

у С был лишь небольшой перевес в популярности;

Уточним: на ПК.

насчёт эйфеля очень советую - посмотрите

Эйфелем я интересовался (и интересуюсь) примерно с 1991 г. Одним из результатов стала вот эта работа: http://liinwww.ira.uka.de/cgi-bin/bibshow?e=Njtd0ECMQ02::4/fyqboefe%7d2711:8::&r=bibtex&mode=intra

главная идея того постинга - в том, что C и C++ прошли именно своей связкой. если бы такая же связка была вместо этого скажем для паскаля+эйфеля - то весьма вероятно, что победили бы они

C++ паразитировал на Си, который в сфере не ПК-попсы (извините за резкость), а профессионалов имел в середине 1980-х годов очень высокий авторитет. Связки C/C++ как таковой, увы, не было.

Что касается Эйфеля, то он всегда был сам по себе. Это неплохой язык с интересными идеями, но главная его проблема -- он синтаксически и по духу оказался вне двух главных ветвей -- Алгола/Паскаля и Си. После прихода Бертрана Мейера в ETH идеи Оберона в лице Мейера практически игнорируются. Почитайте его толмут по ОО-конструрированию (и это человека, называющего себя учеником А.П.Ершова) и найдите там глубокий анализ Оберонов. Там этого нет. Скажите, мыслимое ли дело, чтобы человек, пришедший на место Вирта в лучший университет Европы (ETH), в стенах которого учились и работали такие выдающиеся ученые и инженеры, как Альберт Эйнштейн, Джон фон Нейман, Конрад Цузе, Никлаус Вирт, за несколько лет предал забвению четвертьвековое наследие своего предшественника? Притом, что в мире 1970-1990 гг. были два самых ярких центра -- научный Xerox PARC (в Америке) и университетский ETH Zurich (в Европе).

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

Ответ на »сообщение 3480« (Булат Зиганшин)
___________________________

не совсем так. процедуру, имеющую побочные эффекты, можно считать чистой функцией

Отвечу Вашими же словами: "можно" не означает "нужно".


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

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

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

Так значит Вирт с Модулой не успел... :(
Эх, какой язык загубили...

Не так. Там были требования Минобороны, которым нужно было удовлетворить. Сами понимаете. А Вирт сделал по-своему.

на мой взгляд, Вирт всегда стремился создавать *небольшие* ЯП. во времена появления мини, а затем и микро-компьютеров с их ограниченными ресурсами эта идея выстрелила, и Паскаль с Модулой завоевали популярность профессиоанльных программистов. затем ресурсы машин стали расти и результаты работы Вирта оказались вне маинстрима. проект Ады был как раз "большим" - и в конце концов был отобран большой язык со множеством встроенных возможностей - таких как обработка исключений или многозадачность. оборотной стороной такого критерия стало то, что все 80-е годы Ада оставлась слишком сложным языком для того, чтобы её хорошо реализовать на персоналках :))