Read all of it before I looked at the date. (The date was added to the title just before I posted this.) I thought it very interesting that Clojure and Scala feature very prominently in the comments, and yet I just heard about them a few months ago. I feel like I've had my head stuck in the ground.<p>As for codebase size... Yes, Java is going to have more lines due to the nature of the language. He noted that experienced Java programmers don't see all that excess any more... He claims that's a bad thing, but I think that's what makes the language tolerable for them. They just look over them.<p>I also have to wonder how Mirah would stack up for him. I had high hopes for the language, but it uses the built-in Java types so all that verbosity is still there for anything that uses them. It doesn't really have all the syntactic sugar that Ruby does.
I have read this essay a few times, and I think that steve is missing an insight into modularity. We should be writing libraries for ourselves, not just piling code on top of other code. As an argument, I first offer a few propositions.<p>Any code upon which your project relies can be considered "part of the code base". As an example from Rails, it has become a somewhat common/accepted practice to notice a deficiency in a gem, fork it on github, fix it for your needs, and use it. This is especially common if your project depends on abandoned gems that you still need to use, for whatever reason. Even if this isn't a problem, I often need to look into internals to figure out where something is breaking.<p>Then, if code that your code depends on is considered part of the project, if steve was correct, then it would be very hard to use anything more advanced.<p>However, practical wisdom shows that higher level such as Ruby are more productive than lower level languages, such as C. Thus, the original premise is shown false.<p>If the original premise is false, then what is it that steve is noticing? I think it is about leaky abstractions. If you write libraries for yourself, with good, clean interfaces, you do not need to "notice" the lines of code from other parts of the project.<p>tl;dr It's about creating abstractions for yourself, not pure LOC count.
I realize it is in bad taste to comment before reading the whole article (only 1/3 through yet).<p>But I cannot help but see the irony in taking so many words to say that size is bad for programs.
I was disappointed to see this line:<p><i>design patterns – at least most of the patterns in the "Gang of Four" book – make code bases get bigger.</i><p>This hasn't been my experience. In fact, learning about and applying design patterns has been a crucial part of reducing code size in previous projects by eliminating copy-paste code. For example, a previous company had a lot of code devoted to traversing a particular data structure and taking various actions at each node. There were multiple variants of this traversal code, each with different actions but also slightly different (for no reason) in the traversal code. Applying the Visitor pattern allowed me to write the traversal only once, reducing code duplication and potential future bugs. I also believe it was more readable.<p>This was in C++ though - I'm not sure how much of his comments are directed solely at Java.
I just realised that the game that Steve is referring to in his blog is Wyvern. It was one of the earliest multiplayer games I played. I wouldn't mind playing it again, but it seems I can't reach the website (www.cabochon.com) right now.
Saying that a codebase needs to be small is like saying an airplane needs to be light: yes, it's true, in fact it's plain-and-simple obvious, but it doesn't reveal any of the hidden secrets and planning and so forth that are basically necessary to keep a codebase small and manageable. Even high-powered polymorphic languages a la Lisp will happily hand you enough rope to drown yourself in.<p>If you look at code as basically a description of what a program does, like, a formal description, it's unsurprising that conciseness and clarity are not entirely unrelated and that redundancy is annoying for anyone who has to read it. What's <i>not</i> obvious is the most clear or concise way to describe what the program does, and this is just as true in a computer language as in say a natural language.