bouma@cs.purdue.EDU (William J. Bouma) (03/13/91)
In article <3729.27db5037@iccgcc.decnet.ab.com> schmidtg@iccgcc.decnet.ab.com writes: > bouma wrote: >> Forth down. A language that deals only with characters and integers >> is a joke. It is no coincidence that Forth gravitated to the embedded >> processor area, they don't need to deal with anything besides integers >> ... > >FORTH is an excellent general purpose language for just these reasons! FORTH >provides one with the tools to create more specialized tools which are useful >to solve a given problem. Try adding a new control structure to 'c'! Why do people always try to drag C into the argument? I have never felt the desire to add a new control to C. I can program sufficiently in C given the structures which are provided. In addition C provides me with a wide variety of types and uniform ways to create new ones and deal with intermixing. >Traditional compilers just make too many assumptions about what it is you >want to do. If additional data types are required for your application, FORTH >allows you to easily create them. Perhaps FORTH's expressive power is not >for everyone, but when used with discipline, allows the creation of higher >level languages which are custom tailored to your specific applications. Heck, Assembly language has more "expressive power" than Forth! Does that make it a good general purpose language? Ok, write a floating point package (+ - * / are sufficient) using only Forth. Given a rich variety of integer and character operations this could be done. Now try sharing your code that uses this package with a friend. Good, that works because you have been careful to use only Forth in your package and avoided machine dependencies. Now try com- bining some code that uses your package with your friend's code that uses his package. Trouble. At that point you and your friend are both thinking you should have used the same package to start. Suppose in Forth I want to create a new type which is just a data struc- ture of integers and characters. In doing so I have to think about memory in a concrete sense. Memory allignment, slot access functions, byte size of integers are all considered in writing my code. In any language besides Forth all I gotta do is say I want a type named * which has slots ** of types ***. The compiler takes care of memory offsets, allignment, and access. Memory has become an abstraction with little shape or structure. Personally, I have found the higher the level of abstraction, the farther I am away from the actual machine, the more productive I can be. And I am one who LIKES to program in assembly language and can do so at lightning speed (brag, brag, brag). Forth allows me to program at a high level, but only after I have built a tower with a very concrete base. Having the ability to merge a tool "seamlessly" into the language and having the tool provided are very different things. For one, people are basically lazy and will opt not to write their own given a choice. It takes time and a certain level of expertise to build a solid foundation for the rest of program structure. To build the base in Forth you may have to resort to assembly language to obtain reasonable performance (eg. adding floating point). No other language which calls itself "higher level" would ever require the prog- rammer to know anything about the machine it is running on! Data types is such a basic and fundamental abstraction in programming that it is silly for Forth not to deal with it in a standard fashion, and be done with it. Why should each person that wants to use different types have to first figure out a method, and then implement it individually? It seems proof that Forth was never meant to be general purpose, that the type issue was not dealt with long ago. > bouma said: >> 8^) Perhaps. Perhaps it just isn't that deserving of attention from >> people who aren't tring to interface to hardware or aren't limited to >> 64K of memory. > >Or is it that concepts such as "rapid prototyping" and "extensibility" aren't >"deserving of attention" unless we refer to them in a language like smalltalk, >which originated in a research laboratory? But there are languages provide rapid proto, extensibility, AND a high level of abstraction, plus a rich variety of data types, OO constructs, macros, parallel constructs, automatic memory management, dynamic variables, pattern matching, ... (eg. Common lisp with CLOS) The reason Forth has not gotten any attention is because it has failed to keep up with the latest inovations in computer languages. It has nothing to do with Forth's bastard-like origins. -- Bill <bouma@cs.purdue.edu>
sanders@peyote.cactus.org (Tony Sanders) (03/15/91)
In article <13837@medusa.cs.purdue.edu> bouma@cs.purdue.EDU (William J. Bouma) writes: > seems proof that Forth was never meant to be general purpose, that the > type issue was not dealt with long ago. Lets change "general purpose" to "popular" because certainly Forth is general purpose. You can write games, op systems, etc. I don't think Forth was intended to be popular, and I'm glad. As for the "type issue" don't constrain yourself to a single way of thinking about problems. Just because you don't find Forth useful for what you are doing there is a whole world of people with different problems to solve. > Forth has not gotten any attention is because it has failed to keep up > with the latest inovations in computer languages. It has nothing to do I don't think Forth isn't popular because "it has failed to keep up with latest innovations" but that it's simply odd like old HP calculators, some love them, some hate them, they certainly are NOT for the masses. Forth's blessing is it's simplicity. Forth makes you think about problems in a different way, that alone is worth it. IMHO, The "latest innovations" are next to worthless. This is why people still program in asm, basic, cobol and fortran. The "lastest innovations" just aren't that much better. There ain't no great salvation waiting to be discovered just over the next hill. There are small advances and good ideas that have a lifetime and then they will be replaced with something a little better. Which isn't to say that we havn't come a long way already, just that there is still a long way to go. BTW: Is anyone out there willing to mail me UNIX source for forth-83? please let me know if you are and I'll give the address to mail to. -- sanders@peyote.cactus.org First rule of software: Throw the first one away. and so on... For every message of the day, a new improved message will arise to overcome it. I am not an IBM representative, I speak only for myself.
bouma@cs.purdue.EDU (William J. Bouma) (03/16/91)
In article <5931@awdprime.UUCP> Tony Sanders <sanders@peyote.cactus.org> writes: >Lets change "general purpose" to "popular" because certainly Forth >is general purpose. You can write games, op systems, etc. No, let's not talk about Forth's popularity. Forth is obviously not popular, so what is there to discuss? The question was "why?". My answer is that Forth is not a GOOD general purpose language. Surely you can program anything you want in it. If that is your criterion for "general purpose", what language is not? The generality I am talking about is that of being fairly easy to use for a large number of different areas. Forth could be the language of choice for writing a game, anywhere that is close to the hardware and doesn't need complicated data types like device drivers, or in a command interface. But there are better, friendlier choices of language if one is doing scientific programming, number crunching, symbol manipulation, database management, ... >As for the "type issue" don't constrain yourself to a single way of thinking >about problems. Just because you don't find Forth useful for what you are >doing there is a whole world of people with different problems to solve. Huh? Yeah, calling me close minded really addresses the points I made. Boy, that bites to the heart of the issue. Your argument is just to overwhelming for me! I guess I was totally wrong when I said "Forth is good for nothing". Hold it! Did I say that? >IMHO, > The "latest innovations" are next to worthless. This is why people > still program in asm, basic, cobol and fortran. The "lastest innovations" > just aren't that much better. There ain't no great salvation waiting Oh, really! What makes you such an authority? I think you need to take some of your own advice. Namely, just because you do not use something does not make it useless to everyone else. Do you even know what the latest happenings in computer languages are? And you presume to call me close minded! People still program in FORTRAN mostly because of tradition. There is a large body of useful code written in it that rightfully should not be simply discarded. FORTRAN is still an excellent language for number crunching. If all you want to do is solve large systems of equations, why bother to learn something more? (the lazyness factor again). Is there anything you can do with FORTRAN you cannot do equally or better with C? No. But if FORTRAN gives all you need, and you already know that, why learn C? People still program in assembly because it is necessary. People still program BASIC and COBOL because of tradition. These two are on the way out out out. (Please?) People still program in Forth because it is still good for what it was designed to do, control telescopes. It is still the best language for command and control of hardware in many situations. Forth has an inherent adaptability that I feel has not been taken full advantage of. The language could have grown along with our knowledge of computer languages. But it seems to be stuck in a niche that has not allowed this to happen. > to be discovered just over the next hill. There are small advances and > good ideas that have a lifetime and then they will be replaced with > something a little better. Which isn't to say that we havn't come > a long way already, just that there is still a long way to go. Oh, is that how it goes? But we are supposed to just ignore the small advancements because the old ideas still work? And just when do the new advancements become large enough to be significant? How do you propose to "replace" something you haven't allowed us to adopt in the first place? -- Bill <bouma@cs.purdue.edu>
ir230@sdcc6.ucsd.edu (john wavrik) (03/17/91)
In <13837@medusa.cs.purdue.edu> William J Bouma writes, > I can program sufficiently in C given the structures which are pro > vided. In addition C provides me with a wide variety of types and > uniform ways to create new ones and deal with intermixing. > Heck, Assembly language has more "expressive power" than Forth! > Does that make it a good general purpose language? > The reason Forth has not gotten any attention is because it has > failed to keep up with the latest inovations in computer languages. > It has nothing to do with Forth's bastard-like origins. This discussion seems to confuse several things: (1) what a basic Forth system contains; (2) what Forth is easily capable of support- ing; (3) how Forth has been marketed (including the target popula- tion); (4) how Forth has been managed (or mis-managed) by the Forth community; (5) extraneous factors having nothing to do with the language itself. Forth is a high-level architecture-based language. Like assembly language, most of its primitive commands refer to an underlying architecture. It avoids the extreme machine dependence of assembly languages by being based on an abstract (or virtual) architecture. It retains efficiency by a choice of virtual machine which can be closely mapped to a variety of real machines. On the other hand, it permits hardware dependent programming by containing an assembler producing code which can be readily integrated with high level code. It is unclear what "expressive power" means when applied to assembly language. Apparently it refers to the extent of what can be expressed rather than the ease with which things can be expressed. In terms of ease of expression, assembly language is not very expressive at all. Forth avoids a preoccupation with low level concerns (which charac- terizes assembly language programming) by providing a mechanism for transcending these concerns. It also faciliates program development by providing an interactive environment. In some respects, Forth is "assembly language done right". It avoids many of the shortcomings of assembly language -- while providing the strengths. This accounts for its usefulness in areas where assembly language alone would once have been used (everything from hardware control to the implementation of language features). The discussion above stresses the relationship of Forth to assembly language. Perhaps more important is that most of Forth, including control structures and data structuring words, is written in Forth. Functions conventionally performed by the compiler are, in Forth, distributed to the language. The effect of this is to drastically alter the balance of power between user and language designer/imple- menter. It provides the user with control over the language to an extent not possible in conventional languages. It opens up a possi- bility not offered by other languages: the ability of a user to create a language designed for a particular problem area. It is also not clear why the fact that some people's needs are met by 'C' is regarded as an argument against Forth. The needs of many mathematicians are met by FORTRAN -- but this is not an argument against 'C'. Different people have different computational needs. > A language that deals only with characters and integers is a joke. Here the problem seems to be a failure to distinguish between the core language and what it supports. Forth is a toolkit for building languages. All languages are ultimately built upon the capabilities of processor chips -- thus ultimately on the manipulation of inte- gers. The versions of Forth I use on a day-to-day basis, however, all incorporate more sophisticated data types. The Forth language has been used to produce languages which deal with various types of mathematical objects. The are not languages which "deal only with characters and integers" -- but they are extensions of Forth. > Forth allows me to program at a high level, but only after I have > built a tower with a very concrete base. Having the ability to > merge a tool "seamlessly" into the language and having the tool > provided are very different things. For one, people are basically > lazy and will opt not to write their own given a choice. First let us look at the top of the tower. This is usually a problem- oriented language which is more expressive, within its domain, than a conventional language. The tower has been built to produce a language closer to the target area -- narrowing the gap between the concepts of the area and the means of expression provided by the language. The fact that the tower has a very concrete base is incidental -- in most well-designed Forth systems, concern with the very lowest level occupies only a small part of the building process (and quickly becomes transparent). By the time the first floor has been reached, the system designer is already using specialized building materials, facilitating the construction even from low levels. The idea that such a tower must be erected from its base each time is misleading. Anyone who has programmed in Forth accumulates a repertoire of parts and building materials -- so that eventually towers can be construct- ed from recycled older parts. This not only makes building easier, but it fits in well with current concern about ecology. Apparently the issue being raised here is who will build the parts. There is nothing in the Forth language that prevents people from writing tools for the use of others. It's surprising to find people who actually think that floating point arithmetic has been unavail- able to Forth programmers for these many years. During the past 11 years I have had access to floating point packages on various Forth systems -- and have not had to write one for myself. Perfectly fine strings packages have been available -- and even, for those who want it, packages for adding local variables to a Forth system. The lan- guage does allow features like this to be added to Forth systems by anyone who wants them for building a "tower". The language does not distinguish between tools written by the user and those written by others. There is no doubt that the usefulness of Forth would be greatly enhanced by a variety of building parts that could be added as options to any Forth system. Eleven years ago, Forth was on the right track: the language was probably the most portable computer language in existence. It provided (in the words of John Backus) a flexible framework which could accept powerful fea- tures entirely as changeable parts. The only thing that was missing was a repository for tested and refereed language features. The nature of the language (particularly the access it provides to its implementation) should have opened the door for the production of optional packages of various sorts that could be added (either di- rectly or modified by the user) to any Forth system. There could have been a variety of storage management schemes, methods for introducing classes of data structures, user interfaces, several levels of strings packages, etc. from which towers could be assembled. This approach would have provided a far greater degree of flexibility than conventional languages offer FOR THOSE WHO NEED TO BUILD TOWERS. Let's repeat again that the needs of many people are met by pre-built structures -- there is nothing that Forth can or should do to attract these people to Forth. > The reason Forth has not gotten any attention is because it has > failed to keep up with the latest inovations in computer > languages. It has nothing to do with Forth's bastard-like origins. A language which offers the ability to accept features as add-on options rather than requiring them to be built in should also be in an advantageous position with regard to innovations in computer languages. New ideas can be tested and incorporated into existing systems (by those who want them) without requiring new re-designed languages. The fact that the scenario outlined above (a highly portable, simple, flexible framework -- and the availability of powerful features as changeable parts) has not taken place is not a problem with the Forth language, it is a problem with the Forth community. When a business fails, it could be because the product is bad -- but it also could be that it was not properly advertised, that it was targeted to the wrong market, or that the company was mismanaged. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093
esj@harvee.UUCP (Eric S Johansson) (03/18/91)
In article <5931@awdprime.UUCP> sanders@peyote.cactus.org (Tony Sanders) writes: > > IMHO, > The "latest innovations" are next to worthless. This is why people > still program in asm, basic, cobol and fortran. The "lastest innovations" > just aren't that much better. There ain't no great salvation waiting > to be discovered just over the next hill. There are small advances and > good ideas that have a lifetime and then they will be replaced with > something a little better. Which isn't to say that we havn't come > a long way already, just that there is still a long way to go. People code in XYZ lang for many reasons beyond their control. I code in C because I have to. Other people stay with a language because they are afraid to learn anything new. This does not mean that the latest innovations are worthless. it just means their full impact is not felt immediately. You are quite right that "There ain't no great salvation waiting to be discovered just over the next hill." Fred Brooks said as much in his IEEE Software article "No Silver Bullets". I believe that inovations work by reducing the complexity of solving problems in a specific problem domain. How much the complexity is reduced and the visibility of the reduction affects the value of the innovation. From my perspective, solving a problem is not unlike sitting at the bottom of a bowl and trying to get out. In its initial state all directions are equally difficult or complex (i.e. the depth of the bowl is equal in all directions). Finding a solution means you have reached the rim of the bowl. Tools are a means of deforming the bowl. Using a tool the right way means it is easier to solve the problem (reach the rim) with the tool than without it. The more a tool shows the direction of the deformations (solutions) the more useful the tool. This line of thinking leads me to believe that the next major innovation will be somewhere in the area of the mathamatics of programming. From what I can tell the techniques are incredibly sensitive to solving a problem the "wrong" way and give very strong indicators to where solutions lie. Better start studying your discreet math folks! -- ... ^^^ eric johansson UUCP ...!uunet!wang!harvee!esj esj@harvee.uucp * * a juggling fool AT&T (617) 577-4068 (w) o HAM ka1eec \_/ CSNET johansson%hydra@polaroid.com or hydra!johansson@polaroid.com source of the public's fear of the unknown since 1956
schmidtg@iccgcc.decnet.ab.com (03/19/91)
In article <13837@medusa.cs.purdue.edu>, bouma@cs.purdue.EDU (William J. Bouma) writes: > In article <3729.27db5037@iccgcc.decnet.ab.com> schmidtg@iccgcc.decnet.ab.com writes: >> bouma wrote: >>> Forth down. A language that deals only with characters and integers >>> is a joke. It is no coincidence that Forth gravitated to the embedded >>> processor area, they don't need to deal with anything besides integers >>> ... >> >>FORTH is an excellent general purpose language for just these reasons! FORTH >>provides one with the tools to create more specialized tools which are useful >>to solve a given problem. Try adding a new control structure to 'c'! > > Why do people always try to drag C into the argument? I have never felt > the desire to add a new control to C. I can program sufficiently in C > given the structures which are provided. In addition C provides me with > a wide variety of types and uniform ways to create new ones and deal with > intermixing. > > I consider both FORTH and 'c' to be "multi-level" languages and hence the comparision. Both languages allow you to get close to the machine and then build up to higher levels of abstraction. I think FORTH encourages one to create specialized tools which are useful to solving the problem at hand. For example, if your application requires extensive pattern matching, you might consider creating a CASE statement based on character string comparisons. > > Heck, Assembly language has more "expressive power" than Forth! Does > that make it a good general purpose language? I agree that "expressive power" alone does not make for a good general purpose language although it is a big part of it. Where FORTH excels is in the ease in which higher levels of abstraction may be applied until an application specific high level language is created. As an aside, in some ways I consider FORTH more powerful than assembly since I don't have complete control over the assembler, yet I have complete control over the FORTH "colon compiler" and may redefine it if I like. For example, let's say that I am writing a program in assembly and I want to trace program flow by printing the name of each subroutine as it is called along with its arguments. In assembly, this would be a laborious task and would require source code modifications. In FORTH, I can simply redefine the "colon compiler" to compile my traceback routine into the beginning of each word and then recompile my application. This would require 2, maybe 3 lines of FORTH. > > Ok, write a floating point package (+ - * / are sufficient) using only > Forth. Given a rich variety of integer and character operations this > could be done. Now try sharing your code that uses this package with > a friend. Good, that works because you have been careful to use only > Forth in your package and avoided machine dependencies. Now try com- > bining some code that uses your package with your friend's code that > uses his package. Trouble. At that point you and your friend are both > thinking you should have used the same package to start. If my friend and I have both implemented a standard such as IEEE then I would not expect to have a problem. This is a standards issue and I won't argue the point that FORTH standards for things such as floating point have been slow to mature. > > Suppose in Forth I want to create a new type which is just a data struc- > ture of integers and characters. In doing so I have to think about > memory in a concrete sense. Memory allignment, slot access functions, > byte size of integers are all considered in writing my code. In any > language besides Forth all I gotta do is say I want a type named * > which has slots ** of types ***. The compiler takes care of memory > offsets, allignment, and access. Memory has become an abstraction with > little shape or structure. Personally, I have found the higher the > level of abstraction, the farther I am away from the actual machine, the > more productive I can be. And I am one who LIKES to program in assembly > language and can do so at lightning speed (brag, brag, brag). This is a matter of control. I'd prefer to have the control in my own hands rather than leave it to the compiler. Nothing is more frustrating than a compiler which is "too smart for its own good" and makes assumptions which are correct 90% of the time. A compiler which assumes a particular alignment may not allow me to use its data structuring capability to define an external interface, such as a communication packet because it is making assumptions about alignment which may not always be true. > Forth allows me to program at a high level, but only after I have built > a tower with a very concrete base. Having the ability to merge a tool > "seamlessly" into the language and having the tool provided are very > different things. I agree that FORTH requires you to build a base and I think the standards should at least suggest uniform ways for building the "base". However, in practice, I have found that the needed "base" tends to be small as it need only address those aspects which are important to the problem I am solving. > > Data types is such a basic and fundamental abstraction in programming > that it is silly for Forth not to deal with it in a standard fashion, and > be done with it. Why should each person that wants to use different types > have to first figure out a method, and then implement it individually? It > seems proof that Forth was never meant to be general purpose, that the > type issue was not dealt with long ago. > I tend to think of FORTH as a set of tools which allow me to build special purpose tools which are useful for a given application. Initially, I may put forth (no pun intended) more effort in developing these application specific tools, but once these tools are in place, I may then use these new tools to allow me to be highly productive when applying them to a given problem. I find this to be one of the most creative and productive ways to solve a problem. I like the flexibility of creating my own tools, rather than having them rigidly provided by traditional compilers. I refer to the "staircase" example that Brodie mentions in "Thinking Forth". If I were building a house, I would like to have the ability to build my own staircase, rather than be limited to one supplied by a contractor. By building my own, I can get exactly what I want and be satisfied that it blends well with the rest of the house. On the other hand, I would agree that I should still have the option of buying the staircase from the contractor. With regards to FORTH, I think that issue is something which should be addressed by the FORTH standards. > variables, pattern matching, ... (eg. Common lisp with CLOS) The reason > Forth has not gotten any attention is because it has failed to keep up > with the latest inovations in computer languages. It has nothing to do > with Forth's bastard-like origins. > -- > Bill <bouma@cs.purdue.edu> If you dislike FORTH so much, why do you spend so much time in this newsgroup? Do you have some constructive comments on the direction you would like to see FORTH take, or do you feel that the language is a "joke" and should be abandoned altogether? -- ============================================================================= Greg Schmidt -> schmidtg@iccgcc.decnet.ab.com ============================================================================= "People with nothing to hide have nothing to fear from O.B.I.T" -- Peter Lomax ----------------------------------------------------------------------------- Disclaimer: No warranty is expressed or implied. Void where prohibited. =============================================================================
sanders@peyote.cactus.org (Tony Sanders) (03/19/91)
I attempted to be brief. In article <13903@medusa.cs.purdue.edu> bouma@cs.purdue.EDU (William J. Bouma) writes: > overwhelming for me! I guess I was totally wrong when I said "Forth is > good for nothing". Hold it! Did I say that? No, you didn't say "Forth is good for nothing", sorry I implied that. Your argument is: > Forth has not gotten any attention is because it has failed to keep up > with the latest inovations in computer languages. My reply (and others): Forth HAS, OOP, structures, bitfields, enums, macros, etc. And you can easily extend the language in all kinds of neat and useful ways. Some of these packages will/have standardized over time. Most are trivial to write in the first place. . I claim the lack of attention is that Forth is strange, if you like hp RPN . . calcs you might like Forth. opinions follow (1) I bet most people have not used it enough to know if it's better or not (2) People who like Forth are as fanatic about it as are emacs users :-) >In article <5931@awdprime.UUCP> I wrote: >>IMHO, >> The "latest innovations" are next to worthless. This is why people >>... > Oh, really! What makes you such an authority? I think you need to take > some of your own advice. Namely, just because you do not use something I think it's a reasonable conclusion given that so many OLD languages are still in use WITHOUT the latest and greatest. This DOES NOT imply that the innovations are in any way "bad". (1) They are wonderful ideas worthy of praise and use (2) I don't think that their existance has affected the popularity of Forth (3) I think that Forth HAS these ideas, but they don't solve the bigger problems of software development that may never be solved (ADA is a first attempt to address some of these problems). -- sanders@peyote.cactus.org First rule of software: Throw the first one away. and so on... I am not an IBM representative, I speak only for myself.
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (03/19/91)
> Forth HAS, OOP, structures, bitfields, enums, macros, etc. No, *Forth* does not have these things. *Some Forth implementations* have these things. It is not the same thing at all. Even though there are C-like languages with OOP, C does not have OOP. If many or most Forth implementations had the same set of OOP extensions, then Forth could be said to have OOP, etc. > Some of these packages will/have standardized over time. I doubt it. structures, bitfields, enums and macros are *ancient* technology, and they haven't been standardized yet. What will happen to make the standard? The only reason that ANS Forth has dynamic memory allocation (ALLOCATE and FREE) is because I fought like hell to get it in, and I convinced the committee that it cannot be portably defined on top of an otherwise standard system. > Most are trivial to write in the first place. What is trivial to some is mystical magic for others. Even if everybody could figure how to do a particular thing, nobody would do it the same way. That makes it hard to read and maintain other people's code. Furthermore, most people are jealous of their time, and would rather not re-invent 100 "trivial" wheels every time they have to write a program. Mitch
jwoehr@isis.cs.du.edu (Jack J. Woehr) (03/21/91)
In article <17574@sdcc6.ucsd.edu> ir230@sdcc6.ucsd.edu (john wavrik) writes: > >who actually think that floating point arithmetic has been unavail- >able to Forth programmers for these many years. During the past 11 >years I have had access to floating point packages on various Forth >systems -- and have not had to write one for myself. Right on, Dr. John! Even our eentsy Vesta embedded control oriented CPUs have floating point and transcendentals in ROM Forth ... Floating point (which mostly I can live without) is here to stay in Forth, not because the language prevents it or supports it, but because it ain't that big a deal to implement in Forth. -- # ..!apple!dunike!nyx!koscej!jax # "Therefore, the L-RD G-d # # ..!hplabs!hp-lsd!oldcolo!jax # sent him FORTH ..." # # {apple,hplabs,pacbell,ucb}!well!jax # - Genesis 3:23 # # JAX on GEnie SYSOP RCFB 303-278-0364 # Member ANS Forth X3J14 TC #
bouma@cs.purdue.EDU (William J. Bouma) (03/22/91)
In article <3835.27e4e843@iccgcc.decnet.ab.com> schmidtg@iccgcc.decnet.ab.com writes: >This is a standards issue and I won't argue the point that FORTH standards >for things such as floating point have been slow to mature. Funny, most of what I have been talking about is standards issues! > bouma said: >> Suppose in Forth I want to create a new type which is just a data struc- >> ture of integers and characters. In doing so I have to think about >> ... > >This is a matter of control. I'd prefer to have the control in my own hands >rather than leave it to the compiler. Nothing is more frustrating than a > ... >interface, such as a communication packet because it is making assumptions >about alignment which may not always be true. It is mainly a matter of a standard mechanism for creating new types. How does this imply that one will lose control over anything? It is to us to design it in such a way that one has as much control as is needed. But the mundane repetitious details should in most cases be left to the computer. > bouma wrote: >> Data types is such a basic and fundamental abstraction in programming >> that it is silly for Forth not to deal with it in a standard fashion, and >> be done with it. Why should each person that wants to use different types >> have to first figure out a method, and then implement it individually? >... >given problem. I find this to be one of the most creative and productive >ways to solve a problem. I like the flexibility of creating my own tools, >rather than having them rigidly provided by traditional compilers. I >refer to the "staircase" example that Brodie mentions in "Thinking Forth". >If I were building a house, I would like to have the ability to build >my own staircase, rather than be limited to one supplied by a contractor. >By building my own, I can get exactly what I want and be satisfied that That is silly. That presumes you have both the knowledge and the physical ability to build the stairs. If all I want to do is climb to the second floor, why should I be forced to build my own stair? Since there exist well known and standard ways for building stairs I expect that an exper- ienced builder could do a better job with it than I, unless I were to put a lot of effort into it. The analogy breaks down, though, in that everyone knows how to climb stairs, but if someone were to come over to your "Forth house" he would have to learn from scratch all of your self- built constructs. Is your goal is to simply build yourself a nice per- sonalized house? My goal is to build a skyscraper, a city, or even to go off planet. 8^) I may think I am good, but I will need some help on that last one. >If you dislike FORTH so much, why do you spend so much time in this >newsgroup? Do you have some constructive comments on the direction >you would like to see FORTH take, or do you feel that the language >is a "joke" and should be abandoned altogether? I think I have been clear on what I think Forth in it's present form is good for. As to the first question, it answers itself. The fact that I spend time time in this group at all shows that I like Forth. I have learned things from reading this group, and I think I have something to contribute to it. I have as much right to post my opinion on why Forth has not found CS acceptance as anyone else. (If you think back, that is how this all started.) I thought I had been giving constructive criticism! One of the directions (I have several, but don't want to upset anybody.) I would like to see Forth go is to acknowledge that there are other types besides integers and characters. I think this can be done in such a way that Forth does not lose its identity, its flexibility, or its controlability. What it might gain is a higher level of programming and an increased sharing of code. Several of you seem ready to dismiss the whole concept as bad without ever thinking objectively about it. If you just want to build houses, why deny the rest of us the tools to build cities? Forth may be be good enough for you now, but I would not mind seeing it made better. Thus I hate Forth. -- Bill <bouma@cs.purdue.edu>
cwpjr@cbnewse.att.com (clyde.w.jr.phillips) (03/22/91)
In article <13985@medusa.cs.purdue.edu>, bouma@cs.purdue.EDU (William J. Bouma) writes: > In article <3835.27e4e843@iccgcc.decnet.ab.com> schmidtg@iccgcc.decnet.ab.com writes: > >This is a standards issue and I won't argue the point that FORTH standards > >for things such as floating point have been slow to mature. > > Funny, most of what I have been talking about is standards issues! > > > bouma said: > >> Suppose in Forth I want to create a new type which is just a data struc- > >> ture of integers and characters. In doing so I have to think about > >> ... > > > >This is a matter of control. I'd prefer to have the control in my own hands > >rather than leave it to the compiler. Nothing is more frustrating than a > > ... > >interface, such as a communication packet because it is making assumptions > >about alignment which may not always be true. > > It is mainly a matter of a standard mechanism for creating new types. If <Builds Does> doesn't equate to essentially allowing a specific "contractor" to establish a "Standard" mechanism for defining structures as defined below then this thread may have merit. I like structure defining words. I Like <Builds Does>. I can essntially produce the same results from either, but only <Builds Does> is "standard" In the analogy here structure defining words are prefab's and <Builds Does> is standard construction methodology. Is your argument that having structure defining words standard would be better than defaulting to multiple "contractor methodologies"? ( ie for building subdivisions vs a dream house ) If so I think you could have stated that without the recource of challenging other's programming "manhood". In other words you are playing a too literal semantics game here that I feel denigrates you more than your protagonist, at best zero sum. Come on out for standard structure and union words if that's what you mean. Don't just be meam. Clyde
esj@harvee.UUCP (Eric S Johansson) (03/25/91)
In article <5992@awdprime.UUCP> sanders@peyote.cactus.org (Tony Sanders) writes: > opinions follow > (1) I bet most people have not used it enough to know if it's better or not > (2) People who like Forth are as fanatic about it as are emacs users :-) I must be in really deep sneakers. I am a fanatical emacs and forth user... :-) --- eric -- ... ^^^ eric johansson UUCP ...!uunet!wang!harvee!esj esj@harvee.uucp * * a juggling fool AT&T (617) 577-4068 (w) o HAM ka1eec \_/ CSNET johansson%hydra@polaroid.com or hydra!johansson@polaroid.com source of the public's fear of the unknown since 1956
schmidtg@iccgcc.decnet.ab.com (03/26/91)
In article <1991Mar22.144111.3076@cbnewse.att.com>, cwpjr@cbnewse.att.com (clyde.w.jr.phillips) writes: > > If <Builds Does> doesn't equate to essentially allowing a specific > "contractor" to establish a "Standard" mechanism for defining > structures as defined below then this thread may have merit. > > I like structure defining words. I Like <Builds Does>. I can essntially > produce the same results from either, but only <Builds Does> is "standard" > > In the analogy here structure defining words are prefab's and <Builds Does> > is standard construction methodology. > > Is your argument that having structure defining words standard would be > better than defaulting to multiple "contractor methodologies"? > > ( ie for building subdivisions vs a dream house ) > Let me elaborate: The ability to define define 'c' like structures seems to be a common item in the "base" of many programs. This usually looks something like struct <structname> <size> field <fieldname> . . . and is generally useful. "struct" above is the "prefab" version and is useful 90% of the time when I want to deal with structures in FORTH. I have seen variations of the above implemented slightly differently in several FORTH programs. As this appears to be a common part of the "base" of many programs, I think it would be nice if there was a FORTH standard which addressed such optional, but commonly implemented constructs such as this. That way, if we all follow the standard, I don't have to understand each new variation which looks slightly different, yet accomplishes the same task. I was arguing that I consider this a "standards issue", not a weakness in the FORTH language itself. I'll continue to use CREATE DOES> when building my "dream house". However, most of the time I only want to build a tract home and I WANT my tract home to look exactly like everybody elses because the contractor gives me a better deal on the maintenance plan. In that case, I'd really like to have a standard "struct". (The above argument also applies to pseudo-standard things such as CASE statements and the like.) > If so I think you could have stated that without the recource of > challenging other's programming "manhood". I didn't know that anyone's programming "manhood" was being challenged in these discussions. Where did you get that idea? > In other words you are playing a too literal semantics game here that > I feel denigrates you more than your protagonist, at best zero sum. Huh? Speaking, of semantics, could you be a little more specific here? > Come on out for standard structure and union words if that's what you mean. > Don't just be meam. > > Clyde Hmmm, meaness was certainly not the intent. By the way, have you read "Re: Hooray for Dissention"? -- that might help clarify Greg -- ============================================================================= Greg Schmidt -> schmidtg@iccgcc.decnet.ab.com ============================================================================= "People with nothing to hide have nothing to fear from O.B.I.T" -- Peter Lomax ----------------------------------------------------------------------------- Disclaimer: No warranty is expressed or implied. Void where prohibited. =============================================================================