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

V> А сколько сравнений сделает Хаскель для последнего варианта в первоначальном коде? 12? Так может, это не столько Хаскель тормозит, сколько программисты на нём?
V> Сорри, если кого-то задел в "пылу боя", но ты бы сам взглянул на генерируемый бинарный код приведённого примера, для начала.
Мне не нужно, спасибо. И я не програмист на Хаскеле(хотя не зарекаюсь), и не был задет. Я просто взглянул на эти "12" и понял что вы даже не слышали о том, что паттерн матчинг компилируют. А если вы не слышали об этом, то наверное считали, что програмисты на Haskell (SML, OCAML, Nemerle, Scala) такие тупые(и ленивые!), что вместо того, чтобы взять бумажку (как вы), и откомпилировать на ней (как вы) — они лепят везде этот страшно неэффективный код с M*N сравнений.

У меня тут в кустах, случайно стоит рояль — правда с динамической типизацией — придется руками дооптимизировать:

С точки зрения компиляции ПМ, 'balin' аналогичен:

-- типа Lua
local Just, Nothing, TypeError = 'Just', 'Nothing', 'TypeError'

local fun mock_balin
  | (Just|Nothing),Just,Just       -> 111
  | Just,Nothing,Just              -> 222
  | Just,Just,Nothing              -> 333
  | (Just|Nothing),Nothing,Nothing -> 444
  | (Just|Nothing),(Just|Nothing),Nothing        -> 555
  | (Just|Nothing),(Just|Nothing),(Just|Nothing) -> 666
  | _,_,_ -> TypeError
end

Компилятор (не знающий о статической типизации и алгебраических типах) выдаст нам:

local function mock_balin(_u0,_u1,_u2)
  if _u0 == Just then
    if _u1 == Just then
      if _u2 == Just then return 111
      else
        if _u2 == Nothing then return 333 else return TypeError end;
      end;
    else
      if _u1 == Nothing then
        if _u2 == Just then return 222
        else
          if _u2 == Nothing then return 444 else return TypeError end;
        end;
      else return TypeError
      end;
    end;
  else
    if _u0 == Nothing then
      if _u1 == Just then
        if _u2 == Just then return 111
        else
          if _u2 == Nothing then return 555 else return TypeError end;
        end;
      else
        if _u1 == Nothing then
          if _u2 == Nothing then return 444
          else if _u2 == Just then return 666 else return TypeError end;
          end;
        else return TypeError
        end;
      end;
    else return TypeError
    end;
  end;
end;

Теперь нам нужно выкинуть все ветки с 'TypeError'(статическая типизация) и обратить внимание на то, что тег либо Just либо Nothing и второй тест не нужен (type span optimization):

local function mock_balin2(tag1,tag2,tag3)
  if tag1 == Just then
    if tag2 == Just then 
      if tag3 == Just then return 111 else return 333 end
    else --// tag2 == Nothing
      if tag3 == Just then return 222 else return 444 end
    end
  else --// tag1 == Nothing
    if tag2 == Just then
      if tag3 == Just then return 111 else return 555 end
    else --// tag2 == Nothing
      if tag3 == Nothing then return 444 else return 666 end
    end
  end
end

Вот и все, обращаем внимание на то, что все правые части сохранились — значит исходный код не был избыточным. Хороший компилятор перепишет это как case и сделает hash-consing для экономии места.

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

L>Мужики, вы о разном говорите. Да, Haskell тоже не помешают некоторые инструменты. Да, некоторые из финтифлюшек IDEA — костыли, следствие низкого уровня Java.
Да я не спорю. Java по уровню не сильно лучше какого-нибудь VisualBasic'а версии 6. Разве что синтаксис поприятнее.

Однако, эта примитивность оборачивается тем, что возможна поддержка со стороны IDE. ИМХО, будет дальнейшая миграция в этом направлении, прям до идеального коммунистического будещего с единым народом и партией.

C>>Я не думаю, что это было бы возможно в каком-либо DSLе. Даже в Haskell'е.
L>Ну как. Если хост-язык у нас один, то у нас уже есть его поддержка и не надо на каждый чих (dsel) писать новую.
Не получится.

Скажем, во многих случаях требуется работа с внешними ресурсами. Например, IDEA мне подсветит, если у меня в запросе есть неизвестная табличка (в схеме БД её нет), или если в JS в JQuery используется неизвестный CSS-класс.

C>>Сейчас следующим языком, который я буду использовать после Питона и Java станет, скорее всего, Scala. Слишком избалован я нормальными IDE.
L>Я постепенно прихожу к выводу, что Scala возникла тоже из-за низкого уровня Java
Да.

L>А это не та причина, по которой надо создавать новый язык, IMHO. А то получится Scala — монстр типа С++. Язык с набором несвязанных фич вместо языка с фичами, уложенными в некую систему. Хотя, вполне допускаю, что я пока просто эту систему не вижу.
Почему? JVM — это вполне нормальная среда для языков. Разве что систему типов нормально без erasure не сделать

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

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

Ну, как тебе сказать.

Вот в игростроении, например. Делал всё, как все остальные: DirectX прямо в коде, без всякой обвязки. Так у меня на две тысячи строк кода взрывов было всего порядка пяти или шести вызовов D3D — DrawIndexPrimitive и установка параметров шейдеров. Да, я использовал уже написанный collision detection и выборку по миру. Так это был нами написанный код.

E>Вот в моем проекте, которым я занимаюсь последние несколько лет, порядка 100K строк прикладного кода. Самые большие из задействованных в нем библиотек -- ACE (330K строк), SObjectizer (50K), ObjESSty (60K). Не считая того кода, который спрятан в ODBC, реляционных БД, http-серверах.

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

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

Стиль кодирования защищает от слишком накладных возможностей языка. Обвязка вокруг библиотеки защищает от её полного знания и понимания. Да ещё даёт возможность более быстрого переноса.

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

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

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

T>Ну, как тебе сказать.

T>Вот в игростроении, например. Делал всё, как все остальные: DirectX прямо в коде, без всякой обвязки. Так у меня на две тысячи строк кода взрывов было всего порядка пяти или шести вызовов D3D — DrawIndexPrimitive и установка параметров шейдеров. Да, я использовал уже написанный collision detection и выборку по миру. Так это был нами написанный код.

Собственно, об этом и речь, что предметная область довольно специфическая. Как в свое время АСУТП была -- народ писал сам все, начиная от драйверов устройств и заканчивая рисованием исторических трендов. Затем, постепенно, развились SCADA системы и некоторые классы информационно-измерительных систем стали решаться на раз, с помощью только визуального программирования.

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

E>>Вот в моем проекте, которым я занимаюсь последние несколько лет, порядка 100K строк прикладного кода. Самые большие из задействованных в нем библиотек -- ACE (330K строк), SObjectizer (50K), ObjESSty (60K). Не считая того кода, который спрятан в ODBC, реляционных БД, http-серверах.

T>Теперь посчитай возможности этих библиотек, которые ты действительно используешь и прикинь, насколько их объём можно сократить. С учётом стиля вашего кодирования, поскольку, как я понимаю, вы используете Java и некоторые из этих библиотек вынуждены поддерживать её целиком.

С++ используем.

T>Библиотеки — это те же самые языки программирования. Их возможности используются процентов на 10, хорошо если так много. Просто разным людям нужны разные возможности, вот и пестрота с объёмом наперевес.

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

T>И в заключении: деньги платят за решение проблем, которые никто ещё не решал. Не решённые проблемы не существуют в виде библиотек. Уже существующими библиотеками можно только облегчить свою судьбу, но не уйти от неё совсем.

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

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

C>Скажем, во многих случаях требуется работа с внешними ресурсами. Например, IDEA мне подсветит, если у меня в запросе есть неизвестная табличка (в схеме БД её нет), или если в JS в JQuery используется неизвестный CSS-класс.

Ну раз хост язык у нас один, то эти таблички и css (вернее их описания) у нас в языке же. Нет таблички или класса — программа не скомпилируется.

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

C>>Скажем, во многих случаях требуется работа с внешними ресурсами. Например, IDEA мне подсветит, если у меня в запросе есть неизвестная табличка (в схеме БД её нет), или если в JS в JQuery используется неизвестный CSS-класс.
L>Ну раз хост язык у нас один, то эти таблички и css (вернее их описания) у нас в языке же. Нет таблички или класса — программа не скомпилируется.
Т.е. мне нужно будет создать DSL для:
1) HTML
2) CSS
3) SQL (в разных диалектах)
4) JavaScript
5) Регэкспы (в том числе перловые)
6) .....

Причём нужно создать почти идеально совместимый по синтаксису DSL, так как в браузеры у нас пока Haskell не встроен. В общем, задача очень быстро станет наааааамного сложнее написания модуля для IDEA.

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

C>Причём нужно создать почти идеально совместимый по синтаксису DSL, так как в браузеры у нас пока Haskell не встроен. В общем, задача очень быстро станет наааааамного сложнее написания модуля для IDEA.

Почему? Не понял, если честно. Писать injected language сложнее, чем DSeL, а т.к. кол-во первых должно быть равно кол-во второго, то непонятно откуда растёт сложность?

Во-вторых, я не призываю писать тебя dsl для css. Речь вообще не об этом. Началось с чего? Ты сказал, что то, что может injected language — не может eDSL. Я не понял почему (ведь для хоста-языка у нас уже всё есть) и переспросил.

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

C>>Причём нужно создать почти идеально совместимый по синтаксису DSL, так как в браузеры у нас пока Haskell не встроен. В общем, задача очень быстро станет наааааамного сложнее написания модуля для IDEA.
L>Почему? Не понял, если честно.
Не, ну тебе нужно будет повторить весь HTML, CSS и JS в виде DSL.

L>Писать injected language сложнее, чем DSeL, а т.к. кол-во первых должно быть равно кол-во второго, то непонятно откуда растёт сложность?
...кстати, а сложнее ли?...

Смысл в том, что для Injected-языка я могу использовать ЛЮБОЙ парсер, в том числе и интеллектуальный, пропускающий плохие куски, могу использовать ЛЮБОЕ промежуточное представление и т.д.

Ну и вопросы с рефакторингом остаются.

L>Во-вторых, я не призываю писать тебя dsl для css. Речь вообще не об этом. Началось с чего? Ты сказал, что то, что может injected language — не может eDSL.
Ну вот я и объясняю.

L>Я не понял почему (ведь для хоста-языка у нас уже всё есть) и переспросил.
Не верно. Для хост-языка может быть есть парсеры, но это O-малое для качественного DSL.

C>Просто недавно заметил — если писать на Питоне, то кода где-то раза в два меньше, чем на Java получается. Но только пишется он где-то раза в два медленнее.

Это странно. При всех своих недостатках, питон все же выше уровнем чем жаб... джава раза эдак в четыре.

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

C>>Просто недавно заметил — если писать на Питоне, то кода где-то раза в два меньше, чем на Java получается. Но только пишется он где-то раза в два медленнее.
dmz>Это странно. При всех своих недостатках, питон все же выше уровнем чем жаб... джава раза эдак в четыре.
Чем выше? Ну есть у него list comprehensions и прочие вкусности. Из-за этого и получается код меньше.

Зато в Java у меня есть умный автокомплит и средства генерации кода, которые сглаживают разницу в объёме.

dmz>>Это странно. При всех своих недостатках, питон все же выше уровнем чем жаб... джава раза эдак в четыре.
C>Чем выше? Ну есть у него list comprehensions и прочие вкусности. Из-за этого и получается код меньше.

Я как-то не могу сходу сформулировать, но Java — это вообще низкоуровневый язык, примерно как C++, более того, если мне не изменяет память, местами C++ даже имеет какие-то полезные штуки, которых в Java не было. Так что быть уровнем выше Java — вообще не штука.

Ну вот теже list comprehensions. lambda. Декораторы. Перегружаемые операторы. Доступ к собственному AST. Богатая стандартная библиотека. Вроде все мелочи, но вот так и набегает.

C>Зато в Java у меня есть умный автокомплит и средства генерации кода, которые сглаживают разницу в объёме.

Черт его знает. Автокомпилит за тебя код писать не будет. "Средства генерации кода" вроде должны, но если их есть и они такие удобные, зачем тогда умный автокомплит — написал немного кода, и он сгенерил тебе МНОГО кода. А когда кода мало, так что можно глазом охватить — то вроде как и умный автокомплит не нужен. В частности, зачем он тебе нужен для SQL, если этот SQL генерится из представления твоих данных и идеологии работы с ними
и ты в глаза его не видишь, этот SQL?

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

Опять же, о скорости набора. Нажал, подождал, выбрал из из списка. Который еще придется листать и смотреть. Это что, быстрее, чем просто написать ?

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

dmz>Я как-то не могу сходу сформулировать, но Java — это вообще низкоуровневый язык, примерно как C++, более того, если мне не изменяет память, местами C++ даже имеет какие-то полезные штуки, которых в Java не было. Так что быть уровнем выше Java — вообще не штука.
Ага.

dmz>Ну вот теже list comprehensions. lambda. Декораторы. Перегружаемые операторы. Доступ к собственному AST. Богатая стандартная библиотека. Вроде все мелочи, но вот так и набегает.
Ну и? Ну декораторы и лямбда. Что дальше? Они нужны бывают не на каждой строке кода, а уж по библиотекам Java ничуть не хуже.

C>>Зато в Java у меня есть умный автокомплит и средства генерации кода, которые сглаживают разницу в объёме.
dmz>Черт его знает. Автокомпилит за тебя код писать не будет.
Он сейчас такой умный, что даже иногда и пишет

dmz>"Средства генерации кода" вроде должны, но если их есть и они такие удобные, зачем тогда умный автокомплит — написал немного кода, и он сгенерил тебе МНОГО кода. А когда кода мало, так что можно глазом охватить — то вроде как и умный автокомплит не нужен. В частности, зачем он тебе нужен для SQL, если этот SQL генерится из представления твоих данных и идеологии работы с ними
Там немного другое. В Java нельзя общим образом организовать hashCode/equals методы. Но в IDE я могу сделать их парой нажатий клавиш.

dmz>Вообще, по моему, автокомплит больше относится к скорости набора кода — т.е. при нормальном раскладе все это "о малое" от времени думания. Если язык такой, что думать приходиться мало, а набивать много — то это какой-то неправильный язык.
А ещё средства рефакторинга. Например, я люблю переменные переименовывать. В Питоне — это полный упс.

dmz>Опять же, о скорости набора. Нажал, подождал, выбрал из из списка. Который еще придется листать и смотреть. Это что, быстрее, чем просто написать ?
Ну вот видишь, ты автокомплитом в IDEA не пользовался.

C>>>Зато в Java у меня есть умный автокомплит и средства генерации кода, которые сглаживают разницу в объёме.
dmz>>Черт его знает. Автокомпилит за тебя код писать не будет.
C>Он сейчас такой умный, что даже иногда и пишет

Есть мнение, что он пишет только такое (и так) что лучше было бы это не писать вообще.

C>Ну вот видишь, ты автокомплитом в IDEA не пользовался.

Вы все такие загадочные... Хоть расскажите словами (и примерами), про зияющие высоты, которых мы не замечаем. Может придется забить на все и перелезть на Java.

Да в общем, немного пользовался. Давно. Я помню, оно там по фрагменту зуба (кусок названия типа переменной что ле) генерило все животное целиком:

MyCool<хоткей> - втыкаем в меню - еще пара нажатий на клавиши ->

MyCoolType myCoolType = new MyCoolType(...)

В этой строке лишнего чуть меньше, чем всё.

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

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

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

Все эти действия можно обозначить некими символами, например:

^, X, ->, <-

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

Если эти рассуждения верны (а вроде они достаточно очевидны), то очевидные недостатки тут таковы:

Язык (типичный брейнфак получился) — невербальный (это фактически язык жестов) и не само-объясняемый.

Программа на этом языке обладает побочными эффектами, т.е. результат меняется в зависимости от контекста (который включает состояние мозга)
и вообще оно интерактивно — т.е. требует участия человека.

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

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

А подход с хоткеями — это такой DSL, выход которого потом надо ковырять и поддерживать. Т.е. вся эта мегадопечатка повышает уровень языка только в смысле одноразового написания кода, но сам-то код потом надо тестировать, поддерживать и т.п. При этом, если мы написали мало кода (функцию высшего порядка) — то она всегда работает тем образом, которым она определена и поддерживать нам надо только ее. А вот код, который нагенерился нашими хоткеями, требует индивидуального подхода — т.е. если у нас сгенерился кусок кода A, про который мы знаем, что он работает правильно, то про сгенеренный похожим (но не идентичным! идентичным он быть не может) образом кусок кода B — мы ничего сказать не можем. Короче говоря, это все раздувает код. Больше кода — больше ошибок. Ну ее нахрен, такую "высокоуровневость".

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


T>Ну, возможно, видел. Но ведешь себя так, как будто не видел. В голове у тебя не отложилось, как это можно использовать.

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

V>>Очень редкое нефункциональное требование, из области забавного. (да, ты приводил уже ссылку)
V>>Абсолютно не применимо, когда логика алгоритма зависит от входных данных — а это большинство сценариев в современных бизнес-приложениях.

T>Круто!
T>Совсем-совсем не применимо? Даже пытаться не стоит?

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


T>Все косяки в esimp, что ты увидел, существовали только в твоих глазах, дорогой товарищ.

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


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

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


T>В случае исключительно высокой скорости надёжного распространения знаний мы можем уже первую версию выпустить качественно, если мы осознали наше непонимание.

Да-да, компилятор за нас всё напишет... Это я уже слышал, но ни разу еще не видел (хотя вплотную занялся исходниками Хаскеля — и там не вижу тоже).

А если это область обработки сигналов или ИИ, суть числомолотилка, умножение векторов и т.д? Оно что в ООП, что в твоём ФП даже записывается примерно одинаково. На обоих ЯП в алгоритмах можно наделать косяков, о которых компилятор и знать не будет — будет честно компилить подсунутые расчёты, которые туфтой и являются.

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

В общем, ты очень много пишешь, но мало приводишь примеров. Из тех, что приводил — не для демонстрации основного твоего посыла "невозможно накосячить", из-за чего собственно и разгорелось у нас. Хотим хлеба и зрелищ. Покажи нам подтверждение своих слов.


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

T>О! "Плоское пространство имён".

T>import qualified Data.Map
T>import qualified Data.Map as Map
T>-- или import qualified Data.IntMap as Map

Где ты увидел вопрос про "плоское пространство имён"? Похоже, ты не отличаешь "область видимости" от "уровня доступа/видимости".

T>Ты, уж, ознакомься с критикуемым-то. Вся информация в интернете есть.
T>А то мне скоро наскучит мириться с твоим тиражированием идиотизма.

Хамишь, парниша... Это помимо того, что опять бросаешься отвечать, не понимая сути вопроса. Даю еще одну попытку.


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

T>Ты уж извини, но библиотеки не могут быть написаны на все случаи жизни.

T>Например, Java и .Net до сих пор не имеют библиотеки моделирования систем на дискретных событиях.

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

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

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

Кстати, интересная мысль в голову пришла. Вот у нас есть некий направленный граф. Есть 2 распространённых способа моделирования направленного графа:
— отдельно список вершин и отдельно список дуг, дуга при этом содержит обе вершины;
— список исходящих дуг принадлежит узлу, дуга при этом содержит только конечную вершину.

Как на Хаскеле зациклить этот граф во втором случае?


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

Это смотря где больше:

using(Stream s = File.OpenStream(path))
  return EDIParser.Parse(s);

В любом случае, пример неудачный. Огромная часть бизнес задач сегодня — это распределённые системы, веб-морды, данные в СУБД (метаданные тоже), насраиваемое логгирование и т.д. и т.п., под небольшой прикладной логикой плавают целые айсберги тяжеловесного middleware.

T>Приведи пример.
T>Есть у меня подозрение, что функциональности там кот наплакал.

У меня есть подозрения, что даже одну вшивую, но интерактивную страничку, работающую с различными платёжными системами, и использующую со стороны сервера сразу несколько защищённых протоколов передачи и протоколов аутентификации, на Хаскеле долго и нудно ручками долбить надо будет, в отличие от .Net или Java, где это всё 2 пальца об асфальт.

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



T>Потому, что в случае популярности Хаскеля им начнёшь пользоваться ты. А меня это беспокоит.

Что именно беспокоит? И почему тебя беспокоит, чем занимаются люди в тысячах километров от тебя?


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

Странно, не помню "специальных" случаев для задачи оптимизации. Может, поделишься трудностями — подскажем как решить.

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

Очередной выпад типичного ФП-проповедника. Смысл как обычно: "все дураки".
Дык, у меня есть чудесный ответ: "сам дурак". Мы конкретный твой исходник обсуждаем, а не предполагаемые вербальные ограничения его использования. И ведь насколько мне позволяют судить мои познания в Хаскеле, в твой исходник можно подавать любые типы, для пары которых определена операция умножения "*". И уж тем более не понятно, почему ты явно не указал в контракте, что тип аргументов будет одинаков, раз того требует твой сценарий использования этого оптимизатора. А ведь этот косяк посильнее первого будет, не находишь? В общем, хреновый из тебя продавец ФП, будь ты в моей команде — был бы наруган за подобное разгильдяйство в контрактах. Так что, список мест, где тебе стоило бы взять свои слова обратно, неуклонно растёт.


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

Ну и какую?

T>Да в той задаче мне это просто не нужно было. И в той задаче отлично справился подход с алгебраическим представлением, вот и всё моё умное лицо.

Так это я неправильно мыслю об оптимизации вообще, или оно тебе в этом конкретном месте не очень надо было? У тебя с логикой вообще как?


T>>>Но это твои личные проблемы.
V>>Я так и понял, проехали. Если ФП не в состоянии "автоматом" исправлять ошибки логики, то это проблемы программиста, а не ЯП... ЧТД.

T>Оно может указывать на ошибки логики.

Я знаю, на какие ошибки логики оно может указывать. И вывод типов не только в Хаскеле есть, если помнишь. И логика не только на if или паттерн матчингах строится, сами вычисления — это тоже часть логики. Ты же всё время пытаешься меня убедить, что мы тут в основном совершаем ошибки того плана, который обязательно найдёт компилятор. Это заблуждение. Подавляющее большинство ошибок по моему опыту — это или высокоуровневые, т.е. ошибки той логики, которая компилятору недоступна, и связана с некорректным пониманием требований или (что гораздо чаще) с неполной их реализацией. Или же те описки, которые пропускает система типов компилятора.
Вот суть одного моего косяка из недавнего:

public bool SomeProp {
  set {
    if(value
      DoSomething();

    _value = false; // должно быть _value = value;
  }
}

Причём, то-ли глаз замылился, то ли что... Но даже при просмотре кода я эту описку упускал дважды, не мог понять, что за фигня (было подозрение на ошибку синхронизации и перезапись из другого потока). Типизация в порядке — компилятор себе компилит. Чистое ФП не предлагать, я бы и на Хаскеле тут State сделал бы, это один из атрибутов состояния активного соединения.

Или взять твой пример BallinF, там ведь в правой части каждой строки матчинга можно допустить описку/ошибку логики, которая прекрасно скомпилится. И где тут будет помощь компилятора?


T>Спасибо. Буду знать. А то не знал, что не знаю, теперь буду знать. Не думаю, что буду знать, что знаю, правда, но буду знать о своём незнании.
T>Самому-то не видно, что не знаешь.

Наплюй, просто в твоей манере решил абзац написать. Как оно смотрится со стороны, когда банальности за откровения выдаются, теперь представляешь.

V>>>>Maybe понятен, непонятен Just. Почему не так:
V>>>>

V>>>>data Maybe a = Nothing | a
V>>>>

...
T>Да, большое спасибо. Еще про одно своё незнание узнал.

Дык, на вопрос лучше не отвечать вообще, чем отвечать так, как ты там ответил.
Раз не смог объяснить, значит сам не знаешь. Как тебе такая логика?

T>Теперь я буду уверен, что отвечать "я не понял твоего вопроса" много лучше, чем отвечать, так и не поняв вопроса оппонента.

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


T>Слушай, вот эта картинка выдаёт уровень твоего внимания как нельзя лучше.

Да, надо заканчивать в 6 утра постить. Сделал правильно, кол-во сравнений у себя посчитал неправильно.


T>>>>>Стиль кодирования? Нет?
V>>>>Нет.
T>>>Почему?
V>>Потому что задачи разные бывают. Вот простая задача: кеш неких связанных данных, обслуживающий сетевые запросы, приходящие из разных потоков, требующий транзакционности выборок связанных данных. Уверен, что на Хаскеле это будут танцы с бубнами и куча лишних строк кода, по сравнению с mainstream-языками.

T>MVar
T>хгкд=http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-Chan.html]Chan[/url]
T>Software Transactional Memory.

T>Последнее только-только добирается до мейнстрима.
T>Ещё раз: предполагать самый плохо вариант ответа — не самая лучшая стратегия. Да и тактика тоже так себе.

Ладно, много раз порывался забросить этот театр абсурда, ибо кое-кто нить рассуждения постоянно теряет... Но мне пока кое-что надо увидеть (надеюсь этот бонус всё-таки будет). В общем, конкретно здесь речь шла о том (просто напоминаю), что я предположил, что на некоторых задачах ты всё-равно будешь использовать больше, чем упомянутые 10% возможностей. Я понимаю, что эти модули по приведённым тобой ссылкам сделал не ты лично, но зато ты имеешь возможность взглянуть в их исходники, сравнить кол-во использованных возможностей языка со своим "стилем кодирования" и, теперь восстановив нить обсуждения, сказать — удачный ли был мой пример в плане демонстрации того, что не только стиль кодирования определяет набор используемых языковых ср-в для решения задач, но иногда выход за эти 10% обуславливается характером самих задач.


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

T>Почему State monad уродство? Твоё личное предпочтение?

Обычное lvalue.

T>Типобезопасность в ленивых ФЯ достигается проще всех остальных. Все остальные системы сложнее. BitC, например — авторы сами признают, что задача у них очень мощная и почти неподъёмная.

Наверно ты хотел сказать — вывод типов в ленивых ФЯ достигается проще всех остальных. Однако, ты же можешь и явно типы специфицировать, начиная от примитивных, типа int (или как они там в Хаскель называются). И тогда ленивость/нелинивость будут до фени.

T>Всё, что может Фортресс, выражается в зависимых типах.

Хороший аргумент.
Это из разряда "всё, что могут делегаты C# выражается в библиотечном виде на С++".

T>Собственно, почему я на них так и сфокусирован: разобравшись с ЗТД, я получаю забесплатно и Фортресс, и Boo и практически всё, что смогу захотеть.

Это было бы так, если бы не странные ограничения name conventions (сдаётся мне, что это еще один из минусов для целей популяризации). C# и то отличает тип от ф-ии, не обладая такой системой вывода типов.

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

T>Увы, практика доказывает обратное.
T>Алгоритм W (Хиндли-Милнера) сперва доказали для чистого подмножества ML, а потом отдельно доказывали для ML со ссылками.

Насколько я понял, еще в конце 80-х все эти вещи произошли.

dmz>А подход с хоткеями — это такой DSL, выход которого потом надо ковырять и поддерживать. Т.е. вся эта мегадопечатка повышает уровень языка только в смысле одноразового написания кода, но сам-то код потом надо тестировать, поддерживать и т.п. При этом, если мы написали мало кода (функцию высшего порядка) — то она всегда работает тем образом, которым она определена и поддерживать нам надо только ее. А вот код, который нагенерился нашими хоткеями, требует индивидуального подхода — т.е. если у нас сгенерился кусок кода A, про который мы знаем, что он работает правильно, то про сгенеренный похожим (но не идентичным! идентичным он быть не может) образом кусок кода B — мы ничего сказать не можем. Короче говоря, это все раздувает код. Больше кода — больше ошибок. Ну ее нахрен, такую "высокоуровневость".


И еще — если мы написали функцию высшего порядка, или код на DSL — то когда нам надо что-то поменять в поведении — мы можем поменять только в одном месте — в определении функции или в кодогенераторе DSL.

Если же код нагенерился из языка жестов, и нам надо поменять поведение нагенеренного кода — то мы делаем что?

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

C>>Ну вот видишь, ты автокомплитом в IDEA не пользовался.
dmz>Вы все такие загадочные... Хоть расскажите словами (и примерами), про зияющие высоты, которых мы не замечаем. Может придется забить на все и перелезть на Java.
Например, пишу:

for(Unit un : units.<shift_space>
//Tyт оно мне СРАЗУ мгновенно напишет, если нет ambiguity
for(Unit un : units.getUnits())

dmz>Да в общем, немного пользовался. Давно. Я помню, оно там по фрагменту зуба (кусок названия типа переменной что ле) генерило все животное целиком:
dmz>

dmz>MyCool<хоткей> - втыкаем в меню - еще пара нажатий на клавиши ->
dmz>MyCoolType myCoolType = new MyCoolType(...)
dmz>

Да, так тоже умеем.

dmz>По мне, вся эта системы допечатки является неким языком — так как что бы получить результат, надо проделать некие действия — нажать горячую клавишу, посмотреть, выбрать, нажать еще.
Она ОЧЕНЬ легковесная. Многие действия я просто уже "вслепую" делаю.

НО!

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

Map<AA,BB> something=new <shift_space>

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

Для С++ такое нормально не сделать, кстати. Так как даже XRefactory не может разибирать некоторые программы.

C>for(Unit un : units.<shift_space>
C>//Tyт оно мне СРАЗУ мгновенно напишет, если нет ambiguity
C>for(Unit un : units.getUnits())
C>[/java]

По моему — мизер. По моему, если ты помнишь, что у тебя есть Unit и units — то о существовании getUnits не забудешь точно.
А уж если есть та самая ambigity... А уж явное декларирование Unit un...

А уж если мы нагенерили пиццот таких блоков, а потом выяснили, что надо делать, то, что мы в них делаем, немного по-другому...

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

dmz>По моему — мизер. По моему, если ты помнишь, что у тебя есть Unit и units — то о существовании getUnits не забудешь точно.
dmz>А уж если есть та самая ambigity... А уж явное декларирование Unit un...
Ты не понимаешь, мне эти самые getUnits() писать не надо. Оно мгновенно само подставляется.

Таких мелочей в IDEA просто очень много.

dmz>А уж если мы нагенерили пиццот таких блоков, а потом выяснили, что надо делать, то, что мы в них делаем, немного по-другому...
И чем поможет DSL, когда выяснится, что мы его неправильно изначально спроектировали?

dmz>>По моему — мизер. По моему, если ты помнишь, что у тебя есть Unit и units — то о существовании getUnits не забудешь точно.
dmz>>А уж если есть та самая ambigity... А уж явное декларирование Unit un...

C>Ты не понимаешь, мне эти самые getUnits() писать не надо. Оно мгновенно само подставляется.

Что бы оно "мгновенно само подставилось", ты уже написал Units un. А если у тебя больше одной функции,
которая возвращает что-то типа Units, то пропадает "само" и "мгновенно".

Да и мне как-то почти по барабану, нажать shift-space, или написать getUnits.

C>Таких мелочей в IDEA просто очень много.

dmz>>А уж если мы нагенерили пиццот таких блоков, а потом выяснили, что надо делать, то, что мы в них делаем, немного по-другому...
C>И чем поможет DSL, когда выяснится, что мы его неправильно изначально спроектировали?

Когда мало кода и он в одном месте — это лучше чем много кода и он в разных местах? Или не лучше? Или одинаково?
Так вот обобщить часто используемый паттерн в ФВП или DSL — приводит к "мало кода в одном месте".

А генерация кода — приводит к "много подобного кода в разных местах"

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

C>>Ты не понимаешь, мне эти самые getUnits() писать не надо. Оно мгновенно само подставляется.
dmz>Что бы оно "мгновенно само подставилось", ты уже написал Units un. А если у тебя больше одной функции,
dmz>которая возвращает что-то типа Units, то пропадает "само" и "мгновенно".
Ну тогда надо просто тыкнуть на нужный элемент в списке. Два-три нажатия клавиш.

dmz>Да и мне как-то почти по барабану, нажать shift-space, или написать getUnits.
Нет. Если там есть getSomeSpecialUnits() — то можно и имя забыть, и писать дольше будет.

C>>И чем поможет DSL, когда выяснится, что мы его неправильно изначально спроектировали?
dmz>Когда мало кода и он в одном месте — это лучше чем много кода и он в разных местах? Или не лучше? Или одинаково?
dmz>Так вот обобщить часто используемый паттерн в ФВП или DSL — приводит к "мало кода в одном месте".
dmz>А генерация кода — приводит к "много подобного кода в разных местах"
Ну приводит. Что дальше? Я не говорил, что макросы — совсем не нужны.