Pull to refresh

Comments 95

вы ето перепишите, вспомнив, какая буква пишется в слове «это» и производных
извините, русский не учил, вижу что в плюса еще не скоро влезу но спасибо за подсказку, исправлюсь
И еще слово «експеримент» следует исправить.
Стоило бы воспользоваться тегом habracut — он позволит снизить число раздраженных комментаторов :)
перво-наперво, под кат.
Во-вторых, хочется увидеть «продолжение банкета». В частности, обоснование «Erlang — лучший ЯП, с которого стоит начинать знакомство с функциональными языками»: я, вот, с функциональными языками познакомился на примере Haskell'а — и до сих пор доволен, хотя много в нём так и не усвоил.
кат сделал, продолжение будет после того, как увижу здесь достаточно комментариев и смогу по ним определить форму и содержимое продолжения :)

насчет почему эрланг лучший для знакомства с ФП — чисто субьективная точка зрения. вкратце — у эрланга синтаксис попроще хаскела.
ну вот вам иодна из тем для ближайшего продолжения: покажите нам красоту erlanga. Без сарказма: с удовольствием полюбуюсь. Будучи Java разработчиком радуюсь каждому изящному языку, как ребёнок )
А как насчет применения? Меня заинтересовало, что он широко применяется в телекоммуникациях. Это верно?

За последние полгода читал о Erlang-e в двух периодических изданиях.
да, неотъемлемая часть эрланга — OTP(Open Telecom Platform), да и сам язык разработаны в Ericsson и широко применяются в различных телекоммуникационных узлах. сами эриксоновцы заявляют, что с помощью эрланга и ОТП им удалось достичь 99.999999999% (9 девяток) аптайма, что есть весьма уникальный результат. стоит и сказать об непрожорливости эрланга — он с успехом применяется на различных embedded дэвайсах, лишь бы оперативной памяти хватило(как минимум 16 мб).
Эрланг хорош для первого знакомства тем, что на нем можно быстро написать то, что традиционных языках — весьма нетривиальная задача. Например, многопоточный сервер в десяток строк кода. Если и приврал в количестве строк, то самую малость.

Хаскеллу тоже есть чем поразить новичка — хотя бы работой с бесконечными списками — но все же «вау-эффект» слабее.

А что касается синтаксиса, тут как раз Эрланг мне кажется несовершенным.
Зоопарк разделителей — и запятые между операциями, и точки с запятой между clause-ами, и точки в конце определений. Хаскелловские отступы мне гораздо приятнее.
точки, запятые, точки с запятыми — это все пришло из пролога и они все имеют особый смысл.
, — это «и»
; — это «или»
. — конец предиката ну или чего там :)
Шок при знакомстве с Erlang это то что переменная не может быть присвоена более одного раза. Хочешь новое значение — делай еще одну переменную. i++ непройдет, нужно делать что-то типа i2 = i + 1.
Это не Erlang такой, это функциональное программирование такое:)
Странно — в математике вас это не смущает и вы, может и с неохотой, но вводите все эти a3 или ε8 — а как переходите к программированию, так у вас шок наступает…
Ну у меня вполне бывает переназначение на старые переменные и в математике :-)
Если нельзя сделать i = i + 1, то для меня это крайне непонятно и дико.
Понимате, если вы на бумаге написали какую-то переменную, то менять ее значение потом нет смысла — вы этим ни память, ни бумагу не сэкономите. :-)
Кстати, говоря, в математике есть переменные, меняющие значение: например в операторе Сумма или Произведение.
возможность делать i=i+1 подразумевает наличие изменяемой памяти, чего в Эрланге пытались избежать всю историю его создания(с 89го года).

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

а в математике в операторе сумма или произведение ничего не изменяется в контексте блока по которому итерируемся — значение i всегда одинаково во всей формуле.
Как делать присваивание и изменение переменной? Каждый раз объявлять новую?
Само собой, что i не меняется в течение конкретной итерации — оно меняется между ними.
присваивание — легко
изменение — никак

в большинстве случаев менять ничего не надо, достаточно грамотно разбить программу на отдельные функционалы, тогда и переменных меньше надо будет и программа правильнее в функциональном смысле.
Сумму можно рассмотреть как функционал, параметрами которого выступают лямбда выражение и два числа; а тот вид, который наиболее распространен, считать синтаксическим сахаром.
Я так подозреваю что ни Сумма ни Произведение не меняют значение тех переменных которыми оперируют, они возвращают третье, уже новое, значение.
Ведь при z = x + y и h = x * y ни x ни y не меняюся, так?
Если нельзя сделать i = i + 1, то для меня это крайне непонятно и дико.
Почему?
Понимате, если вы на бумаге написали какую-то переменную, то менять ее значение потом нет смысла — вы этим ни память, ни бумагу не сэкономите. :-)
Но ведь и с текстом программы то же самое! Чем, собственно, текст программы отличается от текста математической теоремы? Разрешите компилятору самому разбираться с тем где, когда и как вам хранить значения переменных! Это просто следующий шаг после C/C++: там вы разрешили компилятору самому заботится о том сколько, чего и когда хранить в регистрах, теперь вы отдаёте ему и управление памятью тоже. Не нужно бояться что он с этим плохо справится: в 90% случаев (а то и в 99%) он это делает не хуже человека, а там где он не справится — к вашим услугам C/C++ и ассемблер...
Кстати, говоря, в математике есть переменные, меняющие значение: например в операторе Сумма или Произведение.
А такое есть и в функциональных языках. И вводятся эти сокращённые обозначения так же — через рекурсию…
> Если нельзя сделать i = i + 1, то для меня это крайне непонятно и дико.
На то и называется переменной, чтобы меняться :)
Как эта возможность реализуется в Эрланге.

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

просто выбирайте правильные инструменты для своих задач. нигде в статье не написано, что эрланг или рекурсии — панацея ;)
ребята вы спорите о разном!
ни с чем в erlang'e смиряться не нужно

Просто есть Функциональные языки программирования, а есть Императивные и у них соответственно разные подходы.
в Эрланге нет переменных ;)
хорошее замечание. в Эрланге нет переменных, есть только данные, которые можно именовать, что вводит в заблуждение императивщиков, которые видят аналогию с использованием переменных.
А еще там нет циклов. :)

Изучаю всего лишь меньше недели, но восторгаюсь как младенец. Совсем иная парадигма, да, но она прелестна.
Лучший ЯП для обучения это например Scheme. Erlang со своим COP(Concurrent Oriented Programming) немного отвлекает от изучения функциональной парадигмы:)
Точно, совсем забыл про этот замечательный курс:)
Если кому будет интересно: mitpress.mit.edu/sicp/
а еще этот замечательный курс есть на русском, да еще и в книжном варианте, счастливым обладателем которой я являюсь

вот кста где можно прикупить
www.libex.ru/detail/book151196.html
вот еще замечательный ресурс — Структура и интерпретация компьютерных программ: заметки и решения
sicp.sergeykhenkin.com/
ну, использовать процессы совсем необязательно, в то же время использовать ФП в эрланге очень просто. мое мнение таково, что чем проще синтаксис, тем проще обучающемуся понять базовые понятия языка и нагляднее можно продемонстрировать решение задач с помощью етих понятий, главное чтоб парадигма совпадала.
Насчет чем проще тем лучше — полностью согласен. Но посмотрите всеже Shceme, там еще проще:) И особенно курс на который я ссылку дал чуть выше, лучше по функциональному программированию не найти.
Erlang все таки очень ускоспециализированный язык, хоть и функциональный.
По-моему, если уж изучать Erlang, то изучать надо именно его конкурентность.
И в связке с его платформой OTP. Тогда можно посмотреть мощные фичи для отказаустойчивых систем типо смены кода на ходу или мониторинг и перезапуск процесса при ошибке, и всякое прочее конкурентное:) Что к функциональному программированию по большому счету отношения не имеет.
Кстати, я сейчас тоже готовлю серию статей по Erlang'у, впринципе можно будет скооперироваться:)
Scheme посмотрю. Собственно Erlang начал учить после выхода знаменитой книги Армстронга именно из-за его конкурентности, но это был и первый успешный опыт с функциональностью чем я очень доволен(до Erlang'а пробовал освоить Haskell — терпения не хватило :)).

В остальном(OTP, fault-tolerance, смена кода) — согласен, но такие темы нужно поднимать после освещения всей функциональности языка, без чего добиться успехов в конкуррентности было бы трудно.

Скооперироваться — очень даже буду рад :)
Имхо, из функциональных языков Erlang является наименее узкоспециализированным. Во всяком случае меня он привлек именно тем, что на нем реализованно довольно много прикладных проектов (от бд до веб-фреймворков), а не только разного рода «академические».
Я под словом «узкоспециализированный» не подразумевал «академический». Erlang хоть и является языком общего назначения и на нем пишут вещи типо ErlyWeb и есть gs для создания GUI, всеже инструмент для создания высонагруженных, отказоустойчивых систем(читать серверов:)).
И основные проекты на нем это доказывают: ejabberd, YAWS, CouchDB.
Так что из функциональных языков, я бы сказал, он ну очень специализированный:)
Кстати, я сейчас тоже готовлю серию статей по Erlang'у, впринципе можно будет скооперироваться

Ну-ка, ну-ка :)
Изучать ФП лучше на Хаскеле, это будет идеологически более правильно, ибо scheme никак не препятствует использованию императивного стиля. ИМХО, разумеется.
Ну это смотря чего вы хотите достичь. Если ваша цель — «проникнуться духом», то Haskell лучше (не смухлюешь), а если ваша цель — «реальное функционально программирование», то лучше Scheme — именно потому что в любой реальной задаче есть части, которые функционально описываются плохо и в Haskell их написание и, особенно, восприятие весьма затруднено…
UFO just landed and posted this here
Давно ждал. Пытаюсь понемногу сам писать на нем, но к сожалению за неимением реальной задачи пока туго идет.
собственно и у меня опыта не очень много: дипломный проект + делаю эмулятор сервера ворлд оф варкрафт. итого по времени чуть больше года. но язык я считаю очень перспективным и интересным и уж точно достойным обсуждения на хабре.
Давно хотел писать на нём, но… Остановила нетривиальность запуска написанных приложений — достаточно быстро я этот OTP завести не смог. Было бы намного проще, если бы Erlang-приложения компилировались в обычные ELF/PE бинарники — мне не удалось найти никаких решений, позволяющих делать с ними такое. Впрочем, я так понимаю, архитектура и возможности Erlang/OTP и не позволят сделать это достаточно полноценно — не теряя всех вкусностей Erlang-а.
просто эрланг так не работает… эрланг это виртуальная машина и каждое эрланг-приложение может использовать одну или больше виртуальных машин в зависимости от аппаратного окружения. зачем же изолировать приложение в один узел? или наоборот — зачем изолировать целый узел лишь для одного приложения?
Ну так не всем многохостовые сервера писать надо. Может, я клиент написать хочу…
собственно говоря архитектура и возможности Erlang/OTP вас никак не ограничивают в этом, существуют успешные клиентские программы которые даже конкуррентности там не используют, но странен сам факт выбора этого ЯП для таких целей
Если какая-то система в серверной части использует Erlang, почему бы ей не использовать его же в клиентской-эндюзерной? Например, для реюза части кодовой базы.
однозначного ответа нет. Эрланг конечно не идеальный язык, и то что на протяжении 20ти лет он подтачивался именно для создания серверных приложений делает его не очень удобным для создания клиентских приложений.
wings3d
да дофига клиентский приложений
да везде их можно реализовать, топик то не об этом ;)
Хотим конкретных примеров для чего это вообще и с чем едят! А то какая-то вода :(
Вода, но забористая… меня, по крайней мере, зацепило.
UFO just landed and posted this here
знакомство с сим языком и функциональным программированием привело к сплошным растройствам. я всё ещё оперирую объектами, но уже знаю, что можно и по-другому.
кстати, вот более-менее сносная ide sourceforge.net/projects/erlybird
UFO just landed and posted this here
конечно, с создателем языка не посоревнуешся. может это и плохо но я решил не писать много а лишь в общих чертах описать возможности языка…
ИМХО весь этот пост мог бы быть предисловием к более серьезной статье. А так даже нет акцента на ФП. Все можно все можно свести к одной субъективной фразе: «Эрланг — рулит!».

Про трудности программирования на Джаве, Си и про потоки вообще бред :)

Мне вот интересно, в Эрланге память процессов изолируется как то по особенному и это контролируется не ОС? Раз уж затронули эту тему, то можно побольше технических деталей?
Насколько я знаю, все контролируется виртуальной машиной Erlang. Как работа с памятью, так и планировщик процессов.
весь этот пост и есть предисловием к серии статей об Эрланге и это можна понять с первых слов топика. субьективизм я пытался свести к минимуму — об этом можно подискутировать.

вы считаете многопоточное программирование в императивной парадигме интуитивно понятным и простым?

отсутствие технических деталей обьясняеться легко. просто прочитайте топик еще раз. первые 10 слов…
Не считаю простым, и не считаю сложным.

Но Вы ничего не противопоставили этому со стороны Эрланга, там вообще присутствует многопоточность? Без таких важных деталей в статье пропадает смысл.
вот она важная деталь:

> Каждый процесс изолирован и не имеет доступа к памяти других процессов
> если нет общей памяти то нет проблемы с доступом к этой памяти

процесс — читайте трэд или нить.

обещаю расписать обо всем подробнее в следующих топиках :)
Ну тогда это все объясняет. Процесс и поток это две разные вещи, поэтому я и не понял почему вы говорите о потоках в императивных языках, а потом о процессах в Эрланге.
Самое интересное, что процесс в Эрланге — и не процесс, и не поток с точки зрения ОС.
В принципе, порождение процесса в Эрланге почти столь же легковесная операция, как вызов метода в Яве.
Процесс в Эрланге — вещь более лёгкая, чем поток в императивном языке.
>вот она важная деталь:
ets может быть общей памятью между процессами ;)
конечно может, но использовать ets труднее чем научится правильно писать программы на эрланге. к тому же ваши программы будут удивительно медленны если вы решите писать в императивном стиле используя ets ;)

я не вспоминал об ets, дабы не пробуждать нездоровый интерес тем, кто лишь начинает осваивать эрланг
comet? Всегда считал это Streaming-ом. (читая статью не раз подумал об этом).

P.S. Имхо, вторая часть самая зачетная.
Пишите, конечно. Интересный язык с необычной парадигмой.
Только вправду исправьте ошибки. Сложная пунктуация, отсутствие речевых ошибок — не обязательно, а вот «ети» видеть неприятно: простейший спеллчеккер это исправит.
>лучший ЯП, с которого стоит начинать знакомство с функциональными языками
Erlang это конечно хорошо но начинать лучше с Scheme и SICP :)
А почему Scheme? Лиспоподобный синтаксис может отпугнуть — слишком низкий уровень, при высокой логической красоте. Так что я бы скорее голосовал за Haskell как первый функциональный язык.
А хаскель может отпугнуть матаном не-математиков :) Да дело даже не в самой схеме, а в SICP, очень лёгкая и полезная книга. Перестроить мышление с императивного на функциональное не так-то просто, SICP учит, а потом можно хотя за erlang, хаоть за haskell или за ocaml садиться.
Матаном там не пахнет — только мат. логика, теория категорий и λ-исчисление:)
Жалко людей, для которых математика это только матан.
Вот только объём исходного кода ejabberd на Erlang больше, чем OpenFire на Java при меньших возможностях…
я не знаю смотрели ли вы сами на объём исходников этих проектов, кажется нет. объем исходником ежабберда — 15 мегабайт вместе с локализациями на десятки языком(которые и занимают большинство этого обьема). без локализаций(ибо это не код) объём — 3 мегабайта.

на сайте OpenFire предлагают скачать архив с исходниками размером 51 мегабайт.

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

и вообще надо бы давать пруфлинк делая такие заявления
Исходники не в смысле зипов с документацией на сайте, а тексты на языке программирования.
Из возможностей например у ejabberd нет поддержки ntlm.
сделал чекаут сурсов OpenFire. всего — 72 мегабайт. размер папки src — 28 мегабайт.
насчет поддержки ntlm, в OpenFire она тоже с рогами реализована да и клиентов под это дело почти нет. преимущество неубедительное имхо
Не очень правильно обосновывать «меньше возможностей» примерами фич, которых нет ;) Может ntlm в ejabber-е и нету, но общее количество поддерживаемых XEP-ов может оказаться бОльшим.
И ещё не верю, что управление каналами при помощи мультиплексирования сообщений работает лучше, чем мультиплексирование соединений.
есть программы написаные на этом языке?
конечно есть. один из популярнейших в мире жаббер серверов ejabberd написан на эрланге, также есть веб-сервер YAWS, веб-платформа Mochiweb, встроенная в язык база данных Mnesia, поддерживающая кластеризацию и репликацию на многих узлах в сети, также есть перспективный проект документо-ориентированной базы данных CouchDB с возможностью доступа через REST-интерфейс. программ много, гугл вам в помощь.
А какие есть хорошие книги по Erlang'у?
Обязательно продолжайте! Жду двух вещей:
= Хотелось бы оценить синтаксис с высоты птичьего полёта.
= Приведите какие-нибудь выразительные примеры (компактные, но понятные и демонстрирующие плюсы языка). Скажем можно ли на Erlang легко отсортировать массив данных, который хранится на двух машинах и не может поместиться на одной? А если два заменить на 100? ,-) Было бы очень интересно!
спасибо за статью, узнал много нового
Почитал, что Erlang более эффективный язык, чем традиционные императивные языки.
Одно мне непонятно: почему ejabber на erlang имеет исходный код в 4 раза больше, чем jabberd2?

Очень надеюсь на ответ. Так как для меня, как для программиста, лучше тот язык на котором код короче
Sign up to leave a comment.

Articles