Typing system vs. Java

[Donn Cave]

Quoth Courageous <jkraska1 at san.rr.com>:
(quoting Dave Brueck>
|> My take is that, especially in Python, type-related bugs make up an
|> extremely small segment of all bugs, and the examples I've seen of
|> specifying all that type information dramatically increase the complexity
|> of the source code, even to the point of possibly _introducing_ bugs.
|
| I feel alot of synergy for the above sentiment and believe it is quite
| insightful. Of late, I've been thinking alot about lexical, grammatical,
| and semantic complexity as it applies to computer programming and
| the various different correctness memes which float around in the
| community. I've concluded  that comprehensible tersness trumps all
| other measures of merit.
|
| I believe that there is a sort of Occam's Razor of Coding, as it were,
| where given two different programs which execute identically, the one
| which is shorter, simpler, and easier to understand is the better
| program, notwithstanding any principles it may or may not adhere to.
|
| Various different rules which have crept up over the years such as
| "don't use global variables," and "practice strong encapsulation,"
| and so forth are all only distractions and are useless to the degree
| that in any particular context they don't satisfy Sir Occam's relentless
| blade.

The hard problems are really in large systems, though, aren't they?
How do you apply this razor to IIS, for example, or SunOS?

This afternoon I finally forced myself to get back to work on a large
piece of software that I want to modify.  It's a network server that
performs a fairly simple function and isn't really all that big, but
it's inordinately difficult to work with.  I could show you some
excerpts, you'd laugh, but I'm sure the author would argue that his
code is shorter and simpler, and for him I suppose perhaps even
easier to understand.

But the worst part is just that it's big and you have to follow
the flow of control all over the place to understand what interacts
with what, and to some extent you have to retain that understanding
while writing your part.  And this is "Hello, world", compared to
real industrial strength big software.

Can you make that stuff manageable by keeping things short and simple?  
Well, maybe yes, but it isn't enough to just meet some definition of
short and simple.  Classic software engineering models like structured,
object oriented, functional programming all add some modular discipline
to code at the expense of straightforward brevity, and you need it to
survive.  The enemy is not so much the small scale complexity of a
few lines of code, but the complexity of interactions in a large
system.  Make that short and simple, and you're cooking - and you're
probably doing pretty well with your common software engineering
models.

I'm here because I need to reduce complexity, my head doesn't do
too good with the complicated stuff.  And I make mistakes, a lot.
Python helps.  It handles complicated stuff like managing storage
so I can deal with objects at a more abstract level.  It handles
mistakes with exceptions, so I don't have to account for all the
things I don't expect.  Those two, anyway, make for shorter and
simpler code most of the time, but you know there's a lot more
there than just how many lines of code.  For one thing, in my
opinion those two features alone make a big difference for the
implementation of library functions, they reduce the complexity
of interfaces in a very important way.

If you look at a functional language with strong static type
checking, it's doing the same thing from a different direction -
reducing unnecessary side effects and so forth.  But it also
benefits from a model that allows the compiler to infer some
degree of correctness in the relationships in your program.
It can't do your job better than you, but you can use it to
do your job better.

	Donn Cave, donn at drizzle.com