Category: it

добрый

А вы используете дебаггер?

Сабж, собственно.

Под словом "дебаггер" я подразумеваю традиционный tool, то есть всякие breakpoints и подобное.
gdb дебаггером считается. Зацепленный slime к lisp-процессу - ну, наверное тоже, хотя тут уже границы размываются.

Если да - то каким, для каких целей и в каких условиях/ситуациях? Если нет - то почему?


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

Почему так - ну во-первых потому что я луддит. Во-вторых, потому что я считаю, что надо понимать программу без дебаггера (а дебажные принты лучше запоминаются, чем watch-и в дебаггере, чисто психологически), что логирования должно быть достаточно для 98% проблем. В-третьих, потому что в 90% случаев чтобы использовать debugger нужно сделать множество приседаний (например, пересобраться, или взгромоздить xdebug на удалённую машину), а я ленивый (а иногда эта удалённая машина - кастомерский продакшн-сервер, и туда ничего нельзя ставить).

В моей практике без дебаггера плохо только в java (точнее, там использование дебаггера удобнее, чем логирование и принты), ну и в некоторых специфичных случаях типа там хитрых C++-ных приложений с использованием кучи сторонних библиотек. Вполне допускаю, что есть направления и проблемы, где без дебаггера никак.

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

Троллинг в стиле thesz ;)

Почему в стиле thesz - Сергей любит ссылаться на исследования, выводы из которых можно посчитать подтверждением какой-либо его мысли. Особенно он любит напирать на то, что ошибки в программах на Хаскелле сложнее не заметить. И несмотря на то, что во многих случаях кажется, что он близок к правде, хочу показать, почему я не люблю такие аргументы.

Итак, имеем смешное: http://habrahabr.ru/post/161967/, цитата (выделение моё): "Группа греческих учёных под руководством Диомидиса Спинеллиса провела интересное исследование чувствительности десяти популярных языков программирования к ошибкам и опечаткам при наборе текста программы.

...

Скрипт на Perl вносил в исходный код тестовых задач ошибки, имитирующие естественные ошибки при наборе программ

...

Языки со статической и/или строгой типизацией, что вполне ожидаемо, проявили себя наилучшим образом — C#, Java, С и C++ показали очень похожие результаты — около 10% не замеченных компилятором, лучший результат (8%) у C++. Немного хуже проявил себя Haskell — около 15%"



Ну то есть, согласно этому исследованию, компилятор С++ лучше ловит ошибки, чем компилятор Хаскелля.



В чём смысл моего поста? В том, что не все исследования одинаково полезны.
добрый

Функциональное мышление: Тонны трансформаций

http://habrahabr.ru/post/161249/

Scala позабавила жопами:
factors.foldLeft(0)(_ + _)


А все остальные, кроме Хаскела и Кложуры - многословием.

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

Куда мигрировать с макоси: linux vs. windows

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

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

Collapse )
добрый

Про технологии, или Haskell не нужен ;)

"Вообще, положа руку на область желудка, программирование в IT бизнесе имеет примерно такую же важность, как вождение грузовика в доставочном бизнесе. Да, без программистов (водителей) не обойдешься, но в результате sales и marketing рулят и бибикают." отсюда

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

Итого, спор о языках - это спор об автомобилях.

Осталось сделать таблицу вида "PHP - это мотороллер 'Муравей'", и все желающие смогут сраться и по поводу ЯП тоже ;)
добрый

Говно в common lisp

Я common lisp знаю не очень хорошо, я больше по scheme, но тем не менее, раз зашла такая тема, напишу несколько (не 10, сорри :) ) недостатков common lisp.

1. нет бесплатных хороших кроссплатформенных реализаций. sbcl не работает под винду, имеет проблемы в макоси. abcl малораспространён. Коммерческие лиспы дороги.
2. типизация. В некоторых применениях откровенно раздражают runtime ошибки, которые даже в окамле невозможны. Но этот же пункт является и достоинством.
3. для меня это не минус, но по факту это минус - синтаксис. Простые люди его боятся. В некоторых случаях лисп многословен [типичный пример: (remove-if #'(lambda(x) (> 5 x)) my-list), ибо карринга нету; ну или вспомним CLOS, который нередко похож на MyClass myclass = new MyClass(); ]. Это фиксится (например, через reader macro для введения специального синтаксиса для каррированных лямбд; в случае CLOS - через макросы и MOP, гы гы), но для мелких наколенных однострочников фикс немного тяжеловат.
4. практически все более-менее хорошие реализации жрут память. Это является большой проблемой для использования common lisp внутри virtuozzo, например. hello world на sbcl забирает гиг VSS и ~120 метров RSS (для сравнения - plt scheme укладывает в 60 метров RSS веб-сервер и сервлет мелкого сайта с несколькими сессиями в continuation based фреймворке).
5. standalone binaries вообще и кросскомпиляция - среди бесплатных реализаций я не знаю ни одной, в которой это было бы удобно сделано.
6. сложность. Сам по себе лисп кажется простым, но когда у тебя вылезет трейс на 30 строк (из которых 10 - это slime, и к твоей программе они отношения не имеют), то довольно непросто разобраться в том, что где-то какой-то символ не заэкспортился как надо было. Ну и кроме пакетов много областей, где надо разбираться (тот же CLOS; conditions/restarts, да даже вроде бы банальный asdf - сравните с require в plt scheme, и вы поймёте).
7. интеграция с не-лисповым кодом. Несмотря на ffi и подобные техники, интегрировать лисп с чем-нибудь ещё в лучшем случае неудобно, в худшем (когда надо позвать лисп откуда-нибудь) - жопа.

Вроде всё.

А про scheme могу сказать только один практический недостаток (2 и 3 из списка выше для scheme тоже справедливы, но это продолжение достоинств; 7 тоже справедливо, но для разных scheme в разной степени) - production scheme не существует, в смысле, любая production ready реализация scheme сильно расширяет стандарт, и называть это scheme нельзя, ибо на другой реализации твоя программа работать уже не будет. common lisp в этом плане намного удачнее. В этом аспекте правильнее говорить не просто scheme, а, например, PLT Scheme. А, ну и scheme либо быстрые, либо удобные :) Хотя PLT Scheme на глаз заметно быстрее питона и PHP, по мне так этого много где достаточно.
добрый

Про OOD

Либо я туплю (что вероятно), либо PHP говно (что несомненно), либо OOP говно (что высоковероятно).

Collapse )
добрый

Сервис для хранения конфигов

Конфигурю тут emacs (заодно может поиграюсь с textmate, но пока что он меня особо не возбуждает - да, есть пара хороших вещей, в первую очередь в GUI (в чём emacs традиционно слаб, чо уж греха таить), но macos only, кодировки, нет slime (да, я всё ещё надеюсь когда-нибудь писать на common lisp в production), кастомизация слабее, чем в emacs и так далее) и возникла у меня проблема - хачю не просто бекапить конфиги, но держать их во внешнем по отношению к моей машине VCS.

Конторские машини отпадают - не хочу привязываться к конторе, домашняя моя извне недоступна, somewhere.ru - не под моим контролем (то есть ненадёжна), внешний винт у меня во-первых дома, а во-вторых там ntfs (то есть time machine не канает, да и вообще, зачем тут проприетарщина?).

Остаётся внешний сервис типа sourceforge.

Внимание, вопрос - а где именно (на каком сервисе) сейчас модно хранить конфиги?

Требования:
1. доступен отовсюду
2. бесплатен (либо стоит не дороже 5$ в год и процедура оплаты проще некуда)
3. какой именно VCS - похрену совершенно, лишь бы на маке он был (то есть все разумные подходят)
4. доступ к содержимому VCS - только авторизованным пользователям (и на r/o в том числе), анонимусы либо вообще запрещены, либо я могу указывать, к какому каталогу разрешён анонимный доступ
5. надёжный - не люблю менять привычки. 24x7 не надо, но и лежать днями тоже недопустимо
6. политика сервиса должна допускать его использование в качестве хранилища конфигов (я не читал правила sourceforge, но логично предположить, что там надо какой-нибудь софт держать, а не просто мои личные конфиги, которые я не собираюсь дистрибьютить).
7. простая регистрация, ничего лишнего (не надо мне всякой почты, wiki и подобного говна, то есть если они есть - должны быть необязательными)

В конфигах у меня ничего приватного не будет, так что пункт 4 - nice to have, остальные - must.