пятница, 26 февраля 2010 г.

день третий

10, 10, 10, 10

четверг, 25 февраля 2010 г.

Вышел четвертый выпуск журнала "Практика функционального программирования"

Сегодня появится четверный выпуск электронного журнала "Практика функционального программирования".
Журнал всегда радует хорошими и полезными статьями, читать всегда интересно и приятно. Спасибо создателям и авторам за качественный материал.
И отдельное спасибо за дополнительную заботу о читателях: электронные выпуски доступны в нескольких фоматах:

  • Для eBook и низких разрешений экрана A5, 144 с., 1,0Mb PDF, крупный шрифт

  • Для чтения с большого экрана A5, 122 с., 980K PDF, для экранов 20" и больше

  • Для печати A4, 105 с., 1,4Mb PDF

  • Для экономной печати A4, 59 с., 1,3Mb PDF

  • HTML-версии отдельных статей

Читателям предоставляется ответная возможность проявить заботу о журнале. ;)

понедельник, 22 февраля 2010 г.

Работает -- не трогай!

Водопровод, эта такая странная фигня, что после поломки/починки одного участка, через непрогнозируемый интервал времени, ломается в совершенно неожиданном и несвязном со старой поломкой месте. А если происходит чудо, и ничего не ломается, то тогда бляцкие шаловливые руки все равно надирает полезть туда, куда не надо.
А ведь казалось бы, все и так хорошо, живи и радуйся. Но нет, через несколько дней засомнивался, решил что пока выходные, то вооот здесь нужно на всякий случай перемотать и еще самую чуточку подтянуть вот эту хрень... . Вообщем, конечно же, сорвал резьбу.
Часть дня обещает пройти интенсивно, будет богата впечатлениями. :)

P.S.
С благодарностью вспоминаю собственную прозорливость -- не поленился когда-то купить заглушки: предотвращает затопление соседей (и все сопутствующие этому радости) при утреннем включении горячей воды. Проблем будет уже более чем на половину меньше. :)

день второй

21, 26, 14, 7.

воскресенье, 21 февраля 2010 г.

Кому-то повезет

По ссылке френда bormotov прочитал интервью с провокационным названием "Называю вас обезьяной". Статья интересная, дядька прикольный -- вообщем "доставило". Чрезмерное упрощение не портит статью, на мой взгляд. В конце-концов, это интервью.
Я конечно и так знаю, что есть исключения: женщины, которые вопреки распространенному мнению, занимающиеся математикой и программированием успешнее своих коллег-мужчин. Правила, исключения -- дьявол всегда в мелочах. Поэтому мне несколько более интересна литература, которая затрагивает эти самые мелочи. Например книжка "Язык взаимоотношений (мужчина и женщина)". Обычно такие названия я отбрасываю, расплодилось их чрезмерно, но эта книжка оказалась интересной, несмотря на некоторые спорные моменты. Радует факт, что чтиво подобной направленности пока еще выходят на "просвященном западе".
После прочтения этих двух ссылок, возникла следующая мысль. Тот, кто более-менее грамотно умеет распределять людские ресурсы -- уже имеет преимущество перед конкурентами. Тот, кто пошлет нахуй радикальных теоретиков от идей равенства или преобладания полов, и будет делать свой выбор, более тонко учитывая природные закономерности и замечая очевидные исключения -- получит офигенное преимущество.

Я конечно же опять придираюсь

Захотелось глянуть, что javavmwrapper пихает в environment.
Написал, поглядел и почти успокоился.
for(Map.Entry item: System.getenv().entrySet()) {
System.out.println(item.getValue() + "=" + item.getKey());
}
Но черт надрал меня полюбопытствовать, добавив пару строчек.
for(Map.Entry item: System.getenv().entrySet()) {
String key, value;
key = item.getKey();
value = item.getValue();
System.out.println(key + "=" + value);
}
А компилятор глаголит:
incompatible types
found : java.lang.Object
required: java.lang.String
key = item.getKey();
^
Т.е. значение вызова getKey (и getValue) надо явно кастить к String, тогда работает.
Ну с какого хрена оно мне возвращает Object, когда в документации явно обещали коллекцию с элементами, в которых будут строки: public static Map<String,String> getenv().
Я конечно могу что-то упускать: мысль мелькнула, десять минут в документации, пару строчек -- появился результат, "всем спасибо, до новых встреч". Но со стороны как-то нелогично и неаккуратненько смотрится, при обилии явно указанных типов.

воскресенье, 14 февраля 2010 г.

"The intention of saying Java is strongly typed is to give the impression of robustness"

Смотрю статью на википедии о языке Ява: Typing discipline: Static, strong, safe, ...

Java SE 6 используется полным ходом, уже скоро на подходе SE 7, а статьи 11-летней давности (by Harold Thimbleby), похоже, актуальны и по сей день.

Java is strongly typed, but the type correctness of a Java program is not known at compile time. In other words, Java is not statically typed (like ML). The intention of saying Java is strongly typed is to give the impression of robustness. Type robustness would be achieved by strong static typing, where the compiler detects type errors before a program is run. Like Java, both BASIC and LISP are strongly typed, but neither are statically typed; their type systems do not seem to be what the Java hype seems to imply! Our discussion, above, of the duck and lame duck's equals method illustrated some problems of Java not being statically typed.

The following example demonstrates Java's lack of strong static typing; it involves creating an Object and casting it to a Character. This is statically correct (i.e., it compiles without error), but at run time it throws an error (a ClassCastException), because Objects are not Characters. (Sophisticated compilers might detect the problem (though whether they -- and they alone -- should is an interesting question of compatibility), but they can easily be defeated by passing an Object as a parameter to a method expecting a Character: the result will be the same.)
Character c = (Character) new Object();
// always causes runtime java.lang.ClassCastException
Apparently the assignment is not questionable, for
"Java prevents incompatible assignments by forbidding anything questionable." p121