Коллекционные карточные игры: секрет успеха на мобильных платформах

Мне кажется, фишка ККИ в том, что их не нужно балансировать. Точнее это не так критично, как в обычных стратегиях, где все изначально в равных условиях.

Символьные вычисления на примере решения одной несложной задачи по квантовой механике

Автор крут. Сразу видно, проделана огромная работа.
Только, мне кажется, что привязка к задаче по квантовой физике немножко лишняя. Т.е. можно было просто описать модуль для символьных вычислений без привязки к какой-либо предметной области (квантовой физики в данном случае). А то неподготовленный читатель при виде выражения "|ϕ> = ½ |0> + (1 + √2 i)/2 |1>" может испугаться и убежать.
Кстати, что за курсы такие по квантовым вычислениям? Они уже заранее готовят программистов для квантовых компьютеров? :)

Ленивый hGetContents. Баг или фича? (Haskell)

main = openFile "1.txt" ReadMode >>= \file -> 
	hGetContents file >>= \content -> 
	hClose file >> 
	print content

Ленивый hGetContents. Баг или фича? (Haskell)

Давайте рассмотрим ОДНУ функцию и вычислим её ДВУМЯ разными способами. Объясните мне, почему они дают разный результат?

main = do 
    file <- openFile "1.txt" ReadMode
    content <- hGetContents file
    hClose file
    print content

Ленивый hGetContents. Баг или фича? (Haskell)

Монады уж точно не для этого «придумывали». У вас в рассуждениях телега стоит впереди лошади — это наличие монад (с синтаксическим сахаром в виде do-нотации) позволяет представлять программу в виде функции, которая выглядит императивно. А не наоборот.

Не понял, в чем я был не прав. По-моему я написал то же самое.

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

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

Ленивый hGetContents. Баг или фича? (Haskell)

Спасибо за пояснение

Ленивый hGetContents. Баг или фича? (Haskell)

Спасибо за пояснение.

Ленивый hGetContents. Баг или фича? (Haskell)

Странно, что нет стандартной safe функции, и приходится придумывать какие-то костыли.

Ленивый hGetContents. Баг или фича? (Haskell)

Я так понял, все подходят к этому вопросу с практической точки зрения. Если нужен ленивый вариант, вот одна функция, если не ленивый — другая.
А меня больше задевает идеологическая сторона вопроса. Почему я пишу корректную (в энергичном смысле) программу, а она выдает некорректный результат. Вот представьте, вы бы нашли какую-нибудь лазейку, как протащить side-effect в чистую функцию. Что бы вы подумали? Я бы, например, немножко разочаровался. Я бы подумал: «ну так не интересно, я-то думал, что в haskell это невозможно».

p.s.: Я знаю что существуют функции, типа trace, которые не совсем чистые. Но, поскольку они применяются для отладочных целей, им прощается :)

Ленивый hGetContents. Баг или фича? (Haskell)

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

import System.IO
main = do 
    c <- withFile "1.txt" ReadMode $ hGetContents
    withFile "1.txt" WriteMode $ \h -> hPutStr h $ "<" ++ c ++ ">" 

И никакие другие функции, типа withFile, readFile, writeFile, тут не помогут, потому что они всего лишь обертка над openFile, hGetContetns и hClose.

>Пишу:
> length content `seq` do…
За пример спасибо :)

Монада ContT в картинках (Haskell)

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

Монада ContT в картинках (Haskell)

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