low-level approach

[Kyle Lahnakoski]

Billy Tanksley wrote:

> No -- you're absolutely right.  They're ugly.  But monads are not 
> Haskell! You claim that Haskell has no advantages over any other 
> languages, when in fact Haskell merely has ONE disadvantage.  There's a
> HUGE, critical difference there!  We need to learn from Haskell.

Oh yes!  I did not even follow my own rule: we are only looking into the
good aspects of languages.


> Of course, I'm exaggerating.  Order isn't absolutely good; I like 
> unordered things.  Names aren't absolutely bad (APL is the exception,
> not the rule, and it proves the rule by helping the user use names).
> My point is that you can't afford such a dogmatic view.

I am fine with this.


> >I did not mean to say that meta programming, or postfix notation, was an
> >academic novelty.  I meant to say that Forth's particular concatenative
> >style appears strictly academic to me.
> 
> Then why on earth isn't Forth used in any college classes?  It's ONLY used
> by engineers, almost none of them CS people.  How could you call that
> academic?  I really am honestly confused here.

Just because I label a concept or thing academic, it does not mean it
necessarily came from, or is used in, academia.  Forth was designed from
certain principals that, to me, conflict with my intuitive concept of
expressive.  I only label these principles academic because they do not
appear to be useful.

Forth used by engineers makes perfect sense!  Engineers write small
programs, programs built for hardware (very likely small hardware). 
Forth, is well suited to these types of devices.  Now I can see that
Fourth's principles of design are quite helpful in this area of software
development; not academic at all.


> >I see your point that the combinators certainly have the potential to
> >minimize code length, but that is not expressiveness.  If strict code
> >length defined expressiveness then zipped source code would be
> >considered as having superior expressiveness.  For an language to be
> >expressive it must be able to optimize the balance between code length
> >and human readability.

> What combinators _do_ is make dataflow clear, and computing is all about
> data flow and modification.  Combinators allow the programmer to *express*
> that.  Anyone who's ever used them recognises the feel of programming with
> them: ideas just flow out, and often don't need to be corrected; changes
> have only local effect, unless certain dangerous words are present (words
> with deep stack-effect), and those become obvious with a little experience
> or watchfulness.  Compare this to naming-based code: you don't know what
> things any specific change is going to affect, because the effects depend on
> the scope of the variables affected by the change.

Maybe I am missing your point.  But why is clear dataflow a good thing? 
Whenever I think of managing dataflow I can't help but to think that I
am doing more work. Maybe someone can jump in here and help me
understand.

I can see the functional aspect of Forth being useful (lack of side
effects as you mention).  I can also see linear aspects of Forth (again,
a lack of side effect).  I do not see how dataflow provides semantic
advantage.


> I must point out that complex dataflow is complex regardless of whether it's
> expressed by variables or by explicit dataflow notations.  And with
> variables, the dataflow MUST be held entirely in your mind; it's not
> possible to write it in the program.  With dataflow, the flow only has to be
> thought of once, and from then on you can forget it -- dataflow
> modifications can be made locally.

For dataflow problems, dataflow notation would certainly be a good
thing.  I am really concerned with problems that do not have a dataflow
aspect.  SQL is an example of a domain specific language that removed
all dataflow specification.

Every time you specify dataflow you imply a certain computation model. 
When that computation model changes then the program must be reversed
engineered to its important results and reprogrammed in the new
computation model.  I am thinking of distributed and quantum computing;
both highly parallel computing models.  Tell me more about Forth in a
parallel world.


> >All this optimization you mention must be done by the human programmer.
> >This optimization should be done by the compiler.  If you remove the
> >necessity to specify how a program will run, you are left with much less
> >to specify and and easier development time in general.
> 
> This optimization MUST be done by the programmer: he's the only one who
> knows what his task will need next.  The compiler can make guesses after
> undertaking extensive analysis, but will never better the programmer; the
> compiler is better used as a domain expert on the specific optimizations
> needed for the target machine (alignment, caching, number of registers, and
> so on).  After all, ordering the operations is an obvious and trivial part
> of designing the algorithm.

We disagree on the roll and abilities of the compiler.  I believe the
compiler should be responsible for as much dataflow as possible.  If
dataflow is not part of the problem then it should not be specified.

In general good compilers outperform humans.  There may be a problem
where a human can produce more efficient code, but then that can be
taught to the compiler.  The compiler is an expert in many things, one
of those things should be dataflow.


> You're also missing what I said above: a parse tree doesn't give you any
> more textual flexibility than a tokenized concatenative language naturally
> has (sometimes a lot less), and it's harder to get and apply.  This is why
> it's taken so long to come out with decent refactoring tools.

If parse tree were so difficult to manage then Smalltalk would not have
so many refactoring tools.