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

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

12. The Module SYSTEM

facilities to break the data type compatibility rules otherwise imposed by the language definition.

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

Ну это естественно В диссертациях есть синтаксический оверхед, а в в Обероне — нет. Очевидно же

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

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

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

K>Ничего смешного тут нет. Это грустно. Смысл синтаксиса в том, чтоб было удобно что-то делать. Синтаксис Си удобен для написания копирования строк, оканчивающихся нулем.

То есть в настоящее время он не нужен?

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

Хм. А что именно Вирт ухудшил?
И, кстати, можете обосновать, что цели не было, или это ваши домыслы?

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

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

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


FR>При том тот же виртовский паскаль (его потомки) вполне жив, и даже модула местами еще шевелится:
FR>

Увы, популярные VCS не подходят для Оберона, поэтому сравнивать в приведенном тобой виде абсолютно бесполезно. Я не говорю, что одобряю такое положение дел, просто констатирую факт. Точно так же ты не найдешь кучи проектов на VBA (именно VBA, а не VB), хотя таких проектов немеряно были и есть. Просто потому что файлы Офиса неудобно было хранить в популярных бесплатных VCS. И ведь до дотнета проекты на VB и VBA на западе абсолютно лидировали в общем кол-ве коммерческих проектов. Просто есть коммерческие VCS, которые умеют в т.ч. офисные док-ты со встроенным VBA-кодом.


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

Не знаю, не знаю... Тот же BlackBox в куда высокой степени готовности находится, чем один из самых сложных аналогичных опен-сорсовых проектов — MonoDevelop, да и тот вовсе не с 0-ля писан, а форк другой относительно старой среды разработки. Гораздо лучше из всех опенсорсов выглядит только Eclipse, в который IBM и Co вкладывали немерянную кучу ресурсов в 2000-е.

Ну и опять же, ссылки на проекты на Обероне уже давали. Просмотрев все эти проекты их можно накрыть одним общим определением "требуется надежность". Заметь, в опенсорсе этого вообще никогда не требуется... Т.е. непонятно что с чем сравнивать.

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

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

Ну, посмотрел, увидел добавленные в язык мутабельные типы данных (MVar):

type Account = MVar Integer
 
credit :: Integer -> Account -> IO ()
credit amount account = do
    current <- takeMVar account
    putMVar account (current + amount)

Обыкновенная императивная хрень на мутабельных типах данных. Фтопку такой Хаскель.


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

Бери любой мутабельный объект, к которому идут асинхронные вызовы. Я ХЗ что тут может быть непонятного про продолжения и иммутабельность. В условиях иммутабельного кода у нас не может быть явно выраженого в языке состояния, у нас могут быть только потоки исполнения. А состояния могут быть организованы разве что над этими потоками в виде сохраненных продолжений.

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

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

Угу, зачем мне масло, если у меня есть масло.

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

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

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

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

V>>>У самых ходовых моделей 18-й серии (18 ног) доступное для произвольного использования ОЗУ полторы сотни байт +-.
C>>И как же туда влазит АктивныйОберон? Да, со сборщиком мусора, естественно.
V>Активный не влазит, бо он в контроллере не нужен. В контроллерах вообще всё на глобальных переменных, увы и ах. Бо лишняя косвенность и нафик не сдалась в среде, где нет динамической загрузки приложений.
1) Таки влазит при желании.
2) Софт для космических аппаратов писали на ЛИСПе ещё в 80-е годы.
3) На Окамле для PIC'ов тоже можно писать, как и на Java (см. Java Card).
4) Причём косвенности и динамическая загрузка — х.з.

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

V>Обыкновенная императивная хрень на мутабельных типах данных. Фтопку такой Хаскель.
Я не знаю, что ты подразумеваешь под "активными обьектами". ИМХО это зеленые потоки и fifo, что и реализовано в Concurrent Haskell. MVar это просто кирпич для построения fifo (channels) и семафоров.

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

Так как кода ты писать не хочешь, начинать надо мне. Где скажем тут мутация?

chanExample = do
  ch <- newChan
  forkIO $ agent ch 0

agent :: Chan Int -> Int -> IO ()
agent c sum = do n <- readChan ch
                 let newsum = sum + n
                 print newsum
                 agent c newsum

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


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

При желании можно передвигаться раком.


C>2) Софт для космических аппаратов писали на ЛИСПе ещё в 80-е годы.

На обсуждаемых гарвардских архитектурах интерпретаторы и прочие байт-коды чувствуют себя крайне неуютно.


C>3) На Окамле для PIC'ов тоже можно писать, как и на Java (см. Java Card).

Можно не значит нужно.


C>4) Причём косвенности и динамическая загрузка — х.з.

При том, что принципы использования памяти в системах, скомпиленых по жестким адресам, существенно отличаются от привычных тебе. И обсуждаемый АО — это заведомо косвенные адресации на каждый чих. Почему так — медитировать.

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

N>MVar это просто кирпич для построения fifo (channels) и семафоров.

Это просто мутабельная переменная, огорожденная автоматическим локом.


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

N>Так как кода ты писать не хочешь, начинать надо мне. Где скажем тут мутация?

N>

N>chanExample = do
N>  ch <- newChan
N>  forkIO $ agent ch 0

N>agent :: Chan Int -> Int -> IO ()
N>agent c sum = do n <- readChan ch
N>                 let newsum = sum + n
N>                 print newsum
N>                 agent c newsum
N>

В канале, ес-но.
Я ХЗ какой смыл сравнивать язык с мутабельными переменными в кач--ве представителя функционального лагеря. Это же профанация.

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

K>>Ничего смешного тут нет. Это грустно. Смысл синтаксиса в том, чтоб было удобно что-то делать. Синтаксис Си удобен для написания копирования строк, оканчивающихся нулем.
ARK>То есть в настоящее время он не нужен?

Нужен. На С++ вообще удобно по памяти бегать в одну строчку кода. ANSIZ cтроки — частный случай.

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

ARK>Хм. А что именно Вирт ухудшил?
ARK>И, кстати, можете обосновать, что цели не было, или это ваши домыслы?

Домыслы ес-но.
У Оберона философия навроде джавы, только чуть удобней.

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

N>>Так как кода ты писать не хочешь, начинать надо мне. Где скажем тут мутация?

N>>

N>>chanExample = do
N>>  ch <- newChan
N>>  forkIO $ agent ch 0

N>>agent :: Chan Int -> Int -> IO ()
N>>agent c sum = do n <- readChan ch
N>>                 let newsum = sum + n
N>>                 print newsum
N>>                 agent c newsum
N>>

V>В канале, ес-но.
V>Я ХЗ какой смыл сравнивать язык с мутабельными переменными в кач--ве представителя функционального лагеря. Это же профанация.

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

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

V>>>Активный не влазит, бо он в контроллере не нужен. В контроллерах вообще всё на глобальных переменных, увы и ах. Бо лишняя косвенность и нафик не сдалась в среде, где нет динамической загрузки приложений.
C>>1) Таки влазит при желании.
V>При желании можно передвигаться раком.
Ну вот. ЛИСП рулит, Оберон — ацтой.

C>>2) Софт для космических аппаратов писали на ЛИСПе ещё в 80-е годы.
V>На обсуждаемых гарвардских архитектурах интерпретаторы и прочие байт-коды чувствуют себя крайне неуютно.
ЛИСП может компилироваться. Для указанных космических аппаратов так и делалось.

C>>3) На Окамле для PIC'ов тоже можно писать, как и на Java (см. Java Card).
V>Можно не значит нужно.
Ага, см.: "Оберон"

C>>4) Причём косвенности и динамическая загрузка — х.з.
V>При том, что принципы использования памяти в системах, скомпиленых по жестким адресам, существенно отличаются от привычных тебе. И обсуждаемый АО — это заведомо косвенные адресации на каждый чих. Почему так — медитировать.

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

N>Становиться все интересней..В активном обероне значиться обьекты общаются асинхронно при помощи иммутабельных мэйлбоксов.

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


N>Можно переписать мой код?

Он у тебя не целиком.
Где та часть, что пишет в канал?

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

C>Ну вот. ЛИСП рулит, Оберон — ацтой.

Лисп рулит как ровно настолько, насколько может рулить ассемблер байткода.

V>>На обсуждаемых гарвардских архитектурах интерпретаторы и прочие байт-коды чувствуют себя крайне неуютно.
C>ЛИСП может компилироваться. Для указанных космических аппаратов так и делалось.

Не может Лисп компиллироваться, не говори ерунды. 50% возможностей языка — заведомая динамика. Если там была полноценная компиляция, то речь могла идти о другом языке. Даже если у этого языка был синтаксис Лиспа (с высоты птичьего полета), это не делало его Лиспом. Даже банальные замыкания в Лиспе требуют динамики, потому что должны замыкаться by name.


C>>>3) На Окамле для PIC'ов тоже можно писать, как и на Java (см. Java Card).
V>>Можно не значит нужно.
C>Ага, см.: "Оберон"

Если работает на сравнимых с Си объемах памяти, то вполне можно. А если OCaml так не умеет, то брать более дорогой чип лишь бы покодить на выученном языке — это и есть тот самый инженерный идиотизм. Профнепригодность, в общем. Нормальному спецу язык должен быть до лампочки.

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

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

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

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

V>Угу, зачем мне масло, если у меня есть масло.

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

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

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

Это какие-то странные предрассудки.

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

K>>Ничего смешного тут нет. Это грустно. Смысл синтаксиса в том, чтоб было удобно что-то делать. Синтаксис Си удобен для написания копирования строк, оканчивающихся нулем.
ARK>То есть в настоящее время он не нужен?

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

ARK>Хм. А что именно Вирт ухудшил?

Навскидку — КРИЧАЩИЕ КЛЮЧЕВЫЕ СЛОВА. В алголах, насколько я помню, способ выделения ключевых слов среди прочих оставался на усмотрения имплементатора. Вирт (впрочем, не исключено, что это кто-то другой придумал) безошибочно выбрал и зафиксировал неправильный способ, а все остальные — правильный.

Справедливости ради нужно сказать, что синтаксические улучшения по сравнению с алголом все-таки есть. Например, "идентификатор : Тип" у Вирта (но это точно не он придумал) против "Тип идентификатор" в алголе.

ARK>И, кстати, можете обосновать, что цели не было, или это ваши домыслы?

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