Hacker News Reader

Comment by va_coder | Hacker News Reader

Are Clojure shops experiencing this? One of the things that makes Clojure appealing to me is the lack of types and simplicity (IMO) of the language.

View on HN

I wrote a medium sized project in clojure at my last job and it was a good experience. The team was small (under 5) so the hiring and training wasn't an issue for us. I never had a problem reading clojure code, and the only major headache I can remember, which was our fault, was that clojure keywords (think ruby symbols) used to be turned into interned strings which are stored in permgen and we were running out of permgen space. I believe this has been fixed in recent versions of clojure, but I'm not 100% sure about that.

http://eigenjoy.com/2011/03/02/clojures-keyword-can-fill-up-...

ruby (MRI ruby, even!) has that same bug.

So does Erlang, but it's not really a bug. Symbols (atoms, whatever) are guaranteed to be a unique identifier, so the fact that they're allocated and exist for the duration of execution isn't really surprising.

It's just something you need to be aware of.

not a bug, a known issue: interned strings aren't GC'd in python, erlang BEAM, many runtimes.

Jdk 7 puts interned Strings into the old generation instead of the permgen. Maybe give that a try.

So I'm not a big lisp guy, but from what I understand and what I know of CL, lisp is in a much better place on the expressiveness:simplicity relationship than Scala.

That said, some of these issues (slow collections, talent availability, tools) have nothing to do with language complexity and might affect almost any relatively new programming language if the implementors didn't consciously work to counteract it.

"That's just conpletely false. I don't know where your assertions are coming from but language design absolutely has a great deal to do with what kind of tools / developers you can expect to find to support the language. I'm all a-huff with the sheer gall and ignorance of your assertion that I'm just not even sure what to do. Bad developer. >:( bad"

Revised: fine ok maybe a bit harsh. My opinion is that language design would be extremely influencial over how people implementing collections/tools/compilers go about doing their work and what the end result of their efforts would look like. In fact they probably are more telling of a design than anything else. That last part was sort of bs guesswork but it sounds right. Happy now?

Lisp is in a very different domain, being dynamically/uni-typed, whereas Scala is statically typed. Statically typed languages don't aim only for simplicity/power ratio, but also for various compile-time guarantees.

I started writing a response to this but it got bloggy so I did that instead: http://bit.ly/u1Y6Lc

Reply on news.ycombinator.com