Re: What's right with FORTH and wrong with c.l.f.

John Passaniti <nntp@[EMAIL PROTECTED]
> wrote:
> Jonah Thomas wrote:

> > But why go to that trouble when locals will put things wherever you
> > want with no thought required? Similarly, why accept a simple string
> > package that requires you to think, when you can have a complicated
> > one that does everything you want behind your back and gives you
> > results with no thought required?
> 
> Questions like this stem from an underlying assumption that all 
> programming is the same.  Embedded systems, game programming, web 
> programming, desktop applications, database applications, casual 
> scripting, system tools, and so on... all the same.  Same needs, same 
> priorities, same methodologies, same constraints, same same same.
> 
> Wrong wrong wrong.  Why accept a simple string package?  Because in
> some contexts, that's exactly what you need.  You need explicit and
> direct control.  You need efficiency.  You need a lack of abstraction.
>  Why 
> then are there complicated string packages?  Because sometimes strings
> 
> are not the problem you're trying to solve.  Because sometimes you're 
> more than willing to put up with underlying complexity and implicit 
> mechanisms because it makes expression of the algorithm clearer. 

So Forth might benefit from both approaches. Simple low-overhead string
functions for the occasions those are useful, and something that
imitates a complex easy-to-use string package for the times when string
performance is not an issue. When dealing with strings is less than 1%
of the problem, why call in another language to do that? So, both could
be useful.

I'm interested in the possibility you might perhaps get the best of both
worlds. Start with a simple system that's very good at getting low-level
results simply, and it might lead to a more complete system that isn't
as complicated as people now prefer. That would be a win, if the reality
turned out that way. I don't know enough to be sure it couldn't. At some
point there's a minimum complexity you can't reduce, and attempts to get
rid of that only shift it around. But I don't know where that minimum
level is. Maybe some of the things people think are essential for
intermediate results aren't actually essential after all.