Это копия, сохраненная 22 октября 2017 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.

В отличие от того же хаскелла, erlang создавался не для бесконечного аутирования над кучей абстракций (и мастурбацией на свою охуительность), которые надо было каким-то образом повязать друг с другом, а для решения прикладных задач – в первые годы его существования такие нужды определила сфера телекома.
Шапка треда: http://telegra.ph/Erlang-thread-09-26
Как влиться в разработку?
1) установить erlang из пакетного менеджера / собрать самому
2) Learn Some Erlang For Great Good [http://learnyousomeerlang.com] + Erlang and OTP In Action
Я советую для разработки использовать Intellij Idea IDE + erlang plugin, а в качестве простенького менеджера проектов rebar3, чтобы попервой не трахаться с написанием правильных Makefile.
еще есть связка из emacs + distel, но в свете последних версий erlang/OTP пакет distel оказался сломан и на последних версиях erlang не работает (ждем фикс).
В последние годы еще пробился к популярности язык, построенный поверх BEAM, который можно окрестить как "erlang для ленивых" – Elixir. по сути – erlang с ruby синтаксисом. на самом деле, можно начать с него погружение в erlang-среду, потому что всё вышеописанное действительно и для Elixir, но у него намного проще абстракции, да и комьюнити у него, как ни странно, более активное. но я бы не советовал, честно, на нем зацикливаться, потому что Elixir много вещей пересоздает заново, что не очень разумно + чтобы хорошо писать на elixir нужно все же хорошо познать erlang/OTP.
Ну если честно, из твоего описания и следует что он для промышленных нужд подходит. Промышленность - один из крупнейших потребителей услуг ИТ, как-никак.
Наблюдая определённое число адептов этого замечательного языка, зачинаем первый ОФФИЦИАЛЬНЫЙ ЭРЛАНГОТРЕД!
Приглашаются также интересующиеся Elixir и прочие причастные.
Erlang - один из немногих функциональных языков, разработанный специально для применения в реальном мире.
OTP - платформа, содержащая огромное количество библиотек для построения приложений на Erlang, рассматривают с языком как единое целое.
Изначально ориентированный на высоконагруженные распределённые отказоустойчивые системы, тем не менее имеет более широкую сферу применения.
Среди самых популярных приложений, написанных на Erlang стоит упомянуть RabbitMQ, Riak, CouchDB, Wings3D, WhatsApp, Chef
Язык поддерживает все основные концепции функционального программирования, но при этом не перегружен академичностью, писать на нём легко и приятно.
Кажущийся с первого взгляда перегруженным синтаксис очень быстро становится привычным и интуитивно понятным.
Elixir - язык созданный для виртуальной машины Erlang, соответственно имеет те же самые преимущества. При этом имеет более привычный синтаксис в духе Ruby/Python, а также унаследовал от Lisp-семейства мощную систему макросов.
1. С чего начать?
http://www.tryerlang.org/
https://github.com/patrickgombert/erlang-koans
2. Что читать?
Joe Armstrong "Programming Erlang"
Fred Hebert "Learn You Some Erlang for great good!"
+книги из шапки ньюфаготреда
3. В чём писать?
Emacs + erlang-mode
Vim + https://github.com/vim-erlang
Sublime Text
Intellij Idea + Erlang плагин
Наблюдая определённое число адептов этого замечательного языка, зачинаем первый ОФФИЦИАЛЬНЫЙ ЭРЛАНГОТРЕД!
Приглашаются также интересующиеся Elixir и прочие причастные.
Erlang - один из немногих функциональных языков, разработанный специально для применения в реальном мире.
OTP - платформа, содержащая огромное количество библиотек для построения приложений на Erlang, рассматривают с языком как единое целое.
Изначально ориентированный на высоконагруженные распределённые отказоустойчивые системы, тем не менее имеет более широкую сферу применения.
Среди самых популярных приложений, написанных на Erlang стоит упомянуть RabbitMQ, Riak, CouchDB, Wings3D, WhatsApp, Chef
Язык поддерживает все основные концепции функционального программирования, но при этом не перегружен академичностью, писать на нём легко и приятно.
Кажущийся с первого взгляда перегруженным синтаксис очень быстро становится привычным и интуитивно понятным.
Elixir - язык созданный для виртуальной машины Erlang, соответственно имеет те же самые преимущества. При этом имеет более привычный синтаксис в духе Ruby/Python, а также унаследовал от Lisp-семейства мощную систему макросов.
1. С чего начать?
http://www.tryerlang.org/
https://github.com/patrickgombert/erlang-koans
2. Что читать?
Joe Armstrong "Programming Erlang"
Fred Hebert "Learn You Some Erlang for great good!"
+книги из шапки ньюфаготреда
3. В чём писать?
Emacs + erlang-mode
Vim + https://github.com/vim-erlang
Sublime Text
Intellij Idea + Erlang плагин
Если есть базовые представления о языках с С синтаксисом то думаю да. Я и создал тред затем, чтобы внести свою лепту в популяризацию языка, чтобы скрипткиддис и ноде.жс брейнлеты познали настоящую силу HPC.
Daje lisperi sumeli ves svoj zoopark sobrat' v odnom tredi, a otp-pidori zasirajut vsju dosku svoimi telebeiskami.
sagi
Создавать треды широкой направленности имо не очень продуктивно, потому что разговор будет идти обо всем, и не о чем одновременно. Если бы делал тред про OTP-like, то делал бы его максимально оторванным от языка и больше о теории.
Предположим, что у нас есть некий язык с зависимыми типами.
Довольно легко написать три функции: isSorted : Array a -> Bool, sort : Array a -> Array a, makeSorted : Array a -> Maybe ({isSorted} Array a)
С первыми двумя все очевидно, а третья выглядит как-нибудь так:
makeSorted a = case sort a of
__a | isSorted a -> Just ({isSorted} a)
__a -> Nothing
В Идрисе примерно такая реализация возможна. Но эта реализация вынуждает каждый раз обмазываться проверками на Nothing, что неудобно.
Как бы сделать удобную функцию sort : Array a -> {isSorted} Array a?
Тогда я смогу возвращать Either ({isNotSorted} Array) ({isSorted} Array). Но мне-то нужен сортированный массив без обёрток.
> вынуждает каждый раз обмазываться проверками на Nothing
https://en.wikibooks.org/wiki/Haskell/Understanding_monads
Моноид, аппликативный функтор, или монада (в зависимсоти от задачи) тебе в помощь. Они искаропки обмазаны проверками на Nothing.
Ну я конечно подразумевал фп контекст. Надеялся тут есть люди, знающие, что статические типы не только в джавах.

Кстати добавьте в шапку борду по эрлангу(и не только) написанную на эрланге.
Довольно популярный миф, но не буду разводить холивар, предположим что она равна, просто разные компромиссы.
Haskell концептуально - это то же джава. Просто в джаве кроме убогого сабтайпига и прикрученных сбоку дженеиков других выразительных средств - нет, отсюда все AbstractSingletonProxyFactoryBean и прочие достижение индусов в области набора текста латиницей. Haskell в этом плане конечно намного более продвинутый, но подход к написанию программ тот же самый. Поэтому не удивительно что существуют языки типа Scala, это просто вся суть всей этой ебалы.

>Изначально вбрасывает гиперхоливарную и всех давно заебавшую тему статика vs динамика
> не буду разводить холивар
>предположим что она равна
А вот нихуя мы не будет это предполагать.
Она совершенно не равна. Пока ты там на своей статике будешь по две недели изобретать очередной йобаморфизм и доказывать тайпчекеру что ты не верблюд, динамикобог всё сделает за денёк и перейдёт следующей таске. Ну и пердолинг с типами ради ко-ко-ко-ректности на самом деле ради самих же типов, вместо нормальной культурны тестов - это достаточно замедлительно. Особенно если учесть, что проверки типов IRL не достаточно и баги могут быть из-за логических ошибок, из-за ошибок проектирования, просто по невнимательности (без нарушения типов) и т.д.
Только не стоит забывать, что в какой-то момент динамикобогу приходится задумываться: как переделать часть своей системы, ничего не сломав? Если динамикобог сделал все правильно, ему придется всего-то навсего добавить кучу тестов и аккуратно переписать нужный участок, если нет — выбросить половину кода и создать почти с нуля.
Статикомакаке же сначала тяжело, зато потом можно хуяк-хуяк рефакторинг.
Что в длительной перспективе быстрее — я не знаю. Какие-то ненаучные исследования показывали, что Smalltalk круче всех, но это не подтверждается успешным коммерческим применением.
>как переделать часть своей системы, ничего не сломав?
Тесты. В эрланге вон аж два фреймворка из коробки под это.
Btw, можно подумать, если у тебя на статике типы сошлись, то значит, что программа после обновления будет работать как ожидается.
>ему придется всего-то навсего добавить кучу тестов
Нет, потому что тесты уже должны быть там.
>если нет — выбросить половину кода и создать почти с нуля.
Ну зачем так преувеличивать? Всего-то взять отладчик, локализовать баг и пофиксить. Благо иммутабельность, изоляция, отсутствие явного глобал стейта и прочие фишки ФП этому помогают. А в хаскелях, и прочих ленвых языках отладка - это задача со звёздочкой, да.
>зато потом можно хуяк-хуяк рефакторинг.
Зато потом у тебя всё в лифтингах, стеках трансформеров и т.д. Сложность программы на статике вообще растёт экспоненциально по ходу добавления новых фич.
>что Smalltalk круче всех
Ну смолток для того времени действительно был лучше всех, но это касалось формошлёпства в основном, да и аналогов нормальных не было.
Зря о эликсир не написал ничего в шапке. Младший брат оче даже годен.
Давай пиши-переписывай тесты на всю ту хуйню, которую у нормальных языков тайп-чекер отлавливает сам.
Статикодауны могут заниматься аутотреннингом где-нибудь в другом месте, например, в джява-треде.
>доказывать тайпчекеру что ты не верблюд
Тайпчекер всего лишь отлавливает ошибки, с которыми языке с динамической типизацией ты бы столкнулся в рантайме.
>добавить кучу тестов
Тестирование не доказывает корректность. Совсем.
Т.о., тестирование - карго-культ. Целиком.
Вобщем-то, достаточно, чтобы типизация была сильной. А статическая/динамическая - исключительно вкусовщина.
>Статикомакаке же сначала тяжело, зато потом можно хуяк-хуяк рефакторинг.
Non-exhaustive, который может вылезти после изменения типа, появится только в ран-тайме.
В Хаскеле, например.
Напомни, зачем нужна была абстрактная фабрика в явапараше? Про абстракцию для порождения семейства объектов можешь не рассказывать, скажи, зачем именно интерфейс нужен был?
Ты опять на свою джаву? Здесь эстетику ML семейства собрались обсуждать, а не фасолевые фабрики.

>эстетику ML семейства

>эстетику ML семейства

>эстетику ML семейства
Это верблюжье говно что ли?
А при чём тут какой язык? Статика есть статика - вынуждает жрать говно большой ложкой. Вроде программу пишешь, а и думаешь о каких-то типах, вообще охуеть.
Как раз наоборот. Ты выписываешь правила, перекладываешь максимум работы на IDE. Автоматизируешь по максимуму, вместо того чтобы держать в голове. Снижаешь когнитивную нагрузку.
прототип всеже, это что бы быстро, меньше time to market. зачем тратить время на устойчивость? ничего другого в erlang нет, не?
если для работы, то это нужно изучать на работе, иначе не окупятся неделимые расходы. был тут анон. я немного по работе использовал, но все забыл.
С лиспа и хаскеля.
Ну это ты так считаешь. А с моей точки зрения - типы всегда только усложняют программу. Всё типодрочерство заканчивается тем, что у тебя весь код либо в абстрактных одиноких заводах фасолин, либо весь в лифтингах, и всё заврапанное-переврапанное, так что читать это без крови из глаз невозможно. Ну и конечно же весь проект будет горизонтально размазан на 100500 файлов по 30 строчек ничего не делающего кода, так что без IDE действительно ёбнуться можно будет, но и с ним не намного лучше. А всё потому что типодрочеры строят предметную область, вместо того чтобы программировать то, что программа должна делать.
>Снижаешь когнитивную нагрузку.
Вот как раз когда у тебя всё плоское: только функции и простейшие типы, - тогда конгнитивная нагрузка минимальна, потому что такой код можно читать как книжку, причём в любом порядке, снизу вверх, сверху вниз, из любой части проекта, и это может делать любой человек с улицы. А вот типодрочерские проекты нужно учить(!), потому что там ебанутая иерархия абстракций и невозможно новичку объяснить что делает какая-то хуитка, не открыв 30 файлов в уютненькой идеешечке.
И не нужно рассказывать про хаскели и т.д. Я уже говорил, хаскелисты - это те же джаваиндусы с ворохом UML диаграмм за пазухой, только новые баззворды выучили и очки нацепили.
>когда у тебя всё плоское: только функции и простейшие типы, - тогда
любая хоть сколько-то сложная программа превращается в процедурную лапшу, а сложность и объем проекта начинают расти экспоненциально с добавлением новых фич.
Она не превратится в процедурную лапшу, если будешь следовать простым правилам, известным ещё со времён структурного и модульного программирования которые переоткрываются сегодня как некое откровение.
> а сложность и объем проекта начинают расти экспоненциально с добавлением новых фич.
Сложность проекта - это сложность чтения кода в нём. Если всё плоское и пишется снизу-вверх, то сложность будет расти линейно, экспоненциально она растёт у типодрочеров , которые у мамы дохуя систематизаторы и обобщаторы, т.е. любителей создавать форму без содержания.
>Она не превратится в процедурную лапшу, если будешь следовать простым правилам, известным ещё со времён структурного и модульного программирования которые переоткрываются сегодня как некое откровение.
>
Удачного внесения изменений в процедуры
С другой стороны, если проебаться с абстракциями, хрен редьки не слаще
>типодрочеры строят предметную область, вместо того чтобы программировать то, что программа должна делать.
Не аргумент, любой программист строит предметную область. Только кто-то делает это неосознанно и у него получаются текущие абстракции, а кто-то сознательно и у него получается красивый DSL.
В эрланге и эликсире нет процедур. Для повторого использования кода, функционала используй модули.
>ВАЖНО
Зачем это сейчас??? Есть же Golang который тоже шибко мощный по многопоточности и io, но только не функции не функциональный, зато вакансий поболее
Тот факт, что ты игнорируешь результат вычисления функции, еще не делает функцию процедуркой.
В Эрланге функция всегда что-то возвращает, как и в других функциональных языках. Функции в Эрланге это не процедуры, вроде в книге Джо Армстронга это написано. Процедура это понятие из императивного программирования, и к функциям в ФП не имеет отношения.
В ФП нет функций.
В текущей реализации она возвращает сообщение, переданное ПИДу. Можешь сматчить вызов функции с переменной и убедиться в этом.
Аноны, я вот знаю var при создании объектов во имя стабильности кода, тобишь var pidor = new dvacher;
Это же не зашквар, верно?
мимошарпомакак
Блядь, во имя читабельности. Ебаная автоподстановка.
> тобишь var pidor = new dvacher
Вывод типов — это же топ фича. В нормальных языках используется по максимуму, в императивном C# особо не повыводишь, но хоть вар есть
Elsi "funcia" vsegda vozvrashaet null (ili kakoj nibudj ok) i nihuya ne delaet krome side-effecta - eto toze functia u tebya?
To est' esli ya vozmy luboe imperativnoe govno i zatavlu vse proceduri vozvrashat' "ti hui" on stanet FP ot etogo?
I nahuj ono nado, ia chto ne zhau chto ia posialaju processu? Ono vse ravno vse vremya vozvrashaet etu hujnyou daze esli process sdoh davno. S takim ze uspeshom mozno vozvrashatj null. Ili eto takoj hitrii sposob implementacii I-kobminatora? Pravda nahuj on nuzen esli net karringa po umolchaniju...
>I-kobminatora
В глаза долбишься? Функция двухарная, никак id не получается. А в результате - даже не декартово произведение входных данных.
Ты там с GPD WIN что ли капчуешь?
Там имеется ввиду процедура как некий процесс, абстрактно, но не как в императивных языках процедура это кусочек кода. Функция здесь полноценный объект, она не отличима от данных.
Где ты тут канцелятор углядел, дебич?
А вот хуй, функция в примере (Pid1, Message) -> {Pid2, Message}, что нихуя не комбинатор, т.к. Pid2 получен побочным эффектом.
Ты ебанутый? Это Erlang, а не Clean или Haskell, алё. Функция "!" не возвращает {Pid2, Message}, она возвращает Message и всё.
Sends the value of Expr2 as a message to the process specified by Expr1. The value of Expr2 is also the return value of the expression.
http://erlang.org/doc/reference_manual/expressions.html#send
Так изначально базар как раз о том, что это не функция нихуя на самом деле, а процедурка, а возвращаемое значение зделоли чисто чтоб отмазаться, мол раз что-то возвращает - то не процедура, хотя толку от этого значения всё равно нет, оно заранее известно всегда и никогда не используется (что-то матчить по нему нет смысла, потому что "!" всегда возвращает Message, даже если процесс сдох, в крайнем случае бросает bad argument exception, но это и не значение).
Про комбинатор это типа шутка юмора была, а ты споришь на серьёзных щах, пиздец, take it easy.
В глаза ебешься?
1> T = self() ! {self(), 'ti hui'}.
{<0.61.0>,'ti hui'}
2> T.
{<0.61.0>,'ti hui'}
>потому что "!"
При чем здесь "!"? Мы обсуждаем функцию procedurka, пользователь которой может использовать возвращаемое значение для своих целей.
>Про комбинатор это типа шутка юмора была
Обосрался, притворись троллем.
>>1072252
Бля, я снова говорю с ботом, который не может в контекст. Мы, начиная с вот этого поста >>1071079 , говорим про "!", нужно быть дауном или ботом, чтоб этого не понять.
>Обосрался, притворись троллем.
Бот неумело маскирует своё неумение в шутеечки шаблонными фразами, однако применяет их ни к месту, забавно. Никто не говорил про тралинг, хуёвый бот, тупой.
Ваще не понял, к чему ты это
Мань, ты уже столько раз обосрался, что лень объяснять. Контекст, блять, у него поменялся.
гранит
Да, довен ты одноклеточный, контекст, то во что ты не можешь.
Контекст обсуждения был задан, когда какой-то отсталый или зелёный спизданул итт, что в эрланге нет процедур. Дальнейшая цепочка сообщений шла о том что они есть, и только бот или аутист не смог бы догнать, что общее во всех примерах это "!" и изменение стейта процесса. Не какая-то конкретная кастомная функция, а то что именно она делает. Дальнейшее обсуждение шло о "!" и о том, что оно a -> b -> b прям как KI. Просто ты жопочтец, который не может следовать простой цепочке обсуждения, поэтому доебался до чего-то вообще не по теме, и тупишь пол треда. Так что хуй соси, быдляк. И не пиши сюда больше.
Как что-то плохое.
>типодрочерство
Вся ж суть не у типах, а в доказах теорем для перевірки коректності створюваних тобою програм.
Ну он не работает. Плюс в инженерных буднях нужна интроспекция, в которую статикоговна не могут нормально.
>>1073474
> доказах теорем
Но в хаскеле нет пруфов.
Ты выбери, что ты собрался делать, теоремки доказывать (тогда Cock в зубы и вперёд, при чём тут разработка) или софт писать. Только не рассказывай про Карри-Говарда, точность до изоморфизма в математике может ок, инженерии - слишком расплывчато. Пока что из пруфов эффективные программы генерить не научились, и пруфы из программ толком тоже. Типы же спасут тебя от перепутанных значений полей "референс" и "назначение платежа" только если ты сделаешь под них два отдельных типа и такая хуйня будет по всей программе. А потом с этим ещё жить и поддерживать.

Тоже Actor-Based , только OOP + Shared Memory + Capability-based + Type Safe (мат. доказательство прилагается). Кто-то его пробовал?
https://www.ponylang.org/discover/
>в хаскеле нет пруфов
декларации типов - это и есть пруфы, уёба
штаны постирай свои и не позорься
Дурачек, он, очевидно, имел в виду что-то больше, чем lambda omega.
Что почитать про распределенную генерацию возрастающих последовательностей в п2п сетях? Что вообще почитать на тему самых типичных задач, методов их решений и подводных камней в распределенных системах?
Иди нахуй, дебил. И хватит придумывать оправдания своей никчемности.

>Может тут подскажете. Зачем в 2017+ году нужен язык с динамической типизацией?
Роберт Видринг говорил как-то на одной из конф: динамическая томущо хотелось горячей замены кода для работающего продакшена. Прикинули и решили что горячая замена неимоверно усложнится, если всё обмазать типами, придётся думать о том как решать конфликты типов уже в рантайме.
Кстати, интересная мысль. С этим связан вопрос: совместима ли горячая замена кода со статической типизацией? Может кто-то знает исследования по этому вопросу?
>Кстати, интересная мысль.
Сумасшедшая скорее.
>С этим связан вопрос: совместима ли горячая замена кода со статической типизацией?
Совместима.
А как достигается корректность, если при компиляции типизационные суждения вычёркиваются?
>А как достигается корректность, если при компиляции типизационные суждения вычёркиваются?
Я смутно себе представляю, что ты там себе представляешь.
Но.
Для динамической замены кода ненужно вычеркивать никаких типов.
Эти вещи не связанны от слова совсем никак.
А то что там в erlang-е какие-то проблемы на этой почве, так это его ерланга специфическая проблема.
Я не про ерланг. Я хочу понять, как вообще это можно или нельзя делать.
Например так. Написали первый фрагмент программы, компилятор проверил типы статически, стёр суждения типизации, оставшиеся термы скомпилировал. Затем мы запускаем этот фрагмент. Потом мы готовим второй фрагмент, дальше надо его скомпилировать. Вероятно, проверять типы в нём надо совместно с первым фрагментом (в общем случае). Это обеспечит корректность такой двухфрагментной программы для компилятора. Далее стирание типов и компиляция второго фрагмента. Теперь нужно загрузить готовый второй фрагмент к выполняемому первому. Но на этом этапе гарантий корректности желаемой двухфрагментной программы у загрузчика нет.
Либо, если не стирать типы (ни в первом ни во втором фрагменте), то проверку типов должен проводить загрузчик непосредственно перед загрузкой второго фрагмента. Я не владею этим вопросом. Это всё реалистично?
Кстати, а как первый фрагмент начинает выполнять код из второго? Нужно использовать метасредства языка? В полной ли мере корректность согласована с метаязыковыми средствами? Обязательно ли это, или есть другие варианты?
Какие по этому вопросу есть теоретические исследования?
Интерфейсы.
Классы\модули
Указатели на функцию\делегаты
Сообщения
У тебя есть интерфейс.
Его реализует модуль 2 и знает модуль 1
Модуль 1 общается с модулем 2 через этот интерфейс.
Меняй модуль 2 на все что угодно, лишь бы реализовывал интерфейс.
>Какие по этому вопросу есть теоретические исследования?
Если модуль 1 корректен, и модуль 2 корректен, и "модуль коммуникации" корректен, то и система в целом корректна.
>Интерфейсы.
>Классы\модули
>Указатели на функцию\делегаты
>Сообщения
Заебись, ну значит в джаве тоже есть хотлоадинг кода. Джава - ето таки лишп, слава Гослингу!
>Заебись, ну значит в джаве тоже есть хотлоадинг кода. Джава - ето таки лишп, слава Гослингу!
В ЯП такой вещи как хотлоадинг кода быть в принципе не может. По очевидным причинам.
Это может быть либо в среде выполнения, любо в твоей конкретной программе.
В jre вроде как такого функционала нет, но при желании можно его реализовать множеством разнообразных способов.
>знает модуль 1
То есть типы не вычёркивать? И какие-то проверки типов нужно производить при загрузке второго фрагмента? Тогда это будет динамическая типизация?
Кстати, а чем тогда отличается горячая замена в условиях динамической типизации от динамического связывания?
>Оставьте это математикам
Что ж поделать, если я, как бы, и есть.
>никакой швятой корректности
А что не так?
Раз ты математик, то пиши пейперы и создавай хаскел тред и аутируй там на гомотопии и прочее говно, это другая область. Мне платят за то что системы решают проблемы других людей. Системы должны разрабатываться быстро, быть производительными и там должно быть по минимуму багов. Все это решается культурой разработки и принятием определенных практик и моделей и парадигм. Еще эмпирически, да да, банально попробовать и если не сработало то попробовать еще раз, очень часто так и делается. Математика и типы не должны быть преобладающим вектором при разработке системы, если это не какая-то ебучая ракета которая доставляет жратву на МКС. Для построения систем, которые я разрабатываю (систем для которых эрланг и дизайнился) типы могут помочь только в определенных узких местах, например для консистентности данных. Но обмазывать типами всю систему это клиника.
Эрланг это не функциональный язык в том понимании, которое туда вкладывают шизики. Это простой пацанячий язык с иммутабельностью и асинхронным обменом сообщений, на этой хуйне можно делать нормальные распределенные отказоустойчивые системы и типы похую
>Математика и типы не должны быть преобладающим вектором при разработке системы
>Но обмазывать типами всю систему это клиника.
Говоришь только за себя? В меру своих способностей?
Давайте, не будем указывать друг другу,
кому что делать
Меня интересуют некоторые вопросы в ЯП, в т.ч. в динамических. Их и задаю.
>Говоришь только за себя? В меру своих способностей?
>НИАСИЛИЛИ
Говоришь так будто типы это что-то ниебаца сложное лол. Много систем написал?
Да без пизды, конечно задавай. Но я их буду просто игнорить. Создавай свой тред и там их задавай.
>И какие-то проверки типов нужно производить при загрузке второго фрагмента?
Второй фрагмент уже проверенный, вначале проверяется, вот ты код написал, потом его что-то там проверило, собрало в модуль, все.
Модуль проверенный и теперь он подгружается.
>Меняй модуль 2 на все что угодно, лишь бы реализовывал интерфейс.
А заменять второй модуль можно только в момент, когда закончено выполнение его кода?
Ты себе хоть немного работу компутера представляешь?
Сириусли, ознакомся челе.
С архитектурой ПК, и базовым курсом ассемблера.
Ибо вопросы не несут какого либо смысла.
>А заменять второй модуль можно только в момент, когда закончено выполнение его кода?
Разрешаю заменять когда угодно.
>работу компутера представляешь?
Представляю, конечно.
>Разрешаю заменять когда угодно.
Если исполнение некоторой процедуры P1 из модуля M2 не завершено, как же в этот момент можно его заменять на модуль M2'? Чревато сбоями?
Для джавы, да? Очень интересно. Не расскажешь, что за способы?

>Второй фрагмент уже проверенный, вначале проверяется, вот ты код написал, потом его что-то там проверило, собрало в модуль, все.
>Модуль проверенный и теперь он подгружается.
В Эрланге во время горячей загрузки существуют две версии кода: старая и новая. В момент когда модуль вызывает себя через полное имя my_module:my_function(). Происходит подмена старого кода новым.
Допустим что и в новом коде и в старом коде все типы проверены, ошибок нет. А как быть когда половина модулей уже переключились на новый код, а половина нет? Это ведь процесс не мгновенный, как удержать zero down time? Будет ведь неконсистентность, правильно?
Раз ты математик, то пиши пейперы и создавай гамалогии тред и аутируй там на гомотопии и прочее говно, это другая область. Мне платят за то что здания решают проблемы других людей. Здания должны разрабатываться быстро, быть надежными и там должно быть по минимуму щелей. Все это решается культурой разработки и принятием определенных практик и моделей и парадигм. Еще эмпирически, да да, банально попробовать и если не сработало то попробовать еще раз, очень часто так и делается. Математика и матан не должны быть преобладающим вектором при проектировке здания, если это не какая-то ебучая ракета которая доставляет жратву на МКС. Для построения зданий, которые я разрабатываю (зданий для которых автокад и дизайнился) матан может помочь только в определенных узких местах, например для консистентности данных. Но обсчитывать матаном все здание это клиника.
>Если исполнение некоторой процедуры P1 из модуля M2 не завершено, как же в этот момент можно его заменять на модуль M2'?
Наверное никак.
>Представляю, конечно.
>Чревато сбоями?
Еще раз повторюсь, удели время курсу ассемблера.
>А как быть когда половина модулей уже переключились на новый код, а половина нет?
И в чем проблема?
>Это ведь процесс не мгновенный
Не мгновенный.
>как удержать zero down time?
О чем конкретно ты говоришь? Что за zero down time?
>Будет ведь неконсистентность, правильно?
С чего бы это она будет когда у тебя все корректно?
>Будет ведь неконсистентность, правильно?
В момент замены кода в Эрланге виртуальная машина останавливается.

>В момент замены кода в Эрланге виртуальная машина останавливается.
ничего не останавливается, чё ты гонишь. Она может и минуту проработать в промежуточном состоянии, пока все процессы не перемигрируют на новый код.
Я говорил про неконсистентность статических проверок, типизации, если бы она была у Эрланга.
Ещё скажи, что она в момент сборки мусора останавливается.
Это копия, сохраненная 22 октября 2017 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.