pierson@mist (Dan Pierson) (12/29/88)
In article <eWbWj#4OkIf8=eric@snark.UUCP>, eric@snark (Eric S. Raymond) writes: > The European `bondage-and-discipline' school of >language design (the people who brought you Algol-68, Pascal, Modula, Ada, and >Modula-2 and are now having yet another try at getting their mistakes right in >Modula-3) ... Not to start a flame war over this matter of taste, but a couple of points: 1. I personally think that "they" may finally have gotten it right with Modula-3. While the standard modules may need a bit more work, neither C nor C++ appeared at birth with complete standard libraries. I think that world really needs a strongly typed language that is powerful, flexible, and efficient enough for production use while remaining portable and simple enough to be comprehensible and implementable. I know it's heresy, but C is neither the most portable language around nor an all-around ideal language. There are many areas in which a safer language is better. While I'd miss the conciseness of C, I simply don't understand people who feel that being force to adhere to their own type abstractions intolerably cramps their style. My experience is that all well written programs have a well (but maybe not explicitly) defined set of data types anyway, strongly typed languages simply protect against careless errors using these types. 2. "They" are neither European nor the same folks. The Modula-3 design team is more closely related to the people who created the Xerox Parc set of B&D languages which culminated in Cedar. This is good both because Cedar looked like a very interesting system (the closest an Algol-descended imperative language has gotten to a Lisp environment) and because Wirth wasn't the designer. Wirth has a history of designing 80% of a language and setting it free; the Modula-3 team made a serious attempt to design the whole thing before releasing it. -- dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@multimax.encore.com
eric@snark.UUCP (Eric S. Raymond) (12/30/88)
In article <4509@xenna.encore.com>, pierson@mist (Dan Pierson) writes: > In <eWbWj#4OkIf8=eric@snark.UUCP>, eric@snark (Eric S. Raymond) writes: > > The European `bondage-and-discipline' school of language > >design (the people who brought you Algol-68, Pascal, Modula, Ada, and > >Modula-2 and are now having yet another try at getting their mistakes right > >in Modula-3) ... > > Not to start a flame war over this matter of taste, but a couple of points: > > 1. I personally think that "they" may finally have gotten it right > with Modula-3. Time will tell. The track record of its predecessor languages is not encouraging -- each (with the possible exception of Pascal) was touted as "they finally got it right" and all turned out to be botches of varying degrees of dreadfulness. I expect Modula-3 will turn out to be more of the same. Wanna start a pool on the announcement date of Modula-4? > While the standard modules may need a bit more > work, neither C nor C++ appeared at birth with complete standard > libraries. True, though C++ comes close -- after all, it can use C libraries. > I think that world really needs a strongly typed > language that is powerful, flexible, and efficient enough for > production use while remaining portable and simple enough to be > comprehensible and implementable. I agree. That language is called C++ -- or, if you value "safety" a bit higher, Eiffel. > I know it's heresy, but C is > neither the most portable language around nor an all-around ideal > language. There are many areas in which a safer language is > better. Again, I agree. That's why I'm watching Eiffel closely. > While I'd miss the conciseness of C, I simply don't > understand people who feel that being force to adhere to their own > type abstractions intolerably cramps their style. Ah. Now we come to the crux of the matter. My gripe with the B&D languages isn't "strong typing" -- I *like* strong typing. I write in ADT style myself (you must have seen my mildly evangelistic postings on the virtues of abstract data type programming in comp.lang.c!). My problem with B&D languages is that they have strong typing *with no escape mechanism* -- and no way to represent the 'real' machine-level entities needed for systems programming. And primitive data type sets poorly matched to real- world application programming on real-world machines. C's great virtue -- the one that makes me a fan despite its obvious flaws -- is that for a large class of machine architectures and problems it gets the trade- off between cleanness of type abstraction and fit of primitives to architecture *right*. It was brilliant of Thompson and Ritchie to understand those issues as well as they did; and in teaching that understanding to the world, I think they advanced language design far more than the B&D languages have. For another example of similar strengths, consider LISP -- also a `minimalist' language based on an astute choice about fit-to-architecture; also, like C, enduring and adaptable because its `open world' type paradigm has left it room to evolve. The thing that makes a 'bondage & discipline' language B&D is that there is *no esacape* from whatever paradigmatic shortsightednesses got built in. Other characteristic-of-breed problems like impoverished control structures, verbosity, and the kind of chrome-and-tailfins featuritis you see most developed in ADA are symptoms of the same basic problem; B&D-language designers are all by definition arrogant enough to have believed that *their* programming paradigm, *their* primitive data type set, *their* preferred style of algorithm representation is the One True Way before which all mere mortals should bow down in awe. > My experience is > that all well written programs have a well (but maybe not > explicitly) defined set of data types anyway, strongly typed > languages simply protect against careless errors using these types. I agree with this as far as it goes, but `strongly typed' isn't the issue here. The issue is whether the kind and level of type protection you get is the *designer's* choice or *your* choice! > 2. "They" are neither European nor the same folks. The Modula-3 > design team is more closely related to the people who created the > Xerox Parc set of B&D languages which culminated in Cedar. O.K. Perhaps there's hope for Modula-3 yet. There are some interesting ideas in the Cedar family, and I agree with your assessment of it. However, I feel that history justifies a certain skepticism and even cynicism on the issue. After all...who *needs* another conventional (that is to say, Algol/FORTRAN/ BASIC-descended) procedural language right now? I think it's clear that the expressive potential of such languages has been pushed to its limit already; the action now is in second-generation OO languages like C++ and Eiffel, or in more exotic areas like pure-functional or non-procedural languages. Perpetrating yet another conventional B&D language on the world seems to me to be a silly waste of time at best, much like announcing the ultimate buggy whip when everybody knows automobiles are the coming thing. We already know how to do better! -- Eric S. Raymond (the mad mastermind of TMN-Netnews) Email: eric@snark.uu.net CompuServe: [72037,2306] Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718
mccalpin@loligo.fsu.edu (John McCalpin) (12/30/88)
In article <eZCUN#34OkqV=eric@snark.UUCP> (Eric S. Raymond) writes: >My problem with B&D languages is that they have strong typing >*with no escape mechanism* -- and no way to represent the 'real' ^^^^^^^^^^^^^^^^^^^^^^^^^^ >machine-level entities needed for systems programming. And primitive >data type sets poorly matched to real-world application programming >on real-world machines. Attacking this problem was one of the major goals of the Turing language recently reviewed in the Communications of the ACM.... I know that some Turing people read this group - any comments? >After all...who *needs* another conventional (that is to say, Algol/FORTRAN/ >BASIC-descended) procedural language right now? I think it's clear that the >expressive potential of such languages has been pushed to its limit already; Although I agree that the expressive potential of Algol-style procedural languages has already been "expressed", it has not done so in a *single* language (with the possible exception of Algol-68 :-)). I work in the field of high-performance scientific computing, and I have no trouble claiming that there does not exist a "good" scientific programming language for vector and parallel architectures. There is no reason why it cannot be done in the good old Fortran or Algol styles, it just has not been done yet. What I want is a strongly-typed procedural language that: (1) understands data structures; (2) provides an expressive and concise array syntax; (3) allows for user specification of the precision of variables and constants in some machine-independent manner; (4) allows specification of data-dependencies to aid coarse-grain parallelization; (5) exists and produces good code on CDC/ETA and Cray supercomputers, and on my IRIS workstation :-) ! Perhaps something like the Fortran-8X extensions added to a Pascal-like base language.... > Eric S. Raymond (the mad mastermind of TMN-Netnews) > Email: eric@snark.uu.net CompuServe: [72037,2306] John D. McCalpin mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu mccalpin@fsu (BITNET or MFENET) SCRI::MCCALPIN (SPAN)
pierson@mist (Dan Pierson) (12/31/88)
In article <eZCUN#34OkqV=eric@snark.UUCP>, eric@snark (Eric S. Raymond) writes: It looks like we agree much more that I thought. >> I think that world really needs a strongly typed >> language that is powerful, flexible, and efficient enough for >> production use while remaining portable and simple enough to be >> comprehensible and implementable. > >I agree. That language is called C++ -- or, if you value "safety" a bit >higher, Eiffel. I like C++ too. The only bad thing about it is that it seems so destined to succeed big that reasonable competitors don't have a chance. Also C++ still lacks exception handling which I rate about equal to object orientation as an essential language feature. While this hole will probably be filled eventually, real implementations will lack it for some time to come. Eiffel is very interesting. It's chance of success will probably depend on whether true competitive implementations appear. Unfortunately, I can't name a single proprietary language that's made it big; probably because the entry cost is too high for it to get a critical mass of users. From recent Eiffel postings, it looks like the Eiffel folks are going for a second generation lock-out. They'll let "anyone" license the language design for free (would that include an agreement that FSF would be likely to accept?) but intend to continue developing the language and standard library under their control. This appears to make all "competitive" implementations second-class citizens who get to spend all their time playing catch-up. >Ah. Now we come to the crux of the matter. My gripe with the B&D >languages isn't "strong typing" -- I *like* strong typing. I write in >ADT style myself (you must have seen my mildly evangelistic postings >on the virtues of abstract data type programming in comp.lang.c!). Unfortunately I don't normally read comp.lang.c. I just resubscribed yesterday and noticed a number of your postings for the first time. >My problem with B&D languages is that they have strong typing *with >no escape mechanism* -- and no way to represent the 'real' >machine-level entities needed for systems programming. And primitive >data type sets poorly matched to real- world application programming >on real-world machines. In general, I agree, however note the following from page 41 of the Modula-3 spec: "An unchecked type transfer operation has the form: LOOPHOLE(e, T) where e is an expression whose type is not an open array type and T is a type." Of course, this is only available in an UNSAFE module. The assumtion, straight from Cedar, is that the vast majority of modules are SAFE and that this sort of code can be localized in special modules which are exceptionally thoroughly tested. >For another example of similar strengths, consider LISP -- also a >`minimalist' language based on an astute choice about >fit-to-architecture; also, like C, enduring and adaptable because its >`open world' type paradigm has left it room to evolve. As a Lisp developer, how can I not agree? >The thing that makes a 'bondage & discipline' language B&D is that >there is *no esacape* from whatever paradigmatic shortsightednesses >got built in. Other characteristic-of-breed problems like >impoverished control structures, verbosity, and the kind of >chrome-and-tailfins featuritis you see most developed in ADA are >symptoms of the same basic problem; I agree, one of the things that most attracts me to Modula-3 is that they succeeded in limiting themselves to a language with a 50 page readable spec. One thing the world does not need is gargantuan languages like Ada that are unreasonably difficult to teach, understand, and implement (yes, I know, and why is Common Lisp so bloated). >After all...who *needs* another conventional (that is to say, >Algol/FORTRAN/ BASIC-descended) procedural language right now? I >think it's clear that the expressive potential of such languages has >been pushed to its limit already; the action now is in >second-generation OO languages like C++ and Eiffel, or in more exotic >areas like pure-functional or non-procedural languages. I agree to the extent that I think Eiffel is one of the worthy competitors of Modula-3 (did I mention that Modula-3 also is an OO language with single inheritance and default methods?). C++ strikes me as the successor of C, and therefore not competive with either language in the design arena; it will win the commercial competition no matter what its merits are. -- dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@multimax.encore.com
boehm@titan.rice.edu (Hans Boehm) (12/31/88)
I agree with most of the points made in this discussion, but Dan Pierson included one sentence that troubles me: > Also C++ still lacks exception handling which I rate about > equal to object orientation as an essential language feature. I disagree somewhat about the importance of exception handling, but that's beside the point. I'm troubled by the view that "object orientation" (or exception handling) should be a language feature. I agree that object-oriented programming is an extremely useful methodology. But casting it in stone by directly embedding one view of it into the language design seems to be precisely what the "Bondage & Discipline" languages are about (although they of course generally did it for a less modern methodology). I would certainly agree that a language should make it easy to program using an object oriented methodology. But I would be much more convinced if this happened because the language design was sufficiently general that it could express the necessary concepts rather than because someone specifically tacked on the necessary constructs. Both classes and objects are really just tuples of things. Inheritance amounts to adding elements to a tuple. If I can't express these without adding new language constructs, isn't there something wrong with my language that has little to do with object orientation? I also wouldn't have much confidence that it could survive the next minor change in methodology. Similarly, if I want exceptions, I would be happier with first-class continuations, perhaps together with a library implementing your favorite style of exception handling, than I would be with a new language primitive. Admittedly, some of this raises incompletely resolved issues in language and compiler design (which is of course one legitimate reason for the popularity of languages like C++). But there are languages that come close to achieving these things. Scheme, as well as a variety of more experimental statically typed languages come to mind. I may have read a lot into Dan Pierson's statement that he didn't think he said. If so, I apologize. Hans-J. Boehm boehm@rice.edu
dan-hankins@cup.portal.com (Daniel B Hankins) (12/31/88)
In article <eZCUN#34OkqV=eric@snark.UUCP> eric@snark.UUCP (Eric S. Raymond) writes: >Wanna start a pool on the announcement date of Modula-4? Have a look at Oberon. Save for its omission of multitasking, it appears to be a winner. Very small language, small compiler, highly optimizing, more expressive power than C or Modula-2 while still capable of getting down and dirty with the machine. >My problem with B&D languages is that they have strong typing *with no >escape mechanism* -- and no way to represent the 'real' machine-level >entities needed for systems programming. And primitive data type sets >poorly matched to real- world application programming on real-world >machines. Modula-2 certainly *does* have an escape mechanism - type casts are perfectly legal. And the primitive data types of BYTE and WORD should take care of just about all the rest. >the action now is in second-generation OO languages like C++ and Eiffel, >or in more exotic areas like pure-functional or non-procedural languages. Ummm, OO languages are, strictly speaking, non-procedural (unless they are hybrids such as C++ or Eiffel). Nobody could accuse Smalltalk or Self of being procedural, yet they are two of the most OO languages around. But in general, I'll agree with this statement. It's really time to finish up futzing around with procedural languages and get into OO bigtime. The major problem is that there are *so* many programmers out there who have a very hard time in thinking in any but the procedural paradigm. Eiffel and Oberon might be two ways to gradually introduce the timid to the concepts of OO languages, rather like building an automobile shaped like a horse-drawn carriage, only without the horses. Dan Hankins
peter@ficc.uu.net (Peter da Silva) (01/01/89)
Dan Hankins says Smalltalk is nonprocedural. Funny, I always though 'procedural' referred to control flow. So a non- procedural language would be something like a declarative language (Prolog, for example) or a dataflow language (don't know of any offhand, apart from ladder diagrams). -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
peter@ficc.uu.net (Peter da Silva) (01/01/89)
I mentioned in the previous message that I couldn't think of any dataflow languages, off the top of my head. Of course I should be given a good swift kick for forgetting Icon here... -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
oster@dewey.soe.berkeley.edu (David Phillip Oster) (01/03/89)
Dataflow languages? Don't forget our favorite:
% cat languagelist | grep dataflow | awk '{ printf $2 "is dataflow!\n" }'
sh is dataflow!
csh is dataflow!
ksh is dataflow!
looks like dataflow to me!gudeman@arizona.edu (David Gudeman) (01/03/89)
In article <2594@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >I mentioned in the previous message that I couldn't think of any dataflow >languages, off the top of my head. Of course I should be given a good swift >kick for forgetting Icon here... Ahem. I hate to nit-pick, but my understanding of dataflow languages is that they are non-procedural languages based on something similar to circuit diagrams. Icon is an expression-based procedural language where expressions may produce multiple results under goal-directed evaluation (sort of like Lisp with more readable syntax and Prolog's backtracking mechanism). No doubt Mr. da Silva was thinking of some other language.
robert@island.uu.net (Robert Leyland) (01/03/89)
Ok folks, time to add some Worcestorshire sauce to the fire. Check out the latest issue of Communications of the ACM. It has a desciption of a language (called Turing) which escapes many of the S&M aspects of some languages, while retaining the elegance and simplicity required for minimalists. I haven't used this language, but the preview in that article certainly made me want to look for it. (If anyone has details please mail them, I'll post a follow up, inparticular I'd like either a Macintosh (MPW) or IBM PC (yech) version). One of the nicest features of the language is that it is simple enough for beginning students to pick up and learn easily, and with a defined set of extensions powerful enough to rival C in getting "close" to the machine. I also, particularly, appreciate the removal of silly requirements like semicolons at the end of statements. enough for know, rob sez check it out... References: CACM Vol 31 #12 December 1988, "The Turing Programming Language" R.C. Holt and J.R.Cordy Pp 1410- PS. anyone else notice how much better CACM has been getting recently? -- Robert Leyland - Island Graphics, 4000 Civic Ctr Dr #400, San Rafael, CA 94903 sun!island!robert - (415) 491-1000 - GEnie: r.leyland - usual disclaimers apply Utopia is a nice place to visit but I wouldn't want to live there. I'd be bored!
daveh@cbmvax.UUCP (Dave Haynie) (01/04/89)
in article <2593@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) says: > Dan Hankins says Smalltalk is nonprocedural. > Funny, I always though 'procedural' referred to control flow. Well, I'm sure he means nonprocedural, in that it's based on message passing rather than procedure calling. At least on the surface, though, they sure looks much more alike than Prolog or the like. > Peter da Silva, Xenix Support, Ferranti International Controls Corporation. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
peter@ficc.uu.net (Peter da Silva) (01/04/89)
In article <8527@megaron.arizona.edu>, gudeman@arizona.edu (David Gudeman) writes: > In article <2594@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >I mentioned in the previous message that I couldn't think of any dataflow > >languages, off the top of my head. Of course I should be given a good swift > >kick for forgetting Icon here... > Ahem. I hate to nit-pick, but my understanding of dataflow languages > is that they are non-procedural languages based on something similar > to circuit diagrams. The multiple-result feature of Icon is a non-procedural dataflow capability built on top of the procedural kernel. It's very well integrated, so it's easy to ignore, but it's really an amazing capability. > (sort of like Lisp with more readable syntax and Prolog's backtracking > mechanism). Not really that much like Lisp, but it's definitely got a lot in common with Prolog. Where it differs from prolog is that the data stream is built explicitly by a procedure rather then implied by the database. > No doubt Mr. da Silva was thinking of some other language. Nope. And we don't need to be so formal... you can call me Peter. Just not "Pete". -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
eugene@eos.UUCP (Eugene Miya) (01/04/89)
In article <27309@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >Dataflow languages? Don't forget our favorite: > >% cat languagelist | grep dataflow | awk '{ printf $2 "is dataflow!\n" }' >sh is dataflow! >csh is dataflow! >ksh is dataflow! > >looks like dataflow to me! I first heard this comparison given by Mike O'Dell (then at LBL). While the pipeline is neat (i.e., in the beginning was the pipe, and the pipe was good....), I didn't quite believe it. Time passed. Then David posted this; sorry, David. Fortunately, Jack Dennis is now working down the hall, I asked him about my gut uneasiness, and he resolved something I could not: # Date: Tue, 3 Jan 89 15:36:30 PST # From: Jack Dennis <dennis@riacs.edu> # To: dennis@riacs.edu, eugene@eos.arc.nasa.gov # Subject: Re: Question? # Status: R # # Are Unix shell languages "data flow" languages? -- Not really. They use # the notion of composing stream functions, however since the individual # func may cause "side effects" on files, I would not call them pure # functional, and therefore they are not data flow. # # -j Another gross generalization from --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov resident cynic at the Rock of Ages Home for Retired Hackers: "Mailers?! HA!", "If my mail does not reach you, please accept my apology." {uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene "Send mail, avoid follow-ups. If enough, I'll summarize."
gudeman@arizona.edu (David Gudeman) (01/04/89)
In article <2608@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <8527@megaron.arizona.edu>, gudeman@arizona.edu (David Gudeman) writes: > >> Ahem. I hate to nit-pick, but my understanding of dataflow languages >> is that they are non-procedural languages based on something similar >> to circuit diagrams. > >The multiple-result feature of Icon is a non-procedural dataflow capability >built on top of the procedural kernel. It's very well integrated, so it's >easy to ignore, but it's really an amazing capability. I guess my understanding of "dataflow" is different from yours (and since I've never studied the subject, I'm willing to admit ignorance), but Icon's multiple-result feature is definitely procedural in nature. At least it is if you would call co-routines procedural. Icon has a subset of co-routines built in to every expression in such a way that you can ignore them if you want, or you can often pretend that they are declarative. But the bottom line is that when you resume an expression for another result, that expression gets control and it can do anything it wants, from changing the value of a variable to exiting a loop to quiting the program. Example: while line := read() do { res := parse(line) | break ------------------- write(res) } The underlined portion is a generator, an expression that can produce multiple results. If the function parse() produces a result, then that result is assigned to res. However the | operator says that if the first argument does not produce a result (the function parse() may fail), then the result is the result of the second argument. If break were a value, then this value would be assigned to res. But break is a control structure that exits the loop. The net effect is that you will keep reading lines, parsing them and printing the result until end of file or you get a failure in parsing, then you will exit the loop. BTW: this is an example of a common Icon idiom: using failure as a simple exception-handling mechanism. Sort of like 0 is used in C or nil is used in Lisp, but it can't be confused with any legitimate value.
peter@ficc.uu.net (Peter da Silva) (01/05/89)
In article <2269@eos.UUCP>, eugene@eos.UUCP (Eugene Miya) writes: > From: Jack Dennis <dennis@riacs.edu> > # Are Unix shell languages "data flow" languages? -- Not really. They use > # the notion of composing stream functions, however since the individual > # func may cause "side effects" on files, I would not call them pure > # functional, and therefore they are not data flow. I can't agree. That's like saying the only lisp is pure lisp, since in pure lisp there are no side effects... only the return value of a function is used. Just because X has additional features other than those in a pure Y language, doesn't mean that X isn't a Y language. The shell and Icon are dataflow languages with side effects. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
peter@ficc.uu.net (Peter da Silva) (01/05/89)
In article <8540@megaron.arizona.edu>, gudeman@arizona.edu (David Gudeman) writes: > I guess my understanding of "dataflow" is different from yours (and > since I've never studied the subject, I'm willing to admit ignorance), > but Icon's multiple-result feature is definitely procedural in nature. > At least it is if you would call co-routines procedural. I don't. A define a procedural language as one in which all modules have a parent-child relationship with each other. I also don't classify languages by implementation details... for example, SmallTalk uses messages to pass data between procedures, but since they generally have a parent-child relationship (one calls the other) they're still procedures. Icon uses a stack to pass a stream of data between concurrently executing modules. They have a source/drain relationship. It's non-procedural. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
eugene@eos.UUCP (Eugene Miya) (01/06/89)
In summary:
I followed-up David <27309@ucbvax.BERKELEY.EDU> (who was commenting to
Peter) by asking Jack Dennis about data flow and Unix shells <2269@eos.UUCP>
since he's here (The mortal equivalent of Marshall McCullan[sp]).
Peter replies that <2626@ficc.uu.net> with the classic comment about
pure lisp (basically Jack's comment is a nitpick). Now we can go grab
McCarthy over at Stanford. I think I want to stand out of the way.
Honest, I didn't know myself. I think you guys can call send mail to one
another.
I always wondered what was supposed to happen after that scene in Annie Hall.
Another gross generalization from
--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
resident cynic at the Rock of Ages Home for Retired Hackers:
"Mailers?! HA!", "If my mail does not reach you, please accept my apology."
{uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene
"Send mail, avoid follow-ups. If enough, I'll summarize."mac3n@babbage.acc.virginia.edu (Alex Colvin) (01/07/89)
> I can't agree. That's like saying the only lisp is pure lisp, since in pure > lisp there are no side effects... only the return value of a function is > used. > > Just because X has additional features other than those in a pure Y language, > doesn't mean that X isn't a Y language. The shell and Icon are dataflow > languages with side effects. true, the shell could be called a dataflow language if it ALLOWED (not REQUIRED) you to write dataflow programs. unfortunately, it doesn't. you have to be careful about file use conflicts, such as "filter <x >x". no cycles (deadlocks). not to mention the difficulty of anything but a straight-line pipe. i'd look for something more like Lucid.
mac3n@babbage.acc.virginia.edu (Alex Colvin) (01/07/89)
does smalltalk allow computation of continuations (a` la scheme)? does icon allow a computation (expression?) to generate several unsynchronized result streams?
dan-hankins@cup.portal.com (Daniel B Hankins) (01/08/89)
In article <2630@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >I don't. I define a procedural language as one in which all modules have a >parent-child relationship with each other. I also don't classify languages >by implementation details... for example, SmallTalk uses messages to pass >data between procedures, but since they generally have a parent-child >relationship (one calls the other) they're still procedures. Hmmm. By this definition, Prolog would have to be procedural. Attempting to unify a clause results in a parent-child call to its subclauses. On the other hand, both ConcurrentSmalltalk and my language Theme would have to be non-procedural because the message sends are real message sends, not disguised procedure calls. Is this really what you meant to say? Dan Hankins
rjh@cs.purdue.EDU (Bob Hathaway) (01/09/89)
Lets please stop using the term B&D languages, this is a bad analogy and a heavily biased opinion. Maybe I can't adequately express classes or model abstractions in expression-based language X and feel similarly constrained. This shows the term 'B&D' can be applied from almost any paradigm or style of programming to any other and is semantically worthless. Lets be more precise and use unambiguous terms such as strongly, weakly, or dynamically typed languages so we don't have to type 'k' so often. rjh
gudeman@arizona.edu (David Gudeman) (01/09/89)
In article <488@babbage.acc.virginia.edu> mac3n@babbage.acc.virginia.edu (Alex Colvin) writes: >... >does icon allow a computation (expression?) to generate several unsynchronized >result streams? Yes and no. It depends on what you mean by ``unsynchronized''. Icon does allow result sequences to be liberated from their immediate context with co-expressions, so the results can be gathered at the programmer's leisure rather than in a depth-first order. But Icon doesn't support parallelism. However, there is a language based on Icon that uses generators as a basis for parallelism. Quite an interesting feature. The languages is experimental, it's not distributed or supported.
peter@ficc.uu.net (Peter da Silva) (01/09/89)
In article <13293@cup.portal.com>, dan-hankins@cup.portal.com (Daniel B Hankins) writes: > In article <2630@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >I don't. I define a procedural language as one in which all modules have a > >parent-child relationship with each other.... > Hmmm. By this definition, Prolog would have to be procedural. > Attempting to unify a clause results in a parent-child call to its > subclauses. Hmmm. Maybe there should be something in there about explicit relationships, or something. Or maybe 'procedural' is something in the mind of the programmer. A Prolog program looks more like a homogenous database... hmmm... Of course I'm not going to attempt to defend Prolog as being or not being procedural... I'm not a Prolog fan. In fact I'm pretty down on it. > On the other hand, both ConcurrentSmalltalk and my language Theme > would have to be non-procedural because the message sends are real message > sends, not disguised procedure calls. I would say any language that uses concurrency as one of its basic paradigms is pretty non-procedural. What does "Theme" look like? Personally, I'd much rather program in Concurrent C than Objective C. > Is this really what you meant to say? I don't know. It's pretty close to what I meant to say. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
eric@snark.uu.net (Eric S. Raymond) (01/11/89)
(begin half-smiley mode... In <5795@medusa.cs.purdue.edu>, rjh@cs.purdue.edu (Bob Hathaway) writes: > Lets please stop using the term B&D languages, this is a bad > analogy and a heavily biased opinion. I've promulgated the usage you're objecting to because I think it's a *good* analogy, at least good enough for semi-serious rhetorical purposes. I would be willing to switch to alternate terminology. If you prefer political obscenity to sexual reference, this libertarian would be quite happy to substitute `totalitarian language' for 'bondage & discipline language' in communicating with you. > Maybe I can't adequately > express classes or model abstractions in expression-based > language X and feel similarly constrained. Quite possibly. You're thinking of things like Backus's pure-functional language aren't you? Yes, that has the B&D nature. So does Prolog. Don't for a minute think I reserve my spleen for *obvious* examples of the breed... > This shows the > term 'B&D' can be applied from almost any paradigm or style > of programming to any other and is semantically worthless. I disagree. Perhaps you missed my original definition. To attain the B&D nature, a language must be a) wedded to some *one* 'high-level' programming philosophy known to be inadequate for general-purpose programming, and b) lack the generality or the low-level 'escape' constructs that would permit other styles of system organization. Thus, for example, APL is less hard-core B&D than, say, Prolog -- because it has a 'goto' construct that permits alternatives to the preferred applicative style (this observation should *not* be construed as a defense of goto-intensive spaghetti-coding!). > Lets be more precise and use unambiguous terms such as > strongly, weakly, or dynamically typed languages so we don't have > to type 'k' so often. *<chortle>* So, you think these terms are unambiguous, do you? I think I'll let someone else tackle *that* grand illusion! Hey, look, B&D languages have their uses. For some people. I'd be the last to try and legislate morality in the hack-room. What goes on between a consenting programmer and his or her machine is strictly their business as long as no third party is harmed. I just get annoyed when these people start evangelizing for their kinks as though they'd found the Final Solution to the Programming Problem... ...end half-smiley mode) -- Eric S. Raymond (the mad mastermind of TMN-Netnews) Email: eric@snark.uu.net CompuServe: [72037,2306] Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718
david@indetech.UUCP (David Kuder) (01/13/89)
In article <edcpu#4E04mv=eric@snark.uu.net> eric@snark.uu.net (Eric S. Raymond) writes: >Quite possibly. You're thinking of things like Backus's pure-functional >language aren't you? Yes, that has the B&D nature. So does Prolog. Don't >for a minute think I reserve my spleen for *obvious* examples of the breed... > I think your use of B&D just got too broad. Every language has a paradigm, Prologs may be other than procedural but it isn't any more constricting than C or LISP. As far as it goes, it has always struck me as freeing rather than binding. It does have a certain discipline to it but what language doesn't? Even this verdammit English stuff has rules that insure that things are understood. Speaking of *obvious* examples, what isn't a B&D language? Is there a better way of differentiating it from, for example, APL than calling one B&D? -- ____*_ David A. Kuder {sun,sharkey,pacbell}!indetech!david \ / / Independence Technologies \/ / 42705 Lawrence Place FAX: 415 438-2034 \/ Fremont, CA 94538 Voice: 415 438-2003
eric@snark.uu.net (Eric S. Raymond) (01/15/89)
In article <1226@indetech.uucp>, david@emerald.UUCP (David Kuder) writes: > I think your use of B&D just got too broad. I was *wondering* how long it would be before some nettled Prolog partisan spoke up...:-) > Every language has a paradigm, > Prologs may be other than procedural but it isn't any more constricting than > C or LISP. You couldn't prove that by me, friend -- or by half the Prolog programmers I know! This much I'll give Prolog, that it's at least compulsive about some interesting and useful ideas. More so than APL. *Much* more so than Pascal. > As far as it goes, it has always struck me as freeing rather than > binding. Well, yes -- *if* the things that you care about can be modeled by Horn clauses. The trouble is that there are lots of important things that cannot, that are intrinsically stateful/sequential/procedural. Consider I/O, for example, carefully. > Speaking of *obvious* examples, what isn't a B&D language? C. C++. Lisp. Basic. Fortran. Any assembler. These languages escape the category by including enough low-level primitives to support just about any programming style that's even vaguely procedural; of course, you may have to give up a lot of the language's expressive power to do so. Smalltalk and (possibly) Algol-68 escape the category because, although they are wedded to particular programming paradigms, they include enough power and extensibility that you can customize your way out from under the designers' assumptions if you need to. > Is there a better > way of differentiating it from, for example, APL than calling one B&D? Sure. Does a language simply *support* some bizarre and interesting way new of thinking about algorithms, or does enforce the method with such religious fervor that you can't do anything else, *even though the method is demonstrably inadequate for general-purpose programming*? -- Eric S. Raymond (the mad mastermind of TMN-Netnews) Email: eric@snark.uu.net CompuServe: [72037,2306] Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718
holt@turing.toronto.edu (Ric Holt) (01/16/89)
A "puritanical language" is one in which you necessarily use only the semantics provided by the language. Turing proper is one of these languages. A "permissive language" is one in which you are allowed to access details of the underlying implementation. Turing Plus and C are such languages.
sommar@enea.se (Erland Sommarskog) (01/17/89)
Eric S. Raymond (eric@snark.uu.net) writes: >> Speaking of *obvious* examples, what isn't a B&D language? > >C. C++. Lisp. Basic. Fortran. Any assembler. These languages escape the >category by including enough low-level primitives to support just about any >programming style that's even vaguely procedural; of course, you may have to >give up a lot of the language's expressive power to do so. I must admit that I have found this discussion somewhat phoney. What is B&D must be totally subjective. To me C seems like a typical example. The programmer gets stuck in a bondage of discipline and has to think of irrelevant that a language like Ada saves him from. (Which Eric's last line also says in a way.) But to throw some new wood on the fire, consider the following: Assume you have routine you want to call but whose name you don't know until run-time, thus you have the name in a string. Now in which langauges can you easily do this? Interpreting langauges like Lisp and Basic, support this I guess. But compiled langauges? -- Erland Sommarskog ENEA Data, Stockholm This signature is not to be quoted. sommar@enea.se
pds@quintus.uucp (Peter Schachte) (01/17/89)
In article <eeuqR#3lcVcX=eric@snark.uu.net> eric@snark.uu.net (Eric S. Raymond) writes: >> Speaking of *obvious* examples, what isn't a B&D language? >C. C++. Lisp. Basic. Fortran. Any assembler. Gee, the last time I used C, the garbage collector didn't seem to work. Oh, you mean I'm BOUND to manage memory myself? I have to DICIPLINE myself to make sure I free memory I'm not using anymore? I think we need a narrower definition of B&D. Like, maybe, "a language which doesn't allow the programmer to do everything the hardware allows." Note that this definition factors in the hardware. All the langauges you mention, except assembler, would be B&D on a vector processor. APL might be a better choice on such an architecture. A while back, someone built a machine designed to do combinator reduction. On such a machine, SASL would be a good choice; on a 680x0, SASL would be pretty far from the hardware. -Peter Schachte pds@quintus.uucp ..!sun!quintus!pds
peter@ficc.uu.net (Peter da Silva) (01/17/89)
In article <4246@enea.se>, sommar@enea.se (Erland Sommarskog) writes: > But to throw some new wood on the fire, consider the following: Assume > you have routine you want to call but whose name you don't know until > run-time, thus you have the name in a string. Now in which langauges > can you easily do this? Interpreting langauges like Lisp and Basic, > support this I guess. But compiled langauges? I do this all the time in 'C', for one reason or another. Many of my interactive programs have the equivalent of this in them. It's more painful to implement this in a language without aggregate initialisation, of course. I can't imagine doing without this capability. Chopping up a line into argv/argc is an excersize left to the reader. struct { char *fname; int (*fcode)(); } funtab[] = { "fname1", func1, "fname2", func2, "fname3", func3, ... }; int nfuns = sizeof funtab / sizeof *funtab; int call(name, argc, argv) char *name; int argc; char *argv; { int i; for(i = 0; i < nfuns; i++) if(strcmp(name, funtab[i].fname) == 0) return (*funtab[i].func)(argc, argv); return 0; } -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
blarson@skat.usc.edu (Bob Larson) (01/18/89)
In article <4246@enea.se> sommar@enea.se (Erland Sommarskog) writes: >But to throw some new wood on the fire, consider the following: Assume >you have routine you want to call but whose name you don't know until >run-time, thus you have the name in a string. Now in which langauges >can you easily do this? Interpreting langauges like Lisp and Basic, >support this I guess. But compiled langauges? Info/Basic (Assuming you consider p-code languages compiled.) Most any language under Primos: Pl/I, C, FORTRAN, PMA, etc. The language does need to support procedure pointers and some way to do type punning, (or this part can be done in another language) and the routine called must be in one of the libraries in the entry$ search rules. -- Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%ais1@ecla.usc.edu oberon!ais1!info-prime-request
sam@csri.toronto.edu (Samuel Weber) (01/18/89)
In article <eeuqR#3lcVcX=eric@snark.uu.net> eric@snark.uu.net (Eric S. Raymond) writes: >In article <1226@indetech.uucp>, david@emerald.UUCP (David Kuder) writes: >> Speaking of *obvious* examples, what isn't a B&D language? > >C. C++. Lisp. Basic. Fortran. Any assembler. What!!! I am willing to admit that Lisp might not be B&D, but C and C++ are unquestionably one of the worst bondage and disipline languages around! Both of these languages force one to adhere to an artificial program/data distinction, as if there was some carved-in-stone declaration of which bytes happened to be code, and which data. If I want to write self-modifying code, and the language prevents me because the designer thought that self-modifying code was a 'bad thing', one can hardly state that the language is not totalitarian! What is especially irritating is that even though many people, such as the designers of Lisp, approved of self-modifying code, the designers of C and C++ decided to single-handedly legislate it out of existance. Conclusion: If you are going to disapprove of "B&D" languages, you should realize that you are also arguing against C and C++. -- --Sam Weber "Little Birds are bathing sam@csri.toronto.edu Crocodiles in cream, Like a happy dream: Like, but not so lasting-- (quote by Crocodiles, when fasting, Lewis Carroll) Are not all they seem!"
elg@killer.DALLAS.TX.US (Eric Green) (01/19/89)
in article <8901180542.AA20739@yorkville.csri.toronto.edu>, sam@csri.toronto.edu (Samuel Weber) says: > In article <eeuqR#3lcVcX=eric@snark.uu.net> eric@snark.uu.net >>In article <1226@indetech.uucp>, david@emerald.UUCP (David Kuder) writes: >>> Speaking of *obvious* examples, what isn't a B&D language? >>C. C++. Lisp. Basic. Fortran. Any assembler. > What!!! I am willing to admit that Lisp might not be B&D, but C and > C++ are unquestionably one of the worst bondage and disipline languages > around! Both of these languages force one to adhere to an artificial > program/data distinction, as if there was some carved-in-stone > declaration of which bytes happened to be code, and which data. If > I want to write self-modifying code, and the language prevents me > because the designer thought that self-modifying code was a 'bad > thing', Note that self-modifying code will break on most processors with seperate C-cache and D-cache. The D-cache is usually write-through, but not the C-cache. Writing code through the D-cache won't update the cached code in the C-cache. Also note that most modern operating systems (e.g. BSD4.[23]) page code directly from the object file, and share this RAM image between all instances of the running program. E.g. if you have four Emacs's running, you only have a single instance of the code segment shared amongst all four Emacsen. Self-modifying code would mean that the code segment would no longer be sharable, meaning a MUCH higher swapping/paging overhead. There are good reasons for not having self-modifying code. It is thus silly to say that a language is "B&D" for not supporting it. Re: what is NOT B&D: How about "any language in which you can write a device driver is not B&D." Unfortunately, it's just as easy to write a device driver in Pascal or Modula II as it is in "C" (although you have to use unions to do so). > especially irritating is that even though many people, such as the > designers of Lisp, approved of self-modifying code, the designers > of C and C++ decided to single-handedly legislate it out of existance. Hardware and OS designers legislated it out for efficiency reasons. Self-modifying code in Lisp runs in the D-space, and is NOT shared amongst processes. This has an obvious efficiency hit when you have ten people all on the same system running that program. -- Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 Netter A: In Hell they run VMS. Netter B: No. In Hell, they run MS-DOS. And you only get 256k.