Ерланг завоевывает сердца программистов и маркетологов, пробираясь к вершинам Олимпа ентерпрайз уровня как лучшая среда разработки, конкурентного языка.
Все больше внимания приковывается к этой революционной среде разработанной специально для эффективного решения вопросов распределенных вычислений. И это еще не все!
Современные тенденции показывают рынка показывают, что пользователи с удовольствием покупают домашние машины с несколькими процессами, но никто не знает как с этим эффективно работать. Незнают как заставить работать эту мощь в полную силу. Неважно, что Д. Кнут говорит что нет классических алгоритмов способных эффективно работать на нескольких процессорах, важно что тут появляется Джон Армстронг и говорит вам что 2 процессора делают работу в два раза быстрей.
Так рождаются мифы, и эффективные продажи, а теперь больше о деле.
Очередная презентация об лучшем из лучших языков программирования позволяющим загрузить намертво ваши процессоры с минимальной эффектностью и большими проблемами сопутствующими конкурирующим вычислениям. Теперь сами авторы отвечают на проблемы языка, оправдываясь пред своими поклонниками за такие серьезные оплошности, о которых они никогда не думали.
http://www.infoq.com/presentations/wiger-multicore-erlang
Несмотря на то, что в первые 20 минут докладчик утверждает что распределенные вычисления это сложно, с ерлангом вы это сделаете за пару минут.
Несмотря на лестные обещания, несколькими минутами позже делается противоположная оговорка, говорящая совершенно об обратном. И дальше до конца презентации мы, вместе с докладчиком, будем всегда делать два шага. Первый шаг о том какой хороший язык еранг его преимуществах и способностях бороться со всеми проблемами конкуренси вычислений, а второй шаг, о том что этот самый язык, стараясь не называть его в слух (ерланг) или делать это неуверенно, имеет те же самые проблемы.
Вот что у меня получилось вкратце:
1) эрланг легкий язык для создания распределенных вычислений
2) да, но без определенных знаний при реализации тривиального map/pmap, в нашем языке Х(икс) вы получите либо не эффективный код, либо код с потенциальными проблемами надежности. Но эранг это хорошо.
1) эранг эффективный язык.
2) правда в некоторых НЕ ПРАВИЛЬНЫХ реализациях тестов, наш некоторый язык Х(икс) медленней С++ в 200 раз. Но еранг даже не смотря на эти таблички, он должен! и работает быстрей, чем тут написано.
1) эрланг отлично работает без общей памяти и атомарный
2) правда в нашем языке Х(икс), случаются ситуации когда вы ловите time-related bugs. Но используя quckcheck, технологию Erlang, вы без труда сами найдете любые ошибки.
1) эрланг отлично работает без mutex
2) но в некотором языке есть проблемы с API среды и требуют доработки, хотя мы не знаем как это исправить.
Докладчик мрачно замечает только локальные проблемы, говоря о сложностях некоторых реализаций, не видя проблемы в целом и не произнося величественного: Defective By Design. Продолжая читать с совершенно каменным и добрым лицом, он не указывает на просчеты в дизайне механизма обработки ошибок. О том, что обработка исключений вообще не вписывается в общий синтаксис языка и притянута за уши. Такие вот временные решения всегда и везде были причиной подобных ошибок. Но это вы там не услышите.
Кроме того, наличие всех этих проблем омрачает отсутствие нормальной среды разработки, отладчиков, и проблем самой среды.
Ерланг среда с ужасными сайд эффектами, которые для отладки в сложных системах потребуют годы и штаты разработчиков на их поиск и устранение. И стало это возможно потому, что среда содержит ошибки содержащиеся в самом дизайне этой системе. Вас все еще призывают улучшать эту среду вместе с ними?
Не хочу оставлять свою речь без положительных моментов. В итоге, что же мы тут находим интересного. В презентации мы в очередной раз узнаем о том, что атомарные приложения, гораздо лучше подлежат отладке, чем с большим количеством циклов и условий. В этом нам всегда помогает хороший интерактивный отладчик и классические юниттесты. Писать код лучше без использования lock конструкций и общих областей памяти. Однако, такие конструкции лучше скрывать внутри объектов. Лучше, если ваш код будет напоминать архитектуру еранг приложений. А это: объектный язык, имеющий атомарные вызовы методов, с пулом потоков равному количеству процессоров на вашей системе. В итогде вы получаете эффективный, распределенное приложение, в удобной среде отладки, лишенное сайд эффектов - С++\Java приложение.
Ссылки по теме:
Donald: I don’t want to duck your question entirely. I might as well flame a bit about my personal unhappiness with the current trend toward multicore architecture. To me, it looks more or less like the hardware designers have run out of ideas, and that they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks! I won’t be surprised at all if the whole multithreading idea turns out to be a flop, worse than the "Itanium" approach that was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write.
четверг, 16 июля 2009 г.
Подписаться на:
Комментарии к сообщению (Atom)
0 коммент.:
Отправить комментарий