Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
The Secret of a Successful Programming Language?
557 views
Skip to first unread message
Bluebee
Jul 17, 2012, 8:57:16 PM7/17/12
to dirk....@usa.net
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.
- 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.
Mark Wills
Jul 18, 2012, 4:30:51 AM7/18/12
to
Bernd Paysan
Jul 18, 2012, 9:13:06 AM7/18/12
to
Bluebee wrote:
> 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.
This is why we appointed Peter Knaggs to be the standard editor.
> 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.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
Bernd Paysan
Jul 18, 2012, 9:19:49 AM7/18/12
to
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.
>> 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.
It's the beard, get over it. And Forth200x will be a huge success,
because our editor's beard is huge.
Mark Wills
Jul 18, 2012, 11:24:56 AM7/18/12
to
coat!
hughag...@yahoo.com
Jul 18, 2012, 7:25:11 PM7/18/12
to
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.
> 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.
> 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,
> Come on, this was a really funny post, and you want to argue with facts.
> 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.
Ron Aaron
Jul 19, 2012, 1:35:19 AM7/19/12
to
On 07/19/2012 02:25 AM, hughag...@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
> The majority of the programmers in the world believe that Forth Inc. *is* Forth.
is a language called "Forth", let alone a company called "Forth Inc"
Hannu Vuolasaho
Jul 19, 2012, 2:31:02 AM7/19/12
to
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
Howerd
Jul 19, 2012, 4:55:07 AM7/19/12
to
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
> 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.
>
>
> > >> 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,
>
> > Come on, this was a really funny post, and you want to argue with facts.
> > 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.
>
> 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.
>
>
> 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 -
> 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.
> It is generally assumed that Forth Inc. represents the pinnacle of Forth technology
> ...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
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
Albert van der Horst
Jul 19, 2012, 7:20:40 AM7/19/12
to
In article <c789bbd2-148c-424c...@googlegroups.com>,
>t=92s
>y/
>> >>
>> >> Seems to be that Chuck Moore made one mistake in his life: he di=
>> > 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
>> --=20
>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
<hughag...@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 i=
>On Wednesday, July 18, 2012 6:19:49 AM UTC-7, Bernd Paysan wrote:
>> Mark Wills wrote:
>t=92s
>> >> all about the beard."
>> >>
>> >> Source:http://www.wired.com/wiredenterprise/2012/06/beard-galler=
>> >>
>y/
>> >>
>> >> Seems to be that Chuck Moore made one mistake in his life: he di=
>dn't
>> >> grow a beard.
>> >=20
>> >> grow a beard.
>> > 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
>> "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* F=
>> "If you want it done right, you have to do it yourself"
>> http://bernd-paysan.de/
>
>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
Elizabeth D. Rather
Jul 19, 2012, 3:09:17 PM7/19/12
to
On 7/18/12 10:55 PM, Howerd wrote:
...
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."
==================================================
...
>> ...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.
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.
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?
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."
==================================================
Hugh Aguilar
Jul 19, 2012, 9:49:35 PM7/19/12
to
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
> 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.
(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.
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.
Hugh Aguilar
Jul 19, 2012, 10:36:53 PM7/19/12
to
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
> 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).
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.
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.
Forth died out during the lengthy time period when the 8088 and 80286
were being used, and Turbo C dominated as the development system.
Howerd
Jul 20, 2012, 3:39:00 AM7/20/12
to
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 :
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
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).
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
model, which limited it to 64K?
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.
>There is
>no benefit whatsoever. The only *reason* is that nobody at Forth Inc.
>knew 8088 assembly language.
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.
"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
Sp...@controlq.com
Jul 20, 2012, 12:22:53 PM7/20/12
to
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?
> 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.
>
ken...@cix.compulink.co.uk
Jul 20, 2012, 1:08:52 PM7/20/12
to
In article <wvWdnQsAo5zAxpXN...@supernews.com>,
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
era...@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
> Every programming technology is subject to the limitations
> of its physical platform.
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
Bluebee
Jul 21, 2012, 7:17:29 PM7/21/12
to
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/break-points/4372144/Farewell--ESD?Ecosystem=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 ...
>
> Users. Inertia.
>
I just read "Farewell, ESD" by Jack Ganssle (who doesn't like Forth):
http://www.eetimes.com/discussion/break-points/4372144/Farewell--ESD?Ecosystem=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 ...
Hugh Aguilar
Jul 24, 2012, 3:21:06 AM7/24/12
to
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
> 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?
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.
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.
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 :-)
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.
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.
Clyde W. Phillips Jr.
Jul 24, 2012, 11:01:14 PM7/24/12
to
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:
> On Wednesday, July 18, 2012 6:19:49 AM UTC-7, Bernd Paysan 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/2012/06/beard-gallery/
> > &gt;&gt;
> > &gt;&gt; Seems to be that Chuck Moore made one mistake in his life: he didn&#39;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&#39;s the beard, get over it. And Forth200x will be a huge success,
> > because our editor&#39;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. 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.
> 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.
>
>
> 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.
> Then ANS-Forth came out in 1994, and it was a grossly bad design. This nailed the coffin shut forever.
>
>
> 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.
Hugh Aguilar
Jul 25, 2012, 2:00:21 AM7/25/12
to
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
> 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.
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.
Mark Wills
Jul 25, 2012, 4:22:11 AM7/25/12
to
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 :-)
Hugh Aguilar
Jul 25, 2012, 4:30:50 AM7/25/12
to
On Jul 24, 11:00 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
> ... somebody will invariably announce that he is a
> "real Forth expert," meaning that he wrote a Forth of his own. ...
wasn't a very good singer. The result was that almost anybody could
sing a Bob Dylan song and do a better job than Bob Dylan himself.
Forth is like that --- the concept (invented by Chuck Moore) is
excellent, but Forth Inc. (headed by Elizabeth Rather after Chuck
Moore got kicked out) is all marketing glitz and no technical
capability. The result is that almost anybody can implement a Forth
and do a better job than Forth Inc. itself.
> ... somebody will invariably announce that he is a
> "real Forth expert," meaning that he wrote a Forth of his own. ...
> 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).
It has been said that Bob Dylan's songs were excellent, but that he
> 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).
wasn't a very good singer. The result was that almost anybody could
sing a Bob Dylan song and do a better job than Bob Dylan himself.
Forth is like that --- the concept (invented by Chuck Moore) is
excellent, but Forth Inc. (headed by Elizabeth Rather after Chuck
Moore got kicked out) is all marketing glitz and no technical
capability. The result is that almost anybody can implement a Forth
and do a better job than Forth Inc. itself.
Hugh Aguilar
Jul 25, 2012, 4:51:20 AM7/25/12
to
On Jul 25, 1:22 am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> 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.
For the most part, Pascal was the standard teaching language for
> 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.
undergraduates, and C was the language for graduate students who were
primarily interested in OS stuff rather than application programming.
I wouldn't know from direct experience though, because I never made it
past high school.
I think that Java became successful in the universities because of its
security features. With Pascal and C, there were chronic problems in
regard to the students messing up the computer system either
accidentally or maliciously. Also, the students would hack into the
school computer system to get access to data such as other students'
accounts. With Java, each student is given his own sandbox and he
can't access anything outside of that.
Sun originally developed the Java security system with the intention
that we would download Java applets and run them on our personal
computers without worry that they would do anything malicious to our
system (install viruses). For reasons that I don't understand, this
didn't work out very well and JavaScript took over instead, with Java
being rarely used. Java's security system then found a home at the
universities. Ironically, many of those students are now using Java on
the server-side rather than the client-side, just because they are
familiar with Java and not because Java has any inherent advantage,
which is exactly the opposite of what Sun intended.
I do use Java client-side every day though! I play Go on KGS and this
is done in a Java applet that gets downloaded every time that I log
on. My KGS name is "Classic" in case anybody wants to challenge me to
a game. :-) I don't program in Java.
Elizabeth D. Rather
Jul 25, 2012, 1:18:21 PM7/25/12
to
On 7/24/12 10:22 PM, Mark Wills wrote:
...
> 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.
This worked because AT&T was a well-known and respected entity
(especially Bell Labs, which developed it). FORTH, Inc. was trying to
publicize Forth at the same time. It was more difficult, because we had
zero name-recognition and inadequate capitalization to do the kind of
promotion they were able to (in this case, papers at conferences,
journal articles, etc., all of which costs money and is easier to do if
you are from a well-known organization).
We also provided free or low-cost Forths to universities, and had
several dedicated users, but although they told us Forth gave them a
technical advantage they were dissed in academic conferences because
Forth was perceived as a "hobby" language. So they adopted a policy of
not mentioning the language they used :-((
> 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.
Another example of promotion by a highly-respected company (Sun).
> 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!
Sad but true.
...
> 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.
Generally true.
> 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.
(especially Bell Labs, which developed it). FORTH, Inc. was trying to
publicize Forth at the same time. It was more difficult, because we had
zero name-recognition and inadequate capitalization to do the kind of
promotion they were able to (in this case, papers at conferences,
journal articles, etc., all of which costs money and is easier to do if
you are from a well-known organization).
We also provided free or low-cost Forths to universities, and had
several dedicated users, but although they told us Forth gave them a
technical advantage they were dissed in academic conferences because
Forth was perceived as a "hobby" language. So they adopted a policy of
not mentioning the language they used :-((
> 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!
van...@vsta.org
Jul 25, 2012, 2:07:01 PM7/25/12
to
>> 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.
>> ...
>> 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.
> This worked because AT&T was a well-known and respected entity
> (especially Bell Labs, which developed it).
To be fair, C hit a very sweet spot at the time. We were faced with PL/1
> (especially Bell Labs, which developed it).
type languages, Pascal-oid ones, Fortran was still around, and then there
were the brutally ugly ones like Bliss. C let you quickly write source which
compiled into decent machine code. The compiler fit on a PDP-11. The C
library provided a lot of stuff which saved you time, and C was good at
not getting in the way of what you were trying to do while still being
helpful.
Not only was the software easily gotten (at a university, anyway), but the
documentation was very approachable. Folks may not realize what a difference
it made, but Kernighan/Ritchie/Thompson and such used a very readable,
conversational style which made it much easier to get up to speed on what
they provided. The norm back then was IBM-style "this page intentionally
left blank" style of technical tomes.
And yes, I was one of those who picked up C in college, then helped it
displace Modcal at HP once I was in the workforce. With hindsight I still
believe it was the optimal choice for that time in technology.
--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html
Sp...@controlq.com
Jul 25, 2012, 4:53:28 PM7/25/12
to
On Wed, 25 Jul 2012, van...@vsta.org wrote:
> Date: 25 Jul 2012 18:07:01 GMT
> From: van...@vsta.org
> Newsgroups: comp.lang.forth
> Subject: Re: The Secret of a Successful Programming Language?
Modcal!!! I was one of the first recipients of the HP9000 series 540
outside the continental US. The 5xx was build upon the Focus chip set, a
32bit micro processor architecture (arguably one of the first), which
predated the PA-RISC architecture and its HPUX variant ran on top of a
hardware interface written in Modcal, IIRC. The 5xx was short lived, and
replace rapidly by the PA-RISC when it came out ...
I also used the SPL (systems programming language) on the HP 3000 MPE-V
system, which was what the bulk of MPE was written in (a 16 bit stack
oriented architecture with segmented virtual code space) ... ahhh good
times 8-) ....
Truly a blast from the past, Andy ...
Cheers,
Rob Sciuk
> Date: 25 Jul 2012 18:07:01 GMT
> From: van...@vsta.org
> Newsgroups: comp.lang.forth
> Subject: Re: The Secret of a Successful Programming Language?
outside the continental US. The 5xx was build upon the Focus chip set, a
32bit micro processor architecture (arguably one of the first), which
predated the PA-RISC architecture and its HPUX variant ran on top of a
hardware interface written in Modcal, IIRC. The 5xx was short lived, and
replace rapidly by the PA-RISC when it came out ...
I also used the SPL (systems programming language) on the HP 3000 MPE-V
system, which was what the bulk of MPE was written in (a 16 bit stack
oriented architecture with segmented virtual code space) ... ahhh good
times 8-) ....
Truly a blast from the past, Andy ...
Cheers,
Rob Sciuk
Bernd Paysan
Jul 25, 2012, 5:25:31 PM7/25/12
to
Mark Wills wrote:
> 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.
And to get university education, you absolutly need a guy with a beard.
> 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.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
visplo...@gmail.com
Jul 25, 2012, 7:52:04 PM7/25/12
to
On Wednesday, July 25, 2012 1:22:11 AM UTC-7, Mark Wills wrote:
> 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.
>
> 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
> a SCADA company, we suddenly saw a 'paradigm shift' (I think that
;)
thats what I am asking!!!!
;)
;)
i was imagining today a forth app that used 1 file on unix but kept all kinda things in thsi file, and the file could extend into ram, like varnish cache does, and this fiel can do foth based database stuff and have data and have lots of multi tasking all in 1 file so minial need to screw with forth to unix compat file crap, and max fun programming forth to dominate the web with leaner the a microbe web apps!!!
> 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.
> Well, getting back to the original topic, I stand by my original
> assertion. The secret to a successful progamming language is simply:
>
> * Users
> * Inertia
>
>
> 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
> 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.
>
> 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
> was out. Java was in. The King is dead. Long live the King. 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
> 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
> 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.
>
> 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
>
>
> What it has *absolutely nothing* to do with is:
>
> * The quality of the language!
>
> YMMV :-)
so how can forth pull a clever maneuver?
> What it has *absolutely nothing* to do with is:
>
> * The quality of the language!
>
> YMMV :-)
;)
thats what I am asking!!!!
;)
;)
i was imagining today a forth app that used 1 file on unix but kept all kinda things in thsi file, and the file could extend into ram, like varnish cache does, and this fiel can do foth based database stuff and have data and have lots of multi tasking all in 1 file so minial need to screw with forth to unix compat file crap, and max fun programming forth to dominate the web with leaner the a microbe web apps!!!
Hugh Aguilar
Jul 25, 2012, 8:00:17 PM7/25/12
to
visplo...@gmail.com
Jul 25, 2012, 8:01:00 PM7/25/12
to
> > "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.
> Well, getting back to the original topic, I stand by my original
> assertion. The secret to a successful progamming language is simply:
>
> * Users
> * Inertia
>
>
> 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
> 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.
>
> 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
> was out. Java was in. The King is dead. Long live the King. 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
> 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
> 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.
>
> 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
>
>
> What it has *absolutely nothing* to do with is:
>
> * The quality of the language!
>
> YMMV :-)
lol
> What it has *absolutely nothing* to do with is:
>
> * The quality of the language!
>
> YMMV :-)
yeaheha!!
u tell em!!
also helps to have successful apps!!
unix being in c was quite a help to c
I agree
wow im rhyming
what glee
visplo...@gmail.com
Jul 25, 2012, 7:49:24 PM7/25/12
to
On Wednesday, July 18, 2012 10:35:19 PM UTC-7, Ron Aaron wrote:
> On 07/19/2012 02:25 AM, hughag...@yahoo.com wrote:
>
> > The majority of the programmers in the world believe that Forth Inc. *is* Forth.
> On 07/19/2012 02:25 AM, hughag...@yahoo.com wrote:
>
>
> In my experience, the majority of programmers are not even aware there
> is a language called "Forth", let alone a company called "Forth Inc"
> In my experience, the majority of programmers are not even aware there
and boy are they missing out
:)
majority of the wingnuts using crapola lie ruby rails and are happy with it
lolz
visua...@rocketmail.com
Jul 25, 2012, 8:10:06 PM7/25/12
to
> > "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.
> Well, getting back to the original topic, I stand by my original
> assertion. The secret to a successful progamming language is simply:
>
> * Users
> * Inertia
>
>
> 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
> 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.
>
> 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
> was out. Java was in. The King is dead. Long live the King. 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
> 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
> 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.
>
> 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
>
>
> What it has *absolutely nothing* to do with is:
>
> * The quality of the language!
>
> YMMV :-)
I made this kind of observation decades ago in Germany: at their first job engineers like to have the same equipment which they had at the university.
> What it has *absolutely nothing* to do with is:
>
> * The quality of the language!
>
> YMMV :-)
That's why I started the "Forth for Education" Initiative, short 4E4th, to get Forth promoted at an even lower levels, at schools. For now this Initiative started in Europe, see http://www.4e4th.eu/
DB.
Hugh Aguilar
Jul 26, 2012, 1:44:39 AM7/26/12
to
> DB.
Are you Dirk Bruehl?
Mark Wills
Jul 26, 2012, 4:46:14 AM7/26/12
to
point. It hadn't occurred to me. To be honest, it was all before my
time. I mean, we're talking circa 1970, right? I was *born* in
1970 ;-)
Thanks for the contribution.
Mark
Doug Hoffman
Jul 26, 2012, 5:24:06 AM7/26/12
to
Mark Wills wrote:
> 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.
There was a window of time at the universities, probably 1972 thru 198x,
> 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.
where RPN was made very popular via the Hewlett-Packard pocket
calculators. Even mechanical engineering students (which includes me)
at the time were taught to use (unstructured) Fortran. We knew we
didn't like Fortran. We knew we liked Forth. That is how I got started
with Forth. But it took a savvy CS engineer friend to make me aware
that Forth even existed.
I suspect that today, given the wide availability of personal computers,
that HP calculators don't get used much. I could be wrong about that.
My sons, both mechatronic engineers, used/use HP calculators but they
were influenced by me.
-Doug
Doug Hoffman
Jul 26, 2012, 5:26:30 AM7/26/12
to
correction:
> We knew we didn't like Fortran. We knew we liked *RPN*.
-Doug
> We knew we didn't like Fortran. We knew we liked *RPN*.
-Doug
Hugh Aguilar
Jul 27, 2012, 1:26:10 AM7/27/12
to
calculators didn't have parenthesis in those days --- either way it
was a PITA to "key" a formula on a calculator (although it was still a
step up from slide-rules).
I don't think it really matters whether a calculator or computer uses
RPN or uses infix with parenthesis --- what people care about is that
the calculator or computer uses the same notation that the textbooks
use --- if textbooks used RPN rather than infix with parenthesis, then
RPN would be popular.
Forth doesn't use RPN because it is particularly readable --- Forth
uses RPN because it simplifies the parsing, which makes it possible
for the application programmer to write defining words in Forth, which
isn't possible in Fortran, C, etc..
Hugh Aguilar
Jul 27, 2012, 1:48:34 AM7/27/12
to
popular in the olden days and Unix used C, but this didn't at all
imply that C was going to make the jump into personal computers and/or
micro-controllers.
In the early 1980s when 8-bit personal computers (the 65c02
Commodore-64 and the Z80 CP/M business machines) were used, Forth was
a better candidate than C because it was small enough to work on those
extremely memory-limited machines, which C wasn't. At that time, Forth
had inertia and users! It was lack of leadership that caused Forth to
lose out to C when we upgraded from 8-bit to 16-bit computers (8088
and 68000) and the memory limitations were relaxed.
It is remarkable to me that Unix made the jump to personal computers
(as Linux). When Linux first came out, Ray Duncan (of UR/Forth fame)
said that Unix/Linux was a terrible choice for personal computers
because it is designed for workstations with multiple terminals and it
lacks the interactive aspect that personal computers are all about.
Good point!
I read a book: "You are not a gadget" (Jaron Lanier). He is
unimpressed with computer people. He points out that the two big
applications today are Wikipedia and Linux --- but both encyclopedias
and Unix are 1970s technology --- he sees a lack of innovation here,
in that we are using our high-tech computers to emulate what was
commonplace 40 years ago. Good point!
P.S. I boycott Wikipedia. I do my own research.
Doug Hoffman
Jul 27, 2012, 1:52:13 PM7/27/12
to
On 7/27/12 1:26 AM, Hugh Aguilar wrote:
> On Jul 26, 2:26 am, Doug Hoffman <glide...@gmail.com> wrote:
>> corrected:
> On Jul 26, 2:26 am, Doug Hoffman <glide...@gmail.com> wrote:
>>
>> There was a window of time at the universities, probably
>> 1972 thru 198x, where RPN was made very popular via the
>> Hewlett-Packard pocket calculators. Even mechanical engineering
>> students (which includes me) at the time were taught to use
>> (unstructured) Fortran. We knew we didn't like Fortran.
>> There was a window of time at the universities, probably
>> 1972 thru 198x, where RPN was made very popular via the
>> Hewlett-Packard pocket calculators. Even mechanical engineering
>> students (which includes me) at the time were taught to use
>> We knew we liked RPN *on our pocket calculators*.
>>
>>
>
> Actually, nobody really liked RPN --- it is just that the infix
> calculators didn't have parenthesis in those days --- either way it
> was a PITA to "key" a formula on a calculator (although it was still a
> step up from slide-rules).
I liked RPN on a pocket calculator, back then and even today. Though
>>
>
> Actually, nobody really liked RPN --- it is just that the infix
> calculators didn't have parenthesis in those days --- either way it
> was a PITA to "key" a formula on a calculator (although it was still a
> step up from slide-rules).
today one is probably not far (seconds) from a personal computer and
using something like Excel to do calculations makes so much more sense.
Typos are easily detected and corrected: not so on a pocket
calculator, and more.
> I don't think it really matters whether a calculator or computer uses
> RPN or uses infix with parenthesis --- what people care about is that
> the calculator or computer uses the same notation that the textbooks
> use --- if textbooks used RPN rather than infix with parenthesis, then
> RPN would be popular.
a time where most engineers at universities were very familiar with RPN
due to their HP calculators. Getting those same students to try Forth
*at that time* might have attracted quite a few. That's how I got
started with Forth. I already knew RPN. Today that situation has
changed. Does anyone still use pocket calculators at the universities?
Don't know.
-Doug
Bernd Paysan
Jul 27, 2012, 5:44:19 PM7/27/12
to
Hugh Aguilar wrote:
> I read a book: "You are not a gadget" (Jaron Lanier). He is
> unimpressed with computer people. He points out that the two big
> applications today are Wikipedia and Linux --- but both encyclopedias
> and Unix are 1970s technology --- he sees a lack of innovation here,
> in that we are using our high-tech computers to emulate what was
> commonplace 40 years ago. Good point!
Hm, I think the problem is something else here: Linux and Wikipedia are
> I read a book: "You are not a gadget" (Jaron Lanier). He is
> unimpressed with computer people. He points out that the two big
> applications today are Wikipedia and Linux --- but both encyclopedias
> and Unix are 1970s technology --- he sees a lack of innovation here,
> in that we are using our high-tech computers to emulate what was
> commonplace 40 years ago. Good point!
*populare*, because they are old hat. We have this thing with users and
inertia, and what it does is to conserve structures and methods. People
have used Unix for 40 years now, they continue to do so. And they have
used encylopedias for much longer. The technology of Wikipedia is a
Wiki, and that is 1990s technology, the most well-known Wikipedia-like
technology mentioned in the late 1970s was the Hitch Hiker's Guide to
the Galaxy.
Jaron Lanier is also completely wrong: The by far most popular open
source applications are the LAMP environment (Linux, Apache, MySql,
PHP), plus the browsers, which base on three open source projects:
Mosaic (Internet Explorer 1.0 was Mosaic with Microsoft logo - they
figured out that they were allowed to change the code and keep it closed
source), Mozilla (the re-write of Mosaic at Netscape, which was latter
rewritten again to become Gecko), and Webkit (of KHTML origin). This is
what most people use most of the time when they use a computer.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
Hugh Aguilar
Jul 27, 2012, 6:25:04 PM7/27/12
to
On Jul 27, 2:44 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Hugh Aguilar wrote:
> > I read a book: "You are not a gadget" (Jaron Lanier). He is
> > unimpressed with computer people. He points out that the two big
> > applications today are Wikipedia and Linux --- but both encyclopedias
> > and Unix are 1970s technology --- he sees a lack of innovation here,
> > in that we are using our high-tech computers to emulate what was
> > commonplace 40 years ago. Good point!
>
> Hm, I think the problem is something else here: Linux and Wikipedia are
> *populare*, because they are old hat. We have this thing with users and
> inertia, and what it does is to conserve structures and methods. People
> have used Unix for 40 years now, they continue to do so. And they have
> used encylopedias for much longer. The technology of Wikipedia is a
> Wiki, and that is 1990s technology, the most well-known Wikipedia-like
> technology mentioned in the late 1970s was the Hitch Hiker's Guide to
> the Galaxy.
The difference between encyclopedias in the old days, and Wikipedia,
> Hugh Aguilar wrote:
> > I read a book: "You are not a gadget" (Jaron Lanier). He is
> > unimpressed with computer people. He points out that the two big
> > applications today are Wikipedia and Linux --- but both encyclopedias
> > and Unix are 1970s technology --- he sees a lack of innovation here,
> > in that we are using our high-tech computers to emulate what was
> > commonplace 40 years ago. Good point!
>
> Hm, I think the problem is something else here: Linux and Wikipedia are
> *populare*, because they are old hat. We have this thing with users and
> inertia, and what it does is to conserve structures and methods. People
> have used Unix for 40 years now, they continue to do so. And they have
> used encylopedias for much longer. The technology of Wikipedia is a
> Wiki, and that is 1990s technology, the most well-known Wikipedia-like
> technology mentioned in the late 1970s was the Hitch Hiker's Guide to
> the Galaxy.
is that in the old days the writers were expected to have at least a
modicum of expertise on the subject that they were writing about. Now
any idiot can edit a Wikipedia page, and most do. Wikipedia is
promoting a troll culture in which everybody gets to be an instant
expert on every subject, so long as they can get their fellow trolls
who are equally ignorant to back them up. It reminds me of the "Last
Man" that we were warned about in "Thus Spoke Zarathustra," who makes
small of everything and believes in nothing, except the wisdom of the
crowd. We have gone downhill since the 1970s, and I predict that this
trend will continue.
It has been said that if you put a million monkeys to work tapping on
a million keyboards, they would eventually produce something
meaningful. Now, thanks to the internet, we know that this isn't true.
> Jaron Lanier is also completely wrong: The by far most popular open
> source applications are the LAMP environment (Linux, Apache, MySql,
> PHP), plus the browsers, which base on three open source projects:
LAMP etc. is a tool. Lanier was talking about applications.
Bernd Paysan
Jul 27, 2012, 6:44:36 PM7/27/12
to
Hugh Aguilar wrote:
> It has been said that if you put a million monkeys to work tapping on
> a million keyboards, they would eventually produce something
> meaningful. Now, thanks to the internet, we know that this isn't true.
We are all monkeys. It shows far too often, that's correct.
> It has been said that if you put a million monkeys to work tapping on
> a million keyboards, they would eventually produce something
> meaningful. Now, thanks to the internet, we know that this isn't true.
Still, when comparing Wikipedia to other encyclopedias, it shows that
paid authors and editors produce about the same level of crap.
> LAMP etc. is a tool. Lanier was talking about applications.
same. Facebook is the most popular application on top of that
framework, and yes, it's closed source. The second-most popular
application on top of that framework is the other one Lanier mentioned:
Wikipedia.
Hugh Aguilar
Jul 27, 2012, 6:52:15 PM7/27/12
to
On Jul 27, 10:52 am, Doug Hoffman <glide...@gmail.com> wrote:
> Today that situation has
> changed. Does anyone still use pocket calculators at the universities?
> Don't know.
The universities are most likely the only place that calculators are
> Today that situation has
> changed. Does anyone still use pocket calculators at the universities?
> Don't know.
still used. You can't carry a laptop into class, especially not for a
test --- you have to use a calculator --- you may also be required to
use a simple calculator that doesn't allow formulas to be saved in
memory.
In the real world, not too many people use calculators, but everybody
uses a computer. The HP12C may still get some use for financial
calculations, but that would only be when the person is away from his
desk for some reason. BTW, the primary use of the log-log slide-rules
was calculating compound interest, which otherwise involved look-up
tables on paper --- engineering problems generally required more
precision than the slide-rule provided.
I have worked as a CNC machinist. That is one field in which
calculators are still commonly used. Most of the time you are just
evaluating a trig function, but all of your design work is being done
on pencil and paper and mostly involves sketching rather than
calculation. A computer would be too slow for such simple
calculations. A slide-rule would also work fine as the trig functions
are just a direct look-up. Also, with the help of gauge marks, some
calculations can be done more quickly than with a calculator. I've
never seen anybody use a slide-rule at work though --- if you did, you
would need to *never* make a mistake, as your weird method would be
blamed and the mistake would not be forgiven.
Marc Olschok
Jul 28, 2012, 2:15:23 PM7/28/12
to
>[...]
difference that AT&T did not just license C but Unix. It was the
operating system that mattered to the user in the universities.
I still remember the time when I was in the first year of university and
they gladly replaced BS 2000 with Unix. Nobody cared about C as a language,
it simply gained usage because it was the preferred implementation
language under Unix.
On the Forth side I did not notice anything comparable.
--
Marc
> > 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.
>
> This worked because AT&T was a well-known and respected entity
> (especially Bell Labs, which developed it). FORTH, Inc. was trying to
> publicize Forth at the same time. It was more difficult, because we had
> zero name-recognition and inadequate capitalization to do the kind of
> promotion they were able to (in this case, papers at conferences,
> journal articles, etc., all of which costs money and is easier to do if
> you are from a well-known organization).
>
> We also provided free or low-cost Forths to universities, and had
> several dedicated users, but although they told us Forth gave them a
> technical advantage they were dissed in academic conferences because
> Forth was perceived as a "hobby" language. So they adopted a policy of
> not mentioning the language they used :-((
We had this discussion before, but I still think it was an important
> > 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.
>
> This worked because AT&T was a well-known and respected entity
> (especially Bell Labs, which developed it). FORTH, Inc. was trying to
> publicize Forth at the same time. It was more difficult, because we had
> zero name-recognition and inadequate capitalization to do the kind of
> promotion they were able to (in this case, papers at conferences,
> journal articles, etc., all of which costs money and is easier to do if
> you are from a well-known organization).
>
> We also provided free or low-cost Forths to universities, and had
> several dedicated users, but although they told us Forth gave them a
> technical advantage they were dissed in academic conferences because
> Forth was perceived as a "hobby" language. So they adopted a policy of
> not mentioning the language they used :-((
difference that AT&T did not just license C but Unix. It was the
operating system that mattered to the user in the universities.
I still remember the time when I was in the first year of university and
they gladly replaced BS 2000 with Unix. Nobody cared about C as a language,
it simply gained usage because it was the preferred implementation
language under Unix.
On the Forth side I did not notice anything comparable.
--
Marc
Elizabeth D. Rather
Jul 28, 2012, 2:35:04 PM7/28/12
to
capabilities were certainly included. But it was not designed as a
general-purpose OS in the sense that Unix was (i.e., run any programs
written in any language). It was intended to support a cluster of apps
pertaining to a particular project or application domain, and assumed
that all were written in Forth.
As an OS, it was vastly faster than Unix, but obviously not a direct
competitor.
Paul Rubin
Jul 29, 2012, 12:59:01 AM7/29/12
to
"Elizabeth D. Rather" <era...@forth.com> writes:
> Forth was (and sometimes still is) its own OS, and all the OS
> capabilities were certainly included. But it was not designed as a
> general-purpose OS in the sense that Unix was (i.e., run any programs
> written in any language).
Until the 1990's or so, C was the main viable language to write anything
> Forth was (and sometimes still is) its own OS, and all the OS
> capabilities were certainly included. But it was not designed as a
> general-purpose OS in the sense that Unix was (i.e., run any programs
> written in any language).
substantial in under Unix (languages like awk or perl were used for
small scripts). I'd say Unix was much better set up than a Forth OS to
handle multiple programs running independently of each other
(i.e. preemptive multitasking with protected processes in separate
address spaces). That was at least as big a difference as Forth vs. C.
visplo...@gmail.com
Jul 29, 2012, 12:56:17 AM7/29/12
to
On Wednesday, July 18, 2012 6:13:06 AM UTC-7, Bernd Paysan wrote:
> Bluebee wrote:
>
> > 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.
>
>
>
> This is why we appointed Peter Knaggs to be the standard editor.
and fast and modifiable
forth seems to work
can it replace bsd and linux and ruby rails and dajngo and php?
hmm not sure yet
> Bluebee wrote:
>
> > 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.
>
>
>
> 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/
good book = successful lang
>
>
> --
>
> Bernd Paysan
>
> "If you want it done right, you have to do it yourself"
>
> http://bernd-paysan.de/
and fast and modifiable
forth seems to work
can it replace bsd and linux and ruby rails and dajngo and php?
hmm not sure yet
Sp...@controlq.com
Jul 30, 2012, 11:53:40 AM7/30/12
to
On Sat, 28 Jul 2012, Paul Rubin wrote:
> Date: Sat, 28 Jul 2012 21:59:01 -0700
> From: Paul Rubin <no.e...@nospam.invalid>
It turns out that following unix, or rather, developed apace, were the
troff system, and many small utilities which made the OS useful. The
philosophy of small utilities piping their output from one to the other to
achieve an end allowed almost immediate utility ... and the AT&T guys
wrote what they needed ... intially, the text processing system.
We don't run OS's in a vacuum. If there are no useful applications, then
there is no use for the OS, and in the case of Unix, some very bright
minds simply wanted some tools which fueled a wider need. The man page
utility still uses the rudimentary runoff text processing system for which
Unix was designed (IIRC).
Rob.
> Date: Sat, 28 Jul 2012 21:59:01 -0700
> From: Paul Rubin <no.e...@nospam.invalid>
> Newsgroups: comp.lang.forth
> Subject: Re: The Secret of a Successful Programming Language?
>
> Subject: Re: The Secret of a Successful Programming Language?
>
troff system, and many small utilities which made the OS useful. The
philosophy of small utilities piping their output from one to the other to
achieve an end allowed almost immediate utility ... and the AT&T guys
wrote what they needed ... intially, the text processing system.
We don't run OS's in a vacuum. If there are no useful applications, then
there is no use for the OS, and in the case of Unix, some very bright
minds simply wanted some tools which fueled a wider need. The man page
utility still uses the rudimentary runoff text processing system for which
Unix was designed (IIRC).
Rob.
Hugh Aguilar
Jul 30, 2012, 11:38:46 PM7/30/12
to
On Jul 30, 8:53 am, S...@ControlQ.com wrote:
> On Sat, 28 Jul 2012, Paul Rubin wrote:
> > Date: Sat, 28 Jul 2012 21:59:01 -0700
> > From: Paul Rubin <no.em...@nospam.invalid>
> On Sat, 28 Jul 2012, Paul Rubin wrote:
> > Date: Sat, 28 Jul 2012 21:59:01 -0700
> > Newsgroups: comp.lang.forth
> > Subject: Re: The Secret of a Successful Programming Language?
>
> > Subject: Re: The Secret of a Successful Programming Language?
>
> > "Elizabeth D. Rather" <erat...@forth.com> writes:
> >> Forth was (and sometimes still is) its own OS, and all the OS
> >> capabilities were certainly included. But it was not designed as a
> >> general-purpose OS in the sense that Unix was (i.e., run any programs
> >> written in any language).
>
> > Until the 1990's or so, C was the main viable language to write anything
> > substantial in under Unix (languages like awk or perl were used for
> > small scripts). I'd say Unix was much better set up than a Forth OS to
> > handle multiple programs running independently of each other
> > (i.e. preemptive multitasking with protected processes in separate
> > address spaces). That was at least as big a difference as Forth vs. C.
>
> It turns out that following unix, or rather, developed apace, were the
> troff system, and many small utilities which made the OS useful. The
> philosophy of small utilities piping their output from one to the other to
> achieve an end allowed almost immediate utility ... and the AT&T guys
> wrote what they needed ... intially, the text processing system.
>
> We don't run OS's in a vacuum. If there are no useful applications, then
> there is no use for the OS, and in the case of Unix, some very bright
> minds simply wanted some tools which fueled a wider need. The man page
> utility still uses the rudimentary runoff text processing system for which
> Unix was designed (IIRC).
>
> Rob.
It is true that, for a long time, Unix was primarily a text-processing
> >> Forth was (and sometimes still is) its own OS, and all the OS
> >> capabilities were certainly included. But it was not designed as a
> >> general-purpose OS in the sense that Unix was (i.e., run any programs
> >> written in any language).
>
> > Until the 1990's or so, C was the main viable language to write anything
> > substantial in under Unix (languages like awk or perl were used for
> > small scripts). I'd say Unix was much better set up than a Forth OS to
> > handle multiple programs running independently of each other
> > (i.e. preemptive multitasking with protected processes in separate
> > address spaces). That was at least as big a difference as Forth vs. C.
>
> It turns out that following unix, or rather, developed apace, were the
> troff system, and many small utilities which made the OS useful. The
> philosophy of small utilities piping their output from one to the other to
> achieve an end allowed almost immediate utility ... and the AT&T guys
> wrote what they needed ... intially, the text processing system.
>
> We don't run OS's in a vacuum. If there are no useful applications, then
> there is no use for the OS, and in the case of Unix, some very bright
> minds simply wanted some tools which fueled a wider need. The man page
> utility still uses the rudimentary runoff text processing system for which
> Unix was designed (IIRC).
>
> Rob.
platform. Now that we have the internet most information is put into
screen-displayable format and rarely gets printed to paper --- but in
pre-internet days, most information had to go to paper in order for
humans to digest it.
My only use for Linux is to run LaTeX --- there are tools for LaTeX
available under Windows (I paid a $30 shareware fee for WinEdt), but
they really don't compare to what is available under Linux for free.
LaTeX is designed for generating technical books. Books are obsolete
now though --- most people (Gavino!) have a 2-minute attention span,
and they aren't going to read any book. First we had the Macintosh
with its "desktop publishing" that was primarily used to generate 1 or
2 page sales brochures. The Mac also popularized the GUI "desktop"
that is full of icons that we point-and-click on, very much like how
10,000 years ago we drew pictures on cave walls and would then point-
and-grunt to communicate what we wanted to do. With the advent of the
internet we got essentially the same thing as desktop-publishing
except on-line.
Now Twitter has nailed the coffin shut. The next step down will be
screeching and grinning like we did 100,000 years ago (or chimpanzees
still do) --- just like a "tweet" except with 140 fewer characters.
Brad Eckert
Sep 21, 2012, 4:47:23 PM9/21/12
to
On Wednesday, July 18, 2012 4:25:11 PM UTC-7, (unknown) wrote:
>... locals on the return stack, which is not possible if it is
>also going to support >R R@ R> etc., which it does.
If it's not possible, why do so many Forths do it?
> 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.
Does anyone want to Photoshop Elizabeth with a RMS beard?
>... locals on the return stack, which is not possible if it is
>also going to support >R R@ R> etc., which it does.
If it's not possible, why do so many Forths do it?
> 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.
Does anyone want to Photoshop Elizabeth with a RMS beard?
Hugh Aguilar
Sep 21, 2012, 10:37:06 PM9/21/12
to
On Sep 21, 1:47 pm, Brad Eckert <hwfw...@gmail.com> wrote:
> On Wednesday, July 18, 2012 4:25:11 PM UTC-7, (unknown) wrote:
> >... locals on the return stack, which is not possible if it is
> >also going to support >R R@ R> etc., which it does.
>
> If it's not possible, why do so many Forths do it?
Forths that have locals and have >R R@ R> etc. typically give the
> On Wednesday, July 18, 2012 4:25:11 PM UTC-7, (unknown) wrote:
> >... locals on the return stack, which is not possible if it is
> >also going to support >R R@ R> etc., which it does.
>
> If it's not possible, why do so many Forths do it?
locals their own stack. If the locals are on the return-stack, then
you have to know at compile-time how many >R will be done at run-time
so that you know how to adjust the offsets of the locals from the
return-stack pointer. This isn't possible because the >R may be inside
of a loop and the number of iterations that the loop executes (and
hence the number of >R that get executed) depends upon parameters
given to the function at run-time.
It is common to have >R inside of a loop when you have variable
numbers of parameters (usually a lot of non-zero data with a zero
sentinal underneath). This is sometimes also done with strings where
all of the chars in the string get pushed onto the return-stack. If
you don't understand how >R can be inside of a loop, I have examples
in my novice package:
http://www.forth.org/novice.html
BTW, I won't support DO loops or >R etc. in Straight Forth. They
aren't compatible with each other either! ANS-Forth is full of these
weird incompatibilities. The programmer has to remember not to use >R
and DO loops together, he has to remember not to use >R and locals
together --- you know, there is a reason why most Forth novices give
up on the language because it is too difficult for them to learn ---
the ANS-Forth standard is just a mish-mash of conflicting ideas that
clash with each other.
Brad Eckert
Oct 3, 2012, 12:34:53 PM10/3/12
to
On Friday, September 21, 2012 7:37:07 PM UTC-7, Hugh Aguilar wrote:
>
> BTW, I won't support DO loops or >R etc. in Straight Forth. They
> aren't compatible with each other either! ANS-Forth is full of these
> weird incompatibilities. The programmer has to remember not to use >R
> and DO loops together, he has to remember not to use >R and locals
> together --- you know, there is a reason why most Forth novices give
> up on the language because it is too difficult for them to learn ---
> the ANS-Forth standard is just a mish-mash of conflicting ideas that
> clash with each other.
Yes, ANS is 1990s Forth encased in amber. Maybe you can do better. You should write a specification first and present it to c.l.f for review.
>
> BTW, I won't support DO loops or >R etc. in Straight Forth. They
> aren't compatible with each other either! ANS-Forth is full of these
> weird incompatibilities. The programmer has to remember not to use >R
> and DO loops together, he has to remember not to use >R and locals
> together --- you know, there is a reason why most Forth novices give
> up on the language because it is too difficult for them to learn ---
> the ANS-Forth standard is just a mish-mash of conflicting ideas that
> clash with each other.
John Passaniti
Oct 6, 2012, 12:24:20 PM10/6/12
to
On Wednesday, October 3, 2012 12:34:54 PM UTC-4, Brad Eckert wrote:
> Yes, ANS is 1990s Forth encased in amber. Maybe
> you can do better. You should write a specification
> first and present it to c.l.f for review.
That specification has been in comp.lang.forth for months now, distributed over many messages. To understand his Straight Forth, you only have to understand one thing:
> Yes, ANS is 1990s Forth encased in amber. Maybe
> you can do better. You should write a specification
> first and present it to c.l.f for review.
All of ANS Forth beyond the simplest primitives is wrong and he will do it better in Straight Forth. You don't know /how/ he will do it better, but details like that don't matter. The mere fact that Hugh's massive throbbing intellect says he will do better is all you need to know. For now, just assume ANS Forth is wrong, download his "novice" package (because that's what you are), and see how Forth is supposed to be done by a master. Asking the question "What Would Hugh Do" is the first step towards accelerating your career and coming to a deeper understanding of Forth.
0 new messages