> Я понял, ты спал на уроках математики.

У меня был класс с углубленным изучением математики. В детстве любил поспать, поэтому опаздывал на первые уроки и моя учительница алгебры, по совместительству зауч, не начинала урок пока я не приду. Признаюсь, грешен, спал в универе на матане в первом семестре, а потом просто перестал туда ходить, ибо программу по математике, читаемую на физфаках в течении 3-х лет, знал ещё в школе (за исключение ТФКП и методов мат. физики). По всем математикам имею отлично.

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

> Кто бы это суперструнщикам сообщил...

А, так ты знаешь, как оно на самом деле? Или знаешь, как опровергнуть «измышления суперструнщиков»?

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

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

Скорее, в каком месте статическая типизация в хаскелле может быть полезна в реальном применении?

См. выше по треду. Устал повторять.

Зачем он нужен?

Не знаю, не пользуюсь.

Да, настоящий скрывает под собой механизм условных переходов и изменения переменных.

Ну и у меня скрывает. В том же смысле.

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

Конечно не знают, я же это только что написал.

свою весьма изощренную теоретическую демонстрацию не можешь связать с реальностью

Этот LispDo уже можно юзать. Реально.

И ещё, например, сделать в лиспе что-то типа dotimes, dolist и т.д. - тривиально. В хаскелле без знания огромного кол-ва теории - никак.

Тривиальные циклы и так сделаны - forM, sequence и т.п.

Где ты в итерации разглядел стрелки, категории и т.д.?

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

Тогда с эквивалентными возможностями хаскелла всё еще хуже.

Отнюдь. Динамическая типизация легко реализуется через статическую; обратное неверно.

Кстати, МП в лиспе не МП, а лишь следствие контроля времени вычисления через спец. форму.

В чём разница?

Возможно, хотя конструкции LispDo (->) () Integer выглядят как-то сомнительно для простой итерации.

Ну, сделай

type VerySimpleLoop = LispDo (->) ()

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

Программирование - это такой раздел прикладной математики. Очень прикладной.

А, так ты знаешь, как оно на самом деле? Или знаешь, как опровергнуть «измышления суперструнщиков»?

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

>Ты хочешь строить все теории на основе эмпирического опыта?!

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

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

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

Так что за теорию надо братся без отрыва от практики.

> Конечно, дискретку в топку, зачем она разработчикам?

Не знаю. Я её не изучал. За выпускниками факультета «Прикладная математика» особых алгоритмических способностей не заметил: обычно вся алгоритмическая логика на мне (как и проектирование). Когда читал AIMA (мне нужны были некоторые алгоритмы для планирования и поиска в пространстве состояний) каких-либо сложностей с понимание материала не имел. Так зачем она нужна?

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

too fat

> Так зачем она нужна?

Она, как и другие направления, нужны для того, чтоб такого не было:

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

Обезъяннее перекладывание чужого кода на CL с кастомизацией - молодец, мои поздравления, ты состоялся.

Лично мы было бы так стыдно про себя говорить. И особенно стыдно делать то, чего я не понимаю.

s/ мы/ мне/

Программирование это прикладной раздел CS.
CS такая же математика, как математика - физика.

>Конечно не знают, я же это только что написал.

Ну тогда, раз автор и сам не может сформулировать зачем это нужно и чем это лучше существующего, то это хуже и не нужно?

См. выше по треду.

Вижу только переусложнённое даже в тривиальном случаем МП.

Тривиальные циклы и так сделаны - forM, sequence и т.п.

Ясно, заюзать для этой цели хаскелльный вариант do уже чрезвычайно сложно.

сайд-эффекты как правило означают монаду либо стрелку.

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

В чём разница?

в возможности мп именно из-за такого дизайна языка.

Динамическая типизация легко реализуется через статическую; обратное неверно.

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

> Обезъяннее перекладывание чужого кода на CL с кастомизацией

Не перекладывание. А прочитать, понять и сделать лучше.

Лично мы было бы так стыдно про себя говорить.

И особенно стыдно делать то, чего я не понимаю.

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

Впрочем, у меня есть пример и на счет «не понимаю». Точнее, не вполне понимаю. Мне нужен был демон на pure lisp, без всяких там Screen и т.п. Сложность в том, что если у lisp-процесса закрыть стандартный поток ввода, то он немедленно завершится. Открыл исходный код detachtty, и не очень хорошо понимая что делаю перенёс на CL. О существовании псевдотерминалов я узнал только в процессе изучения этого кода и до сих имею об этом весьма смутное представление.

Или вот, мне надо работать с MS SQL. В MS SQL, ровно как и в FreeTDS я полный ноль. И мне не стыдно по этому поводу, и нет желания досконально разбираться в этом. Я просто открыл исходный код pymssql и на его основе за полтора дня реализовал нужную мне функциональность.

Так чего я должен стыдиться?

> Так чего я должен стыдиться?

В том, что не захотел почитать man forkpty/pty

В том, что перед решением задачи с парсингом текста не соизволил полистать теорию

В том, что даже после ad-hoc решения задач ты всё ещё не подтянул свои знания

В том, что толсто троллишь

> В том, что не захотел почитать man forkpty/pty

Зачем мне это? У меня был конкретная проблема и я её решил. И получив уникальное решение, ибо весь остальной мир продолжает делать lisp-демонов через Screen. Тема терминалов мне не интересна и для других задач не нужна, зачем мне разбираться дальше? У меня всё прекрасно работает.

В том, что перед решением задачи с парсингом

текста не соизволил полистать теорию

Я пролистал прекрасно написанный (на быдло-PHP, которого я не знаю) код Dokuwiki, всё прекрасно понял (код правда отличный) и реализовал у себя, получив при этом общий фрэймкворк для парсинга вики-разметок, который затем использовал для другой, более сложной задачи. Итого, на всё я потратил 8 часов. Я не фанат парсинга, и взялся за это только потому, что никто больше не хотел это делать. И у меня всё прекрасно работает. Зачем мне что-то ещё листать?

В том, что даже после ad-hoc решения задач ты всё ещё

не подтянул свои знания

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

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

> с Common Lisp я познакомился потому, что Python и C++, которые были в тот момент моими основными инструментами, явно не подходили для решения стоящей тогда задачи.

И принял решение перейти на него? Сам, не советуясь с командой?

А про троллинг почему молчишь?

> И принял решение перейти на него? Сам, не советуясь с командой?

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

> А про троллинг почему молчишь?

А что должен сказать? В чём суть претензий? Там меня выше и идиотом называли, и ещё по-разному, я должен на всё реагировать?

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

Типичная история успеха Лиспа - эффектная и не особо относящаяся к обычной жизни :)

Толсто! Очень толсто!

> Типичная история успеха Лиспа - эффектная и

не особо относящаяся к обычной жизни :)

Обычную жизнь строим мы сами. Мне понравился Common Lisp и настолько, что я создал для себя условия, что бы иметь возможность писать на нём. Возможно, Common Lisp и не поможет вам устроиться в банк, но зато может оказаться полезным, если вы решите запустить стартап (хотя я к этому только иду). Это вопрос свободы и воли: решает ли кто-то за вас, или вы сами принимаете решение. Если вы хотите решать сами, то тот факт, что все пишут на Java и PHP не будет иметь особого значения.

>> Типичная история успеха Лиспа - эффектная и не особо относящаяся к обычной жизни :)

Обычную жизнь строим мы сами.

В обычной жизни программы пишутся коллективами, а не суперпрограммистами-одиночками; и нужно, чтобы они работали, а не «работали хоть как-нибудь».

>В обычной жизни программы пишутся коллективами, а не суперпрограммистами-одиночками; и нужно, чтобы они работали, а не «работали хоть как-нибудь».

Лично я наблюдал совсем другое

>> В обычной жизни программы пишутся коллективами, а не суперпрограммистами-одиночками; и нужно, чтобы они работали, а не «работали хоть как-нибудь».

Лично я наблюдал совсем другое

Расскажи.

>Расскажи.

Рассказать как я неоднократно ВНЕЗАПНО становился единственным специалистом на предприятии? Помоему это тут совсем невтему.

> Рассказать как я неоднократно ВНЕЗАПНО становился единственным специалистом на предприятии?

Я так понимаю, что это не предприятие, разрабатывающее софт? Тогда не надо.

Программирование это прикладной раздел CS.

CS - раздел прикладной математики.

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

раз автор и сам не может сформулировать зачем это нужно и чем это лучше существующего, то это хуже и не нужно?

Дык я и писал только по просьбе какого-то анонимуса.

Вижу только переусложнённое даже в тривиальном случаем МП.

Разуй зенки.

Ясно, заюзать для этой цели хаскелльный вариант do уже чрезвычайно сложно.

Отнюдь. Просто есть более подходящие инструменты. Повыше уровнем.

Нет, они означают, что тут лямбла уже не подходит

Неверно.

в возможности мп именно из-за такого дизайна языка.

Ещё раз: в чём разница между МП и тем, что ты там тявкнул?

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

Низачем. Как и динамическая типизация вообще.

Плюс, вряд ли ошибусь, если предположу

Ошибёшься.

надежды возложеные на «ленивое программирование» и «автоматическое распаралеливание» не оправдлаись. человек делает ето намного лучше чем машина.

Не вполне. Я не знаю языка, кроме Хаскеля, где можно было бы сказать машине «вычисли этот список параллельно», не занимаясь ручной работой.

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

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

Но всё же, ради любопытства, не просветите о «должной теоретической подготовке», без которой миллионные прожекты не пишутся?

>Дык я и писал только по просьбе какого-то анонимуса.

получилось плохо, уже все увидели.

Отнюдь. Просто есть более подходящие инструменты. Повыше уровнем.

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

Неверно.

Верно. Использование не оправдавшей себя лямбды, которая предназначена была исключительно для теории, там где есть более просты способы - неадекват. Стрелки, монады, и кроме тривиальных рекламных примеров сложный код станет ещё на порядок сложнее.

Ошибёшься.

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

>Я не знаю языка, кроме Хаскеля, где можно было бы сказать машине «вычисли этот список параллельно», не занимаясь ручной работой. Если ты о Data Parallel Haskell, то оно там нифига не автоматическое. С тем же успехом можно PLINQ использовать, семантически они практически эквивалентны, только в PLINQ еще и промышленное качество от Microsoft.

получилось плохо, уже все увидели.

Чем плохо?

повыше уровнем = сложнее аналогов и без ощутимой пользы?

Нет.

где польза от типов?

Выше по треду.

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

Не абстрактным «человеком», а конкретным тобой.

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

Не пиши в коде кучу мусора.

Использование не оправдавшей себя лямбды

1) Приведи аргументы о неоправданности.

2) Покажи, где ты там увидел лямбду.

Стрелки, монады, и кроме тривиальных рекламных примеров сложный код станет ещё на порядок сложнее.

Примеры масштабируются.

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

У тебя сбоит блок логики. Посмотри, на что был мой ответ.

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

если в коде фактически куча мусора?

Какого мусора, няшечка? Код на Хаскеле видел или просто осуждаешь?

Если ты о Data Parallel Haskell, то оно там нифига не автоматическое.

Нет, в данном случае я НЕ о DPH. Я о Control.Parallel.Strategies.

PLINQ не смотрел, не знаю.

>Нет.

Не абстрактным «человеком», а конкретным тобой.
Примеры масштабируются.
Не пиши в коде кучу мусора.

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

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

Не все я, что anonymous. Задай конкретный вопрос, получишь конкретный ответ. Я сюда недавно заглянул, тред целиком читать лень.

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

Ну, ты вообще логикой не владеешь.

Разве оно автоматическое?

А разве я это сказал? Читай, что написано, а не что тебе там приснилось.

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

Вообще, это называется «комбинатор par», представляющий собой хинт компилятору - здесь МОЖНО (не обязательно) сделать параллельно.

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

>Цель - реализация некоторых правил. Заметим декларативных, что в большей степени соответствует человеческому мышлению.

да.

А императивщина - это моторика - бежать, лезть на дерево, рвать банан, ну ты понял.

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

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

Ни одного раза я не высказывал утверждение «Haskell распараллеливает автоматически». Мой комментарий означал следующее: делать параллельные программы на Haskell ЛЕГЧЕ. Частично - я показал, почему.

но всё декларативное к этому сводится в конечном счёте

В конечном счёте всё сводится к двоичному коду. Ты же не пишешь методом cat > program?

если легче представить декларативную конструкцию сразу императивно (где это уместно) + функционально + МП, а не как на хаскелле, то почему не выбрать лёгкий путь?

Прекрасно. Поскольку императивные конструкции на Хаскеле записываются легко и приятно. А временами они могут быть автоматически преобразованы в чистые функции (см. Control.Monad.ST).

вот написать аналог do - в лиспе ничего сложного, всё прямолинейно, зачем тогда привлекать для решения этой проблемы на порядок более сложные способы?

Да какие сложности, один тип (одна строчка), после чего всё остальное пишется практически единственным возможным образом.

>Использование не оправдавшей себя лямбды,

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

Стрелки, монады

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

По кой черт тебе сдался хаскель? Юзай Scala, юзай Clojure, Groovy, F#, наконец.

где польза от типов

Бестиповых языков не бывает.

>и если легче представить декларативную конструкцию сразу императивно (где это уместно) + функционально + МП, а не как на хаскелле

Не, а какие проблемы именно в Хаскелле? Императивное представление пишется очень просто даже без понимания нижележащих механизмов.

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

Единственное, в чем он мне не удобен, так это в том, что нельзя менять программу прямо в процессе работы без перезапуска. Люблю «по-живому» писать, чтобы сразу результат видеть. GHCi конечно есть, но это уже не то. Ну и библиотек маловато. В остальном все удобно и приятно.

>Лямбда-абстракции - это те же яйца, что и машины Тьюринга. Только в профиль.

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

Т.е. любая фигня, которая поддерживает (явно или не явно) операцию композиции - монада.

Щитоу? А вот не всякий applicative functor монада, например. А вот класс монад не замкнут относительно операции композиции, например.

З.Ы. херовая у вас капча.