Comment by stcredzero | Hacker News Reader

Comment by stcredzero | Hacker News Reader

Parent Full thread

I have noticed that when a program is small enough that I can see all of it, then I can reason about all of it, and when I cannot see all of the code, then I cannot.

You've made a powerful observation about how programmers and human minds in general interface with complex systems. What if you had language semantics that could let you ignore most of your codebase with 100% reliability?

I've had a long career dealing with very complex "enterprise" software for multi-nationals. Semantic tricks that let you make far-reaching deductions and securely ignore most of the code are absolutely vital in contexts like that. It was precisely in the parts of the code where things weren't structured to allow this, that things broke down, and everyone dreaded to check-in code.

I'm disinclined to waste energy on what I view as premature optimisation.

There are certain contexts where one already knows that this sort of thing is not premature optimisation. (Granted, lots of programmers seem to make a fetish of acting like they are in such a context, when they really aren't. Analogous to: http://xkcd.com/538/ )

Most of my professional life has been reading other people's code and finishing other people's programs. One thing I've noticed is that nobody has ever asked me to help fix a small codebase.

Another thing I've noticed is that having well documented interfaces between small components is extremely effective at improving isolation time.

Another thing I've noticed is that interfaces with two or fewer arguments (none of which boolean) tend to be used correctly more often than interfaces with a large number of arguments, or booleans.

I would very much enjoy having a conversation about those language semantics. I haven't noticed any language semantics that would be useful in that way, however I have noticed a number of these "disciplines" that are helpful at reducing search time, reducing defect count and increase performance (run-time and programmer).

What exactly are you thinking about?

I really like your observations, and have noticed pretty much the same thing.

Your point about the boolean arguments especially, I can't tell you the number of times I've painstakingly documented the parameter in the /// section of the function (in c#) just to make sure it's clear what passing false actually means.

I should just create an enum{ doTheDance,dontDoTheDance} with two values instead, often thought about it, but for some reason never actually done that.

Just do it!

The next guy will thank you.

Another thing I've noticed is that having well documented interfaces between small components is extremely effective at improving isolation time.

Good point. There aren't languages that do a complete job of absolutely enforcing such patterns of behavior, but there are environments that do a fairly good job of encouraging them.

Another thing I've noticed is that interfaces with two or fewer arguments (none of which boolean) tend to be used correctly more often than interfaces with a large number of arguments, or booleans.

Goes to the same point. Most of my work with complex stuff was in Smalltalk, and there is practically no enforcement of anything in that language. However, my experience is that it's practical to have codebases that adhere very closely to a number of patterns or coding standards. Also, there were very powerful search facilities in the environment that facilitated powerful deductions about the codebase. Often, work would involve making deductions, figuring out how those could be broken, then quickly searching for these instances. Often enough, the deductions could stand and make debugging and modifications easy.

Your preference in interfaces is also the one preferred by better Smalltalkers. Also, the environment is built up entirely of small components. One path of least resistance is to build new systems along the same lines. (That said, one could still write Fortran and COBOL in Smalltalk, and I had to deal with this professionally.)

Reply on news.ycombinator.com