UNBCIC@BRFAPESP.BITNET (03/20/91)
> 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. First point: agree. (Talk about Modula 2, for example!) Rest: ok, ok, you think that what C have is what you need... I need more to do VERY good programs in a SMALL time. BUT: C don't have data types. TYPEDEF is no more than #DEFINE (I'm being case non-sensitive) as is made clear in K&R famous book. A type have information and operations. You don't add operations to C. Modula 2, Ada, Smalltalk, CLU, Simula 67 have data types. And Forth have data types to, because you specify an operation with DOES>. > Heck, Assembly language has more "expressive power" than Forth! Does > that make it a good general purpose language? Hehehehehehe. "expressive power" is doing lots of things with very small code. You can do that in assembler? Man, you are a genious. > 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. Modular programming. You have parts. You don't try to combine parts. This wouldn't work even in C. You have to plan. And if you say that you don't have programs with many modules.... you do not represent the computer community. (p.s. give one more thing to me that is so hard to make fast in Forth as is floating point; floating point vendors standard is my answer to your example.) > 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). Yes, you have to care about lots of things when creating types in Forth. With ANS Forth we, now, have a STANDARD way to do it. But, anyway, Forth is like that to be able to be everywhere (give me a chip today, tomorrow I'll give you a Forth in this chip). If I want to be more abstract, I load a OO extension. What's the problem in doing this? > 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 Sorry, but you have to build a very concrete base anyway in any language. The difference is that in non-extensible languages the program is difficult all the way. In Forth it gets easier and easier. > "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! It's very simple: if you can only merge tools, you don't have nothing -- if all the correct tools were available, we wouldn't program anymore. (p.s.: I do not agree about assembly language. I don't need it in any place where I wouldn't need in other languages. I do not accept the floating point example, as I had said before.) > 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. We think this way: you will always have to abstract data types, so it's better provide a way to build *THE* data type I need than to provide many types and no good way to abstract new ones. OOL have good ways to abstract new data types. OOL would be a good alternative if their compilers/interpreters were PRAGMATIC. They are slow, produce big code and are hard to implement. Now, if you want to impose another way of thinking, and show that we can't do general programming based on YOUR way of thinking, we just can't talk. > 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. We have all this! They are not built in, but we have them. So, you CANNOT say that we didn't keep up with the latest inovations. It's just that we figure out that they are useful when they are useful, and, until them, we are not going to put them in our systems. When we want them, we use them! Why can't you see this?! Take a look at HS/Forth... What you want that it do not provide? Don't tell me that this is not standard: it's so standard as any laboratory language you can metion. > Bill <bouma@cs.purdue.edu> (8-DCS) Daniel C. Sobral UNBCIC@BRFAPESP.BITNET : Forth CREATE program that DOES> what is needed . ;
bouma@cs.purdue.EDU (William J. Bouma) (03/22/91)
In article <9103210411.AA14444@ucbvax.Berkeley.EDU> UNBCIC%BRFAPESP.BITNET@SCFVM.GSFC.NASA.GOV writes: >Sorry, but you have to build a very concrete base anyway in any language. The >difference is that in non-extensible languages the program is difficult all th Oooh, I hate that when you say your sorry! >It's very simple: if you can only merge tools, you don't have nothing -- if al >the correct tools were available, we wouldn't program anymore. If it is so simple, why didn't I understand a single thing you just said? >We think this way: you will always have to abstract data types, so it's better >provide a way to build *THE* data type I need than to provide many types and n That is just it. I would like to see Forth provide a way to do that. >that they are useful when they are useful, and, until them, we are not going t >put them in our systems. When we want them, we use them! Why can't you see >this?! Take a look at HS/Forth... What you want that it do not provide? Don't I do not mean this as an insult. It is just from the way you talk I cannot imagine you have written much code. -- Bill <bouma@cs.purdue.edu>