Clojure: Элитные языки программирования [my-clojure.blogspot.ru]
Спустя 110 сек.
Этот топик нужно переместить в Lisp
Спустя 74 сек.
Элитные языки программирования
На этот пост меня подвигли рассуждения Майкла Фогуса (автора "The Joy of Clojure") о том, что такое "программерская элита".
Фогус очень разумно объясняет, что не язык программирования является признаком "элитности" программиста. Даже Java может казаться сложной и непонятной тем, кто ее не знает. И даже Haskell будет простым и удобным тем, кто разобрался с этим языком.
Более того, действительно крутые программисты, с которыми Фогусу довелось иметь дело, работали даже с таким позорным убожеством, как С++, и тем не менее умудрялись быть очень-очень продуктивными.
Элитными могут быть, пожалуй, только программерские задачи, решить которые может лишь очень малый процент программистов. Т.е. не мега-навыки делают программиста "элитой", а, в первую очередь, крайне сложные проблемы, которые этот программист решает. Само собой, для решения сложных задач нужно иметь уровень профессионализма намного выше среднего, а также подходящие инструменты.
Выбор языка программирования для решения нетривиальных задач -- это уже следствие сложности самих задач. Язык программирования тогда "подходит" для задачи, когда упрощает ее решение, а не тогда, когда конкретный программист знает язык лучше или любит его больше. Clojure -- один из таких языков. Его "функциональность", макросы, гомоиконный синтаксис, STM, REPL, Swank -- все это предназначено для упрощения решения именно сложных задач.
Впринципе, согласен с тем, что написал Фогус. Clojure не просто располагает к экспериментированию, а прямо навязывает такой "экспериментаторский" стиль разработки. Вспомните, как нас учили программировать в школе и универе? Задачи часто решались на бумажке, нередко рисовали блок-схемы алгоритмов. Везде, где я работал, любили UML и много "планировали" перед тем, как приступить к кодированию. В Clojure -- все наоборот. Думать заранее, конечно, тоже нужно, но конспектируется "планируемое" решение не в блок-схемах или псевдокоде, а прямо на Clojure.
Т.е. вначале может и возьмешь бумажку с ручкой, но уже через минуту думаешь: "Какого чёрта?", открываешь Emacs, Slime REPL и пробуешь все уже там. Заработало? Сохраняешь в файл с исходником. Не заработало? Пробуешь дальше, не перезагружая программу. Все вычисленные данные, все переменные -- все остается; прямо в работающей программе можно переопределить любые функции и значения. Создается ощущение, что попал не просто в debug-режим, а будто только в таком режиме и работаешь.
На днях я экспериментировал с алогритмом Support Vector Machine, хотел научить классификатор по набору прилагательных от личать хорошие отзывы от плохих. С ресурса kinopark.by скачал все комментарии ко всем фильмам и рассортировал на два кластера: положительные отзывы и отрицательные (суммарно получилось окло 18Мб чистого текста). Выбрал все прилагательные (без окончаний) из каждого комментария; каждый комментарий закодировал дескриптором, содержащим 1 или 0 для каждого прилагательного из всего множества. Получился вектор размерностью около 10000. Вот такие-то вектора и скармливал классификатору на обучение.
Все это я делал только исключительно на Clojure. Все это, включая загрузку и разбор страниц с комментариями, заняло около 300 строк кода. За все время мне ни разу не потребовался дебаггер, и даже в голову не пришло писать unit-тесты (зачем, ведь функция каждый раз "пробуется" в REPL-е перед попаданием в исходник). И я не могу себе представить инструмента, более удобного для таких задач, чем Clojure.
Использованные библиотеки:
1.clj-http;
2.clj-tagsoup;
3.libsvm.
Clojure: Элитные языки программирования
my-clojure.blogspot.ru
What the?!?
blog.fogus.me
