The Secret of a Successful Programming Language?

The Secret of a Successful Programming Language? A Really Great Beard
- That's an article headline at WIRED, fun to read:

"Why do some programming languages take over the world while others
wallow in obscurity?
Two academics at Princeton and the University of California, Berkeley
are combing through mountains of data trying to tackle this mystery of
the modern world. They think the answer may lie with how well a
language is documented. Or with the reality that the average
programmer doesn’t have the time or the inclination to learn more than
a handful of programming tools. Or even with the age-old tendency of
academics to build stuff that’s gloriously clever but completely
impractical.
But a man named Tamir Kahson has a different answer. He thinks it’s
all about the beard."

Source: http://www.wired.com/wiredenterprise...beard-gallery/

Seems to be that Chuck Moore made one mistake in his life: he didn't
grow a beard.

On Jul 18, 1:57*am, Bluebee <visualfo...@rocketmail.com> wrote:
> The Secret of a Successful Programming Language? A Really Great Beard
> - That's an article headline at WIRED, fun to read:
>
> "Why do some programming languages take over the world while others
> wallow in obscurity?
> Two academics at Princeton and the University of California, Berkeley
> are combing through mountains of data trying to tackle this mystery of
> the modern world. They think the answer may lie with how well a
> language is documented. Or with the reality that the average
> programmer doesn’t have the time or the inclination to learn more than
> a handful of programming tools. Or even with the age-old tendency of
> academics to build stuff that’s gloriously clever but completely
> impractical.
> But a man named Tamir Kahson has a different answer. He thinks it’s
> all about the beard."
>
> Source:http://www.wired.com/wiredenterprise...beard-gallery/
>
> Seems to be that Chuck Moore made one mistake in his life: he didn't
> grow a beard.

Users. Inertia.

Bluebee wrote:
> Source: http://www.wired.com/wiredenterprise...beard-gallery/
>
> Seems to be that Chuck Moore made one mistake in his life: he didn't
> grow a beard.

This is why we appointed Peter Knaggs to be the standard editor.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

Mark Wills wrote:
>> But a man named Tamir Kahson has a different answer. He thinks it’s
>> all about the beard."
>>
>> Source:http://www.wired.com/wiredenterprise...beard-gallery/
>>
>> Seems to be that Chuck Moore made one mistake in his life: he didn't
>> grow a beard.
>
> Users. Inertia.

Come on, this was a really funny post, and you want to argue with facts.
It's the beard, get over it. And Forth200x will be a huge success,
because our editor's beard is huge.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

On Jul 18, 2:19*pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Mark Wills wrote:
> >> But a man named Tamir Kahson has a different answer. He thinks it’s
> >> all about the beard."
>
> >> Source:http://www.wired.com/wiredenterprise...beard-gallery/
>
> >> Seems to be that Chuck Moore made one mistake in his life: he didn't
> >> grow a beard.
>
> > Users. Inertia.
>
> Come on, this was a really funny post, and you want to argue with facts.
> It's the beard, get over it. *And Forth200x will be a huge success,
> because our editor's beard is huge.
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"http://bernd-paysan.de/

This is indeed true. I'm sorry for the misinformation. I'll get my
coat!

On Wednesday, July 18, 2012 6:19:49 AM UTC-7, Bernd Paysan wrote:
> Mark Wills wrote:
> &gt;&gt; But a man named Tamir Kahson has a different answer. He thinks it’s
> &gt;&gt; all about the beard.&quot;
> &gt;&gt;
> &gt;&gt; Source:http://www.wired.com/wiredenterprise...beard-gallery/
> &gt;&gt;
> &gt;&gt; Seems to be that Chuck Moore made one mistake in his life: he didn't
> &gt;&gt; grow a beard.
> &gt;
> &gt; Users. Inertia.
>
> Come on, this was a really funny post, and you want to argue with facts.
> It's the beard, get over it. And Forth200x will be a huge success,
> because our editor's beard is huge.
>
> --
> Bernd Paysan
> &quot;If you want it done right, you have to do it yourself&quot;
> http://bernd-paysan.de/

The majority of the programmers in the world believe that Forth Inc. *is* Forth. It is generally assumed that Forth Inc. represents the pinnacle of Forth technology, and that everybody else is just a wanna-be. A lot of C programmers have told me that they examined Forth Inc. products and determined that they were garbage, and that concluded their investigation of Forth. Itis extremely difficult to convince anybody to look beyond Forth Inc. because of the name.

In MS-DOS days, most people were using Turbo Pascal or one of the C compilers (Turbo C, Microsoft C or Watcom). All of these provided several memory models, with Small being the most commonly used. In Small, we had 64K code and 64K data for the application, and the compiler ran in its own memory space. There were other memory models that provided more memory for code or data or both, but which required the use of Far pointers. By comparison, PolyForth had only a Tiny memory model. The application's code and data shared a 64K segment. PolyForth was actually tinier than Tiny, because the compiler and the symbol table also shared that same 64K segment. It was abundantlyobvious that nobody at Forth Inc. knew enough about 8088 assembly languageto use the 8088 segmented memory system --- most likely, PolyForth was a line-by-line port of an old 8080 Forth that somebody (most likely Chuck Moore) had written for CP/M. Elizabeth Rather could fake it in her novice class, because she and her students were only writing a handful of small functions --- but PolyForth wasn't capable of supporting actual programs due to its severe memory constraints.

I remember that I used to try to tell C programmers that UR/Forth used something roughly comparable to the Small memory model. Nobody would listen. Intheir minds, Forth Inc. owned the name "Forth," and that was the end of the story. Now we have 32-bit Forth systems, but it is too late. Forth died out during MS-DOS days. Forth was still taken seriously in the early 1980s when most people were using 8-bit computers with an inherent 64K limit. Almost all programming on 8-bit computers was done in assembly language --- C and Pascal were really too bulky for those little computers --- Forth was the only high-level language that was small enough to run on the computer, but big enough to support actual programs. PolyForth failed to make the jump to 16-bit computers though, and everybody switched over to C. Compared to Turbo C, PolyForth was just a weird joke --- this is what killed Forth.

Then ANS-Forth came out in 1994, and it was a grossly bad design. This nailed the coffin shut forever.

The ANS-Forth document uses the word "may" as a crutch throughout. The document is also not self-consistent, saying that locals may be on the return stack, which is not possible if it is also going to support >R R@ R> etc., which it does. Gforth has some words with dual xt values, and some with no xt value at all --- and this is supposedly legal ANS-Forth. The whole thing was just a nightmare --- like trying to warm up a corpse and make it walk again --- nobody in the world wants to use ANS-Forth for professional programming.

I personally blame Elizabeth Rather for ruining Forth. I don't know if she has a beard or not, but she is an evil evil person --- her sole claim to fame is that she knew Chuck Moore in the 1970s, and she hopes that this will make up for the fact that she is not a computer programmer herself --- but this lack of programming knowledge is what killed Forth.

On 07/19/2012 02:25 AM, yahoo.com">hughaguilar96@yahoo.com wrote:

> The majority of the programmers in the world believe that Forth Inc. *is* Forth.

In my experience, the majority of programmers are not even aware there
is a language called "Forth", let alone a company called "Forth Inc"

On 2012-07-19, Ron Aaron <rambamist@gmail.com> wrote:
> On 07/19/2012 02:25 AM, yahoo.com">hughaguilar96@yahoo.com wrote:
>
>> The majority of the programmers in the world believe that Forth Inc. *is* Forth.
>
> In my experience, the majority of programmers are not even aware there
> is a language called "Forth", let alone a company called "Forth Inc"

Indeed. If I say someone that I like to play with Forth, the answer is
Fortran is so stupid.

Nowdays I use Amforth with my Atmel MCUs and that impresses my
technologically enlightened friends. It is so hard to understand someone
that there is interactive system in small MCU.

And is Forth really dead? There are psotscript and biblatex style
programming language. At least they have same ideas as Forth. Only brave
and fearless people touch them with editor. One tombstone with name
Forth is set. As Openfirmware computers are going to extinct. And
only word people knew from it was BOOT.

And I know saying those are Froth is saying like C++ is C. But my
opinnion is that there is Forth's legacy to be seen.

best regards,
Hannu Vuolasaho

On 19 Jul., 01:25, hughaguila...@yahoo.com wrote:
> On Wednesday, July 18, 2012 6:19:49 AM UTC-7, Bernd Paysan wrote:
> > Mark Wills wrote:
> > >> But a man named Tamir Kahson has a different answer. He thinks it’s
> > >> all about the beard."
>
> > >> Source:http://www.wired.com/wiredenterprise...beard-gallery/
>
> > >> Seems to be that Chuck Moore made one mistake in his life: he didn't
> > >> grow a beard.
>
> > > Users. Inertia.
>
> > Come on, this was a really funny post, and you want to argue with facts..
> > It's the beard, get over it. *And Forth200x will be a huge success,
> > because our editor's beard is huge.
>
> > --
> > Bernd Paysan
> > "If you want it done right, you have to do it yourself"
> >http://bernd-paysan.de/
>
> The majority of the programmers in the world believe that Forth Inc. *is*Forth. It is generally assumed that Forth Inc. represents the pinnacle of Forth technology, and that everybody else is just a wanna-be. A lot of C programmers have told me that they examined Forth Inc. products and determined that they were garbage, and that concluded their investigation of Forth. It is extremely difficult to convince anybody to look beyond Forth Inc. because of the name.
>
> In MS-DOS days, most people were using Turbo Pascal or one of the C compilers (Turbo C, Microsoft C or Watcom). All of these provided several memorymodels, with Small being the most commonly used. In Small, we had 64K codeand 64K data for the application, and the compiler ran in its own memory space. There were other memory models that provided more memory for code or data or both, but which required the use of Far pointers. By comparison, PolyForth had only a Tiny memory model. The application's code and data shared a 64K segment. PolyForth was actually tinier than Tiny, because the compiler and the symbol table also shared that same 64K segment. [snip] but PolyForth wasn't capable of supporting actual programs due to its severe memoryconstraints.
>
> I remember that I used to try to tell C programmers that UR/Forth used something roughly comparable to the Small memory model. Nobody would listen. In their minds, Forth Inc. owned the name "Forth," and that was the end of the story. Now we have 32-bit Forth systems, but it is too late. Forth diedout during MS-DOS days. Forth was still taken seriously in the early 1980swhen most people were using 8-bit computers with an inherent 64K limit. Almost all programming on 8-bit computers was done in assembly language --- Cand Pascal were really too bulky for those little computers --- Forth was the only high-level language that was small enough to run on the computer, but big enough to support actual programs. PolyForth failed to make the jump to 16-bit computers though, and everybody switched over to C. Compared toTurbo C, PolyForth was just a weird joke --- this is what killed Forth.
>
> Then ANS-Forth came out in 1994, and it was a grossly bad design. This nailed the coffin shut forever.
> - Zitierten Text anzeigen -

> It is generally assumed that Forth Inc. represents the pinnacle of Forth technology
[snip]
> ...but PolyForth wasn't capable of supporting actual programs due to its severe memory constraints
PolyForth uses "overlays" to load a binary image into memory - even
with a floppy disk this doesn't take long, and on a hard disk the
delay is not perceptible. This is like colorForth's Just-In-Time (JIT)
compilation technique, and allows programs to be as large as your disk
drive can hold.
PolyForth also has extended memory operators that take a segment and
offset - E@ , E! etc. to access the full 1MByte address range.

> PolyForth failed to make the jump to 16-bit computers though
polyForth 8086 is 16 bit, as is the 8086.
Do you mean that polyForth failed to use the F86-style segmented
model, which limited it to 64K?
This was a design decision which made polyForth faster, but required
overlays for larger programs.
[snip]
> --- this is what killed Forth
I think we have to agree to differ on the state of Forth's mortality.
We are, after all discussing this on c.l.f., which is surely some sign
of life?

> I remember that I used to try to tell C programmers ...
[snip]
> It is extremely difficult to convince anybody to look beyond Forth Inc. because of the name
Why are you trying? "There is none so blind as those who _will_ not
see"

Forth is a secret, and it is kept secret by its simplicity.
Some people like elegance, some people like the current language of
the month. Some people like both...
As Hannu points out, many people are not interested in Forth because
it sounds too much like Fortran.

My first encounter with Forth was COSMAC 1802 polyForth, and I have
_so_ much fun programming in Forth since then :-)

Best regards,
Howerd

In article <c789bbd2-148c-424c-a828-7298a5eb468a@googlegroups.com>,
<hughaguilar96@yahoo.com> wrote:
>On Wednesday, July 18, 2012 6:19:49 AM UTC-7, Bernd Paysan wrote:
>> Mark Wills wrote:
>> &gt;&gt; But a man named Tamir Kahson has a different answer. He thinks i=
>t=92s
>> &gt;&gt; all about the beard.&quot;
>> &gt;&gt;
>> &gt;&gt; Source:http://www.wired.com/wiredenterprise.../beard-galler=
>y/
>> &gt;&gt;
>> &gt;&gt; Seems to be that Chuck Moore made one mistake in his life: he di=
>dn't
>> &gt;&gt; grow a beard.
>> &gt;=20
>> &gt; Users. Inertia.
>>=20
>> Come on, this was a really funny post, and you want to argue with facts. =
>=20
>> It's the beard, get over it. And Forth200x will be a huge success,=
>=20
>> because our editor's beard is huge.
>>=20
>> --=20
>> Bernd Paysan
>> &quot;If you want it done right, you have to do it yourself&quot;
>> http://bernd-paysan.de/
>
>The majority of the programmers in the world believe that Forth Inc. *is* F=
>orth. It is generally assumed that Forth Inc. represents the pinnacle of Fo=
>rth technology, and that everybody else is just a wanna-be. A lot of C prog=
>rammers have told me that they examined Forth Inc. products and determined =
>that they were garbage, and that concluded their investigation of Forth. It=
> is extremely difficult to convince anybody to look beyond Forth Inc. becau=
>se of the name.

I'm a professional programmer. In my body shopping life
have seen virtually all important industries in the Netherlands from the
inside. Once in a blue moon I meet a programmer who knows Forth.
I never met a programmer who had a strong opinion about Forth Inc, or
even knew it existed.

Sorry, this story coming from a cab driver is very dubious.

Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On 7/18/12 10:55 PM, Howerd wrote:
....
>> ...but PolyForth wasn't capable of supporting actual programs due to its severe memory constraints

polyFORTH was used in many commercial applications, including the
well-known Saudi airport project (last I heard, a couple of years ago,
that was still running). It used far less memory than competing
technologies, and we never experienced any limitations due to memory
constraints. Every programming technology is subject to the limitations
of its physical platform. Most used runtime overlays, which slowed
performance substantially.

> PolyForth uses "overlays" to load a binary image into memory - even
> with a floppy disk this doesn't take long, and on a hard disk the
> delay is not perceptible. This is like colorForth's Just-In-Time (JIT)
> compilation technique, and allows programs to be as large as your disk
> drive can hold.
> PolyForth also has extended memory operators that take a segment and
> offset - E@ , E! etc. to access the full 1MByte address range.

polyFORTH was capable of using segment registers on x86 processors and
memory management on the PDP-11 and similar minis. polyFORTH programs
typically ran far faster than, say, Fortran (which was the dominant
language in the 70's and well into the 80's) because it used less memory
and hence fewer runtime overlays.

>> PolyForth failed to make the jump to 16-bit computers though
> polyForth 8086 is 16 bit, as is the 8086.
> Do you mean that polyForth failed to use the F86-style segmented
> model, which limited it to 64K?
> This was a design decision which made polyForth faster, but required
> overlays for larger programs.

And we did introduce a segmented model, but after only a couple of years
replaced it with a 32-bit implementation.

>> --- this is what killed Forth
> I think we have to agree to differ on the state of Forth's mortality.
> We are, after all discussing this on c.l.f., which is surely some sign
> of life?

It is far from dead. A significant fraction of the power grid of North
America is managed with Forth-based controllers, as are DirectTV uplink
antennas and many other ubiquitous items of technology.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

On Jul 19, 1:55*am, Howerd <howe...@yahoo.co.uk> wrote:
> On 19 Jul., 01:25, hughaguila...@yahoo.com wrote:
> > The majority of the programmers in the world believe that Forth Inc. *is* Forth. It is generally assumed that Forth Inc. represents the pinnacle of Forth technology, and that everybody else is just a wanna-be. A lot of C programmers have told me that they examined Forth Inc. products and determined that they were garbage, and that concluded their investigation of Forth.. It is extremely difficult to convince anybody to look beyond Forth Inc. because of the name.
>
> > In MS-DOS days, most people were using Turbo Pascal or one of the C compilers (Turbo C, Microsoft C or Watcom). All of these provided several memory models, with Small being the most commonly used. In Small, we had 64K code and 64K data for the application, and the compiler ran in its own memoryspace. There were other memory models that provided more memory for code or data or both, but which required the use of Far pointers. By comparison, PolyForth had only a Tiny memory model. The application's code and data shared a 64K segment. PolyForth was actually tinier than Tiny, because the compiler and the symbol table also shared that same 64K segment. [snip] but PolyForth wasn't capable of supporting actual programs due to its severe memory constraints.
>
> > I remember that I used to try to tell C programmers that UR/Forth used something roughly comparable to the Small memory model. Nobody would listen.. In their minds, Forth Inc. owned the name "Forth," and that was the end of the story. Now we have 32-bit Forth systems, but it is too late. Forth died out during MS-DOS days. Forth was still taken seriously in the early 1980s when most people were using 8-bit computers with an inherent 64K limit. Almost all programming on 8-bit computers was done in assembly language ---C and Pascal were really too bulky for those little computers --- Forth was the only high-level language that was small enough to run on the computer, but big enough to support actual programs. PolyForth failed to make the jump to 16-bit computers though, and everybody switched over to C. Compared to Turbo C, PolyForth was just a weird joke --- this is what killed Forth.
>
> > Then ANS-Forth came out in 1994, and it was a grossly bad design. This nailed the coffin shut forever.
> > - Zitierten Text anzeigen -
> > It is generally assumed that Forth Inc. represents the pinnacle of Forth technology
> [snip]
> > ...but PolyForth wasn't capable of supporting actual programs due to its severe memory constraints

> PolyForth uses "overlays" to load a binary image into memory - even
> with a floppy disk this doesn't take long, and on a hard disk the
> delay is not perceptible. This is like colorForth's Just-In-Time (JIT)
> compilation technique, and allows programs to be as large as your disk
> drive can hold.

I wouldn't consider the use of binary overlays to be like Just-In-Time
(JIT) compilation technique. lol

UR/Forth had binary overlays too but I never used them. They are not
very useful unless you have separate and very distinct aspects of your
program that can be swapped in and out. For the most part, this only
applies to the compiler itself. For example, the editor can be an
overlay because it is not used at the same time that compilation is
being done, and it is pretty big. Overlays don't work well for
applications though, because you usually just have a single big
program that has to all be in memory at the same time.

PolyForth didn't make the jump to 16-bit systems. It may have been
written in 8088 assembly language, but it wasn't taking advantage of
the fact that the 8088 could address more than 64K of memory, which is
the sole point of moving from the 8080/Z80 to the 8088. PolyForth was
obviously just an old CP/M program that had been ported line-by-line
to the 8088. I think there were some automated tools available that
converted 8080 assembly language into 8088 assembly language, but
didn't take advantage of any of the 8088 features --- these tools were
mostly used by non-programmers who just wanted to keep an old program
running.

> PolyForth also has extended memory operators that take a segment and
> offset - E@ , E! etc. to access the full 1MByte address range.

Far addressing is not very useful. You have double numbers for your
segment/offset pairs, and these are cumbersome and slow to juggle on
the stack, and they take up a lot of memory (two words rather than
one) to store. Also, that only helps with data, and not with code.

Most people in those days just used Turbo C (or some other C or Pascal
compiler) with the Small memory model. In this case, you get 64K of
data and 64K of code for your application (the compiler and symbol
table are stored elsewhere during compilation), and your program is
fast because you are using Near addressing for everything (no segment/
offset Far pointers).

There is no *reason* for Forth Inc. to cram both application and
compiler into a single 64K segment as they did in PolyForth. There is
no benefit whatsoever. The only *reason* is that nobody at Forth Inc.
knew 8088 assembly language.

Hi Hugh,

Something has happened to your last post - the original text seems to
have got copied twice, so I snipped it all.

> Most people in those days just used Turbo C (or some other C or Pascal
>compiler) with the Small memory model. In this case, you get 64K of
>data and 64K of code for your application (the compiler and symbol
>table are stored elsewhere during compilation), and your program is
>fast because you are using Near addressing for everything (no segment/
>offset Far pointers).

I originally asked :
Do you mean that polyForth failed to use the F86-style segmented
model, which limited it to 64K?
The F-86 model uses a segment register as the Forth Instruction
Pointer, so that Forth words must be aligned to a 16 byte paragraph.
Can I assume that you mean that polyForth should have used separate
64K code and 64K data spaces?

>There is no *reason* for Forth Inc. to cram both application and
>compiler into a single 64K segment as they did in PolyForth.
One reason is to avoid having two sets of memory access words.

>There is
>no benefit whatsoever. The only *reason* is that nobody at Forth Inc.
>knew 8088 assembly language.
This statement is absurd in so many ways that it makes it very
difficult for anyone reading this thread to take anything you say
seriously.
1) I know many people who have worked at Forth,Inc., and all of them
knew about the 8086 and its segmented architecture
2) No one can know that *nobody* at Forth Inc. knew this
3) There are pros and cons with any architecture, so to say there is
"no benefit whatsoever" is wrong

It is very difficult to discuss these ideas if you smother any
sensible comments you make in outrageous opinions and speculation.

>>This is like colorForth's Just-In-Time (JIT)
>> compilation technique, and allows programs to be as large as your disk
>> drive can hold.
>I wouldn't consider the use of binary overlays to be like Just-In-Time
>(JIT) compilation technique.
I agree - JIT is not the same as binary overlays, but I said
"colorForth's Just-In-Time (JIT) compilation technique".
Perhaps we need a new name for this, to avoid confusion - how about
CJIT?
>lol
Is it just me, or the use of "lol" in this context slightly offensive?
I mean this as a serious question - I'm not sure how to interpret
it :-)

With CJIT the original source (as typed by the programmer) is
converted on-the-fly into pre-parsed source. This pre-parsed source is
then "compiled" when needed.
I put "compiled" in quotes because this is not the same as normal
compilation from text source - its much simpler and faster.
With Binary Overlays the original source is compiled into a binary
image which is then used to overwrite part of the Forth system
dictionary.

The main difference between these two techniques is that CJIT does not
need to be decompiled to be edited.

Best regards,
Howerd

In article <wvWdnQsAo5zAxpXNnZ2dnUVZ_vqdnZ2d@supernews.com> ,
erather@forth.com (Elizabeth D. Rather) wrote:

> Every programming technology is subject to the limitations
> of its physical platform.

Just about every serious CPM program used overlays of some sort. The
data base I ran on my Video Genie (TRS80) clone had limited space in
memory and relied on the disks to swap data in and out.


Ken Young

On Jul 18, 4:30*am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
>
> Users. Inertia.
>

I just read "Farewell, ESD" by Jack Ganssle (who doesn't like Forth):
http://www.eetimes.com/discussion/br...ystem=embedded

Quote:
"Regular columnists Dan Saks and Jack Crenshaw have had a fiercely-
loyal following. Who knows how many others have contributed articles
and commentary?"

May be regular columnists are another Secret of a Successful
Programming Language?

May be a regular Forth columnist would have helped ...