Это конечно уже выходит за рамки как философии, так и программирования, но

Pzz>Меня интересует, понимания ради, а не флейму для , как Хаскель
Pzz>вписывается в, скажем так, коммерческое (не академическое) программирование.

Pzz>А именно:
Pzz> 1. Где брать кадры?

Если в России, то воспитывать.
Я серьезно. Брать студентов и учить вручную — на практике выходит гораздо эффективнее, брать ученых в пользу менее эффективного инструмента. Конкретно хаскель по опыту (я четырех человек обучил) свежими (не обремененными специальностью) мозгами усваивается очень быстро — благо там учить нечего, язык простой как три рубля.

Pzz> 2. Как преодолевать естественное сопротивление менеджеров?

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

Pzz> 3. Для каких практических проектов он подходит? (только не надо
Pzz>говорить, "для всех" — это отписка, и я сразу приведу опровергающий пример).

Конечно не для всех. Однозначно не подходит для написания драйверов и для реального времени (язык с ленивой семантикой, потому выполнение нестрогое). Как язык со статической и строгой типизацией, видимо, не самый лучший кандидат на скриптинг (ну на одноразовый по крайней мере).
В остальном принципиальных ограничений нет, но больше всего остальных он обходит в написании компиляторов, системах со сложной логикой (сложными правилами и алгоритмами), системах, где нужна максимальная надежность (медицина, армия, космос и тп)
А так — спектр очень широкий в т.ч благодаря и довольно сильным метавозможностям даже без макросов (TemplateHaskell).
Вот недавно я попробовал GUI всякий пописать, так там в wxhaskell целый свой маленький язык сделан на комбинаторах — в результате все описывается очень компактно и понятно в xml-подобном стиле.

Pzz> 4. Насколько получающиеся программы ресурсоемки? Тут бы хотелось
Pzz>какой-то практический ответ, а не сравнение с C/C++/C#/Java/Perl/... -
Pzz>такие сравнения не имеют смысла.

Однозначно тут ответить нельзя — некоторые конструкции (особенно у начинающих) могут и медленно работать и потреблять дикое количество памяти (всеж на рекурсии да на копировании). Но уверенных руках хаскель (в данный момент и в данном случае речь идет о GHC в первую очередь) очень эффективен — то есть кое где и Си оставит позади (в основном благодаря более аккуратной работе со всякими структурами и ленивому вычислению). Замечу еще что теоретически он может компилироваться в _очень_ эффективный код, но современные компиляторы пока далеки от совершенства в этом плане, потому какие-то вещи приходится конечно оптимизировать руками (явно объявлять принудительное вычисление аргументов и использовать там например массивы вместо более удобных списков где-то). Я не знаю как дать более практический ответ. Память вовсе не является его слабым местом (она или вся быстро уходит или на минимальном уровне потребляется ) А по скорости хаскель проседает (настолько, что есть смысл задумывать о переписывании функции на Си) в основном когда нужны битовые операции и всякая такая гадость.


Pzz> 5. Насколько хорошо получающиеся программы живут под операционными
Pzz>системами, которыми пользуются пользователи?

Речь про windows, я так понимаю
Ничего кроме того, что адреса двух главных разработчиков GHC заканчиваются на @microsoft.com я сказать не могу

А вот на маке чтобы заставить корректно работать wxhaskell мне пришлось попотеть (хотя это претензии скорее напрямую к wxwidgets)

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

K>как сразу писать качественный код (т.е. с минимальным числом алгоритмических ошибок и чтобы как можно меньше их исправлять на стадии тестирования) ...

Умный вещь №1: Никак. Ибо человеком сие проделать невозможно по определению.

Но! Можно построить систему и ритуалы которые помогают
а) локализовать ошибки
б) минимизировать последствия ошибок

Например:
1) сначала нарисовать кубики на бумаге, как ни парадоксально но помогает здорово. (это то что предыдущие ораторы подразумевали под "думать")
2) создавая файл (модуль) четко знать — здесь я буду писать вот это.
3) пиши изначально простой код, классы и функции.
3a) тело функций как правило не должно превышать видимой области в редакторе.
3б) использование сложных конструкций типа stl templates на первых порах ограничить до минимума. До тех пор пока точно не будешь знать что они делают.
4) базовые, принципиальные кубики в основании программы проверять тестами по ходу (unit testing).
5) не лениться и все базовые параметры и вход процедур проверять асертами (assert) — проверенно — очень эффективно отсекаются очень многие несуразицы.

Еще кто вспомнит чего?

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

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

Здравствуйте, Nickolay Ch, Вы писали:
NC>Здравствуйте, vitaly_spb, Вы писали:
OT>>>Думать не пробовал, когда код пишешь?
_>>Вот просто интересно, за что человеку минусов понаставили. Минус это как известно "Не согласен" (см. tooltip), значит Nickolay Ch и Plague не согласны что надо думать?
NC>Лично я не согласен с такой формой ответа.
NC>Вам бы понравилось, если б я в ответ на Ваш вопрос написал то же самое?
Отличие в том, что отвечают не вам.

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

GZ>>Никак. По крайней мере не научился. Некачественно написать легче. И сразу же доработать напильником для качества.
S>Кажется у Кернигана было, научится прграмировать можно только програмируя. Это как езда на велосипеде можно прочитать об этом десятки книжек, но без практики вы на нём не поедете и наверняка пока научитесь набъёте немало шишек, а может и охота этим заниматся пропадёт, хотя умные книжки тоже надо читать, но надо подкреплять их практическим опытом закрепляя прочитаное.
Ты не понял. Это у меня стиль такой. Вначале я пишу функцию. А потом просматриваю что у меня получилось. И если некрасиво(а такое бывает часто), то рефакторю неотходя от кассы, и не забывая что пять минут назад делал. И уж тем более не чекиня такие изменения.

S>По собственному опыту, тот же рефакторинг с неплогохо качества, по вашему мнению, кода даёт значительно лучшие результаты чем написать сразу тяп-ляп, а потом доводить до ума.
Тут я совсем не понял. Что такое "лучшие результаты рефакторинга"?

С уважением, Gleb.