Здравствуйте, ironwit, Вы писали:
I>VladD2 пишет:
>> Человек у которого в списке интересов Эрланг стоит сам кому хочешь >> должен все рассказать. I>так я с ним еще не все понял I>только в последней версии добавили имитацию работы драйверов написанных I>на сторонних языках так, как будто они сделаны в ерланге (если я верно I>понял) I>а у меня все драйвера на delphi
Речь про Эрланг? Если да, то непонятно откуда "имитация", а ports и erl_interface уже очень давненько наличествуют, если не с самого начала.
Думаю перевести сишные хэдэры на паскаль нет очень большой проблемы, другое дело, что драйвер "вообще" и эрланговый — очень разные вещи.
Здравствуйте, FR, Вы писали:
FR>Я заглядывал и показалось что что-то не так FR>Вот как бы выкусить оттуда комментарии незнаешь? Там вроде целый препроцессор на перле используется, так что в лоб скриптиком похоже не выйдет. FR>А на глаз их оценить тяжело.
Запускаешь make -f Makefile.alone, и брюки превращаются в элегантные шорты.
Я вот помаялся дурью, чтобы таки определить длину и диаметр.
В исходниках lua-ml мы учитываем только *.ml, т.к. сигнатуры модулей в *.mli полностью дублируются в *.ml и генерируются из одного источника. Далее, мы удаляем автоматически сгенерированные лексер и парсер, вместо них мы будем учитывать только соответствующие *.mll и *.mly:
$ for i in luaparser.mli luaparser.ml luaparsex.mli luaparsex.ml luascanner.ml ; do mv $i $i.auto ; done
Теперь оцениваем версию на C. Сгенерированный парсер тоже удаляем, заголовочные файлы тоже не рассматриваем (просто, чтобы никто не возмущался , по-хорошему надо бы их оставить, т.к. все определения типов находятся там, дублирования, как в случае Окамла, нет):
Курилка пишет: > Здравствуйте, ironwit, Вы писали: > > I>VladD2 пишет: > >> > Человек у которого в списке интересов Эрланг стоит сам кому хочешь >> > должен все рассказать. > I>так я с ним еще не все понял > I>только в последней версии добавили имитацию работы драйверов написанных > I>на сторонних языках так, как будто они сделаны в ерланге (если я верно > I>понял) > I>а у меня все драйвера на delphi > > Речь про Эрланг? Если да, то непонятно откуда "имитация", а ports и > erl_interface уже очень давненько наличествуют, если не с самого начала. > Думаю перевести сишные хэдэры на паскаль нет очень большой проблемы, > другое дело, что драйвер "вообще" и эрланговый — очень разные вещи.
я говорил про это
The Erlang driver API has been extended with a portable POSIX thread
like API for multi-threading. The Erlang driver thread API provides:
threads, mutexes, condition variables, read/write locks, and
thread-specific data. For more information see the erl_driver(3)
documentation.
с http://www.erlang.org/doc/highlights.html
но если в чем то напутал то прошу извинить..., читал обьявление о релизе
на лету, и просто поставил в голове галочку что чтото в ерланге с
драйверами поменялось, надо бы почитать подробнее. вскользь проглянул
про erl_driver(3) documentation, понял что напутал.
Здравствуйте, ironwit, Вы писали:
I>я говорил про это I>
I>The Erlang driver API has been extended with a portable POSIX thread
I>like API for multi-threading. The Erlang driver thread API provides:
I>threads, mutexes, condition variables, read/write locks, and
I>thread-specific data. For more information see the erl_driver(3)
I>documentation.
I>
I>с http://www.erlang.org/doc/highlights.html I>но если в чем то напутал то прошу извинить..., читал обьявление о релизе I>на лету, и просто поставил в голове галочку что чтото в ерланге с I>драйверами поменялось, надо бы почитать подробнее. вскользь проглянул I>про erl_driver(3) documentation, понял что напутал.
Ну изменения есть, факт, меня "сторонние языки" смутили
А про потоки есть инфа здесь
Кстати, может быть у меня тоже появятся задачи код дельфовый интегрить с Эрлангом в следующем году
очень понравилось. R>>Визуально вроде код на С на несколько вспомогательных строчек длиннее, но по сути один в один с Немерле. WH>Влад на это еще тогда ответил...
Ну а что он там ответил?
То, что вот это супер пример-убийца, показывающий неописуемую принципиально неповторимую мега-мощь немерле:
И то, что вот это аналогичный мега-убогий, на 2 порядка худший, принципиально неподдерживаемый код на С++:
case expr::Call:
if ("max" == e.name) Math.Max(e.arg1, e.arg2);
else if ("min" == e.name) Math.Min(e.arg1, e.arg2);
else throw InvalidOperationException(e);
Ты это имеешь в виду?
Кстати, у меня, например, возникают вопросы к некому ".Eval()" в примере на немерле? Уж не убица ли это типизации? И не замена union'ам? А что, если я опишусь и напишу "name.Eval()", при этом в name по счастливому стечению обстоятельств лежит нечто похожее на число?
Аналогичный код на С так никуда и не делся. Субьективные рассуждения про "марально устаревшие языки" не очень интересны.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, FR, Вы писали:
FR>>С (*.с *.h) 194 kb FR>>Ocaml (*.nw) 222 kb FR>>(я еще не копался что там внутри так что если кто раскопает и разъяснит почему буду рад)
WH>На первый взгляд в коде на Ocaml очень сильно больше комментариев чем в сишном коде.
Здравствуйте, palm mute, Вы писали:
PM>Получаем разницу в 2 раза, что и требовалось доказать.
Еще здесь есть неплохие картинки показывающий размер кода (притом оптимизированного на скорость) для разных языков, правда там не компиляторы, а более общий код, что для меня интересней. Разница между ML образными и C++ как раз в полтора — два раза.
Здравствуйте, remark, Вы писали:
WH>>На первый взгляд в коде на Ocaml очень сильно больше комментариев чем в сишном коде. R>Это наталкивает на мысли...
О том что код писался как пример...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, remark, Вы писали:
R>И то, что вот это аналогичный мега-убогий, на 2 порядка худший, принципиально неподдерживаемый код на С++: R>
R> case expr::Call:
R> if ("max" == e.name) Math.Max(e.arg1, e.arg2);
R> else if ("min" == e.name) Math.Min(e.arg1, e.arg2);
R> else throw InvalidOperationException(e);
R>
Нет никаких arg1 и arg2. Вторым параметром идет список. Также нужно вычслить выражения перед тем как их скормить Min/Max
Те как минимум должно быть так:
case expr::Call:
if ("max" == e.name && e.args.size() == 2) Math.Max(eval(e.args[0]), eval(e.args[1]));
else if ("min" == e.name && e.args.size() == 2) Math.Min(eval(e.args[0]), eval(e.args[1]));
else throw InvalidOperationException(e);
И это весьма примитивный пример.
При попытке повторить это у тебя будет ужасное нагромаждение кода
R>Кстати, у меня, например, возникают вопросы к некому ".Eval()" в примере на немерле? Уж не убица ли это типизации?
С какой это стати?
R>И не замена union'ам?
Нет. union'ы не типобезопасны.
R>А что, если я опишусь и напишу "name.Eval()", при этом в name по счастливому стечению обстоятельств лежит нечто похожее на число?
Что значит нечто похожее на число?
Nemerle статически типизированный язык.
Приведения типов в рантайме нужно указывать явно.
R>Аналогичный код на С так никуда и не делся. Субьективные рассуждения про "марально устаревшие языки" не очень интересны.
Они объективны нравится это тебе или нет.
Ибо код на на С сложен для поддержки и восприятия. Код на С практически не контролирует компилятор.
Что скажет компилятор если ты ошибешься с индексами или забудешь else throw ?
Да ничего он не скажет.
И на тестовых примерах вероятно все отработает.
А у клиента все свалится.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
R>>И то, что вот это аналогичный мега-убогий, на 2 порядка худший, принципиально неподдерживаемый код на С++: R>>
R>> case expr::Call:
R>> if ("max" == e.name) Math.Max(e.arg1, e.arg2);
R>> else if ("min" == e.name) Math.Min(e.arg1, e.arg2);
R>> else throw InvalidOperationException(e);
R>>
WH>Нет никаких arg1 и arg2. Вторым параметром идет список. Также нужно вычслить выражения перед тем как их скормить Min/Max WH>Те как минимум должно быть так: WH>
Так это и тут выглядит как "ужасное нагромаждение кода". То, что это удалось запихнуть в 3 строчки, не является показателем хорошести кода. Вполне возможно, что я предпочёл запись этого кода в 10 строк.
R>>Кстати, у меня, например, возникают вопросы к некому ".Eval()" в примере на немерле? Уж не убица ли это типизации? R>>И не замена union'ам? R>>А что, если я опишусь и напишу "name.Eval()", при этом в name по счастливому стечению обстоятельств лежит нечто похожее на число?
Тут беру слова обратно — не разобрался, что такое Eval()
R>>Аналогичный код на С так никуда и не делся. Субьективные рассуждения про "марально устаревшие языки" не очень интересны. WH>Они объективны нравится это тебе или нет. WH>Ибо код на на С сложен для поддержки и восприятия. Код на С практически не контролирует компилятор. WH>Что скажет компилятор если ты ошибешься с индексами или забудешь else throw ? WH>Да ничего он не скажет. WH>И на тестовых примерах вероятно все отработает. WH>А у клиента все свалится.
Писать на С я не призываю. Я лично пишу на С++ и мне нравится. Компилятор контролирует код не меньше, чем в других современных языках, а учитывая распространённость С++, возможно, что и больше.
Индексы я использую редко. Что будет, если ошибусь? Исключение или ассёрт скорее всего. Вообще индексы я использую редко. Они сами по себе провоцируют ошибки. Обнаружение большинства ошибок я стараюсь переносить на фазы компиляции/линковки/стартапа. Имхо смысл иметь исключение, где по сути должен быть ассёрт не много.
Если забуду "else throw" — компилятор предупреждает от неполных switch, отсутствии return, неопределённых виртуальных функциях.
Код на немерле не падает "у клиента"? Даже если неправильно указать индекс?
Здравствуйте, Константин Л., Вы писали:
VD>>Ну, не мучительнее чем бустовский, првада?
КЛ>А я его не читаю. Только хэдэра. От имплементации иногда не по себе, но это случается раз в полгода.
Дык по сложности решаемых задач ему до ядра компилятора далеко. Не странно, что без глубокого погружения в нем мало что понять можно.
Конечно наличие мегафичи дающей информацию о типах жить легче. Но подобные фичи и для плюсов очень полезны. Вот только в тех же плюсах есть сильно недотипизированные куски кода вроде шаблонов (до реального применения во многих местах вообще мало что сказать можно).
К тому же, если тебе нужно ты можешь уточнять типы вручную. Считашь что это повысит читабельность? Вперед...
Лично я когда разбираюсь с нетривиальными кусками даже не поддержкой IDE пользуюсь, а отладчиком. Там все типы известны. Более того там известны реальные данные и можно протросировать неясные участки. Это урощает понимание кода на любом языке.
VD>>А вывод типов из инициализации и в С++ введут. Они вроде его как в Ди "auto" хотят назвать. Чтобы ключевое слово повторно использовать.
КЛ>Введут, и я от этой фичи не в восторге. Разве что для foreach полезна
Зря. Привыкнешь немного и поймешь, что это удбобно.
КЛ>Я не в курсе что такое обобщенные реализации функций.
Ну, как бы ты пишешь обычную функцию, а компилятор сам разбирается как ее можно в шаблон превратить. Причем шаблоны получаются строготипизированными.
КЛ>Если бы решало, то я бы не бегал Рефлектором.
А вот Рефлектор на Немерле падает.
Ну, и очень советую не Рефлектор использовать, а отладчик. Рефлекто он иногда помогает при отладке не тривиальных макросов. И то это от убогости родных тулзов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Еще здесь есть неплохие картинки показывающий размер кода (притом оптимизированного на скорость) для разных языков, правда там не компиляторы, а более общий код, что для меня интересней. Разница между ML образными и C++ как раз в полтора — два раза.
1.5 — это если очень тупить на ML-еподобном языке и если очень окуратно писать на С. С++ обычно еще больший оверхэд добавляет, так как классы для компиляторов это перебор.
А вот если задача сложная (настоящий компилятор) и все наоборот (тупят на С++ и акуратно пришут на клонах ML), то разрыв может достигать и 10 раз.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Курилка пишет: > > Ну изменения есть, факт, меня "сторонние языки" смутили > А про потоки есть инфа здесь > <http://www.erlang.org/doc/man/erl_driver.html#ErlDrvTid> > Кстати, может быть у меня тоже появятся задачи код дельфовый интегрить с > Эрлангом в следующем году
во. класс
порассказываешь много страшного?
Здравствуйте, remark, Вы писали:
R>Ну это только в таких развитых языках как немерле. А на С++ достаточно и этого: R>
R> case expr::Call:
R> if ("max" == e.name) Math.Max(e.intArg1, e.intArg2);
R> else if ("min" == e.name) Math.Min(e.intArg1, e.intArg2);
R> else throw InvalidOperationException(e);
R>
Нет никаких intArg1 и intArg2. Call содержит список ибо функции бывают с разным колличеством ургуметов.
R>Так это и тут выглядит как "ужасное нагромаждение кода". То, что это удалось запихнуть в 3 строчки, не является показателем хорошести кода. Вполне возможно, что я предпочёл запись этого кода в 10 строк.
Вот так и получается в 3 раза больше кода на ровном месте... Да и твой код будет куда мение читаемым.
R>Писать на С я не призываю. Я лично пишу на С++ и мне нравится. Компилятор контролирует код не меньше, чем в других современных языках, а учитывая распространённость С++, возможно, что и больше.
Бред.
А выделеное полный бред.
Ибо распростаненность языка никак не влияет на его систему типов.
R>Индексы я использую редко. Что будет, если ошибусь? Исключение или ассёрт скорее всего. Вообще индексы я использую редко. Они сами по себе провоцируют ошибки. Обнаружение большинства ошибок я стараюсь переносить на фазы компиляции/линковки/стартапа. Имхо смысл иметь исключение, где по сути должен быть ассёрт не много.
В данном случае тебе придется их использовать ибо Call содержит несколько аргументов.
R>Если забуду "else throw" — компилятор предупреждает от неполных switch, отсутствии return, неопределённых виртуальных функциях.
Ну-ну. В данном случае никаких предупреждений не будет ибо в С++ не редко пишут код в котором намеренно пропускают выполнение за приделы case.
R>Код на немерле не падает "у клиента"? Даже если неправильно указать индекс?
Там небудет индексов на ровном месте.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Константин Л., Вы писали:
VD>>>Ну, не мучительнее чем бустовский, првада?
КЛ>>А я его не читаю. Только хэдэра. От имплементации иногда не по себе, но это случается раз в полгода.
VD>Дык по сложности решаемых задач ему до ядра компилятора далеко. Не странно, что без глубокого погружения в нем мало что понять можно.
Boost большой, там есть вполне сопоставимые по сложности с ядром компилятора вещи. Да и занимается во многом тем же самым эмуляцией высокоуровневых фич
Здравствуйте, palm mute, Вы писали:
PM>Считаем строки: PM>
PM>$ wc -l *.ml luascanner.mll luaparsex.mly
PM> 3107 total
PM>
PM>Теперь оцениваем версию на C. Сгенерированный парсер тоже удаляем, заголовочные файлы тоже не рассматриваем (просто, чтобы никто не возмущался , по-хорошему надо бы их оставить, т.к. все определения типов находятся там, дублирования, как в случае Окамла, нет): PM>
PM>$ wc -l `find . -name *.c -or -name '*.stx'` # *.stx - это исходники парсера
PM> 7083 total
PM>
PM>Получаем разницу в 2 раза, что и требовалось доказать.
По-хорошему, из тех и других исходников нужно выкосить комментарии и пустые строки. В OCaml-е нужно выбросить строки, содержащие только end, а из C -- строки с единственными { и }.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
.
