Вышел Erlang/OTP R15B

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

Ша. Сидел пару дней назад изобретал do-notation в эрланге юзая parse-transform. Плакал от динамической типизации. Пришел к очевидному выводу что функциональный язык без статической типизации - убог.

ананим тут имеет ввиду, что нельзя понять в какой последовательности они попадут в очередь сообщений.

Аноним может это сделать на любом другом языке?

Этот релиз впервые поддерживает 64 битную версию Windows.

Какой-то недоязычок. Категорически не готов для серьезного использования в энтерпрайзе.

Категорически не готов для серьезного использования в энтерпрайзе.

Виндовс в энтерпрайзе не нужен. На нормальных платформах он давно 64.

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

Опиши типы в спеках и клепай свои haskell-костыли. Или тебе мама запретила указывать типы данных в эрланге?

Или тебе мама запретила указывать типы данных в эрланге?

Мне мама говорила что спеки эрланга - самый многословный способ описания типов.

Сигнатура функции:

format(Pattern, Datetime).

-spec format(Pattern, Datetime) -> string() when
    Pattern :: string(),
    Datetime :: calendar:datetime().

Доля виндовс-серверов в энтерпрайзе стремительно растет, а ты тут рассказываешь про какие-то «нормальные платформы». Назови хоть одну кроме RedHat?

Доля виндовс-серверов в энтерпрайзе стремительно растет

Я испытываю живейшее сочувствие ко всем этим людям.

Назови хоть одну кроме RedHat?

Я так понимаю энтерпрайзом ты называешь продукты которых в названии присутствует слово enterprise?

Ну да. Enterprise Linux - линукс для предприятий. Сразу понятно о чем речь.

Какой-то у erlang очень невнятный синтаксис, еще хуже чем у python. И непонятно, есть ли там поддержка объектного программирования.

Что не так? Хм. Как бы это выразить... Просто выдвигается тезис - erlang не является языком программирования общего назначения. А в качестве обоснования приводится пример хреновой технологии программирования (хранимые состояния, в том числе общая область памяти), от которой в erlang осознанно отказались в пользу другой технологии (сообщений). Когда читаешь такие «обоснования», становится понятно, кто есть ху..., а кто действительно осознает, что значит выражение «проектировать приложение».

Имхо, статью писал «плохой танцор» в мире программирования.

Ну да. Enterprise Linux - линукс для предприятий. Сразу понятно о чем речь.

лицоладонь.

Если вам нужны объекты, посмотрите в сторону Java. Там их полно. Можете еще на Smalltalk взглянуть (там другая модель ООП реализована).

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

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

Вам запудрили мозги. Серьезно.

В Erlang хреново решаются две задачи (может больше, но я пока только две знаю): числодробилки и работа с оборудованием. Попробуйте-ка, напишите простейший аудио-плеер, который умел бы воспроизводить wav'ки. Вы будете сильно удивлены.

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

Все узкие места принято обходить с помощью FFI (linked_in drivers), но это жуткий изврат и в реале я что-то не заметил сильного распространения этой технологии.

Какой-то у erlang очень невнятный синтаксис

Синтаксис просто непривычный, но изучается быстро.

Сидел пару дней назад изобретал do-notation в эрланге

Но зачем?

Если два потока отправили третьему сообщение то ты не можешь предсказать какое из них будет первым в очереди

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

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

Сие есть полное 4.2. ТАм их даже более одного способа.

Например эрланговский подход в модуле file сделан вообще замечательно. Жаль только там вреализации есть неконсистентности - причесать бы эту либу. Как пример реализации - файловый десткриптор имеет структуру: {module, data}, где модуль - указывает какой модуль обрабатывает данный тип дескрипторов. Сама библиотека осуществляе диспетчиризацию вызовов в зависимости от типа дескриптора. То есть сам код использует стандартное апи модуля file, а реализаций несклько в зависимости от того куда тычет собственно дескриптор. Я например сделал свою реализацию этого «интерфейса» который проекцирует посегментно файл в память на open. Сам модуль читающий из этого файла - знать не знает что это за херня - он читает из любой реализации api file.

В Erlang хреново решаются две задачи (может больше, но я пока только две знаю): числодробилки и работа с оборудованием

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

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

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

А на чем кросплаформенный плеер сварханить легко? Это вообще нерешаемая задача - для каждой платформы придется делать свою реализацию.

Но зачем?

Альтернатива - каскадные case или try ... catch (невнятный шит хеппенз вида no match непонятно где).

при трансформации она собственно и превращается в каскадный case.

Пока выглядит вот так:

   b4e_lang:do([ RemoteMD5 ||
        FtpListing <- b4e_ftp:nlist(Pid, "*.csv.MD5"),
        RemoteMD5File <- b4e_lang:to_left(b4e_list:first(FtpListing), remote_md5_not_found),
        RemoteMD5 <- ftp:recv_bin(Pid, RemoteMD5File)
    ])

Если два потока отправили третьему сообщение то ты не можешь предсказать какое из них будет первым в очереди

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

Это да. Но в питоне задачу как-то (тоже через FFI?) решили, а тут что-то глухо все. Я нашел возможность прикрутить библиотеку portaudio (vlc тоже через нее работает, например), но когда я осознал, сколько времени уйдет на написание linked_in драйвера, бросил затею.

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

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

На котором кто-то написал эту либу до тебя:)

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

в принципе необходимость lang:do и убедила мне что функциональный язык без статической типизации - не тру. Нету возможности отличить мой list comprehension который надо трансформироваьт от всех прочих без явного дискриминатора. В языке с СТ это бы распозналось на уровне типов - как это же самое сделано в скале - а тут фига с два.

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

Без объектов программировать можно лишь очень узкий класс задач.

Зайди, например, на hackage.

Какой-то у erlang очень невнятный синтаксис, еще хуже чем у python. И непонятно, есть ли там поддержка объектного программирования.

Походу троллинг, но «prolog» вам о чем-нибудь говорит?

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

Просто выдвигается тезис - erlang не является языком программирования общего назначения.

Хе-хе, так недалеко и до тьюринг полноты докатиться. Вопрос конечно же в удобстве, и удобство это субъективное.

от которой в erlang осознанно отказались в пользу другой технологии (сообщений)

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

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

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

Так-с... Посмотрим, что там у нас есть...

MODULE
ets

MODULE SUMMARY
Built-In Term Storage

DESCRIPTION
This module is an interface to the Erlang built-in term storage BIFs. These provide the ability to store very large quantities of data in an Erlang runtime system, and to have constant access time to the data. (In the case of ordered_set, see below, access time is proportional to the logarithm of the number of objects stored).

Пользуйтесь на здоровье :)

logarithm of the number of objects stored

день юмористов на ЛОРе. Как ты думаешь, сколько процессорных тактов займет у потока достать указатель на объект из очереди? Указатель в смысле С, естественно.

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

Настолько лютый что ты просто не понял что я сказал. Что - если нету слова class - то фантазия не работает?

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

В хаскеле такой же самый синтаксис с точностью до знаков препинания.

Хаскель:

f 5 = 5
f _ = 10

Эрланг:

f(5) -> 5;
f(_) -> 10

Нормальный удобный синтаксис.

казатель в смысле С, естественно.

В shared nothing - у тебя и есть «указатели в мысле C». Ничего никуда не копируется. По той простой причине что ты перепортить ничего не можешь.

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

Юмористы, такие юмористы. Некоторые задачи решаются на серверах не потому, что это круто, а потому, что для их решения нужны большие вычислительные мощности. Если у тебя именно такая задача, то тебе не стоит гоняться за каждой миллисекундой, а надо честно предупредить заказчика, что для решения задачи потребуется хороший мощный сервер (у кого-то даже кластер).

И, нет, я не призываю писать программы хрен знает на чем (например, на питоне) и левой пяткой. Просто надо не задрачиваться на скорости, а искать баланс между разными качествами ПО. Например,между скоростью и надежностью.

Я понял, что на каждую специализацию объекта файл надо писать отдельный модуль, наследовать в который из уже написанных нельзя. А почему нельзя обойтись функцией?

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

Я понял, что на каждую специализацию объекта файл

Фак. Уже одно это....

Если тебе надо функция дополнительная для работы с файлами - пиши эту функцию и все. А если тебе надо что-то что крякает как файл, плавает как файл, но файлом на доиске не является - ты пишешь свою функцию open которая возвращает стандартный дескриптор в котором упомянуто какой модуль умеет с этим работать. Это обычный чистейший ad-hoc полиморфизм - точно такой же как в ООП. Другой пример - это собственно ducktyping которй точно так же присутствуе в эрланге как в любом динамическом язые.

-module(x).
f() -> x.

- module(y).
f() -> y.

-module(z).
call_f(Module) -> Module:f().
.....

> z:call_f(x).
x

> z:call_f(y).
y

чистейший ad-hoc полиморфизм.

В двух словах это не объяснить. Проще говоря, все потоки вашей программы выполняются на одной виртуальной машине (на самом деле могут и не на одной, но это другая история) и память в этой машине вся общая. Это для потоков внутри машины она «разная».

А мне как раз и надо «перепортить», то есть отдать указатель на буфер уже обработанный одним потоком, следующему в цепочке.

Если тебе нужно портить буфер байтов - бери буфер байтов (binary в эрланге) - и порть. А указатели на строки чтобы их портить - это страшнейшая херня для многопоточных програм.

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

Но нужный функционал можно проделегировать, же.

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

Спроси у чуваков, которые написали апач или мускуль. Думаю, что немного, поскольку все либы для работы с потоками вполне надежны и давно отлажены.

это собственно ducktyping которй точно так же присутствуе в эрланге

Угу, только в стандартной библиотеке он как-то хреново представлен. Например коллекций, по факту, нет.

Думаю, что немного, поскольку все либы для работы с потоками вполне надежны и давно отлажены.

Ага шаз. Сравни за сколько времени написали апач и за сколько времени написали явс - который на «медленном» эрланге уделывает по производительности этот самый апач.

http://www.sics.se/~joe/apachevsyaws.html