Re: An Observation

On Mar 17, 12:24 pm, John Doty <j...@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

Since users literate in Standard Forth are extremely rare, code in
Standard Forth has a negligible maintainability advantage over other
dialects. Better to go with simplicity.

Any Forth programmer can learn to write adequate Forth 94 code in less
than a day. The problems that get so much attention here are mostly
arcane things that matter only for special purposes.

Keep it simple and you can go for years without using ['] IF or
writing a state-smart word. And you don't need to manipulate
dictionary entries. If you feel like the core wordset is bloated then
ignore the words you don't need -- having those words in the standard
doesn't hurt your code at all unless you use them. And if you don't
use them I guarantee other people will still be able to read your code
if you write well and simply.

Learn standard Forth and you will be more portable. Many Forths are
ANS-compatible and you can use them and be productive from the first
day -- though you must study them to use their special strengths.

Still, a simpler more powerful Forth would be a good thing.

So if we get a simpler more powerful Forth, it needs to be compatible
with standard Forth.

You'll never get a better Forth that way. Chuck figured that out.

If a better Forth can add on a compatibility layer so it can accept
standard Forth code, then you can get whatever benefits come from the
standard. You can import code written for some other systems, and you
can get some benefit from programmers who don't know your dialect yet.
You might get increased acceptance for your Forth when you can
legitimately call it a standard Forth system.

If standard Forth can get a compatibility layer so it can accept code
written for your system, then your code will run on standard Forth
systems. People can program your way without worrying that it only
runs on your compilers. Code written for your system can run on most
Forths and Forth programmers who use it have the chance to look at how
you do it and how much harder it is to write their way instead of your
way. So your dialect can spread faster.

This double compatibility layer looks like a good thing to me, if it's
feasible. If it isn't feasible then OK, do without it.


...
By some measures Forth is maintaining its niche. By Anton's measure
we're advancing. By the TIOBE measure we're holding steady at 0.15%.
(We've recently climbed to 36th place without increasing our
percentage share.) http://www.tiobe.com/tpci.htm

But Python is in 7th place and Ruby has gone from 21st place to 10th
place in a year. By whatever TIOBE measures, Ruby's popularity has
gone up 7-fold in one year.

Note that neither of these have standards: they have *specifications*
and portable *implementations*. This moves many of the compatibility and
portability issues off of the language users' plates onto the language
developers' plates, giving everybody better leverage.

Yes.

Could a Forth do that? Yes, why not? If
there was some reason that lots of new users thought a Forth dialect
was very easy to learn and also very powerful, and easy to integrate
into multi-language apps, why not?

Because a sloppy standard puts a burden on users that users of languages
with clean specifications don't have to bear?

If there was a dialect of Forth that people had reason to learn to the
extent that in one year there were 6 times as many users of that
dialect as there were users of all other Forth dialects put together,
it would be the de facto standard. As long as it stayed popular.

Just for fun, I want to imagine what a Forth dialect would have to be
like, to increase the number of Forth programmers 7-fold in one year.
It would take a lot of hype etc that I don't know how to make happen,
but it would have to be more than hype or it wouldn't work. What would
a Forth system have to be like, to get 18,000 people to learn it in
one year?

It would have to be powerful, and dead simple. If it's complicated you
can't teach that many people in one year. And the more effort it takes
to learn, the more of them will drop out. The simpler it is, the less
professionalism is required of the users. They don't need to know all
about computer science, they just need a tool that helps them get
their work done. The less effort it takes to learn it and the less
effort it takes to use it, the more people will learn it just so they
can automate tasks that currently bug them. There's a giant gap
between "I'm a programming professional; I learn as many languages as
I have time for so I will always choose the best tool for the problem"
and "I don't want to learn a computer language, I just want to get my
work done".

Ruby's claim is that everything is an Object, and the syntax is very
simple.
Python claims to be simple, readable, interactive, extendable -- just
like Forth! -- except it achieves all this by being so high-level.

Forth's claim has always been simplicity. We'd need to describe using
the stack as simpler than using variables -- which it is. With the
right capabilities built into it (and with the right marketing, which
I don't know how to do) in 10 years we could have 90% of the
secretaries learning a version of Forth to automate their office
tasks.

The goal then would be to take everything that's a little hard to
understand and replace it with something that's easy to understand.
And throw out as many constructions as possible, or at least treat
them as advanced methods that aren't usually needed.

And then -- maybe put a complex front-end on it. Like, an editor that
puts each name into a little graphical box with lines in front to
represent the stack inputs, and lines in back to represent the stack
outputs. Make them colors that indicate datatypes and the editor makes
a warning if they're obviously incompatible. The datatype lines would
wrap around for loops and branch at branches. Source code in the
editor would be flowcharts and dataflow charts. Shades of Werty!

I'm serious, do it right and we could turn 90% of the secretaries into
Forth programmers in 10 years. Being a Forth programmer would be like
using Word, you mostly wouldn't consider yourself a secretary if you
didn't know it.

;) Well, I'm laughing too. But I'm serious between the laughs.

.

Relevant Pages

  • Re: subroutine stack and C machine model
    ... Hardly matters -- the type rules predate the standard by years. ... was defined as I have said to protect the profits of vendors. ... programmers and as such did a far more valuable service. ... how dare they come up with a common language definition so that people ...
    (comp.lang.c)
  • Re: (Prolog + LISP + Erlang) with integration issues versus C++
    ... >> they will write idiomatic lisp so soon after learning it. ... >> Learning the language on the job is not a recipe for good maintainance. ... > programmers. ... standard, but it's been extended so heavily it may as well not be. ...
    (comp.lang.lisp)
  • Re: Literary phonetic alphabet
    ... Scots poetry by Standard English--speakers. ... language is much more alien than it really is. ... This "system" consists of spelling a limited number of characteristic dialect words "phonetically" (not "eye-dialect" though, which, by definition, is writing words differently from the standard which are actually pronounced essentially the same in both dialect and standard), but spelling all other words identically to English. ...
    (sci.lang)
  • Re: Is C99 the final C? (some suggestions)
    ... >> because the ANSI standard obsoleted them, and everyone picked up the ANSI ... > fixed by using another language. ... programmers managing the meaning of the symbols for more generic operators. ... According to a paper by Intel, widening multiply accounts for something like ...
    (comp.lang.c)
  • Re: nationalists, languages and dialects
    ... >> standardised language is, and so could easily become extinct. ... > "standard language" taught in school is nothing more than a standard ... > "standard" Japanese (a variation of Kanto dialect) is taught throughout ... have to at least try to speak standard Slovak. ...
    (sci.lang)