Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cs.utexas.edu!ut-emx!mybest!moray!uhnix1!sugar!karl From: karl@sugar.uu.net (Karl Lehenbauer) Newsgroups: comp.lang.forth Subject: Re: type checking Message-ID: <2654@sugar.uu.net> Date: 20 Sep 88 03:27:09 GMT References: <8808121826.AA23206@jade.berkeley.edu> <1575@crete.cs.glasgow.ac.uk> <504@smegma.UUCP> Organization: Sugar Land Unix - Houston, TX Lines: 40 In article <1457@ficc.uu.net> I wrote: >Neither does the Forth language nor any Forth environment to my knowledge >adequately support the development of millions of lines of code by hundreds ^^^^^^^^ ^^^^^^^^ >of programmers, which is the scale of the activities at this mail address. In response to which mdg@smegma.UUCP (Marc de Groot), in article <504@smegma.UUCP>, wrote: > One of my clients has a data acquisition package for the IBM PC written in > Forth. 14 megabytes of source, or approximately 100,000 lines of Forth code. ^^^^^^^ > The project has been running for six years. The code is VERY maintainable, > due to the self-discipline of the programmers involved. The project has been > worked on by about a dozen different people over six years, some who were ^^^^^ > short-term, and others who have been there the whole time. Big difference in scale here, over a magnitude both in lines and number of programmers. > There are many environments that allow development of millions of lines > of Forth code. I would submit for the consideration of the net that Forth > suffers more from bad image than bad performance. What Forth environment even supports the *concurrent* editing of a few hundred thousand lines of code by a dozen programmers, let alone millions by hundreds? Do you have a Forth source code control system that's up to the task? Can't I still crash multiuser development in most Forth environments by doing a ": DIE BEGIN AGAIN ; DIE"? email support? networking? We need a real realtime operating system, too, not a polled task switcher. Of course it has to run protected mode multiuser multitasking. We insist on not having errant tasks clobbering each other when inexpensive hardware (even the '286) can prevent it. It must be able to swap and run a hundred tasks concurrently. Although there may be one, there is certainly no well known, moderately standard, successful implementation. I doubt most companies would let one write all that stuff from scratch if something else could be found that would do most of it. More reasons, I guess, why Forth hasn't received wider acceptance. -- -- uunet!sugar!karl, Unix BBS (713) 438-5018