Haskell не оправдал ожиданий русскоязычного сообщества

Все правильно сказал. Но относительно Haskell. ФП в более практичных ЯП будет еще как процветать.

нагуглил http://en.wikipedia.org/wiki/Datalog

и что ты этим хотел сказать?

Кому нужен этот недоязычок, кроме как яйцеголовым теоретикам?

В тысячный раз повторяю - http://www.softcraft.ru/paradigm/fp/whynotfp.shtml

просто ты неосилятор. Да, найти человека, который может писать ФП сложнее, чем идиота, лепящего PHP, или скажем php-c++ (aka boost). Это не причина хоронить ФП. А твой Филип Вадлер в очередной раз доказал, что 95% - идиоты. В т.ч. и среди программистов.

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

Просто феерический бред, не знаю, что и ответить. Какой ещё main loop, начнём с этого.

man WinAPI очевидно же!

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

почему ещё не написали?

И не мутант-математик замучается на каждое простое логическое решение подбирать быстрый математический аналог.

IRL проще аналог подобрать, чем потом в fuckup'ах из-за гонок разбираться...

Ну писал я на этой беде. Для SDL main loop'ы я тоже делал всякие, в т.ч. и на haskell. Какое отношение API сторонних сишных библиотек имеет к языку?

Это не причина хоронить ФП.

Где вопли про «функциональщина не нужна, у меня есть велосипед на сишке»? Тебя точно не убил какой-нибудь ЛОРовский функциональщик и не угнал аккаунт?

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

Ну писал я на этой беде. Для SDL main loop'ы я тоже делал всякие, в т.ч. и на haskell. Какое отношение API сторонних сишных библиотек имеет к языку?

ИМХО только маздайщику с MSDN головного мозга могло придти в голову

многопоточность <...> для разгрузки главного цикла приложения.

Я это понимаю как 100500 кнопочек на форме приложения, при этом каждая кнопка работает в своём потоке. Т.е. нажимаешь «сделай мне ****», и приложение форкается, главный цикл продолжает крутится, а отдельным потоком приложение делает **** клиенту.

Где вопли про «функциональщина не нужна, у меня есть велосипед на сишке»? Тебя точно не убил какой-нибудь ЛОРовский функциональщик и не угнал аккаунт?

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

Всё никак не возьмусь осилить haskell. Сначала покончу со scala, потом в планах у меня common lisp, и только потом haskell...

И всё это параллельно с учёбой/работой, которая с ФП, увы, никак не связана.

Гонки даже тестами нормально не покроешь.

ИМХО то, что сейчас называют «тестами» - профанация заказчиков для выколачивания бабла путём быстрого написания быдлокода и тестов под него.

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

это совершенно справедливо. Вот только быдлокодеры против. И их аргументы почему-то сводятся к тому, что «LISP - УГ мамонта». Я это понимаю как «не мешайте нам писать свой быдлокод».

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

Хаскель - замечательный, прекрасный язык. Я рад и счастлив, что взялся за него - столько вещей сразу встали на свои места в моем сознании.

http://tonsky.livejournal.com/272075.html?thread=2522315#t2522315

Для того, чтобы начать использовать новый инструмент, работодатель должен осознать наличие профита от использования именно этого инструмента, а не другого. В одной местной новосибирской конторе я внедрял разработку на Ерланге. Необходимо было сделать поддержку протокола H.248/Megaco в одной из железок, и самая лучшая из доступных библиотек megaco была именно в OTP. Было достаточно нелегко убедить начальство начать использовать Ерланг по некоторым причинам, которые мне предъявляли. Во-первых, новый непонятный язык, если я уволюсь, писать будет некому. Во-вторых байткод, а не нативный бинарник, считалось, что будет жрать много ресурсов и тормозить.

В результате сошлись на том, что я честно сказал начальству, мол Erlang/OTP — это такой сишный телекомовский фреймворк, написанный целиком на C, но со своим внутренним встроенным языком. В общем, стали делать поддержку этого протокола на железке. В результате получилось, что вся логика, отвечающая за связь с коммутатором и реализующая протокол H.248, потребляла меньше ресурсов, чем один бинарник на C, подключаемый в качестве порта и занимающийся одним лишь взаимодействием с железом через API, предоставленный производителем железки. Всё заработало, прошли сертификацию в институте связи, после чего все всё поняли и решили делать свой коммутатор на Erlang. В той конторе я уже давно не работаю, люди там успешно продолжают писать на Erlang (человек 10 примерно). Ни одно из первоначальных опасений начальства не оправдалось, все пришли к успеху.

Так что если хочется, чтобы работодатели использовали Haskell — пишите блядь на Haskell, а не про Haskell. Одна статья, про Haskell, описывающая, как там круто решать головоломки и защищать PhD — минус 83% потенциальных случаев использования Haskell. Одно крутое приложение на Haskell — плюс 83% к использованию Haskell в продакшене. Большинству «популяризаторов» Haskell не стоило бы его «популяризировать», если они не желают добиться эффекта, обратного от заявляемого. Писать про Haskell можно только после 15 лично написанных пакетов на Hackage, причём пакетов не для решения математических головоломок и кроссвордов, а каких-нибудь полезных библиотек.

Хаскель - замечательный, прекрасный язык. Я рад и счастлив, что взялся за него

Настолько, что забросил перевод «Pharo by Example»?

Настолько, что забросил перевод «Pharo by Example»?

Я его не забрасывал :)

rsug.ru:
Текущая сборка (английский и русский вперемежку) (последнее обновление 13.03.2012)

«Я не сплю — я очень медленно моргаю».

Как и положено гуру, Simon Peyton-Jones раскрыл тему гораздо меньшим количеством букаф. :-)

IRL проще аналог подобрать, чем потом в fuckup'ах из-за гонок разбираться...

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

поддержку протокола H.248/Megaco в одной из железок, и самая лучшая из доступных библиотек megaco была именно в OTP.

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

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

в _одном_ потоке всё хорошо. Я не спорю.

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

ты разве не понял, что проблемы гонок возникают не из-за того, что бульдог с носорогом трахаются, а из-за того, что в постели твоей жены спят по ночам несколько мужиков, причём _одновременно_. И ей в потёмках не видно, ты это, или не ты. А в функциональном программировании такой проблемы попросту не возникает, ибо у каждой пары есть _свой_ личный контекст, который ни с кем НЕ разделяется. Оно конечно не слишком экономично, но вопросов «от кого дети?» тоже не возникает.

в _одном_ потоке всё хорошо. Я не спорю.

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

А в функциональном программировании такой проблемы попросту не возникает, ибо у каждой пары есть _свой_ личный контекст, который ни с кем НЕ разделяется.

Зато возникает головомойка при их изучении. Если обмен информацией между потоками нормально организован, то можно иметь и свой личный и общий контенты - не надо путать проблемы конкретных ООП фреймворков и императивных ЯП. Общий контент нужен для асинхронного обмена информацией между потоками, если к нему никого не пускать, то для организации простого действия придётся изобретать что-то сложное.

Зато возникает головомойка при их изучении.

это проблема неосиляторов.

Если обмен информацией между потоками нормально организован, то можно иметь и свой личный и общий контенты - не надо путать проблемы конкретных ООП фреймворков и императивных ЯП.

а это проблема как раз императивных ЯП. И ФП - это панацея (с побочными эффектами конечно).

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

ты сам понял, что сказал? Либо женщина общедоступная(шлюха), либо - никого не пускать(жена). Третьего не дано.

это проблема неосиляторов.

Все ЯП нормально осилить нельзя.

а это проблема как раз императивных ЯП. И ФП - это панацея (с побочными эффектами конечно).

Опиум с кокаином когда-то продавались в аптеках как лекарства но потом обнаружились побочные эффекты.

ты сам понял, что сказал? Либо женщина общедоступная(шлюха), либо - никого не пускать(жена). Третьего не дано.

Может для тебя любой программный код и жена но для меня что-то нет. Скорее это кусочек разума/недоразума.

В императивных языках особых гонок не наблюдается

Именно в них гонки и наблюдаются, ваш К.О.

#include <stdio.h>
#include <omp.h>

int main()
{
    using namespace std;
    int n;
    omp_set_num_threads(6);
    #pragma omp parallel
    {
        n = omp_get_thread_num() + 1;
    }
    printf("Dice roll: %d\n", n);
}

Если сразу определить какой поток с какими переменными что может делать и эти правила не нарушать

Как это определить средствами языка так, чтобы при нарушении код не скомпилировался? А вдруг в безобидной функции есть статическая переменная?

Все ЯП нормально осилить нельзя.

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

Опиум с кокаином когда-то продавались в аптеках как лекарства но потом обнаружились побочные эффекты.

побочные эффекты были известны сразу, не было альтернативы. Сейчас есть, потому вещества и запретили. А вот альтернативы ФП пока нету. Как будет - выкинем на свалку истории, между флогистоном и философским камнем.

Может для тебя любой программный код и жена но для меня что-то нет. Скорее это кусочек разума/недоразума.

фишка в том, что любой код может изменять общие данные, а может и не изменять. Типы данных и индексы массивов никак на это НЕ влияют - мы меняем одни и те же данные, только делаем это одновременно. От того и сложности. Очевидный способ избавления - использовать в каждой функции свой контекст, тогда проблемы с общими данными не будет по определению. Потому-что таких данных не будет. А вот в императивном программировании, _все_ данные по умолчанию общие. Потому, в ИП надо наворачивать костыли для защиты общих данных, а в ФП надо наворачивать другие костыли, для того, что-бы сделать данные общими. Ну например, продолжая тему о бабах, я могу спать с одной, а ты с её сестрой-близняшкой. Причём эта сестра постоянно обсуждает _все_ вопросы с другой. В итоге, что-бы ты не придумал, я это тоже попробую, хотя и косвенно и с задержкой. Но разницы почти никакой. Это самый простой костыль в ФП для реализации «квазиобщих ресурсов».

Именно в них гонки и наблюдаются, ваш К.О

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

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

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

А вдруг в безобидной функции есть статическая переменная?

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

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

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

побочные эффекты были известны сразу, не было альтернативы.

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

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

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

А вот в императивном программировании, _все_ данные по умолчанию общие.

Неа. Существуют области видимости и не каждую переменную можно читать и записывать в конкретном исходнике. Данные хранящиеся в локальных переменных вообще никак не общие а в ООП существует инкапсуляция и защищённые секции.

Потому, в ИП надо наворачивать костыли для защиты общих данных

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

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

ты не боишься по незнанию затратить полжизни на повторное изобретения LISP'а? С чего ты взял, что твоя «прослойка» как раз и не будет эквивалентна ФП? Может это и есть то самое ФП, которое ты самостоятельно придумал, и реализовал? Молодец конечно(если осилишь), но может проще изучить то, что УЖЕ придумали?

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

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

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

слушай, вот у тебя есть такой код:

x = y;

Неа. Существуют области видимости и не каждую переменную можно читать и записывать в конкретном исходнике. Данные хранящиеся в локальных переменных вообще никак не общие а в ООП существует инкапсуляция и защищённые секции.

это всё костыли. область видимости вообще только имя скрывает, а вовсе не само значение - то, что у тебя записано по адресу 0x12345678 видно ВЕЗДЕ. В любом потоке, и в любой области видимости. Просто где-то этот адрес называется x, где-то y, а где-то вообще никак не называется. Локальные переменные дают какое-то приближение к контексту, вот только что-то не видать программеров, которые используют _только_ стек. Как раз наоборот... Ну а адрес в сишечке _всегда_ глобальный. Как и в C++.

2008-й был годом надежды на Haskell и радикальное ФП. Потом оказалось, что это быстро приводит к куче неподдерживаемого неговнокода.

«Радикальное ФП» - хорошо сказано. Само по себе ФП очень хорошо прижилось в том же C#, правда не столь «радикальное». Сейчес редкий сишарпер не знает и не умеет читать Linq. Здесь я имею в виду больше запись через extension methods, чем sql-подобный синтаксис, который я, кстати, не люблю.

ты не боишься по незнанию затратить полжизни на повторное изобретения LISP'а? С чего ты взял, что твоя «прослойка» как раз и не будет эквивалентна ФП? Может это и есть то самое ФП, которое ты самостоятельно придумал, и реализовал? Молодец конечно(если осилишь), но может проще изучить то, что УЖЕ придумали?

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

слушай, вот у тебя есть такой код:
x = y;
пока он однопотоковый, проблем нет. Проблемы появляются если потоков больше одного. Вот только, сколько бы не было потоков, никакие типы здесь НЕ меняются. Потому ошибки типа здесь НЕ БУДЕТ. В другом потоке тип другого y в точности такой же.

a:=1;
while a=1 do sleep(10);

Где здесь проблема? Проблема возникнет только если код однопоточный.

это всё костыли. область видимости вообще только имя скрывает, а вовсе не само значение - то, что у тебя записано по адресу 0x12345678 видно ВЕЗДЕ. В любом потоке, и в любой области видимости. Просто где-то этот адрес называется x, где-то y, а где-то вообще никак не называется.

Если глобальная переменная не видна, то обратиться к ней можно только через указатели (и не факт что запись будет разрешена), что не ССЗБ без крайней необходимости делать не будет - проблема тобой придумана.

Ну а адрес в сишечке _всегда_ глобальный. Как и в C++.

Цэпроблемы, ты ещё с 1913 годом хацкель сравни.

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

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

a:=1;
while a=1 do sleep(10);

Где здесь проблема? Проблема возникнет только если код однопоточный.

проблема в том коде, который меняет a. А в этом потоке a не меняется (это-же пас-кал?)

Если глобальная переменная не видна, то обратиться к ней можно только через указатели (и не факт что запись будет разрешена), что не ССЗБ без крайней необходимости делать не будет - проблема тобой придумана.

Цэпроблемы

ну-ну... В других ЯП с этим ещё хуже.

проблема в том коде, который меняет a. А в этом потоке a не меняется

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

(это-же пас-кал?)

Лиспокала не держим.

ну-ну... В других ЯП с этим ещё хуже.

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

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

да, конечно. Где код-то?

да, конечно. Где код-то?

В программе, таким макаром работают кнопки «загрузить файл» и «сделать зашибись»:) Минимальная демка будет состоять из трёх файлов, но 4 всё же лучше, вот счас всё брошу и начну строчить для одного читателя.

В программе, таким макаром работают кнопки «загрузить файл» и «сделать зашибись»:) Минимальная демка будет состоять из трёх файлов, но 4 всё же лучше, вот счас всё брошу и начну строчить для одного читателя.

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

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