memory management war is not over

[yuridichesky]

Как-то в прошлом году ходил на Java-Day в Воронеже, который держал DataArt. Со знакомыми повидаться, на секту эту джавскую изнутри посмотреть (шутка) :-)

Послушал там доклад об устройстве GC в джаве, young generation, old generation, etc. Докладчик говорил, что GC написан исходя из гипотезы, что "достаточно много объектов не ссылаются на будущие

Comments

[tonsky]

Ад для GC создавало использование reflection-а в очень горячем месте кода, который плодил кучу объектов Method, Class etc. То есть конкретно эта проблема - в неочевидной, шероховатой интеграции м/у кложей и хост-платформой, на чистой джаве этой проблемы бы не было. Сами иммутабельные большие векторы прекрасно создавались и не уступали почти иммутабельным спискам.

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

[yuridichesky]

Да, с этим не поспоришь.

В том, что я написал, многое идет от моего подсознательного неприятия джавы, и как только повод представился, сразу захотелось еще раз с самим собой согласиться :-)

Тем не менее, явное указание типа там, где результат выражения как-бы однозначно этот тип определеяет, несколько настораживает. А целом Clojure нравится, хотя пальцы и не любят квадратные скобки.

[tonsky]

Квадратные - одна кнопка, круглые - две на каждую. Квадратные круче, мне кажется.

[yuridichesky]

Мои пальцы очень привыкли к круглым скобкам, и вот почему: круглые скобки ближе, за ними не надо тянуться мизинцем; открывающая и закрывающая скобки "привязаны" каждая к своему пальцу; не надо "думать", какую форму закрывать какой скобкой при записи выражений лиспа.