Nexus Programming Language

[Brian Adkins]

Joy and Factor are essentially dialects of Forth that attempt to add
some elegance and a functional language perspective. IMHO neither one
of them is as elegant and practical as the RPL language HP put into
the HP-28, 48 and 49 calculators. If you're going to make a reverse
Polish language, RPL is the way to do it.

Ah, what memories

I still have my HP-48SX and 2 volume programming manual, what a great
machine. As an undergrad in a numerical analysis class, the prof said
we could use any language we wanted for a particular assignment
(multiple linear regression?), so I asked if I could use the HP-48SX,
and he said sure. It was a blast to crank out on that calculator, and
I'm pretty sure it was a fraction of the size of all the submissions.

 

[M. Edward (Ed) Borasky]

I used <- in a language I designed once.

So does R and IIRC all the other dialects of S. Also IIRC R allows

a = b
a <- b
b -> a

which have equivalent meaning -- "a becomes (a reference to the
object) b". But "formal" R code uses "<-", "->" is deprecated and "="
appears in a lot of actual code. And "==" is the equality test
operator.

At one point R also allowed

a _ b

but I think that disappeared sometime since I first learned R. I
remember that one couldn't have names like

descent_rate

but had to use

descent.rate

because dot was a letter and underscore wasn't. But underscore is now a letter.

 

[M. Edward (Ed) Borasky]

Ah, what memories

I still have my HP-48SX and 2 volume programming manual, what a great
machine. As an undergrad in a numerical analysis class, the prof said
we could use any language we wanted for a particular assignment
(multiple linear regression?), so I asked if I could use the HP-48SX,
and he said sure. It was a blast to crank out on that calculator, and
I'm pretty sure it was a fraction of the size of all the submissions.

I had a 28S which I just loved. It died and got replaced by an HP100LX
and Derive for DOS. When *that* died I stopped buying pocket sized
machines. Now I have the latest model HP-49 and a bunch of TI
scientific calculators. But the HP is still the one I use.

 

[Mike Gold]

The parentheses are in Lisp because functions (and special forms) have
variable arity. If they had fixed arity the parentheses would not be
required. But since S-expressions were defined using parentheses and
Lisp wanted programs to look like S-expressions, variable arity was
thrown in as a bonus.

The parentheses are there for power: code is data, data is code. When
evaluated as a language only, putting aside external issues such as
mindshare, it is an objective statement to say that lisp is more
powerful than any language which does not have the code-data
equivalence. And the only languages which have it are lisp-like (with
the possible exception of Dylan).

Without end we could discuss popularity, "naturalness," "well I like
...", blah blah blah. But it remains an empirical fact some things can
be done in lisp which cannot be done in ruby, unless ruby greenspuns its
own code processor. In lisp you can manipulate code _in code_. The
curious can ponder the implications of that, and/or learn some lisp to
get a sense of it. The incurious will rage against it and call me a
troll.

If I understand Pascal's point, if he has one, it is that the vast
majority of programmers do not realize that the non-lisp language they
use is preventing them from thinking certain thoughts. If after reading
the previous sentence you shouted "bullshit!", then you might not be
fully aware of this special code-data equivalence and why it makes lisp
and lisp-like languages different. I still remember sudden realization
I had when saw what the comma does inside a lisp macro. It has no
counterpart in other languages.

I am not soliciting opinions on what is more practical, what you prefer,
what is better, or what your favorite color is. I am just giving an
overview of the core language itself, with all those issues aside.

 

[Pascal J. Bourguignon]

At one point R also allowed

a _ b

but I think that disappeared sometime since I first learned R.

In the old times, the code 95 often displayed as â†
and the code 94 displayed as ↑

It's only on newer terminals that you would see: a _ b
it was originally: a ↠b

 

[Dylan Evans]

[Note: parts of this message were removed to make it a legal post.]

More than that -- and still relevant today -- parsers for Polish notation
are generally more difficult to *write*. I know -- I've tried designing
both Polish notation parsers and RPN parsers. In fact, Polish notation
parsers are more difficult to write for essentially the same reason that
RPN parsers are slightly more efficient from the machine's point of view.

That's seems funny because bison uses RPN as an example. The syntax isn't
complex and once you have tokens you just need to shift the values onto a
stack and when an operator comes along you just apply it to the last two
values then push the result. Or you can create a tree where each value
becomes a node and the following operation the parent.

 

[David Masover]

The parentheses are there for power: code is data, data is code. When
evaluated as a language only, putting aside external issues such as
mindshare, it is an objective statement to say that lisp is more
powerful than any language which does not have the code-data
equivalence.

How is it more powerful than any other language which allows reflection?
Including Ruby, with ParseTree?

Without end we could discuss popularity, "naturalness," "well I like
...", blah blah blah. But it remains an empirical fact some things can
be done in lisp which cannot be done in ruby, unless ruby greenspuns its
own code processor. In lisp you can manipulate code _in code_.

Right. Like ParseTree.

I have found Ruby's reflection to be more immediately useful, but I
didn't use Lisp long enough to really be sure. I'm talking about the
more specialized stuff, like define_method and instance_eval.

If I understand Pascal's point, if he has one, it is that the vast
majority of programmers do not realize that the non-lisp language they
use is preventing them from thinking certain thoughts. If after reading
the previous sentence you shouted "bullshit!", then you might not be
fully aware of this special code-data equivalence and why it makes lisp
and lisp-like languages different.

Actually, I shouted "bullshit!" because a language cannot _prevent_
thoughts.

For example: Ruby has blocks, where JavaScript does not. But JavaScript
does have anonymous functions.

So while Javascript doesn't support this:

foo.each do |obj|
# do something with 'obj'...
end

It does support this (using jQuery):

$.each(foo, function() {
// do something with 'this'...
});

// or, on a jQuery wrapped object:
foo.each(function() {
// do something with 'this'...
});

The question then becomes whether a language actually makes certain
things impossible, or impractical, or just annoying. And Ruby does have
ParseTree.

I am not soliciting opinions on what is more practical, what you prefer,
what is better, or what your favorite color is. I am just giving an
overview of the core language itself, with all those issues aside.

However, Pascal's point was that Lisp was unarguably the _best_
language, and implied that we were all "unwashed masses" for using Ruby
(and that we probably didn't know about Lisp). I think if we're really
going to have a discussion about "best", practicality has to play a part
of that.

In fact, even if we're only talking about the most powerful language,
power is also subjective. Ruby, for example, allows me to define a DSL
as a subset of Ruby, and have the DSL be very readable -- the
parentheses alone would make that harder in Lisp. All the flexibility
that I like about Ruby's practice of duck typing would bother someone
who wanted strict compiler checks and mathematical provability -- that
is, the power to ignore type would bother someone who wanted the power
to enforce it.

"Power" is subjective.

 

[Tom]

And Ruby does have ParseTree.

BTW does ParseTree work with ruby 1.9? The last time I tried it
didn't.

Anyway, ruby isn't really made for that kind of thing. If you look at
the example at their homepage, the :scope and :block node seem to be
superfluous when dealing with code as data, and something like
"[:call, [:lvar, :arg1], :==, [:array, [:lit, 0]]]" also seems more
complicate than it could be. I think it's a good start but it doesn't
really match lisp capabilities in this respect where there is no
structural difference between the code and the data that represents
that code. That syntax most people in this thread were mocking has its
advantages and if you're denying that, the difference to "those cl
advocates" is only a marginal one.

Maybe you should rather ask if in ruby it is really necessary to
manipulate code as data the way it is necessary in lisp. With a few
exceptions, I have seldom felt a need for it whereas in lisp the use
of macros is something you do all the time.

 

[Pascal J. Bourguignon]

And Ruby does have ParseTree.

BTW does ParseTree work with ruby 1.9? The last time I tried it
didn't.

Anyway, ruby isn't really made for that kind of thing. If you look at
the example at their homepage, the :scope and :block node seem to be
superfluous when dealing with code as data, and something like
"[:call, [:lvar, :arg1], :==, [:array, [:lit, 0]]]" also seems more
complicate than it could be. I think it's a good start but it doesn't
really match lisp capabilities in this respect where there is no
structural difference between the code and the data that represents
that code. That syntax most people in this thread were mocking has its
advantages and if you're denying that, the difference to "those cl
advocates" is only a marginal one.

Maybe you should rather ask if in ruby it is really necessary to
manipulate code as data the way it is necessary in lisp. With a few
exceptions, I have seldom felt a need for it whereas in lisp the use
of macros is something you do all the time.

Auto-meta-programming is only part of the picture.

Of course, when programming in Lisp, we use auto-meta-programming
obliviously all the time, but there are also a lot of lisp programs
written to implement DSL or to generate inferior languages. For these
heterogenous meta- programming applications, Ruby can be used too.

Here is for example how I generate C++ code from Ruby:

(class MapType
(def makeToStringExpression(fieldAccess , mandatory , inVector = false , encoding = nil)
(if mandatory
(e = fieldAccess)
(ib = [["." , e , :begin]])
(ie = [["." , e , :end]])
else
(e = [[ "." , fieldAccess , :getValuePtr]])
(ib = [["->" , e , :begin]])
(ie = [["->" , e , :end]])
end)
(k = (@keyType . makeToStringExpression(["->" , :i , :first] , true , encoding)))
(v = (@elementType . makeToStringExpression(["->" , :i , :second] , true , encoding)))
(s = [:block ,
[:inline , "typedef " + (self . cxxPath) + " map_type;"] ,
(Cxx::Variable . newi , (Cxx::Type . new((self . cxxPath)+"::"+"const_iterator")) , ib)) ,
(Cxx::Variable . newe , (Cxx::Type . new((self . cxxPath)+"::"+"const_iterator")) , ie)) ,
[ "<<" , :s , " (map"] ,
[:for , [ nil , ["!=" , :i , :e],["post++",:i]] ,
[:block , ["<<", :s , " ("] , k , ["<<", :s , " . "] , v , ["<<", :s , ")"]]] ,
[ "<<" , :s , ")"]])
end)
end)


and how I would do it from Lisp:

(defmethod make-to-string-expression ((self map-type) field-access mandatory &optional in-vector encoding)
(let ((f (if mandatory field-access `(\. ,field-access get-value-ptr))))
`(block
(typedef ,(cxx-path self) map-type)
(variable (scope ,(cxx-path self) const-iterator) i (,(if mandatory '\. '->) ,f begin))
(variable (scope ,(cxx-path self) const-iterator) e (,(if mandatory '\. '->) ,f end))
(<< s "(map ")
(for (nil (!= i e) (post++ i))
(block
(<< s " (")
,(make-to-string-expression (key-type self) `(-> i first) t encoding)
(<< s " . ")
,(make-to-string-expression (key-type self) `(-> i second) t encoding)
(<< s ")")))
(<< s ")"))))


(The generator written in Ruby cuts off the C++ syntax at the level of
types and variable expressions, hence the inline and instanciations.
In Lisp, since I could use auto-meta-programming I could easily and
in less time implement the syntax for all the parts of C++, so
there's no need to cross the language boundaries.)

 

[Mike Gold]

How is it more powerful than any other language which allows reflection?
Including Ruby, with ParseTree?

Because in lisp, the metalanguage is the same as the language. Tweaking
ParseTree data is different than writing ruby code. In lisp, the two
activities are the same.

Right. Like ParseTree.

You are supporting my point here. ParseTree only runs on 1.8 CRuby,
being tied to the C implementation's AST. If ruby as a language
supported a retrievable AST structure, then it could be put alongside
dylan as one of the non-lisp languages which supports code as data. But
Matz has explicitly decided against this.

I have found Ruby's reflection to be more immediately useful, but I
didn't use Lisp long enough to really be sure. I'm talking about the
more specialized stuff, like define_method and instance_eval.

Reflection is different from code-data equivalence.

Actually, I shouted "bullshit!" because a language cannot _prevent_
thoughts.

Most people are surprised when they learn lisp macros. I know I was,
and I know many students who were. Why did it surprise us? Because we
hadn't thought of that before. It is not that a language prevents the
thoughts willfully like a evil demon, it's that the thoughts never arise
in the first place.

The question then becomes whether a language actually makes certain
things impossible, or impractical, or just annoying. And Ruby does have
ParseTree.

Not in 1.9 or JRuby. Nor is it planned. Let me know if it happens.

"Power" is subjective.

No, not in the way I used the term. Because of code-data equivalence,
lisp can do things which ruby cannot. In this formal, objective sense,
lisp is more powerful. Even if ruby greenspuns its own tools like
ParseTree, the language will still be different than the metalanguage.
Don't take it personally. This fact is well understood. There is no
sense wiggling around it just to somehow respond with a
counter-argument.

Matz has called lisp "extreme abstraction", which is one way to put it.
Lisp allows for more abstractions than ruby. It was his choice to
relinquish some of those abstractions, some of that power, in the design
of ruby. After all, despite all the catch phrases, ruby is not lisp, by
design.

 

[Brian Adkins]

...
Here is for example how I generate C++ code from Ruby:

(class MapType
(def makeToStringExpression(fieldAccess , mandatory , inVector = false , encoding = nil)
(if mandatory
(e = fieldAccess)
(ib = [["." , e , :begin]])
(ie = [["." , e , :end]])
else
(e = [[ "." , fieldAccess , :getValuePtr]])
(ib = [["->" , e , :begin]])
(ie = [["->" , e , :end]])
end)
(k = (@keyType . makeToStringExpression(["->" , :i , :first] , true , encoding)))
(v = (@elementType . makeToStringExpression(["->" , :i , :second] , true , encoding)))
(s = [:block ,
[:inline , "typedef " + (self . cxxPath) + " map_type;"] ,
(Cxx::Variable . newi , (Cxx::Type . new((self . cxxPath)+"::"+"const_iterator")) , ib)) ,
(Cxx::Variable . newe , (Cxx::Type . new((self . cxxPath)+"::"+"const_iterator")) , ie)) ,
[ "<<" , :s , " (map"] ,
[:for , [ nil , ["!=" , :i , :e],["post++",:i]] ,
[:block , ["<<", :s , " ("] , k , ["<<", :s , " . "] , v , ["<<", :s , ")"]]] ,
[ "<<" , :s , ")"]])
end)
end)

Pascal, I'm curious about your use of parentheses above. Do you use
them because it makes some things easier in your editor, or to compare
more directly with the Lisp example I elided, or simply to try and
make your Ruby code look as much like Lisp as posisble, or ... ?

 

[Jason Roelofs]

...
Here is for example how I generate C++ code from Ruby:

=A0 =A0 =A0 (class MapType
=A0 =A0 =A0 =A0 =A0(def makeToStringExpression(fieldAccess , mandatory ,= inVector =3D false , encoding =3D nil)
=A0 =A0 =A0 =A0 =A0 =A0 (if mandatory
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(e =3D fieldAccess)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(ib =3D [["." , e , :begin]])
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(ie =3D [["." , e , :end]])
=A0 =A0 =A0 =A0 =A0 =A0 =A0else
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(e =3D [[ "." , fieldAccess , :getValuePt= r]])
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(ib =3D [["->" , e , :begin]])
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(ie =3D [["->" , e , :end]])
=A0 =A0 =A0 =A0 =A0 =A0 =A0end)
=A0 =A0 =A0 =A0 =A0 =A0 (k =3D (@keyType =A0 =A0 . makeToStringExpressio= n(["->" , :i , :first] =A0, true , encoding)))
=A0 =A0 =A0 =A0 =A0 =A0 (v =3D (@elementType . makeToStringExpression(["= ->" , :i , :second] , true , encoding)))
=A0 =A0 =A0 =A0 =A0 =A0 (s =3D [:block ,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [:inline , "typedef " + (self . cxxP= ath) + " map_type;"] ,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (Cxx::Variable . newi , (Cxx::Type= . new((self . cxxPath)+"::"+"const_iterator")) , ib)) ,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (Cxx::Variable . newe , (Cxx::Type= . new((self . cxxPath)+"::"+"const_iterator")) , ie)) ,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [ "<<" , :s , " (map"] ,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [:for , [ nil , ["!=3D" , :i , := e],["post++",:i]] ,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [:block , ["<<", :s , " ("] = , k , ["<<", :s , " . "] , v , ["<<", :s , ")"]]] ,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[ "<<" , :s , ")"]])
=A0 =A0 =A0 =A0 =A0 end)
=A0 =A0 =A0 =A0end)

Pascal, I'm curious about your use of parentheses above. Do you use
them because it makes some things easier in your editor, or to compare
more directly with the Lisp example I elided, or simply to try and
make your Ruby code look as much like Lisp as posisble, or ... ?

I think he was making a point to compare Ruby code with LISP code and
showing how similar it is at the core. At least, that's what I saw.

Jason

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

The parentheses are there for power: code is data, data is code. When
evaluated as a language only, putting aside external issues such as
mindshare, it is an objective statement to say that lisp is more
powerful than any language which does not have the code-data
equivalence.

Homoiconicity doesn't afford power so much as simplicity. Using parse
transformations in Ruby requires learning what the Ruby parser's "sexps"
look like, whereas in Lisp you write your code directly in those sexps so
there is no disconnect.

Once you have the Ruby parser's sexps, the same class of transformations are
still available, as they are in any language which allows you to
programatically retrieve parser output and invoke the compiler from within
the language itself.

However, for day-to-day programming tasks I find code in sexp form harder to
read (and write) than code in a more complex grammar which is able to
express the same idea with fewer tokens and less syntactic noise.

Lisp is certainly better optimized for macros, but in my opinion Ruby is
better optimized for day-to-day use and readability.

 

[Sebastian Hungerecker]

I'm leaning more toward = being used for both, and some other signifier
determining how the expression should be evaluated.

What should that other signifier be? I guess you could say that assignment has
no value (instead of returning the assigned value as it usually does) and
then interpret = as checking for equality when it's used in a place where a
(boolean) value is expected and as assignment when it's not. But I imagine
that could become confusing as well. Also it'd make it impossible to do
things like "while item = get_item" (which may or may not be a good thing
depending on your point of view, of course).

 

[David Masover]

Because in lisp, the metalanguage is the same as the language. Tweaking
ParseTree data is different than writing ruby code. In lisp, the two
activities are the same.

I consider that to be a strength of Ruby.

It's possible I simply haven't done enough Lisp to miss some obvious
cases where macros would be helping. However, all the other
metaprogramming (instance_variable_set, define_method, etc) all work
pretty naturally as part of the language. The ParseTree stuff, while it
makes ParseTree itself slightly harder to learn (as you have to learn
how it represents Ruby code), allows the language to be easier and
cleaner when you don't need it.

Even when you do, I'd argue that ParseTree tends to match the structure
that you have in your head for that code, anyway.

Reflection is different from code-data equivalence.

Code-data equivalence is a kind of reflection.

No, not in the way I used the term. Because of code-data equivalence,
lisp can do things which ruby cannot.

I believe I've shown that either of the following is true:

Ruby can do everything Lisp can (ParseTree, etc)...
- OR -
there are things Ruby can do that Lisp cannot.

If we accept that ParseTree counts, Ruby can do everything Lisp can,
with the additional point that not all dialects of Lisp have a concept
of objects.

If we decide that ParseTree doesn't count, then "power" is at least
somewhat based on a superficial, syntactical difference when writing
functionally-equivalent code. In which case, I can find plenty of things
I can do with Ruby syntax that I can't do with Lisp.

In this formal, objective sense,
lisp is more powerful. Even if ruby greenspuns its own tools like
ParseTree, the language will still be different than the metalanguage.

Again, a _syntactical_ difference.

For this kind of reflection, Lisp wins. For everything else, Ruby syntax
is much more readable, at least to me.

Don't take it personally. This fact is well understood. There is no
sense wiggling around it just to somehow respond with a
counter-argument.

Then try responding to that counter-argument, rather than "wiggling
around it" by simply repeating your own, and tacking on an argument from
authority.

 

[Pascal J. Bourguignon]

...
Here is for example how I generate C++ code from Ruby:

(class MapType
(def makeToStringExpression(fieldAccess , mandatory , inVector = false , encoding = nil)
(if mandatory
(e = fieldAccess)
(ib = [["." , e , :begin]])
(ie = [["." , e , :end]])
else
(e = [[ "." , fieldAccess , :getValuePtr]])
(ib = [["->" , e , :begin]])
(ie = [["->" , e , :end]])
end)
(k = (@keyType . makeToStringExpression(["->" , :i , :first] , true , encoding)))
(v = (@elementType . makeToStringExpression(["->" , :i , :second] , true , encoding)))
(s = [:block ,
[:inline , "typedef " + (self . cxxPath) + " map_type;"] ,
(Cxx::Variable . newi , (Cxx::Type . new((self . cxxPath)+"::"+"const_iterator")) , ib)) ,
(Cxx::Variable . newe , (Cxx::Type . new((self . cxxPath)+"::"+"const_iterator")) , ie)) ,
[ "<<" , :s , " (map"] ,
[:for , [ nil , ["!=" , :i , :e],["post++",:i]] ,
[:block , ["<<", :s , " ("] , k , ["<<", :s , " . "] , v , ["<<", :s , ")"]]] ,
[ "<<" , :s , ")"]])
end)
end)

Pascal, I'm curious about your use of parentheses above. Do you use
them because it makes some things easier in your editor,

Yes, definitely. I use emacs with paredit-mode.

or to compare
more directly with the Lisp example I elided,

Not specifically, but it's a nice side effect.

or simply to try and
make your Ruby code look as much like Lisp as posisble, or ... ?

Yes, definitely. It makes me feel if not at home, at least, at a
strange aunt's, vs. in a totally strange home in a totally strange
land.

 

[Eleanor McHugh]

Yes, definitely. It makes me feel if not at home, at least, at a
strange aunt's, vs. in a totally strange home in a totally strange
land.

And that is precisely the point that many Lispers overlook. Lisp is a
mathematical notation and so people of a mathematical inclination feel
at home, however languages with "complex" syntax approximate natural
language notation and that's a place where the vast majority of
literate humans feel comfortable.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Robert Klemme]

But then again I've seen beautiful code in C and Assembler, even in
Pascal (see my favourite book, Programming Languages: An Interpreter-
based Approach for some wonderful examples) and perhaps one day I'll
see beautiful code in Nexus. That alone will be justification enough
for the love and effort its developers are pouring into it.

Of course, this provokes the question "what is beauty?" (or "what is a
beautiful program?"). Pascal seems to like cascades of brackets so he
even writes Ruby code that way (or maybe it's just a habit) - other
people will like something else. IIRC there is this saying about the
"eye of the beholder"...

What I probably wanted to say was: if you consider beauty as a criterion
for discussing languages it comes as no surprise that there is so little
agreement among people.

And yes, we've gone completely OT.

Kind regards

robert


PS: For me beauty in a program is clear structure and few but well
chosen lines of code.

 

[Jörg W Mittag]

Homoiconicity doesn't afford power so much as simplicity. Using parse
transformations in Ruby requires learning what the Ruby parser's "sexps"
look like, whereas in Lisp you write your code directly in those sexps so
there is no disconnect.

Actually, you can have complex syntax *and* easy manipulation, by
delegating the building of the AST to the tool that already knows how
to do that anyway: the compiler.

The Converge Programming Language (<http://ConvergePL.Org/>) is a
great example of compile time metaprogramming in a language with
complex syntax (Pythonic in this case). It uses quasi-quoting to let
you build ASTs using the *concrete* syntax of the language and it uses
splice points to allow you to splice AST fragments back into the AST.

For things that are too complex for simple quoting and splicing,
Converge has an abstract standardized API to the compiler.

jwm

PS: Consider this my entry to "what Reia could steal from other
languages" (-:

 

[s.ross]

[Note: parts of this message were removed to make it a legal post.]

Actually it dates back to Algol. The people who designed it did it for
a reason, but I can't remember what it was. I think it was to remind
people that assignment was not equality, and the purists pronounce

a := b

IIRC, that's similar to how the production is written in BNF, and made
sense in the context of creating compilers. But really, this
discussion is primarily about syntactic sugar. The whole point of a
high level programming language is to enable to let people think as
people do and translate those constructs into something that machines
can process efficiently. Many people, myself included, don't have
stack-based architectures and thus don't think well in RPN. So Forth
might not be my language of first choice.

But in the end, any T-complete language should allow you to (or should
I say "not prevent you from") do(ing) your job.