Думаем в этом направлении. В каком-то виде обязательно будем делать. Но мы не собираемся конкурировать с традиционными текстовыми IM-клиентами. Наша особенность — именно рисование и это останется главным. А текстовое общение будет — как дополнительная особенность.
По всем правилам OTP мы не делали. Замена версии у нас выполняется пока полной перезагрузкой узла. Но вы напомнили про эту очень хорошую возможность OTP. Обязательно напишу в следующей статье.
Вы про перевод этого термина на русский! Не сразу понял :) Вообще на русском по моему книг про Эрланг еще нет, поэтому все читал на английском. А так вы правы: «узел» — по русски более правильное понятие.
Эрланг — это функциональный язык, но насколько уж строго функциональный не скажу. Я больше практик, чем теоретик. Насколько я знаю, Эрланг писали для практического применения, поэтому синтаксис языка сильно упрощен по сравнению с тем же Lisp и в нем допускаются отклонения от чистой функциональной парадигмы для упрощения написания программ.
Что качается переменных, они все же называются в Эрланге переменными. Можно объявлять новые в функции. Но ничто не мешает в общем-то писать все на вызовах функций и передаче им параметров. Мне больше нравиться использовать переменные, там где это удобно, так как я все же пришел из мира традиционных языков программирования и не использую строго-функциональную стиль программирования :)
Заметьте, использование неизменяемых переменных внутри функции нисколько не мешает распараллеливанию и так же отсутствуют побочные эффекты у функции.
Да, согласен пример со spawn можно было сделать попроще. Но чтобы процесс жил долго можно просто в нем написать receive something -> ok end. и он будет вечно ждать получения сообщения для него :) То есть рекурсия не обязательна.
В статье я как раз привожу конкретные цифры по объему занимаемой памяти и скорость работы процессов. По своему опыту могу точно сказать, что памяти эрланг потребляет мало, тут проблем с ним не будет, но по скорости работы конечно проигрывает и С и часто Java, особенно в интенсивных вычислениях. Но всегда можно написать такой кусок кода на C и просто вызывать его из Эрланга о чем я напишу в следующей статье.
Про Амазон замечания учту: напишу и организационную сторону. Про клиент серверное взаимодействие тоже планирую писать в следующих статьях. С примерами насколько позволит размер статьи.
А с UTF в Эрланге пока глухо, бибилиотеки для нормальной работы с ними написанной на самом же Эрланге я не нашел. Мы лично используем Starling — но он использует библиотеки на C. Нам нужно было преобразование в Upper Case. Конечно просто чтение UTF-строк в эрланге есть, но вот работы с полученными данными потом отсутствует.
Пока я пас по этой теме. Нет опыта написания серверов на нескольких языках. Пока я пишу сервер только на Эрланге. Но как будущую тему для статьи буду иметь ввиду :)
Я бы сказал очень легко. Я сравниваю со скоростью разработки клиента на C++ и Qt и сервера. Так вот в сервер я вношу изменения раза в 3-5 быстрее, чем в клиента. Я сам сначала удивлялся. Одна из причин: код на Эрланге получается очень компактным по сравнению с C++ изменения обычно вносятся в одном месте, а не в двух-трех местах, как в C++ (я имею ввиду небольшие изменения). Плюс отсутствие строгой типизации переменных часто приводит к тому, что код сервера даже менять не надо, при небольших изменениях на клиенте или в данных обмена между клиентом и сервером.
Сейчас добавление новой функциональности на сервере, например новой команды в API сервера обычно занимает не больше одного дня.
Придерживаюсь терминологии Эрланга: там они называются нодами. К тому же в эрланге есть ряд комад, например: nodes(). — выдать список нод, с которыми связана данная нода. В общем, чтобы не запутаться самому, лучше называть их нодами. Я уже к этому вполне привык :)
Все же в документации Эрланга и в книге Армстронга они называются переменными, которые могут находится в двух состояниях: связанным и не связанным. Да ходя бы в самом шеле эрланга напиши «A.» и нажми Enter, сообщение об ошибке будет такое: «1: variable 'A' is unbound».
Но с другой стороны по моему спор чисто о терминологии, называть их переменными или промежуточными именованными данными. Я предпочитаю все же называть их переменными :)
P.S. Примеры в твоем комментарии все конечно правильные.
Да, буду писать про OTP в следующей статье. А вот про пример портирования несложного приложения с другого языка, пока ничего написать не смогу, так как пока у меня такого опыта нет. Мы свою систему писали с нуля сразу на Эрланге.
Если Erlang и использует системные трэды, то это происходит глубоко внутри виртуальной машины и самих программ на Эрланге не касается, то есть эрланговский код от этого никак не меняется сколько бы ядер не было в процессоре. К сожалению про внутреннее устройство виртуальной машины я имею только поверхностное представление.
Удачи вам в создании своей VM!
Хорошо, я постараюсь написать более подробно про это в следующей статье. Пока можешь почитать по приведенной ссылке документацию Эрланга, там достаточно понятно все написано.
Смотря какой заказчик. Если это дизайнерское бюро, то вполне можно порисовать с будущим работником в рисоваське при приеме на работу или посмотреть, как рисует фрилансер. Наши знакомые именно так и хотят ее использовать :)
Все же Рисоваська в данный момент не является заменой традиционных IM: ICQ, Jabber, Skype. Но мы планируем интеграцию, в первую очередь с Jabber.
Что качается переменных, они все же называются в Эрланге переменными. Можно объявлять новые в функции. Но ничто не мешает в общем-то писать все на вызовах функций и передаче им параметров. Мне больше нравиться использовать переменные, там где это удобно, так как я все же пришел из мира традиционных языков программирования и не использую строго-функциональную стиль программирования :)
Заметьте, использование неизменяемых переменных внутри функции нисколько не мешает распараллеливанию и так же отсутствуют побочные эффекты у функции.
Да, согласен пример со spawn можно было сделать попроще. Но чтобы процесс жил долго можно просто в нем написать receive something -> ok end. и он будет вечно ждать получения сообщения для него :) То есть рекурсия не обязательна.
В статье я как раз привожу конкретные цифры по объему занимаемой памяти и скорость работы процессов. По своему опыту могу точно сказать, что памяти эрланг потребляет мало, тут проблем с ним не будет, но по скорости работы конечно проигрывает и С и часто Java, особенно в интенсивных вычислениях. Но всегда можно написать такой кусок кода на C и просто вызывать его из Эрланга о чем я напишу в следующей статье.
Про Амазон замечания учту: напишу и организационную сторону. Про клиент серверное взаимодействие тоже планирую писать в следующих статьях. С примерами насколько позволит размер статьи.
А с UTF в Эрланге пока глухо, бибилиотеки для нормальной работы с ними написанной на самом же Эрланге я не нашел. Мы лично используем Starling — но он использует библиотеки на C. Нам нужно было преобразование в Upper Case. Конечно просто чтение UTF-строк в эрланге есть, но вот работы с полученными данными потом отсутствует.
Сейчас добавление новой функциональности на сервере, например новой команды в API сервера обычно занимает не больше одного дня.
Но с другой стороны по моему спор чисто о терминологии, называть их переменными или промежуточными именованными данными. Я предпочитаю все же называть их переменными :)
P.S. Примеры в твоем комментарии все конечно правильные.
Удачи вам в создании своей VM!
Все же Рисоваська в данный момент не является заменой традиционных IM: ICQ, Jabber, Skype. Но мы планируем интеграцию, в первую очередь с Jabber.