Re[16]: Бизнес-логика на Erlangе
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.06.07 11:10
Оценка:
Здравствуйте, Gaperton, Вы писали:

E>>При использовании encoding rules с метками (ASN1 BER, текстовые форматы XML, JSON, YAML обладают аналогичными характеристиками) проблемы расширения или сужения набора данных в пакете не существует.


E>>Поэтому страхи по поводу кирдыка, в общем случае преувеличены

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

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

Какие-то ты страшилки рассказываешь про вручную писанные сериализаторы/десериализаторы в XXI-м веке. Странно, право. Если не брать автоматически генерируемых сериализаторов, то даже простые библиотеки для организации сериализации/десериализации превращают код сериализации/десериализации в довольно декларативный. Можно вспомнить хотя бы MFC-сериалиацию или Boost-сериализацию.

G>Тэгированные форматы лишены многих подобных проблем — это и есть тот формат, который применяется при автоматической сериализации в динамических языках. Тебе для его реализации придется руками воспроизвести то, что динамический язык делает автоматически. И ты, кроме того что непродуктивно потратишь время, при этом двадцать раз облажаешься.


Лучше нужно думать о людях. Двадцать раз облажаться -- это еще суметь нужно.
Кроме того не нужно говорить о "динамических языках" во множественном числе. Результат Erlang-овского term_to_binary ты не сможешь разобрать в Python или Ruby, хоть они и динамические. Равно как и результат Ruby-нового Marshall.dump не распарсится в Erlang. Поэтому как только встанет вопрос интероперабильности с чем-нибудь, то по любому придется писать какие-то конверторы или же использовать иной способ сериализации. В том числе и расставлять теги вручную.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Бизнес-логика на Erlangе
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.06.07 11:32
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Зипование потока не выход — оно увеличивает и так недетский оверхэд на отправку-получение плюс привносит задержку в процесс передачи — от чего возрастает латентность — это тоже неприемлемо для приложений реального времени.


Кстати об упаковке сериализованных потоков. При работе с медленными каналами ввода/вывода (связь через dial-up к примеру) или медленными устройствами (теми же HDD) зипование даже бинарного потока может оказаться выгоднее передачи исходных данных. Т.к. время упаковки и, особенно, распаковки, оказывается гораздо меньше, чем время пропихивания всего объема исходных данных. А в случае использования специальных упаковщиков (LZO, к примеру) это время еще более сокращается. Не случайно поэтому LZO использовалась для сжатия данных на борту NASA-вских марсоходов Spirit и Opportunity.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[33]: преимущества erlang-а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.06.07 11:46
Оценка:
Здравствуйте, FR, Вы писали:

VD>>Ежу понятно. Но это уже не совсем честное сравнение. Это уже пенисометрия библиотек, или, что еще хуже, сравнение С с С но замаскированный под Питор (обман, значичь).


FR>Тебе шашечки или ехать?


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

FR>Это нормальное использование для glue языка.


Вот пусть его и позиционируют как "glue", а не как С++ на стеройдах. А мне glue-код не нужен. Я исползуют компонентные языки и рантаймы, которые решают в том числе и проблему динамического связыания разных модулей в единое решение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Бизнес-логика на Erlangе
От: Mamut Швеция http://dmitriid.com
Дата: 08.06.07 12:11
Оценка:
E>Лучше нужно думать о людях. Двадцать раз облажаться -- это еще суметь нужно.
E>Кроме того не нужно говорить о "динамических языках" во множественном числе. Результат Erlang-овского term_to_binary ты не сможешь разобрать в Python или Ruby, хоть они и динамические. Равно как и результат Ruby-нового Marshall.dump не распарсится в Erlang. Поэтому как только встанет вопрос интероперабильности с чем-нибудь, то по любому придется писать какие-то конверторы или же использовать иной способ сериализации. В том числе и расставлять теги вручную.

А term_to_binary и не нужен. Достаточно реализации Эрланговского "external term format" (довольно протсого, кстати, как я понял), чтобы программа на любом языке смогла общаться с Эрлангом на языке Эрланга.


dmitriid.comGitHubLinkedIn
Re[18]: преимущества erlang-а?
От: gandalfgrey  
Дата: 08.06.07 12:14
Оценка:
Здравствуйте, Mamut, Вы писали:

M>А term_to_binary и не нужен. Достаточно реализации Эрланговского "external term format" (довольно протсого, кстати, как я понял), чтобы программа на любом языке смогла общаться с Эрлангом на языке Эрланга.

Более того, исходники либы EI ( на С ) поставляются вместе с дистрибутивом Ерланга. Я без большого напряга прицепил ее к Тиклю, который чейчас общается с Ерланговским сервером по Ерланговскому же протоколу.
Re[17]: Бизнес-логика на Erlangе
От: Gaperton http://gaperton.livejournal.com
Дата: 08.06.07 13:59
Оценка:
Здравствуйте, eao197, Вы писали:

G>>Зипование потока не выход — оно увеличивает и так недетский оверхэд на отправку-получение плюс привносит задержку в процесс передачи — от чего возрастает латентность — это тоже неприемлемо для приложений реального времени.


E>Кстати об упаковке сериализованных потоков. При работе с медленными каналами ввода/вывода (связь через dial-up к примеру) или медленными устройствами (теми же HDD) зипование даже бинарного потока может оказаться выгоднее передачи исходных данных. Т.к. время упаковки и, особенно, распаковки, оказывается гораздо меньше, чем время пропихивания всего объема исходных данных. А в случае использования специальных упаковщиков (LZO, к примеру) это время еще более сокращается. Не случайно поэтому LZO использовалась для сжатия данных на борту NASA-вских марсоходов Spirit и Opportunity.


Надо же блин, а я и не знал, что иногда что-то полезно сжимать . Жду еще интересной и познавательной информации — например, интересно узнать, — потоковое видео передающееся по сети тоже выгоднее сжимать? Или все-таки лучше гнать как есть — некомпрессированными кадрами? Данные-то как-никак бинарные. А если сжимать, то чем? Специальными упаковщиками — вроде MPEG2 или H.264 (пардон, вышел из роли — "слишком умное слово для такой маленькой девочки"), или все-таки лучше LZO (все-таки в NASA применяется для марсоходов)? А?

ЗЫ: Да, кстати, может тебе интересно будет. В сервере CQG практически все данные, которые пишутся на диск — жмутся. И не группой LZ, а более простой, эффективной и на несколько порядков более быстрой, специально разработанной под формат данных схемой (разность цен приведеннах к целым числам для соседних котировок жмется Хаффманом с фиксированным словарем). Это дает выигрыш в 4 раза по скорости и объему, и только потому, что обработка данных настолько тривиальна, что все затыкается в диск. Будь иначе — никакой компрессии делать бы смысла не имело. Решение о компрессии — всегда индивидуально, и для грамотно построенного бинарного формата алгоритмы группы LZ покажут эффект близкий к нулевому. Они рулят на текстовых протоколах, и на тупых бинарных в специальных условиях.
Re[17]: Бизнес-логика на Erlangе
От: Gaperton http://gaperton.livejournal.com
Дата: 08.06.07 14:13
Оценка:
Здравствуйте, eao197, Вы писали:

E>>>При использовании encoding rules с метками (ASN1 BER, текстовые форматы XML, JSON, YAML обладают аналогичными характеристиками) проблемы расширения или сужения набора данных в пакете не существует.


E>>>Поэтому страхи по поводу кирдыка, в общем случае преувеличены

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

E>Слушай, а ты не доктор в прошлом? У них манера такая -- сначала запугать до смерти, а затем принять позу, мол я попробую, но вы же сами понимаете, что я не волшебник.


Нет, не доктор. А ты, слушай, в прошлом не пациент?

E>Какие-то ты страшилки рассказываешь про вручную писанные сериализаторы/десериализаторы в XXI-м веке. Странно, право. Если не брать автоматически генерируемых сериализаторов, то даже простые библиотеки для организации сериализации/десериализации превращают код сериализации/десериализации в довольно декларативный. Можно вспомнить хотя бы MFC-сериалиацию или Boost-сериализацию.


Я рассказываю про типовые ошибки в сериализаторах-десериализаторах, которые имеют обыкновение проявляються при попытках вносить изменения в протокол. Эти ошибки можно выловить и исправить, потому, что вообще любые ошибки можно выловить и исправить. Ничего "странного право" я не вижу. Можно такие ошибки допустить, о которых я говорю? Можно. Чего споришь? Отловить их тоже можно, но это трата времени.

G>>Тэгированные форматы лишены многих подобных проблем — это и есть тот формат, который применяется при автоматической сериализации в динамических языках. Тебе для его реализации придется руками воспроизвести то, что динамический язык делает автоматически. И ты, кроме того что непродуктивно потратишь время, при этом двадцать раз облажаешься.


E>Лучше нужно думать о людях. Двадцать раз облажаться -- это еще суметь нужно.

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

E>Кроме того не нужно говорить о "динамических языках" во множественном числе. Результат Erlang-овского term_to_binary ты не сможешь разобрать в Python или Ruby, хоть они и динамические. Равно как и результат Ruby-нового Marshall.dump не распарсится в Erlang. Поэтому как только встанет вопрос интероперабильности с чем-нибудь, то по любому придется писать какие-то конверторы или же использовать иной способ сериализации. В том числе и расставлять теги вручную.


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

Что насчет интероперабельности —
1) Можно взять библиотеку для разбора Эрланговских термов из стандартной поставки, и прикрутить к любому языку.
2) Можно воспольваться компилятором ASN.1 из стандартной поставки.
3) Можно реализовать любой протокол ручками — на Эрланге это будет проще, чем на любом другом языке (и чем на Руби тоже) благодяря бинарисам.
4) Можно воспользоваться CORBA (стандартная поставка).
5) Можно использовать XML (стандартная поставка).
6) С Явой есть готовый биндинг (guess what? стандартная поставка).
7) С С — тоже.

Чего-то не хватает для интероперабельности?
Re[18]: Бизнес-логика на Erlangе
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.06.07 16:40
Оценка:
Здравствуйте, Gaperton, Вы писали:

<...упражнения в острословии поскипаны...>

Кроме того, что ты попытался постебаться что-нибудь еще ты сказал в дополненение к тому, что иногда данные полезно сжимать? По-моему, ты просто повторил мои слова, но на свой неповторимый манер.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[18]: Бизнес-логика на Erlangе
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.06.07 16:51
Оценка:
Здравствуйте, Gaperton, Вы писали:

E>>Слушай, а ты не доктор в прошлом? У них манера такая -- сначала запугать до смерти, а затем принять позу, мол я попробую, но вы же сами понимаете, что я не волшебник.


G>Нет, не доктор. А ты, слушай, в прошлом не пациент?


И в прошлом, и в будущем.

E>>Какие-то ты страшилки рассказываешь про вручную писанные сериализаторы/десериализаторы в XXI-м веке. Странно, право. Если не брать автоматически генерируемых сериализаторов, то даже простые библиотеки для организации сериализации/десериализации превращают код сериализации/десериализации в довольно декларативный. Можно вспомнить хотя бы MFC-сериалиацию или Boost-сериализацию.


G>Я рассказываю про типовые ошибки в сериализаторах-десериализаторах, которые имеют обыкновение проявляються при попытках вносить изменения в протокол. Эти ошибки можно выловить и исправить, потому, что вообще любые ошибки можно выловить и исправить. Ничего "странного право" я не вижу. Можно такие ошибки допустить, о которых я говорю? Можно. Чего споришь? Отловить их тоже можно, но это трата времени.


Видишь ли, с такой же вероятностью ты можешь допустить ошибку в DDL-файле с описанием для автоматической тулзины для сериализации/десериализации. Даже в Erlang-е ты можешь записать:
B = term_to_binary( {A,C,B} )

вместо
B = term_to_binary( {A,B,C} )

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

E>>Кроме того не нужно говорить о "динамических языках" во множественном числе. Результат Erlang-овского term_to_binary ты не сможешь разобрать в Python или Ruby, хоть они и динамические. Равно как и результат Ruby-нового Marshall.dump не распарсится в Erlang. Поэтому как только встанет вопрос интероперабильности с чем-нибудь, то по любому придется писать какие-то конверторы или же использовать иной способ сериализации. В том числе и расставлять теги вручную.


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


Теперь понятно, что ты имел ввиду, что применительно к любому динамическому языку два сервиса на этом языке будут общаться между собой без проблем. Я понял тебя иначе.

Собственно, а Java со своей встроенной сериализацией здесь как тогда выглядит?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[19]: Бизнес-логика на Erlangе
От: Gaperton http://gaperton.livejournal.com
Дата: 09.06.07 09:09
Оценка:
Здравствуйте, eao197, Вы писали:

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


E><...упражнения в острословии поскипаны...>


E>Кроме того, что ты попытался постебаться что-нибудь еще ты сказал в дополненение к тому, что иногда данные полезно сжимать? По-моему, ты просто повторил мои слова, но на свой неповторимый манер.


А я и не утверждал, что сжимать данные всегда бесполезно. Я тебе сказал ровно то, что сказал — не больше: сжатие потока не решает проблем с XML — оно увеличивает и без того высокий оверхэд на десериализацию (примерно в 50 раз против бинарного протокола) + привносит задержку в протокол, что нехорошо для приложений реального времени. Т.е. я говорил не о сжатии, а об XML. Все. А ты что пишешь в ответ? Какие нахрен марсоходы? Какие модемы? Хватит делать из меня идиота.
Re[20]: Бизнес-логика на Erlangе
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.06.07 09:23
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>А я и не утверждал, что сжимать данные всегда бесполезно. Я тебе сказал ровно то, что сказал — не больше: сжатие потока не решает проблем с XML — оно увеличивает и без того высокий оверхэд на десериализацию (примерно в 50 раз против бинарного протокола) + привносит задержку в протокол, что нехорошо для приложений реального времени. Т.е. я говорил не о сжатии, а об XML. Все. А ты что пишешь в ответ? Какие нахрен марсоходы? Какие модемы? Хватит делать из меня идиота.


Даже для приложений реального времени, работающих на медленных каналах (даже на 10Mbit Ethernet), сжатие XML может как раз таки убрать лишние задержки из протокола. А использование XML может быть данностью, обусловленной требованиями заказчиков. Все зависит от конкретных условий.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[21]: Бизнес-логика на Erlangе
От: Gaperton http://gaperton.livejournal.com
Дата: 09.06.07 12:59
Оценка:
Здравствуйте, eao197, Вы писали:

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


G>>А я и не утверждал, что сжимать данные всегда бесполезно. Я тебе сказал ровно то, что сказал — не больше: сжатие потока не решает проблем с XML — оно увеличивает и без того высокий оверхэд на десериализацию (примерно в 50 раз против бинарного протокола) + привносит задержку в протокол, что нехорошо для приложений реального времени. Т.е. я говорил не о сжатии, а об XML. Все. А ты что пишешь в ответ? Какие нахрен марсоходы? Какие модемы? Хватит делать из меня идиота.


E>Даже для приложений реального времени, работающих на медленных каналах (даже на 10Mbit Ethernet), сжатие XML может как раз таки убрать лишние задержки из протокола.

Использовать ХМЛ для приложений реального времени критичных к траффику да еще на относительно медленных каналах — идиотизм. Сначала создать себе проблемы, потом их героически преодолевать (зипуя канал и тд). В таких случаях нормальные люди применяют бинарные протоколы (посмотри как обошлись в МПЕГ7 — там применяется BiM — это такой бинарный ХМЛ). На быстром канале зипование внесет дополнительную задержку — она связана с окном просмотра компрессоров группы ЛЗ.

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

Случай, когда ХМЛ — это данность, не относится к нашему разговору о преимуществах и недостатках методов сериализации. Требование заказчиков могут обусловить вообще все что угодно — это не предмет обсуждения.

Да, и еще. Мне надоело переливание из пустого в порожнее.
Re[15]: Бизнес-логика на Erlangе
От: thesz Россия http://thesz.livejournal.com
Дата: 09.06.07 18:38
Оценка:
G>1) полноте тестового покрытия (никак не зависит от типизации). и

One word: epigram.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[22]: Бизнес-логика на Erlangе
От: thesz Россия http://thesz.livejournal.com
Дата: 09.06.07 18:45
Оценка:
E>>Даже для приложений реального времени, работающих на медленных каналах (даже на 10Mbit Ethernet), сжатие XML может как раз таки убрать лишние задержки из протокола.
G>Использовать ХМЛ для приложений реального времени критичных к траффику да еще на относительно медленных каналах — идиотизм. Сначала создать себе проблемы, потом их героически преодолевать (зипуя канал и тд). В таких случаях нормальные люди применяют бинарные протоколы (посмотри как обошлись в МПЕГ7 — там применяется BiM — это такой бинарный ХМЛ). На быстром канале зипование внесет дополнительную задержку — она связана с окном просмотра компрессоров группы ЛЗ.

Задержкой будет обладать не любой LZ, а только LZ с блочным кодом Хафмана.

Если мы применяем LZW или LZSS с (блочно-)динамическим кодом Хафмана, никакой задержки не будет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[18]: Бизнес-логика на Erlangе
От: thesz Россия http://thesz.livejournal.com
Дата: 09.06.07 18:54
Оценка:
A>>Часть тестов в статичской типизации не нужна.
G>Не понимаю, с чего это прогрессивной общественности взбрела в голову такая мысль. Откуда дровишки-то? Любой тест приводит к выполнению кода, и убирание этого теста уменьшает тестовое покрытие — у вас какой-то код становится тестими не покрыт. Адекватное же тестовое покрытие найдет 99,999% ошибок типизации — не нужны никакие специальные тестовые сценарии для их ловли, достаточно близкого к 100% покрытия по строкам кода . Т.е. тестовое покрытие потребуется одинаковое.

Тикль:
foreach t $list {
   incr s $t
}
puts "Last was $t, sum $s"


Где ошибка? Один тест со 100% покрытием ее не найдет.

(тикль не присваивает t никакого значения, если список пустой. Во всех языках со статической типизацией это будет выловлено. И в некоторых с динамической — например, в Эрланге, — но уже с тестами.)
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[33]: преимущества erlang-а?
От: thesz Россия http://thesz.livejournal.com
Дата: 09.06.07 18:57
Оценка: -1
G>Эрланг придумали не идиоты, а чрезвычайно опытные инженеры, и не из любви к исскуству, а для того, чтобы легче выполнять работу.

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

То, что Джо не инженер, видно хотя бы по его словам о его коде на Си.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[19]: Бизнес-логика на Erlangе
От: Gaperton http://gaperton.livejournal.com
Дата: 09.06.07 19:43
Оценка:
Здравствуйте, thesz, Вы писали:

A>>>Часть тестов в статичской типизации не нужна.

G>>Не понимаю, с чего это прогрессивной общественности взбрела в голову такая мысль. Откуда дровишки-то? Любой тест приводит к выполнению кода, и убирание этого теста уменьшает тестовое покрытие — у вас какой-то код становится тестими не покрыт. Адекватное же тестовое покрытие найдет 99,999% ошибок типизации — не нужны никакие специальные тестовые сценарии для их ловли, достаточно близкого к 100% покрытия по строкам кода . Т.е. тестовое покрытие потребуется одинаковое.

T>Тикль:

T>
foreach t $list {
T>   incr s $t
T>}
T>puts "Last was $t, sum $s"


T>Где ошибка? Один тест со 100% покрытием ее не найдет.

Понятия не имею. Не понимаю, что означает $. Но тест со 100% покрытия ее должен найти — у тебя для 100% должен быть выполнен incr.

T>(тикль не присваивает t никакого значения, если список пустой. Во всех языках со статической типизацией это будет выловлено. И в некоторых с динамической — например, в Эрланге, — но уже с тестами.)


Приведи лучше пример бесполезного теста, который просто не нужен в языках со статической типизацией — ты его выкинешь и тестовое покрытие не ухудшится. Вот тогда ты мне возразишь.
Re[20]: Бизнес-логика на Erlangе
От: thesz Россия http://thesz.livejournal.com
Дата: 10.06.07 09:24
Оценка: 6 (1)
G>Приведи лучше пример бесполезного теста, который просто не нужен в языках со статической типизацией — ты его выкинешь и тестовое покрытие не ухудшится. Вот тогда ты мне возразишь.

Практически любая индуктивно определенная на рекурсивном алгебраическом типе функция.

length [] = 0
length (x:xs) = 1+length xs

data E = C Double | V String | N E | R E | A E E | M E E

diff vn (V v)
   | vn == v   = C 1
   | otherwise = C 0
diff vn (N e) = N $ diff vn e
diff vn (R e) = N $ M (diff vn e) (M e e)
diff vn (A a b) = A (diff vn a) (diff vn b)
diff vn (M a b) = M (diff vn a) b `A` M a (diff vn b)
diff vn (C c) = C 0


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

Если у нас есть сомнения в применимости какого-то куска кода, мы можем протестировать его отдельано. Например, только
test = diff "x" $ M (V "x") (V "y")
, если у меня есть сомнения насчет каких-то плохо специфицированых критериев (или вообще отданных на откуп разработчику).

Также, как ты радуешься возможности выбора применения строгой типизации не ко всему проекту, а к его части, с весом этой части в диапазоне [0..1], использующий строгую типизацию (проверки компилятора) программист радует возможности переложить на компилятор написание тестов к части проекта, с весом этой части в диапазоне [0..a], где 0 < a < 1.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[35]: преимущества erlang-а?
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.07 18:35
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>В Эрланге просто нет массивов нормальных, и все . Плавающую запятую HIPE компилирует нормально, рекурсия там тоже быстра. Что-нить без того, чтобы лопатить вперехлест здоровый массив, как в альфабленде — это будет совсем другое дело. Хоть перемножение матриц. Здесь можно будет обогнать Питон.


G>Но лучше что-нить нейтральное — работа с какими-нибудь деревьями. Это достаточно низкоуровнево, библиотеки не нужны — все по честному. Можно в эти деревья плавающую запятую добавить и целые числа.


Мне кажестя, что интересен набор тестов. Кому интересна специализированная пенисометрия? Всегда можно подтосовать набор тестов который покажет продукт с лучшей стороны. Но интересно же знать на что способен продукт в широком диапазоне применения. Вот тебе очевидно, что альфблэнд на Эрланге и Питоне — это глупость. А кто-то может думать иначе.

В общем, комплексные тесты дали бы релаьную информацию.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.