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

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

Ключевое слово в вашем замечании -- "можно". Вот именно, можно. А как это поддерживают, как стимулируют? Что безусловно доминирует на рынке, в сознании? Правильно, ООП.

Проблема носит далеко не технологический характер.

Ответ на »сообщение 3748« (Руслан Богатырев)
___________________________
В чем же состоит "политика навязывания своих условий". Скажем на Дельфи можно писать модульные программы без использования ООП или с минимальным использованием, например только интерфейсных компонент.
Стоп, стоп, про раздельную загрузку не будем. Я говорю о языке представления алгоритмов, а не о взаимодействии с операционной системой и исполнительной средой. Будет ли он компилируемым, интерпретируемым или помодульно подгружаемым мне не важно. Я хочу всего-навсего с минимальными затратами описать сложный алгоритм.

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

А если реализовать Кронос на сегодняшних тех. процессах? Не судьба? ;)

Примерно в таком же ключе задал вопрос залу Гуткнехт на пресс-конференции в Политехническом.

Кронос был ярким проектом. Люди объединились вокруг него и поставили перед собой большую цель. Они ее добились, хотя на самом деле делали-то компьютеры для себя. Так для себя даже лучше. Это потом был МАРС и все такое. Громкие слова Горбачева с кремлевской трибуны. А делала-то все горстка единомышленников. Сейчас их судьба разбросала по свету, но переписываются, встречаются.

Вопрос Гуткнехта имел такой подтекст -- неужели перевелись в России те, кто готов бросать технологический вызов индустрии? Или слабо браться за масштабные вещи?

В Lilith и Кроносе использовался M-код. Насколько я помню была чисто стековая архитектура. Можно ли Оберон делать в "камне"? Можно.

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

Насчёт "диктата ООП". ООП - весьма требовательная идеология, хотя как раз с модульным подходом ну ни как не конфликтует.

Диктат -- это не конфликт. К чему подменять понятия?

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

Ну закидали булыжниками, закидали. Неужели раздельная компиляция является обязательным условием модульного программирования? А слабо вообразить модульный язык-интерпретатор? :)

Далее. Для dll-ки выполняются все условия определения "модуля" даже если внутри объектный класс - это как???

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

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

Вышла новая Crazy-Fresh сборка Bluebottle.
Одно из нововведений - изменился формат объектных файлов и расширение их, теперь .Bbx

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

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

Упрекать в незнании модульного программирования тех, кто с такими языками не работал, конечно можно. Но можно понять и то, что существовали вполне определенные объективные причины, почему эта область осталась за кадром.

С каким языками модульного программирования люди могли работать?

С Modula-2 ? Язык устаканился в 1978 г. Формально считается появившимся в 1979 г. Modula-2 вышла в свет (далеко за пределы ETH) примерно в 1982-84 гг. Была на Mac, на PC, на DEC LSI-11/PDP-11 (Электроника-60, ДВК, СМ-4 и т.п.). Толкали на рынок Logitech и JPI TopSpeed. Некоторую нишу завоевала, но и только. Оба флагмана подзавяли.

С Ada ? На ПК компиляторов долгое время практически не было, а когда появились, уже шла полным ходом волна C++. Попытки ее продвигать в России ограничились, пожалуй, Новосибирском (проект БЕТА) и Москвой (МГУ). Кстати, Евгений Зуев (ETH, Zonnon) специализировался на Аде, а потом только занялся своим компилятором C++.

Что же остается? Ну да, как же я забыл -- Turbo Pascal! В самом деле, Хейльсберг ведь написал свой компилятор Blue Label Pascal, который перенес на CP/M и DOS под именами Compas Pascal и PolyPascal. А затем его заприметил предприимчивый Филипп Кан, под мудрым руководством которого  ассемблерную поделку юного датчанина облекли в пышные одежды и толкнули на рынок под именем Turbo Pascal.

Turbo Pascal очень много что позаимствовал (в меру своего понимания) UCSD Pascal, команда которого под руководством Кена Боулеса "слизала" (опять же в меру своего понимания) особенности Modula-2. Ключевая вещь -- модуль -- стала называться unit. А об источнике заимствования говорили весьма лукаво -- из Ады.

Итак, Turbo Pascal. В начале 1980-х прошла волна публикаций про ООП, в основном они были приурочены к раскрутке Smalltalk-80. Эта волна породила новые языки -- Objective C (Бред Кокс, впоследствии язык стал основой NeXTSTEP) и Object Pascal (Ларри Теслер из Apple). Оба появились примерно в один год -- в 1985 г. То есть до C++ Бьерна Страуструпа.

После скандала в Borland и демонстративного ухода вице-президента Нильса Йенсена, разругавшегося с Филиппом Каном, начался проект создания JPI Modula-2. То, что Йенсену закрыли вывод продукта на рынок под маркой Borland, того взбесило. Ушел, создал свою компанию Jensen & Partners International. Но серия JPI TopSpeed-компиляторов вспыхнула яркой звездочкой и затем погасла. Брюс Баррингтон (Clarion) подмял их бизнес под себя, похоронил бренд, компилятор Modula-2, а затем, проиграв в противостоянии Visual Basic и Delphi, продал Clarion-бизнес другим.

Ну а Borland? С выходом Turbo Pascal 5.5 (в мае 1989 г.) про модульное программирование можно было уже забыть. Классы, объекты, методы, наследование, полиморфизм -- вот каким стал новый лексикон модного программирования.

Прошло без малого 20 лет. Зачем ворошить былое? Знают и используют ли идеи модульного программирования в наши дни? Очень мало. Часто с трудом понимают его плюсы и минусы.

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

Ответ на »сообщение 3738« (iZEN)
___________________________
А если реализовать Кронос на сегодняшних тех. процессах? Не судьба? ;)
Подобные процессоры существовали, например, и для языка Forth http://www.ultratechnology.com/4thvhdl.htm
И для Оберон'а его можно будет релизовать без проблем. http://oberon2005.ru/paper/eth10497.pdf
Главное, что-бы в этом была рыночная потребность.
Взгляните на Native Oberon. Его можно-было без проблем со всеми приложениями втолкнуть в память мобилки. Только вот рынок требует Жавы. В мобилки и Linux уже засовывают. Только вот для Linux подобный процессор будет создать проблематично ;)

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

Я никак не могу понять, чем неудобна Java. Объясните, пожалуйста.

Если убрать рыночные вопросы и пропагандистские войны за скобки, то, на мой взгляд, нельзя сказать, что Java -- плохой язык. Более того, я бы даже не взял на себя смелость утверждать, что он безусловно уступает тому же Компонентному Паскалю.

Я уже говорил и повторюсь. Оденьте Java в одежды Оберон-синтаксиса, и язык будет выглядеть совсем по-другому. А ведь семантика-то сохранится.

В каждом языке есть свои недостатки и изъяны. Как правило, они являются продолжением его достоинств.

То, что многим не нравится Java (мне, например, не нравится -- но это очень частное мнение) не говорит о том, что это обязательно плохой язык. Просто разные люди, разный опыт, разные задачи.

Java -- язык, в котором классы возведены в абсолют. Где-то это хорошо. Но любой абсолют вызывает подозрение. Да и на самом деле ООП (как, кстати, и любая иная парадигма) -- не панацея. Это не универсальное лекарство, а нередко -- просто наркотик.

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

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

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

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

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

Хороший язык программирования должен быть:

Соглашусь с этим утверждением с поправками
1. поддерживать структурное программирование
2. поддерживать модульное программирование
3. поддерживать ООП


Плюс добавлю "хороший язык программирования для повсеместного использования".

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

Это известная проблема. Те, кто создают языки, как правило, не являются активно практикующими программистами, задействованными в крупных промышленных проектах.

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

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