Этого треда уже нет.
Это копия, сохраненная 22 октября 2017 года.

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
25 Кб, 500x445
Тред самого актуального (тм) языка в 2017 году # OP #1066582 В конец треда | Веб
Что такое Erlang? это первый функциональный язык общего назначения, разработанный, в первую очередь, для промышленных нужд.
В отличие от того же хаскелла, 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.
#2 #1066584
В Эрланге/Элексире полезна в основном только натуральная параллелизация и отказоустойчивость всего с этим связанного. Очень ситуационный язык/семейство языков, на мой взгляд.
# OP #3 #1066588
>>1066584
Ну если честно, из твоего описания и следует что он для промышленных нужд подходит. Промышленность - один из крупнейших потребителей услуг ИТ, как-никак.
#4 #1066589
На правах ОПа старых тредов, закину старую шапку:

Наблюдая определённое число адептов этого замечательного языка, зачинаем первый ОФФИЦИАЛЬНЫЙ ЭРЛАНГОТРЕД!

Приглашаются также интересующиеся 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 плагин
#4 #1066589
На правах ОПа старых тредов, закину старую шапку:

Наблюдая определённое число адептов этого замечательного языка, зачинаем первый ОФФИЦИАЛЬНЫЙ ЭРЛАНГОТРЕД!

Приглашаются также интересующиеся 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 плагин
#5 #1066594
Стоит изучать с нуля?
# OP #6 #1066615
>>1066594
Если есть базовые представления о языках с С синтаксисом то думаю да. Я и создал тред затем, чтобы внести свою лепту в популяризацию языка, чтобы скрипткиддис и ноде.жс брейнлеты познали настоящую силу HPC.
sage #7 #1066674
>>1066582 (OP)
Daje lisperi sumeli ves svoj zoopark sobrat' v odnom tredi, a otp-pidori zasirajut vsju dosku svoimi telebeiskami.
sagi
#8 #1066798
>>1066674
Создавать треды широкой направленности имо не очень продуктивно, потому что разговор будет идти обо всем, и не о чем одновременно. Если бы делал тред про OTP-like, то делал бы его максимально оторванным от языка и больше о теории.
#9 #1067024
Хачкель-тред утонул, так что ответьте вы мне: как написать функцию, доказывающую свойство возвращаемого результата?
Предположим, что у нас есть некий язык с зависимыми типами.
Довольно легко написать три функции: 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?
#10 #1067060
>>1067024
Очевидно, заведи {isNotSorted}
#11 #1067125
>>1067060
Тогда я смогу возвращать Either ({isNotSorted} Array) ({isSorted} Array). Но мне-то нужен сортированный массив без обёрток.
#12 #1067237
>>1067024

> вынуждает каждый раз обмазываться проверками на Nothing


https://en.wikibooks.org/wiki/Haskell/Understanding_monads
#13 #1067247
>>1067125
Моноид, аппликативный функтор, или монада (в зависимсоти от задачи) тебе в помощь. Они искаропки обмазаны проверками на Nothing.
#14 #1067298
Может тут подскажете. Зачем в 2017+ году нужен язык с динамической типизацией?
#15 #1067321
>>1067298
Чтобы не быть джавадолбоёбом?
#16 #1067332
>>1067321
Ну я конечно подразумевал фп контекст. Надеялся тут есть люди, знающие, что статические типы не только в джавах.
#17 #1067346
>>1067298
Скорость разработки?
5 Кб, 247x34
#18 #1067350
>>1066582 (OP)
Кстати добавьте в шапку борду по эрлангу(и не только) написанную на эрланге.
#19 #1067353
>>1067346
Довольно популярный миф, но не буду разводить холивар, предположим что она равна, просто разные компромиссы.
#20 #1067357
>>1067332
Haskell концептуально - это то же джава. Просто в джаве кроме убогого сабтайпига и прикрученных сбоку дженеиков других выразительных средств - нет, отсюда все AbstractSingletonProxyFactoryBean и прочие достижение индусов в области набора текста латиницей. Haskell в этом плане конечно намного более продвинутый, но подход к написанию программ тот же самый. Поэтому не удивительно что существуют языки типа Scala, это просто вся суть всей этой ебалы.
49 Кб, 400x392
#21 #1067358
>>1067353

>Изначально вбрасывает гиперхоливарную и всех давно заебавшую тему статика vs динамика


> не буду разводить холивар

#22 #1067363
>>1067353

>предположим что она равна


А вот нихуя мы не будет это предполагать.
Она совершенно не равна. Пока ты там на своей статике будешь по две недели изобретать очередной йобаморфизм и доказывать тайпчекеру что ты не верблюд, динамикобог всё сделает за денёк и перейдёт следующей таске. Ну и пердолинг с типами ради ко-ко-ко-ректности на самом деле ради самих же типов, вместо нормальной культурны тестов - это достаточно замедлительно. Особенно если учесть, что проверки типов IRL не достаточно и баги могут быть из-за логических ошибок, из-за ошибок проектирования, просто по невнимательности (без нарушения типов) и т.д.
#23 #1067367
>>1067363
Только не стоит забывать, что в какой-то момент динамикобогу приходится задумываться: как переделать часть своей системы, ничего не сломав? Если динамикобог сделал все правильно, ему придется всего-то навсего добавить кучу тестов и аккуратно переписать нужный участок, если нет — выбросить половину кода и создать почти с нуля.
Статикомакаке же сначала тяжело, зато потом можно хуяк-хуяк рефакторинг.
Что в длительной перспективе быстрее — я не знаю. Какие-то ненаучные исследования показывали, что Smalltalk круче всех, но это не подтверждается успешным коммерческим применением.
#24 #1067368
>>1067298
Что бы не ебать себе мозги на ровном месте, типа как здесь >>1067024 ?
#25 #1067372
>>1067367

>как переделать часть своей системы, ничего не сломав?


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

>ему придется всего-то навсего добавить кучу тестов


Нет, потому что тесты уже должны быть там.

>если нет — выбросить половину кода и создать почти с нуля.


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

>зато потом можно хуяк-хуяк рефакторинг.


Зато потом у тебя всё в лифтингах, стеках трансформеров и т.д. Сложность программы на статике вообще растёт экспоненциально по ходу добавления новых фич.

>что Smalltalk круче всех


Ну смолток для того времени действительно был лучше всех, но это касалось формошлёпства в основном, да и аналогов нормальных не было.
#26 #1067417
>>1066582 (OP)
Зря о эликсир не написал ничего в шапке. Младший брат оче даже годен.
#27 #1067442
>>1067346
Давай пиши-переписывай тесты на всю ту хуйню, которую у нормальных языков тайп-чекер отлавливает сам.
#28 #1067461
Это тред про Erlang.
Статикодауны могут заниматься аутотреннингом где-нибудь в другом месте, например, в джява-треде.
#29 #1067472
>>1067363

>доказывать тайпчекеру что ты не верблюд


Тайпчекер всего лишь отлавливает ошибки, с которыми языке с динамической типизацией ты бы столкнулся в рантайме.
#30 #1067519
>>1067367

>добавить кучу тестов


Тестирование не доказывает корректность. Совсем.
Т.о., тестирование - карго-культ. Целиком.
#31 #1067543
>>1067298
Вобщем-то, достаточно, чтобы типизация была сильной. А статическая/динамическая - исключительно вкусовщина.
#32 #1067544
>>1067367

>Статикомакаке же сначала тяжело, зато потом можно хуяк-хуяк рефакторинг.


Non-exhaustive, который может вылезти после изменения типа, появится только в ран-тайме.
#33 #1067545
>>1067298
Подожди, динамопараша все еще считается языками программирования?
#34 #1067578
>>1067544
В каком языке это так?

>>1067545
Вот и зашел спросить в тред "самого актуального", как так.
#35 #1067591
>>1067578
В Хаскеле, например.
#37 #1067666
>>1067621

>пук


)
#38 #1067836
>>1067472
Напомни, зачем нужна была абстрактная фабрика в явапараше? Про абстракцию для порождения семейства объектов можешь не рассказывать, скажи, зачем именно интерфейс нужен был?
#39 #1067882
>>1067836
Ты опять на свою джаву? Здесь эстетику ML семейства собрались обсуждать, а не фасолевые фабрики.
49 Кб, 375x525
#40 #1067895

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

110 Кб, 533x351
#41 #1067897

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

36 Кб, 604x403
#42 #1067899

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

#43 #1067902
>>1067882
Это верблюжье говно что ли?
#44 #1067909
>>1067882
А при чём тут какой язык? Статика есть статика - вынуждает жрать говно большой ложкой. Вроде программу пишешь, а и думаешь о каких-то типах, вообще охуеть.
#45 #1067919
>>1067909
Как раз наоборот. Ты выписываешь правила, перекладываешь максимум работы на IDE. Автоматизируешь по максимуму, вместо того чтобы держать в голове. Снижаешь когнитивную нагрузку.
#46 #1067922
если для прототипирования, то почему не запустить несколько процессов? если сравнить с rails, ну будет на пару серверов меньше, ну и что, это стоит потраченного времени?

прототип всеже, это что бы быстро, меньше time to market. зачем тратить время на устойчивость? ничего другого в erlang нет, не?

если для работы, то это нужно изучать на работе, иначе не окупятся неделимые расходы. был тут анон. я немного по работе использовал, но все забыл.
59 Кб, 568x943
#47 #1067981
С чего начинать изучения сабжа?
#48 #1068051
>>1067981
С лиспа и хаскеля.
#49 #1068360
>>1067919
Ну это ты так считаешь. А с моей точки зрения - типы всегда только усложняют программу. Всё типодрочерство заканчивается тем, что у тебя весь код либо в абстрактных одиноких заводах фасолин, либо весь в лифтингах, и всё заврапанное-переврапанное, так что читать это без крови из глаз невозможно. Ну и конечно же весь проект будет горизонтально размазан на 100500 файлов по 30 строчек ничего не делающего кода, так что без IDE действительно ёбнуться можно будет, но и с ним не намного лучше. А всё потому что типодрочеры строят предметную область, вместо того чтобы программировать то, что программа должна делать.

>Снижаешь когнитивную нагрузку.


Вот как раз когда у тебя всё плоское: только функции и простейшие типы, - тогда конгнитивная нагрузка минимальна, потому что такой код можно читать как книжку, причём в любом порядке, снизу вверх, сверху вниз, из любой части проекта, и это может делать любой человек с улицы. А вот типодрочерские проекты нужно учить(!), потому что там ебанутая иерархия абстракций и невозможно новичку объяснить что делает какая-то хуитка, не открыв 30 файлов в уютненькой идеешечке.
И не нужно рассказывать про хаскели и т.д. Я уже говорил, хаскелисты - это те же джаваиндусы с ворохом UML диаграмм за пазухой, только новые баззворды выучили и очки нацепили.
#51 #1068464
>>1068360

>когда у тебя всё плоское: только функции и простейшие типы, - тогда


любая хоть сколько-то сложная программа превращается в процедурную лапшу, а сложность и объем проекта начинают расти экспоненциально с добавлением новых фич.
#52 #1068603
>>1068464
Она не превратится в процедурную лапшу, если будешь следовать простым правилам, известным ещё со времён структурного и модульного программирования которые переоткрываются сегодня как некое откровение.

> а сложность и объем проекта начинают расти экспоненциально с добавлением новых фич.


Сложность проекта - это сложность чтения кода в нём. Если всё плоское и пишется снизу-вверх, то сложность будет расти линейно, экспоненциально она растёт у типодрочеров , которые у мамы дохуя систематизаторы и обобщаторы, т.е. любителей создавать форму без содержания.
#53 #1068669
>>1068603

>Она не превратится в процедурную лапшу, если будешь следовать простым правилам, известным ещё со времён структурного и модульного программирования которые переоткрываются сегодня как некое откровение.


>


Удачного внесения изменений в процедуры
#54 #1068670
>>1068669
С другой стороны, если проебаться с абстракциями, хрен редьки не слаще
#55 #1068807
>>1068360

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


Не аргумент, любой программист строит предметную область. Только кто-то делает это неосознанно и у него получаются текущие абстракции, а кто-то сознательно и у него получается красивый DSL.
#56 #1068822
>>1068360
>>1068464
>>1068603

>Процедуры


В Эрланге нет процедур. В ФП отсутствует понятие процедура. Ну вы и лохи. И эти люди учат нас жить?!
#57 #1070511
>>1068464
В эрланге и эликсире нет процедур. Для повторого использования кода, функционала используй модули.
#58 #1070567
>>1068822
>>1070511
Спасибо, кэп.
#60 #1070785

>ВАЖНО


Зачем это сейчас??? Есть же Golang который тоже шибко мощный по многопоточности и io, но только не функции не функциональный, зато вакансий поболее
#61 #1070793
>>1070625
Но ведь procedurka - это функция.
#62 #1070830
>>1070793
В чём разница между функцией и процедуркой знаешь?

А так: https://ideone.com/2lWrMv ?
#63 #1070843
>>1070830
Тот факт, что ты игнорируешь результат вычисления функции, еще не делает функцию процедуркой.
#64 #1070914
>>1070843
А тот факт что она ничего не возвращает тоже не делает?
#65 #1070986
>>1070914
В Эрланге функция всегда что-то возвращает, как и в других функциональных языках. Функции в Эрланге это не процедуры, вроде в книге Джо Армстронга это написано. Процедура это понятие из императивного программирования, и к функциям в ФП не имеет отношения.
#66 #1071008
>>1070986
В ФП нет функций.
#67 #1071016
>>1070914
В текущей реализации она возвращает сообщение, переданное ПИДу. Можешь сматчить вызов функции с переменной и убедиться в этом.
#68 #1071017
>>1070986
В СИКПе схемские лямбда абстракции авторы называют процедурами.
#69 #1071033
>>1067298
Аноны, я вот знаю var при создании объектов во имя стабильности кода, тобишь var pidor = new dvacher;
Это же не зашквар, верно?

мимошарпомакак
#70 #1071034
>>1071033
Блядь, во имя читабельности. Ебаная автоподстановка.
#71 #1071059

> тобишь var pidor = new dvacher



Вывод типов — это же топ фича. В нормальных языках используется по максимуму, в императивном C# особо не повыводишь, но хоть вар есть
#72 #1071072
>>1071059
Cho pizdish loh, v skalke pochti vezde vivoditsya.
#73 #1071073
>>1070986
Elsi "funcia" vsegda vozvrashaet null (ili kakoj nibudj ok) i nihuya ne delaet krome side-effecta - eto toze functia u tebya?
#74 #1071074
>>1070986
To est' esli ya vozmy luboe imperativnoe govno i zatavlu vse proceduri vozvrashat' "ti hui" on stanet FP ot etogo?
#75 #1071079
>>1071016
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...
#76 #1071095
>>1071079

>I-kobminatora


В глаза долбишься? Функция двухарная, никак id не получается. А в результате - даже не декартово произведение входных данных.
#77 #1071110
>>1071095
Da, typly, eto K-combinator (esli bi bil karring)
#78 #1071112
>>1071110
Почему ты пишешь как мудак? Не умеешь в слепой набор?
#79 #1071121
>>1071110
Blya, opyat' obasralsya, eto ne K, a KI.

>>1071112
V nabor mogy, no znaki prepinaniya tyt ne na meste, tak chto ebet.
#80 #1071181
>>1071121
Ты там с GPD WIN что ли капчуешь?
#81 #1071193
>>1071017
Там имеется ввиду процедура как некий процесс, абстрактно, но не как в императивных языках процедура это кусочек кода. Функция здесь полноценный объект, она не отличима от данных.
#82 #1071220
>>1067442

distil.
#83 #1071394
>>1071110
Где ты тут канцелятор углядел, дебич?
#84 #1071395
>>1071121

>Blya, opyat' obasralsya, eto ne K, a KI.


О снова обосрался.
#85 #1071715
>>1071395
Niet, ti.

KIab = b
KIab = (KIa)b = Ib = b
#86 #1072054
>>1071715
А вот хуй, функция в примере (Pid1, Message) -> {Pid2, Message}, что нихуя не комбинатор, т.к. Pid2 получен побочным эффектом.
#87 #1072240
>>1072054
Ты ебанутый? Это 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
#88 #1072248
>>1072054
Так изначально базар как раз о том, что это не функция нихуя на самом деле, а процедурка, а возвращаемое значение зделоли чисто чтоб отмазаться, мол раз что-то возвращает - то не процедура, хотя толку от этого значения всё равно нет, оно заранее известно всегда и никогда не используется (что-то матчить по нему нет смысла, потому что "!" всегда возвращает Message, даже если процесс сдох, в крайнем случае бросает bad argument exception, но это и не значение).
Про комбинатор это типа шутка юмора была, а ты споришь на серьёзных щах, пиздец, take it easy.
#89 #1072249
>>1072240
В глаза ебешься?
1> T = self() ! {self(), 'ti hui'}.
{<0.61.0>,'ti hui'}
2> T.
{<0.61.0>,'ti hui'}
#90 #1072252
>>1072248

>потому что "!"


При чем здесь "!"? Мы обсуждаем функцию procedurka, пользователь которой может использовать возвращаемое значение для своих целей.

>Про комбинатор это типа шутка юмора была


Обосрался, притворись троллем.
#91 #1072260
>>1072249
>>1072252
Бля, я снова говорю с ботом, который не может в контекст. Мы, начиная с вот этого поста >>1071079 , говорим про "!", нужно быть дауном или ботом, чтоб этого не понять.

>Обосрался, притворись троллем.


Бот неумело маскирует своё неумение в шутеечки шаблонными фразами, однако применяет их ни к месту, забавно. Никто не говорил про тралинг, хуёвый бот, тупой.
#92 #1072275
>>1071072
Ваще не понял, к чему ты это
#93 #1072688
Начал учить какие подводные?
#94 #1072764
>>1072260
Мань, ты уже столько раз обосрался, что лень объяснять. Контекст, блять, у него поменялся.
#95 #1072857
>>1072688
гранит
#96 #1073003
>>1072688
Как я уже начал, динамическая типизация
#97 #1073022
>>1072764
Да, довен ты одноклеточный, контекст, то во что ты не можешь.
Контекст обсуждения был задан, когда какой-то отсталый или зелёный спизданул итт, что в эрланге нет процедур. Дальнейшая цепочка сообщений шла о том что они есть, и только бот или аутист не смог бы догнать, что общее во всех примерах это "!" и изменение стейта процесса. Не какая-то конкретная кастомная функция, а то что именно она делает. Дальнейшее обсуждение шло о "!" и о том, что оно a -> b -> b прям как KI. Просто ты жопочтец, который не может следовать простой цепочке обсуждения, поэтому доебался до чего-то вообще не по теме, и тупишь пол треда. Так что хуй соси, быдляк. И не пиши сюда больше.
#98 #1073023
>>1073003
Как что-то плохое.
#99 #1073322
Самый ламповый треад!
#100 #1073469
Кому потрібен цей клятий Erlang, коли є Cloud Haskell.
#101 #1073471
>>1072249

>В глаза ебешься?


Я цнотливий.
#102 #1073474
>>1068360

>типодрочерство


Вся ж суть не у типах, а в доказах теорем для перевірки коректності створюваних тобою програм.
#103 #1074281
>>1073469
Ну он не работает. Плюс в инженерных буднях нужна интроспекция, в которую статикоговна не могут нормально.

>>1073474

> доказах теорем


Но в хаскеле нет пруфов.
Ты выбери, что ты собрался делать, теоремки доказывать (тогда Cock в зубы и вперёд, при чём тут разработка) или софт писать. Только не рассказывай про Карри-Говарда, точность до изоморфизма в математике может ок, инженерии - слишком расплывчато. Пока что из пруфов эффективные программы генерить не научились, и пруфы из программ толком тоже. Типы же спасут тебя от перепутанных значений полей "референс" и "назначение платежа" только если ты сделаешь под них два отдельных типа и такая хуйня будет по всей программе. А потом с этим ещё жить и поддерживать.
102 Кб, 1652x948
#104 #1074292
Вот есть Pony. Позиционируется как убийца Erlang.
Тоже Actor-Based , только OOP + Shared Memory + Capability-based + Type Safe (мат. доказательство прилагается). Кто-то его пробовал?
https://www.ponylang.org/discover/
#105 #1074357
>>1074281

>в хаскеле нет пруфов


декларации типов - это и есть пруфы, уёба
штаны постирай свои и не позорься
#106 #1074667
>>1074357
Дурачек, он, очевидно, имел в виду что-то больше, чем lambda omega.
#107 #1074684
Вот же тред, который мне нужен!

Что почитать про распределенную генерацию возрастающих последовательностей в п2п сетях? Что вообще почитать на тему самых типичных задач, методов их решений и подводных камней в распределенных системах?
#108 #1075250
>>1073022
Иди нахуй, дебил. И хватит придумывать оправдания своей никчемности.
#109 #1075252
>>1074357

>декларации типов - это и есть пруфы


Это теоремы ващето.
118 Кб, 730x499
#110 #1076570
>>1067298

>Может тут подскажете. Зачем в 2017+ году нужен язык с динамической типизацией?



Роберт Видринг говорил как-то на одной из конф: динамическая томущо хотелось горячей замены кода для работающего продакшена. Прикинули и решили что горячая замена неимоверно усложнится, если всё обмазать типами, придётся думать о том как решать конфликты типов уже в рантайме.
#111 #1076591
>>1076570
Кстати, интересная мысль. С этим связан вопрос: совместима ли горячая замена кода со статической типизацией? Может кто-то знает исследования по этому вопросу?
#112 #1076611
>>1076591

>Кстати, интересная мысль.


Сумасшедшая скорее.

>С этим связан вопрос: совместима ли горячая замена кода со статической типизацией?


Совместима.
#113 #1076613
>>1076611
А как достигается корректность, если при компиляции типизационные суждения вычёркиваются?
#114 #1076633
>>1076613

>А как достигается корректность, если при компиляции типизационные суждения вычёркиваются?



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

А то что там в erlang-е какие-то проблемы на этой почве, так это его ерланга специфическая проблема.
#115 #1076659
>>1076633
Я не про ерланг. Я хочу понять, как вообще это можно или нельзя делать.
Например так. Написали первый фрагмент программы, компилятор проверил типы статически, стёр суждения типизации, оставшиеся термы скомпилировал. Затем мы запускаем этот фрагмент. Потом мы готовим второй фрагмент, дальше надо его скомпилировать. Вероятно, проверять типы в нём надо совместно с первым фрагментом (в общем случае). Это обеспечит корректность такой двухфрагментной программы для компилятора. Далее стирание типов и компиляция второго фрагмента. Теперь нужно загрузить готовый второй фрагмент к выполняемому первому. Но на этом этапе гарантий корректности желаемой двухфрагментной программы у загрузчика нет.
Либо, если не стирать типы (ни в первом ни во втором фрагменте), то проверку типов должен проводить загрузчик непосредственно перед загрузкой второго фрагмента. Я не владею этим вопросом. Это всё реалистично?
Кстати, а как первый фрагмент начинает выполнять код из второго? Нужно использовать метасредства языка? В полной ли мере корректность согласована с метаязыковыми средствами? Обязательно ли это, или есть другие варианты?
Какие по этому вопросу есть теоретические исследования?
#116 #1076802
>>1076659
Интерфейсы.
Классы\модули
Указатели на функцию\делегаты
Сообщения

У тебя есть интерфейс.
Его реализует модуль 2 и знает модуль 1
Модуль 1 общается с модулем 2 через этот интерфейс.
Меняй модуль 2 на все что угодно, лишь бы реализовывал интерфейс.

>Какие по этому вопросу есть теоретические исследования?


Если модуль 1 корректен, и модуль 2 корректен, и "модуль коммуникации" корректен, то и система в целом корректна.
#117 #1076810
>>1076802

>Интерфейсы.


>Классы\модули


>Указатели на функцию\делегаты


>Сообщения


Заебись, ну значит в джаве тоже есть хотлоадинг кода. Джава - ето таки лишп, слава Гослингу!
#118 #1076856
>>1076810

>Заебись, ну значит в джаве тоже есть хотлоадинг кода. Джава - ето таки лишп, слава Гослингу!


В ЯП такой вещи как хотлоадинг кода быть в принципе не может. По очевидным причинам.
Это может быть либо в среде выполнения, любо в твоей конкретной программе.
В jre вроде как такого функционала нет, но при желании можно его реализовать множеством разнообразных способов.
#119 #1077027
>>1076802

>знает модуль 1


То есть типы не вычёркивать? И какие-то проверки типов нужно производить при загрузке второго фрагмента? Тогда это будет динамическая типизация?
Кстати, а чем тогда отличается горячая замена в условиях динамической типизации от динамического связывания?
#120 #1077032
Вы чо ебанулись на этих статических типах? Тут системы разрабатывают, приоритеты другие чем кококоректность. Оставьте это математикам и тем кто пишет пруфы с компиляторами. Нам надо динамика, надо чтобы код мог легко преобразовываться, перегружаться. Нужна гибкость на уровне синтаксиса и семантики желательно с отделенным control flow. Типы связывают всю систему, измени 1 тип и весь твой прекрасный мирок рухнул и надо все переебывать по новому. Алгебраические типы данных и классы сосут, никакой швятой корректности там нету, это иллюзия. Если бы это было так, ты бы сейчас не сидел на двачах заебанный от того, что этот ебаный баг правишь уже неделю. И ведь оно вполне себе компилится и работает в продакшене, так откуда баг то? Так что не надо пиздеть.
#121 #1077034
>>1077032

>Оставьте это математикам


Что ж поделать, если я, как бы, и есть.

>никакой швятой корректности


А что не так?
#122 #1077037
>>1077034
Раз ты математик, то пиши пейперы и создавай хаскел тред и аутируй там на гомотопии и прочее говно, это другая область. Мне платят за то что системы решают проблемы других людей. Системы должны разрабатываться быстро, быть производительными и там должно быть по минимуму багов. Все это решается культурой разработки и принятием определенных практик и моделей и парадигм. Еще эмпирически, да да, банально попробовать и если не сработало то попробовать еще раз, очень часто так и делается. Математика и типы не должны быть преобладающим вектором при разработке системы, если это не какая-то ебучая ракета которая доставляет жратву на МКС. Для построения систем, которые я разрабатываю (систем для которых эрланг и дизайнился) типы могут помочь только в определенных узких местах, например для консистентности данных. Но обмазывать типами всю систему это клиника.
Эрланг это не функциональный язык в том понимании, которое туда вкладывают шизики. Это простой пацанячий язык с иммутабельностью и асинхронным обменом сообщений, на этой хуйне можно делать нормальные распределенные отказоустойчивые системы и типы похую
#123 #1077038
>>1077037

>Математика и типы не должны быть преобладающим вектором при разработке системы


>Но обмазывать типами всю систему это клиника.


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

Меня интересуют некоторые вопросы в ЯП, в т.ч. в динамических. Их и задаю.
#124 #1077040
>>1077038

>Говоришь только за себя? В меру своих способностей?


>НИАСИЛИЛИ


Говоришь так будто типы это что-то ниебаца сложное лол. Много систем написал?
Да без пизды, конечно задавай. Но я их буду просто игнорить. Создавай свой тред и там их задавай.
#125 #1077107
>>1077027

>И какие-то проверки типов нужно производить при загрузке второго фрагмента?


Второй фрагмент уже проверенный, вначале проверяется, вот ты код написал, потом его что-то там проверило, собрало в модуль, все.
Модуль проверенный и теперь он подгружается.
#126 #1077142
>>1076802

>Меняй модуль 2 на все что угодно, лишь бы реализовывал интерфейс.


А заменять второй модуль можно только в момент, когда закончено выполнение его кода?
#127 #1077143
>>1077142
Ты себе хоть немного работу компутера представляешь?
Сириусли, ознакомся челе.
С архитектурой ПК, и базовым курсом ассемблера.
Ибо вопросы не несут какого либо смысла.

>А заменять второй модуль можно только в момент, когда закончено выполнение его кода?


Разрешаю заменять когда угодно.
#128 #1077146
>>1077143

>работу компутера представляешь?


Представляю, конечно.

>Разрешаю заменять когда угодно.


Если исполнение некоторой процедуры P1 из модуля M2 не завершено, как же в этот момент можно его заменять на модуль M2'? Чревато сбоями?
#129 #1077170
>>1076856
Для джавы, да? Очень интересно. Не расскажешь, что за способы?
161 Кб, 940x645
#130 #1077173
>>1077107

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


>Модуль проверенный и теперь он подгружается.



В Эрланге во время горячей загрузки существуют две версии кода: старая и новая. В момент когда модуль вызывает себя через полное имя my_module:my_function(). Происходит подмена старого кода новым.

Допустим что и в новом коде и в старом коде все типы проверены, ошибок нет. А как быть когда половина модулей уже переключились на новый код, а половина нет? Это ведь процесс не мгновенный, как удержать zero down time? Будет ведь неконсистентность, правильно?
#131 #1077174
>>1077037
Раз ты математик, то пиши пейперы и создавай гамалогии тред и аутируй там на гомотопии и прочее говно, это другая область. Мне платят за то что здания решают проблемы других людей. Здания должны разрабатываться быстро, быть надежными и там должно быть по минимуму щелей. Все это решается культурой разработки и принятием определенных практик и моделей и парадигм. Еще эмпирически, да да, банально попробовать и если не сработало то попробовать еще раз, очень часто так и делается. Математика и матан не должны быть преобладающим вектором при проектировке здания, если это не какая-то ебучая ракета которая доставляет жратву на МКС. Для построения зданий, которые я разрабатываю (зданий для которых автокад и дизайнился) матан может помочь только в определенных узких местах, например для консистентности данных. Но обсчитывать матаном все здание это клиника.
#132 #1077275
>>1077146

>Если исполнение некоторой процедуры P1 из модуля M2 не завершено, как же в этот момент можно его заменять на модуль M2'?


Наверное никак.

>Представляю, конечно.


>Чревато сбоями?


Еще раз повторюсь, удели время курсу ассемблера.
#133 #1077276
>>1077173

>А как быть когда половина модулей уже переключились на новый код, а половина нет?


И в чем проблема?

>Это ведь процесс не мгновенный


Не мгновенный.

>как удержать zero down time?


О чем конкретно ты говоришь? Что за zero down time?

>Будет ведь неконсистентность, правильно?


С чего бы это она будет когда у тебя все корректно?
#134 #1077317
>>1077275
>>1077276
Ой, блядь, ебаные баобабы, вы понимаете, что у лишпофортов и сочувствующих другая модель исполнения, отличающаяся от статикоговна?
#135 #1077729
>>1076613

>Будет ведь неконсистентность, правильно?


В момент замены кода в Эрланге виртуальная машина останавливается.
#136 #1077732
>>1077729
Ответ сюда: >>1077173
155 Кб, 940x605
#137 #1077800
>>1077729

>В момент замены кода в Эрланге виртуальная машина останавливается.


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

Я говорил про неконсистентность статических проверок, типизации, если бы она была у Эрланга.
#138 #1077835
>>1077729
Ещё скажи, что она в момент сборки мусора останавливается.
Тред утонул или удален.
Это копия, сохраненная 22 октября 2017 года.

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
« /pr/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски