Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #14139 > unrolled thread

The Secret of a Successful Programming Language?

Back to article view | Back to comp.lang.forth

Contents

  The Secret of a Successful Programming Language? Bluebee <visualforth@rocketmail.com> - 2012-07-17 17:57 -0700
    Re: The Secret of a Successful Programming Language? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-18 01:30 -0700
      Re: The Secret of a Successful Programming Language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-18 15:19 +0200
        Re: The Secret of a Successful Programming Language? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-18 08:24 -0700
        Re: The Secret of a Successful Programming Language? hughaguilar96@yahoo.com - 2012-07-18 16:25 -0700
          Re: The Secret of a Successful Programming Language? Ron Aaron <rambamist@gmail.com> - 2012-07-19 08:35 +0300
            Re: The Secret of a Successful Programming Language? Hannu Vuolasaho <hannu.vuolasaho@nospam.tut.fi.invalid> - 2012-07-19 06:31 +0000
            Re: The Secret of a Successful Programming Language? visploveslisp@gmail.com - 2012-07-25 16:49 -0700
          Re: The Secret of a Successful Programming Language? Howerd <howerdo@yahoo.co.uk> - 2012-07-19 01:55 -0700
            Re: The Secret of a Successful Programming Language? "Elizabeth D. Rather" <erather@forth.com> - 2012-07-19 09:09 -1000
              Re: The Secret of a Successful Programming Language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-07-19 19:36 -0700
                Re: The Secret of a Successful Programming Language? Spam@ControlQ.com - 2012-07-20 12:22 -0400
              Re: The Secret of a Successful Programming Language? kenney@cix.compulink.co.uk - 2012-07-20 12:08 -0500
            Re: The Secret of a Successful Programming Language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-07-19 18:49 -0700
              Re: The Secret of a Successful Programming Language? Howerd <howerdo@yahoo.co.uk> - 2012-07-20 00:39 -0700
                Re: The Secret of a Successful Programming Language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-07-24 00:21 -0700
          Re: The Secret of a Successful Programming Language? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-19 11:20 +0000
          Re: The Secret of a Successful Programming Language? "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2012-07-24 20:01 -0700
            Re: The Secret of a Successful Programming Language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-07-24 23:00 -0700
              Re: The Secret of a Successful Programming Language? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-25 01:22 -0700
                Re: The Secret of a Successful Programming Language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-07-25 01:51 -0700
                Re: The Secret of a Successful Programming Language? "Elizabeth D. Rather" <erather@forth.com> - 2012-07-25 07:18 -1000
                  Re: The Secret of a Successful Programming Language? vandys@vsta.org - 2012-07-25 18:07 +0000
                    Re: The Secret of a Successful Programming Language? Spam@ControlQ.com - 2012-07-25 16:53 -0400
                    Re: The Secret of a Successful Programming Language? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-26 01:46 -0700
                      Re: The Secret of a Successful Programming Language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-07-26 22:48 -0700
                        Re: The Secret of a Successful Programming Language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-27 23:44 +0200
                          Re: The Secret of a Successful Programming Language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-07-27 15:25 -0700
                            Re: The Secret of a Successful Programming Language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-28 00:44 +0200
                  Re: The Secret of a Successful Programming Language? Marc Olschok <nobody@nowhere.invalid> - 2012-07-28 18:15 +0000
                    Re: The Secret of a Successful Programming Language? "Elizabeth D. Rather" <erather@forth.com> - 2012-07-28 13:35 -0500
                      Re: The Secret of a Successful Programming Language? Paul Rubin <no.email@nospam.invalid> - 2012-07-28 21:59 -0700
                        Re: The Secret of a Successful Programming Language? Spam@ControlQ.com - 2012-07-30 11:53 -0400
                          Re: The Secret of a Successful Programming Language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-07-30 20:38 -0700
                Re: The Secret of a Successful Programming Language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-25 23:25 +0200
                Re: The Secret of a Successful Programming Language? visploveslisp@gmail.com - 2012-07-25 16:52 -0700
                  Re: The Secret of a Successful Programming Language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-07-25 17:00 -0700
                Re: The Secret of a Successful Programming Language? visploveslisp@gmail.com - 2012-07-25 17:01 -0700
                Re: The Secret of a Successful Programming Language? visualforth@rocketmail.com - 2012-07-25 17:10 -0700
                  Re: The Secret of a Successful Programming Language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-07-25 22:44 -0700
                Re: The Secret of a Successful Programming Language? Doug Hoffman <glidedog@gmail.com> - 2012-07-26 05:24 -0400
                  Re: The Secret of a Successful Programming Language? Doug Hoffman <glidedog@gmail.com> - 2012-07-26 05:26 -0400
                    Re: The Secret of a Successful Programming Language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-07-26 22:26 -0700
                      Re: The Secret of a Successful Programming Language? Doug Hoffman <glidedog@gmail.com> - 2012-07-27 13:52 -0400
                        Re: The Secret of a Successful Programming Language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-07-27 15:52 -0700
              Re: The Secret of a Successful Programming Language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-07-25 01:30 -0700
      Re: The Secret of a Successful Programming Language? Bluebee <visualforth@rocketmail.com> - 2012-07-21 16:17 -0700
    Re: The Secret of a Successful Programming Language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-18 15:13 +0200
      Re: The Secret of a Successful Programming Language? visploveslisp@gmail.com - 2012-07-28 21:56 -0700

Page 1 of 3  [1] 2 3  Next page →

#14139 — 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/2012/06/beard-gallery/

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

[toc] | [next] | [standalone]

#14140

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/2012/06/beard-gallery/
>
> Seems to be that Chuck Moore made one mistake in his life: he didn't
> grow a beard.

Users. Inertia.

[toc] | [prev] | [next] | [standalone]

#14143

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/2012/06/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/

[toc] | [prev] | [next] | [standalone]

#14145

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/2012/06/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!

[toc] | [prev] | [next] | [standalone]

#14151

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/2012/06/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 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 abundantly obvious that nobody at Forth Inc. knew enough about 8088 assembly language to 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. 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. 

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.

[toc] | [prev] | [next] | [standalone]

#14157

On 07/19/2012 02:25 AM, 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"

[toc] | [prev] | [next] | [standalone]

#14159

On 2012-07-19, Ron Aaron <rambamist@gmail.com> wrote:
> On 07/19/2012 02:25 AM, 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

[toc] | [prev] | [next] | [standalone]

#14392

On Wednesday, July 18, 2012 10:35:19 PM UTC-7, Ron Aaron wrote:
> On 07/19/2012 02:25 AM, 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"

and boy are they missing out

:)

majority of the wingnuts using crapola lie ruby rails and are happy with it

lolz

[toc] | [prev] | [next] | [standalone]

#14165

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/2012/06/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 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. [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.
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

[toc] | [prev] | [next] | [standalone]

#14178

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."
==================================================

[toc] | [prev] | [next] | [standalone]

#14195

On Jul 19, 12:09 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> 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).

That Saudi airport project was written a loooooong time ago using the
venerable PDP-11, by Chuck Moore himself. He left Forth Inc. decades
ago, but you are still bragging about his work for Forth Inc. when he
was still employed at Forth Inc.. He doesn't brag about the Saudi
airport project --- it was decades ago and he has forgotten about it,
and he did it for an ex-employer that he is no longer supporting. You
endlessly brag on this forum and on the Forth Inc. website about
having known Chuck Moore --- but I notice that he doesn't brag about
having known you. According to Jeff Fox, you ripped Chuck Moore off
for $40,000 --- you know, a lot of people in this world would have
killed you for that.

It is really pathetic that you continue to hold up Chuck Moore as a
shining example of Forth Inc. prowess, decades after Chuck Moore
ditched Forth Inc..

What exactly was your personal contribution to the Saudi airport
project? Did you make coffee?

I would just ignore you --- but you seriously offended me by siding
with Passaniti in saying that my software "sucks" and that I "pulled
it out of my ass." You hate and fear Forth programmers so much that
you would ally yourself with a homosexual troll so long as he agrees
to attack Forth programmers and not attack Forth Inc.. You really
shouldn't have attacked me --- people who live in glass houses
shouldn't throw stones --- and Forth Inc. is a glass house.

> 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.

64K is not a "limitation of the physical platform" for the 8088 ---
although it was for the 8080 and Z80.

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

By the time that the 80386 came out, Forth was dead.

Forth died out during the lengthy time period when the 8088 and 80286
were being used, and Turbo C dominated as the development system.

[toc] | [prev] | [next] | [standalone]

#14216

On Thu, 19 Jul 2012, Hugh Aguilar wrote:
> By the time that the 80386 came out, Forth was dead.
>
> Forth died out during the lengthy time period when the 8088 and 80286
> were being used, and Turbo C dominated as the development system.
>

Run over by a cab, I suppose?

[toc] | [prev] | [next] | [standalone]

#14218

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

[toc] | [prev] | [next] | [standalone]

#14194

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 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 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.

[toc] | [prev] | [next] | [standalone]

#14198

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

[toc] | [prev] | [next] | [standalone]

#14343

On Jul 20, 12:39 am, Howerd <howe...@yahoo.co.uk> wrote:
> 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?

The F86 model does allow for large programs, but it is slow. UR/Forth
used separate 64K code and data spaces, plus a 64K space for the
dictionary headers. This was much faster. There was some limitation on
the size of the programs but not too much --- this was highly
comparable to the Small memory model used in Turbo C etc.. Both of
these designs were reasonable, with UR/Forth emphasizing speed and F83
emphasizing size.

The only really bad design was PolyForth. It was slow (comparable to
F83) because it used ITC, but it didn't allow for large programs which
is supposed to be the benefit of ITC (as done by F83). The size issue
was the major problem. When you have your application's code and data,
and the compiler and the dictionary, all in a single 64K segment, your
applications are going to be extremely limited in size. Forth Inc.
didn't just shoot themselves in the foot, they shot themselves in both
feet (size and speed).

The whole point of moving from the 8-bit computers (Z80, 65c02 and
6809) to MS-DOS, was to escape the 64K limit of those computers.
Within this context, PolyForth inflicting a 64K limit on MS-DOS users
was just not amusing at all --- this was like buying a Porsche and
then saving money by not buying tires but just driving it on the rims
--- the fact that this was done by "Forth Inc." killed Forth's
credibility.

> >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.

The application program doesn't normally access code memory or the
dictionary headers anyway, so this should never be an issue.

PolyForth did have E@ and E! for accessing memory using far pointers.
Considering how little data memory there was, I expect that most
PolyForth programmers did try to put as much data as they could out
there in far space. But that is hugely inefficient and cumbersome!
This is supposed to be an alternative to having two sets of memory
access words?

Meanwhile, large numbers of programmers were perfectly happy writing
Turbo C programs using the Small memory model --- they thought that
Forth was just a weird joke.

> >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.

There are no pros to the PolyForth design.

It may well be true that people who worked at Forth Inc. knew 8088
assembly language and knew about the segmented architecture --- but
Elizabeth Rather obviously didn't --- so they had to just play dumb
and pretend that 64K was a "physical limitation" of the 8088.

This is what happens when a non-technical salesperson gets put in
charge --- the employees just play dumb and go along with the most
outrageous technical decisions --- when the boss speaks you just grin
like an idiot and bob your head up and down, and so long as your
paycheck doesn't bounce you don't care.

> >>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 :-)

For the most part, I don't use lol and all of that internet slang. I
apologize if that was offensive.

Comparing binary overlays to JIT was pretty amazing though --- I did
actually laugh out loud when I read that.

We have a lot of non-programmers on comp.lang.forth who fake up
expertise with their jargon-heavy discussions peppered with idiotic
ideas. The obvious example is John Passaniti. He first attacked my use
of binary trees (symtab in the novice package) saying that hash tables
are better. I don't think that is really true, but at least it
partially makes sense. Then he went on to say that linked lists are
more efficient than my binary trees too. It became obvious at that
time that he was a complete phony.

When I read your statement that binary overlays are like JIT, I
supposed that you were a phony like Passaniti. Other than that one
weird remark however, your comments have been on the level
technically, and you haven't resorted to vulgar language --- so I'll
give you the benefit of the doubt and assume that you are a
programmer.

> 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.

I don't know anything about ColorForth, and I don't really want to
either, as all of that color-syntax stuff is too far out and funky for
my taste.

Coincidentally however, the Forth that I am currently writing uses a
technique similar to what you are describing. I don't have an
assembler. I write the low-level words using a traditional assembler.
Using macros in that assembler (HLA), I generate a dictionary that
keeps track of info about the words, including the address that the
code starts and ends at. The Forth compiler pastes the low-level words
into the high-level words effectively providing inline assembly
despite the fact that I don't have an assembler available at compile-
time. The already-compiled words are like little tiny binary-overlays
that get copied into the middle of the words getting compiled later
on. It is crude, and there are limitations compared to using a Forth
assembler, but it works. My goal is to have execution speed at least
twice that of SwiftForth, and I think this is a reasonable goal.

This Forth that I described here is called ToyForth and it will mostly
be used for writing toy programs similar to what Gforth is used for
(suduko solvers, etc.). Later on ToyForth will become HostForth and be
incorporated into Straight Forth. The Straight Forth system consists
of HostForth that runs on the desktop computer and TargForth that is
the cross-compiler written in HostForth. The only program that will
ever be written in HostForth is TargForth. The users will program in
TargForth and will have minimal need to mess with HostForth which is
underneath it. HostForth doesn't have to be particularly fast
executing because applications aren't written in it, which is why I am
using such a crude compilation technique as described above. By
comparison, TargForth will use a more sophisticated compilation
technique --- it will use a Forth assembler for the micro-controller
that is being targeted and it will do analytic compilation.

I originally wanted Gforth to be my HostForth, and make TargForth an
ANS-Forth compliant program. This didn't work out. ANS-Forth has
serious problems. This is why I had to write ToyForth/HostForth myself
--- despite the fact that there are already many many x86 Forths
available. Nothing in the Forth world is any good! In the year 2012 I
have to write my own Forth from scratch using a traditional assembler,
because there really isn't anything already available that is worth
using --- this is why I say that Forth is dead.

> Best regards,
> Howerd

Best regards to you too! Good job on maintaining a civil discussion.

I don't tolerate vulgarity. Over the weekend when I was driving my cab
I had to call the police because some faggot took off his clothes and
was dancing around naked on the side of the road. I'm really sick of
this kind of thing. When Elizabeth Rather supported John Passaniti in
telling me that my code "sucks," she did the one thing that really
offends me --- I will never forgive her for that.

[toc] | [prev] | [next] | [standalone]

#14167

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/2012/06/beard-galler=
>y/
>> &gt;&gt;
>> &gt;&gt; Seems to be that Chuck Moore made one mistake in his life: he di=
>dn&#39;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&#39;s the beard, get over it.  And Forth200x will be a huge success,=
>=20
>> because our editor&#39;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

[toc] | [prev] | [next] | [standalone]

#14360

On Wednesday, July 18, 2012 6:25:11 PM UTC-5, (unknown) 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/2012/06/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 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 abundantly obvious that nobody at Forth Inc. knew enough about 8088 assembly language to 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. 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. 
> 
> 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.

A poll of most programmers in the world would include the ones that have written their own FORTHs, and the rest who know how to look past a namng convention, not to mention the open source projects. What a crock.

[toc] | [prev] | [next] | [standalone]

#14364

On Jul 24, 8:01 pm, "Clyde W. Phillips Jr." <cwpj...@gmail.com> wrote:
> A poll of most programmers in the world would include the ones that have written their own FORTHs, and the rest who know how to look past a namng convention, not to mention the open source projects. What a crock.

I don't know what you are talking about in regard to a naming
convention or open-source projects.

It is true that a lot of programmers have written their own Forth.
Another thing that I have noticed is that when I say that I have
programmed Forth professionally (such as during a job interview for a
C programming job), somebody will invariably announce that he is a
"real Forth expert," meaning that he wrote a Forth of his own. He
always expects me to be awed by the fact that he is a Forth compiler-
writer whereas I am a mere Forth application programmer. In the old
days, these were typically ITC implementations loosely based on
PolyForth except with the 64K limit problem solved (either by putting
code and data in their own 64K segments or by using ES as the Forth IP
and starting every word on a paragraph boundary). In more modern
times, these are typically C implementations with a gigantic SWITCH
statement (what Rod Pemberton is doing). The programmer declares
himself to be a "real Forth expert" and in the next breath will
declare that Forth is a mildly amusing educational exercise but that
it has no practical value. Whether it is an ITC-based PolyForthesque
implementation or a C-based Gforthesque implementation, the execution
speed is too slow for it to be used professionally (by about an order
of magnitude). Of course, Python is also slow as molasses, but at
least Python has powerful features and extensive libraries, which
neither SwiftForth nor Gforth have.

Forth Inc. not only ruined Forth's credibility with their 64K-limited
PolyForth, but they also ruined Forth's credibility with their
horribly-slow ITC implementation. This is why, during 16-bit MS-DOS
days when Turbo C dominated, almost everybody who knew about Forth
described Forth as an interpreted language. People would routinely
state that because PolyForth uses ITC, Forth doesn't deserve to be
described as a "compiler" but should instead be described as an
"interpreter" --- that PolyForth was in the same category as QBasic,
but should not be compared to the C compilers at all.

[toc] | [prev] | [next] | [standalone]

#14366

On Jul 25, 7:00 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
> On Jul 24, 8:01 pm, "Clyde W. Phillips Jr." <cwpj...@gmail.com> wrote:
>
> > A poll of most programmers in the world would include the ones that have written their own FORTHs, and the rest who know how to look past a namng convention, not to mention the open source projects. What a crock.
>
> I don't know what you are talking about in regard to a naming
> convention or open-source projects.
>
> It is true that a lot of programmers have written their own Forth.
> Another thing that I have noticed is that when I say that I have
> programmed Forth professionally (such as during a job interview for a
> C programming job), somebody will invariably announce that he is a
> "real Forth expert," meaning that he wrote a Forth of his own. He
> always expects me to be awed by the fact that he is a Forth compiler-
> writer whereas I am a mere Forth application programmer. In the old
> days, these were typically ITC implementations loosely based on
> PolyForth except with the 64K limit problem solved (either by putting
> code and data in their own 64K segments or by using ES as the Forth IP
> and starting every word on a paragraph boundary). In more modern
> times, these are typically C implementations with a gigantic SWITCH
> statement (what Rod Pemberton is doing). The programmer declares
> himself to be a "real Forth expert" and in the next breath will
> declare that Forth is a mildly amusing educational exercise but that
> it has no practical value. Whether it is an ITC-based PolyForthesque
> implementation or a C-based Gforthesque implementation, the execution
> speed is too slow for it to be used professionally (by about an order
> of magnitude). Of course, Python is also slow as molasses, but at
> least Python has powerful features and extensive libraries, which
> neither SwiftForth nor Gforth have.
>
> Forth Inc. not only ruined Forth's credibility with their 64K-limited
> PolyForth, but they also ruined Forth's credibility with their
> horribly-slow ITC implementation. This is why, during 16-bit MS-DOS
> days when Turbo C dominated, almost everybody who knew about Forth
> described Forth as an interpreted language. People would routinely
> state that because PolyForth uses ITC, Forth doesn't deserve to be
> described as a "compiler" but should instead be described as an
> "interpreter" --- that PolyForth was in the same category as QBasic,
> but should not be compared to the C compilers at all.

Well, getting back to the original topic, I stand by my original
assertion. The secret to a successful progamming language is simply:

* Users
* Inertia

And of course, you don't get the intertia without the users.

There's one other secret ingredient: The languge you learned at
university.

AT&T pulled of a very clever manoeuvre when they licenced Unix to the
universities for next to nothing. Obviously, I don't know if it was a
deliberate move, but the side effect was to breed generation after
generation of C programmers. That obviously 'bubbled up' to the
workplace as those students graduated. They took their programming
languge skills with them in exactly the same way as they took their
spoken language skills with them. In other words, it was completely
natural.

Back in the early 2000's, working as a Principal Software Engineer for
a SCADA company, we suddenly saw a 'paradigm shift' (I think that
phrase is somewhat over-used, but is applicable in this case): Our new
graduates didn't want to use C, or C++. Why? Because they probably
only spent a couple of days studying the language at college/uni. C
was out. Java was in. The King is dead. Long live the King. They
didn't want to do 'low-level' close-to-the-metal programming. They
wanted to do OOP, because it was sexy, and it was what they knew.
Showing a 25 year old graduate how pointers work in C is not fun.
It was quite a battle getting them to settle down and see the wood for
the trees. But it really was night and day. British Uni's dumped C in
around 2001 and switched to Java.

I attribute that directly to the success of Java, just as with C.

So, you need:

* Promotion via university education, which gives you:
* Users, which gives you:
* Inertia

Once it's got the intertia, it's quite un-stoppable.

What it has *absolutely nothing* to do with is:

* The quality of the language!

YMMV :-)

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web