oz@yunexus.yorku.ca (Ozan Yigit) (07/29/90)
In article <2408@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >It seems that the various groups of language designers seem more concerned >with restricting the language than in having it a means of communication. How do you know that?? Do you think you have studied enough many computer languages to make such sweeping claims? Have you ever designed and implemented a usable language? What do you know about human/computer communication? Have you studied *either* of these topics to any depth whatsoever before opening your mouth? >We need a language with reasonable syntax with which we can communicate >with the computer. How about esperanto ?? > It will necessarily have to contain a super-assembler. Necessarily !!! >Such a beast, >with a flexible macro processor, and a user-rewritable flexible syntax Macros AND user-rewritable syntax? Ah but of course !!! That is exactly what is needed !!! Why didn't anybody think of that before? Say, Herman, you ever heard of EL/1 ?? But Herman, why would I need any of this if I were communicating an AI program to solve problems? [Don't have to answer that Herman!! It is only a rhetorical question.] >would >enable someone like me to produce good code at a comparable rate to the HLLs. I doubt it very much. >HLL features can be added; I have no opposition to that.But we cannot afford >languages like the present analogues of Basic English, where the language >takes the position that something cannot be said. So glad to have your well-informed opinion on this matter.
ted@nmsu.edu (Ted Dunning) (07/30/90)
In article <13227@yunexus.YorkU.CA> oz@yunexus.yorku.ca (Ozan Yigit) writes: >would >enable someone like me to produce good code at a comparable rate to ^^^^ ^^ > the HLLs. I doubt it very much. actually, having seen an example of mister rubin's, i think that a super assembler really would allow him to generate code just as fast as any high level language. that doesn't mean that the high level language is deficient. it only points out the deficiency in mister rubin's programming skills. if _was_ kind of him to point this our for us. -- Offer void except where prohibited by law.
nevin@igloo.scum.com (Nevin Liber) (08/09/90)
[sorry for the repost, but I don't think that this made it out last time] In article <2416@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >It should be such as to enable the programmer to express his problem >in a manner that is compatible with the structure of his problem and >the capabilities of the machine. Wow, we actually agree on something. :-) >It should also be such that the >resulting program is reasonably efficient. True, but REASONABLY EFFICIENT is not the same thing as OPTIMAL. You seem to always want the most efficient "run time" solution, while the rest of us want to figure in our development time and the compile time as well. We are trying to make the whole computing SYSTEM more efficient, instead of just focusing all our energy on just one part of that system (in your case, the run time execution speed). You seem to ignore making the programmers work reasonably efficient. If it takes you half an hour to rewrite, compile, and test a routine so that it saves one millisecond, that routine had better be used at least 1.8 MILLION times just to break even! I'll even suppose that the cost of your coding time is negligible compared to the cost of computer time. How much CPU time do you spend in an editor? Or doing an extra compile or two because you feel it necessary to hand-optimize? If, for example, this averages to 15 CPU seconds per optimization, you had better be shaving at least that much off of the final CPU run time. Otherwise, your SYSTEM (you + computer) is not being reasonably efficient. >Now I do not believe that a language which can accomplish all this >can be produced which is completely portable. But it is necessary >to take these things into account in designing the language. Making >it extensible can enable local modifications to be made. This has many prices to it. Since you tend to ignore issues like code maintenance and portability, I'll focus on some more direct costs. Putting these features into the language increases the complexity of the compiler, and hence the compiler uses more computing resources. Are you really going to make your code that much more efficient, to make up for a compiler that takes, say, 5-10 times longer (both CPU time and real time) than, a C compiler? This is very doubtful. -- NEVIN ":-)" LIBER nevin@igloo.scum.com or ..!gargoyle!igloo!nevin (708) 831-FLYS Advertisement: Hire me!
karsh@trifolium.esd.sgi.com (Bruce Karsh) (08/15/90)
In article <2718@igloo.scum.com> nevin@igloo.UUCP (Nevin Liber) writes: >You seem to ignore making the programmers work reasonably >efficient. If it takes you half an hour to rewrite, compile, and test >a routine so that it saves one millisecond, that routine had better be >used at least 1.8 MILLION times just to break even! An excellent analysis. It's pretty easy for a routine in a program which is used by 10,000 people to be run 1.8 million times. Each user only has to run it 180 timesi, or once every working day for less than a year. If the routine is imbedded in an iteration, then it talkes even less people to break even. >I'll even suppose that the cost of your coding time is negligible >compared to the cost of computer time. How much CPU time do you spend >in an editor? Or doing an extra compile or two because you feel it >necessary to hand-optimize? If, for example, this averages to 15 CPU >seconds per optimization, you had better be shaving at least that much >off of the final CPU run time. Otherwise, your SYSTEM (you + computer) >is not being reasonably efficient. Again an excellent analysis. However, I have to quibble with your definition of SYSTEM. I think the SYSTEM should be (you + computer + users). Often there are a lot more users than you and the computer. So, if you save 15 seconds of run time and you have 1000 users, then it's worth 15*1002 seconds of time to perform the optimization. That's about 4 hours. If the system has 10,000 users, its worth 40 hours, or about a half a programmer-week. >This has many prices to it. Since you tend to ignore issues like code >maintenance and portability, I'll focus on some more direct costs. >Putting these features into the language increases the complexity of >the compiler, and hence the compiler uses more computing resources. >Are you really going to make your code that much more efficient, to >make up for a compiler that takes, say, 5-10 times longer (both CPU >time and real time) than, a C compiler? This is very doubtful. Still another excellent analysis! We shouldn't have to put up with a 5 times degradation in compile time. Of course, Unix C programmers have been putting up with this much degradation for a long time. Think C on the Mac is about 10 times faster than typical UNIX C compilers. So we need to make our C compilers much faster. Perhaps we could, in part, achieve that by bootstrapping them from a truely efficient language? Bruce Karsh karsh@sgi.com