community split на пустом месте, другая RTS со своими проблемами

т.е. это совсем другой язык

единственный плюс, что все средства выполнения и инструментирования от явы есть

т.е. с inline-java так нельзя

т.к. haskell код остается нативным

и переносимости которая есть в java нету

и отдадчик/профилировщик так просто не прицепить

но зато с inline-java можно нормально haskell код писать

Ну обычно проблемы на scala разраба найти. А на eta где потом кодера искать будут?

хаскелистов перетащат

Ну циклы пускай будут. Хотя можно и без них обойтись если будет оптимизация хвостовой рекурсии. А так все иногда скопировал обьекты в новую коллекцию, поменял их, но так как ты скопировал ссылки. То в старой они т оже изменились. И потом сидишь и дуплишь о причине страного поведения.

Циклы разрешили значит.... А они без мутабельности не бывают - от слова совсем ? Плач о дуплении и грусти при изменении объектов по ссылке - [b]эта[\b] конечно сильно ?

я как-то находил Monad.Imperative

https://hackage.haskell.org/package/ImperativeHaskell-2.0.0.1

Ну обычно это бывает если есть кеш. Обычно по проекту лень лазить и детально в нем копаться.

во примеры https://github.com/mmirman/ImperativeHaskell/blob/master/Main.hs

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

эм.. а при чем тут императивность?

возможно имелось ввиду мутабельность?

которая не является ни следствием, ни синонимом императивности

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

императивное = ты описываешь последовательность операций

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

если в объекте заменяются поля, то все зависит от того, изменяемый (mutable) он (или язык) или нет

так например в java (до 1.8) строка это неизменяемый объект, и "изменение" строки приведёт к аллокации нового объекта и отмечанию старого как неиспользуемого

(что кстати там в 1.8 и далее, уже всегда mutable? не слежу уже особо)

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

В F# есть мутабельность, в куче Лиспов/Схем (даже в моем Лискрипте), в Скале/Кложе вроде тоже (каламбур ? ) Сложности есть, но что не сделаешь ради желанной мутабельности ?

например в haskell никто не запрещает сделать alloca или использовать structs и менять что угодно

главное, что если язык ленивый нужно сохранить все data dependency

кстати, мутабельность особенно в конкурентном окружении может быть сильно переоценена

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

(не считая аллокации на стеке и прочую радость)

поэтому какой-нить аккуратный фьюзящийся алгоритм на векторах может всего-лишь в 1.1-1.3 раза проигрывать сишному коду (если там автор не навтыкает sse руками)

но наверное это уже оффтоп по сравнению с тем, что тут обсуждали

А в иммутабельном языке нет gc?

Все на стек разве кладется?

есть еще подобное чтиво? https://blog.jakuba.net/2014/07/20/mutable-state-in-haskell.html

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

Открыл ссылку и все родное синхронизация, транзакциионная память...

@Vladimir_Sentsov в иммутабельном языке есть gc

и поэтому там аллокации дешевые

дороже, чем на стеке, но на стеке юзкейс ограничен

черт, на henrychern.wordpress.com убрали содержание

а, нет, ложная тревога

кстати, мутабельность особенно в конкурентном окружении может быть сильно переоценена

локальность данных теряется в иммутабельных языках быстрее

хотя, это скорее всё таки специфические задачи на больших массивах и в хаскеле наверное для такого есть специальные либы

локальность штука интересная

у haskell компактирующий gc

у нас был случай (Зефиров про это писал не раз), мы (он) писали код для работы с потоковыми графами, по аналогии со stinger

который сишная либа с openmp и радостями и считается одним из лучших решений

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

т.к. у haskell куча собиралась и сжималась, и не было проблем с аллокациями, т.к. частый malloc/free приводил к тому, что у сишки работа с памятью дороже

несмотря даже на специальные представления графов запросов и т.п.

у нас тупо поверх IntMap было сделано

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

я не застал когда этот код писался, но я тестил это и результаты подтверились

кстати либа есть на hackage

не то, чтобы доделана и исходники только те что на hackage без истории

кстати либа есть на hackage

это ты про какую?

круто. граф (связи) обычно представляется в виде 2мерного массива, откуда там частые аллокации, компакты?

GraphHammer

@vlastachu ну вот у тебя есть граф гигов на 500, представляй

http://stingergraph.com/

можешь почитать у этих ребят и про представления и про алгоритмы

ну тут уже наверное тонкая работа над подгрузкой графа в оперативу

я ж говорю там streaming graph, поидее в тебя идёт поток событий и ты должен что-то находу считать

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

не ведёт

более чем уверен

с другой стороны он же перемещает сначала что видит

т.е. или depth или breadth first будет рядом складывать

статистика это ж дорого

вообще я так понимаю в gc стараются делать чем меньше тем лучше

ну да наверное

вроде потому и thread local heap (точнее как называлась эта ветка) позволяющая минорные gc делать не stop the world не прижилась

что код очень усложнился в impact почти не было

т.е. или depth или breadth first будет рядом складывать

наверное breadth

скорее всего

можно исходники посмотреть, но лень

Ну поробовали бы java. Там тоже сравнительно дешевая аллокация/деаллокация. Так как нет адресной арифметики.

было вчера

[begin..end] строится с помошью succ?

Prelude> :t [1.. 2] [1.. 2] :: (Num t, Enum t) => [t] да

Prelude> :t \a -> [a..a] \a -> [a..a] :: Enum t => t -> [t]

Так нагляднее (нет Num)

Только вот там не succ, а enumFromTo

Это отдельный метод класса

Недавно начал изучать Haskell. Я так понял, джентельменский набор — это GHCi и текстовый редактор? IDE никто не использует?

Их нет

Плагины для Sublime/Atom etc

есть среда для MacOS

Haskell for Mac вроде

Скорее всего еще в JetBrain'овских IDE есть плагины

Да, точно http://haskellformac.com

Плагины для Sublime/Atom etc

последнее обновление плагина для idea очень даже ок

А как он сам по себе? Я для Rust плагин юзал и он адски тормозной

Причем под словом адски я подразумеваю то, что он по 5 минут может подсвечивать ошибку в синтаксисе, которой уже нет