Orchid XP v8 wrote:
> It's more that when you have a very large number of things, some of 
> which are important and some of which are incidental, you tend to forget 
> about some of them.

Only if you're using a functional language and therefore you have to pass 
everything around all the time, even if you're not using it right now. :-)

> Also, if you *change* how your code works (e.g., you add an extra layer 
> of indirection), having a type system means you can just follow the 
> error messages to find the exact places where you need to change something.

This is helpful, but it also seems to not be much of a problem in practice. 
You have an object that represents a concept, and that's where you make the 
change. Yes, I suspect this is very problematic for a dynamically-typed 
functional language (like Erlang, say). But in an OO language, you don't 
have (for example) "state" and "list of states": You have "where I am now in 
the state machine processing". It's exactly this kind of change that good OO 
design is trying to make trivially simple. (It isn't, of course...)

I suspect it's harder than just "follow the error messages", because you 
have to decide the logic of what to do at each point anyway. If you don't, 
then the "duck typing" works exactly as it should. If there are many places 
in your code where you depend on whether you have an extra level of 
indirection, and they're not all obvious (e.g., in one class), then your 
code is poorly organized and your algorithms probably depend on the 
assumption that you don't have an extra level of indirection there. If there 
aren't that many places, finding them isn't that hard if you know how the 
code works, and having a good development environment helps you find them.

One of my problems with Erlang is that the documentation for the libraries 
and especially the dev tools suck badly. There's all kinds of system 
information that's useful, but it's like reading man pages to learn how to 
design an X application - if you don't already know how it works, the 
tidbits in the documentation isn't going to tell you. There are half a dozen 
tracing tools and log display tools and everything, and nowhere does it say 
"this is the order you combine these six things to get an idea of how the 
system works."  Typical open-source big-company stuff - sit down with the 
other programmers and ask them. Except when you're not part of the company.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message