"billy" <wtanksleyjr@[EMAIL PROTECTED]
> wrote in message
news:256020f2-8cde-4d1b-845f-6ac81e832f44@[EMAIL PROTECTED]
> "cr88192" <cr88...@[EMAIL PROTECTED]
> wrote:
>> yes, RPN has uses, but I will argue, is still not the best model for
>> general programming.
>
> Well, you DO assert that, but you don't exactly argue it. But that's
> okay, 'cause I'll concede: RPN isn't a "model for general
> programming", it's just another type of syntax for programming
> languages. I'd even concede that it's not the "best" type of syntax
> (but I'm weasel wording, because I don't think there's an optimum
> syntax type). I do think that RPN is as useful as any other syntax
> type, but simply less studied and formally understood. Oh, and it's
> also useful in different specific areas than the areas in which infix
> or prefix are useful.
>
yes, I will agree to this.
where it works very well, IMO, is in many of the same kinds of places that
assembler works well...
> For an example of an area in which RPN excels over the others, all
> transformations in a pure RPN language can be expressed as direct
> 'textual' replacements on a flat list, rather than pattern matching on
> a tree. This makes some formal theory simpler to work with. In
> practice, of course, nobody works with a pure RPN language (I've only
> ever seen one, and it's a "turing tarpit"), but again in practice,
> even a non-theoretical language like Forth winds up matching so close
> to theory that most of the results wind up being discovered and used
> by most programmers naturally.
>
I will also agree to this.
some of the advantages of RPN, is why I use it, in my lower compiler...
if you want something very simple and powerful, RPN is likely a good bet.
>> I will argue then that natural is not so much what we need concern
>> ourselves
>> with (much of what is most useful is clearly not 'natural'), but
rather,
>> more obvious problems:
>> complicated expressions in RPN, or manual binary arithmetic (for
>> non-trivial
>> values), very quickly become unmanageable.
>> so, the downfall of forth is not that it is 'unnatural', but rather
that
>> no
>> one can really read and follow the code...
>> one has to 'study', even their own code in a language they may know
well,
>> just to figure out what the hell they were doing.
>
> This is not necessarily so in general; and to the extent that it is
> true for specific cases, it's true for all language types.
>
I will disagree, in that I find some forms of syntax to be more easily
understandable than others, for different arguably subjective reasons.
note though, my views are not based on parsing or processing concerns.
that
RPN is simple to parse and process, and that something like C or C++ is
nearly unparsable (absent significant investment), is not really my
concern.
however, we can assert that, failing everything else, there is one
"strong"
advantage to C style syntaxes (in a general sense, including C, C++, C#,
Java, JavaScript, ...):
this is a strong preference within both the industry, and within the minds
of many developers.
as far as the languages themselves go, C, C++, and Java, are almost
universally understood, which means, again, that there is strong reason to
emulate them.
so, IMO:
RPN is really good for low-level processing (and very simple
interpreters),
but I personally view it as awkward, counter-intuitive, and not terribly
scalable or readable (also, the syntax itself does not offer much
'abstraction');
S-Expressions are very good for intermediate processing tasks, and allow a
reasonable level of abstraction, but are ugly and a hassle to work with
(especially in non paren-counting editors);
more traditional syntaxes (C or Pascal like), are a lot better for human
editing, primarily because they offer abstraction, use visual
associativity
(rather than structural associativity).
>> this is not so much a problem with a more C-style syntax...
>
> False. Both computational theory and actual practice indicate that in
> general, it's very easy to write code that can't be easily read later,
> in ANY language.
>
true, but irrelevant.
I will assert that a more C or Pascal style syntax allows greater
readability.
so, the issue is more one of proving that RPN languages have at least a
similar, if not greater, readability on average than generally well
written
code in a language with a more conventional syntax.
one of the major problems I have found before with RPN is the difficulty
in
breaking and indenting things in a more or less "sane" manner (due in
large
part to the non block-and-statement style structuring of such languages).
> -Wm
|
