On Wed, 16 Apr 1997 17:09:56 GMT, ala...@abwillms.demon.co.uk (Alaric
B. Williams) wrote: >>Ok, most people would put C++ first in the so-called "low-level" power >>stakes. But it doesn't all go C++'s way. You define low level power as >>the power to control implementation. Consider that C++ is a strictly >>stack based language. Unlike Scheme, (or assembler with some tricky >>mucking around), you can't have multiple "stack-like" environments all >>existing at once. (i.e. continuations and call/cc).
>>This is a powerful low level feature that C took away from assembler, >>but Scheme allows.
Iiiii know what I found a little odd about this. Yeah, I don't really think call/cc is a low level feature. It is a window to something usually totally hidden by the implementation, but it's not low level control of the implementation, since you don't know/tell anything you don't need to when you program continuations. I mean, accessing the bits of an integer is low level, but being able to dynamically link libraries in is more a widening of control than of making control lower-level, IYSWIM...
ABW -- "Plug and Play support: WfEWAD will autodetect any installed Nuclear Arsenals, Laser Satellites, Battlefield Control Networks, Radar Installations, Fighter Squadrons, and other WfEWAD compliant devices, including the new Macrosoft Unnatural Keyboard, with full support for the now-famous Big Red Buttom(tm)."
(Windows for Early Warning and Defence User's manual P26)
On 17 Apr 1997 16:04:25 GMT, c...@cs.umd.edu (Charles Lin) wrote:
> Notice this is why I said "if one HAD to" choose a single data type, >a string would probably be it. I didn't argue that it was a good idea. >In other words, given that you had to choose one type that a language >had to be in, what would you choose? The problem with lists is that >a list is really a compound data structure. For example, in a Lisp >list (a (b c)), what is "a", "b", and "c"? Lists are built from >basic elements. Yes, yes, you can build up some sort of counting by >using the empty list and list of empty lists, and so on, but again, >ease of programming counts.
It's that misconception again! TCL is lists of characters! Scheme has a load of types which are on equal footings, in that containers and atoms are interchangeable!
-- "Plug and Play support: WfEWAD will autodetect any installed Nuclear Arsenals, Laser Satellites, Battlefield Control Networks, Radar Installations, Fighter Squadrons, and other WfEWAD compliant devices, including the new Macrosoft Unnatural Keyboard, with full support for the now-famous Big Red Buttom(tm)."
(Windows for Early Warning and Defence User's manual P26)
> Will Duquette wrote: > > You'll notice that I've made no arguments about Tcl as a *language*. > > Pragmatically speaking, though, it enables me to get my job done > > easily, efficiently, and well.
> At last a sensible attitude about Tcl. No unjustified claims to > superiority, just pragmattics.
> graham > -- > You can blow out a candle > But you can't blow out a fire > Once the flame begins to catch > The wind will blow it higher
Pragmatics have no place in a theological debate or language flame war. They might blow out the fire. <g>
Seriously, offtimes DCL (the VMS shell language) let's me get my job done. So what? It is not nor does it pretend to be a good language. We're comparing languages, so I suggest we fight to the death over (or until we agree upon) The One Best Language for Everything <g>.
I suggest Lisp. Any counter-offers must include full dynamism, introspection, procedural macros, lexically-scoped closures and generic functions and must not include static typing. You know, Lisp. <g>
On 15 Apr 1997 18:18:45 GMT, c...@cs.umd.edu (Charles Lin) wrote:
> If one had to choose a single type for everything, a string is a >pretty good choice. Why not a number? How would you represent a >string with a number?
Because the fundamental type has to be some kind of list. So really, the TCL fundamental type is the character, which never exists outside of a string (much like quarks like to hang around in pairs or threes), whereas in LISP, there ain't a fundemantal type... you get ints, chars, etc. which may or may not be inside lists or vectors.
Just thought I'd clear that up.
ABW -- "Plug and Play support: WfEWAD will autodetect any installed Nuclear Arsenals, Laser Satellites, Battlefield Control Networks, Radar Installations, Fighter Squadrons, and other WfEWAD compliant devices, including the new Macrosoft Unnatural Keyboard, with full support for the now-famous Big Red Buttom(tm)."
(Windows for Early Warning and Defence User's manual P26)
According to Paul Prescod <papre...@csclub.uwaterloo.ca>: :In article <s6ypvvukubq....@aalh02.alcatel.com.au>, :Chris Bitmead uid(x22068) <Chris.Bitm...@alcatel.com.au> wrote: :>none the wiser (apart from awful performance of course). Why do you :>want to fit everything in a string?? It buys you NOTHING.
Note that Tcl does _not_ store _everything_ in a string. It uses strings as the data type to pass between it's commands.
For instance, when one opens a file, one gets back a string whose value is a handle pointing to an open file descriptor. The file descriptor remains the binary structure the OS expects. The Tk extension's creation of widgets is another fine example. I hope that folk don't think that Tcl somehow converts all the various X window system structures to string to pass around. Instead, handles (of type string) for these structures are created. When one needs to manipulate the binary entity under one of these handles, one uses a structure which knows how to move from the string to the structure and back.
Various other extensions have had great success adding other handles to other data types. So in the strictest sense, one is not just limited to strings in Tcl. One is, at least pre-Tcl 8.0, limited in treating the _names_ of these entities as strings. -- Larry W. Virden INET: lvir...@cas.org <URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh." Unless explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions.
|| strings are excellent for external representation, and that's where they || should be used. internal representation should be efficient for the || machine. when and if you need to read or print a value, use the external || representation, but as long as you work with it internally, use something || more efficient. where you define yourself relative to "external" is of || course an open issue.
This was the point. Now, perhaps I completely misunderstood what Ousterhout did, but I was under the impression that he said everything in Tcl (the external representation) is a string. Why are we talking about internal representations at all? My point is that if you had one external type you wanted to use (and I don't even argue that this is a good idea), I would think it would be a string. Internal representations aren't going to be important because they are hidden from the user (mostly). Use whatever representation is useful to get the thing done internally. That's not what I was addressing. To repeat, my argument has absolutely nothing to do with how the computer represents the language internally. The point is that (almost) no one wants to write a program whose *external* representation is numbers. Strings are more flexible, if they're the only type you have, as external representation.
The argument I've read is (1) numbers can be used to represent any other (countable) type through Godel enumeration, and (2) computers use numbers to represent things underneath. The challenge is this. You are to write a language for users to use. I give you one type that you will give to the user to use. Would your users prefer strings or numbers? I'm not talking about internal representation. Do I think everything should be strings in a language. Personally, no, but given the above, how would you have answered it?
p.s. I understand internal representation vs. external. Computers use two's complement signed notation to represent integers and mostly IEEE 754 floating point representation to represent floating point numbers with mantissa and exponent. Strings are usually represent (in C/C++) as ASCII in consecutive bytes in memory terminated by a null character. Each position is a character in the ASCII character set.
On 18 Apr 1997 11:38:56 +0200, giacomo boffi wrote in comp.lang.scheme,comp.lang.scheme.scsh,comp.lang.lisp,comp.lang.tcl,comp.la ng.functional,comp.lang.c++,comp.lang.perl.misc,comp.lang.python,comp.lang. eiffel <URL: news:m3g1wooekv.fsf@boffi95.stru.polimi.it>: ++ o...@ds9.rnd.border.com (ozan s. yigit) writes: ++ > life is too short to have to re-respond to the same old bits again ++ > and again, and not everyone has tom christiansen's stamina. :) ++ ++ sorry ozan, you were fouled: ++ ++ the Tom Christiansen on c.l.p. is an AI perl program ++
>Ok, in all fairness I do have to note this as a contribution on the >side of Tcl. I was quite pleased that a language existed to allow >control of other programs, and did in fact think it was a nifty idea. >So regardless of my feelings towards Tcl, I do admire the idea of >Expect.
. . . It's a different contribution than you might realize. Don Libes has emphasized, at least in the writings I've seen, that there's no necessary connection between Expect and Tcl. He always expected people to write Expecting extensions for such other languages as Perl, Rexx, ...; in fact, there was an Expect (in C?) *before* he re-did it for Tcl.
Perhaps *that* is some sort of testimony to Tcl's appropriateness; as straightforward as it would be to re-do Expect in other lan- guages, Tcl has always been good enough, and so the migration has never been done.
In article <5j7o20$s1...@news.du.etx.ericsson.se>,
Robert Virding <r...@erix.ericsson.se> wrote: >In article <E8sJ14...@undergrad.math.uwaterloo.ca>, papre...@csclub.uwaterloo.ca (Paul Prescod) writes: >>In article <s6ypvvukubq....@aalh02.alcatel.com.au>, >>Chris Bitmead uid(x22068) <Chris.Bitm...@alcatel.com.au> wrote: >>>none the wiser (apart from awful performance of course). Why do you >>>want to fit everything in a string?? It buys you NOTHING.
>>It buys you not having to write string->number. I don't think that this is a >>big win, but I could see how it would be useful to people who are not used >>to thinking about data types.
>Actually there is no win at all. If you are going to DO anything with >the number you need string->number. The question in this case is >rather WHEN you do the conversion.
No, the system does the conversion implicitly. The user never types string->number.
>If it is not the language itself then it must be some property of the >system itself which is useful and not found in other language >systems. What I don't know.
* Charles Lin | Now, perhaps I completely misunderstood what Ousterhout did, but I was | under the impression that he said everything in Tcl (the external | representation) is a string. Why are we talking about internal | representations at all?
because the internal representation in Tcl is the string.
| Internal representations aren't going to be important because they are | hidden from the user (mostly).
I think you're missing the point all over the place. Tcl's purpose is to glue different applications together, but also to do something with the returned "values" (i.e., output) of these programs. of course we're dealing with interfaces where external representations will be used, but Tcl uses the same external representations for internal purposes, too. when you execute a numeric operation, the string is converted to a number, the operation is performed, and then converted back to a string. in contrast to this view, AWK converts a string to a number when it is used for a numeric purpose, and a number to a string when it is used for a string purpose, but not otherwise. (at least, this is what I have understood from what I have read about Tcl.)
| The point is that (almost) no one wants to write a program whose | *external* representation is numbers.
nobody has suggested they do, and nobody in their right mind would.
| Strings are more flexible, if they're the only type you have, as external | representation.
but external representations _aren't_ typed!
I'd venture that that's the whole point in using an _untyped_ string (or even byte-sequence) representation is that whoever reads it would be able to interpret it, indeed that type would emerge from the interpretation.
#\Erik -- I'm no longer young enough to know everything.
: Pragmatics have no place in a theological debate or language flame war. : They might blow out the fire. <g> ... : We're comparing languages, so I suggest we fight to the death over (or : until we agree upon) The One Best Language for Everything <g>. ... : I suggest Lisp. Any counter-offers must include full dynamism, : introspection, procedural macros, lexically-scoped closures and generic : functions and must not include static typing. You know, Lisp. <g>
I represent a rabble of one that takes no prisoners! Counterthrust: where the bleep is human-factors in this never-ending thread? Anybody care to actually reference what little research has been done in this area?
I couldn't help but notice that the Ousterhout white paper had only one reference to one measly result of human factors research; and it came from a secondary source. I believe that ALL the designers of ALL the languages this thread is cross-posted to (and many that aren't) didn't even attempt to study software psychology (or psycholinguistics).
NOTE TO LISP AND FORTH FANS: one important reason your languages have never caught on may be due to the fact that many natural languages follow the "subject verb object" form. Usage of SOV, OSV, VSO, and VOS are less likely (I don't have any references in front of me; if anybody wants details, I'll try to locate what I have). They also lack visual redundancy (they aren't alone in this short-coming of course).
In <MPG.dc132702ba24471989...@news.demon.co.uk>, cyber_sur...@gubbish.wildcard.demon.co.uk (Cyber Surfer) wrote:
> With a mighty <19970417.7DC0A38.8...@contessa.phone.net>, > bouncen...@contessa.phone.net uttered these wise words...
> > Most programming languages (including > > ports from Unix) include facilities to talk to these applications. > So what are people arguing over? The choice of scripting language is > irrelevant, if the app doesn't dictate any specific language.
Unfortunately, there are people using lesser platforms that don't have or only recently acquired these facilities, so they can't do that. :-)
And some people just like arguing about religious issues.
> I don't see why MS and Windows developers - and users - should be the > only people to benefit from this fine idea.
They aren't. Like I said, I (and a few million others) have had the benefit of this functionality for most of the last decade.
It appears that Unix may get such a solution in the form of applications that support JVM as a scripting mechanism. This allows any language that can be used to produce JVM bytecodes to be used for scripting. There may be technical problems with this solution, but it's a start.
If you're really interested, I started working on a TCP/IP solution for this kind of thing a while back. It got aborted by a corporate takeover, but I may still have the groundwork somewhere (if not, the critical parts are easy to recreate).
<mike
-- Do NOT reply to the address in the From: header. Reply to mwm instead of bouncenews at the same machine. You have been warned. Sending unsoliticed email I consider commercial gives me permission to subscribe you to a mail list of my choice.
In article <s6yn2qxkwix....@aalh02.alcatel.com.au> Chris.Bitm...@alcatel.com.au (Chris Bitmead uid(x22068)) writes:
The only benefit you claim for Tcl that doesn't also apply to scheme is #3. You would like to type...
func arg1 arg2 instead of (func arg2 arg2)
Ok, a minor but perhaps valid point if you want dumb users to use it like a shell.
And then, he goes on to suggest ways to make Scheme do that.
What I was expressing with my point #3 was a psychological effect, and it extends to functions written in the language as well as individual commands, though I notice it most when typing commands interactively. I also prefer
if {$x < 3} { foo arg1 arg2 } else { bar arg3 arg4 }
to something like
(if (< x 3) (foo arg1 arg2) (bar arg3 arg4))
I confess, though I've toyed with Lisp and Scheme in the past, I'm primarily a C programmer. Most of the people I work with are C or C++ programmers. The Tcl version gives us warm fuzzies, and the Scheme version doesn't.
I did a web search yesterday, and found a couple of Scheme implementations which would probably work as well for my purposes as Tcl, except for the psychological issues I mention. If I were starting over, though, I'd still pick Tcl. It's plenty good enough, and it "feels" better to me. Frankly, that's what's important.
-- -------------------------------------------------------------------------- Will Duquette, JPL | William.H.Duque...@jpl.nasa.gov But I speak only | w...@bean.jpl.nasa.gov for myself. | It's amazing what you can do with the right tools.
d...@danpc.cris.com (Dan Haskell) writes: >In article <5ilbk6$f8...@news.du.etx.ericsson.se>, Robert Virding wrote: >[lots snipped] >>A final question which has long interested me and which seems relevant >>to this whole discussion: who would use Tcl if it DIDN'T have such a >>integrated interface to Tk? >Anyone who wanted a simple scripting language that could be easily embedded >into their applications. Last time I checked Tcl was the only language you >could do this with. There was something called libscheme that came close, >but did not really allow for full integration with the application.
What do you mean by "full integration with the application"? Libscheme just lets you control the Scheme interpreter from C, what does Tcl has that helps your integration.
Talking of Scheme's for embedding:
mzscheme is built on top of libscheme and somewhat more under developement. Uses the same C call interface (and a slightly screwup up install procedure). Mzscheme also has support for Guile's C interface.
SCM and Guile are another line, using a different interface (two, to be precises), a faster interpreter than libscheme that is slower at startup.
The third is Elk, which focuses on using C from Lisp, can load object files at runtime. The other systems work the other way round, by linking the C program with a scheme lib.
Elk is very descent, libscheme as well, but guile-1.0 lacked suport for important functions when it comes to embedding (the current snapshots have them) and Scm is somewhat hard to build for non-experienced people.
Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% Martin_Craca...@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536 "As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
* James Logajan | NOTE TO LISP AND FORTH FANS: one important reason your languages have | never caught on may be due to the fact that many natural languages follow | the "subject verb object" form. Usage of SOV, OSV, VSO, and VOS are less | likely (I don't have any references in front of me; if anybody wants | details, I'll try to locate what I have). They also lack visual | redundancy (they aren't alone in this short-coming of course).
I hope you find studies of human factors with _experienced_ users. the results coming from the ever-present inexperienced users has no validity for more than inexperienced users, yet get touted as truths about the languages. this tends to annoy people who believe that "experience" is a valid concept in any discipline.
for some reason, we don't see open heart surgery defamed by "research" into how inexperienced users with a scalpel and an attitude kill people and that it should therefore be a discommended practice.
many a Lisp programmer will testify that he thinks in Lisp and reads Lisp code with _less_ "stack depth" and "cognitive load" than is needed for the many other languages he knows. e.g., I find C to be _much_ harder to read than Lisp because I need to scan forward in hairy expressions a lot to know how things work together, and to scan backwards for type information. I also have to work to remember operator precedence rules in the language. in Lisp, I may have to scan back and upwards, but I've already been there when I'm reading the code. in C++, I need to keep in mind the classes of all the variables so I can have a glimmer of hope of understanding _which_ function is being called. the foo in x.foo is not the foo in y.foo, unless the class of x and the class of y relate such that they are. in CLOS, (foo x) and (foo y) is the same generic function with different specializers and a Lisp programmer is _much_ less likely to implement widely different semantics with the same name than is a C++ programmer who is "alone" in his class (hierarchy).
there should be a measure of "mental clutter" that each language leaves with its (moderate to excellent) programmers.
somebody should tell those Subject-Verb-Object guys from the wrong department that it is quite uncommon to nest sentences and expressions the way it is done in programming languages, lest this invalid argument should keep coming back from the argument grave yard yet again. for some reason, C/C++ programmers can't handle very deep nesting, while Lisp people can. my take on this is that C/C++ already "use up" quite a number of "stack levels" with its complex syntax, while Lisp does not, and can use those "stack levels" for real work.
back in high school, I was reprimanded by my teachers for using too long sentences and too complex sentence structure. (my editors have said the same.) I found the rules they laid down for me to follow to be extremely crippling in expressive power. write short sentences. use only simple conjunctions. don't use the passive voice. the active voice helps "involve" people. this all gives me the creeps. subject verb object. I just don't think that way. I think of my sentences as evaluation of nested expressions that yield intermediate values used by other parts of the sentence and which conclude in communicating some meaning. the paragraph is similarly constructed to carry those sentence-values forward into a concluding sentence. this process _precludes_ the use of stunted forms and the imperative, active style for me. then again, I don't write children's books or "Crotch Sniffing for Dummies".
and last time I checked, I was still human, despite all this bogus research into human factors that pretends I and people like me don't exist.
#\Erik -- I'm no longer young enough to know everything.
James Logajan <jam...@netcom.com> wrote: >Ken Tilton (t...@bway.net) wrote: >: Pragmatics have no place in a theological debate or language flame war. >: They might blow out the fire. <g>
There is a difference between theories and theology, though either is often easy to mistake for the other.
>: We're comparing languages, so I suggest we fight to the death over (or >: until we agree upon) The One Best Language for Everything <g>.
I don't think many poeple here believe there is One Best Language for Everything. There are, however, languages that are good for more things than others. (Say Pascal vs. Modula-2, to pick a similar-but-different pair.)
>: I suggest Lisp. Any counter-offers must include full dynamism, >: introspection, procedural macros, lexically-scoped closures and generic >: functions and must not include static typing. You know, Lisp. <g>
I like all of those features myself, but let's not get greedy. :-) (And by the way, generic functions are not part of Lisp per se, they're part of Common Lisp with CLOS and some other languages that adopted the idea, including some OOP languages.)
I suggest talking about which features are crucial and work well together, so we can swipe the best features of various languages and combine them into a coherent whole, rather than just kludging scripting languages together.
There's too much of a religious/propagandistic tendency for people to either say "A tool for each job", or to say "one tool for every job," rather than talking about "a handy combination of a few tools." This just leads to misunderstanding and flame wars. I for one, have never said that Scheme is the ideal scripting language. I know it's not. However, I do think some of the core ideas of Scheme are very useful and would work well in that setting. I also think something like Self might be a good start, and it's a very different language.
I also think that Tcl has some good stuff in it. What I'm trying to figure out is which features are due to simple lack of knowledge of the alternatives, and which say something fairly deep about how a scripting language should be designed.
>I represent a rabble of one that takes no prisoners! Counterthrust: >where the bleep is human-factors in this never-ending thread? Anybody >care to actually reference what little research has been done in this >area?
Not the research I know about. It's mostly baby-stuff because the main issues are hard to conduct good, controlled experiments about. (The results about how many characters of indenting are more readable come to mind as some of the *better* research, though the studies weren't thorough enough in several ways. Beyond that, you tend to get experiments that *seem* to say something basic, but it's not clear how to apply it to the richer context of real programming in real languages, or stuff that's so simplistic it's more likely wrong than right. Counterexamples very welcome.)
>I couldn't help but notice that the Ousterhout white paper had only one >reference to one measly result of human factors research; and it came >from a secondary source. I believe that ALL the designers of ALL the languages >this thread is cross-posted to (and many that aren't) didn't even attempt >to study software psychology (or psycholinguistics).
I don't know if that's true of the designers of the popular languages. I know it's not true of all of the readers of this thread. (I for one, worked in HCI for a while, and studied psychology, some linguistics, and philosophy of psychology in grad school. Of course, that doesn't make me any kind of authority, though.)
I'm just saying that some of us are aware of some of the research, but it tends to be hard to interpret for a realistic context. Little studies tend to be wildly unrealistic and test absolute beginners' skills, and big ones tend to be hard to interpret because there are too many uncontrolled variables. For this stuff to be done well, there should be lots of studies at various granularities, which will inevitably support quite a few conflicting conclusions. Only then will people get a better idea of which questions to ask, to show *why* some things turn out one way, and other work out in other wasy. That's the way work in psychology tends to go, because it's an intrinsically difficult, multi-leveled subject.
>NOTE TO LISP AND FORTH FANS: one important reason your languages >have never caught on may be due to the fact that many natural languages >follow the "subject verb object" form. Usage of SOV, OSV, VSO, and VOS >are less likely (I don't have any references in front of me; if anybody >wants details, I'll try to locate what I have).
I think this is mostly a red herring, but maybe not entirely. First, different natural languages tend to vary wildly in the orderings of terms. Consider French and Spanish postfix adjectives vs. English prefix adjectives. Which is better? Hard to say. And look at basic sentence structure in English. Often we force things into our "normal" syntax when it makes no particular semantic sense, and end up with funny constructions that confuse non-native speakers.
With respect to SVO structure, I think there's a good argument that VSO is more natural for English speakers because in programming languages we're often writing imperative sentences, e.g., "Put [ the ] cat [ on the ] mat" is more familiar than "Cat put [yourself] on [the mat}".
The latter makes some sense in Smalltalk, where it's assumed there's a privileged receiver of the message, and that we really are telling the cat to put itself on the mat. But some things don't fall gracefully into that framework, which is why some OO languages now have generic functions (or multimethods, which is essentially the OOP term for the same thing). Often method selection depends on more than one argument, because the "sentence" has more than one "object". (If your language doesn't support that concept, you may have to kludge it.)
The difference isn't usually crucial, because putting the action (or function name) first often tips you off to facts about the arguments. e.g., if I say add(a,b) or (in Lisp syntax) (+ a b), once you see the operator you can guess that the operands are things it makes sense to add.
A major difference between computer
>They also lack visual >redundancy (they aren't alone in this short-coming of course).
I think this problem is largely due to bad teaching. (Especially in programming language courses where neither the teacher nor the writer of the textbook understands Lisp/Scheme style.) The visual redundancy in Lisp and Scheme comes largely from the indenting, so you really have to teach/learn good indenting to be able to read the code visually. Indenting is important anyway, in any language, so it should be taught regardless, but it's crucial in Lisp/Scheme, so learners need to know the rules and know what they signify.
On the other hand, I do allow that Lisp and Scheme have fewer visual irregularities than other languages. I'd like to point out, though, that this is largely a choice by Lispers and Schemers. You could build a language based on Lisp/Scheme technology with a more conventional syntax, and more redundant keywords. For example, it's trivial to redefine if so that instead of writing
(if (< a b) a b)
you could write
(if (< a b) a else b)
Note that in Scheme we don't have to write returns, because everything's an expression. We don't have to use returns to return a value. So where in a C-influenced language like Java or Tcl we might write something like
proc min(a, b) { if (a < b) return a; else return b; }
In Scheme we'd write
(define (min a b) (if (< a b) a b))
If you wanted a more conventional syntax, you could add infix operators as well as extra keywords, and make it look pretty much like C or Tcl. (If we really want terseness, we can use a C-like ternary operator instead of if. In a Scheme-like language if works just like the ternary operator AND if, because everything is an expression that returns a value, but which may have side effects.)
Common Lisp and many Schemes also have keyword arguments, too, as was shown earlier in this thread by translating Ousterhout's Tcl/Tk example into Common Lisp. So if you want more redundancy and terseness within a basically Lisp-like framework, you can easily get it.
By slapping a conventional-syntax parser on Scheme, and changing a few keywords, you can get a version of Scheme with a syntax like this:
proc min(a, b) { if (a < b) then a; else b; }
or this:
proc min(a, b) (a < b) ? a : b;
depending on how much of a terseness fanatic you are.
-- | Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wil...@cs.utexas.edu) | Papers on memory allocators, garbage collection, memory hierarchies, | persistence and Scheme interpreters and compilers available via ftp from | ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)
> The only benefit you claim for Tcl that doesn't also apply to scheme > is #3. You would like to type...
> func arg1 arg2 > instead of > (func arg2 arg2)
> Ok, a minor but perhaps valid point if you want dumb users to use it > like a shell.
>And then, he goes on to suggest ways to make Scheme do that.
>What I was expressing with my point #3 was a psychological effect, and >it extends to functions written in the language as well as individual >commands, though I notice it most when typing commands interactively.
This is understandable. How to you feel about scripting languages that have a more C-like syntax, so that you'd write
func(arg1, arg2)
except when emitting a command to the operating system?
(I'd think that for tiny programs which mostly communicate with the UNIX shell, the shell-like syntax might be preferable, but for non-tiny scripts which mostly invoke other scripts, you'd want a more familiar programming-language-like notation. (The called scripts which may be written in a foreign language, but not require a call out to the OS to start a new process).
>I also prefer
> if {$x < 3} { > foo arg1 arg2 > } else { > bar arg3 arg4 > }
Disregarding the parenthesis issue and the infix vs. prefix issue (which can be solved with a simple parser on top of something like Scheme), how do you feal about the $x substitution thing?
Would you rather be able to write something like
if (x < 3) foo(arg1,arg2) else foo(arg3,arg4);
(maybe without the commas, but where you don't have to remember to force the evaluation of x in the condition?)
>I confess, though I've toyed with Lisp and Scheme in the past, I'm >primarily a C programmer. Most of the people I work with are C >or C++ programmers. The Tcl version gives us warm fuzzies, and >the Scheme version doesn't.
Understandable. Familiarity can be significant, especially in the beginning. (Personally, I found Tcl and Perl's evaluation rules mystifying in the beginning.)
>I did a web search yesterday, and found a couple of Scheme >implementations which would probably work as well for my purposes as >Tcl, except for the psychological issues I mention. If I were >starting over, though, I'd still pick Tcl.
Is this because you like programming in a shell style (e.g., don't mind having to force evaluation by controlling substitution) or because Scheme syntax is unfamiliar in other ways?
>It's plenty good enough, >and it "feels" better to me. Frankly, that's what's important.
That's understandable, too. What I'm trying to figure out is which issues are the most important in overcoming resistance to things like Scheme and Smalltalk.
-- | Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wil...@cs.utexas.edu) | Papers on memory allocators, garbage collection, memory hierarchies, | persistence and Scheme interpreters and compilers available via ftp from | ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)
With a mighty <19970418.79D47D0.8...@contessa.phone.net>, bouncen...@contessa.phone.net uttered these wise words...
> Unfortunately, there are people using lesser platforms that don't have > or only recently acquired these facilities, so they can't do that. :-)
That's exactly my point. If MS can do it, so can lots of other presumably more talented people. Am I the only one who thinks that this will be a big win? Actually, I think that's an understatement. I'm predicting that it'll be a _massive_ win.
> And some people just like arguing about religious issues.
Alas. No wonder MS get ahead - they steamroller along, ignoring the religious issues, and just _do it_. No wonder so many people feel a need to slag them off. I'm one of them, BTW, so I'm criticising myself! Was this what Richard P. Gabriel's "Lisp: Good News Bad News How to Win Big" was about? Well, he didn't mention MS, but I guess they're way of doing things is closer to "MIT" than "NJ". <URL:http://www.ai.mit.edu/articles/good-news/good-news.html>
> > I don't see why MS and Windows developers - and users - should be the > > only people to benefit from this fine idea.
> They aren't. Like I said, I (and a few million others) have had the > benefit of this functionality for most of the last decade.
Has Guile been around for that long?
> It appears that Unix may get such a solution in the form of > applications that support JVM as a scripting mechanism. This allows > any language that can be used to produce JVM bytecodes to be used for > scripting. There may be technical problems with this solution, but > it's a start.
<sigh> Yet Another Language Specific Solution. Please note that Activex isn't dependant on a single language. You don't have to use JavaScript to appreciate ActiveX. It'll work with _any_ language that's available as an ActiveX script engine.
I'm sure that something similar _could_ be done for Unix, but I've not yet heard of it. Guile is close, but no cigar. Of course, if nobody complains about using Scheme as the "VM", then there's no problem.
However, ActiveX Scripting doesn't use a VM. That could be a big limitation, but the only working (note: I didn't say "workable") alternative right now is the JVM, which apparently has a few disadvantages for some languages. ActiveX Scripting doesn't suffer like this, altho it is (currently) dependant on Wintel. The ideas could be a lot more portable than the technology itself, which is why I wonder if something similar could be done for other platforms.
Think it as introspection. ActiveX Scripting adds enough introspection to allow the scripting language to be completely decoupled from the app that uses it. That gives the developer and the user a lot of of leaverage, and without sacrificing any performance, nor leaving any room for language politics to get in the way of using it. Neither Guile nor the JVM have that advantage, but perhaps this can change.
Meanwhile, MS steamroller ahead. Who can blame them? They set a goal, they achieve it, and everyone else eats their dust. In the case of Bill Gates' "Basic for scripting everywhere", I think that it took 10 something like years or more to achieve, but now it's here. It would be naive to pretend that people won't exploit it, or that it won't big a big win. It's such a simple idea, so only the "not invented here" attitude can stop anyone else from using it.
Unfortunately, that's been an effective block to progress for many years. (Who remembers ACE?) If technical superiority really does count, then please forget the political crap and just _do it_. You can argue all you like about which language is "best" _after_ you've saved the world...
> If you're really interested, I started working on a TCP/IP solution > for this kind of thing a while back. It got aborted by a corporate > takeover, but I may still have the groundwork somewhere (if not, the > critical parts are easy to recreate).
Good luck. -- <URL:http://www.wildcard.demon.co.uk/> You can never browse enough Martin Rodgers | Programmer and Information Broker | London, UK Please note: my email address is gubbish.
>{ courtesy copy emailed to ous...@tcl.eng.sun.com , jo...@cnet.com} >-------------------------------------------------------------------------- ------------------------------- >Someone who claimed to be John Shen <jo...@cnet.com> wrote: >>Dear Professor O, >> Please get back to doing your good work and gently ignore them. >>I must say that your paper (which undoubtedly can be improved in many >>ways) truly has had an enormous impact on all the programmers/project >>leaders as I have not seen that much discussions on any other topic >>recently in so many programming groups.
>I personally was favorably affected by Prof O's paper. >Sure, it may not be a literary or a CS masterpiece, but it certainly >provided food for thought.
Tastes vary. Many of us already knew the almost all of the stuff in the whitepaper, had questions about them, and were left unsatisfied, or even with a bad taste in their mouths.
Ousterhout's notion of "scripting" vs. "systems" programming is a very limitied view, and many of us think it's not right---there can be languages that can be good for both "systems" and "applications" programs, and there are languages that can be good for both "applications" and "systems" programming. Unfortunately, the split that Ousterhout has chosen just happens to be the one that makes Tcl look best.
It's also the one that appeals to C programmers, who are sick to death of using a systems programming language as an applications programming language. Mightn't it be better to use a convenient, interactive language most of the time, and only write the most time-critical or system-dependent code in C?
It's interesting that many Tcl programmers are using Tcl as one could Lisp or Smalltalk. They're not hitting themselves in the head with a big rock (C development style) as often as they used to. Instead they're hitting themselves with a smaller rock (Tcl's limitations) most of the time. In some sense, Lisp has won, after being shunned by macho C programmers for so long. ("We don't need no steenking command-loop, we've got compilers! And we write FAST code!")
Often the reason that Tcl seems like the right language for the job, even one it's not designed for, is just that C is the wrong language for the job.
>>Languages like >>Perl and Tcl (well, I cannot help putting Perl ahead of Tcl :-) have >>been looked down upon by some as tools to craft quick-and-dirty >>solutions, yet their successes in mission-critical projects >>contradicts such views (actually they can be used for the full >>spectrum from q&d to enterprise-level applications, which is the >>beauty of it all).
As I've said before, languages like Tcl should in fact embarrass the academic programming languages community, which has generally had tunnel vision with respect to gluing.
>His clear accounts of the gluing vs systems programming paradigms >were "worth the price of admission ".
I think that the general idea has some truth to it, but Ousterhout presents it in such a way that it misleads many of his readers. Mostly by omission, he makes it sound as though the design of Tcl followed rationally from the problem domain, which many knowledgeable people doubt. Some of the language features are obviously a good idea, but the guts of the language seem poorly motivated.
I, for one, had hoped we could get to a point where we'd talk about design choices in programming languages, and how they'd interact, rather than just flaming back and forth about whose language was better.
>Perhaps he didn't mention your or my currently favorite languages, ( >eg: Perl in your case, Python in mine ) but that was not the point of >the paper.
No, it wasn't, but he also didn't mention programming language design alternatives, such as lexical scope, conventional dynamic typing, closures, objects, and garbage collection. People have been doing scripting of some sort in languages with various combinations of those features for a very long time. Are they irrelevant?
By neglecting to mention language *ideas* that are relevant, as well as seminal languages, and by strongly pushing a false dichotomy, Ousterhout wrote a paper that sounded to some people like more biased marketing hype rather than interesting discussion of important issues.
If Ousterhout had taken the line that "Tcl is a warty, limited language, but it has momentum so let's go with it," fewer people would have objected. But by what he stresses, and omission, he makes Tcl sound better than it is, and like it has not only momentum but righteousness. He stakes out the ground of a good language designer who's invented a New Kind of Language.
>Read, learn and move on....
Exactly. But to learn what's important, you have to understand basic things, so that you can compare them properly, and know what lessons to take with you.
I'm a language designer, and I don't know what to make of Tcl. I think Ousterhout's a very smart guy, and I have immense respect for much of his work in other areas. When it comes to Tcl, though, I often can't distinguish between his technical smarts and his marketing smarts. I don't know what to learn from Tcl other than that "Tk and glue are real handy."
Arguments from popularity and size of extant programs can have some merit, but remember that there are programs in COBOL that are millions of lines long, and that well after UNIX became fairly popular, MS-DOS was by far the most popular OS in the world. None of that convinces me that COBOL and MS-DOS are Good Things. The fact that it's possible to use something for a nontrivial task doesn't make it a good idea. The fact that many people do so doesn't make it a good idea, either.
Simple personal testimonials don't quite cut it---unless there is a description of the advantages of that tool, and *how* the tool works well when you'd think it'd be lacking a crucial feature. An argument like "we don't need no steenking records, because I wrote 100,000 lines of Tcl and it worked!" The same goes for millions of lines of COBOL and FORTRAN, and IBM 360 assembler. Unless we're told how it was done, and why doing it that way is better than doing it some seemingly better way, we don't know how to learn from it. -- | Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wil...@cs.utexas.edu) | Papers on memory allocators, garbage collection, memory hierarchies, | persistence and Scheme interpreters and compilers available via ftp from | ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)
With a mighty <kig912fjgfs....@jagor.srce.hr>, hnik...@srce.hr uttered these wise words...
> I don't know about you, but I certainly don't recognize MS here.
Oops, I meant to say that they're closer to the "NJ" camp. Thanks for pointing out my (obvious) error. It's one of those boolean "off by one" errors...
I guess my intended meaning wasn't clear enough. Sorry for the confusion. I've untrimmed the newsgroups list, so that my correction will reach anyone who read the article that we're refering to. Followups are set to comp.lang.lisp.
Many thanks. -- <URL:http://www.wildcard.demon.co.uk/> You can never browse enough Martin Rodgers | Programmer and Information Broker | London, UK Please note: my email address is gubbish.
On 18 Apr 1997 19:34:38 GMT, c...@cs.umd.edu (Charles Lin) wrote:
> The argument I've read is (1) numbers can be used to represent >any other (countable) type through Godel enumeration, and (2) computers >use numbers to represent things underneath. The challenge is this. >You are to write a language for users to use. I give you one type >that you will give to the user to use. Would your users prefer >strings or numbers? I'm not talking about internal representation. >Do I think everything should be strings in a language. Personally, >no, but given the above, how would you have answered it?
Actually, I think they'd prefer audio samples instead of either...
"Let X equal Y plus one, write X to the screen, then for every element E of list B, write E to the screen, end loop."
ABW -- "Plug and Play support: WfEWAD will autodetect any installed Nuclear Arsenals, Laser Satellites, Battlefield Control Networks, Radar Installations, Fighter Squadrons, and other WfEWAD compliant devices, including the new Macrosoft Unnatural Keyboard, with full support for the now-famous Big Red Buttom(tm)."
(Windows for Early Warning and Defence User's manual P26)
One of the most common criticisms of my white paper has been that the distinction between scripting and system programming is artificial, and that it is possible for a single language to be good at both tasks. Lisp-like languages such as Scheme were suggested as living proof. I can't prove that it's impossible for a single language to be good at both scripting and system programming, but I don't know of a good example and I doubt that it will ever happen. The reason for this is the difference in typing, as I explained in the white paper. A given language embodies a particular style of typing, which can range from very strongly typed to totally untyped. Once that decision has been made, the language's position on the spectrum between system programming and scripting is set. I think it's possible to have a language that's in the middle, but it's not likely to be terrific at either task.
Let's take Lisp as an example. I think that Lisp falls somewhere between scripting and system programming. Many of you have suggested that it is an ideal language for both system programming and scripting, but I think that it isn't really very good for either. In fact I suspect that this may be why Lisp hasn't been used much for practical programming. Lisp isn't a good system programming language because it's too hard to write efficient programs in it and it doesn't provide good low-level access to machine facilities. On the other hand, Lisp isn't good for scripting either. In order to be a good scripting language, you need to be able to interoperate with lots of other things, which are often written in other languages (the best glues are those that stick to lots of different materials). But Lisp has never been very good at this. For example, it's hard to include C code with Lisp because they have very different data types and memory models. Lisp systems are typically closed: you have to live entirely in the Lisp world. Good scripting languages are open and friendly: they talk to and work with everything.
Just to short-circuit the discussion that will ensue...
I'm sure that many of you will argue against these claims ("my new version of Scheme is just as fast as C", "Lisp just needs a new garbage collector that embodies the latest techniques", "I know someone who combined C with Scheme and had no problems at all", etc.). However, I've seen a fair amount of evidence on this and the problems far outnumber the success stories. Many of the best minds in Computer Science have worked on Lisp over the last 30 years, and they haven't been able to fix the language so that it could be widely used either for system programming or scripting tasks. This says to me that there is something fundamentally wrong with the language, at least for these tasks.
By the way, I think that Lisp is a fascinating language with neat mathematical properties. It's great for a variety of meta-programming tasks where you're experimenting with new programming paradigms, such as AI and language theory. It just isn't good for system programming or scripting. This reinforces my claim that you should use different tools for different tasks. This is also why I didn't mention Lisp in the paper. The things I discussed in the white paper aren't the things that Lisp was designed for or that it does best, so it isn't really fair to compare Lisp along those dimensions.
* John Ousterhout | The reason for this is the difference in typing, as I explained in the | white paper. A given language embodies a particular style of typing, | which can range from very strongly typed to totally untyped.
I get the impression that John Ousterhout does not understand what "dynamic typing" means. "untyped" is recurring in his articles and his paper. apparently, the concept that an object has type information, not the variable that holds it, is hard to grasp for many programmers in the C tradition. yet, unions with type tags are common. now, of course, a C programmer would shudder at the very idea of using a union with a type tag, so let's just say that this is well optimized in Lisp implementations, often with support from the hardware. (yes, CPU's _do_ have instructions that C compilers don't use.)
| Let's take Lisp as an example. I think that Lisp falls somewhere between | scripting and system programming. Many of you have suggested that it is | an ideal language for both system programming and scripting, but I think | that it isn't really very good for either. In fact I suspect that this | may be why Lisp hasn't been used much for practical programming.
there are many reasons why Lisp has not become popular. they have all been hashed out quite extensively over the years. yours is totally new. it is safe to say that with the criticism presented to you that your distinction between scripting and systems programming language is artificial, the fact that you're the first to find this reason for Lisp's lack of use is actually an argument _against_ your (artificial) distinction. or proof of incredibly sloppy thinking on your part. perhaps both.
| Lisp isn't a good system programming language because it's too hard to | write efficient programs in it and it doesn't provide good low-level | access to machine facilities.
I have criticized the use of "Lisp per se" in comp.lang.lisp, as it seems that "Lisp" means some sort of proto-Lisp to many people, including you. since there is no such language, any discussion of Lisp that fails to be precise in which Lisp it discusses is literally devoid of meaning. that you draw wide-ranging conclusions about an unspecific language is perhaps significant, perhaps not. in either case, it is disconcerting that you don't bother to be specific.
| For example, it's hard to include C code with Lisp because they have very | different data types and memory models.
this is getting quite amusing...
| Just to short-circuit the discussion that will ensue... | | I'm sure that many of you will argue against these claims ("my new | version of Scheme is just as fast as C", "Lisp just needs a new garbage | collector that embodies the latest techniques", "I know someone who | combined C with Scheme and had no problems at all", etc.).
this is the most ignorant nonsense I have ever seen anyone who pretends to be serious has ever written! if this is the best John Ousterhout can do when he researches something, there's no _wonder_ Tcl is the way it is!
have you even _seen_ a Common Lisp compiler, John Ousterhout?
| However, I've seen a fair amount of evidence on this and the problems far | outnumber the success stories.
why should anyone trust you on that?
| Many of the best minds in Computer Science have worked on Lisp over the | last 30 years, and they haven't been able to fix the language so that it | could be widely used either for system programming or scripting tasks. | This says to me that there is something fundamentally wrong with the | language, at least for these tasks.
the saddest, but still quite amusing, part of this ranting is that you rely on the reader's acceptance of "widely used" to justify your arguments, yet have made no distinction between, e.g., Bill Gates' beloved BASIC and Tcl. Tcl is clearly a phenomenal failure compared to BASIC. how can you have the _gall_ to argue that Tcl is widely used and that Lisp is not if you don't even consider "widely used" relative to their "markets"?
| By the way, I think that Lisp is a fascinating language with neat | mathematical properties. It's great for a variety of meta-programming | tasks where you're experimenting with new programming paradigms, such as | AI and language theory. It just isn't good for system programming or | scripting. This reinforces my claim that you should use different tools | for different tasks. This is also why I didn't mention Lisp in the | paper. The things I discussed in the white paper aren't the things that | Lisp was designed for or that it does best, so it isn't really fair to | compare Lisp along those dimensions.
again, why should anyone trust your judgment on this? you are clearly unable to recognize the simple fact that you don't know Lisp in practice well enough to pass judgment on it. yet you make a big stink about evidence and lots of important words that carry no _precise_ meaning.
ANSI Common Lisp, and even Common Lisp the Language, 2nd edition, specify a language that is, in practice, _routinely_ compiled to code as fast as C, often faster because Common Lisp programmers use better algorithms and have more time to optimize where it is needed than C programmers.
it's _tragic_ to see that John Ousterhout is this affected by myths and general ignorance, and doesn't even know he's out on a limb.
after what I have read from John Ousterhout, I have reached the sad conclusion that he is intellectually dishonest and does not know when he no longer has sufficient information to state a conclusion and when he must be humble enough to request more information before he can do so. a highly acclaimed academic should not be _able_ to lose this ability just because he's working for a company.
Richard Gabriel's "worse is better" may even apply to people in some ways.
#\Erik -- I'm no longer young enough to know everything.
* John Ousterhout | The reason for this is the difference in typing, as I explained in the | white paper. A given language embodies a particular style of typing, | which can range from very strongly typed to totally untyped.
I get the impression that John Ousterhout does not understand what "dynamic typing" means. "untyped" is recurring in his articles and his paper. apparently, the concept that an object has type information, not the variable that holds it, is hard to grasp for many programmers in the C tradition. yet, unions with type tags are common. now, of course, a C programmer would shudder at the very idea of using a union with a type tag, so let's just say that this is well optimized in Lisp implementations, often with support from the hardware. (yes, CPU's _do_ have instructions that C compilers don't use.)
| Let's take Lisp as an example. I think that Lisp falls somewhere between | scripting and system programming. Many of you have suggested that it is | an ideal language for both system programming and scripting, but I think | that it isn't really very good for either. In fact I suspect that this | may be why Lisp hasn't been used much for practical programming.
there are many reasons why Lisp has not become popular. they have all been hashed out quite extensively over the years. yours is totally new. it is safe to say that with the criticism presented to you that your distinction between scripting and systems programming language is artificial, the fact that you're the first to find this reason for Lisp's lack of use is actually an argument _against_ your (artificial) distinction. or proof of incredibly sloppy thinking on your part. perhaps both.
| Lisp isn't a good system programming language because it's too hard to | write efficient programs in it and it doesn't provide good low-level | access to machine facilities.
I have criticized the use of "Lisp per se" in comp.lang.lisp, as it seems that "Lisp" means some sort of proto-Lisp to many people, including you. since there is no such language, any discussion of Lisp that fails to be precise in which Lisp it discusses is literally devoid of meaning. that you draw wide-ranging conclusions about an unspecific language is perhaps significant, perhaps not. in either case, it is disconcerting that you don't bother to be specific.
| For example, it's hard to include C code with Lisp because they have very | different data types and memory models.
this is getting quite amusing...
| Just to short-circuit the discussion that will ensue... | | I'm sure that many of you will argue against these claims ("my new | version of Scheme is just as fast as C", "Lisp just needs a new garbage | collector that embodies the latest techniques", "I know someone who | combined C with Scheme and had no problems at all", etc.).
this is the most ignorant nonsense I have ever seen anyone who pretends to be serious has ever written! if this is the best John Ousterhout can do when he researches something, there's no _wonder_ Tcl is the way it is!
have you even _seen_ a Common Lisp compiler, John Ousterhout?
| However, I've seen a fair amount of evidence on this and the problems far | outnumber the success stories.
why should anyone trust you on that?
| Many of the best minds in Computer Science have worked on Lisp over the | last 30 years, and they haven't been able to fix the language so that it | could be widely used either for system programming or scripting tasks. | This says to me that there is something fundamentally wrong with the | language, at least for these tasks.
the saddest, but still quite amusing, part of this ranting is that you rely on the reader's acceptance of "widely used" to justify your arguments, yet have made no distinction between, e.g., Bill Gates' beloved BASIC and Tcl. Tcl is clearly a phenomenal failure compared to BASIC. how can you have the _gall_ to argue that Tcl is widely used and that Lisp is not if you don't even consider "widely used" relative to their "markets"?
| By the way, I think that Lisp is a fascinating language with neat | mathematical properties. It's great for a variety of meta-programming | tasks where you're experimenting with new programming paradigms, such as | AI and language theory. It just isn't good for system programming or | scripting. This reinforces my claim that you should use different tools | for different tasks. This is also why I didn't mention Lisp in the | paper. The things I discussed in the white paper aren't the things that | Lisp was designed for or that it does best, so it isn't really fair to | compare Lisp along those dimensions.
again, why should anyone trust your judgment on this? you are clearly unable to recognize the simple fact that you don't know Lisp in practice well enough to pass judgment on it. yet you make a big stink about evidence and lots of important words that carry no _precise_ meaning.
ANSI Common Lisp, and even Common Lisp the Language, 2nd edition, specify a language that is, in practice, _routinely_ compiled to code as fast as C, often faster because Common Lisp programmers use better algorithms and have more time to optimize where it is needed than C programmers.
it's _tragic_ to see that John Ousterhout is this affected by myths and general ignorance, and doesn't even know he's out on a limb.
after what I have read from John Ousterhout, I have reached the sad conclusion that he is intellectually dishonest and does not know when he no longer has sufficient information to state a conclusion and when he must be humble enough to request more information before he can do so. a highly acclaimed academic should not be _able_ to lose this ability just because he's working for a company.
Richard Gabriel's "worse is better" may even apply to people in some ways.
#\Erik -- I'm no longer young enough to know everything.
> NOTE TO LISP AND FORTH FANS: one important reason your languages > have never caught on may be due to the fact that many natural languages > follow the "subject verb object" form. Usage of SOV, OSV, VSO, and VOS > are less likely (I don't have any references in front of me; if anybody > wants details, I'll try to locate what I have). They also lack visual > redundancy (they aren't alone in this short-coming of course).
Best quote on this topic I've read lately
The use of the Chomsky formalism is also responsible for the term "programming language", because programming languages seemed to exhibit a strucure similar to spoken languages. We believe that this term is rather unfortunate on the whole, because a programming language is not spoken, and therefore is not a language in the true sense of the word. Formalism or formal notation would have been more appropriate terms.
Niklaus Wirth
In Wirth's opinion, and the opinion of many reputable linguists like Steven Pinker, the analogy betweem formal notations :-) and human languages is bogus. "Spoken" is the key point to consider.
