Elixir

[kuser]

Спасибо. Интересная статья.

[cursed]

Это не совсем статья. Хотелось завлекалочку написать.

[5HT]

Хуита

[5HT]

Теперь вместо того, что бы создавать переносимый код какие-то идиоты будут писать на рубиподобном гавне, только из-за того, что другой закостенелым мозгом прилип к объектно-ориентированному программированию. К сожалению еще один бесполезный проект в тонущем гавне второго математического кризиса.

[seriyPS]

Да ладно прям…

Вон Scala например — язык на основе Java JVM, но с функциональным уклоном… Тоже будем кричать «Не нужен»?

[yrashk]

С другой стороны, позитивный момент в том что все больше интереса к erlang vm и его принципам. Да, эти все языки-надстройки скорее лишний барьер на пути к ерлангу, но про позитивные индикаторы не стоит забывать.

[EvilBlueBeaver]

Кто-нибудь объяснит мне, зачем оно вообще нужно?

[Leeb]

Потому что синтаксис эрланга кажется многим несколько своеобразным.

[jakobz]

Синтаксис руби тоже многим кажется своебразным :)

[cursed]

В большинстве своем тех, кому не нравится синтаксис Erlang, удовлетворит синтаксис Ruby.

[netslavehq]

Рубияны любят Elixir :)

[CheatEx]

Ох не то слово — скрестили смолтолк с паскалем, блин :) Вот бы кто-нибудь замутил язык для Erlang VM на базе питона…

[xyu]

Не на базе питона, но похож на него — efene.tumblr.com marianoguerra.com.ar/efene/

[CheatEx]

Спасибо посмотрю. Обидно, что вообще ниразу в гугле не всплывает.

А не знаете ничего о его практическом использовании? Коммерческие или хотя-бы opensource проекты?

[netslavehq]

Мое мнение что синтаксис у Erlang`а простой.
Да, может поначалу немного странноват, но ко всему привыкаешь.

[el777]

Меня вот тут убивает открывающий апостроф без закрывающего — это ужастно.
Например как мне задать вот такой атом 'aa,bb' с запятой внутри? И как с ним не запутаться?

[cursed]

Эти синтаксис атомов в лиспе. Не помню, зачем такое нужно было делать, но автор упоминал.

Что насчет вашего примера, то вот такой вариант будет работать:

'"aa,bb"

Насколько это красиво, другой вопрос.

[RomkoGoofique]

Да тут не только на синтаксис посягнули… Какие нафик объекты в Эрланге? :\

[EvilBlueBeaver]

Да нормальный там синтаксис. Но тут же не только синтаксис добавили, они ж еще и объекты туда воткнули зачем-то.

[Leeb]

Так я и не утверждал обратного. Но у некоторых не получается понять, как без ООП в их привычном понимании (в виде java, c# и тому подобного) можно проектировать и писать большие системы. На rsdn некоторое время назад был довольно эпический спор на эту тему.

[EvilBlueBeaver]

Ну так значит и erlang этим людям не нужен, если они не в состоянии понять)

[bubuq]

Почему бы не писать имя автора по-русски?
«Хозе Валим (José Valim) опубликовал в своём...»

[moborb]

Спасибо большое, меня проект заинтересовал, возможно для меня это будет переходной точкой к erlang.

[pluseg]

Согласен. Спасибо, что привели основы синтаксиса Erlang'a и Elixir'a.

[seriyPS]

Весьма занятно… Параллелить главное тоже умеет))

Есть, кстати, еще Reia reia-lang.org/ вроде тоже немного похоже

[erlyvideo]

Reia не умеет работать с #record{}-ами

[oogl]

Добавьте тег велосипеды

[zvulon]

поправьте: «Mixin'ы — объекты не содержать методов. „

Вообще интересно.
С эрлангом всегда не хватало простого
list.map( x => x*x ).
весь этот fun...end только мешается.

Но вот внесение состояния (объекты ) это разрушает основной принцип ФП. И тогда вообще не понятно причем тут единстевнное присвание.

[cursed]

Эти объекты — синтаксический сахар. Они скрывают необходимость использования отдельной структуры для передачи в различные функции:

%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

[zvulon]

Тогда отставить тревогу, пошел играться.

Добавте эти строчки в обзор, пожалуйста, они упрощают понимание:

Эти объекты — синтаксический сахар. Они скрывают необходимость использования отдельной структуры для передачи в различные функции:

Изменение свойств объекта возвращает новую структуру, как и в Erlang:

[avesus]

А потом мы забудем, что есть возможность multidispatch'а… Благими намерениями…

[yrashk]

«Elixir способен просматривать и модифицировать структуру объекта во времени исполнения.»

seriously?

[erlyvideo]

Я вчера с Хосе Валимом поработал немного на тему пригодности elixir внутри живых проектов. Посмотрим — может попробую приткнуть в erlyvideo.

[david_mz]

А напишите потом впечатления от языка?

[erlyvideo]

Да, конечно отпишусь.

[avesus]

Простите, и как язык?

[dalfy]

Видимо так себе :)

[CheatEx]

Занятно, занятно…
Сам Эрланг то страшен как атомная война, а вот с его VM давно хотелось поиграть, уж больно интересные вещи умеет.

Очень надеюсь, что авторы не бросятся на втачивание фичей, а займутся документацие и тьюториалами.

Вопрос: были другие попытки завести приличный язык под Erlang VM(знаю, у неё есть собственное название — не могу вспомнить). Что-то другое Ruby подобное и LISP. Я верно понимаю, что оба они полумёртвые и промышленного применения не имеют?

[yrashk]

Вот я до сих пор пытаюсь понять, в чем страшность Erlang? Где именно начинается непонимание?

[cursed]

Нужно отличать объективные и субъективные вещи.

Erlang позволяет легко писать гибкие распределенные системы. Это объективная реальность.
Я понимаю синтаксис Eralng, и он мне нравится. Это субъективная реальность, которая применима ко мне, но не применима к Васе из Челябинска.

[yrashk]

Это все понятно, но вопрос вот в чем: где начинается затык у Васи из Челябинска?

[CheatEx]

1. Отсутствие нормальных структур данных с именованными полями. Всё впихивается в списки и кортежи.

2. Как следствие первого — паттерн-матчинг основное средство работы со структурами. В учебных примерах всё красиво, но реальный код, который видел в репозитариях проектов мягко говоря напрягает. В своём проекте такого ниразу не хочется.

3. Зависисмость от знаков препинания.

Как следствие уже три раза начинал ковырять учебник на оф. сайте и бросал через пару глав. Становилось очевидно, что 80% усилий идут не на осознание соответствующих идей а на парсинг кода. Даже с хаскелем и F# не настолько всё плохо.

[yrashk]

1. records? (они, конечно, не идеал, но задачу именованных полей решают весьма сносно).
2. И как следствие, я нахожу pattern matching по records весьма удобным. Можно примеры кода который напрягает?
3. Вас напрягает зависимость от знаков препинания в натуральном языке? В erlang, как по мне, весьма логичная схема. Если думать о ф-циях как о предложениях, все становится на свои места. Мы же не ставим точку посреди предложения? Коньюктивы отображаем как запятые? Ну а точка с запятой — это «или» — что то вроде «Мы можем поступить так; или можно пойти другим путем». С этой аналогией мне в свое время стало легко вкуриться в синтаксис.

learnyousomeerlang.com видели?

[CheatEx]

1. Ага, и правда есть… В предпоследнем разделе тьюториала. Я бросил раньше. Судя по тому, что нагуглилось они сильно перегружены каким-то синтаксическим мусором при использовании.
2. Да вот жеж ведь!
3. Наверно я просто избалован Scala/Groovy/Python, но меня раздражает необходимость лишний раз что-то вводить в очевидных местах. Кроме того это потворствует попыткам втыкать по несколько конструкций на строку :)

[erlyvideo]

я тебе сразу скажу: код, который по ссылке про Comet приложение сдохнешь отлаживать.

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

Иначе говоря, код который по ссылке явно не эталон. Уже не говоря про некоторые остальные тонкости, делающие его поддержку мучительной.

Что до синтаксического мусора, то действительно не всё сделано минимально, впрочем гораздо более высокоуровневая семантика паттерн-матчинга компенсирует неидеальность синтаксиса, что в итоге в моей практике приводит к коду, который в 5-100 раз компактнее, чем аналог на джаве.

[CheatEx]

Так если в учебную статью постят говнокод что-то не отлаживаемое, что будет когда «проект надо было сдать вчера а у нас 50 ошибок в трекере»?

Ну, можно ещё с C++ сравнить :) Да и вообще компактность шутка сложная, в Java большая часть многословности тоже не от ограничений языка, а от принятого стиля программирования.

[Leeb]

1. А рекорды чем не угодили? При всем при этом они остаются всего лишь сахаром. Действительно списков и кортежей достаточно. Но рекорды есть и их даже матчить можно. В реальных проектах все нормально.

3. Как это зависимость? Вы не можете разобраться, где ставить ",", где ";" а где "."?

[zvulon]

Меня лично напрягает то что ',' и ';' сепараторы, а не терминаторы (как в C# например).

то есть получать ошибку тут:
A = a(),
B = b(),
.
не очень то приятно.

А вообще на мой взгляд эрланг хорошие вещи у пролога позаимствовал.

[el777]

Здесь терминатор — точка ".".
А "," и ";" разделители.

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

Хотя потом привыкаешь, что последняя запятая не нужна — как в натуральных языках.

[zvulon]

Я про то же, выглядит красиво,
но при добавлении \ обмене местами выражений иногда раздражает.

[CheatEx]

Ответил выше.

[erlyvideo]

Не понял насчёт «паттерн-матчинг основное средство работы со структурами»
Во-первых, это не единственное средство работы, во-вторых чего тут плохого?
Какой именно код не нравится?

К рекордам претензии совершенно другие и пока хороших способов решения нет.

Зависимость от знаков препинания — да, утомляет.

[yrashk]

Мне вот все еще интересно, откуда выплывает утомление от знаков препинания?

[erlyvideo]

От того, что при перестановке двух клозов местами, надо не забыть поменять знаки препинания.
В итоге лишние изменения в гит-репозитории, лишнее место для ошибок.

Знаки препинания в эрланге реально утомляют. Причем особено утомляет даже не ,; а то, что иногда почему-то становится нельзя ставить;

[yrashk]

Примеры «иногда»?

[erlyvideo]

case Frame#video_frame.codec of
h264 -> handle_h264(Frame);
aac -> handle_aac(Frame);
pcma -> handle_pcma(Frame)
end


удаляем клоз на pcma и получаем синтаксическую ошибку. В итоге в изменениях будет видно удаление 2-х строк, а не одной. Хорошего мало.

[yrashk]

Но ведь это не про «почему-то», это же вполне ожидаемое поведение.

[erlyvideo]

Ожидаемое с точки зрения уже существующего парсера.
Тем не менее оно для меня очень нелогичное и неудобное.

[yrashk]

Меня лично это момент ничуть не утомляет. Однако можно попробовать нестандартное форматирование?

case Frame#video_frame.codec of
h264 -> handle_h264(Frame)
; aac -> handle_aac(Frame)
; pcma -> handle_pcma(Frame)
end


[el777]

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

[yrashk]

А племя мумба-юмба обходится даже без алфавита ;)

[el777]

Они, наверное, на брейн-факе программируют — там тоже алфавит не нужен :)

[yrashk]

мне кажется вообще, что эта проблема совсем не уникальная для erlang. switch/case statement не утомляет в C? или в сложных or/and конструкциях в условиях в любом языке нас же не удивляет что последний or или and оператор надо тоже удалить?

По поводу последнего, представим такой код:

if ( (flag & TCP_NOKIDDING) ||
zlag < Z_LAG_THR ) {
...
}


предположим, последнее условее более не надо

if (flag & TCP_NOKIDDING) {
..
}


сколько строчек поменяется в гите? правильно, тоже две.

[erlyvideo]

switch(frame->codec) {
case H264: handle_h264(frame); break;
case AAC: handle_aac(frame); break;
case PCMA: handle_pcma(frame); break;
}


Так человечнее

[yrashk]

по сути ответа на пример с if'ом не было ;)

[yrashk]

а человечнее имхо было бы сделать

handle_frame(Frame),
..
handle_frame(#video_frame{ codec = h264 } = Frame) ->
...
ну и так далее по тексту


[erlyvideo]

И схлопотать ровно те же проблемы с.; которые вполне можно решить по-другому на уровне парсера.

[yrashk]

предложения как решить это на уровне парсера?

[erlyvideo]

Очевидно при смене заголовка функции понимать, что клозы функции закончились. Тогда вместо точно можно будет обойтись;

[yrashk]

А что если это была ошибка?

handle_frame(..) ->
...;
handke_frame(..) ->
...


В данный момент об ошибке сразу станет известно на этапе компиляции. В случае «умного парсера» — в лучшем случае на этапе тестов. В худшем — в продакшне когда function_clause вывалится в лог.

[el777]

if ( (flag & TCP_NOKIDDING) ||
zlag < Z_LAG_THR ) {
...
}

Если бы у меня был километровый if, то его проще переписать так:
if (
(flag & TCP_NOKIDDING)
|| zlag < Z_LAG_THR
) {
...
}

Чтобы в логе гита изменялись не все строки, а только строки, содержащие условие — то есть там где реально было изменение смысла.

[yrashk]

case Frame#video_frame.codec of
h264 -> handle_h264(Frame)
; aac -> handle_aac(Frame)
; pcma -> handle_pcma(Frame)
end


[el777]

Как вы поняли сами, это не решение, это просто перемещение проблемы с последней строки в первую :)

Точно так же как раньше я не мог спокойно закомментировать последнюю строку, я сейчас не могу это сделать с первой.

[yrashk]

/me умывает руки.

[CheatEx]

И вам тоже ответил выше :)

[yrashk]

ferd.ca/on-erlang-s-syntax.html

[el777]

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

Идеальный терминатор строки — это его отсутствие.
Наоборот, если выражение продолжается, то надо его продлевать и этот случай обозначать особенным образом. Потому что лишь 0.1% выражений приходится переносить на другую строку, все остальные нормально помещаются. Поэтому удобнее писать 1 раз на 1000 строк "\" в конце, чем в каждой строке ставить ",;.".
Единсвтенно, если не использовать выделение блоков отсутпами, то можно использовать слово end

[yrashk]

да ну, а в языке Си и не знали что нельзя делать сепаратор ";"

[Suor]

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

[poimtsev]

радует, что основной коммитер — Jose Valim :)