Здравствуйте, vdimas, Вы писали:
V>Нужен. На С++ вообще удобно по памяти бегать в одну строчку кода. ANSIZ cтроки — частный случай.
А по-моему, все заточено под блоки памяти, оканчивающиеся нулем. Для работы с просто блоками памяти удобный синтаксис для работы с диапазонами подходил бы лучше.
V>У Оберона философия навроде джавы, только чуть удобней.
Ну да. У Джавы философия заключается в том, что все программисты глупы, а у оберона в том, что Вирт знает как лучше. Первое обидно, но для всех, а потому демократично. А второе просто обидно. Но это не причина неуспеха. По крайней мере, у питона философия та же, только вместо Вирта — Ван-Россум. А питон вполне успешен. Причина неуспеха в том, что Вирт не знает как лучше.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
> V>Нормальному спецу язык должен быть до лампочки.
Ты там на бороду себе что ли наступил, так ругаешься?
В давние-давние времена, когда языки были простыми, библиотек было две или три, а фреймворков вообще не было, грамотный специалист мог писать на любом языке. Сейчас такого нет. Вылезай из музея.
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, AlexRK, Вы писали:
K>>>Ничего смешного тут нет. Это грустно. Смысл синтаксиса в том, чтоб было удобно что-то делать. Синтаксис Си удобен для написания копирования строк, оканчивающихся нулем. ARK>>То есть в настоящее время он не нужен?
K>В языках, на которых не пишут в основном код, копирующий строки, заканчивающиеся нулем — нет, не нужен. Нужен синтаксис облегчающий написание того, что в основном и пишут.
Как я понимаю, сейчас сильно редко на С++ пишут код для копирования строк, заканчивающихся нулем. Сталбыть, не нужен С-подобный синтаксис нигде?
ARK>>Хм. А что именно Вирт ухудшил?
K>Навскидку — КРИЧАЩИЕ КЛЮЧЕВЫЕ СЛОВА. В алголах, насколько я помню, способ выделения ключевых слов среди прочих оставался на усмотрения имплементатора. Вирт (впрочем, не исключено, что это кто-то другой придумал) безошибочно выбрал и зафиксировал неправильный способ, а все остальные — правильный.
В принципе, тут можно согласиться, хотя я особого криминала не вижу в верхнем регистре.
K>Справедливости ради нужно сказать, что синтаксические улучшения по сравнению с алголом все-таки есть. Например, "идентификатор : Тип" у Вирта (но это точно не он придумал) против "Тип идентификатор" в алголе.
Понятно. А создатели С что придумали хорошего, кроме птичьих операторов (++, --, ==, ||, &&, **, etc.), ну и криптованного синтаксиса в целом?
ARK>>И, кстати, можете обосновать, что цели не было, или это ваши домыслы?
K>Была цель или нет установить невозможно — в голову (на нашем этапе технического развития) не загляшешь. Зато известен результат, совпадающий с тем, что бывает при отсутствии цели.
Это вы лихо по результату вычислили аргументы. Интересный метод.
Кстати, и результат не самый плохой. Язык достаточно широко известен и кое-где вроде бы даже применяется.
Здравствуйте, vdimas, Вы писали:
V>Нет у тебя никаких иммутабельных мейлбоксов.
У меня нет, но ты вроде утверждаешь что это полное г... и в активном обероне активные объекты работают по другому. Покажи как.
N>>Можно переписать мой код? V>Он у тебя не целиком. V>Где та часть, что пишет в канал?
Думал она самоочевидна, но если нет, то вот:
chanExample = do
c <- newChan
forkIO $ agent c 0
forkIO $ writer c [1..10]
forkIO $ writer c [10..1]
writer :: Chan Int -> IO ()
writer c s = forM_ s $ \e -> writeChan c e >> threadDelay e
agent :: Chan Int -> Int -> IO ()
agent c sum = do n <- readChan c
let newsum = sum + n
print newsum
agent c newsum
Здравствуйте, vdimas, Вы писали:
C>>Ну вот. ЛИСП рулит, Оберон — ацтой. V>Лисп рулит как ровно настолько, насколько может рулить ассемблер байткода.
Можно посмотреть на emacs на Обероне?
Спасибо.
V>>>На обсуждаемых гарвардских архитектурах интерпретаторы и прочие байт-коды чувствуют себя крайне неуютно. C>>ЛИСП может компилироваться. Для указанных космических аппаратов так и делалось. V>Не может Лисп компиллироваться, не говори ерунды.
Может. С помощью вывода типов и их явной аннотации.
Плюс к этому — динамическая рекомпиляция при необходимости, как сейчас для JS делают.
C>>>>3) На Окамле для PIC'ов тоже можно писать, как и на Java (см. Java Card). V>>>Можно не значит нужно. C>>Ага, см.: "Оберон" V>Если работает на сравнимых с Си объемах памяти, то вполне можно. А если OCaml так не умеет
Умеет. Тебе уже привели ссылку.
Здравствуйте, AlexRK, Вы писали:
ARK>Как я понимаю, сейчас сильно редко на С++ пишут код для копирования строк, заканчивающихся нулем. Сталбыть, не нужен С-подобный синтаксис нигде?
Да это вообще не важно — нужен он сейчас или нет. Сейчас уже этот синтаксис, к сожалению, популярен и приходится есть кактус. Важно то, что хоть какой-то код, написанный на C может выглядеть хорошо (или выглядел хорошо в свое время) и это создало необходимый рекламный эффект для раскрутки синтаксиса. Вирт же этого, по видимому, не понимает. Его синтаксис не выглядит хорошо ни в каком случае. Вместо того, чтоб изменить его соотвествующим образом, он доказывает, что он и должен выглядеть плохо. Т.е все так и запланировано. Можно сколько угодно доказывать людям, что быть бедным и больным лучше, чем богатым и здоровым — эффекта не будет никакого. Зато можно обманом склонить людей к этому, приманить эффектной приманкой и потом они сами всем будут доказывать, что бедным и больным быть лучше — когда у них выбора не будет. Если выбора нет, базу подведут под что угодно, чтоб обосновать что вот это единственное — и есть то что нужно. Вирт же сначала пытается подвести базу под нездоровые идеи, но пока идеи эти не стали общераспространенными — от них можно просто промахнуться.
Впрочем, то, что Вирт не способен заставить делать так как он считает нужным хоть сколько нибудь заметное кол-во людей — это положительная черта, это делает его безвредным.
ARK>Понятно. А создатели С что придумали хорошего, кроме птичьих операторов (++, --, ==, ||, &&, **, etc.),
Не уверен, что это он (Ричи) их все придумал. К тому же, ничего плохого в них нет.
ARK>ну и криптованного синтаксиса в целом?
Я бы не сказал, что он в целом "криптованный". В частностях (вроде аннотации типов, особенно в случае указателей на функции) да, а в целом все просто.
ARK>Кстати, и результат не самый плохой. Язык достаточно широко известен и кое-где вроде бы даже применяется.
Результат хуже некуда. Известен он, в основном, как какой-то нелепый язык из глубин прошлого, который пропагандируется зелотами, кидающимися на людей по TCP/IP, чтоб их покусать. Ну и, соотвественно, короткий ассоциативный ряд от "Оберон" до "Диантетика", "Heaven's Gate", "Газовая атака в Токийском метро".
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, AlexRK, Вы писали:
ARK>>Как я понимаю, сейчас сильно редко на С++ пишут код для копирования строк, заканчивающихся нулем. Сталбыть, не нужен С-подобный синтаксис нигде?
K>Да это вообще не важно — нужен он сейчас или нет. Сейчас уже этот синтаксис, к сожалению, популярен и приходится есть кактус.
Это верно.
K>Его синтаксис не выглядит хорошо ни в каком случае. Вместо того, чтоб изменить его соотвествующим образом
Не думаю, что синтаксис Вирта выглядит плохо, за исключением спорного обероновского решения о верхнем регистре. Лично мне Pascal-подобный синтаксис нравится больше C-подобного. Он более последователен и менее подвержен разночтениям.
ARK>>Понятно. А создатели С что придумали хорошего, кроме птичьих операторов (++, --, ==, ||, &&, **, etc.),
K>Не уверен, что это он (Ричи) их все придумал. К тому же, ничего плохого в них нет. K>Я бы не сказал, что он в целом "криптованный". В частностях (вроде аннотации типов, особенно в случае указателей на функции) да, а в целом все просто.
Ну не знаю, не знаю. У меня от этих значков и крючков в глазах рябит. Кажется, нет ни одного спецсимвола, который бы не применялся в алфавите C, а некоторые еще и особо извращенным образом (таки да, всякие формы указателей).
ARK>>Кстати, и результат не самый плохой. Язык достаточно широко известен и кое-где вроде бы даже применяется.
K>Результат хуже некуда.
Я бы все-таки сказал, что хуже некуда — это у прорвы языков, канувших в лету. Оберон к таким явно не относится.
K>Известен он, в основном, как какой-то нелепый язык из глубин прошлого, который пропагандируется зелотами, кидающимися на людей по TCP/IP, чтоб их покусать. Ну и, соотвественно, короткий ассоциативный ряд от "Оберон" до "Диантетика", "Heaven's Gate", "Газовая атака в Токийском метро".
Это, наверное, только на RSDN.
А вот, например, создатели Go вряд ли так думают.
Здравствуйте, AlexRK, Вы писали:
ARK>Не думаю, что синтаксис Вирта выглядит плохо, за исключением спорного обероновского решения о верхнем регистре. Лично мне Pascal-подобный синтаксис нравится больше C-подобного.
Это понятно.
ARK>Он более последователен и менее подвержен разночтениям.
А вот это — попытка подвести базу под вкусовщину. Последовательность не измеришь, да и кашу из нее не сваришь: что толку, что синтаксис "последовательный", если код многословный и обвешанный ничего не значащими финтифлюшками.
ARK>Ну не знаю, не знаю. У меня от этих значков и крючков в глазах рябит. Кажется, нет ни одного спецсимвола, который бы не применялся в алфавите C, а некоторые еще и особо извращенным образом (таки да, всякие формы указателей).
Ну так что плохого-то? Я еще понял бы, если б альтернатива была в возможности применять префиксно/инфиксно/постфиксно функции с буквенными идентификаторами. А реализовывать, например, постинкремент как префиксную операцию — это анекдот вроде фотографии, на которой на две трубы одного цвета приклеены таблички "красная" и "синяя".
ARK>Я бы все-таки сказал, что хуже некуда — это у прорвы языков, канувших в лету. Оберон к таким явно не относится.
Я пронимаю, конечно, что есть мнение, будто бы разницы между рекламой и антирекламой нет, но я его не разделяю. Отрицательнае коннотации хуже, чем полная неизвестность.
ARK>Это, наверное, только на RSDN.
Ну а там, где не изестен в таком ключе — не известен вообще. Пример:
stackoverflow.com
[oberon] 7 вопросов, 7 фолловеров.
эзотерический [haskell] 7436 вопросов, 3.8k фолловеров.
мейнстримная [java] 269977 вопросов 28.8k фолловеров.
ARK>А вот, например, создатели Go вряд ли так думают.
Я бы попросил ссылку на одобрительные высказывания Роба Пайка об Обероне, да вот только я не могу заботиться меньше о мнении Роба Пайка.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, vdimas, Вы писали:
V>- безопасный язык, способный компиллироваться в оптимизируемый нейтивный код;
Не новость.
V>- плоская память;
Единое объектное пространство на всю систему это приговор масштабируемости и безопасности.
Ну и возможность уронить всю ОС одним кривым модулем. Re[41]: Нужна ли Оберон-ОС защита памяти?
При этом в сингулярити с этим проблем нет.
Если один процесс начнет жрать память его можно просто прибить. Можно даже на каждый процесс повесить ограничение по памяти.
Бутылка так не может.
А еще сингулярити можно запустить на кластере.
Распределив процессы между узлами.
Процессы драйверов конечно будут прибиты к конкретным железкам. Но все остальные процессы можно прямо во время работы переносить между узлами. Причем даже если на узлах процессоры разные.
Бутылка так тоже не может.
V>- миллионы дешевых агентов;
Не новость.
V>- GC на уровне ОС;
Очень плохо.
Ибо сборка мусора будет тормозить всю ОС.
В сингулярити свой мусорщик на каждый процесс. Причем в разных процессах могут быть разные алгоритмы. Могут быть даже процессы совсем без мусорщика.
V>- бесплатное переключение контекстов из пользовательского кода в ядерный и обратно;
Там нет контекстов.
V>- юзер-левел асинхронность, подерживаемая на уровне шедуллера ОС;
Там нет юзерлевел.
И асинхронности в твоем "понимании" там тоже нет.
V>- эффективнейший в природе ввод-вывод и обмен данными м/у процессами.
Который построен на механизмах делающих ОС неработоспособной.
А ведь можно добиться того же не ломая изоляцию.
Авторам сингулярити это удалось.
Еще со старых флеймов остался вопрос, что делать, если нам нужно несколько копий одного модуля? Ведь в модулях есть состояние. Считай глобальные переменные на всю ОС. А если еще и разных версий?
Ну и если я ничего не путаю, модули распространяются в виде исполняемого кода. И грузяться без проверки. И изоляции нет. Привет вирусам.
В сингулярити этой проблемы нет. А в verve вообще тотальная верификация.
V>Кароч, я действительно некорретно себя вёл, что повелся на провокации и вообще что-то там обсуждал с людьми, которые представляли суть АОС как набор локов, мьютексов и прочего своего беспробудного невежества...
Тут про это прямым текстом пишут. http://bluebottle.ethz.ch/languagereport/node3.html#SECTION00031000000000000000
V>Показанный выше список — это непременный атрибут будущих ОСей на многих ядрах. Уже прямо сейчас с этим глупо спорить. Иначе многоядерность не взлетает, увы. Ес-но, в будущих разработках это может быть доведено до совершенства... но называть устаревшими идеи ПО будущих поколений, да еще в такой хамовитой манере — это был явный перебор.
Учитывая, что ты не понял, почему бутылка в реальных условиях работать не может...
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, AlexRK, Вы писали:
ARK>>Он более последователен и менее подвержен разночтениям.
K>А вот это — попытка подвести базу под вкусовщину. Последовательность не измеришь, да и кашу из нее не сваришь: что толку, что синтаксис "последовательный", если код многословный и обвешанный ничего не значащими финтифлюшками.
Да нет. С-синтаксис содержит больше слабых мест. Fallthrough в switch (это вообще за гранью добра и зла), путаница с объявлением указателей (char* s1, s2) и прочая. Оберон многословный — ну и ладно, не вижу криминала в этом...
ARK>>Ну не знаю, не знаю. У меня от этих значков и крючков в глазах рябит. Кажется, нет ни одного спецсимвола, который бы не применялся в алфавите C, а некоторые еще и особо извращенным образом (таки да, всякие формы указателей).
K>Ну так что плохого-то? Я еще понял бы, если б альтернатива была в возможности применять префиксно/инфиксно/постфиксно функции с буквенными идентификаторами. А реализовывать, например, постинкремент как префиксную операцию — это анекдот вроде фотографии, на которой на две трубы одного цвета приклеены таблички "красная" и "синяя".
Что плохого? Ну не особо читабельно оно, на мой вкус (и не только на мой). А постинкремент можно и обычной функцией реализовать.
ARK>>Я бы все-таки сказал, что хуже некуда — это у прорвы языков, канувших в лету. Оберон к таким явно не относится.
K>Я пронимаю, конечно, что есть мнение, будто бы разницы между рекламой и антирекламой нет, но я его не разделяю. Отрицательнае коннотации хуже, чем полная неизвестность.
ARK>>Это, наверное, только на RSDN.
K>Ну а там, где не изестен в таком ключе — не известен вообще. Пример: K>stackoverflow.com K>[oberon] 7 вопросов, 7 фолловеров. K>эзотерический [haskell] 7436 вопросов, 3.8k фолловеров. K>мейнстримная [java] 269977 вопросов 28.8k фолловеров.
ARK>>А вот, например, создатели Go вряд ли так думают.
K>Я бы попросил ссылку на одобрительные высказывания Роба Пайка об Обероне, да вот только я не могу заботиться меньше о мнении Роба Пайка.
Пайк признавал, что взял из Оберона ряд концепций.
Blockly is a visual programming editor from Google.
Blockly was developed by Neil Fraser, who has appeared previously on Metafilter.
posted by alby (93 comments total) 40 users marked this as a favorite
В этом обсуждении, в частности, упомянут и ДРАКОН:
The programming for the russian space program was done
in a visual programming language DRAKON.
posted by Ad hominem at 11:32 AM on June 19 [3 favorites]
Здравствуйте, Klapaucius, Вы писали:
V>>какой смыл сравнивать язык с мутабельными переменными в кач--ве представителя функционального лагеря. Это же профанация. K>Это какие-то странные предрассудки.
Исходно зацепились за это:
V>В Хаскеле даже продолжений нормальных нет, а они являются необходимым элементом для иммутабельных языков, чтобы те умели работать в агентской среде.
Как вывод: в Хаскель необходимо добавить либо мутабельный тип данных, либо продолжения. Насколько я вижу, то бишь не вижу ничего интересного на Concurrent Haskell, попытка пойти по пути наименьшего сопротивления (добавления мутабельного типа данных) не вызвала поддержки масс. Предлагаю эксперименты с мутабельностью в Хаскеле сразу в топку как противоречащие концепции языка и сделать таки нормальные продолжения. ))
Здравствуйте, novitk, Вы писали:
V>>Нет у тебя никаких иммутабельных мейлбоксов. N>У меня нет,
Поторопимшись ты утверждал, что есть.
N>но ты вроде утверждаешь что это полное г... и в активном обероне активные объекты работают по другому.
Ес-но, по другому чем в чистых ф-ых языках. Уже полностью расшифровал "до самого дна", в чем отличие. Вопросы?
N>Покажи как.
Гы, а что с чем ты хотел сравнить? Один императивный язык с другим? Молодец. И это там, где речь была о принципиальном отличии подходов к асинхронности в языках с иммутабельностью. А то, что ты показал, Хаскелем никак не является, не смотря на плагиат в одном из слов в названии. Это просто императивный язык с хаскелеподобным синтаксисом. И не факт, что хаскелеподобный синтаксис так уж удобен для императивности. Просто ты не понял философия Хаскеля — его выразительность заведомо заточена под чистые ленивые вычисления и тут он фактически вне конкуренции. А иначе такой Хаскель не нужен, хотя бы из-за "синтаксического оверхеда". Сравни исходный пример с банковским счетом
Вот эффект того, что императивные операции встроены в язык, а не стеснительно проэмулированы через одно место, как в Concurrent Haskell...
N>>>Можно переписать мой код? V>>Он у тебя не целиком. V>>Где та часть, что пишет в канал? N>Думал она самоочевидна, но если нет, то вот:
Это было нужно не мне, а тебе, т.к. ты поначалу считал, что мейлбоксы иммутабельны. И да, тебе было бы всяко полезней посмотреть на устройство readChan, writeChan, чем на высокоуровневый пример на их основе.
Здравствуйте, Klapaucius, Вы писали:
K>Легкие потоки и продолжения не одно и то же.
Фактически одно и то же когда продолжения делаются не в языке-интерпретаторе, а в компиллируемом в нейтивный код. В этом случае продолжения делаются именно через полное дублирование контекста исполнения (и "родного" стека машины в т.ч.). Разница лишь в том, какой вид многозадачности доступен в такой системе — кооперативный, или полноценный с вытеснениями. ИМХО, для обсуждаемой задачи, когда агенты должны постоянно сидеть в ожидании сигналов ввода-вывода каналов (прямо по условию) разница м/у видами многозадачности не столь принципиальна.
Здравствуйте, grosborn, Вы писали:
G>Ты там на бороду себе что ли наступил, так ругаешься? G>В давние-давние времена, когда языки были простыми, библиотек было две или три, а фреймворков вообще не было, грамотный специалист мог писать на любом языке. Сейчас такого нет. Вылезай из музея.
В обсуждаемом embedded это практически всегда так. Никаких библиотек, размерность исходной задачи заведомо меньше размерности тестирования и т.д.
Здравствуйте, Klapaucius, Вы писали:
V>>Нормальному спецу язык должен быть до лампочки.
K>А вот это — серьезная ошибка.
Увы, бывают такие области, где акценты расставлены не так, как ты привык. По моему опыту — сложность собственно кодирования невелика в embedded. Все-равно задачи обыгрываются на модели (из области цифровой радиосвязи, например), много математики и т.д. Разница трудозатрат, даваемая языками исполнения не видна и под микроскопом в общем объеме труозатрат. Ну и к тому же всегда было стремление породить минимальный футпринт, это влияло на стоимость подходящего чипа.
Здравствуйте, Cyberax, Вы писали:
V>>Лисп рулит как ровно настолько, насколько может рулить ассемблер байткода. C>Можно посмотреть на emacs на Обероне?
Дык, BlakcBox как бэ многократно покруче будет.
C>Спасибо.
Да не за что.
V>>Не может Лисп компиллироваться, не говори ерунды. C>Может.
Ну ты бы хотя б посмотрел на то, что производят лучшие компиляторы Схемы. Да, кое-где (мало где) идет прямо машинный код, а по большей части встроенный в конечный образ движок выполняет eval значений динамического типа.
C>С помощью вывода типов и их явной аннотации.
Я так и думал, что имел ввиду какой-то другой язык, в котором тоже много скобок.
C>Плюс к этому — динамическая рекомпиляция при необходимости, как сейчас для JS делают.
К чему плюс-то? )))
V>>Если работает на сравнимых с Си объемах памяти, то вполне можно. А если OCaml так не умеет C>Умеет. Тебе уже привели ссылку.
Угу, привели. Взяли 512 ОЗУ байт для минимального примера. Для реального там нужны будут килобайты. Как раз во времена обсуждаемого Оберона чипы с таким объемом памяти стоили 3-5-ти раз дороже стандартного.
Здравствуйте, Klapaucius, Вы писали:
K>Ну т.е. тем, кто пишет на модуле для контроллеров переходить на оберон нет смысла, потому что полезные для этого вещи, имеющиеся в модуле, из оберона выкинуты (убраны вариантные типы, урезана функциональность указателей и т.д.)
В Обероне с указателями все-нормально. Мне эта идея нравится точно так же, как типизированные файлы ввода-вывода. Невозможно ошибиться.
K>а то, что появилось нового, по сравнению с модулой — использовать в контролерах нельзя.
А что там нового? Просто шлифовка. Упрощенное описание интерфейса импорта модулей разве нельзя использовать?
Здравствуйте, Klapaucius, Вы писали:
V>>Нужен. На С++ вообще удобно по памяти бегать в одну строчку кода. ANSIZ cтроки — частный случай. K>А по-моему, все заточено под блоки памяти, оканчивающиеся нулем. Для работы с просто блоками памяти удобный синтаксис для работы с диапазонами подходил бы лучше.
Есть и так и как угодно. Да и несерьезно обсуждать отличия навроде таких:
V>>У Оберона философия навроде джавы, только чуть удобней. K>Ну да. У Джавы философия заключается в том, что все программисты глупы, а у оберона в том, что Вирт знает как лучше. Первое обидно, но для всех, а потому демократично. А второе просто обидно.
Спасибо, поржал. Без иронии, просто прикольный ход мыслей.
K>Но это не причина неуспеха. По крайней мере, у питона философия та же, только вместо Вирта — Ван-Россум. А питон вполне успешен. Причина неуспеха в том, что Вирт не знает как лучше.
Обилие языков программирования и бесконечный процесс их изобретения говорит о том, что никто не знает как лучше. Тем не менее, общие принципы в современных императивных языках шлифовались не без заимствований... и у Вирта в т.ч.
