Комментарии 81
Спасибо. Интересная статья.
Хуита
Теперь вместо того, что бы создавать переносимый код какие-то идиоты будут писать на рубиподобном гавне, только из-за того, что другой закостенелым мозгом прилип к объектно-ориентированному программированию. К сожалению еще один бесполезный проект в тонущем гавне второго математического кризиса.
Да ладно прям…
Вон Scala например — язык на основе Java JVM, но с функциональным уклоном… Тоже будем кричать «Не нужен»?
Вон Scala например — язык на основе Java JVM, но с функциональным уклоном… Тоже будем кричать «Не нужен»?
С другой стороны, позитивный момент в том что все больше интереса к erlang vm и его принципам. Да, эти все языки-надстройки скорее лишний барьер на пути к ерлангу, но про позитивные индикаторы не стоит забывать.
Кто-нибудь объяснит мне, зачем оно вообще нужно?
Потому что синтаксис эрланга кажется многим несколько своеобразным.
Синтаксис руби тоже многим кажется своебразным :)
В большинстве своем тех, кому не нравится синтаксис Erlang, удовлетворит синтаксис Ruby.
Рубияны любят Elixir :)
Ох не то слово — скрестили смолтолк с паскалем, блин :) Вот бы кто-нибудь замутил язык для Erlang VM на базе питона…
Не на базе питона, но похож на него — efene.tumblr.com marianoguerra.com.ar/efene/
Мое мнение что синтаксис у Erlang`а простой.
Да, может поначалу немного странноват, но ко всему привыкаешь.
Да, может поначалу немного странноват, но ко всему привыкаешь.
Меня вот тут убивает открывающий апостроф без закрывающего — это ужастно.
Например как мне задать вот такой атом 'aa,bb' с запятой внутри? И как с ним не запутаться?
Например как мне задать вот такой атом 'aa,bb' с запятой внутри? И как с ним не запутаться?
Да тут не только на синтаксис посягнули… Какие нафик объекты в Эрланге? :\
Да нормальный там синтаксис. Но тут же не только синтаксис добавили, они ж еще и объекты туда воткнули зачем-то.
Почему бы не писать имя автора по-русски?
«Хозе Валим (José Valim) опубликовал в своём...»
«Хозе Валим (José Valim) опубликовал в своём...»
Спасибо большое, меня проект заинтересовал, возможно для меня это будет переходной точкой к erlang.
Весьма занятно… Параллелить главное тоже умеет))
Есть, кстати, еще Reia reia-lang.org/ вроде тоже немного похоже
Есть, кстати, еще Reia reia-lang.org/ вроде тоже немного похоже
Добавьте тег велосипеды
поправьте: «Mixin'ы — объекты не содержать методов. „
Вообще интересно.
С эрлангом всегда не хватало простого
list.map( x => x*x ).
весь этот fun...end только мешается.
Но вот внесение состояния (объекты ) это разрушает основной принцип ФП. И тогда вообще не понятно причем тут единстевнное присвание.
Вообще интересно.
С эрлангом всегда не хватало простого
list.map( x => x*x ).
весь этот fun...end только мешается.
Но вот внесение состояния (объекты ) это разрушает основной принцип ФП. И тогда вообще не понятно причем тут единстевнное присвание.
Эти объекты — синтаксический сахар. Они скрывают необходимость использования отдельной структуры для передачи в различные функции:
Изменение свойств объекта возвращает новую структуру, как и в Erlang:
%Erlang
Person = person:find(john),
Modified = person:set(name, john_doe, Person)
true = person:save(Modified)
%Elixir
In Elixir, this would be written as:
person = Person.find('john)
modified = person.set('name, 'john_doe)
true = modified.save
Изменение свойств объекта возвращает новую структуру, как и в Erlang:
object Person
def constructor(name, age)
{ 'name: name, 'age: age }
end
def name
@name
end
def age
@age
end
def name(value)
self.set_ivar('name, value)
end
end
person = Person.new('john, 24)
another_person = person.name('john_doe)
person.name % => 'john
person.age % => 24
another_person.name % => 'johh_doe
another_person.age % => 24
Тогда отставить тревогу, пошел играться.
Добавте эти строчки в обзор, пожалуйста, они упрощают понимание:
Добавте эти строчки в обзор, пожалуйста, они упрощают понимание:
Эти объекты — синтаксический сахар. Они скрывают необходимость использования отдельной структуры для передачи в различные функции:Изменение свойств объекта возвращает новую структуру, как и в Erlang:
«Elixir способен просматривать и модифицировать структуру объекта во времени исполнения.»
seriously?
seriously?
Я вчера с Хосе Валимом поработал немного на тему пригодности elixir внутри живых проектов. Посмотрим — может попробую приткнуть в erlyvideo.
Занятно, занятно…
Сам Эрланг то страшен как атомная война, а вот с его VM давно хотелось поиграть, уж больно интересные вещи умеет.
Очень надеюсь, что авторы не бросятся на втачивание фичей, а займутся документацие и тьюториалами.
Вопрос: были другие попытки завести приличный язык под Erlang VM(знаю, у неё есть собственное название — не могу вспомнить). Что-то другое Ruby подобное и LISP. Я верно понимаю, что оба они полумёртвые и промышленного применения не имеют?
Сам Эрланг то страшен как атомная война, а вот с его VM давно хотелось поиграть, уж больно интересные вещи умеет.
Очень надеюсь, что авторы не бросятся на втачивание фичей, а займутся документацие и тьюториалами.
Вопрос: были другие попытки завести приличный язык под Erlang VM(знаю, у неё есть собственное название — не могу вспомнить). Что-то другое Ruby подобное и LISP. Я верно понимаю, что оба они полумёртвые и промышленного применения не имеют?
Вот я до сих пор пытаюсь понять, в чем страшность Erlang? Где именно начинается непонимание?
Нужно отличать объективные и субъективные вещи.
Erlang позволяет легко писать гибкие распределенные системы. Это объективная реальность.
Я понимаю синтаксис Eralng, и он мне нравится. Это субъективная реальность, которая применима ко мне, но не применима к Васе из Челябинска.
Erlang позволяет легко писать гибкие распределенные системы. Это объективная реальность.
Я понимаю синтаксис Eralng, и он мне нравится. Это субъективная реальность, которая применима ко мне, но не применима к Васе из Челябинска.
1. Отсутствие нормальных структур данных с именованными полями. Всё впихивается в списки и кортежи.
2. Как следствие первого — паттерн-матчинг основное средство работы со структурами. В учебных примерах всё красиво, но реальный код, который видел в репозитариях проектов мягко говоря напрягает. В своём проекте такого ниразу не хочется.
3. Зависисмость от знаков препинания.
Как следствие уже три раза начинал ковырять учебник на оф. сайте и бросал через пару глав. Становилось очевидно, что 80% усилий идут не на осознание соответствующих идей а на парсинг кода. Даже с хаскелем и F# не настолько всё плохо.
2. Как следствие первого — паттерн-матчинг основное средство работы со структурами. В учебных примерах всё красиво, но реальный код, который видел в репозитариях проектов мягко говоря напрягает. В своём проекте такого ниразу не хочется.
3. Зависисмость от знаков препинания.
Как следствие уже три раза начинал ковырять учебник на оф. сайте и бросал через пару глав. Становилось очевидно, что 80% усилий идут не на осознание соответствующих идей а на парсинг кода. Даже с хаскелем и F# не настолько всё плохо.
1. records? (они, конечно, не идеал, но задачу именованных полей решают весьма сносно).
2. И как следствие, я нахожу pattern matching по records весьма удобным. Можно примеры кода который напрягает?
3. Вас напрягает зависимость от знаков препинания в натуральном языке? В erlang, как по мне, весьма логичная схема. Если думать о ф-циях как о предложениях, все становится на свои места. Мы же не ставим точку посреди предложения? Коньюктивы отображаем как запятые? Ну а точка с запятой — это «или» — что то вроде «Мы можем поступить так; или можно пойти другим путем». С этой аналогией мне в свое время стало легко вкуриться в синтаксис.
learnyousomeerlang.com видели?
2. И как следствие, я нахожу pattern matching по records весьма удобным. Можно примеры кода который напрягает?
3. Вас напрягает зависимость от знаков препинания в натуральном языке? В erlang, как по мне, весьма логичная схема. Если думать о ф-циях как о предложениях, все становится на свои места. Мы же не ставим точку посреди предложения? Коньюктивы отображаем как запятые? Ну а точка с запятой — это «или» — что то вроде «Мы можем поступить так; или можно пойти другим путем». С этой аналогией мне в свое время стало легко вкуриться в синтаксис.
learnyousomeerlang.com видели?
1. Ага, и правда есть… В предпоследнем разделе тьюториала. Я бросил раньше. Судя по тому, что нагуглилось они сильно перегружены каким-то синтаксическим мусором при использовании.
2. Да вот жеж ведь!
3. Наверно я просто избалован Scala/Groovy/Python, но меня раздражает необходимость лишний раз что-то вводить в очевидных местах. Кроме того это потворствует попыткам втыкать по несколько конструкций на строку :)
2. Да вот жеж ведь!
3. Наверно я просто избалован Scala/Groovy/Python, но меня раздражает необходимость лишний раз что-то вводить в очевидных местах. Кроме того это потворствует попыткам втыкать по несколько конструкций на строку :)
я тебе сразу скажу: код, который по ссылке про Comet приложение сдохнешь отлаживать.
В связи с отсутствием номеров строк в стектрейсах эрланга, второй уровень вложенности case приводит к очень серьезным проблемам в диагностике ошибок. В итоге эта проблема очень сильно подталкивает к существенно более цивильному способу написания программ в виде разнесения логики по функциям.
Иначе говоря, код который по ссылке явно не эталон. Уже не говоря про некоторые остальные тонкости, делающие его поддержку мучительной.
Что до синтаксического мусора, то действительно не всё сделано минимально, впрочем гораздо более высокоуровневая семантика паттерн-матчинга компенсирует неидеальность синтаксиса, что в итоге в моей практике приводит к коду, который в 5-100 раз компактнее, чем аналог на джаве.
В связи с отсутствием номеров строк в стектрейсах эрланга, второй уровень вложенности case приводит к очень серьезным проблемам в диагностике ошибок. В итоге эта проблема очень сильно подталкивает к существенно более цивильному способу написания программ в виде разнесения логики по функциям.
Иначе говоря, код который по ссылке явно не эталон. Уже не говоря про некоторые остальные тонкости, делающие его поддержку мучительной.
Что до синтаксического мусора, то действительно не всё сделано минимально, впрочем гораздо более высокоуровневая семантика паттерн-матчинга компенсирует неидеальность синтаксиса, что в итоге в моей практике приводит к коду, который в 5-100 раз компактнее, чем аналог на джаве.
Так если в учебную статью постят говнокод что-то не отлаживаемое, что будет когда «проект надо было сдать вчера а у нас 50 ошибок в трекере»?
Ну, можно ещё с C++ сравнить :) Да и вообще компактность шутка сложная, в Java большая часть многословности тоже не от ограничений языка, а от принятого стиля программирования.
Ну, можно ещё с C++ сравнить :) Да и вообще компактность шутка сложная, в Java большая часть многословности тоже не от ограничений языка, а от принятого стиля программирования.
1. А рекорды чем не угодили? При всем при этом они остаются всего лишь сахаром. Действительно списков и кортежей достаточно. Но рекорды есть и их даже матчить можно. В реальных проектах все нормально.
3. Как это зависимость? Вы не можете разобраться, где ставить ",", где ";" а где "."?
3. Как это зависимость? Вы не можете разобраться, где ставить ",", где ";" а где "."?
Меня лично напрягает то что ',' и ';' сепараторы, а не терминаторы (как в C# например).
то есть получать ошибку тут:
A = a(),
B = b(),
.
не очень то приятно.
А вообще на мой взгляд эрланг хорошие вещи у пролога позаимствовал.
то есть получать ошибку тут:
A = a(),
B = b(),
.
не очень то приятно.
А вообще на мой взгляд эрланг хорошие вещи у пролога позаимствовал.
Ответил выше.
Не понял насчёт «паттерн-матчинг основное средство работы со структурами»
Во-первых, это не единственное средство работы, во-вторых чего тут плохого?
Какой именно код не нравится?
К рекордам претензии совершенно другие и пока хороших способов решения нет.
Зависимость от знаков препинания — да, утомляет.
Во-первых, это не единственное средство работы, во-вторых чего тут плохого?
Какой именно код не нравится?
К рекордам претензии совершенно другие и пока хороших способов решения нет.
Зависимость от знаков препинания — да, утомляет.
Мне вот все еще интересно, откуда выплывает утомление от знаков препинания?
От того, что при перестановке двух клозов местами, надо не забыть поменять знаки препинания.
В итоге лишние изменения в гит-репозитории, лишнее место для ошибок.
Знаки препинания в эрланге реально утомляют. Причем особено утомляет даже не ,; а то, что иногда почему-то становится нельзя ставить;
В итоге лишние изменения в гит-репозитории, лишнее место для ошибок.
Знаки препинания в эрланге реально утомляют. Причем особено утомляет даже не ,; а то, что иногда почему-то становится нельзя ставить;
Примеры «иногда»?
case Frame#video_frame.codec of
h264 -> handle_h264(Frame);
aac -> handle_aac(Frame);
pcma -> handle_pcma(Frame)
end
удаляем клоз на pcma и получаем синтаксическую ошибку. В итоге в изменениях будет видно удаление 2-х строк, а не одной. Хорошего мало.
Но ведь это не про «почему-то», это же вполне ожидаемое поведение.
Ожидаемое с точки зрения уже существующего парсера.
Тем не менее оно для меня очень нелогичное и неудобное.
Тем не менее оно для меня очень нелогичное и неудобное.
Меня лично это момент ничуть не утомляет. Однако можно попробовать нестандартное форматирование?
case Frame#video_frame.codec of
h264 -> handle_h264(Frame)
; aac -> handle_aac(Frame)
; pcma -> handle_pcma(Frame)
end
мне кажется вообще, что эта проблема совсем не уникальная для erlang. switch/case statement не утомляет в C? или в сложных or/and конструкциях в условиях в любом языке нас же не удивляет что последний or или and оператор надо тоже удалить?
По поводу последнего, представим такой код:
предположим, последнее условее более не надо
сколько строчек поменяется в гите? правильно, тоже две.
По поводу последнего, представим такой код:
if ( (flag & TCP_NOKIDDING) ||
zlag < Z_LAG_THR ) {
...
}
предположим, последнее условее более не надо
if (flag & TCP_NOKIDDING) {
..
}
сколько строчек поменяется в гите? правильно, тоже две.
switch(frame->codec) {
case H264: handle_h264(frame); break;
case AAC: handle_aac(frame); break;
case PCMA: handle_pcma(frame); break;
}
Так человечнее
по сути ответа на пример с if'ом не было ;)
а человечнее имхо было бы сделать
handle_frame(Frame),
..
handle_frame(#video_frame{ codec = h264 } = Frame) ->
...
ну и так далее по тексту
if ( (flag & TCP_NOKIDDING) ||
zlag < Z_LAG_THR ) {
...
}Если бы у меня был километровый if, то его проще переписать так:
if (
(flag & TCP_NOKIDDING)
|| zlag < Z_LAG_THR
) {
...
}Чтобы в логе гита изменялись не все строки, а только строки, содержащие условие — то есть там где реально было изменение смысла.
И вам тоже ответил выше :)
да, синтаксис чем-то похож на структуру английских предложений.
Но программисткий язык все же отличается от человеческого — с ним идет немного другая работа, поэтому он может немного отличаться.
Идеальный терминатор строки — это его отсутствие.
Наоборот, если выражение продолжается, то надо его продлевать и этот случай обозначать особенным образом. Потому что лишь 0.1% выражений приходится переносить на другую строку, все остальные нормально помещаются. Поэтому удобнее писать 1 раз на 1000 строк "\" в конце, чем в каждой строке ставить ",;.".
Единсвтенно, если не использовать выделение блоков отсутпами, то можно использовать слово end
Но программисткий язык все же отличается от человеческого — с ним идет немного другая работа, поэтому он может немного отличаться.
Идеальный терминатор строки — это его отсутствие.
Наоборот, если выражение продолжается, то надо его продлевать и этот случай обозначать особенным образом. Потому что лишь 0.1% выражений приходится переносить на другую строку, все остальные нормально помещаются. Поэтому удобнее писать 1 раз на 1000 строк "\" в конце, чем в каждой строке ставить ",;.".
Единсвтенно, если не использовать выделение блоков отсутпами, то можно использовать слово end
Не вижу смысла в этом эликсире. Ну синтаксис поменяли, но семантика, то осталась функциональная, разве нет? Т.е. большинству людей всё равно будет слишком непривычно. Плюс синтаксис не соответствует семантике, т.е. даже для знакомых с ФП язык плох.
радует, что основной коммитер — Jose Valim :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Elixir