Re: Just one more anecdote
Date: 1 Aug 2005 22:40:25 -0700
Message-ID: <1122961225.078706.285730_at_g43g2000cwa.googlegroups.com>
dawn wrote:
> Marshall Spight wrote:
> >
> > I just have to pop in here and say that out of all the design
> > principles
> > I've ever picked up or articulated myself, I put Simplicity as the
> > most important.
>
> The simplest design might be based on a more complicated underlying
> model, right?
Well, uh, no. Simplicity derives from underlying simplicity, in my experience.
> I suspect I would have willingly traded houses at that point in spite
> of my house having the smallest design. :-)
Okay, you're conflating small physical size with few concepts.
When it comes to houses, I like 'em big and complicated! Bigger is better! High ceilings and balconies and stairways and, hey, minarets, why not, what the hell.
For source code and conceptual models, a nice comfy bungalow is best. Remember: you have to clean it yourself. You don't want to be vacuuming all those grand ballrooms every weekend.
Okay, metaphor stretched all out of shape now. Back to regularly scheduled programming.
> But, yes, I do accept your point and agree to a large extent regarding
> design. But just because a system could be implemented using paper and
> pencil, a much, much simpler set of tools than a computer, does not
> mean that is a better idea.
Argh! I just finished with the last metaphor.
> I do employ this "simple is best" approach in the design of a data
> model, avoiding adding in "maybe we will want this data captured in the
> future" attributes.
Okay!
> If one system does the exact same thing as another, but the first is
> simpler, it might not be equally scalable. If they are fully equal in
> what they do, what they can do, and how much it costs to do it, and one
> is simpler, then, yes, the simpler one is better. I've never seen the
> tradeoffs come down to such a obvious choice, however. cheers! --dawn
Yes; usually the more complicated one is worse in many different ways.
Sure, we add complexity to applications to achieve specific performance characteristics. But this isn't application design we're talking about in this newsgroup. It is language design! The two are both software but they are quite different in many important ways.
An excellent book for studying languages and language *design* is "Concepts, Techniques, and Models of Computer Programming" by Peter Van Roy and Seif Haridi.
Does an AMAZING job of looking at how adding or subtracting single concepts from a language can radically change the expressive power.
Marshall Received on Tue Aug 02 2005 - 07:40:25 CEST