Hi Matz,

I think everything that you said is true.  I guess people who are not
"real programmers" tend to favor minimalism.  I think one example is NumPy
which has been very popular with physicists at Argonne (or
Livermore?) National Lab since a long time ago.

Yes, this is because the capability of human brain is limited.  We in
engineering probably prefer simple, limited rules in programming because
programming is just a means in achieving the objective, which is
usually system design and optimization.

Regards,

Bill
============================================================================
Yukihiro Matsumoto <matz / ruby-lang.org> wrote:
> I'm sorry if you are bothered by my "smarter than" stuff.  It was only
> a parable.  But it has too important issue to ignore.

> There's two major opposite attitude in designing and criticizing
> languages (and perhaps other thing too).  They are minimalism and
> maximalism.  In a word, it's fight against alternatives.  One wants as
> less alternatives as possible.  Other wants opposite.  For example,
> people who hate "unless" in Ruby are minimalist.  And people who want
> as many choice as possible are maximalist.

> And I believe a good language design lies somewhere between these two
> extreme spectrum.  Because "ordinary people" often feel uncomfortable
> in extreme situation.  We don't use the simplest language ever
> (machine instruction) anymore.  We don't use the most complex language
> either (Ada? PL/I? whatever).  It's the matter of balance.

> Why no extreme?  Because the capability of human brain is limited.
> But it's capability is vary person to person.  Some people have bigger
> ability enough to handle extreme condition.  They even feel more
> comfortable in the situation.  You may remember the story of "real
> programmers".  They loved FORTRAN and Assembler.

> And language designers, often being a real programmer, tends not to
> understand these "ordinary people".  They are very easy to go extreme.
> That's what I meant by "smarter than" stuff.

> |Having too restrictive tools restricts you too.

> Yes.  Tools should not be *too* restrictive.
> And having too unrestrictive tools hinder your work.

> Again, it's the matter of balance.

> 							matz.