Re: your opinion?

[Hans Bezemer]

On Saturday 13 April 2013, you wrote:
> Do you have an opinion you are willing to share regarding:
> http://evincarofautumn.blogspot.mx/2012/02/why-concatenative-programming-ma
>tters.html
Well, first: terminology (jargon) is important. It tells people who you are.
Hence, my "jargon" is very different of what the writer of this piece uses
(and the creator of Factor for that matter), so that tells you immediately
where I stand.

There is a reason why 4tH is ther way it is. For me there are two different
datatypes, bytes and words. That's it. You may want to wrap it into arrays if
you want, but that's it. A structure is simply a special kind of array.

I have very little to do with other datatypes, since you can all reduce them
to the two I mentioned. Some may say lists are a "basic" datatype, but it's
not, since lists are an abstaction in itself. Darn, even "multi-dimensional"
arrays are an abstraction.

Note I got nothing against abstractions, but you only put them into existence
when they serve a purpose to solve a particular problem. Otherwise they don't
exist and shouldn't be a part of your vocabulary.

The problem with types is that they tend to get in your way. Even in C you
might find yourself into a position where types get in your way. Even
a "void" declaration can't get you out of it. And what about malloc()? Since
malloc() doesn't know which type you're declaring it can either align all
allocations OR do some dirty cleaning up afterwards.

4tH on the other hand, always knows EXACTLY what you're doing. @C is for the
Code segment, @ is for the Integer segment and C@ is for the character
segment. I don't care what abstractions you or me throw on top of them, but
it always boils down to this.

"Quotations" are simply unnamed execution tokens. If you want them in 4tH, the
only thing I would have to do is map [ to :NONAME and ] to ;. Bottomline.
Hence, if you want "quotations", you already got them. It's a fance way to
group a bunch of instructions, but I fail to see how they make life easier.

Another problem with fancy stuff is that they introduce overhead. Local
variables are variables in any way and they come with the overhad of fetching
and storing them. Execution tokens are subroutines nonetheless and come with
function call overhead.

Finally, I don't see how they make life easier. I have maintained lots of 4tH
programs and some aren't quite trivial - even if they are small. E.g. TCS has
two separate dictionaries and hence two interpreters. Needless to say
anything about a full fledged Basic interpreter like uBasic which I
retrofitted with a structured extension. And I don't think you'll find that
PP4tH is a "simple" program.

It's like Chuck Moore says: the industry has tried to make it easy for boys to
program - but boys are not carved out to do fancy stuff. That's left to men.
In other words, the tool you choose reflects your skill level. I like 4tH
because it doesn't come into my way. Whatever is on the stack, I decide what
to do with it and what abstraction it is.

Quote: "And hey, thanks to quotations, it’s also easy to declare your own
control structures"

I know at least three ways to implement control structures. They all have
their advantages and disadvantages. I decide which one to use depending on
the problem I want to solve. Quotations are one way to do it, but certainly
not the only way or overall the best way. Note the example he uses. You
really want to write a program that way?

Quote: So our final function can be written: "f = drop dup dup × swap abs rot3
dup × swap − +" Well.. that sucked.

Yes, if you don't document it, duh.. Note TEONW or LANDER. I documented those
ones. And if you want to use the Fortran way to express such formula's, then
use OPG: a particular solution to a particular problem.

The thing I do agree with is that concatenative languages are easier to read
and more compact, because you pass the parameters transparently by the stack
AND you read it consistently from left to right.

strcat(strcat(strcat(strcpy(hello,"Hello"), " "), "world"), "!");

Vs.

Hello >r s"Hello " r@ PLACE s" " r@ +PLACE s" world" r> +PLACE "!"

That is without optimisations like this:

: s! dup >r place r> ;
: +s! rot dup >r +place r> ;
s" Hello" s! s" " +s! s" world" +s! s" !" +s! drop

Or even:

include lib/concat.4th
s" Hello" s" " s" world" s" !" 4 Hello concat

Again, particular problem, particular solution. That's why there are sometimes
several libraries in 4tH with the same basic functionality, but different
characteristics.

But to get back to the original C statement: you start reading a "strcat",
while the first function executed is "strcpy". You read from right to left!

In short, I agree with most of the things he writes. What he tends to forget
(in the context of Forth, agreed) is that Forth was designed to unobfuscate
EVERYTHING, the stack, the concatinativivity, the postfix notation, etc. and
open them up to the programmer, so he can make full use of it and (also) to
put the burden of handling them to the programmer - and not the computer. In
other words, to unabstract the language.

The problem I have with this article (and other articles) is that they want to
mix "modern" constructs with this basic philosophy - and you can't. It simply
doesn't become coherent.

I work the other way around. 4tH is down to earth. You can put another
abraction layer on it if and when you see fit until you can express your
problem in high level words. If you work your way top down (top of the
listing that is) you see the creation of these abstraction layers until they
end up in apotheose, a single word. If you work bottom up, you see this word
fall apart into basic 4tH and basic datatypes.

Sure, I helped you by pre-creating certain abstraction layers, which is your
library. If you don't want or need to use them - it's all the same to me.

But however you turn it, they are separate entities, each one of them at its
own level - and there it stays.

I think the ultimate expression of that philosophy was implementing and
breaking down Object Orientation, so you guys could see and understand what
is really there.

Like a pointer is simply a variable holding an address;
Like a structure is simply an array with offsets;
Like a string is simply a character array with a terminator or a count.

IMHO that's how you make programmers: not by hiding what is there, but showing
what is there. If you want to fix cars, you have to know how they work and
what's under the hood.

Hans Bezemer








--
I have no Facebook account. Consequently, I have no friends and I don't like
anything. Deal with it.

Visit our website! http://thebeez.home.xs4all.nl/4tH/

*** Home of the 4tH compiler! ***

[Hans Bezemer]

On Sunday 14 April 2013, you wrote:
It's published here, without references. You're right, I don't want to burn
this guys article down - that's not my intention.

http://code.google.com/p/4th/wiki/Basic4tHphilosophy