Но довольные заказчики, как и всё остальное — такая же «оптимизируемая» метрика. Специально обученный человек садится на телефон и обзванивает заказчиков, в том числе потенциальных:
— Здравствуйте, вы довольны нашим продуктом?
— Эта проблема уже решается. А ещё?
— Эта проблема будет решена в следующей версии. А ещё?
— Эта проблема есть во всех аналогах, но мы работаем над ней. А ещё?
— То есть в целом вы довольны, спасибо.
В любом случае лучше здравого смысла пока ещё ничего не придумали.
Кто захочет, почитает «Subverting the windows kernel», тем более что эту книгу издавали и на русском.
Классика, разработчики антивирусов наверное её уже наизусть знают. Но как показывает практика, антивирусы принципиально бессильны против кода, получившего ring0.
Но. Опытному программисту на haskell это всё и не нужно объяснять. А вот опытному программисту на с++ никакими аргументами не доказать что map лучше for. Хоть об стену разбейся. Почему? Вопрос открыт.
Диалог слепого с глухим обычно примерно следующий:
— В map нет побочных эффектов, код более надёжен!
— Чо? Каких эффектов? Какой надёжен, он же непонятен! А вот for понятен каждому!
Эта статья замечательный способ запутать разработчика.
Что вы хотели бы там прояснить? Может быть, лямбда функции?
Давайте лучше писать вообще на haskell без haskel например:
Многие так и делают. Хотя назвать это «haskell без haskell» не получится, но встроенные проблемно-ориентированные языки очень распространены, примеры:
В данном случае \a -> это парметр лямбда-функции, тело которой — весь остаток строки. А первый bind связывает getLine и (\a -> putStrLn «Вы ввели:» >>= \_ -> putStrLn a).
Поэтому скобки более правильно было бы расставлять так: Prelude> getLine >>= (\a -> putStrLn "Вы ввели:" >>= (\_ -> putStrLn a))
Но довольные заказчики, как и всё остальное — такая же «оптимизируемая» метрика. Специально обученный человек садится на телефон и обзванивает заказчиков, в том числе потенциальных:
— Здравствуйте, вы довольны нашим продуктом?
— Эта проблема уже решается. А ещё?
— Эта проблема будет решена в следующей версии. А ещё?
— Эта проблема есть во всех аналогах, но мы работаем над ней. А ещё?
— То есть в целом вы довольны, спасибо.
В любом случае лучше здравого смысла пока ещё ничего не придумали.
Кто захочет, почитает «Subverting the windows kernel», тем более что эту книгу издавали и на русском.
Классика, разработчики антивирусов наверное её уже наизусть знают. Но как показывает практика, антивирусы принципиально бессильны против кода, получившего ring0.
Но. Опытному программисту на haskell это всё и не нужно объяснять. А вот опытному программисту на с++ никакими аргументами не доказать что map лучше for. Хоть об стену разбейся. Почему? Вопрос открыт.
Диалог слепого с глухим обычно примерно следующий:
— В map нет побочных эффектов, код более надёжен!
— Чо? Каких эффектов? Какой надёжен, он же непонятен! А вот for понятен каждому!
Что вы хотели бы там прояснить? Может быть, лямбда функции?
Давайте лучше писать вообще на haskell без haskel например:
Многие так и делают. Хотя назвать это «haskell без haskell» не получится, но встроенные проблемно-ориентированные языки очень распространены, примеры:
hackage.haskell.org/package/atom/ — edsl для генерации embedded кода на си
jaspervdj.be/blaze/ — edsl для построения html
legacy.cs.uu.nl/daan/parsec.html — edsl для парсинга контекстно-свободных(и некоторых КЗ — грамматик)
www.lexifi.com/downloads/frankau.pdf — edsl для трэйдинговой системы
Prelude> getLine >>= \a -> putStrLn "Вы ввели:" >>= \_ -> putStrLn a
В данном случае \a -> это парметр лямбда-функции, тело которой — весь остаток строки. А первый bind связывает getLine и (\a -> putStrLn «Вы ввели:» >>= \_ -> putStrLn a).
Поэтому скобки более правильно было бы расставлять так:
Prelude> getLine >>= (\a -> putStrLn "Вы ввели:" >>= (\_ -> putStrLn a))