Re: [stack] A Joy VM in OCaml

This forum seems to have died.
Perhaps others had discovered what I only now discovered:
cat-style can be as deceptive as BASIC was in the 70s.
You think you're programming, but you're just hacking a mess.

This forum prompted me to investigate the power of
linux 'pipe programming',
which is astoundingly decetive.
It's magically easy, for small jobs, but quickly becomes unmanageable.
== Chris Glur.


On 9/4/09, Tom Schouten <[email protected]> wrote:
> On Fri, Sep 04, 2009 at 01:52:42AM +0300, chris glur wrote:
>>
>>
>>    >> OTOH perhaps such "democratic committee" projects aren't feasible.
>>
>>    > I believe good results require a sufficiently annoying `itch' locally
>>    > applied to a single implementor / designer.
>>
>>    Yes, you're talking about making fish.
>>    I'm talking about making fishermen.
>>
>>    Most of the value-added in computing comes from the soft: psychology
>>    and human-cognition. OTOH the Hard: technology; is easier to talk
>> about.
>>
>>    Eg. the only justification for music is 'emotion manipulation'.
>>    But that's near impossible to quantify or describe.
>>    OTOH volumes are/can-be written about the technicalities.
>>
>
> Interesting viewpoint.
>
>
>>    My previous laboured example, perhaps didn't prove the conclusion:--
>>
>
>
>>    The brief sequence of functions described by:
>>    " pstree -p | cut -b25- | grep su ".
>>    which does:
>>    print the process-tree,
>>    but cut-out and show only the part of the lines, from the 25th char
>>    to end-line,
>>    and show only lines which contain the string "su";
>>
>>    shows a very cognitive economical way of achieving the goal.
>>
>>    And has the very important advantage of being achieved by successive
>>    refinement.
>>    Which makes for increased productivity.
>>
>
> What you described is a `process' view on approaching a problem.
> The combinator-style that Joy/Factor/Forth/... promote is an
> example of this.  This is also called `point-free' style.
>
> An applicative language combines this with an `object' view, where
> you name intermediate objects in addition to processes that turn
> objects into objects.
>
> From a human cognition point of view it seems to me that these
> are quite basic entities that can be used to structure the
> information transfer from one brain to another.
>
> The formal language equivalents sure have their roots in natural
> languages, with the added advantage that these languages can
> be manipulated as objects themselves.
>
> (I have the feeling I'm just stating the obvious though..)
>
>
>>    But I'm still waiting for for an explanation if/why joy is good.
>>    And I expect the outcome of any effort to pay-back in the future.
>>    Education, knowledge of universally applicable principles is more
>>    profitable
>>    than aquiring *A* product.
>>
>
> `good' is relative to `purpose'.
>
> On this i can only comment from a personal angle:  I think
> concatenative languages are good for the purpose of working
> with them as data on a meta-level.
> I.e. playing with evaluation order (staging & partial
> evaluation) and allowing very simple interpreters.
>
> Additionally they are interesting for anything that is
> related to arithmetic (or other problems that ``naturally
> factor'' into small processes).
>
> As a general purpose programming language however, I feel
> they are too restrictive.  Some solutions seem to me to
> be more naturally expressed as object instead of process.
> More specifically: when random access of objects by name
> simplifies matters (i.e. tree-structured data translation).
>
>