Immutable worries

[kika]

Не так все шоколадно в неразрушаемом мире.

It's the same reason so many other fundamental datastructures are missing: they just aren't practical in immutable languages.  Skew trees, splay trees, judy trees, julia trees, Knuth's Algorithm X container, Zobrist hashing, basically any ply tree strategy, basically every tree culling algorithm, et cetera - half of the stuff you find in NIST DADS - are casualties.  Erlang can't have real mtd(f).  Erlang can't have real A*.  Erlang can't have real negascout.  Erlang can't have real stochastic octrees.  Erlang can't have half the stuff you want for caching.  You'd do well to just write an interface for a tree or hash to get the expected API behavior and call it a day.  If you can't, it's time to write a port.

http://www.erlang.org/cgi-bin/ezmlm-cgi?4:mss:44582:200906:fheihgcibcpkcjpgfmbj

Текст срезонировал потому что я сейчас делаю IP address longest match lookup (как в таблице маршрутизации) и подумал что мою таблицу в реальный роутер не засунешь. Ибо у меня таблица никогда не перестраивается, поэтому я могу себе позволить ее создавать сколь угодно долго, а в реальном роутере она динамическая. У Ерланга куча наверное очень эффективная, но тем не менее.

Comments

[lionet.livejournal.com]

Знаешь когда видно, что Эрланг — вполне себе достижение компьютерного инжениринга, если не сайенса? Это когда смотришь на какую-то задачу, и говоришь себе: "тут я не вижу, что именно может справиться с ней лучше [быстрее, короче, правильнее] чем эрланг".

Это достаточный для меня критерий, для того, чтобы считать эрланг успешным языком. Таких задач у меня уже вагон и маленькая тележка. И для OCaml тоже вагон. И для C. Знаешь, какой язык у меня выпал по этому критерию из обоймы для тех задач, с которыми доводится иметь дело? C++.

[kika.livejournal.com]

Ты с чем споришь-то? С тем что ерланг не достижение? Я такого не говорил. У тебя в вузе небось был такой занудный предмет как "история науки", физики, химии, ватева. Очень полезно посмотреть на другие науки ретроспективно, вот была астрономия Птолемея, и это был рокет сайенс. А потом пришел Коперник и сказал "че-то тут у вас все сложно как-то", и все сложные ракетные расчеты Птолемея оказались как бы не совсем при чем. Но расчеты Птолемея нельзя взять и пересадить в систему Коперника. И то было достижение и это. Но они несовместимые.

Ты спрашиваешь - зачем такие наезды. Такие наезды нужны для создания спроса, который рано или поздно при необходимом количестве создаст предложение. А если постоянно заниматься склеиванием ассемблера с окамлом, то мы так и будем плавать по таблицам птолемея. Ибо работает же. Ведь это разные вещи, когда ты в программе на С пишешь "asm out ax, bl" и когда ты половину логики реализуешь на одном языке, а другую половину - еще на двух.

Если immutable state есть путь развития цивилизации, значит должны вырасти новые достижения про то, как иммутабельно работать с деревьями, списками, и т.д. Неважно как - реализацией внутренних представлений так что копирование списков будет выполняться за константное время и с константным оверхедом по памяти, или новая процессорная архитектура родится или новые алгоритмы придумают, неважно.

А про то какой язык успешный, а какой нет - боксоффис решает. С++ достаточно успешный, не менее чем С. Я вот писал на С++ несколько лет, потому что проект был на 3/4 про юзер-интерфейс, а на 1/4 про эффективный ввод-вывод. Для UI ничего кроме Qt не придумали, а эффективный ввод-вывод не придумали ни на чем кроме винды. Вот и писал на плюсах под винды. Фломастеры у всех разные.

[lionet.livejournal.com]

(Терминология: клей == ffi)

У меня убеждение такое, что один язык во все ниши сразу идеально вписываться не может. Или по-другому: нет такого языка, который одинаково хорошо подходит для всех ниш. Работы по созданию универсального языка ведутся с завидной регулярностью, но приемлемых решений до сих пор нет, и не предвидится.

Поэтому склеивать всё равно придётся, если стоимость и ригидность клея подходит под задачу. Вопрос в том, насколько сложно склеить (окамл с эрлангом), и оправдывает ли нужное количество склеек стоимость клея.

Так вот, C++ закрывает достаточно много ниш достаточно хорошо, чтобы стоимость его склейки с чем-то другим для многих задач (или/или многих программистов) превышала стоимость разработки чистого монокультурного решения именно на нём. И у многих сиплюсплюсных программистов есть в голове чёткая теория того, что этот язык не только претендует, но и является универсальным — настолько разные в его рамках можно решать задачи с умеренным геморроем.

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

Так что, уйдя от претендующий на универсальность технологии, от кирпично-цементного слоёного пирога язык-клей-язык-клей-язык отойти уже не получится: раз слез с C++, придётся его всеохватность и возможность разработки задач с широким диапазоном абстракций имитировать несколькими технологиями.

Вопрос только в том чтобы по трудозатратам C++ vs X+Y+Z был в пользу этих самых X+Y+Z. Если клей между технологиями очень затратный, значит сами технологии должны быть настолько впереди C++, чтобы оправдывать тяжесть этого интерфейсинга.

У тебя же подход, очевидно, зиждется на том, чтобы сделать из эрланга очередной "всеохватный" язык. Нет уж, второго всеохватного C++ мне совсем не нужно.

Для программистов, которые программируют эпизодически и понемножку, изучение языка типа Java или C++ даёт преимущества: один раз выучил, и пили себе понемножку разные задачи. Изучать и использовать другие языки имеет смысл только тогда, когда ты программируешь столько, что временные затраты на изучения нового языка или парадигмы будут перевешены экономией времени использованием нового языка. Это не для всех программистов верно, вообще-то.

Почему я об этом говорю, это же очевидно? А вот почему. С++ или та же Java имеют тенденцию создавать инерцию мышления, заставляя расценивать другие языки в качестве кандидатов на универсальные платформы (такие как C++ или Java). Любой новый язык расценивается с точки зрения "а могу ли я на нём с успехом решать все те задачи, которые я решаю на своём C++?" Ответы, в подавляющем большинстве случаев, отрицательные.

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

P.S. Диалекты Basic — гораздо более успешны, чем C++, по бокс-офису. Что это доказывает? Ничего.

[kika.livejournal.com]

имхо, универсальный язык - это всего лишь язык, на котором можно написать свой собственный рантайм. С, С++, ассемблер - универсальные языки, а Ява или Хаскель - нет.

Я ничего не имею против клея, ты опять споришь немного не с тем, что я декларирую. Я сам всю жизнь клеил и никаких комплексов по этому поводу не испытывал. Но, когда я купил Фиат Типо и выяснил что почти всю машину можно разобрать и собрать всего двумя гаечными ключами (13 и 15, а совсем всю машину - четыремя) я испытал культурный шок. Не перекладывать из руки в руку инструмент - это удобно. Ускоряет сборку, разборку, производство, ремонт, обслуживание и диагностику. Когда-то у нас было полтора десятка ассемблеров, Фортран и Кобол. И "еще одного ассемблера нам не надо". Но он появился и является сейчас самым наверное распространенным языком в мире, а если считать вместе с наследниками то и без "наверное".

Всеохватность С++ - иллюзорная. Это всеохватность ассемблера, она не имеет смысла в современных условиях.

Я еще раз проитерирую свой тезис: существует огромной пласт компутерного сайенса, который был наработан в системе Птолемея исходя из возможности модифицировать память компьютера чуть более чем полностью один раз. Immutable state эту возможность отнял и весь этот пласт стал несовместим. Это неустойчивая ситуация. Этот пласт был наработан не из озорства, а в ответ на потребности. Клей - это отличный способ решения проблем переходного периода, но не ответ на вопрос что делать дальше. Либо этот клей должен упроститься до уровня Inline:: или даже дальше, либо он умрет, убив и склеиваемые детали. Либо, возможен другой выход - технологии управления разработкой будут усовершенствованы до такого уровня, что необходимость использования произвольного числа языков не будет усложнять процессы управления и контроля за результатом. Это будет просто супер, но я пока даже не вижу предпосылок к этому. Бутиковое производство это, имхо, не ответ. Ответ - это решения для конвейера.

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

[lionet.livejournal.com]

a) Хаскель, в отличие от явы, уже давно написан на хаскеле. C-- был вчера.

a) В машине есть части из металла, резины, кожи. В автомобиле Форда корпус был сделан из дерева — унифицировали, удешевляли производство путём поиска универсальной материальной базы. В дальнейшем от этой унификации отказались и начали плодить разные материалы для разных частей машины. И всё может собираться вместе одинаковыми гайками (стандартный FFI), или клеем (_другой_ стандартный FFI), или вщёлкиваться друг в друга (третий стандартный FFI). То, что у фиата Типо стандартные human-serviceable части используют юниформный FFI - это отлично, но это не то что происходит при сборке машины на самом деле.

Будущее - не за унификацией, а за умением собрать гетерогенную систему из наиболее лучших вариантов реализации её частей. Получается антагонизм <машина <-> организм» В машине мало клея и очень стандартные части, а в организме куча высокоспециализированных тканей и очень разный клей между ними.

То что ты говоришь про пласт компьютерного сайенса я понял, и я настаиваю, что он никуда не девается. Эти алгоритмы — это ниша для современных продуктов. Основное внимание в разработке продуктов уделяется не алгоритмам (нужные из которых можно держать в отдельных подклеенных подсистемах), а разработке средств управления, постоянному повышению абстракции. На программном уровне мы управляем процессами обработки данных (не "суём в priority heap", а "запоминаем в кеше"), а на уровне управления разработкой программного продукта — минимизируем риски и осуществляем попытку многокритериальной оптимизации (по стоимости разработки, скорости работы, количеству глюков).

В этой среде алгоритмы считаются уже известными, а если они не неизвестны, значит их стоит придумать, реализовать и изолировать, подключив их в код через прослойку, повышающую их, алгоритмов, уровень абстракции. Этот "пласт" уже невидим, и исключительно редко является конкурентным преимуществом у компании. Фичи, сделанные на его основе могут составлять конкурентное преимущество, но имплементация и способ использования - нет. Все эти DHT, Geolocation, etc, etc — успешные проекты не работают на этом уровне абстракции. Проекты с использованием абсолютного большинства алгоритмов не должны писаться на их, алгоритмов, уровне абстракции: нужно разработать DSL (хотя бы в форме API над алгоритмом: cache/uncache, store/retrieve, etc) и работать уже на этом уровне.

И оказывается, что если уровень абстракции повышать, и писать метаязыки и DSL'и для предметной области, то мы одновременно можем идти от императивной парадигмы через функциональную к декларативной просто потому что на более высоких уровнях абстракции меньше движущихся частей. Представь какую-нибудь программу для репортинга на C# или такую же, на каком-нибудь DSL, который декларативно описывает всякие констрейнты и взаимозависимости данных. Второе может не являться turing-complete, а значит анализ его будет легче. Мы же не будем говорить что такой язык откидывает "целый пласт"? Нет, пласт алгоритмов всё ещё с нами, он — в интерпретаторе этого языка, который называется TurboTax.

Поэтому я не совсем соглашусь что immitable state based programming откидывает пласт. Он его убирает в подпол, там, где ему место, и расчищает пространство для абстракций и конструкторов систем управления более высокого уровня.

[helvegr.livejournal.com]

> C-- был вчера.

Да ну? (http://darcs.haskell.org/ghc/rts/)

[kika.livejournal.com]

В том-то и дело, что современная индустрия (ватева какая) не умеет производить организмы, а умеет производить машины. Я больше тебя хочу чтобы ты оказался прав, но пока не вижу как. Для того чтобы производить организмы, нужен совсем другой клей, а не те дебильные поделки, которые мы везде имеем в виде FFI и аналогов.
Изолируем алгоритмы и повысим уровень абстракции? Я только за. Через интерфейс порта, просовывая туда ерланговские термы в каком-то дурном бинарном формате, и расковыривая их с обратной стороны кодом на языке Си, повторяя работу интерпретатора? Да ну нафиг. Это не клей, это гвозди какие-то.
А про конкурентные преимущества у компании - это как бы от другой стенки совсем. Вообще говоря, для успешного бизнеса продукт является помехой, что мы и наблюдали некоторое время. Ну и в конце мы наблюли что эта конфигурация "постиндустриального общества" не является особенно устойчивой.
Для того чтобы подниматься выше по уровням абстракции, надо, имхо, построить достаточно надежный фундамент. Не залить там килотонну бетона, а хотя бы убедиться что он стоит на всех своих ногах устойчиво и что если мы рассчитываем что он выдержит то-то и то-то, то он как минимум это и выдержит. А пока мы имеем гору языков, DSLей, чего угодно, и очень хреновые возможности склеивать это все вместе. Хреновые чисто инструментально, в том числе. Плохо документированные, неэффективные, etc.

Чтобы убрать в подпол, надо дать нормальный клей. Клей у ерланга очень трудозатратный и плохо документированный. И, кстати, этот клей является группой риска. Вон, Юра ошибся в клее и у меня вся ерланговая машинерия встала раком. А за надежность именно она отвечает, и я там могу сколько хочу ошибаться, раком все равно ничего не встанет. И в том, к чему Юра клеил тоже можно ошибаться, будет работать плохо, но не встанет раком. А тонкий слой клея - бац и кранты всей скалябельности и надежности.

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

[lionet.livejournal.com]

<noflame>

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

CORBA, и IDL, ага.

Юра ошибся в клее и у меня вся ерланговая машинерия встала раком.

Linked-in drivers? А зачем? http://lionet.livejournal.com/35153.html

расковыривая их с обратной стороны кодом на языке Си

Могу выслать полный разборщик для OCaml. Си к окамлу может быть легче присоединить, чем к Erlang'у.

<noflame>

[kika.livejournal.com]

горба и прочий дком - это клеи немного другой системы, обойные :-)

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

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

[lionet.livejournal.com]

Как выяснилось, через порт ерланг тоже можно рачком-с поставить-с.

А вот это уже интересно. Расскажи?

более тяжелые я как-то так и не собрался попробовать

Могу отсыпать — у нас в одном месте именно так ;)

[cp-poster.livejournal.com]

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

[kika.livejournal.com]

Ну вот есть например асинхронный ввод вывод. Скажем, для дисков или там сокетов. В нынешнем мире сплошной мультимедии и тотального труHD без этого никуда и никак. И как это реализовано в юниксе? Универсальный ответ - никак. Можно призвать сюда дух и плоть юзера pzz и он расскажет, но, боюсь что текст будет существенно 18+.
А в винде есть overlapped I/O, который там да, кривой и местами не продуманный, но он работает и выжимает с дисков столько, сколько можно, пока ПСП не кончится.
А в линухе есть O_DIRECT, который как следует работает только на XFS, которая в свою очередь падает на томах объемом больше чем сколько-то там терабайт, которая отстутствует в стабильных дистрибутивах, а если ты хочешь портировать свой варез на, скажем, FreeBSD, то тебе проще пойти и убить себя нах об стенку.
Короче, давайте не начинать. (а то я пойду и убью себя ап стенку, а семья будет грустить)