ritchie@hpdmd48.boi.hp.com (David Ritchie) (12/16/90)
I have been think about Forth a bit lately, and it seems that it will never be a mainstream language due to several reasons. These are: 1) Non-standard methods of generating standalone applications. There is no entry point that is equivalent to main() in C. There has been little done in books like "Starting Forth" to bridge the gap between typing short definitions at the keyboard to writing real applications. 2) Lack of variable/procedure scoping. No standard way of performing I/O between versions. Nonexistant type checking. Non-text files (yes, I know that this going away, but it is still quite common) for source code. Source code for Forth is just not as readable as HLLs. Reusability is difficult between programmers. 3) No grammar to the language. This makes Forth unfamiliar to the current crop of Pascal/C programmers. This makes it hard to define what Forth is, so instructors are reluctant to teach it. There is also not an industrial demand for Forth programmers, so it is safer for universities to teach C/Pascal. 4) FUD (Fear, Uncertainity, Doubt) in management of companies when Forth is proposed as a solution. "Our programmers only know (C/Pascal/ Fortran77) -- who will maintain this code if you leave?" "I don't know anything about this language." "We don't have time to train our programmers in some technology that may or may not solve our problems". (This is an outgrowth of the problem in that many companies no longer train employees, but instead get new employees that have the current knowledge they need for current projects). Forth is seen as a risk by managers that are uncertain of the abilities of their employees -- which, I would argue, is more often as not the case. It is easier to use languages like C/Pascal that have lots of error detection within their definition. Comments? -- Dave Ritchie ritchie@hpdmd48.boi.hp.com
UNBCIC@BRFAPESP.BITNET (01/03/91)
> I have been think about Forth a bit lately, and it seems that it will > never be a mainstream language due to several reasons. These are: > 1) Non-standard methods of generating standalone applications. There > is no entry point that is equivalent to main() in C. There has been little > done in books like "Starting Forth" to bridge the gap between > typing short definitions at the keyboard to writing real applications. Standalone applications... There is some confusion here... The most commom application in Forth *IS* Standalone, i.e., you turn on your computer, load Forth, load the application, and use it... The application, many times, are not just a entry point, but many words that performs many different functions needed. If you just use menus, you lose flexibility (no patches, for example). What Forth don't have (standard) is that kind of programs, that you type in the name (or click the icon), use whatever-it-is, and then return to the OS. It is a flawn, but not to the kind of application that Forth was designed (is best suited?) for... In the applications where interpretation it's a big difference, for example, the lack of standard way to interpret in C is a problem too... *BUT*, there is a very common way to do this in Forth... deffering BOOT. I think this could get in the (next release of) ANS Forth. In the Forth I use to create little .COM programs for my PC, I use TCOM, witch executes the last word defined (in older versions it had a MAIN....). > 2) Lack of variable/procedure scoping. You don't like VOCABULARIES, do you? I have an excelent Object Oriented Forth Extension (named OO4TH21) that cames with: records/structs, IMPORT/EXPORT as in Modula 2..... > No standard way of performing I/O between versions. Excuse me, I didn't understand this... > Nonexistant type checking. EXTEND YOUR FORTH! The OOFE I metioned above does very strict type-checking. And now, something to consider: Modula 2, Ada, Smalltalk and (who would say!) Algol 68 are all MUCH MORE POWERFUL THAN C AND PASCAL in the above points. In C, for example, you don't have procedure scoping... And, believe me, Modula 2 does EVERYTHING that C does, and MUCH MORE. SO.... > Non-text files (yes, I know that this going away, but it is still quite > common) for source code. No. Text files are common, but they are all different. > Source code for Forth is just not as readable as HLLs. > Reusability is difficult between programmers. I just don't agree. > 3) No grammar to the language. This makes Forth unfamiliar to the > current crop of Pascal/C programmers. This makes it hard to define what > Forth is, so instructors are reluctant to teach it. There is also > not an industrial demand for Forth programmers, so it is safer for > universities to teach C/Pascal. Modula 2, Smalltalk, Ada.... > 4) FUD (Fear, Uncertainity, Doubt) in management of companies when > Forth is proposed as a solution. "Our programmers only know (C/Pascal/ > Fortran77) -- who will maintain this code if you leave?" "I don't know > anything about this language." "We don't have time to train our > programmers in some technology that may or may not solve our problems". > (This is an outgrowth of the problem in that many companies no longer > train employees, but instead get new employees that have the current > knowledge they need for current projects). Forth is seen as a risk > by managers that are uncertain of the abilities of their employees -- > which, I would argue, is more often as not the case. It is easier to > use languages like C/Pascal that have lots of error detection within > their definition. Yeah. That's it. > Comments? Satisfied? > -- Dave Ritchie (8-DCS)
EBERBERS@YUBGEF51.BITNET (____ Zarko Berberski ____) (01/04/91)
> Standalone applications... There is some confusion here... The most commom > application in Forth *IS* Standalone, i.e., you turn on your computer, load > Forth, load the application, and use it... This is almost EXACT definition of appplication that is NOT stand-alone i.e. it can't be executed without some kind of intermediary ;-) Zarko Berberski EBERBERS@YUBGEF51.bitnet