По ссылке с Lambda the Ultimate нашла работу Evaluating High-Level Distributed Language Constructs (.pdf). Авторы исследования переписывают куски телекоммуникационного софта и смотрят на размер результирующего кода. Меньше всего код получается на GdH (Glasgow Distributed Haskell), побольше на Erlang'е, ну а на С++ там вообще какие-то монструозные размеры.
Выводы не так очевидны. Они сами признаются, что не так-то просто оценить качество результирующего софта. Сами авторы таки считают лучшим код на Erlang'е, потому что кода получилось значительно меньше чем на С++, а GdH - это такая экспериментальная штука.
Но кроме размера кода интересно было бы узнать как этот софт дальше работал, легко ли было его развивать. Сложно оценить чистоту эксперимента - они пишут, что софт на разных языках писали разные разработчики примерно одинаковой квалификации, но квалификация штука такая, ее померить сложно. С++ обеспечивает работу на более низком уровне, это преподносится как недостаток. А что если софт нужно потюнить на низком уровне, что тут может предложить Erlang? Автоматическая сборка мусора рассматривается однозначно в плюс Erlang'у. Да, оно конечно удобно, но поскольку ее контролировать затруднительно, что если мусор начнет собираться в совершенно неподходящее время?
Так что по одному только количеству строчек кода судить нельзя. Но из того, что я слышала об Erlang'е, он действительно хорош для разработки распределенных систем.
Ссылки по теме:
Phil Trinders Publications
Quaternions and spherical trigonometry
4 дня назад
Atom feed
20 коммент.:
Интересный критерий - размер кода :)
2 anton: меньше кода — шанс, что легче поддерживать и меньше ошибок.
2 Алёна: про Erlang и ФП встречал в какой-то статье мнение — Ericsson’овские прошивки работают годами без перезапуска. При этом обновляясь в боевом режиме.
Насчет размера кода -- приведу опять мою любимую фразу из хелпа к Fox GUI Toolkit
"Every line of code not written is a correct one" ;)
Что касается сборки мусора -- она при совремнных технологиях сборки совсем не приводит к жестоким неожиданным лагам. Тем более тут лаги будут скорее на уровне сетевого транспорта между узлами распределенного приложения.
А вообще вон есть realtime java -- там вообще отсутствие лагов гарантировано by design, звание realtime обязывает-с )
К сожалению, опять сделали из сферического коня в вакууме линейку, и давай ей мерять вес, ширину и время. Что-то как-то сравнили, но как и зачем сказать толком не могут, а что дали результаты -- тем более.
ссылка на Erlang не корректна. Правильная http://www.erlang.org/
Автоматическая сборка мусора приводит иногда и не к сильно хорошим последствиям. Всем кто не в курсе советую вспомнить робота Томми который на скорости в 70км/ч въехал в стену :)
Дорогие скептики, наберите в гугле, к примеру, "realtime garbage collection", и будет вам счастье. Ссылаясь на результаты, которым в обед сто лет, вы демонстрируете лишь собственную отсталость.
Кроме того, в Эрланге у каждого процесса своя куча, в результате кучи небольшие, и сборка мусора работает быстро.
Что касается "потюнить", то чаще бывает дешевле купить дополнительный сервер, чем маяться с оптимизацией, потом вычищать ошибки, которые при этой оптимизации внесли...
В некотором смысле спор напоминает "языки программирования высокого уровня (Pascal, Algol, Fortran) против ассемблера". Ассемблерщики, ухмыляясь, тоже говорили: "А если надо потюнить?" И где теперь эти ассемблерщики?
К слову про ерланг - стоит отметить, что он проектировался сразу для длительной работы приложений, и поэтому там есть такая штука, как обновление компонентов "на лету" - т.е. вы отладили код на своей машине, а потом начали заливать на коммутаторы.
Стоит (хотя бы в рамках уменьшения зашоренности :-) еще посмотреть на интересный проект - Termite, который приносит в язык Scheme Erlang'овские возможности - легковесные процессы, обмен сообщениями и даже, захват состояния и перенос процедур, вместе с состоянием в другой процесс или ноду
2Fester:
К сожалению, опять сделали из сферического коня в вакууме линейку, и давай ей мерять вес, ширину и время. Что-то как-то сравнили, но как и зачем сказать толком не могут, а что дали результаты -- тем более.
Оно конечно да. Но тогда вообще непонятно каким образом мерить подобные вещи. Авторы исследования честно старались как могли обеспечить наиболее реальные условия для своего эксперимента.
2Sergey:
ссылка на Erlang не корректна
Поправила, спасибо
2Alex Ott
Стоит (хотя бы в рамках уменьшения зашоренности :-) еще посмотреть на интересный проект - Termite
Интересно, посмотрим, посмотрим :-)
2Анонимный
Дорогие скептики, наберите в гугле, к примеру, "realtime garbage collection", и будет вам счастье. Ссылаясь на результаты, которым в обед сто лет, вы демонстрируете лишь собственную отсталость.
Я тут больше читала/слышала претензии от разработчиков игр, нежели от разработчиков телекоммуникационных систем, так вот отношение следующее: автоматическая сборка мусора в играх не есть хорошая идея, потому как привнесет неконтролируемые тормоза в самых неожиданных местах. Я не могу сказать о каких именно алгоритмах автоматической сборки мусора идет речь. Возможно, эта позиция и устарела уже, но она очень популярная до сих пор.
Что касается "потюнить", то чаще бывает дешевле купить дополнительный сервер, чем маяться с оптимизацией, потом вычищать ошибки, которые при этой оптимизации внесли...
Иногда бывает дешевле, а иногда не дешевле... Я бы смотрела по ситуации. Мне вообще нравится ситуация с Питоном, где модули, где особенно важна производительность, пишут на С.
Ну тут опять же я не хочу каким-либо образом критиковать Эрланг, потому что не знаю как там и чего.
ну честно говоря, при разговоре про сборку мусора и игры, мне кажется, что разработчики просто не особо разбирались с этим вопросом. многие сборщики позволяют сказать, что от сих до сих - мусор не собирать, или собирать, но только в паузы или не больше какого-то объема. А если машина многопроцессорная-многоядерная, то это вообще становится проще.
Насколько я помню, этот вопрос уже тут обсуждался, и я давал ссылку на survey разных техник - там приведены были оценки быстродействия и прочих затрат
Интересней даже не размер кода, а сколько для чего нужно писать.
Для erlang
Application 62.2%
Communication 15.1%
Process Mgmnt 9.5%
...
Для C++
Defensive 25.3%
Communication 22.1%
Application 19.2%
Memory management 11.3%
Type declarations 11.2%
...
Оно конечно да. Но тогда вообще непонятно каким образом мерить подобные вещи. Авторы исследования честно старались как могли обеспечить наиболее реальные условия для своего эксперимента.
Просто надо перестать сравнивать вес с длинной :)
У каждого из языков есть своя довольно хорошо очерченная область применения, а решать, что лучше подойдёт для решения некоей конкретной задачи -- это уже задача и работа программиста. Никто ведь не объясняет токарю, где лучше стамеской, а где циркуляркой?
Никто ведь не объясняет токарю
Ч-ч-чёрт, конечно же столяру :)
У каждого из языков есть своя довольно хорошо очерченная область применения
Люди собственно и пытаются в таких исследованиях очертить эти области. Или эти области уже раз и навсегда где-то очерчены? Покажите где..
Люди собственно и пытаются в таких исследованиях очертить эти области. Или эти области уже раз и навсегда где-то очерчены? Покажите где..
Такие исследования проводятся постоянно, только ценность от них, на мой взгляд, нулевая. Выбор языка зависит не от области, а от больше задачи. Разумеется с перспективами.
Тюнинг в коммерческий проектах действительно мало применим, по разным причинам.
И все-таки говорить о неэффективности разработки кода на C++ говрить рано. Пока еще реальной замены ему не существует. Универсальность, огромный инструментарий, полная свобода действий... это весомые аргументы. Сборка мусора? Элементарно (в смысле большое количество готовых решений), любой алгоритм. Много кода? Возможно поможет ООП (в частности большое количество готовых библиотек на все случаи жизни).
Хотя в больших проектах частенько приходится применять комбинацию C++ с каким-либо скриптовым языком программирования. Все плюсы C++ вместе с плюсами интерпретируемого языка программирования дают хороший результат. И в играх этот подход тоже применяется.
В Эрланге сборщик мусора соответствует требованиям soft realtime.
А вот в Хаскелле, увы, нет. По крайней мере, в GHC (вряд ли в GdH по другому)...
Скомпилил как-то FRAG - квейкоподобный шутер на Хаскелле - каждые несколько секунд возникает кратковременная пауза на долю секунды, видимо из-за сборщика мусора... Малозаметный лаг, но есть...
Но, говорят, работа над многопоточным сборщиком мусора ведётся - возможно, скоро в GHC станет получше...
Насколько я помню, этот вопрос уже тут обсуждался, и я давал ссылку на survey разных техник - там приведены были оценки быстродействия и прочих затрат
Продублирую все ссылки по сборке мусора оттуда, пожалуй. Пускай тут тоже будут.
http://citeseer.ist.psu.edu/wilson95dynamic.html, http://citeseer.ist.psu.edu/255424.html http://citeseer.ist.psu.edu/jones03garbage.html
Аргуменыты ниже плинтуса... типа много кода на С++ а на Хаскеле мало...Много не значит непонятно, а мало не значит понятно. Куда важнее ясность. Но ясности как раз нету... А чем меньше кода тем хуже ясность!
Аргуменыты ниже плинтуса... типа много кода на С++ а на Хаскеле мало...Много не значит непонятно, а мало не значит понятно. Куда важнее ясность. Но ясности как раз нету... А чем меньше кода тем хуже ясность!
До сих пор никто не написал удовлетворительного сборщика мусора... Хотя пишут уже лет 20 так..И неудивительно, ибо это интеллектуальная задача, плохо программируемых. И потому всегда будут минусы. Но большой необходимости в ней и нету...
Отправить комментарий