Здравствуйте, vdimas, Вы писали:

V>Просьба в другой раз перед ответом восстанавливать контекст целиком. Потому как не я выбрал OCaml, мне его привели неоднократно в пример, хотя явно не стоило в споре об устаревших технологиях.

Контекст тут не имеет значения, извини (понимаю в пылу спора), но ты ляпнул феерическую глупость про "недопитизированный ocaml".
Ладно бы ты сравнивал с какой нибудь агдой, но с паскалем или обероном, да они все слабо типизированые относительно OCamla или SML.

FR>>Это как-раз фигня, даже тупенький оптимизатор окамла довольно удачно пытается минимизировать эти сдвиги.

V>Эти сдвиги принципиально оптимизируемы только в локальных вычислениях, увы, не более и не менее чем все остальные детерминированные целочисленные вычисления. Если же у тебя есть некий библиотечный алгоритм, пробегающийся по графу объектов в памяти, а не по локальным переменным, то никакой самый современный компилятор сие не соптимизирует.

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


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

Кстати что оберон быстрее окамла еще доказать надо, мне например интересно было бы тесты посмотреть.

FR>>Ты путаешь реализацию и сам язык (как всегда впрочем).

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

Угу "только не бросай меня в терновый куст".

FR>>Но в любом случае редизайн необходим, без многопоточности сейчас уже никуда.

V>Угу, особенно если учесть, что спор зашел с упоминания возможностей Активного Оберона, где не просто многопоточность, а целая философия:
V>- безопасный язык, способный компиллироваться в оптимизируемый нейтивный код;
V>- плоская память;
V>- миллионы дешевых агентов;
V>- GC на уровне ОС;
V>- бесплатное переключение контекстов из пользовательского кода в ядерный и обратно;
V>- юзер-левел асинхронность, подерживаемая на уровне шедуллера ОС;
V>- эффективнейший в природе ввод-вывод и обмен данными м/у процессами.

Active Oberon это уже 2000 год когда все это было далеко не новостью.
Если уж так охота сравнить можно сравнить форк Active Oberon для NET — Zonnon и форк OCaml' для того же NET — F#.

FR>>По моему ты тролишь, да ладно я готов согласится что OCaml к сожалению устарел, но Оберон в той же категории, если не хуже.

V>Твои заявления ничем не лучше заявлений Киберакса... Т.е. еще не факт, кто тут троллит. Ключевой список идей с т.з. моего ИМХО я привел. Если тебе действительно охота что-то обсуждать — прошу обсуждать более предметно. Жду твоего "ИМХО" по этим технологиям.

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

Здравствуйте, vdimas, Вы писали:

V>Продложаешь убивать наповал.. Ты ведь мог поставить Фортран, Аду и другие языки, которые 100% говны мамонтов... Но по твоим признакам получится — что вовсе нет?

Ada — Оберон


Фортран — Оберон

Здравствуйте, vdimas, Вы писали:

V>Вот, примерно так.

Нет начиналось все с мифических огромных требований ML к памяти:

Любым:
— объем бинарного кода;
— эффектвность;
— требования к оперативной памяти.

Из-за всего этого на ML невозможно писать для каких-нить военных железок.

ocapic это вполне опровергает.

Здравствуйте, vdimas, Вы писали:

V>Ну и кто из нас троллит?

Конечно ты, я же не наблюдаю в природе то что ты утверждаешь:

Конкретно OCaml — хреновый объем.

объективных доказательств от тебя нет, если не согласен давай замеры объема кода.

FR>>Если брать байт код то он еще компактней.

V>Вот опять...

Что? Приборы?

Здравствуйте, vdimas, Вы писали:

V>Хаскель нельзя сравнивать с Обероном. Как можно сравнивать характеристики моделей паровоза и парохода? Они движутся по разным физическим средам. И никаких активных объектов в Хаскеле в 90-х не было, не надо ля-ля.
Мне, как и FR, очень лень вторгаться в оберон-болото, но мимо такого наезда на Хаскел пройти не могу. Активные объекты появились в 1996 году, смотри Concurrent Haskell.

V>В Хаскеле даже продолжений нормальных нет, а они являются необходимым элементом для иммутабельных языков, чтобы те умели работать в агентской среде.
Можно кусок кода на Обероне с продолжениями, который "невозможно" сделать один в один на Хаскеле?

Здравствуйте, vdimas, Вы писали:

V>Продложаешь убивать наповал.. Ты ведь мог поставить Фортран, Аду и другие языки, которые 100% говны мамонтов... Но по твоим признакам получится — что вовсе нет?

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



Такое ощущение что на обероне пишут или те кто по привычке перешел с модулы (те же космические проекты) или
укушенные Виртом, притом вирус Вирта скажем в отличии от вируса Александреску вызывает в основном не написание кода,
а написание статей, защиту диссертаций и срачи на форумах.

Здравствуйте, vdimas, Вы писали:

V>У самых ходовых моделей 18-й серии (18 ног) доступное для произвольного использования ОЗУ полторы сотни байт +-.
И как же туда влазит АктивныйОберон? Да, со сборщиком мусора, естественно.

Здравствуйте, FR, Вы писали:

FR>вирус Вирта скажем в отличии от вируса Александреску вызывает в основном не написание кода,
FR>а написание статей, защиту диссертаций и

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

FR>срачи на форумах.

Вот это более правдоподобно.

Здравствуйте, vdimas, Вы писали:

FR>>В любом языке который хоть как-то используется на практике такие конструкции есть и будут, но
FR>>используются они только в крайних случаях.

V>В Хаскеле же нет. И во многих ML-диалектах тоже.

Как бы не так.

-- GHCi, version 7.4.1: http://www.haskell.org/ghc/  :? for help
> Unsafe.Coerce.unsafeCoerce Nothing :: Bool
False
> Unsafe.Coerce.unsafeCoerce $ Just 42 :: Bool
True

(* Standard ML of New Jersey v110.73 [built: Mon May 16 06:14:15 2011] *)
- Unsafe.cast false : int;
val it = 0 : int
- Unsafe.cast true : int;
val it = 1 : int

Вот только к слабой типизации это не имеет отношения. Слабая типизация — это когда такие преобразования происходят неявно.

Здравствуйте, vdimas, Вы писали:

V>В Хаскеле даже продолжений нормальных нет, а они являются необходимым элементом для иммутабельных языков, чтобы те умели работать в агентской среде. async/await.

Зачем увлекательные преключения с продолжениями, async/await и прочим для организации "работы в агентской среде", если есть легкие потоки, позвольте спросить?

Здравствуйте, vdimas, Вы писали:

M>>У нас есть ещё Occam ( http://en.wikipedia.org/wiki/Occam_programming_language ) — это императивный язык со встроенными параллельным примитивами (каналы, fork/join вычисления). В 1983-м году. И этот язык реально использовался в суперкомпьютерах и до сих пор имеет быстрые реализации.
V>Тоже там же ответил. Не имеет быстрые реализации. Сказки. У OCAML есть кое-какое важное ограничение. Подсказку там же дал.

Occam и OCaml не родственники и даже не однофамильцы.

Здравствуйте, Cyberax, Вы писали:

C>ML разрабатывался в конце 70-х годов. На примере ML обычно обкатывались алгоритмы GC и других способов управления памятью (типа region inference).

Ну да. ФЯ очень любят возраст натягивать. ML разрабатывался, разрабатывался и разработался как следует только к началу 90-х. При этом алгебраические типы и паттерн-матчинг для которых он якобы "является "родиной"" (кавычки поставлены не зря) попали в него из другого языка (Hope, если интересно). А region inference вовсе в 2000-ных обкатывали.
Это, впрочем, пустяки по сравнению с хаскелем, который считается "разработанным" прямо с того момента, когда Худак и Пейтон-Джонс решили сообразить на троих с Тернером, да только тот отказался. Так что в этом треде хаскель уже оказывается ровестником оберона.

V>>Потому что не удовлетворяют никаким предъявляемым для военных и космических разработок требованиям.
C>Так, а теперь вопрос ребром:
C>ГДЕ КОД НА ОБЕРОНЕ?

А разгадка проста: в "космических разработках" действительно применяют, насколько я знаю, язык Modula-2. Для которого действительно существуют (до сих пор) компиляторы промышленногог качества типа XDS. Казалось бы, при чем тут Оберон? Дело в том, что Оберон — это такой угол для программистов, в котором они должны стоять и не хныкать, потому что, проказники эдакие, не слушаются Вирта. Раз уж очередной язык от Вирта содержит, обычно, новые кары и унижения, а не пироги и пышки, (как это бывает в случае разработчиков языков, которые программистов не хотят воспитывать как следует, а балуют сладостями) — реализовать его, имея релизацию предыдущего, не так и сложно. Поэтому его и реализовали "чтоб было". Ни кто же не знал, что Оберон не нужен. Понятно, что раз разработчики какого-нибудь ГЛОНАССа используют компилятор модулы и оберона, то было бы как-то странно со стороны оберон-фанатиков не трубить о том, что используется оберон, нес па? И даже если действительно используется Оберон, то используется он, как подсказывает здравый смысл, из-за совместимости с имеющимся Модула-кодом, а не из-за каких-то мифических преимуществ Оберона перед нормальными языками.

C>ML-семейство — они обратно совместимы.

Нет, не совместимы. Правда, зависит от того, что считать ML-семейством. Если это многочисленные реализации SML со своими расширениями языка, и какие-то диалекты типа SML# (не имеет к .net никакого отношения) и Alice — то кое-какая совместимость есть. Можно, также, вполне представить себе кусок кода, который скомпилируется и OCaml и F# (в режиме совместимости с окамлом), но с нетривиальной программой так не получится, потому что в F# нет эмэльных параметризуемых модулей/функторов, да и ОО-подсистемы у них совсем разные. Сходство между SML и OCaml весьма отдаленное, а про Haskell, который некоторые классификаторы к ML-семейству причисляют как-то неудобно и говорить. Некоторое синтаксического сходство у него с SML есть, но семантическое — как у фортрана с прологом, примерно.

Здравствуйте, Klapaucius, Вы писали:

FR>>вирус Вирта скажем в отличии от вируса Александреску вызывает в основном не написание кода,
FR>>а написание статей, защиту диссертаций и
K>А можно как-нибудь подтвердить обилие статей и диссертаций на тему, а то я его как-то не заметил.
Есть-есть. Тот же пресловутый ActiveOberon — это то, что немного выросло из дисера.
http://bluebottle.ethz.ch/languagereport/node5.html#Gut97

P. Fröhlich.
Projekt Froderon: Zur weiteren Entwicklung der Programmiersprache Oberon-2.
Master's thesis, Fachhochschule München, 1997.

Правда, кроме дисеров особо больше ничего и нету.

Здравствуйте, Klapaucius, Вы писали:

C>>ML разрабатывался в конце 70-х годов. На примере ML обычно обкатывались алгоритмы GC и других способов управления памятью (типа region inference).
K>Ну да. ФЯ очень любят возраст натягивать. ML разрабатывался, разрабатывался и разработался как следует только к началу 90-х. При этом алгебраические типы и паттерн-матчинг для которых он якобы "является "родиной"" (кавычки поставлены не зря) попали в него из другого языка (Hope, если интересно).
"Родину" в кавычки я сам поставил. Но таки ML-семейство сделало их популярными.

K>А region inference вовсе в 2000-ных обкатывали.
Конец 80-х: http://en.wikipedia.org/wiki/Region-based_memory_management#Region_inference

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

C>>Так, а теперь вопрос ребром:
C>>ГДЕ КОД НА ОБЕРОНЕ?
K>А разгадка проста: в "космических разработках" действительно применяют, насколько я знаю, язык Modula-2. Для которого действительно существуют (до сих пор) компиляторы промышленногог качества типа XDS.
Про Модулу-2 вопросов как раз нет. Но у меня большие сомнения, что используется именно Оберон, так как он сильно заточен на динамическую память и GC.

К примеру, поддерживаемых компиляторов Оберона в природе сейчас не находится.

C>>ML-семейство — они обратно совместимы.
K>Нет, не совместимы. Правда, зависит от того, что считать ML-семейством.
Семейство SML. Понятно, что .NET-вариации не будут совместимы. Ну и Хаскелл — это нифига таки не ML.

Здравствуйте, Cyberax, Вы писали:

C>А теперь для каждого -1 — доказательство со ссылками на исходный код ОберонОС. Слабо?
Кстати, теперь есть "Проект Оберон" и на русском.. где тексты почти все опубликованы...
И репозиторий у оберонщиков вроде как свой как основной... впрочем, тут уже говорили...

Здравствуйте, Cyberax, Вы писали:

K>>А можно как-нибудь подтвердить обилие статей и диссертаций на тему, а то я его как-то не заметил.
C>Есть-есть.

Я знаю, что они есть. Я сомневаюсь, что их количество значительно.

Здравствуйте, Cyberax, Вы писали:

C>"Родину" в кавычки я сам поставил.

Ну я так и написал, что кавычки правильно поставлены. Суть же возражения в том, что "языки ML семейства" — как эти слова не понимай — это языки, более-менее сформировавшиеся и получившие хоть сколько нибудь практичные реализации скорее в 90-е годы, а вовсе не в 70-е. И судить о ML-е 70-х по SML 97 — это примерно то же самое, что судить о C 70-х по C++11.

C>Но таки ML-семейство сделало их популярными.

К сожалению, популярными они пока не стали.

K>>А region inference вовсе в 2000-ных обкатывали.
C>Конец 80-х: http://en.wikipedia.org/wiki/Region-based_memory_management#Region_inference

То, что было до MLKit едва ли можно назвать "обкатывали".

C>Оберон может быть немного моложе, но не сильно.

ОК, когда появился Оберон (и Оберон-2) понятно. А когда, по-вашему, появился хаскель? В википедии указан 90-й год — это время публикации первого описания языка, который не особенно похож даже на Haskell 98. В нем, к примеру, не просто отсутствуют монады в стандартной библиотеке — такие классы типов на этом языке вообще описать невозможно. Может это был 96-й, когда привычный теперь хаскель-минимум уже появился? Или 99 (да, Haskell 98 — стандарт 99-го года, если не 2002, считая дополнения по FFI), когда он был "стандартизирован"? Или 2001-й, когда была в первом приближении решена, наверное, основная дизайн-проблема хаскеля с многопараметрическими классами типов (во втором приближении она только сейчас решается). Или примерно 2008, когда появилось уже то, что сейчас собственно под хаскелем и понимают? Может 2010-й, когда реализацию можно уже назвать практичной, без особых оговорок? Если в Виртовском языке хоть что-то меняется — его уже называют по-другому. В случае хаскеля же требуются дополнительные пояснения, потому что различия между языками, компилируемым GHC 7.0 и GHC 7.4 (16 месяцев разницы) больше различий между паскалем и обероном-2.

C>Про Модулу-2 вопросов как раз нет. Но у меня большие сомнения, что используется именно Оберон, так как он сильно заточен на динамическую память и GC.
C>К примеру, поддерживаемых компиляторов Оберона в природе сейчас не находится.

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

C>Семейство SML. Понятно, что .NET-вариации не будут совместимы.

Ничего особо понятного тут нет — для .net была реализация нормального sml.

C>Ну и Хаскелл — это нифига таки не ML.

Это-то очевидно. А OCaml — ML? К "SML семейству" он точно не относится.

Здравствуйте, FR, Вы писали:


FR>Контекст тут не имеет значения, извини (понимаю в пылу спора), но ты ляпнул феерическую глупость про "недопитизированный ocaml".
FR>Ладно бы ты сравнивал с какой нибудь агдой, но с паскалем или обероном, да они все слабо типизированые относительно OCamla или SML.

Дык, теперь ты заявляешь глупость относительно Оберона. Он ничуть не меньше типизирован. Это в Паскале и Объектном Паскале возможны опасные преобразования типов, а в Обероне — нет.


FR>Если будет бегать по памяти относительные расходы на арифметику будут стремится к нулю.

Если брать какую-нить линейную пробежку по массиву — то не будет.


V>>Ну вот как раз что тогда паскалевские программы работали быстрее сишных, что сейчас оберон быстрее окамла. Еще раз, я не выбирал этот язык для обсуждения, мне им пару раз неграмотно ткнули.
FR>Кстати что оберон быстрее окамла еще доказать надо, мне например интересно было бы тесты посмотреть.

Кто мешает мешает нарисовать и посмотреть?


FR>>>Но в любом случае редизайн необходим, без многопоточности сейчас уже никуда.

V>>Угу, особенно если учесть, что спор зашел с упоминания возможностей Активного Оберона, где не просто многопоточность, а целая философия:
V>>- безопасный язык, способный компиллироваться в оптимизируемый нейтивный код;
V>>- плоская память;
V>>- миллионы дешевых агентов;
V>>- GC на уровне ОС;
V>>- бесплатное переключение контекстов из пользовательского кода в ядерный и обратно;
V>>- юзер-левел асинхронность, подерживаемая на уровне шедуллера ОС;
V>>- эффективнейший в природе ввод-вывод и обмен данными м/у процессами.

FR>Active Oberon это уже 2000 год когда все это было далеко не новостью.

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


FR>Если уж так охота сравнить можно сравнить форк Active Oberon для NET — Zonnon и форк OCaml' для того же NET — F#.

Zonnon является форком АО с очень большой натяжкой. Исходный АО без специальной операционки под него не имеет смысла. Совсем.


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

Пример Джавы показывает, что не промахнулся. А так же этот пример как и пример дотнета показывает, что для популярности новых языков/платформ одного языка мало, надо давать мильон бесплатных библиотек, чтобы заинтересовать хомячков.

Положа руку на куда-нибудь, мне кажется, что основная ошибка Вирта — это его синтаксис из Модулы. Как не смешон был тред о синтаксическом оверхеде... Но таки стабильно Си-подобный синтаксис или ML-синтаксис становились все более популярными. Никто не мешал Вирту разработать совместимого по компонентной модели близнеца-брата для Оберона в Си-подобном и/или ML-подобном синтаксисе и "влиться в струю". ИМХО, шансов на популярность было бы намного больше.

Здравствуйте, Klapaucius, Вы писали:

K>>>А можно как-нибудь подтвердить обилие статей и диссертаций на тему, а то я его как-то не заметил.
C>>Есть-есть.
K>Я знаю, что они есть. Я сомневаюсь, что их количество значительно.
Оно заметно больше объёма кода на Обероне.

Здравствуйте, vdimas, Вы писали:

V>Положа руку на куда-нибудь, мне кажется, что основная ошибка Вирта — это его синтаксис из Модулы. Как не смешон был тред о синтаксическом оверхеде... Но таки стабильно Си-подобный синтаксис или ML-синтаксис становились все более популярными.

Ничего смешного тут нет. Это грустно. Смысл синтаксиса в том, чтоб было удобно что-то делать. Синтаксис Си удобен для написания копирования строк, оканчивающихся нулем. Синтаксис ML удобен для применения функций и комбинирования комбинаторов. Синтаксис алгола 60, который Вирт потом последовательно ухудшал, не разрабатывался с какой-бы то ни было целью. Это был первоначальный набросок, от которого потом довольно быстро ушли. Собственно, и ML-ный синтаксис (через ISWIM и Hope) и Сишный (через алгол 68 и CPL) произошли от синтаксиса алгол 60, но изменения делались с целью сделать что-то удобно. Изменения которые делал Вирт, по всей видимости, делались с целью "показать им всем". Результат очевиден.