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

LCR>>>1. грязь бывает очень разная — то есть грязь имеет тип.
G>>?! В самом деле, сэр? ("И прекратите говорить мне "в самом деле", Дживс. Каждый раз мне слышится вместо этого, "обалдели, сэр?"" — из рассказов про Дживса) Пример, плз.
LCR>Да, сэр, абсолютно серьёзно! Если гадим в stdio — это один тип, гхм... извините, грязи, если используем императивный доступ к массивам — это другой, используем FFI — это третий, рисуем окошечки — это четвёртый. Можно даже дальше пойти, и захотеть чтобы операции над разными файлами тоже разруливались компилятором, если этого очень хочется. Вот, вкратце такие примеры-с.

Понятно. Грязь, разумеется имеет тип. Для "грязных" типов придуманы объекты, инкапсулирующие в себе состояние. В эрланге то процесс, в OCaml, простите — объект.

G>>Попробуй в Хаскеле вставить логгирование куда-нибудь вниз гражданского кода — огребешь тоже самое в точности. Или будешь вынужден протащить параметр наверх, или расставишь везде свой монадный dirty. Нет?
LCR>И да, и нет. Есть ещё liftM и monad transformers, которые сделают преобразования обычных или монадических функций в монадические. Также есть unsafePerformIO, но это уже когда одолевает бессилие

Ок, ставим вопрос конкретно. У вас система, структурированная как набор бесконечно рекурсивных функций, замкнутая ленивыми списками. Типичный такой подход для моделирования состояния в ленивом языке. Знакомая ситуация? Весь из себя чисто функциональный. Что будем делать, если захотим логгирование вставить в один из блоков? Или случайные числа там поюзать?

G>>Можно, кстати, шибко далеко не идти, и сразу заглянуть, как это сделано в... С++. Делаем dirty частью сигнатуры (как const), разрешаем описывать generic-функции без указания модификатора.
LCR>Способ, которым это сделано в C++ вызывает лёгкое головокружение. И всё-таки. Не мог бы ты, глубокоуважаемый Джин, ответить мне на маненький вопрос:
LCR>

LCR>-- Функция map - она чистая или грязная?
LCR>map :: (a -> b) -> [ a ] -> [ b ]
LCR>

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

Безусловно.

LCR>Развивая мысль далее в этом духе, я прихожу к мысли, что твой dirty будет или синонимом звёздочки в Clean, или монадой в Haskell, или он вообще не будет проверяться в compile-time, как в Эрланге, Окамле, Скале и прочих заслуживающих внимание языках, потому что их системы типов не рассчитаны на такую проверку (т.е. недостаточно мощны). Я не прав?

Да, то что-то вроде звездочки в Clean. Хотя, как именно от этого перекорежит Хиндли-Милнера, я не знаю — не думал об этом.

Что касательно Эрланга — там динамическая семантика вызова. Так что можно и не проверять.

G>>Процесс проектирования в грязном языке несколько другой, не так все плоско. На крупном уровне декомпозиции делают "грязные" классы — это удобно. Логика которых внутри описываются чисто. Пример языка, где сделано так — Эрланг. Таким же образом разумно проектировать и в OCaml c Nemerle. Я как-то об этом уже писал.

LCR>Я совершенно согласен, это хороший подход к. Но коли уж мы хотим проверяемости компилятором, я осмелюсь повторить, что мы столкнёмся с 99% грязных функций, то есть по сути проверять окажется нечего. Коли уж ты упомянул Эрланг, позволь мне процитировать Джо:
LCR>

Notice that I have chosen a particularly simple definition of “dirty.” At first sight it might appear that it would be better to recursively define a module as being dirty if any function in the module calls a “dangerous” BIF or a dirty function in another module. Unfortunately with such a definition virtually every module in the system would be classified as dirty.

Джо, объективно, неправ. Модули, работающие со структурами данных, такие как queue, gb_trees, sets, и прочие — чисты как слеза младенца. Обработку данных и имеет смысл держать чистой. Ввод-вывод — нет. Также, хорошая практика отделять чистый код в отдельные модули, изолируя побочные эффекы, что и делается при хорошем дизайне на Erlang. К примеру, бехавиорсы заведены именно для того, чтобы грязь по возможности спрятать во фреймворк. Я бы привел соответствующие цитаты Джо, да лень искать. Знаешь — у Маркса можно найти цитату на любой подходящий случай? Так и у Джо.

G>>Сверхбольшие? ... Результаты нашего evaluation Хаскеля показывают следующее...

LCR>Хм, огромное спасибо. Мне очень интересно почитать о чужом негативном опыте. "И пепел твоих поражений станет залогом будущих побед". Не так давно была ссылка на ещё один неудачный опыт

Автор: Курилка
Дата: 28.12.06

применения Haskell, там человек попробовал писать на Хаскелле "как на Йаве", и много жаловался на монады.

Одна проблема. На хаскеле у нас писал potan, thesz (они немножечко так понимают в Хаскеле, если ты знаешь, о ком я), а также немного — garrrr, и еще три человека. Никто из них не знает явы, представляешь?

Наш опыт, кстати, это работающий симулятор суперскалярного процессора MIPS, и интеллектуальный контроллер памяти. Проекты успешно завершены.

LCR>Вывод: возлюби монады если хочешь обуздать Хаскелл.

Я тебе тоже совет дам, если можно. Ты напиши полезную системку на Хаскеле хотя бы в тыщу строк кода, а потом свои выводы делай, ладно?

G>>Семантическая простота (как мне кажется из моего опыта maintenance — это когда человеку понять проще), мне думается, связана с indirection level применяемых конструкций. Вот, у монад с indirection level все плохо, как и у макросов. То же самое касается комбинаторного стиля, столь любимого Хаскелистами. Хрен разберешь без бутылки.
LCR>Судя по приведённым примерам, а также по критике макросов тут

Автор: Gaperton
Дата: 09.08.06

твой indirection level — это просто удалённая избыточная информация такая, что трактовка оставшегося куска по прежнему остаётся однозначной.

LCR>Получается, что любой подъём по абстрактной лесенке от низкоуровневых до высокоуровневых абстракций увеличивает этот самый indirection level, независимо от того, как мы подымаемся — новыми функциями, макросами, монадами или абстрактными типами. Почему тогда монады и комбинаторы стоят так особняком?
LCR>(Я обещаю дальше не развивать этот оффтоп, но мне интересно, что ты ответишь).

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

G>>Особенность безусловно интересная с теоретической точки зрения, меня она тоже приводит в восторг. Но проектировать и отлаживать из-за этой возможности на практике очень тяжело. Лучше застрелится сразу, чтобы не мучатся. Особенно, на сверхбольшой системе.
LCR>А как насчёт возможности комбинировать функции и компоненты без abstraction penalty?

Комбинаторный стиль затрудняет читабельность, и снижает maintainability. Сам же в собственном коде не разберешься через год-два. Что говорить о другом человеке?
Впрочем, приведи пример, показывающий что ты хочешь сказать. Я, как Мюллер про сыщиков — считаю что инженерам пристало говорить существительными и глаголами — т.е. конкретно.

LCR>>>Хм. А чем обусловлена такая "невытаскиваемость в принципе"? Или ты априори предполагаешь, что переллелизатор не может быть оформлен в виде библиотеки? Или передать туда информацию кроме как исходный код в принципе невозможно?
G>>Информацию о параллелизме ты вытащишь, это не фокус. Ты не вытащишь информацию о локальности вычислений в программе и о потоках данных — она в статике не получается. Из-за этого и происходит просадка в производительности при увеличении узлов — причина в плохом управлении локальностью вычислений.
LCR>Я о том, чтобы не оставлять компилятор бороться в одиночку а помочь ему декларативными директивами типа "все эти функции должны выполняться в контекстах потоков внутри платы, а вот эти — внутри стойки, эти можно внутри кластера"... (впрочем это тоже оффтоп).
Так можно. Только это, видишь ли, то самое явное выделение потоков, с которым ты борешься. Плюс ко всему — у тебя все равно возникнет проблема с разделяемыми данными. Всю программу надо будет проектировать с учетом параллельного выполнения — данные тебе компилятор автоматом не побьет.

Здравствуйте, Аноним, Вы писали:

G>>Мы обсуждали ленивость/строгость по умолчанию. Мои выводы — язык должен быть строгим по умолчанию, с честными побочными эффектами и вводом-выводом без монад.

А>Так называется тема треда. Вы же ударились в обсуждение чистоты/нечистоты. В основном на эту тему я и высказался.

Говоря о чистоте или нечистоте, я высказывался на тему треда. Потому что ленивость по умолчанию вынуждает быть чистым. Вы, когда влезать в середину дискуссии будете, прочитайте всю ветку с начала, ок? Это снимает массу вопросов.

А>Поскольку Вы выражаетесь крайне невнятно, я позволю себе интерпретировать Ваши "честные побочные эффекты" как побочные эффекты безо всяких ограничений. О чем тогда был весь сыр-бор в этой ветке?
А>И Вы так даже и не намекнули КАКОЙ (то есть ДЛЯ КАКИХ ЦЕЛЕЙ предназначенный) язык должен быть "строгим по умолчанию, с честными побочными эффектами и вводом-выводом без монад".

СПЕЦИАЛЬНО ДЛЯ ШИБКО УМНЫХ. КАПИТАЛИЗАЦИЯ ВОСПРИНИМАЕТСЯ КАК КРИК, А Я НЕ ЛЮБЛЮ, КОГДА НА МЕНЯ ОРУТ. ЭТО РАЗ.

Ничего объяснять я вам не не обязан и не хочу — мне это совершенно неинтересно. Можете интерпретировать как хотите. Это два.

Всего доброго. Это три.

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

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

Это у Вас глюки. С таким же успехом можно утверждать, что энергичность по умолчанию вынуждает быть чистым. Чистым хорошо быть ВСЕГДА. Просто к запаху императивной помойки Вы привыкли и он уже не шибает.

G>СПЕЦИАЛЬНО ДЛЯ ШИБКО УМНЫХ. КАПИТАЛИЗАЦИЯ ВОСПРИНИМАЕТСЯ КАК КРИК, А Я НЕ ЛЮБЛЮ, КОГДА НА МЕНЯ ОРУТ. ЭТО РАЗ.
G>Ничего объяснять я вам не не обязан и не хочу — мне это совершенно неинтересно. Можете интерпретировать как хотите. Это два.
G>Всего доброго. Это три.

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

Здравствуйте, <Аноним>, Вы писали:

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

VD>>Вообще-то намекали и не раз. Язык нужен исключительно для целей создания прикладного и системного ПО. То есть не для баловства одиночек, а для разработки средних и больших систем.

А>Даже когда я разрабывал маленькие системы я НИКАК не мог обойтись каким-то одним языком. Например, типичной ситуацией для меня (в недавнем прошлом) был следующий *МИНИМАЛЬНЫЙ* набор:
А>1. Haskell
А>2. C++
А>3. VBA

Это лично твои проблемы. И это не значит, что по другому быть не может. Просто ты выбрал языки которые плохо подходят для некоторых областей применения. С++ слишком низкоуровневый. Разработака на нем медленна и чревата ошибками. Плюс он не поддерживает компонентую модель (без подпорок вроде КОМ-а). За то он позволяет получить высокую скорость кода. Хаскель способствует порождению тормозного кода, плох в отладке и итеропе. VBA вообще ублюдок работающий только внутри некоторых приложений МС Офиса.

Но есть скажем C# или Nemerle. Что бы кто о них не говорил, но они позволяют получать быстрый код, вести разработку быстро и просто, отлично поддерживают компонентую разработку и обладают отменным итеропом. Последний ко всему прочему спокойно посоревнуются с Хаскелем в области выразительности в любых областях.

А>При этом каждый был на *СВОЕМ* месте.

В прошлом веке я тоже использовал тондем C++ и VB для ускорения разработки. VB служил клеем и высокоуровенвым средством разработки GUI, а на С++ писались КОМ-объекты выполняющие сложные задачи. Вот только с появлением дотнета и C#-а такой подход себя изжил, так как использовать один язык значительно проще, а C# позволял с легкостью обходиться без С++ и при этом его было легко использовать так же как VB.

А>Но вы, как я понял, обитаете в какой-то своей вселенной.

Это ты точно подметил. Она называется — реальный мир.
В этом мире лучим признается то решение которое приводит к желаемому результату при минимуме физических/умственных затрат.

Здравствуйте, <Аноним>, Вы писали:

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

А>Это у Вас глюки. С таким же успехом можно утверждать, что энергичность по умолчанию вынуждает быть чистым. Чистым хорошо быть ВСЕГДА. Просто к запаху императивной помойки Вы привыкли и он уже не шибает.

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

Следующее сообщение пдобоного рода (флуд с наездами) буду безжалостно вырезать. Особенно от лица анонимов.

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

VD>Это лично твои проблемы. И это не значит, что по другому быть не может. Просто ты выбрал языки которые плохо подходят для некоторых областей применения. С++ слишком низкоуровневый. Разработака на нем медленна и чревата ошибками. Плюс он не поддерживает компонентую модель (без подпорок вроде КОМ-а). За то он позволяет получить высокую скорость кода. Хаскель способствует порождению тормозного кода, плох в отладке и итеропе. VBA вообще ублюдок работающий только внутри некоторых приложений МС Офиса.

Это мне напоминает анекдот про Бернарда Шоу и Айседору Дункан: "а что, если он будет красив как я и умен как Вы ?". Вам не приходило в голову, что C++ я использовал там, где нужна скорость и низкоуровневое взаимодействие, Haskell — нетривиальная логика, а VBA — именно с целью использовать все это из "некоторых приложений МС Офиса"?

VD>Но есть скажем C# или Nemerle. Что бы кто о них не говорил, но они позволяют получать быстрый код, вести разработку быстро и просто, отлично поддерживают компонентую разработку и обладают отменным итеропом. Последний ко всему прочему спокойно посоревнуются с Хаскелем в области выразительности в любых областях.

Если я правильно понял, Вы повсеместно используете Nemerle для создания коммерческих приложений? Если не секрет — в какой области? И что именно Вы делаете на Nemerle?

Для меня это звучит совершенно удивительно. Я помню, как в стародавние времена на разные haskell-related mailing lists начали регулярно ходить какие-то люди, собиравшиеся писать Nemerle. Они задавали массу вопросов. Получая ответы, они писали — "это мы делать не будем, то мы делать не будем" и, в конце концов, пропали. Мне до сих пор не известно *НИ ОДНОГО СКОЛЬКО-НИБУДЬ ПРИМЕЧАТЕЛЬНОГО* приложения на Nemerle. Может, я не знаю, где искать? Укажите, пожалуйста. Я вообще всегда был сторонником развитых метасредств, поэтому априорно не испытываю к Nemerle никакой неприязни. Но я не в состоянии найти *НИ ОДНОГО* нетривиального приложения, на нем написанного. Вы скажете — компилятор? Но здесь речь вовсе не идет о компиляторах, ибо, если б речь шла о них, то никому и в голову бы не пришлось отвергать Haskell, который для писания компиляторов приспособлен идеально.

Так что же?

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

VD>Так, пошла демагогия с элементами оскоблений. Если нечего сказать по теме то можно просто промолчать.

VD>Следующее сообщение пдобоного рода (флуд с наездами) буду безжалостно вырезать. Особенно от лица анонимов.

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

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

Если ваш рост > 2 метров — вам нечего делать в кабине истребителя, но возможно стоит попробовать себя на баскетбольной площадке. Вы критикуете Haskell, но на вопрос "с какой точки зрения" заявляете, типа, "ничего объяснять не обязан ... немерле... вырезать.. москвошвея..."

Здравствуйте, <Аноним>, Вы писали:

А>Это мне напоминает анекдот про Бернарда Шоу и Айседору Дункан: "а что, если он будет красив как я и умен как Вы ?". Вам не приходило в голову, что C++ я использовал там, где нужна скорость и низкоуровневое взаимодействие, Haskell — нетривиальная логика, а VBA — именно с целью использовать все это из "некоторых приложений МС Офиса"?

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

А>Если я правильно понял, Вы повсеместно используете Nemerle для создания коммерческих приложений? Если не секрет — в какой области? И что именно Вы делаете на Nemerle?

В данный момент работаем над интеграцией Nemerle и VS 2005

Автор(ы):

. Плюс над самим компилятором.


А>Для меня это звучит совершенно удивительно.

Бывает. Жизнь вообще прекрасна и удивительна.

А> Я помню, как в стародавние времена на разные haskell-related mailing lists начали регулярно ходить какие-то люди, собиравшиеся писать Nemerle. Они задавали массу вопросов.

Это интересная информация. Если будут ссылки, то будет еще интереснее.

А> Получая ответы, они писали — "это мы делать не будем, то мы делать не будем"

Интересно, что конкретно?

А>и, в конце концов, пропали.

Видимо они почерпнули то что им было нужно.

А> Мне до сих пор не известно *НИ ОДНОГО СКОЛЬКО-НИБУДЬ ПРИМЕЧАТЕЛЬНОГО* приложения на Nemerle.

<офтоп>
Зачем же кричать? Тебе еще не говорили, что КРИЧАТЬ НЕКРАСИВО?

Мы же не в древней конфе. Здесь для выражения своих мыслей, и для их подчеркивания есть прличный инструменты форматирования.
</офтоп>

А> Может, я не знаю, где искать?

Я бы начал здесь:
http://nemerle.org/svn/nemerle/trunk
http://nemerle.org/svn/vs-plugin/trunk
Два очень довольно примечательных проекта.

А> Укажите, пожалуйста. Я вообще всегда был сторонником развитых метасредств, поэтому априорно не испытываю к Nemerle никакой неприязни. Но я не в состоянии найти *НИ ОДНОГО* нетривиального приложения, на нем написанного. Вы скажете — компилятор?

А что компилятор столь не простого языка — это тривильно? Ну, тогда тебе не составит написать его на Хаскеле в качестве развлекалова на вечер?

А> Но здесь речь вовсе не идет о компиляторах, ибо, если б речь шла о них, то никому и в голову бы не пришлось отвергать Haskell, который для писания компиляторов приспособлен идеально.

Ни чем не идеальнее чем тот же Nrmerle или даже O'Caml. Как минимум Haskell не иделен с точки зрения производительности получаемого решения.

А>Так что же?

Если чесно, то все что угодно. Я честно говоря с трудом найду задачи которые будут решаться на нем плохо. Конечно он не применим для задач где кровь из носу требуется отсуствие рантайма (нужен нэйтив-код). И так же в нем нет некоторых фрэйворков/решений вроде легких программно-изолированных процессов Эрланга/Сингулярити. Но все это уже не недостаток зыка, а отсуствие фрэйворков которые как раз этому языку очень даже по зубам.

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

Я согласен с Гапертоном, что любое повышение уровня косвенности вредит решению. Однако я так же согласен, что иногда без повышения уровня косвенности невозможно решать задачи изящнь и (как это не смешно звучит) просто. При этом разумным решением является заворачивание сложных вещей в обертки срывающие эти сложности. И прдоставлении пользователям конечных решений. Причем все это должно быть прозрачно для пользователей. Они не должны мучиться с выводом данных в лог или использованием императивного алгоритма. Они просто должны получить нужный им инструмент. Вот это я вижу в Немерле и не вижу в Хаскеле.

Ты задашся вопросом какие приложения есть на Немреле? Но почему перед этом ты не задашся вопросом какие приложения есть на Хаскеле?
Немерле можно сказать еще не родился, но на нем уже пишут довольно сложные приложения. И дальше будет тлько больше. Лично мы собираемся переписать на Немерле этот вот сайт. А вот чего добился Хаскель за это время? На мой взгляд он отлично продемнострировал несколько концепций. Причем некоторе из них довольно спорны. Другими словами он является отличныи исследованием, много давшим компьютерной науке. Классы типов лично мне очень понравились. Ленивость по умолчанию тоже весьма интересный эксперемент (но по-моему не продемонстрировавших особых преимуществ). В общем, Хаскель это очень интересно и здорово, но не для реальной жизни.

Здравствуйте, <Аноним>, Вы писали:

А>Мне, откровенно говоря, было лень заниматься вопросами регистрации,

Это минута от силы.

А> тем более, что я не уверен стоит ли оно того.

Ну, раз принимаешь участие в дисскусси, значит оно тебе надо.

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

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

А>Если ваш рост > 2 метров — вам нечего делать в кабине истребителя, но возможно стоит попробовать себя на баскетбольной площадке. Вы критикуете Haskell, но на вопрос "с какой точки зрения" заявляете, типа, "ничего объяснять не обязан ... немерле... вырезать.. москвошвея..."

Ну, лично я не говорил, что обяснять не обязан. Но я понимаю Гапертона. Он довольно недвусмысленно описал зачем он пробовал применять Хаскель в своей работе. И когда после довльно долгого рассказа

Автор: Gaperton
Дата: 26.02.07

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

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

На мой взгяд эти решения делают язык менее приспособленным к жизни. Отсюда и потребность в VB и С++. Если бы Хаскель не имел проблем, то тебе вряд ли потребовались бы другие универсльные ЯП общего назначения коими являются С++ и Васик. И если Васик еще можно использовть хотя бы потому, что он встрен в Опис и запись макросов ведется именно на нем, то потребность в С++ говорит тольк об одном — о наличии недостатков у твоего любимого ЯП. И что-то мне опдсказывает, что недостатки эти в основном проистекают как раз из-за выбора авторами Хаскеля данных дизайнерских решений.

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

VD>Ну, лично я не говорил, что обяснять не обязан. Но я понимаю Гапертона. Он довольно недвусмысленно описал зачем он пробовал применять Хаскель в своей работе. И когда после довльно долгого рассказа

Автор: Gaperton
Дата: 26.02.07

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

Да нет же. Это никак не проясняет где и зачем он пытался применить Хаскелл. Потому и спросил.

VD>На мой взгяд эти решения делают язык менее приспособленным к жизни. Отсюда и потребность в VB и С++. Если бы Хаскель не имел проблем, то тебе вряд ли потребовались бы другие универсльные ЯП общего назначения коими являются С++ и Васик. И если Васик еще можно использовть хотя бы потому, что он встрен в Опис и запись макросов ведется именно на нем, то потребность в С++ говорит только об одном — о наличии недостатков у твоего любимого ЯП. И что-то мне опдсказывает, что недостатки эти в основном проистекают как раз из-за выбора авторами Хаскеля данных дизайнерских решений.

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

Но в любом случае, я должен задействовать кучу разных API. Если они сразу C-compatible — я могу использовать их напрямую, но во всех остальных случаях мне нужно делать переходники. Здесь нет ничего сложного. Например, COM я могу звать и через dispatch, если оно есть, или через vtables — для этого у меня есть кодогенераторы. Это давно отлажено и работает.

Тем не менее, C++ я использовал и буду использовать, поскольку в критических местах это:
1. дает мне предельную производительность;
2. легко интегрируется с основным решением (на Хаскелле).

Почему я использовал VBA — у меня не было фреймворка для отлова событий. Сейчас он есть, и VBA, в принципе, мне не нужен. Без него я уже обхожусь, даже в тех приложениях, что хостятся в MS Office.

Здравствуйте, <Аноним>, Вы писали:

А>Да нет же. Это никак не проясняет где и зачем он пытался применить Хаскелл. Потому и спросил.

Он же сказал, что создавали систему эмуляции процессора MIPS и интеллектуального контроллера памяти.

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

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

А>Но в любом случае, я должен задействовать кучу разных API. Если они сразу C-compatible — я могу использовать их напрямую, но во всех остальных случаях мне нужно делать переходники. Здесь нет ничего сложного. Например, COM я могу звать и через dispatch, если оно есть, или через vtables — для этого у меня есть кодогенераторы. Это давно отлажено и работает.

Но это опять же сложности. Хотя это уже неудобствно реализации интеропа. Что немного дургая тема.

А>Тем не менее, C++ я использовал и буду использовать, поскольку в критических местах это:
А>1. дает мне предельную производительность;
А>2. легко интегрируется с основным решением (на Хаскелле).

Это и есть доказательство проблем Хаскеля вызванных как раз тем о чем мы говорим.
Лично мне не нужен С++ вот уже 6 лет. Я добиваюсь такой же производительности без него.

А>Почему я использовал VBA — у меня не было фреймворка для отлова событий. Сейчас он есть, и VBA, в принципе, мне не нужен. Без него я уже обхожусь, даже в тех приложениях, что хостятся в MS Office.

Значит эта проблема была вызвана отсуствием фрэйворка/библотеки и по сути не была принципиальной. В случае С++ все совсем не так. Тут проблема принципиальная. И тут Хаскель всегда будет нуждаться в подпорках.

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

VD>Он же сказал, что создавали систему эмуляции процессора MIPS и интеллектуального контроллера памяти.
Это я видел. Он там упоминал potan'a, Зефирова и еще неизвестно кого. Но никаких указаний, что там Хаскелл повредил — не было. Более того, была фраза, что проект успешно завершился.

VD>Это не соответствует словам что ты говорил. Ты утверждал, что применяешь языки для решения конкретных задач. Если речь идет только о легаси, то это другой разговор. Вот только не очень верится, что на Хаскеле можно создать сложное современное решение не прибегая к другим языкам.
VD>Но это опять же сложности. Хотя это уже неудобствно реализации интеропа. Что немного дургая тема.
VD>Это и есть доказательство проблем Хаскеля вызванных как раз тем о чем мы говорим.
VD>Лично мне не нужен С++ вот уже 6 лет. Я добиваюсь такой же производительности без него.
VD>Значит эта проблема была вызвана отсуствием фрэйворка/библотеки и по сути не была принципиальной. В случае С++ все совсем не так. Тут проблема принципиальная. И тут Хаскель всегда будет нуждаться в подпорках.

Дело не в legacy. Попробуй перевернуть логику. Можно было бы делать все только на C/C++. Отчего нет? Все вполне заслуженно. Десятки миллионов строк кода. 90% того, что у тебя на столе, написано на C/C++ — это железобетонная реальность. Уж всяко не чета любым Жаба/Nemerle/whatever.

И здесь оказывается, что:
1. Хаскелл рулит;
2. Хаскелл прекрасно интегрируется со всем этим.

Что не так???

Тут все ругают интероп. Кто-нибудь может внятно сформулировать — что не нравится ??? Я этот вопрос уже во всех (sub)ветках задаю — нет ответа.

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

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

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

AndreiF wrote:
> Значит, надо просто иметь возможность помечать функцию как "чистую". И
> не будет никакого расползания грязи.
Gaperton уже предложил спереть "const" из C++

Здравствуйте, Аноним, Вы писали:

А>Но вы, как я понял, обитаете в какой-то своей вселенной.

Есть такой мир. Там каждый уважающий себя маг должен знать Истинный Язык. А великого знатока ИЯ звали Неммерль.

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

C>Gaperton уже предложил спереть "const" из C++

Правильная мысль

Здравствуйте, Аноним, Вы писали:

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

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

А>Это у Вас глюки. С таким же успехом можно утверждать, что энергичность по умолчанию вынуждает быть чистым. Чистым хорошо быть ВСЕГДА. Просто к запаху императивной помойки Вы привыкли и он уже не шибает.

Цитата из Tackling the Awkward Squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell от Simon Peyton Jones :

The bottom line is that laziness and side effects are, from a practical point of view, incompatible.
If you want to use a lazy language, it pretty much has to be a purely functional language; if you
want to use side effects, you had better use a strict language.

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

К>Цитата из Tackling the Awkward Squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell от Simon Peyton Jones :
К>

К>The bottom line is that laziness and side effects are, from a practical point of view, incompatible.
К>If you want to use a lazy language, it pretty much has to be a purely functional language; if you
К>want to use side effects, you had better use a strict language.

Я, грубо говоря, писал то же самое. "better use a strict language" не потому, что устраняет помойку, а потому, что к этой помойке уже привыкли и более-менее знают где что лежит.

Здравствуйте, Аноним, Вы писали:

А>Я, грубо говоря, писал то же самое. "better use a strict language" не потому, что устраняет помойку, а потому, что к этой помойке уже привыкли и более-менее знают где что лежит.

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

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

К>Здравствуйте, Аноним, Вы писали:

А>>Я, грубо говоря, писал то же самое. "better use a strict language" не потому, что устраняет помойку, а потому, что к этой помойке уже привыкли и более-менее знают где что лежит.

К>Вопрос заключается в том, что ты это называешь (+ грубо) просто "привыкли", а люди говорят, что на реальных примерах применения lazy-подход оказался не очень выгодным. Противоположных примеров пока не озвучено

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

Все как само собой разумеющееся пишут, что, мол, ленивость требует чистоты, не понимая, что строгость требует чистоты ничуть не меньше.

Я Вам больше скажу. Вы даже не сможете точно определить ленивость и строгость в impure случае. Потому что для него нет сколько-нибудь внятных теорий. Остаются одни разговоры. Типа, "функция обязательно вычисляет все аргументы", но в impure случае строго не определено, ни что такое "функция" ни что такое "вычисляет".