Есть ли вещи, которые вы прницпиально не понимаете... - Философия программирования

Здравствуйте, alex_public, Вы писали:

K>>Группировка "внутри одного прямоугольника" определяется архитектурными соображениями. Соответствует ли ей связь а-ля симула-ООП — деталь реализации языка, к архитектуре и UML никакого значения не имеющая.
_>Т.е. всё снова сводится к тому, что вы предлагаете рисовать виртуальное ООП для Хаскеля. Мы же это уже обсуждали — мне уже как-то надоело ходить по кругу...

Так вы не ходите по кругу, а объясните:
1) Откуда следует, что "связь функций и данных" должна быть обязательно симула-стайл, а не какой-то другой.
2) Какие проблемы с использованием UML возникают от того, что она другая.

_>Так это же какая-то недоработка конкретной функции, а не принципиальная проблема архитектуры. Зачем использовать подобные демагогические аргументы во вроде как не базарной дискуссии?

Проблема в том, что для всех юзкейсов удобную функцию не сделаешь, потому и стараются сделать так, чтоб комбинация функций работала так же хорошо, как специально написанная. И если эту главную задачу библиотека не решает — то это уже принципиальная проблема ее архитектуры.

_>С map'ми всё отлично работает, как вы уже видели. А то, что вам посчастливилось наткнуться на какую-то недоработка стандартной библиотеки D при первом же знакомстве с языком, — это конечно нестандартное "везение". )))

Я же говорил, недоработка библиотеки сама по себе возможна и даже вероятна. Но такая проблема должна как-то обходится. Использованием другой библиотеки или каким-то изменением конвейера, или даже дописыванием своей функции, пригодной для оптимизации. Но если от него приходится отказываться в принципе, другого воркараунда нет — это уже говорит о проблеме.

_>Фокус в том, что там нет каких-то преобразований, а есть стандартный подход, прописанный в документации. Кстати, тот же IEnumerable в C# хотя и заметно послабее, но тоже ведь из этой области...

Если "нет каких-то преобразований", то возможности оптимизации сильно ограничены. А IEnumerable работает медленно, потому что никаких преобразований-оптимизаций там нет.
Такой вот код (Seq.cache кеширует последовательность в изменяемом массиве)

let rec primes = Seq.cache << Seq.append [2;3] << Seq.filter isPrime <| { 5 .. 2 .. 1000000000 }
and isPrime x = Seq.forall ((<>)0) << Seq.map (fun y -> x % y) << Seq.takeWhile (fun y -> y*y <= x) <| primes

let test1 = Seq.length << Seq.takeWhile (fun y -> y <= pown 2 24) <| primes

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

_>Ну вот здесь у нас с вами и находится принципиальное различие во взглядах. )

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

_>Да да. ) Только вот переход вверх возможен (написанием своего кода, подключением готового из библиотеки), а переход вниз обычно нет... )

Переход вверх для низкоуровневого языка вроде C++ возможет только интеропом с высокоуровневым языком вроде хаскеля. Точно так же и наоборот — переход на низкий уровень для высокоуровневого языка возможен интеропом с низкоуровневым или генерацией кода на низкоуровневом языке из встроенного ДСЛ.

_>По разному бывает. Частенько требуется не просто использовать какую-то возможность языка, а подключить мощную библиотеку, которая в итоге существенно меняет язык. )

Что такое "существенно поменять язык" в данном случае? Систему типов библиотекой можно поменять? А систему модулей? И как это все будет взаимодействовать с уже написанным кодом на не "измененном существенно" языке. Поддержку нормального сборщика в библиотекке не добавить. Нормальную поддержку ленивости тоже.

_>Да, циклов много, но большая часть из них написана на спец. языке, компилируемом в simd инструкции.

Ну так и комбинации комбинаторов можно в simd инструкции компилировать.

_>Ааа вы всё про это... Ну это же меньше процента погрешность.

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

_>А ведь у вас перед усреднением разброс был существенно больше, не так ли? )

Нет, он не был существенно больше, потому что выбросы я не учитывал.

_>Не знаю что вам непонятно. ) Знать язык и использовать его — это абсолютно разные вещи. Знаю я много языков, использую в реальных проектах очень мало.

Допустим, что разные, хотя я бы не стал переоценивать степень "знания" языка, которым не пользовался. Тут непонятно, почему вы упоминаете "играющихся с маргинальными языками" явно в негативном ключе, хотя сами же таким играющимся и являетесь.

Здравствуйте, alex_public, Вы писали:

_>Просто я существенно разделяю, закладываемое в языке, и добавляемое в библиотеках. Для меня хорош такой язык, который позволяет сделать практически всё что угодно с помощью дополнительных библиотек или своего кода. При этом стандартная поставка не так принципиальна.

Обычно оказывается, что язык, "который позволяет сделать практически всё что угодно с помощью дополнительных библиотек", не позволяет сделать ничего из того, что я полагаю нужным, если этого в языке с самого начала нет. Возможность добавлять что-то в язык с помощью библиотек — возможность очень важная и даже один из основных показателей качества языка. Однако если база у языка неудачная, сделать с этим уже ничего нельзя.

_>В этом смысле D занимает странное положение. По расширяемости он существенно превосходит и C++, но при этом в силу пока небольшого сообщества, библиотек на все случаи жизни пока нет. В то время как в C++ есть совершенно невероятные библиотеки на все случая жизни, которые выжимают из языка уже даже больше, чем он может дать.

При этом в C++ нет нормальной реализации практически ни для одной фичи, изобретенной после 68-го года, да и изобретенные до 68-го не все есть.

_>Я думаю что очень многие программисты мечтали бы иметь такую репутацию, как авторы D. )

Да, я и сам всегда мечтал стать известным писателем (пускай и известным в узких кругах, как Андрей Александреску).

K>>При таком подходе разницы между мутабельными и иммутабельными структурами действительно нет, поздравляю.
_>О, наконец то вы это осознали. )

Да нет, основной принцип апологетики такого рода я уловил довольно давно.
1) Считаем, что Y отсутствующее в языке X это то же самое, что и Y' в языке присутствующее.
1 б) Если в языке вообще ничего достойного упоминания нет, считаем, что отсутствие — это то же, что и наличие в общем случае.
2) На всякий случай одновременно обосновываем, что Y не нужно. Обосновываем, разумеется, отсутствием Y в X.
3) Теперь в нашем чудо языке X есть все, что бы мы не пожелали, и одновременно все (кроме, быть может, прилежания и усидчивости) — не нужно.
...
5) ПРОФИТ!

_>Кстати говоря в D immutable имеет важный смысл при работе с многопоточностью в D.

Да, как и pure.

_>Если признать вашу логику, то тогда любые данные в любых языках выделенные не с помощью прямого вызова VirtualAlloc не могут быть иммутабельными. )

Нет, из моей логики это не следует.

Здравствуйте, Ikemefula, Вы писали:

I>Только зарегистрированым.

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

I>Да вроде как уже сказал — экономить клиентский трафик. Рекламу показывать, как положено. "почаще обновлять страницу" — это не совсем понятно, что за кейс. Кучу рекламы показывать уже стало проблемой ?

Так рекламу чаще всего показывают просто через переход на след. страницу. Во всяком случае на тех сайтах с книгами, что я видел (давно уже не пользуюсь).

Здравствуйте, Ikemefula, Вы писали:

I>Кстати говоря, http://maxim.livejournal.com/392971.html

О, интересная ссылочка. Хотя и несколько устаревшая и от фаната эрланга (соответственно очень прогнозируемое первое место), но в остальном весьма любопытно, т.к. собраны действительно интересные и быстродействующие языки. Хотя без Java (как самого популярного) и C/C++ (как предел по быстродействию) этот тест выглядит всё же скучновато. Единственный сильно выделяющийся там из общей массы, это JS. И при этом он выступил очень достойно, даже обойдя нескольких конкурентов из старшей лиги.

I>Если ты внимаетльно посмотришь, то окажется, что хаскель рвёт в хлам твой хвалёный vibe.d
I>Более того, erlang, до безобразия "манеджед" рвет вообще всех, кроме nginx, который, в свою очередь, даже не на С++ написан.
I>D выступил очень удачно — еле-еле обогнал Node.js

Хы, ты похоже даже не прочитал текст по своей же ссылке. )))

Да, а вообще если интересоваться подобными тестами, то надо смотреть не подобные статьи в жж, а на что-то типа такого http://www.techempower.com/benchmarks/. Правда vibe.d там ещё нет. )

Здравствуйте, Ikemefula, Вы писали:

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

С чего бы это? ) Динамика оно или нет — это наше дело. Снаружи оно будет казаться тем, чем мы захотим.

Здравствуйте, Klapaucius, Вы писали:

K>Так вы не ходите по кругу, а объясните:
K>1) Откуда следует, что "связь функций и данных" должна быть обязательно симула-стайл, а не какой-то другой.

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

K>2) Какие проблемы с использованием UML возникают от того, что она другая.

Только в том, что в данный момент UML заточен под неё (в части своих диаграмм). Теоретически проблема решаемая, но похоже спецов по Хаскелю это не особо интересует. ))) Да, и кстати мы это тоже уже обсуждали... Подобные пережёвывания по нескольку раз утомляют уже.

K>Проблема в том, что для всех юзкейсов удобную функцию не сделаешь, потому и стараются сделать так, чтоб комбинация функций работала так же хорошо, как специально написанная. И если эту главную задачу библиотека не решает — то это уже принципиальная проблема ее архитектуры.

Так диапазоны D как раз и предполагают комбинации — даже здесь это было видно. И оно собственно работало, только почему-то плохо сработала оптимизация.

K>Я же говорил, недоработка библиотеки сама по себе возможна и даже вероятна. Но такая проблема должна как-то обходится. Использованием другой библиотеки или каким-то изменением конвейера, или даже дописыванием своей функции, пригодной для оптимизации. Но если от него приходится отказываться в принципе, другого воркараунда нет — это уже говорит о проблеме.

В том конкретном случае можно было без проблем написать свою версию (а на самом деле наверное глянуть на исходники оригинальной и что-то там подправить) функций any или until (не знаю какая из них тормозила). Только вот в любом случае проще и быстрее было поменять сам алгоритм. ))) Тем более, что речь шла о форумном споре.

K>Если "нет каких-то преобразований", то возможности оптимизации сильно ограничены. А IEnumerable работает медленно, потому что никаких преобразований-оптимизаций там нет.
K>Такой вот код (Seq.cache кеширует последовательность в изменяемом массиве)
K>

K>let rec primes = Seq.cache << Seq.append [2;3] << Seq.filter isPrime <| { 5 .. 2 .. 1000000000 }
K>and isPrime x = Seq.forall ((<>)0) << Seq.map (fun y -> x % y) << Seq.takeWhile (fun y -> y*y <= x) <| primes
K>let test1 = Seq.length << Seq.takeWhile (fun y -> y <= pown 2 24) <| primes
K>

K>полторы минуты работает.

А если на C#? )

K>Проблемы же, если использовать "функции", которые чистыми не являются все равно будут.

Проблемы могут быть только у неумеющих читать документацию. )

K>Мои взгляды легко изменятся, если мне кто-нибудь продемонстрирует действительно интересные возможности, за которые не нужно платить (даже в случае их неиспользования).

Это слишком неопределённо звучит) Начнём с того, что вы можете посчитать интересными возможностями. А то вот скажем мне кажется интересным распараллеливание цикла с помощью simd и на ядра процессора (в идеале и то и другое вместе). А вас такое быть может вообще не впечатляет... )

K>Переход вверх для низкоуровневого языка вроде C++ возможет только интеропом с высокоуровневым языком вроде хаскеля. Точно так же и наоборот — переход на низкий уровень для высокоуровневого языка возможен интеропом с низкоуровневым или генерацией кода на низкоуровневом языке из встроенного ДСЛ.

Как раз если мы имеем генерацию кода, то это не встроенный DSL, а обычный. А встроенный — это чаще результат подключения какой-нибудь библиотеки, о чём я собственно и говорил.

K>Что такое "существенно поменять язык" в данном случае? Систему типов библиотекой можно поменять? А систему модулей? И как это все будет взаимодействовать с уже написанным кодом на не "измененном существенно" языке.

Ну вот подключаем мы скажем Boost.Spirit и начинаем спокойно задавать грамматику для парсера в удобном декларативном виде. Или подключаем Boost.MSM и начинаем задавать конечные автоматы в удобном декларативном виде. При этом код реально становится похож на какой-то другой язык (например так http://www.boost.org/doc/libs/1_55_0/libs/msm/doc/HTML/ch03s04.html#d0e1462), но при этом остаётся всё тем же C++ со всеми его возможностями...

K>Поддержку нормального сборщика в библиотекке не добавить. Нормальную поддержку ленивости тоже.

Хы, ну как раз сборщик мусора и ленивость в C++ получаются подключением библиотек. ))) Но вы сейчас безусловно скажите, что это неправильные сборщики мусора и ленивость. ))) Хотя насчёт сборщика мусора я даже спорить не буду, т.к. вообще не считаю что он нужен в языке (написание его реализаций для C++ мне кажется просто академическими развлечениями).

_>>Да, циклов много, но большая часть из них написана на спец. языке, компилируемом в simd инструкции.
K>Ну так и комбинации комбинаторов можно в simd инструкции компилировать.

Не очень понял. Вот есть у меня функция Filter(uchar* data, int width, int height); Она вызывается из кода на C++, а реализацию имеет на другом специальном языке со своим компилятором. И куда мне тут прилепить конвейер? )

K>Допустим, что разные, хотя я бы не стал переоценивать степень "знания" языка, которым не пользовался. Тут непонятно, почему вы упоминаете "играющихся с маргинальными языками" явно в негативном ключе, хотя сами же таким играющимся и являетесь.

Там же ясно было написано в моей предыдущей фразе. Речь о реальных проектах. Т.е. если скажем у вас основная деятельность реализуется с помощью какого-то из мэйнстримовых инструментов (а не Хаскеля), то значит у вас приблизительно такое же отношение к Хаскелю, как у меня к D (и ещё нескольким языкам).

Здравствуйте, Klapaucius, Вы писали:

K>При этом в C++ нет нормальной реализации практически ни для одной фичи, изобретенной после 68-го года, да и изобретенные до 68-го не все есть.

Это в смысле в голом языке или с учётом библиотек?

K>Да нет, основной принцип апологетики такого рода я уловил довольно давно.
K>...

Нет, вы совсем не то поняли. Речь идёт об одном нюансе, связанном именно с иммутабельностью. Дело в том, что если мы возьмём мутабельный контейнер даже в языке без всяких спец. модификаторов и т.п. на эту тему и будем использовать на нём только не меняющее его подмножество операций, то у нас на самом деле получится полноценная работа с иммутабельными данными. Конечно в таком виде там не будет никаких оптимизаций, но их можно без проблем навесить потом, если они вообще понадобятся. Т.е. грубо говоря для нормальной работы с иммутабельными данными нам вообще ничего особенного не требуется от самого языка. Единственная проблема может быть в том, что компилятор не будет отслеживать применение "запрещенных" операций. А вот если в языке есть ещё и поддержка подобной проверки (как есть в D и частично в C++), то тогда вообще всё замечательно.

Здравствуйте, alex_public, Вы писали:

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

_>С чего бы это? ) Динамика оно или нет — это наше дело. Снаружи оно будет казаться тем, чем мы захотим.

Не будет. CDN это работа со статикий без участия твоего сервера. А если отдават статику динамикой, это непосредственное участие сервера.

Ты можешь внятно ответить на вопрос — каким чудом один и тот же файл можно отдавать через свой сервер, но так, что бы запрос не доходил до сервера ?

Здравствуйте, alex_public, Вы писали:

I>>Кстати говоря, http://maxim.livejournal.com/392971.html

_>О, интересная ссылочка. Хотя и несколько устаревшая и от фаната эрланга (соответственно очень прогнозируемое первое место), но в остальном весьма любопытно, т.к.

И давно nginx на erlang переписали ?

I>>Если ты внимаетльно посмотришь, то окажется, что хаскель рвёт в хлам твой хвалёный vibe.d
I>>Более того, erlang, до безобразия "манеджед" рвет вообще всех, кроме nginx, который, в свою очередь, даже не на С++ написан.
I>>D выступил очень удачно — еле-еле обогнал Node.js

_>Хы, ты похоже даже не прочитал текст по своей же ссылке. )))

Наоборот, я практически процитировал.

_>Да, а вообще если интересоваться подобными тестами, то надо смотреть не подобные статьи в жж, а на что-то типа такого http://www.techempower.com/benchmarks/. Правда vibe.d там ещё нет. )

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

Это понятно ?

Теперь про твои тесты, в частности Data Updates, Multiple Queries — C и C++ отсутствуют среди лидеров. Опаньки ! и почему то отсутствует перформанс парсинга JSON, есть только серилизация.

Вобщем ты привел какие то невнятные тесты, из которых снова не ясно, чем же нативные языки так круты.

Здравствуйте, alex_public, Вы писали:

I>>Только зарегистрированым.

_>Если это модель с продажами, то тогда надо ставить защиту и соответственно это будет уже не тривиальная система, в которой должен быть и специфический js код на клиенте и серверная поддержка этого. Последнее вполне реализуемо на vibe.d, но в одиночку он естественно не правится.

I>>Да вроде как уже сказал — экономить клиентский трафик. Рекламу показывать, как положено. "почаще обновлять страницу" — это не совсем понятно, что за кейс. Кучу рекламы показывать уже стало проблемой ?

_>Так рекламу чаще всего показывают просто через переход на след. страницу. Во всяком случае на тех сайтах с книгами, что я видел (давно уже не пользуюсь).

Я понял, у тебя ничего нет, только общие слова.

Здравствуйте, alex_public, Вы писали:

K>>Так вы не ходите по кругу, а объясните:
K>>1) Откуда следует, что "связь функций и данных" должна быть обязательно симула-стайл, а не какой-то другой.

_>А какую другую может предложить Хаскель? )

А почему вы отвечаете вопросом на вопрос?
Вообще, вынесите пока хаскель за скобки, для ответа на вопрос его притягивать не нужно, да и вы все равно про него недостаточно знаете, чтоб его можно было использовать тут как (контр)пример.
Повторяю вопрос: Откуда следует, что "связь функций и данных" должна быть обязательно симула-стайл, а не какой-то другой?
К примеру, связь экстеншн-метода с расширяемым им классом/интерфейсом в C# не является симула-стайл, однако с архитектурной точки зрения может быть удобнее показывать их на диаграмме как члены расширяемого класса, а не как члены некоего статического утилитного класса, или как одновременно и те и другие.

K>>2) Какие проблемы с использованием UML возникают от того, что она другая.

_>Только в том, что в данный момент UML заточен под неё

В чем эта заточенность выражается?
Можно, наверное, сказать, что UML заточен под связь функции с одним типом — т.е. со всякими мультиметодами могут быть проблемы. Да и то на вряд ли — никаких проблем с размещением одной функции в n прямоугольниках нет.

K>>Проблема в том, что для всех юзкейсов удобную функцию не сделаешь, потому и стараются сделать так, чтоб комбинация функций работала так же хорошо, как специально написанная. И если эту главную задачу библиотека не решает — то это уже принципиальная проблема ее архитектуры.

_>Так диапазоны D как раз и предполагают комбинации — даже здесь это было видно. И оно собственно работало, только почему-то плохо сработала оптимизация.

Ну вот, оптимизация сработала плохо — см. выделенное — и след. главную задачу библиотека не решает.

_>В том конкретном случае можно было без проблем написать свою версию (а на самом деле наверное глянуть на исходники оригинальной и что-то там подправить) функций any или until (не знаю какая из них тормозила). Только вот в любом случае проще и быстрее было поменять сам алгоритм. ))) Тем более, что речь шла о форумном споре.

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

_>А если на C#? )

Немного побыстрее, скорее всего, но не принципиально. Вообще Linq to Objects работает немного быстрее f#-библиотек. Такой вот вариант

let rec primes = Seq.cache << Seq.append [2;3] << Seq.filter isPrime <| { 5 .. 2 .. 1000000000 }
and isPrime x = primes.TakeWhile(fun y -> y*y <= x).Select(fun y -> x % y).All(fun x -> x <> 0)

минуту проработает.
Кое-какие средства фьюжена у Linq to Objects, кстати, есть — но не особенно серьезные: набор написанных вручную "сфьюженных" итераторов типа WhereSelectListIterator, которые выбираются в рантайме.

_>Проблемы могут быть только у неумеющих читать документацию. )

Распространенная отговорка. Примерно то же самое и любители бестиповых языков говорят. Ну, "не умеющие читать документацию" в данном случае означает примерно то же, что и "все".

K>>Мои взгляды легко изменятся, если мне кто-нибудь продемонстрирует действительно интересные возможности, за которые не нужно платить (даже в случае их неиспользования).
_>Это слишком неопределённо звучит)

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

_>Начнём с того, что вы можете посчитать интересными возможностями. А то вот скажем мне кажется интересным распараллеливание цикла с помощью simd и на ядра процессора (в идеале и то и другое вместе). А вас такое быть может вообще не впечатляет... )

"распараллеливание с помощью simd и на ядра процессора" мне кажется интересным. Выжимание из цикла смысла, вкладываемого в него программистом, которое для этого требуется мне тоже интересно, как сложная задача. Но мне интереснее циклы вообще не писать и не читать, средства, которые меня от этого освобождают.

_>Как раз если мы имеем генерацию кода, то это не встроенный DSL, а обычный. А встроенный — это чаще результат подключения какой-нибудь библиотеки, о чём я собственно и говорил.

Встроенный ДСЛ может использоваться для генерации кода. Как в случае сишарпного linq какого-нибудь или хаскельного accelerate.

_>Ну вот подключаем мы скажем Boost.Spirit и начинаем спокойно задавать грамматику для парсера в удобном декларативном виде. Или подключаем Boost.MSM и начинаем задавать конечные автоматы в удобном декларативном виде. При этом код реально становится похож на какой-то другой язык (например так http://www.boost.org/doc/libs/1_55_0/libs/msm/doc/HTML/ch03s04.html#d0e1462), но при этом остаётся всё тем же C++ со всеми его возможностями...

Это называется не "существенно менять язык". Это называется "использовать библиотеку". Базовая фича для языка программирования.

_>Хы, ну как раз сборщик мусора и ленивость в C++ получаются подключением библиотек. )))

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

_>Но вы сейчас безусловно скажите, что это неправильные сборщики мусора и ленивость. )))

Ну вот, вы и сами все знаете.

_>Хотя насчёт сборщика мусора я даже спорить не буду, т.к. вообще не считаю что он нужен в языке (написание его реализаций для C++ мне кажется просто академическими развлечениями).

Это то как раз понятно, потому что ваша позиция заключается в том, что ничего сверх того, что есть в C++ (за исключением перламутровых пуговиц добавленных в D) в принципе не нужно. И собственно наличие в c++ и является критерием нужности.

_>Хотя насчёт сборщика мусора я даже спорить не буду

Насчет ленивости, стало быть, спорить будете?

_>Не очень понял. Вот есть у меня функция Filter(uchar* data, int width, int height); Она вызывается из кода на C++, а реализацию имеет на другом специальном языке со своим компилятором. И куда мне тут прилепить конвейер? )

Туда что код Map(что-то там).Filter(что-то там).Fold(что-то там) превращается в код на "другом специальном языке со своим компилятором".

_>Там же ясно было написано в моей предыдущей фразе. Речь о реальных проектах. Т.е. если скажем у вас основная деятельность реализуется с помощью какого-то из мэйнстримовых инструментов (а не Хаскеля), то значит у вас приблизительно такое же отношение к Хаскелю, как у меня к D (и ещё нескольким языкам).

Да, у меня именно такое же отношение к хаскелю, как у вас к ди, так что непонятно, откуда вы выводите противопоставление.

Здравствуйте, alex_public, Вы писали:

K>>При этом в C++ нет нормальной реализации практически ни для одной фичи, изобретенной после 68-го года, да и изобретенные до 68-го не все есть.
_>Это в смысле в голом языке или с учётом библиотек?

С учетом библиотек.

_>Нет, вы совсем не то поняли. Речь идёт об одном нюансе, связанном именно с иммутабельностью. Дело в том, что если мы возьмём мутабельный контейнер даже в языке без всяких спец. модификаторов и т.п. на эту тему и будем использовать на нём только не меняющее его подмножество операций, то у нас на самом деле получится полноценная работа с иммутабельными данными.

1) Это не имеет отношения к обсуждаемому примеру, в котором используются не "не меняющее его подмножество операций", которого вообще у вашего "иммутабельного типа" нет, а мутирующие операции используются таким образом (линейно и уникально), что мутабельность структуры данных семантически не наблюдается.
2) Нет, если вы используете "не меняющее его подмножество операций", то это не является "полноценной работой с иммутабельными данными". Иммутабельность вообще не про это. Иммутабельность — это, например, когда вы можете рассчитывать, что всем остальным держателем ссылки на объект, с которым вы работаете не доступны мутирующие операции над ним и они не могут его "испортить", а значит вам не нужно оборонительно копировать (не поверхностно) обсуждаемый объект.
Еще иммутабельность — это дешевое создание версии, этот конкретный аспект обычно называют "персистентность".

_>Конечно в таком виде там не будет никаких оптимизаций, но их можно без проблем навесить потом, если они вообще понадобятся. Т.е. грубо говоря для нормальной работы с иммутабельными данными нам вообще ничего особенного не требуется от самого языка.

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

_>Единственная проблема может быть в том, что компилятор не будет отслеживать применение "запрещенных" операций. А вот если в языке есть ещё и поддержка подобной проверки (как есть в D и частично в C++), то тогда вообще всё замечательно.

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

Здравствуйте, Ikemefula, Вы писали:

I>Не будет. CDN это работа со статикий без участия твоего сервера. А если отдават статику динамикой, это непосредственное участие сервера.

I>Ты можешь внятно ответить на вопрос — каким чудом один и тот же файл можно отдавать через свой сервер, но так, что бы запрос не доходил до сервера ?

Я тебе уже несколько раз говорил, но до тебя похоже даже прямой текст перестал доходить. Сервер отработает один раз (отдавая в CDN).

Хотя если у нас вообще только статика на сервере, то естественно никакие фреймворки типа vibe.d вообще не нужны, т.к. привносят только ненужную сложность. Но дело именно в сложности и неудобности (в сравнение со статическим сервером), а не в меньшем быстродействие, которое мы тут обсуждали.

Здравствуйте, Ikemefula, Вы писали:

I>И давно nginx на erlang переписали ?

Nginx там только для оценочного сравнения, т.к. вообще не относится к группе исследуемых фреймворков (они же все для динамики). Т.е. фреймворка на C/C++ в данном тесте вообще не было. А первое место занял именно ерланговский фреймворк, что абсолютно не удивительно с учётом пристрастий автора теста.

I>Ты очевидно не понял. Я привел тесты исключительно сетевой части, то есть самого вебсервера, а ты показываешь совсем другие тесты. Надо объяснять, что если сам сервер не выдержит N коннектов, то нагрузив его чем угодно, не получится выдать эти же 10 тыщ коннектов ?

В большинстве таких фреймворков сервер интегрирован во фреймворк, а не живёт где-то отдельно. )

Здравствуйте, Klapaucius, Вы писали:

K>А почему вы отвечаете вопросом на вопрос?
K>Вообще, вынесите пока хаскель за скобки, для ответа на вопрос его притягивать не нужно, да и вы все равно про него недостаточно знаете, чтоб его можно было использовать тут как (контр)пример.
K>Повторяю вопрос: Откуда следует, что "связь функций и данных" должна быть обязательно симула-стайл, а не какой-то другой?

Нет, дело как раз в Хаскеле. Потому как, раз он не поддерживает связь "симула-стайл", то должен предложить что-то взамен для тех же целей.

K>В чем эта заточенность выражается?
K>Можно, наверное, сказать, что UML заточен под связь функции с одним типом — т.е. со всякими мультиметодами могут быть проблемы. Да и то на вряд ли — никаких проблем с размещением одной функции в n прямоугольниках нет.

Вы в начале опишите с помощью чего на Хаскеле можно спроектировать нормальную иерархическую архитектуру, а мы уже потом посмотрим как это отобразить в UML.

Вот например возьмём самую лубочную реализацию обычного ООП GUI приложения:

class MyView: public View{
    void OnDraw() override;//рисуем что-то в окне
};
class MyWindow: public Window{
    Menubar menu;
    Toolbar tools;
    MyView view;
    Statusbar status;
    void OnViewClear();//реакция на меню/тулбар/хоткей
public:
    MyWindow();//установка элементов по местам и настройка реакций на события
};
class MyApp: public App{
    MyWindow window;
public:
    MyApp();//Инициализация каких-нибудь библиотек
    ~MyApp();//Деинициализация библиотек
};
int main()
{
    MyApp app;
    app.Run();//основной цикл приложения
}

Рисовать UML диаграмму классов для этого кода я здесь не буду, потому как думаю все без проблем представляют её себе. Так вот, взглянув на эту диаграмму я мгновенно понимаю всю структуру приложения (да, сейчас то это и по коду можно, но на практике код будет во многих больших файлах, а не как здесь).

Можно увидеть каноническую реализацию подобного кода на Хаскеле? Т.е. не использование из Хаскеля биндинга к какой-то известной ООП GUI библиотеки (т.к. там всё равно будет сохраняться подобная же структура, хотя и по кривому), а именно если взять GUI библиотеку написанную на Хаскеле с нуля в правильном функциональном стиле.

Ну и соответственно будет интересно взглянуть на UML диаграмму для такого канонического кода — оценим насколько она позволяет понять всю архитектуру приложения.

_>>Так диапазоны D как раз и предполагают комбинации — даже здесь это было видно. И оно собственно работало, только почему-то плохо сработала оптимизация.
K>Ну вот, оптимизация сработала плохо — см. выделенное — и след. главную задачу библиотека не решает.

Вот зачем выдавать какой-то конкретный баг/недоработку в реализации за архитектурную проблему? Это уже демагогия слишком низкого уровня...

K>"распараллеливание с помощью simd и на ядра процессора" мне кажется интересным. Выжимание из цикла смысла, вкладываемого в него программистом, которое для этого требуется мне тоже интересно, как сложная задача. Но мне интереснее циклы вообще не писать и не читать, средства, которые меня от этого освобождают.

Хех, ну я бы тоже такое предпочёл. Только вот в реальном мире нет ничего подобного. Например даже C++ со своим автовекторизатором не дотягивает по эффективности до специализированных (и соответственно более низкоуровневых) решений. А уж про другие реализации я вообще молчу.

K>Это называется не "существенно менять язык". Это называется "использовать библиотеку". Базовая фича для языка программирования.

Да, но в некоторых языках (типа C++ или D) есть возможности очень сильно изменять язык прямо в коде (метапрограммирование, перегрузка операторов и т.п.). И соответственно в таких языках использование некоторых библиотек очень сильно меняет язык, вплоть до задания полноценных встроенных DSL.

_>>Хотя насчёт сборщика мусора я даже спорить не буду, т.к. вообще не считаю что он нужен в языке (написание его реализаций для C++ мне кажется просто академическими развлечениями).
K>Это то как раз понятно, потому что ваша позиция заключается в том, что ничего сверх того, что есть в C++ (за исключением перламутровых пуговиц добавленных в D) в принципе не нужно. И собственно наличие в c++ и является критерием нужности.

Как раз нет. У меня вообще огромный список претензий к C++. В первую очередь это конечно отсутствие статической интроспекции — это просто дико бросается в глаза. Потом переусложнённый и одновременно недостаточно функциональный (в первую очередь нельзя строки передавать как параметры) синтаксис шаблонов (при использование их для метапрограммирования, а не для обобщённого). Далее отсутствие удобной системы модулей и т.д. и т.п. В общем я могу долго продолжать о недостатках C++. Только вот при всём при этом к сожалению ничего лучше по сумме параметров (включающих и наличие библиотек/инструметов и стабильность/оптимизированность) всё равно на рынке не наблюдается.

Но вот относительно конкретно сборщика мусора у меня именно идеологическая позиция, что при наличие полноценного RAII он является только вредным элементом.

K>Насчет ленивости, стало быть, спорить будете?

Насчёт ленивости у меня следующая позиция:
— в принципе ленивость вещь полезная, но не глобально, а в специфических случаях
— в C++, в самом языке, естественно ничего подобного нет
— в C++ есть много библиотек на эту тему (в первую очередь в Boost'е), которые покрывают множество сценариев с ленивостью, но думаю что не все, т.к. там используется так сказать экстенсивный подход, а не фундаментальный
— все встреченные мною случаи, когда была бы полезна ленивость, покрывались библиотеками из Boost'а.

_>>Не очень понял. Вот есть у меня функция Filter(uchar* data, int width, int height); Она вызывается из кода на C++, а реализацию имеет на другом специальном языке со своим компилятором. И куда мне тут прилепить конвейер? )
K>Туда что код Map(что-то там).Filter(что-то там).Fold(что-то там) превращается в код на "другом специальном языке со своим компилятором".

Всё равно не понял. Ну т.е. если вы говорите о том, что бы заменить код вида "Filter(data);Map(data);Fold(data);" на "data.Filter().Map().Fold();", то это действительно без проблем делается. Только вот какой-либо пользы от подобного нет. А если вы про что-то другое, то тогда поясните подробнее.

K>Да, у меня именно такое же отношение к хаскелю, как у вас к ди, так что непонятно, откуда вы выводите противопоставление.

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

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	04.08.14 17:32
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	04.08.14 17:42
Оценка:

	От:	alex_public
	Дата:	05.08.14 03:25
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	05.08.14 05:13
Оценка:

	От:	Klapaucius
	Дата:	05.08.14 09:48
	Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	10.08.14 16:49
Оценка: