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

У меня складывается впечатление, что применимость ФП ограничена "программированием в малом" (где оно весьма перспективно).
Имеется в виду: выполнить ту или иную функцию между точками изменения и расширения программной системы.

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

у меня архиватор использует 5-10 потоков. данные между ними пережаются через каналы, за исключением двухз переменных. одну из них я обернул в синхронизатор, другая (статистика UI) осталась как есть :D

оборачивание переменной в синхронизатор MVar выглядело так (File - это исходный тип до оборачивания, file* - операции над ним):

-- |Архивный файл, заворачивается в MVar для реализации параллельного доступа из разных тредов ко входным архивам
type Archive        = MVar File
archiveCreate        = returnMVar . fileCreate
archiveOpen          = returnMVar . fileOpen
archiveGetPos        = liftMVar1 fileGetPos
archiveGetSize      = liftMVar1 fileGetSize
archiveSeek          = liftMVar2 fileSeek
archiveRead          = liftMVar2 fileRead
archiveReadBuf      = liftMVar3 fileReadBuf
archiveWrite        = liftMVar2 fileWrite
archiveWriteBuf      = liftMVar3 fileWriteBuf
archiveClose        = liftMVar1 fileClose

вообразите то же самое на яве :)))


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

case compressor of
  [a]    ->  storing_PROCESS |> compressP a
  [a,b]  ->  storing_PROCESS |> compressP a |> compressP b
  [a,b,c] ->  storing_PROCESS |> compressP a |> compressP b |> compressP c

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

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

мне представляется, что идеи шли по линии smalltalk->objc->objpascal->delphi->c#. ява же непосредтсвенно из objc (и разумеется, ява оказала первоочередное влияние на c#). во всяком случае, эти технологии были более популярны, чем оберон, и спцифически обероновских особенностей, типа отказа от ООП, в c#/яве не наблюдается.

Булат, еще небольшой штрих к вопросу о корректности и мифотворчестве.

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

Если брать C++, Objective C, Java и C#, то источником их идей были работы Xerox PARC (примерно с 1970 по 1990 гг.), а также, пожалуй, самой тогда мощной по своей инфраструктуре сети исследовательских лабораторий компании DEC (Digital Equipment Corp., потом просто Digital). Той самой, что известна миру по своими PDP-11 и VAX-11, ОС VAX/VMS, OpenVMS и процессором Alpha. Той самой, которую сначала скушала Compaq, а потом эту Compaq -- HP. Народ оттуда (как, кстати, и из Xerox PARC) порастащил все тот же самый Microsoft.

Так вот помимо Smalltalk в Xerox PARC делались также Mesa, Cedar. Ну а в DEC Systems Research Center -- Modula-3. Smalltalk не имел прямых европейских аналогов (разве что норвежская Симула-67), а вот Mesa и Cedar имели: Modula-2 и Oberon. Интересно, что в случае Modula-2 направление творческого заимствования идей (Modula-3) пошло в другом направлении: из Европы в Штаты. Хотя там команда Грега Нельсона и Билла Калсова в контексте той задачи, которая ставилась, поработала на славу: получился монстр масштаба Ады, но при этом сохранивший дух и элегантность Модулы-2.

Благодаря такому параллельному развитию исследований в лучших языках 1970-1990 гг. по обе стороны Атлантики у американцев есть великий соблазн говорить только о своих, американских работах. И они перед этим соблазном не могут, разумеется, устоять. Скажите, Вы где-нибудь читали о том, что Хоар имел какое-то отношение к зарождению идей ООП? Хотя бы в той же Европе? То-то и оно. На мир мы смотрим через очки американцев. А неплохо бы рассуждать самостоятельно.

Хочу еще раз вернуться к тому, что здесь в Королевстве уже обсуждалось. Раз речь зашла об истоках Java, хотел бы внести уточнение. Поскольку нередко можно встретить слова о том, что Java "содрана" с Oberon. Конечно, это не так. Java создавалась под влиянием Оберона. Известна история с лицензированием системы Oberon и выступлнием Франца в SunLabs. Это факты, подтверждающие источники прямого интереса создателей технологии Java (к которой руку приложил не один Гослинг). Но влияние -- вещь эфемерная. Чтобы не было упреков в передергивании, приведу цитату Бьерна Страуструпа (2000): Clearly, Java borrows from C and C++, but under the skin, the similarities to Modula-3 seem greater. http://www.gotw.ca/publications/c_family_interview.htm

Так что автор C++ признает большое влияние на создание Java со стороны языка Modula-3 ( http://en.wikipedia.org/wiki/Modula-3 ), который создавали в DEC Systems Research Center при участии Olivetti Research на основе языка Modula-2, т.е. прямого предшественника Оберона. Это достаточно убедительно говорит об истинных корнях языка Java. Что касается Java-браузера и аплетов (главной точки раскрутки Java в 1995 г.), то здесь факт прямого заимствования из системы Oberon налицо.

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

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

Ответ на »сообщение 3497« (Руслан Богатырев)
вот когда вы говорите, что какие-то вещи есть только в обероне, а в C++ их нету, вспминайте про эти языки тоже. gc, dynamic loading, компонентное программирование. вы ведь знаете возможности этих языков?
ObjC, про который я немного читал, видимо, интересная штука - у него старая история... Увы, не знаком с ним даже "шапочно", нет возможности и времени...

А про Шарп с Явой и говорить нечего - все компонентные возможности были исторически заимствованы из Оберона, однако где-то подкоцаны, где-то наоборот раздуты до текущей мейнстримовской моды... Смотреть там не на что.

Над Шарпом-Нетом работали некоторые люди из Паскаля/Оберона. Клеменс Шиперски - один из первых разработчиков Блэкбокс. Про Андре Хейлсберга (автор Дельфы) все, наверное, знают.
Более того, даже технически Блэкбокс является предтечей .NET - я это увидел воочию, когда перерабатывал его ядро - и параллельно читал Рихтера про особенности реализации .NET.
Однако приличная часть перспективных идей из ББ в .NET не пошла. Например, графический Framework развит из идей VCL, а не из составных документов ББ.

мне представляется, что идеи шли по линии smalltalk->objc->objpascal->delphi->c#. ява же непосредтсвенно из objc (и разумеется, ява оказала первоочередное влияние на c#). во всяком случае, эти технологии были более популярны, чем оберон, и спцифически обероновских особенностей, типа отказа от ООП, в c#/яве не наблюдается.

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

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

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

вот когда вы говорите, что какие-то вещи есть только в обероне, а в C++ их нету, вспминайте про эти языки тоже. gc, dynamic loading, компонентное программирование. вы ведь знаете возможности этих языков?

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

Чтобы понять всю глубину этой простоты, надо копнуть аж до 1950-х годов, проследить цепочку принятия архитектурно-инженерных решений и аргументы сторон. Тот же Лисп -- это вечный язык, не чета нынешним. Минуют многие поколения программистов, а Лисп благодаря своей своей простоте и выразительности, помноженной на то, что Хоар называл концептуальной экономией, будет оставаться точкой приложения интеллекта. В отношении Оберона, думаю, будет то же самое.

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

Ответ на »сообщение 3497« (Руслан Богатырев)
вот когда вы говорите, что какие-то вещи есть только в обероне, а в C++ их нету, вспминайте про эти языки тоже. gc, dynamic loading, компонентное программирование. вы ведь знаете возможности этих языков?
ObjC, про который я немного читал, видимо, интересная штука - у него старая история... Увы, не знаком с ним даже "шапочно", нет возможности и времени...

А про Шарп с Явой и говорить нечего - все компонентные возможности были исторически заимствованы из Оберона, однако где-то подкоцаны, где-то наоборот раздуты до текущей мейнстримовской моды... Смотреть там не на что.

Над Шарпом-Нетом работали некоторые люди из Паскаля/Оберона. Клеменс Шиперски - один из первых разработчиков Блэкбокс. Про Андре Хейлсберга (автор Дельфы) все, наверное, знают.
Более того, даже технически Блэкбокс является предтечей .NET - я это увидел воочию, когда перерабатывал его ядро - и параллельно читал Рихтера про особенности реализации .NET.
Однако приличная часть перспективных идей из ББ в .NET не пошла. Например, графический Framework развит из идей VCL, а не из составных документов ББ.

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

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

Ответ на »сообщение 3491« (Илья Ермаков)
___________________________
Кстати, в последнее время намечяется тенденция к переходу от компонентного программирования к метапрограммирования - к софтверным фабрикам всяким, что-то типа макросов в Лиспе да новомодном Немерле.
Что думают наши оберонщики об этом?
По поводу Немерле - я не в курсе, кроме того, что вроде бы синтетический язык в плане ФП/ИП.

У Оберона есть приличный ресурс по развитию в плане метапрограммирования. Однако пока "потолок" ставится конкретными реализациями. Для поднятия этой планки нужен, в частности, уход на JIT и особые промежуточные представления (например, развивающие Франца). Тема интересная, но пока по ней работы, вроде бы, никем не ведутся...

макросы в обоих языках - это кодогенерация во время компиляции, никакого отношения к RTS средствам она не имеет. немерле похож на C# - ООП язык с ФП надстройками типа лямбда-выражений и выведения типов

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

Ответ на »сообщение 3491« (Илья Ермаков)
___________________________
Кстати, в последнее время намечяется тенденция к переходу от компонентного программирования к метапрограммирования - к софтверным фабрикам всяким, что-то типа макросов в Лиспе да новомодном Немерле.
Что думают наши оберонщики об этом?
По поводу Немерле - я не в курсе, кроме того, что вроде бы синтетический язык в плане ФП/ИП.

У Оберона есть приличный ресурс по развитию в плане метапрограммирования. Однако пока "потолок" ставится конкретными реализациями. Для поднятия этой планки нужен, в частности, уход на JIT и особые промежуточные представления (например, развивающие Франца). Тема интересная, но пока по ней работы, вроде бы, никем не ведутся...

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

Т.е. для сложных системных вещей C++ противопоказан. Для прикладных -- есть куда лучше и надежнее варианты. Остается что -- производительность? Мы будем здесь сравнивать производительность C и той же Modula-2 с C++ или не стоит?


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

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

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

вот когда вы говорите, что какие-то вещи есть только в обероне, а в C++ их нету, вспминайте про эти языки тоже. gc, dynamic loading, компонентное программирование. вы ведь знаете возможности этих языков?

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

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

Да я тоже, вобщем-то, технарь, только я привык больше к Си и Паскалю, чем к Оберонам...
Несколько лет назад (ок. 8 где-то) мне попался Oberon-M - было интересно, но там даже плавающей арифметики не было, и операторв FOR тоже... :о)

А ФП вообще только последние полгода интересуюсь. Представляете, до того, как я узнал о Хаскелле, я больше интересовался Занноно и его активными объектами... :о))
____________

Кстати, в последнее время намечяется тенденция к переходу от компонентного программирования к метапрограммирования - к софтверным фабрикам всяким, что-то типа макросов в Лиспе да новомодном Немерле.

Что думают наши оберонщики об этом?

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

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

Ну если в этом смысле, то связка конечно есть (с чего бы ей не быть, если ее и строили). Паразитирование C++ и ставило целью создание такой связки. Потом, правда, произошла досадная рассинхронизация. Тот же Страуструп, увидев до какой степени обогащения доведено его же детище, признался: "Моим идеалом по-прежнему остается единый язык, и техническая возможность достаточно логично слить С++ с C99 пока сохраняется. На мой взгляд, такой язык мог бы соответствовать любым разумным техническим условиям. Однако я не уверен, что это приемлемо политически". Разработчики UNIX (про Томпсона и Ритчи помолчу, они уже молвили "доброе" слово в адрес C++ и того же Linux) стараются четко разграничивать C и С++ (вроде как не лезьте к нам со свиным рылом в калашный ряд). Возвеличенный до неприличия Линус Торвальдс и тот кроет C++ на чем свет стоит. Т.е. для сложных системных вещей C++ противопоказан. Для прикладных -- есть куда лучше и надежнее варианты. Остается что -- производительность? Мы будем здесь сравнивать производительность C и той же Modula-2 с C++ или не стоит?