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

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

Really?

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

Contents

  Really? Mark Wills <markwills1970@gmail.com> - 2017-02-06 06:46 -0800
    Re: Really? foxaudioresearch@gmail.com - 2017-02-06 07:20 -0800
    Re: Really? polymorph self <jackvanc3@gmail.com> - 2017-02-06 08:58 -0800
    Re: Really? rickman <gnuarm@gmail.com> - 2017-02-06 13:06 -0500
    Re: Really? hughaguilar96@gmail.com - 2017-02-06 11:25 -0800
    Re: Really? "HAA" <someone@microsoft.com> - 2017-02-07 11:45 +1100
    Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-06 15:38 -1000
      Re: Really? hughaguilar96@gmail.com - 2017-02-07 09:50 -0800
    Re: Really? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-06 23:39 -0500
      Re: Really? Mark Wills <markwills1970@gmail.com> - 2017-02-07 08:04 -0800
      Re: Really? "HAA" <someone@microsoft.com> - 2017-02-08 11:04 +1100
        Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 23:42 -0800
          Re: Really? "HAA" <someone@microsoft.com> - 2017-02-08 20:12 +1100
            Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-08 02:44 -0800
            Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-08 17:48 +0000
              Re: Really? Alex <alex@rivadpm.com> - 2017-02-08 18:43 +0000
                Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-08 15:24 -0800
              Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-08 16:26 -0800
      Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 22:45 -0800
        Re: Really? hughaguilar96@gmail.com - 2017-02-07 22:50 -0800
      Re: Really? clozaga@gmail.com - 2017-02-08 21:03 -0800
        Re: Really? clozaga@gmail.com - 2017-02-08 21:04 -0800
        Re: Really? hughaguilar96@gmail.com - 2017-02-11 20:01 -0800
          Re: Really? Alex <alex@rivadpm.com> - 2017-02-12 16:26 +0000
            Re: Really? hughaguilar96@gmail.com - 2017-02-12 16:52 -0800
              Re: Really? Alex <alex@rivadpm.com> - 2017-02-13 09:49 +0000
                Re: Really? minforth@arcor.de - 2017-02-13 07:03 -0800
                Re: Really? hughaguilar96@gmail.com - 2017-02-13 13:41 -0800
                  Re: Really? Alex <alex@rivadpm.com> - 2017-02-13 22:32 +0000
                    Re: Really? hughaguilar96@gmail.com - 2017-02-15 11:42 -0800
                      Re: Really? Alex <alex@rivadpm.com> - 2017-02-15 20:41 +0000
                        Re: Really? hughaguilar96@gmail.com - 2017-02-17 09:42 -0800
                          Re: Really? Alex <alex@rivadpm.com> - 2017-02-17 22:22 +0000
            Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-12 19:24 -1000
              Re: Really? Alex <alex@rivadpm.com> - 2017-02-13 08:49 +0000
    Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-07 11:01 +0000
      Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 03:06 -0800
        Re: Really? hughaguilar96@gmail.com - 2017-02-07 09:35 -0800
        Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-07 17:35 +0000
          Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 23:24 -0800
            Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-09 08:57 +0000
              Re: Really? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-09 13:24 +0100
                Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-11 15:32 +0000
        Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-07 20:42 +0000
          Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-07 13:58 -1000
            Re: Really? hughaguilar96@gmail.com - 2017-02-07 21:51 -0800
              Re: Really? rickman <gnuarm@gmail.com> - 2017-02-08 01:47 -0500
                Re: Really? hughaguilar96@gmail.com - 2017-02-07 22:52 -0800
                  Re: Really? rickman <gnuarm@gmail.com> - 2017-02-08 03:34 -0500
                    Re: Really? Alex <alex@rivadpm.com> - 2017-02-08 13:43 +0000
                      Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-08 15:39 -1000
                        Re: Really? hughaguilar96@gmail.com - 2017-02-08 22:39 -0800
                          Re: Really? Alex <alex@rivadpm.com> - 2017-02-09 08:56 +0000
                            Re: Really? hughaguilar96@gmail.com - 2017-02-09 14:36 -0800
                              Re: Really? Alex <alex@rivadpm.com> - 2017-02-10 08:33 +0000
                        Re: Really? Alex <alex@rivadpm.com> - 2017-02-09 09:03 +0000
                          Re: Really? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-09 10:51 +0100
                            Re: Really? john <anon@example.com> - 2017-02-09 11:54 +0000
                              Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-09 09:30 -1000
                            Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-09 14:14 +0000
                              Re: Really? Alex <alex@rivadpm.com> - 2017-02-09 14:37 +0000
                                Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-09 15:24 +0000
                                  Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-09 12:01 -0800
                                    Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-10 01:09 +0000
                                      Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-09 18:19 -0800
                                        Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-09 16:30 -1000
                                      Re: Really? hughaguilar96@gmail.com - 2017-02-09 19:16 -0800
                                        Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-10 16:29 +0000
                                          OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 17:30 +0000
                                            Re: OT: [ was re: Really?] Foreign aid Cecil Bayona <cbayona@cbayona.com> - 2017-02-10 11:46 -0600
                                              Re: OT: [ was re: Really?] Foreign aid Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-02-10 11:54 -0600
                                                Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 18:05 +0000
                                              Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 17:55 +0000
                                                Re: OT: [ was re: Really?] Foreign aid Cecil Bayona <cbayona@cbayona.com> - 2017-02-10 12:04 -0600
                                                  Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 18:07 +0000
                                                    Re: OT: [ was re: Really?] Foreign aid Cecil Bayona <cbayona@cbayona.com> - 2017-02-10 12:57 -0600
                                                      Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 19:26 +0000
                                                        Re: OT: [ was re: Really?] Foreign aid Cecil Bayona <cbayona@cbayona.com> - 2017-02-10 14:04 -0600
                                                          Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-11 09:35 +0000
                                          Re: Really? hughaguilar96@gmail.com - 2017-02-10 16:33 -0800
                                      Static type checking (was: Really?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-10 11:07 +0000
                                Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-11 15:16 +0000
                                  Re: Really? Cecil Bayona <cbayona@cbayona.com> - 2017-02-11 10:20 -0600
                                  Re: Really? hughaguilar96@gmail.com - 2017-02-11 19:02 -0800
                              Re: Really? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-10 17:31 +0100
                    Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-08 15:34 -1000
                Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-07 21:15 -1000
                Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 23:46 -0800
          Re: Really? hughaguilar96@gmail.com - 2017-02-07 22:47 -0800
            Re: Really? Ron Aaron <rambamist@gmail.com> - 2017-02-08 08:52 +0200
      Re: Really? rickman <gnuarm@gmail.com> - 2017-02-07 06:29 -0500
        Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-07 20:47 +0000
          Re: Really? rickman <gnuarm@gmail.com> - 2017-02-07 16:23 -0500
            Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-08 09:47 +0000
              Re: Really? rickman <gnuarm@gmail.com> - 2017-02-08 05:13 -0500
                Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-08 11:23 +0000
      Re: Really? Cecil Bayona <cbayona@cbayona.com> - 2017-02-07 09:49 -0600
    Really? Mark Wills <markwills1970@gmail.com> - 2017-02-09 00:30 -0800
      Re: Really? "HAA" <someone@microsoft.com> - 2017-02-10 10:32 +1100
        Re: Really? hughaguilar96@gmail.com - 2017-02-09 17:22 -0800

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

#54673 — Really?

"As for Forth, although it has dedicated advocates, it's 
explicit stack orientation and its lack of modularity limit
the scale of Forth programs. One of the largest Forth efforts
was an integrated operating system called Valdocs (Valuable 
Document System) on the Epson QX-10. The software remained buggy
couldn't be updated quickly enough for the machine to remain 
competitive - although you could just as easilly blame the 
computer's Z-80 processor (since at the time the 8088 based IBM PC
and 68000 based Apple Macintosh were being introduced) and difficulty
in finding experienced Forth programmers. Whatever the cause, this 
soured the acceptance of Forth for large scale projects."

http://www.cpushack.com/CPU/cpuAppendB.html#Forth

[toc] | [next] | [standalone]

#54674

On Monday, February 6, 2017 at 9:46:02 AM UTC-5, Mark Wills wrote:
> "As for Forth, although it has dedicated advocates, it's 
> explicit stack orientation and its lack of modularity limit
> the scale of Forth programs. One of the largest Forth efforts
> was an integrated operating system called Valdocs (Valuable 
> Document System) on the Epson QX-10. The software remained buggy
> couldn't be updated quickly enough for the machine to remain 
> competitive - although you could just as easilly blame the 
> computer's Z-80 processor (since at the time the 8088 based IBM PC
> and 68000 based Apple Macintosh were being introduced) and difficulty
> in finding experienced Forth programmers. Whatever the cause, this 
> soured the acceptance of Forth for large scale projects."
> 
> http://www.cpushack.com/CPU/cpuAppendB.html#Forth

I have no first hand knowledge, but I dimly remember writings that indicated the
 Valdocs project bit off way more that it could chew.  It was an attempt to
create a pretty big OS type thing with code page swapping I think.
Using ITC on a Z80 meant is was woefully underpowered. The Z80 kind of sucked as
a Forth machine anyway.

From a PR perspective it was definitely a bad hit for Forth.

BF

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

#54675

On Monday, February 6, 2017 at 9:46:02 AM UTC-5, Mark Wills wrote:
> "As for Forth, although it has dedicated advocates, it's 
> explicit stack orientation and its lack of modularity limit
> the scale of Forth programs. One of the largest Forth efforts
> was an integrated operating system called Valdocs (Valuable 
> Document System) on the Epson QX-10. The software remained buggy
> couldn't be updated quickly enough for the machine to remain 
> competitive - although you could just as easilly blame the 
> computer's Z-80 processor (since at the time the 8088 based IBM PC
> and 68000 based Apple Macintosh were being introduced) and difficulty
> in finding experienced Forth programmers. Whatever the cause, this 
> soured the acceptance of Forth for large scale projects."
> 
> http://www.cpushack.com/CPU/cpuAppendB.html#Forth

I wish there was a forth powered desktop pc now.

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

#54676

On 2/6/2017 9:46 AM, Mark Wills wrote:
> "As for Forth, although it has dedicated advocates, it's
> explicit stack orientation and its lack of modularity limit
> the scale of Forth programs. One of the largest Forth efforts
> was an integrated operating system called Valdocs (Valuable
> Document System) on the Epson QX-10. The software remained buggy
> couldn't be updated quickly enough for the machine to remain
> competitive - although you could just as easilly blame the
> computer's Z-80 processor (since at the time the 8088 based IBM PC
> and 68000 based Apple Macintosh were being introduced) and difficulty
> in finding experienced Forth programmers. Whatever the cause, this
> soured the acceptance of Forth for large scale projects."
>
> http://www.cpushack.com/CPU/cpuAppendB.html#Forth

This would be classed as an opinion piece.  There is no analysis and no 
references.  It's just the author's opinion.  How the heck is Forth 
limited in modularity?

-- 

Rick C

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

#54677

On Monday, February 6, 2017 at 7:46:02 AM UTC-7, Mark Wills wrote:
> "As for Forth, although it has dedicated advocates, it's 
> explicit stack orientation and its lack of modularity limit
> the scale of Forth programs. One of the largest Forth efforts
> was an integrated operating system called Valdocs (Valuable 
> Document System) on the Epson QX-10. The software remained buggy
> couldn't be updated quickly enough for the machine to remain 
> competitive - although you could just as easilly blame the 
> computer's Z-80 processor (since at the time the 8088 based IBM PC
> and 68000 based Apple Macintosh were being introduced) and difficulty
> in finding experienced Forth programmers. Whatever the cause, this 
> soured the acceptance of Forth for large scale projects."
> 
> http://www.cpushack.com/CPU/cpuAppendB.html#Forth

Well, the "explicit stack orientation" doesn't seem like a problem to me, but we do have local variables now --- it is likely that in those days they lacked local variables and were relying on stack-juggling, >R R@ R> etc., and a lot of global variables --- that can make programs bug-ridden and over-complicated.

The "lack of modularity" continues to be a problem today. We have serious name-space pollution problems in big programs. My solution in MFX (a big program even by today's standards) was LOCAL and END-MODULE --- I had to write this in assembly-language though, but it was easy. LOCAL set a flag in the header of the most recent definition indicating that it was smudge-ready. END-MODULE was used at the end of a file and it traversed the entire dictionary (all vocabularies) and every time it found a smudge-ready definition it set the smudge flag and unset the smudge-ready flag. So, each file was a module and all the definitions marked LOCAL were invisible outside of the file --- everything else was the API --- this not only reduced name-space pollution but also made the source-code more readable (the reader could focus on learning the API words and not bother to learn the LOCAL words because he knew they were for internal use only).

The Z80 was a horrible processor for Forth --- ITC code was very inefficient --- STC was inefficient too if IX or IY were used as the data-stack pointer (typical) because IX and IY addressing was horribly slow. I started writing an eZ80 Forth once but gave up on it because the eZ80 was already rapidly becoming obsolete. I had STC, but I used the return-stack as the data-stack. At the beginning of every colon word I pulled the return-address off the return-stack so it wouldn't be in the way of accessing the data, and I moved it to an IX stack. This was better, but still inefficient.

Anyway, beating us up for an old Z80 Forth project seems unfair now.

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

#54679

Mark Wills wrote:
> "As for Forth, although it has dedicated advocates, it's
> explicit stack orientation and its lack of modularity limit
> the scale of Forth programs. One of the largest Forth efforts
> was an integrated operating system called Valdocs (Valuable
> Document System) on the Epson QX-10. The software remained buggy
> couldn't be updated quickly enough for the machine to remain
> competitive - although you could just as easilly blame the
> computer's Z-80 processor (since at the time the 8088 based IBM PC
> and 68000 based Apple Macintosh were being introduced) and difficulty
> in finding experienced Forth programmers. Whatever the cause, this
> soured the acceptance of Forth for large scale projects."
>
> http://www.cpushack.com/CPU/cpuAppendB.html#Forth

What language hasn't produced failures?  A well-known Forther (name
escapes me) who was involved in the Valdocs project spoke about it
(Forth Dimensions?) and put the failure down to early design decisions.
In short too much money had been spent going down the wrong track
and it was impossible to turn back.

The implication of the first sentence in your quote is that Forth is too
low-level to create large projects.  Vendors may be able to demonstrate
otherwise but even if true, does it matter?  There are so many small to
medium projects where Forth can excel.  IMO where Forth (or more
correctly its fans) has failed is the idea that it should be able to compete
with and outperform every other language.  This speaks more of the
insecurities of Forthers than of any qualities of the language.  They don't
produce anything because they don't want to be seen as failures.  Forth
consequently becomes the language that never was.  You'll hear it talked
about on forums but even that will fade away as those who did anything
with it pass on.

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

#54680

On 2/6/17 4:46 AM, Mark Wills wrote:
> "As for Forth, although it has dedicated advocates, it's
> explicit stack orientation and its lack of modularity limit
> the scale of Forth programs. One of the largest Forth efforts
> was an integrated operating system called Valdocs (Valuable
> Document System) on the Epson QX-10. The software remained buggy
> couldn't be updated quickly enough for the machine to remain
> competitive - although you could just as easilly blame the
> computer's Z-80 processor (since at the time the 8088 based IBM PC
> and 68000 based Apple Macintosh were being introduced) and difficulty
> in finding experienced Forth programmers. Whatever the cause, this
> soured the acceptance of Forth for large scale projects."
>
> http://www.cpushack.com/CPU/cpuAppendB.html#Forth
>

That was an effort in the 80's by a group of amateur Forth enthusiasts, 
living in different areas and using different and incompatible versions 
of Forth. Several later went on to become excellent programmers, but 
this was a very poorly organized effort according to what I have been told.

It's also far from one of the "largest Forth efforts." The largest ones 
I'm aware of, in terms of the number of programmers involved and scope 
of effort, must include the instrumentation of the King Khaled 
International Airport in Riyadh, Saudi Arabia (developed in the 80's, 
but last I heard much of it was still in use) and the "smart card 
terminals" project for Europay (now European MasterCard) in the late 
90's. Both were successful, although the Europay project was later 
dropped following successful demos due to higher-level business decisions.

Cheers,
Elizabeth

-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#54688

On Monday, February 6, 2017 at 6:38:25 PM UTC-7, Elizabeth D. Rather wrote:
> That was an effort in the 80's by a group of amateur Forth enthusiasts, 
> living in different areas and using different and incompatible versions 
> of Forth. Several later went on to become excellent programmers, but 
> this was a very poorly organized effort according to what I have been told.

Why would anybody tell you anything?

You also claim that I was fired from Testra because my MFX was no good, and that the MiniForth project was a failure. You just make this stuff up! Why would anybody at Testra keep you informed regarding the MiniForth project after they rejected your sales pitch for Forth Inc. to write the development software? Normally companies don't have a close relationship with a sales person after they show the sales person to the door.

Most likely the "lack of modularity" problem means that all of the Forth programmers involved with sycophants of Elizabeth Rather and so they consequently hated and feared code-libraries.

Every time that somebody needed an array, they wrote it from scratch. Every time that somebody needed a linked list, they wrote it from scratch. Every time that somebody needed an array, they wrote it from scratch. Every time that somebody needed any kind of data-structure, they wrote it from scratch, and they had to keep it simple because they were under deadline (no self-balancing binary-tree, because that takes time to write, and it is only going to be used once or twice anyway).

Here is a quote from you:

On Wednesday, July 10, 2013 at 4:00:01 PM UTC-7, Elizabeth D Rather wrote: 
> Reusable code is a good thing if and only if it is exactly what you want 
> to do. All this discussion of sort algorithms has been much too 
> generalized, IMO. 
> 
> Every application for sorting has two aspects: the data to be sorted, 
> and the appropriate external harness to supply the data and act on the 
> results. The notion of a completely generic sort with changeable data 
> supply and comparison, accompanied by an argument as to which sort 
> algorithm to use for all occasions ignores the fact that the most 
> important issue is the nature of the data: not only whether it's numeric 
> or strings, but whether it's somewhat ordered, completely random, etc. 
> In every application, you surely have enough information to make an 
> informed decision as to which sort algorithm to use for *this* occasion. 
> 
> An experienced programmer should have several sorts in his/her back 
> pocket, that can be whipped out and tailored to the specific application 
> at hand. That is the only way to get optimal performance. 
> 
> Cheers, 
> Elizabeth 

So, every time that data needed to be sorted, the programmer wrote a sort function from scratch (actually, cut-and-paste-and-tweak from some older unrelated program). In that VALDOCS program, there may have been multiple SORT functions in use for various arrays holding different types of structs.

This might be what "lack of modularity" means --- do you think? --- amateur hour!

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

#54681

On Mon, 6 Feb 2017 06:46:00 -0800 (PST)
Mark Wills <markwills1970@gmail.com> wrote:

> "As for Forth, although it has dedicated advocates, it's 
> explicit stack orientation and its lack of modularity limit
> the scale of Forth programs. One of the largest Forth efforts
> was an integrated operating system called Valdocs (Valuable 
> Document System) on the Epson QX-10. The software remained buggy
> couldn't be updated quickly enough for the machine to remain 
> competitive - although you could just as easilly blame the 
> computer's Z-80 processor (since at the time the 8088 based IBM PC
> and 68000 based Apple Macintosh were being introduced) and difficulty
> in finding experienced Forth programmers. Whatever the cause, this 
> soured the acceptance of Forth for large scale projects."
> 
> [link]

Valdocs was nearly 16MB of FORTH code (according to the IEEE) running on
a 4MHz Z80 with only 256KB of RAM.  Why would you expect it to be a
success? ...

Also, during the early home computing years, other small projects using
Forth were failing, such as Easywriter and Money Maestro.  So, Forth
had developed a bad reputation prior to the Valdocs failure:

https://books.google.com/books?id=nS4EAAAAMBAJ&pg=PA80

That link says the Valdocs' "'compact and efficient' Forth code is more
than 400K in size."  Wouldn't that be a problem on a machine with
256K?  This was before MMU's and memory paging.  At best, the Epson
QX-10 was probably bank switched.  (Yes, Wikipedia confirms that.)

Wikipedia mentions "Forth has been used successfully in large, complex
projects," while not citing any such projects.  From Bolo's Forth
webpage, "There are supposedly a large number of applications and
devices in the real world which use Forth. I say supposedly ..."  Etc.
Apparently, the large, complex and successful Forth projects were all
commercial projects as almost no one can cite what they actually are.
(Of course, Ms. Rather has cited some here, not widely known.)

Another article says, "Forth became less common amongst commercial
application and game developers, even as it retained a dedicated cult
of hobbyists who have persisted with the language to this day."  

That seems to sum up the majority of real world Forth usage as the only
notable projects I can find mentioned anywhere are:

NRAO
OK-CAD
OKAD-II
Open Firmware
OLPC
Valdocs

Charles Moore even admitted that Forth was not suited to applications.
Instead, he saw Forth as a way to create a tool set for the programmer,
rather than as a language for coding applications:

"Writing big programs to be distributed in object code is a distortion
of what Forth is all about. Forth is like a set of craftsman’s tools.
You use it to make still more tools that work with whatever you
specialize in. Then you use it to solve problems. Forth programs should
always be distributed in source code. You should have Forth online at
all times. Recompile whenever you want to use a program. Forth programs
are tailored, they’re living and dynamic, not static object code."
- Charles Moore, Byte magazine, Volume 10, pg 316, 1985


Rod Pemberton

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

#54686

On Tuesday, 7 February 2017 04:38:53 UTC, Rod Pemberton  wrote:
> On Mon, 6 Feb 2017 06:46:00 -0800 (PST)
> Mark Wills <markwills1970@gmail.com> wrote:
> 
> > "As for Forth, although it has dedicated advocates, it's 
> > explicit stack orientation and its lack of modularity limit
> > the scale of Forth programs. One of the largest Forth efforts
> > was an integrated operating system called Valdocs (Valuable 
> > Document System) on the Epson QX-10. The software remained buggy
> > couldn't be updated quickly enough for the machine to remain 
> > competitive - although you could just as easilly blame the 
> > computer's Z-80 processor (since at the time the 8088 based IBM PC
> > and 68000 based Apple Macintosh were being introduced) and difficulty
> > in finding experienced Forth programmers. Whatever the cause, this 
> > soured the acceptance of Forth for large scale projects."
> > 
> > [link]
> 
> Valdocs was nearly 16MB of FORTH code (according to the IEEE) running on
> a 4MHz Z80 with only 256KB of RAM.  Why would you expect it to be a
> success? ...
> 
> Also, during the early home computing years, other small projects using
> Forth were failing, such as Easywriter and Money Maestro.  So, Forth
> had developed a bad reputation prior to the Valdocs failure:
> 
> https://books.google.com/books?id=nS4EAAAAMBAJ&pg=PA80
> 
> That link says the Valdocs' "'compact and efficient' Forth code is more
> than 400K in size."  Wouldn't that be a problem on a machine with
> 256K?  This was before MMU's and memory paging.  At best, the Epson
> QX-10 was probably bank switched.  (Yes, Wikipedia confirms that.)
> 
> Wikipedia mentions "Forth has been used successfully in large, complex
> projects," while not citing any such projects.  From Bolo's Forth
> webpage, "There are supposedly a large number of applications and
> devices in the real world which use Forth. I say supposedly ..."  Etc.
> Apparently, the large, complex and successful Forth projects were all
> commercial projects as almost no one can cite what they actually are.
> (Of course, Ms. Rather has cited some here, not widely known.)
> 
> Another article says, "Forth became less common amongst commercial
> application and game developers, even as it retained a dedicated cult
> of hobbyists who have persisted with the language to this day."  
> 
> That seems to sum up the majority of real world Forth usage as the only
> notable projects I can find mentioned anywhere are:
> 
> NRAO
> OK-CAD
> OKAD-II
> Open Firmware
> OLPC
> Valdocs
> 
> Charles Moore even admitted that Forth was not suited to applications.
> Instead, he saw Forth as a way to create a tool set for the programmer,
> rather than as a language for coding applications:
> 
> "Writing big programs to be distributed in object code is a distortion
> of what Forth is all about. Forth is like a set of craftsman’s tools.
> You use it to make still more tools that work with whatever you
> specialize in. Then you use it to solve problems. Forth programs should
> always be distributed in source code. You should have Forth online at
> all times. Recompile whenever you want to use a program. Forth programs
> are tailored, they’re living and dynamic, not static object code."
> - Charles Moore, Byte magazine, Volume 10, pg 316, 1985
> 
> 
> Rod Pemberton

Plenty of NASA and Military projects, too.

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

#54698

Rod Pemberton wrote:
> ...
> That link says the Valdocs' "'compact and efficient' Forth code is more
> than 400K in size."  Wouldn't that be a problem on a machine with
> 256K?  This was before MMU's and memory paging.  At best, the Epson
> QX-10 was probably bank switched.  (Yes, Wikipedia confirms that.)

Tracked down the previous reference I mentioned.  'Interview with J. D. Hall'
Forth Dimensions 14/5  explains his role with Valdocs and the problems
surrounding the project.  It mentions the QX had several 64K banks and
was running a CP/M compatible OS.

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

#54709

"HAA" <someone@microsoft.com> writes:
> Tracked down the previous reference I mentioned.  'Interview with
> J. D. Hall' Forth Dimensions 14/5 explains his role with Valdocs and
> the problems surrounding the project.  It mentions the QX had several
> 64K banks and was running a CP/M compatible OS.

I can't find this anywhere, particularly in Forth Dimensions 14/5 if
you meant this:  http://www.forth.org/fd/FD-V14N5.pdf

Do you have another reference?

I did find a review of the QX10 and Valdocs saying it was nice once they
got the bugs out:

http://www.atariarchives.org/deli/test-driving_the_epson_qx-10.php

A few others said it was nice when it worked but was buggy and slow.

Forth Dimensions 14/5 p. 13 has an interesting article about a
successful telephone answering service application written in Forth,
fwiw.  It says it has 100 KLOC of source code and was written by 17
programmers for a total of 38 man-years.

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

#54713

Paul Rubin wrote:
> "HAA" <someone@microsoft.com> writes:
> > Tracked down the previous reference I mentioned.  'Interview with
> > J. D. Hall' Forth Dimensions 14/5 explains his role with Valdocs and
> > the problems surrounding the project.  It mentions the QX had several
> > 64K banks and was running a CP/M compatible OS.
>
> I can't find this anywhere, particularly in Forth Dimensions 14/5 if
> you meant this:  http://www.forth.org/fd/FD-V14N5.pdf
>
> Do you have another reference?
> ...

Sorry.  It was Forth Dimensions V9N5 page 31

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

#54716

"HAA" <someone@microsoft.com> writes:
> Sorry.  It was Forth Dimensions V9N5 page 31

Thanks, reading it now.

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

#54724

"HAA" <someone@microsoft.com> writes:
>Sorry.  It was Forth Dimensions V9N5 page 31

Thanks.  The point about Valdocs starts on Page 33, column 2: " After
that. I went to work with Rising Star."

About the problems of the project, it says:

|If You want to point any fingers. it was
|because of the editor. The editor was a
|concept picked up from Forth - it was the
|typical Forth line editor extended to this
|glorious What You See Is What You Get.
|
|The idea of the line editor is that you edit on
|the single line in the middle of the screen; as
|You scroll UP or down, the screen moved
|and you were editing that line. But a line of
|text extends any distance; you have to mark
|it there were a lot of complications. But
|the whole model was limited in how it was
|first conceived, and it grew beyond its
|bounds.
|
|The original concept should have been
|modified earlier. Rising Star spent a lot of
|money putting people in hotels. They took
|the editor team and locked them in a hotel
|for three weeks at a time trying to get the
|product up to a certain level. It was a very
|intense situation.There was no time even to
|go back and think.  They just plowed along
|at this point. Probably that should have said
|the end is coming.
|
|MH: If you get off on the wrong foot with
|a concept, you can go a long way; but
|there's a certain point beyond which you
|need to say,"This was a wrong turn,let's go
|back to the very beginning and rethink
|this."
|
|JH: You have to back up, but when money
|is involved, time is involved, and reputations
| are involved, sometimes you can't
|back up. And if you can't back up and you
|can't go ahead, the fate is sealed. That
|doesn't seem to be acceptable either, but it
|often comes to a tragic end.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#54725

On 2/8/2017 17:48, Anton Ertl wrote:
> |JH: You have to back up, but when money
> |is involved, time is involved, and reputations
> | are involved, sometimes you can't
> |back up. And if you can't back up and you
> |can't go ahead, the fate is sealed. That
> |doesn't seem to be acceptable either, but it
> |often comes to a tragic end.

A boss of mine in the early 1980s used to ask; "Why do we never have 
time to do it right, but we always have time to do it over?" I don't 
think he really knew the answer, even though he created, owned and 
managed a very succesful mainframe software company.

-- 
Alex

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

#54729

Alex <alex@rivadpm.com> writes:
> A boss of mine in the early 1980s used to ask; "Why do we never have
> time to do it right, but we always have time to do it over?" 

"Build one to throw away" was one of the take-aways from The Mythical
Man-Month iirc.

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

#54730

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> About the problems of the project, it says:
> |If You want to point any fingers. it was because of the editor. The
> |editor was a concept picked up from Forth - it was the typical Forth
> |line editor extended to this glorious What You See Is What You Get.

I found an old clf post mentioning Valdocs while looking for the FD
article.  The mention is brief but I thought the surrounding points were
also interesting.

 Jonah Thomas, comp.lang.forth 2003-07-18
 https://groups.google.com/d/msg/comp.lang.forth/7gWtjMoQXk8/Wr0yBdbZMWsJ  :

 The central thing Forth depends on is KISS.  We've consistently
 rejected complicated solutions when simpler solutions work.  The result
 is fewer co-adaptations, where you can't change one thing because it's
 built into a bunch of other things.  We do have some of that but not
 very many.  Giving up blocks removed a lot of them.  Blocks gave an
 integrated editor, and fast integrated compiling, and a sort of paged
 virtual memory, and something you could easily turn into a somewhat
 inferior database, etc.  It wasn't the best solution for very much but
 it gave an easy adequate solution for a whole lot.  I read that using
 blocks was a fundamental cause of the Valdocs failure so many years
 ago.  They started out with blocks and then ran into limits and instead
 of throwing them out and starting over they tried to design around them
 and ran out of time.  Now we use blocks when the problem demands them
 instead of wherever they look good enough.  It takes longer and we
 probably get better solutions.

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

#54701

Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
> Valdocs was nearly 16MB of FORTH code (according to the IEEE) running on
> a 4MHz Z80 with only 256KB of RAM.  Why would you expect it to be a
> success? ...

What?  No Valdocs was nowhere near that large.  There was a clf post a
year or so linking to the Valdocs source code and I looked at it.  It
was a mixture of Forth and assembler and I'm glad I didn't have to
maintain it, but I'm not that much of a Forther.  

> So, Forth had developed a bad reputation prior to the Valdocs failure:
> https://books.google.com/books?id=nS4EAAAAMBAJ&pg=PA80

That's a Dvorak column, one of multiple anti-Forth rants of his.

> That link says the Valdocs' "'compact and efficient' Forth code is
> more than 400K in size."

I could believe there's 400K of Forth source code.  That's a heck of a
lot less than 16MB.  I expect it would compile down to much less than
256K.  Here's another writeup about Valdocs that's more positive, by
someone involved in its development:

  http://electronicdesign.com/blog/rising-star

It apparently did quite a lot (word processor, mail program,
spreadsheet, drawing).  Doing that in just 400k actually sounds pretty
impressive.

FWIW I wrote most of my school papers using a text formatting program
(pcroff) originally written for CP/M and I remember it fondly.  It
doesn't take a whole lot of code or resources for basic word processing.
That program was written in C but it would have been doable in Forth,
maybe more intuitively even.  But it didn't include nearly as much stuff
as Valdocs.

> That seems to sum up the majority of real world Forth usage as the only
> notable projects I can find mentioned anywhere are...

The Saudi airport we've all heard about is missing from that list.

> Forth is like a set of craftsman’s tools.... Forth programs are
> tailored, they’re living and dynamic, not static object code."  -
> Charles Moore, Byte magazine, Volume 10, pg 316, 1985

Replace Forth with Lisp in that paragraph and you've got a philosophy
that accomplished some monumental things in the 1980s.  

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

#54704

On Tuesday, February 7, 2017 at 11:45:08 PM UTC-7, Paul Rubin wrote:
> Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
> > Valdocs was nearly 16MB of FORTH code (according to the IEEE) running on
> > a 4MHz Z80 with only 256KB of RAM.  Why would you expect it to be a
> > success? ...
> 
> What?  No Valdocs was nowhere near that large.  

16MB does seem like an exaggeration for a Z80 program. 

How many people were involved in Valdocs?

Is there a description of it somewhere?

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

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

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

csiph-web