Programmers, does this make sense?

[nancylebov]

http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html

The general argument is that the mere size of a big program is a problem in itself, and considerable efforts, in particular choosing a low-bloat language, are definitely worth the trouble.

I'm not qualified to judge it--it sounds plausible, but I'm guessing at what a lot of the words mean.

Here's a cute quote:

Java is like a variant of the game of Tetris in which none of the pieces can fill gaps created by the other pieces, so all you can do is pile them up endlessly.

Comments

[solri.livejournal.com]

I'm not much of a coder (programming is something I do once in a while when I need to get something done) but I'm glad I learned to program on a Sinclair ZX81 with 1KB of memory. One line of code too many and your program wouldn't load.

[selenite.livejournal.com]

I buy it. I make the same complaint about requirements: more = worse.

The IDEs march on

[thnidu.livejournal.com]

I'm reading this essay and appreciating it. But I had to look up the initialism or acronym IDE, which he uses all the time assuming his readers know it (which is probably valid for most of them, and certainly for his target audience).

Google, "define:IDE".

• I'm afraid I can't do that, Dave.
  
• A common hard-drive interface, standing for Integrated Drive Electronics.
  Nope.
  
• Stands for integrated drive electronics. Describes a hard disk with the disk controller integrated within it. See also EIDE.
  No.
  
• A type of hard drive interface. Provided as standard on Risc PC motherboards. It can have up to two physical drives, configured as 'master' and 'slave'.
  Still not that.
  
• An abbreviation for Integrated Drive Electronics, which is the name of a standard interface used to connect primarily disk and CD-ROM drives to a computer system. See also "EIDE" and "ATAPI."
  Uh-uh.
  
• Integrated Development Environment. A GUI workbench for developing code, featuring facilities like symbolic debugging, version control, and data-structure browsing.
  Ah ha!
  
• Integrated Development Environment, an IDE combines the editor, compiler and other useful tools in the same software package. ...
  OK, got the picture now. Thanks, Google.
  

Re: The IDEs march on

[nancylebov.livejournal.com]

I googled on IDE and got this as the first hit.

The other thing I looked up was unit test.

Re: The IDEs march on

[madfilkentist]

They are considered especially frightening around the spring equinox.

[madfilkentist]

My qualifications, for any passersby who may be interested: I'm a professional software developer, and I work almost exclusively with Java these days.

I read only about the first 20% of the article; it's rather long. But I'm not very impressed from that much. Code size as such is not the problem. Uncontrolled interconnectivity is the problem. Code can get arbitrarily large; what makes it go out of control is having to deal with too much at a time. In a successful large software design, there are black boxes within black boxes. From outside the box, you should only need to know how to talk to it, not how it works. (Non-software analogy: You don't need to know what happens mechanically when you step on the gas pedal of your car. You just need to know that it feeds fuel to the engine and makes it go.)

The size of each component is important. I've dealt with functions that were 500 lines long. They're impossible for a human mind to comprehend. If I need to deal with it extensively, it's worth taking the time to do what Stevey despises: I refactor it. This actually makes the code slightly longer in many cases, though it can also eliminate duplicate code. That doesn't make it worse, it makes it better, because I don't have to deal with as much code at a time.

a couple nits

[darius.livejournal.com]

I'm pretty sure I've read this author praising refactoring.

I think it's inconsistent to say large codebases are fine as long as they have low coupling, but a large function is bad no matter what. The typical 500-line function in the wild should be exterminated, though, yeah.

Re: a couple nits

[madfilkentist]

It's really not inconsistent. The central issue is how much you have to hold in your mind. A large codebase is OK as long as most of it is safely behind the curtain under normal circumstances.

There are a few cases where a 500-line function might be OK -- for instance, if it's 500 initializers in a simple sequence and there's really no logic within the function.

Re: a couple nits

[darius.livejournal.com]

I agree with the principle that you want to deal with parts much smaller than 500 lines that make sense on their own, though they're not necessarily functions. I don't think there's any difference in kind from "a large function is OK as long as most of it etc."

I'm going offline now -- happy holidays.

[darius.livejournal.com]

A Deepness in the Sky had some cool bits about this issue, where Pham Nuwen learned the horror of millennia-deep codebases.

Another background check: I was employee #6 at a startup making a new Java IDE (over 10 years ago when the market for such was relatively wide open). They already had around 100,000 lines of Java code then; it was already a drag on their progress and on me getting up to speed. (They were all excellent programmers in different ways.) I've done some other Java work, but I've always preferred other languages with fewer compromises for popularity.

Sometimes big is wonderful: Paradigms of AI Programming (http://norvig.com/paip.html) has over 900 pages of superlative code to learn from (divided about half and half between English and actual code). But it's as concise as the author could make it, and I'm in favor of more in sort of the same way I'd welcome more Beethoven sonatas. The author considered (http://www.norvig.com/python-lisp.html) translating it to Java -- this file (http://norvig.com/paip/search.lisp) is roughly equivalent to this directory (http://www.cs.berkeley.edu/~russell/aima-java/src/aima/search/). So that didn't fly.

I agree that a lot of the time, if you're good, someone needing to deal with your code will only need to deal with a bit of it. But life always throws curves, things that don't fit in your framework; what happens then, well, are you talking about revising a short story, a novel, or a shared-world series of dozens of books? Of course it makes a difference.

[darius.livejournal.com]

(Note that the 500k lines he's talking about translates to about 8000 pages. That's with considerably fewer words per page than for English text, but still.)

[sethg]

If I try to respond in my own words I'll take an hour, so I'll just link to Reg "raganwald" Braithwaite on green, yellow, and red code and Martin Fowler on technical debt.

[nancylebov.livejournal.com]

Thanks. If I understand your general point, it's that the problems of size can be (somewhat?) kept under control by understanding and sequestering them.