Здравствуйте!
Почитал про Erlang, понравилось его формула Erlang=функциональный язык + процессы, читал есть MVC фреймворк erlyWeb, так же читал на хабре статью о использовании ocaml в связке с php.
Возможно ли перевести всю разработку на функциональный язык программирования и будет ли от этого плюсы?
так что ленивые вычисления (при этом можно спорить, является ли данный пример — примером ленивых вычислений или нет) сами по себе не являются причиной роста производительности в данном примере.
whatevs. мне кажется, тут вопрос восприятия — одно решение можно рассматривать с нескольких точек зрения. можно ведь сказать, что struct cdevsw в BSD — это ООП, генераторы в питоне — это ленивые списки и т.д. (или это все паттерны?): -) впрочем, я никого тут не агитирую, называйте как хотите:))
А как бы это написалось на функ. языке?
что-то мне начинает казаться, что ты прикалываешьcя уже. поищи в интернетах mapreduce + название любого функционального языка
мне кажется, что тут еще дело в восприятии — так, когда пишешь MapReduce на хадупе, это ни разу не похоже на функционально программирование:) функциональная идея погребается в куче императивного кода, и хорошо еще, если выглядывает на свет божий в виде какого-нибудь паттерна:)
Ну вот давай рассмотрим классическую хадуп задачу — подсчет числа вхождения слова в входной текст, я вот как до мозга костей императивный программист написал бы ее так (далее псевдокод):
Sergiy Matusevych
crypto5
map(key, value, out) {
out.write(value, 1);
}
reduce(key, values, out) {
long cnt = 0;
for(value: values)
cnt += value;
out.write(key, cnt);
}А как бы это написалось на функ. языке?
Для прироста производительности в данной задаче достаточно что бы не происходило лишних преобразований между форматами, безотносительно в момент доступа к данным или значительно раньше, так что ленивые вычисления (при этом можно спорить, является ли данный пример — примером ленивых вычислений или нет) сами по себе не являются причиной роста производительности в данном примере.идея в том, что некие данные вычислялись только в момент доступа к ним
Все ИМХО конечно.
Любопытный:
Дизайн № 2 — Выбираем универсальный формат и на уровне маршрутизации работаем только с ним
не совсем так. на уровне маршрутизации использовался только очень небольшой набор атрибутов сообщения, которые часто можно было вытащить, не транслируя все сообщение в универсальный формат. т.е. на этапе маршрутизации почти всегда протаскивалось сообщение в исходном формате, хотя по интерфейсу обертки не было видно, в каком формате оно на самом деле.
— Для каждого из N форматов делаем оболочку, которая транслирует вызовы универсального формата в специфические (= N)
во втором варианте мы практически избавились от «универсального формата» — остался только минимальный интерфейс, необходимый для маршрутизации, а само сообщение оставалось внутри в исходном виде; трансляция же происходила уже перед самой отправкой, и напрямую из исходного формата в формат отправки, без промежуточного универсального представления. кроме того, результат трансляции кешировался там же внутри обертки сообщения, на случай если сообщение отправлялось более чем одному получателю.
— Для всех пар форматов делаем преобразователи в обе стороны (= N* (N-1))
ага. на самом же деле их потребовалось гораздо меньше, т.к. многие форматы были только для отправки или только для получения
Если я правильно понял описание, то это выбор скорость vs. сложность кода, которая может быть вполне оправдана. Первый дизайн требует значительно меньше ресурсов для разработки при больших N и для поддержки (читай добавление нового формата). Второй очевидно быстрее и требует меньше памяти, так как в худшем случае делает одно преобразование, а иногда 0, но зато требует написания кучи преобразователей.
прикол в том, что во втором случае получилось все не так уж сложно, даже на джаве — после того как написали фреймворк, добавлялись только плагины для трансляции новых форматов, причем отказ от универсального формата неожиданно очень облегчил жизнь, т.к. это была такая попытка «объять необъятное», а реальные сообщения были намного проще.
И всё же я в упор не вижу, где здесь ленивые вычисления?наверное, я привел слишком громоздкий пример... идея в том, что некие данные вычислялись только в момент доступа к ним, да и то не всегда, а выглядело это как обычная работа с атрибутами объекта. имно, вполне себе ленивые вычисления.
мне кажется, что тут еще дело в восприятии — так, когда пишешь MapReduce на хадупе, это ни разу не похоже на функционально программирование:) функциональная идея погребается в куче императивного кода, и хорошо еще, если выглядывает на свет божий в виде какого-нибудь паттерна:)
И всё же я в упор не вижу, где здесь ленивые вычисления?
Erlang или ФП для веба
вопрос странный. что значит «для веба»? не могу понять. что есть «веб» в данном контексте? веб-страничка? приложение, которое считает то, то что на страничке показывается? Фейсбук это веб? Некоторые сервисы написаны на Ерланге. Амазон это веб? да блин, самые очевидные примеры видны уже из википедии (!). зачем эта философия? если позарез надо — то пишите на чем хотите и для чего хотите. ну елки палки, пилять
crypto5:
ну вот я и рассказал, как применение ленивых вычислений для трансляции сообщений повысило производительность. т.е. речь шла о том, что правильное использование ленивых вычислений может дать выигрыш в производительности даже в обычном, не функциональном языке. только для джавы нам пришлось изобретать всяческие паттерны и писать массу поддерживающего кода.Не совсем понятно причем в данном примере ленивые вычисления и ФЯ. Я не исключаю что на ФЯ можно достичь некоторого уменьшения количества строк кода за счет какого то синтаксического сахара, возможно даже в каких то случая это будет в пять раз, но данная ветка дискусии была посвящена флиянию ленивых вычислений на производительность?
ЗЫ замечу, кстати, что неправильно сводить функциональные языки к «синтаксическому сахару». функциональные (равно как и прочие) фичи влияют на дизайн системы, а посему и подход должен быть соответствующий.
Опыт того же Пола Грэма подсказывает, что, к примеру, лисп разумнее всего применять, если вы хотите в одно рыло рывком наваять нечто, на что у других требуется целая команда. Ну или не в одно рыло, но максимум 2−3 человека. Если проект будет успешен, он впоследствии будет спокойно переписан на mainstream технологии:) Пример — reddit. Вобщем, если у вас возникает вопрос, пользоваться ли ФП, то ответ — точно нет. У тех, кто делает стартапы на ФП, такого вопроса просто не возникает.
Отсюда, сколько — же должен стоить человек который если уволится, проект нужно закрывать, совсем закрывать ибо нового вы не найдете — в пять раз больше среднего спеца наверное.
Нет. Такой проект надо закрывать к чертям, а менеджера который допустил такую уязвимость (проект завязан на 1 человека). Проблема в том что ЗП зависит не линейно от навыков человека, а по факту не от навыков, а от ответственности которую на себя берет человек.
Да на Украине. Вот средняя З.П, по java.
Ну вот не 2, 5, а 2Кбагза в Киеве, а по Украине 1600.
Но какой выигрыш по скорости работы (а не разработки) по сравнению с императивными языками я просто не понимаю
Из личного опыта: одна конкретная реализация ГА на Лиспе, была быстрее чем на Ц, для больших популяций и большого количества поколений. Но я не разбирался в коде ни лиспового варианта, ни сишного.
Я ж говорю: дело в задаче, в ряде случаев ФП очень полезно, а серебряной пули нет и не бывает в принципе. Если говорить о деньгах, то при наличии задач лучше взять квалифицированного, но редкого специалиста и платить ему хорошие деньги, чем трех середнячков. Тот аргумент, что середнячки не разбираются в инструментарии не канает.
Вы живете в каком-то идеальном мире. В реальном мире заказчикам хоть в глаз ссы, но они никогда не согласятся на технологию, в которой более дорогие спецы или технология неизвестная.
Сжальтесь над убогим — поясните.
Я ж говорю: дело в задаче, в ряде случаев ФП очень полезно, а серебряной пули нет и не бывает в принципе. Если говорить о деньгах, то при наличии задач лучше взять квалифицированного, но редкого специалиста и платить ему хорошие деньги, чем трех середнячков. Тот аргумент, что середнячки не разбираются в инструментарии не канает. Так можно и от станков отказаться: станочники редки, стоят дорого, давайте будем по старинке в кузне все делать
Все смешалось в кучу, то что кода получается в пять раз больше (предположим чисто гипотетически, так как точно померять никто не может), совсем не обозначает что он писался в пять раз дольше, будет дебажиться в пять раз дольше и уж тем более работает в пять раз дольше.С использованием ФЯ отложенные вычисления более приятны. В пять раз меньше кода, соответственно, до пяти раз ускоряется время их создания (для дотошных, речь не идет о том, что физически быстрее написать. Меньше кода — меньше ошибок, быстрее процесс отладки) Таким образом что лучше: иметь средней руки программера, или квалифицированного функциональщика. Платить ему в пять раз больше, но получать код более быстрый и что важнее, выдавать на гора результат быстрее до пяти раз?
Мне в таких мерялках всегда нравилась вот эта игра: shootout.alioth.debian.org/...2/benchmark.php test=all& lang=java& lang2=hipe, итак, сравнивается джава и ерланг, что мы имеем, из 9 тестов: — джава разорвала ерланг по производительности везде, — ни о каких 5 разах в количестве строк кода речь не идет, джава проиграла только в трех тестах, в одном победила — джава в половине тестов сьела больше памяти
А давай сконцентрируемся на одной задаче, и ты покажешь как именно в ней ленивые вычисления поднимут на порядок производительность.
Сорри, писать код и показывать нет времени — у нас ночь, да и занят. Как будет возможность, тисну статью на блог.
Не совсем понятно причем в данном примере ленивые вычисления и ФЯ
С использованием ФЯ отложенные вычисления более приятны. В пять раз меньше кода, соответственно, до пяти раз ускоряется время их создания (для дотошных, речь не идет о том, что физически быстрее написать. Меньше кода — меньше ошибок, быстрее процесс отладки) Таким образом что лучше: иметь средней руки программера, или квалифицированного функциональщика. Платить ему в пять раз больше, но получать код более быстрый и что важнее, выдавать на гора результат быстрее до пяти раз?
Не обязательно, точнее не обязательно это будет интерпретировано как путь. Например это может быть поиском решения в алгоритме альфа-бета отсечения, или в методе ветвей и границ. Т.е может быть такая оценочная ф-ция, вычисление которой само по себе занимает много времени.
А давай сконцентрируемся на одной задаче, и ты покажешь как именно в ней ленивые вычисления поднимут на порядок производительность.
Но таки прошу пояснить, что же такое ленивые вычисления?
lazy evaluation — это завтрашние результаты вычисления функций уже сегодня
-
Это отложенные вычисления, которые делаются не тогда, когда поступила команда, а когда запрашиваются данные
Если я правильно понимаю, то именно так.
Я правильно понимаю что это задача поиска наикратчайшего пути между точками на очень большом графе с трудновычислимой функцией растояния?
Не обязательно, точнее не обязательно это будет интерпретировано как путь. Например это может быть поиском решения в алгоритме альфа-бета отсечения, или в методе ветвей и границ. Т.е может быть такая оценочная ф-ция, вычисление которой само по себе занимает много времени.
Но таки прошу пояснить, что же такое ленивые вычисления? Это отложенные вычисления, которые делаются не тогда, когда поступила команда, а когда запрашиваются данные или что? Переведите для тупых пожалуйста, а то в гугле забанили искать, что конкретно имеется в виду в данном треде.
Не совсем понятно причем в данном примере ленивые вычисления и ФЯ. Я не исключаю что на ФЯ можно достичь некоторого уменьшения количества строк кода за счет какого то синтаксического сахара, возможно даже в каких то случая это будет в пять раз, но данная ветка дискусии была посвящена флиянию ленивых вычислений на производительность?
Когда перебор всех вершин занимает слишком много времени, с другой само по себе вычисление оценочной ф-ции достаточно ресурсоемкое
Я правильно понимаю что это задача поиска наикратчайшего пути между точками на очень большом графе с трудновычислимой функцией растояния?
Может я что — то не так понимаю, но имхо как- то так
А когда не применим?; -)
Когда перебор всех вершин занимает слишком много времени, с другой само по себе вычисление оценочной ф-ции достаточно ресурсоемкое
Любой класический поиск в ширину даст такой же эфект
Не всегда применим
Имеется ввиду глубина поиска, можно получить достаточно хорошее решение на одной ветви и не идти глубже. Может сумбурно, но примерно так. Кстати, это тоже поиск на графе, просто граф формируется одновременно с вычислением
Любой класический поиск в ширину даст такой же эфект, так что примера я не понял...
Вовка, вы в Украине живете? Судя по тем числам которые вы приведите, не очень похоже, что вы в курсе про Украинские ЗП.
Да на Украине. Вот средняя З.П, по java. По функциональным Я.П, данных нет из чего я заключаю, что товар это штучный. Люди которые не просто знают Lisp/Haskell/Erlang, а — ля писали для себя несколько программок, а имеют хороший опыт в их применении таки большая редкость. Все — таки высокий порог вхождения это правда. Отсюда, сколько — же должен стоить человек который если уволится, проект нужно закрывать, совсем закрывать ибо нового вы не найдете — в пять раз больше среднего спеца наверное.
откуда мы знаем что пути более длинные не вычислив их
Имеется ввиду глубина поиска, можно получить достаточно хорошее решение на одной ветви и не идти глубже. Может сумбурно, но примерно так. Кстати, это тоже поиск на графе, просто граф формируется одновременно с вычислением
crypto5:
Можно конкретный пример, когда ленивые вычисления на порядок повышают производительность?
в моей практике был случай: нужно было написать некий маршрутизатор сообщений, причем сообщения приходили и отправлялись во множестве разных форматов. в первом варианте для каждого формата был написан плагин, который преобразовывал сообщения в некий универсальный формат и обратно. сообщения в универсальном формате отправлялись в собственно маршрутизатор, где на основании небольшого количества атрибутов принималось решение, куда это сообщение дальше направить (или вообще прибить). все это довольно сносно работало, но под большой нагрузкой начинало тормозить. в результате вместо того, чтобы сходу транслировать каждое сообщение, мы обернули сообщение в некий flyweight-контейнер, а трансляторы вообще вынесли в некое подобие словаря, который находил нужный плагин по паре (исходный формат, формат отправки). теперь сообщения транслировались только непосредственно перед отправкой. производительность выросла на порядок за счет того, что 1) иногда сообщения прибивались в процессе маршрутизации, 2) исходный формат и формат отправки часто совпадали, и 3) трансляция без промежуточного универсального формата нередко происходила быстрее и требовала меньше памяти. все это было написано на джаве (реалии enterprisey проекта), но подход — совершенно функциональный. на любом функциональном языке то же самое потребовало бы раз в 5 меньше кода, я уверен.
Пример конечно очень туманный, но имхо для поиска пути на графе и сходящимся к этому задачам было — бы очень кошерно применить сабж: нет смысла вычислять более длинные пути, если уже найдено приемлемое решение
Действительно туманный — откуда мы знаем что пути более длинные не вычислив их; -)
На С/С++/Java/C#/PHP реализовать такое конечно можно, но очень уж тяжко.Реализовать lazy initialization — это сложно? Не смешите.
Действительно просто, но кода явно больше будет.
когда ленивые вычисления на порядок повышают производительность?
Пример конечно очень туманный, но имхо для поиска пути на графе и сходящимся к этому задачам было — бы очень кошерно применить сабж: нет смысла вычислять более длинные пути, если уже найдено приемлемое решение
Не из пальца, а из личного опыта. Вы встречали подобную ситуацию? Можно подробности?
Сорри, в общий тред нельзя — в личку если хочешь
Пожалуйста — использование отложенных вычислений позволяют в ряде случаев ускорить работу на порядок.
Можно конкретный пример, когда ленивые вычисления на порядок повышают производительность?
Цифры высосаны из пальца.Как и отрицание оного.
Не из пальца, а из личного опыта. Вы встречали подобную ситуацию? Можно подробности?
На С/С++/Java/C#/PHP реализовать такое конечно можно, но очень уж тяжко.
Реализовать lazy initialization — это сложно? Не смешите.
Теперь ответь на вопрос: что лучше, платить среднему джависту две — две с половиной штуки в месяц и он будет педалить фичу месяц — полтора, или платить десять штук функциональщику и иметь нужные изменения в течении часа — двух
Вовка, вы в Украине живете? Судя по тем числам которые вы приведите, не очень похоже, что вы в курсе про Украинские ЗП.
Как и отрицание оного.
Давайте не опускаться до уровня «сам такой».
конкретный пример про быстроту
Пожалуйста — использование отложенных вычислений позволяют в ряде случаев ускорить работу на порядок. На С/С++/Java/C#/PHP реализовать такое конечно можно, но очень уж тяжко. На это дело по сему забивают до тех пор, пока не становится слишком поздно.
Цифры высосаны из пальца.
Как и отрицание оного.
Например, в ряде случаев использование функциональной парадигмы делает код на порядок более быстрым и более гибким.
А можно конкретный пример про быстроту?
он будет педалить фичу месяц — полтора, или платить десять штук функциональщику и иметь нужные изменения в течении часа — двух.
Цифры высосаны из пальца.
с качественной подготовкой в области прикладной математики или компьютерных наук
Не спорю, должны. Более того, их мало, на столько мало что при приеме на работу, придется платить практически по американским рейтам, да и то...
Вот тут не согласен, просто описанный подход в ряде случаев делает разработку очень эффективной. Например, в ряде случаев использование функциональной парадигмы делает код на порядок более быстрым и более гибким.в коммерческой разработке их использовать не эффективно (в основном из экономических соображений)
Я согласен, что в случае интернет магазина функциональщина наверное не нужна, но например в бухгалтерии, для описания постоянно меняющихся правил расчета, была — бы очень полезной.
Как правило в ФП приходят уже сформировавшимися на других языках и писавшими до этого что — нибудь дома.
А должны приходить люди с качественной подготовкой в области прикладной математики или компьютерных наук (даже не компьютерной инженерии, тем более не электроники или сельского хозяйства, я не отрицаю самообразование, но таких единицы), иначе это будет «императивный код на функциональном языке».
Вполне может быть, но это все равно требует качественной подготовки.В случае сложной деловой логики применения функциональной парадигмы оправдано.
Я не противник ФЯП, просто в коммерческой разработке их использовать не эффективно (в основном из экономических соображений), хотя для исследовательских задач, даже в рамках коммерческого продукта, это может быть оправдано, и то не всегда.
Решение: пишем понятный код, а заказчику разработки говорим в 2−4 раза больше, шоб не расслаблялся. потому что такой подход увеличит производительность, стабильность, маштабируемость, вешаем еще какую-то лабудень.
Бывают проекты поддержки в которых код уже попал таким
1) Заменить джависта или дотнетчика, проще чем программиста на, например, ерланге.
Настоящих синьоров на ФП значительно меньше, за счет ограниченности рынка.
Тут согласен.
2) Заказчик платит не за час работы, а за «добавленную кнопочку», и выбить за эту кнопочку бабла, работа продавца, а не программиста.
Не всегда
Порог входа в ФП значительно выше, соответственно затраты на «джуниоров» значительно выше.
Как правило в ФП приходят уже сформировавшимися на других языках и писавшими до этого что — нибудь дома.
Ваше предположение что у ФЯП эффективность выше чем у широкоиспользуемых языков (это, кстати, очень распространенный миф), наводит на мысль что у вас не очень много опыта в данном вопросе, хотя я могу и ошибаться.
Опыт не коммерческий, но эффективность языка зависит от задачи. В случае сложной деловой логики применения функциональной парадигмы оправдано. Более того, в несколько раз превышает традиционные яп. Вот утилиты а- ля отправка почты, отрисовка страниц и т.п. действительно можно на java/C#
Имхо в веб деве кодинг вообще не самая большая проблема. Т.е. применять «тяжелую артиллерию» (продвинутые языки, используемые узким числом редких дорогих профессионалов) мало пользы. Если это очень «узкий» вебдев, напр. вы делаете новый фесбук или гугл, или какой-нибудь comet чат на миллионы юзеров, то и узким технолониям можно найти применения. Если это просто сайтик какой-то, вроде интернет-магазина etc., то кодинг там просто вообще никакая не проблема на тех же java/php/python — зачем платить больше и рисковать?
Решение: пишем понятный код, а заказчику разработки говорим в 2−4 раза больше,Смотри, если сделать без уведомления заказчика часть программы на эрланге/хаскеле/питоне и потом завышать часы это будет обман.
5) Ваше предположение что у ФЯП эффективность выше чем у широкоиспользуемых языков (это, кстати, очень распространенный миф), наводит на мысль что у вас не очень много опыта в данном вопросе, хотя я могу и ошибаться.
А так, бабки листаются, работа идет — все довольны.
Неа, работать меньше надо всем, вот бабла сбить побольше то же надо. Решение: пишем понятный код, а заказчику разработки говорим в 2−4 раза больше, шоб не расслаблялся.Смотри, если сделать без уведомления заказчика часть программы на эрланге/хаскеле/питоне и потом завышать часы это будет обман. Кроме того, заказчик по различным причинам может передать поддержку в другую фирму, может решить, что будет поддерживать софт сам, может... да мало — ли что.
Потом начнутся разборки, дескать почему вы переделали нас не спросясь. Кроме того, время на переделку надо откуда — то брать. Невозможно выбросить говенный, но функциональный код и переписать все на другом языке без задержки релизов. Т.е. надо уведомлять заказчика, мол мы хотим сделать это и это. Заказчик спросит: «а зачем мне это надо? ». Значит нужно говорить, мол это уменьшит время разработки новых фич, т.е. в случае его согласия работы будет меньше. Вопрос: на фига это нужно?
что-то я недопонял...я в веб-деве не силен, но мне кажется, что все необходимые библиотеки для эрланга существуют, развиваются, и есть из чего выбирать. в моей практике пока был только один случай, когда пришлось писать библиотеку самостоятельно — народ на фронтенде хотел непременно использовать haml или нечто подобное, а в эрланге такого не было., но это имно ооочень частный случай.
ок, охотно верю, что есть на ергланге библиотеки для генерации ХТМЛ и подобного. Но вдруг возникла у меня, скажем, задача — интрегрировать свой сайт с фейсбуком используя OAuth2. Если необходимые библиотеки на эрланге есть, какую можно выбрать?
а в дополнение к привычной системе на RoR или там php — например, для comet server-а.
На питоне и джаве точно есть адекватные кометы, более чем уверен что есть они и для руби и пхп, на крайний случай можно интегрироваться с написанным на джаве. Такой подход лучше, потому что найти адекватного программиста (не обязательно синьора) на джаве проще чем на ФП просто потому что фунциональщиков меньше.
имно, на одну платформу вообще лучше не завязываться — хотя бы теоретически.
А завязываться на редкие языки — это угроза для дальнейшей разработки.
Не потолок: знаю людей, которые получают больше:)
Я то же знаю. И че? Суть в том, что в Украине разработчиков которые получают более 3, 1 Кбагза не так уж и много.
Кроме того, какая вам разница потолок это или нет. Вы можете платить больше, если да в чем проблема?
Уровень у кандидатов не синьорский.
В Америке за три бакинских в месяц 12*3=36 по моим данным только студента нанять можно, цены на нормальных специалистов начинаются от трех тысяч.
Я же сказал «в Украине», Украина — не Америка. А в Америке «цены на нормальных специалистов начинаются от» 5 Кбагза (и то зависит от локации)
Платят за час работы, если заказчик согласился, что подвинуть кнопочку стоит 10 часов из — за карколомных загогулин в коде. Никому не надо, чтоб работы стало меньше.
Неа, работать меньше надо всем, вот бабла сбить побольше то же надо. Решение: пишем понятный код, а заказчику разработки говорим в 2−4 раза больше, шоб не расслаблялся.
Не настучит, ему пофик куда девать деньги:)
Че правда? Далее эту тему развивать не буду, а предлагаю вам подумать той частью головы которая отвечает за анализ, а не за фантазии.
Я точно не в курсе, но около 3Кбагза/месяц (это по факту потолок для Украины впритык к 300 Кгрн в год). Вроде от 2, 8.
Не потолок: знаю людей, которые получают больше:) Кроме того, какая вам разница потолок это или нет. Вы можете платить больше, если да в чем проблема? Ах, за такую сумму можно нанять... эээ кого? В Америке за три бакинских в месяц 12*3=36 по моим данным только студента нанять можно, цены на нормальных специалистов начинаются от трех тысяч. Ах, нужно ещё оутсорсеру платить, так откажитесь от его услуг: создайте нормальное представительство, это не так — уж дорого стоит.
То что вы пишете — это полный бред. Кстати, как по вашему не настучит ли муж (скорее всего даже не жене, а врачу) за такие таблетки.
Не настучит, ему пофик куда девать деньги:)
Ваша аналогия немного не корректна. Потому что дамы из вашего примера платят за процесс, а реальные заказчики платят не за код, а за кнопочку на форме и им все равно как вы ее реализовали.
Платят за час работы, если заказчик согласился, что подвинуть кнопочку стоит 10 часов из — за карколомных загогулин в коде. Никому не надо, чтоб работы стало меньше.
Ну не знаю, если платформа достаточно богата и универсальна, все типичные решения давно отлажены и лежат на «кончиках пальцев», на рынке полно спецов, почему бы не юзать ее для 98% кода?
уж всяко лучше, чем жестко завязываться на одну платформу вроде джавы.Это еще почему?...
имно, на одну платформу вообще лучше не завязываться — хотя бы теоретически. «if all you have is a hammer, everything looks like a nail».
уж всяко лучше, чем жестко завязываться на одну платформу вроде джавы.
Это еще почему?...
silverwolf:
я в веб-деве не силен, но мне кажется, что все необходимые библиотеки для эрланга существуют, развиваются, и есть из чего выбирать. в моей практике пока был только один случай, когда пришлось писать библиотеку самостоятельно — народ на фронтенде хотел непременно использовать haml или нечто подобное, а в эрланге такого не было., но это имно ооочень частный случай.Веб-дев. Окружение для того ерланга, соизмеримо с окружением для пхп, руби, питона, джавы или дотНета? Я не знаю точно, но исходя из количества разработчиков, очень сомневаюсь.
кроме того, по моим наблюдениям, эрланг часто используется не вместо, а в дополнение к привычной системе на RoR или там php — например, для comet server-а. имно, вполне разумный подход — уж всяко лучше, чем жестко завязываться на одну платформу вроде джавы.
За сикока баксиков? Тут всё дело в сумме, понимаешь
Я точно не в курсе, но около 3Кбагза/месяц (это по факту потолок для Украины впритык к 300 Кгрн в год). Вроде от 2, 8.
То что вы пишете — это полный бред. Кстати, как по вашему не настучит ли муж (скорее всего даже не жене, а врачу) за такие таблетки.Ошибаешься, иногда человеку будет скучно жить без своей пустячной болезни. Например можно всю жизнь бороться с лишним весом пожирая всевозможные пилюли, сесть на диету и заняться спортом ни — ни. По сему, пустоголовые, но богатых мужей жены — клуши идут не к тому врачу, который посоветует спорт, а к тому который даст дорогущие пилюли с временным эффектом. И скажет, у вас такая сложная ситуация (вай — вай), но мы будем искать, будем пробовать. Вот например эти таблеточки, вытяжка из мозгов шанхайского барса, ну очень хороши. Правда дорого стоят, зато может типа помочь
Ваша аналогия немного не корректна. Потому что дамы из вашего примера платят за процесс, а реальные заказчики платят не за код, а за кнопочку на форме и им все равно как вы ее реализовали.
Уже более года ищем синьора джависта.
За сикока баксиков? Тут всё дело в сумме, понимаешь
Кстати, врачи которые «не полностью лечат богатых пациентов», как правило «долго не живут»
Ошибаешься, иногда человеку будет скучно жить без своей пустячной болезни. Например можно всю жизнь бороться с лишним весом пожирая всевозможные пилюли, сесть на диету и заняться спортом ни — ни. По сему, пустоголовые, но богатых мужей жены — клуши идут не к тому врачу, который посоветует спорт, а к тому который даст дорогущие пилюли с временным эффектом. И скажет, у вас такая сложная ситуация (вай — вай), но мы будем искать, будем пробовать. Вот например эти таблеточки, вытяжка из мозгов шанхайского барса, ну очень хороши. Правда дорого стоят, зато может типа помочь
если тупо искать резюме со словом erlang, то кандидатов, конечно, будет меньше, чем тех, у кого в резюме есть php
А если отбросить тех у кого нет опыта серьезного использования языка? А сколько из них настоящих синьоров?
все зависит от языка и предметной области.
Веб-дев. Окружение для того ерланга, соизмеримо с окружением для пхп, руби, питона, джавы или дотНета? Я не знаю точно, но исходя из количества разработчиков, очень сомневаюсь.
Да нет, не сложно совсем.
Уже более года ищем синьора джависта.
Даже в таком надгробье цивилизации каковым является Киев за двадцать — двадцать пять тысяч долларов в месяц можно нанять очень хорошего специалиста
25 000 * 12 = 300 000 багзов в год. Не надо фантазировать, и не надо рассказывать басни про мега крутых спецов. Украинские реалии это 300 тис грн.
ФП — требует по крайней мере профильное ВО (я не верю в самородков из СельХоз академии которые способны через пару месяцев писать функциональный код, это будет «императивный код на функциональном языке»).Вообще, функциональное программирование не применяется часто по той — же причине, по которой врач не лечит до конца богатого пациента, зато всегда прописывает ему необременительные процедуры и сладкие лекарства.
Кстати, врачи которые «не полностью лечат богатых пациентов», как правило «долго не живут» (обычно в профессиональном смысле, но иногда...)
Возможно ли перевести всю разработку на функциональный язык программирования и будет ли от этого плюсы?
короткий ответ — да, можно, и да, будут. примеров можно найти массу — от мелких стартапов до весьма серьезных проектов. Лев Валкин не так давно делился опытом своего стартапа: habrahabr.ru/...s/erlang/97610
— как правило, ФП подразумевает некий профессиональный уровень, поэтому сложно будет найти людей в команду (а еще сложнее их нанять)
если тупо искать резюме со словом erlang, то кандидатов, конечно, будет меньше, чем тех, у кого в резюме есть php. так что от рекрутера пользы будет меньше, да., но тот же erlang — язык небольшой и простой, и освоить его до приемлемого уровня за 2 недели — вполне посильная задача для вменяемого программиста. Лев об этом пишет.
— как правило, функциональный код медленнее чем императивный, особенно если просто «Почитал про Erlang, понравилось»
== императивный код на функциональном языке медленнее императивного кода на императивном языке.
— как правило, у ФЯП хуже с окружением (библиотеки)
все зависит от языка и предметной области. имно, более важный вопрос — насколько легко можно интегрировать в язык уже существующие компоненты. в том же erlang-e это достаточно продумано, на нескольких уровнях. в других фунуциональных языках (haskell, ocaml) тоже, как правило, очень и очень неплохой FFI.
Вывод:Если хочется поднять ЧСВ напишите домашний проектик, внедрять в промышленных масштабах, ИМХО, глупая затея (хотя и существуют примеры обратного).
глупо внедрять в промышленных масштабах что-либо только ради того, чтобы поиграть с новой технологией и добавить модную строчку к себе в резюме. ФП тут ни при чем.
именно по этой причине процветает аутсорсинг?
Оутсорсинг процветает по другой причине: в него можно отдать уже написанные проекты, чтобы когда надо можно было поменять цвет кнопочек с зелёного на красный. Проекты где надо начинать с начала в оутсорсинг не отдают практически никогда.
Да нет, не сложно совсем. Даже в таком надгробье цивилизации каковым является Киев за двадцать — двадцать пять тысяч долларов в месяц можно нанять очень хорошего специалиста (просто не все из старой гвардии ученых ещё уехали/отошли от дел).нанять хорошего спеца — очень сложно,
Вот по сему легче продираться сквозь лабиринты и получать за это бабло.
Нанимать людей с высоким профессиональным уровнем и платить им очень много, на порядок дешевле, чем толпу студентов по пять гривень за пучок и в два три раза дешевле, чем людей среднего уровня.Че правда? И именно по этой причине процветает аутсорсинг?
нанять стадо мартышек — просто, вот только стадо мартышек, как правило, не шарит ФП, или чего хуже думает что шарит (от тогда точно конец)
ФП подразумевает некий профессиональный уровень, поэтому сложно будет найти людей в команду (а еще сложнее их нанять)
Нанимать людей с высоким профессиональным уровнем и платить им очень много, на порядок дешевле, чем толпу студентов по пять гривень за пучок и в два три раза дешевле, чем людей среднего уровня.
Если вы знаете язык (и окружение) на который планируете перейти, то из плюсов сразу придумываютсяВозможно ли перевести всю разработку на функциональный язык программирования и будет ли от этого плюсы?
Если хочется поднять ЧСВ напишите домашний проектик, внедрять в промышленных масштабах, ИМХО, глупая затея (хотя и существуют примеры обратного).
anonymous
Sergii Voloshyn
Bogdan Shyiak
Сашко
59 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів