Re: An Observation

J Thomas wrote:
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.

Still, that's a lot longer than LSE64. How long does it take to learn to *read* Forth 94?

The problems that get so much attention here are mostly
arcane things that matter only for special purposes.

You mean like the fact that "CHAR X" means different things depending on STATE?


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

I can't unless others have the same discipline.

-- having those words in the standard
doesn't hurt your code at all unless you use them.

I still have to use the interpreted pidgin to do things at build time. So anyone reading my code would have to learn two languages if I used Forth 94.

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.

Does no good if my customers don't know it.

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.

There aren't any.

You can import code written for some other systems,

There is almost none. Why bother?

and you
can get some benefit from programmers who don't know your dialect yet.

I don't know that I've *ever* met a Forth 94 user in the flesh. Besides, any forther could learn LSE in about five minutes.

You might get increased acceptance for your Forth when you can
legitimately call it a standard Forth system.

My customers don't care. But if someone cares about standards I can call it a lightweight, simple, flexible, fast, easy to learn scripting language in standard C. At least they'll have heard of that.


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.

It can't. I make promises Standard Forth can't keep.

People can program your way without worrying that it only
runs on your compilers.

My compiler is portable and published under the GPL. Where's the worry? It's users of commercial Forths who have to worry.

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.

Gotta give people code they want to use/extend. I learned Lisp decades ago, but never used it until gEDA came along using Guile for scripting.


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.

Yes, but is "object" the right model for all data?

Python claims to be simple, readable, interactive, extendable -- just
like Forth! -- except it achieves all this by being so high-level.

Van Rossum studied how users perceive programming before designing Python. That study informed the design, and I believe it had a great deal to do with the success of the language.


Forth's claim has always been simplicity. We'd need to describe using
the stack as simpler than using variables -- which it is.

For volatile temporaries it is when the logic of the data flow is LIFO. In other cases it isn't.

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.



--
John Doty, Noqsi Aerospace, Ltd.
--
Specialization is for robots.
.

Relevant Pages

  • 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: An Observation
    ... Standard Forth has a negligible maintainability advantage over other ... can get some benefit from programmers who don't know your dialect yet. ... So your dialect can spread faster. ... portability issues off of the language users' plates onto the language ...
    (comp.lang.forth)
  • 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: global variables are bad?
    ... letter limit, I cannot really claim that I am convinced. ... language was in all cases, bar one, in English. ... Some of the programmers wanted to ... A few code reviews, standard ...
    (comp.lang.c)