Yep, and yep Cheers,
Alan ________________________________ From: Florin Mateoc <[email protected]> To: Fundamentals of New Computing <[email protected]> Sent: Sun, June 5, 2011 3:51:23 PM Subject: Re: [fonc] languages But wasn't APL called a "write-only language", which would make it in a way a polar opposite of Smalltalk? I agree that it is not about "consequences of message sending". And, while I also agree that uniformity/simplicity are also virtues, I think it is more useful to explicitly state that there are "things" which are truly different. Especially in an object system which models the world. Numbers would be in that category, they "deserve" to be treated specially. In the same vein, I think mathematical operators "deserve" special treatment, and not just from an under the covers, optimization point of view. Thank you, Florin ________________________________ From: Alan Kay <[email protected]> To: Fundamentals of New Computing <[email protected]> Sent: Sun, June 5, 2011 2:30:23 PM Subject: Re: [fonc] languages Check out APL, designed by a very good mathematician, to see why having no special precedences has merit in a language with lots of operators. However, I think that we should have used the standard precedences in Smalltalk. Not from the math argument, or from a kids argument, but just because most conventional routes deposit the conventions on the travelers. The arguments either way don't have much to do with " consequences of message sending" because what can be sent as a canonical form could be the abstract syntax packaging. Prolog had an idea -- that we thought about to some extent -- of being able to specify right and left precedences, but this was rejected as leading to real needless complexities. Cheers, Alan ________________________________ From: Florin Mateoc <[email protected]> To: Fundamentals of New Computing <[email protected]> Sent: Sun, June 5, 2011 11:17:04 AM Subject: Re: [fonc] languages I would object to the claim that complaints about the non-standard precedence are somehow characteristic to the culture of if( The clash is with math, not with another programming language. And it clashes with a well-established convention in math, therefore with the readability/expressibility of math formulae. Of course, a mathematician can agree that these are only conventions, but a mathematician already thinks in a highly abstract way, whereas for Smalltalk the argument was made that this would somehow help kids think more abstractly and better get the concept of precedence. But kids do not think abstractly. Furthermore, the precedence of + and * is not so much about the behavior of arithmetic operators. Regardless over what mathematical structure we define them, they are the very operators used to define the notion of distributivity, closely related to the notion of precedence. Saying that "addition distributes over multiplication" instead of "multiplication distributes over addition" is not more abstract, it just confuses the notions. We might as well start writing Smalltalk with lower caps as the first letter in all identifiers followed by all caps. aND cLAIM tHAT tHIS wILL hELP kIDS tHINK mORE aBSTRACTLY aND sEE tHAT tHE wAY wE cAPITALIZE iS oNLY a cONVENTION. As for the other operators, if they do not have some pre-defined/embedded precedence, they might as well use left to right. But the few of them that do would have warranted an exception. I was thinking recently that operators would actually be a perfect use case for multimethods in Smalltalk, and that the precedence problem is more a consequence of the lack of multimethods. Anyway for numbers the matter of behavior responsibility is also questionable. And since binary selectors are already recognized as different in the language, implementing operators as multimethods could be done with minimal impact for readability. This approach could even be extended to support multikeyword multimethods by having the first keyword start with a binary selector character. Best, Florin ________________________________ From: Alan Kay <[email protected]> To: Fundamentals of New Computing <[email protected]> Sent: Sat, June 4, 2011 2:46:33 PM Subject: Re: [fonc] languages Smalltalk was certainly not the first attempt -- and -- the most versatile Smalltalk in this area was the first Smalltalk and also the smallest. I personally think expressibility is not just semantic, but also syntactic. Many different styles of programming have been realized in Lisp, but "many to most" of them suffer from the tradeoffs of the uniform parentheses bound notation (there are positive aspects of this also because the uniformity does remove one kind of mystery). The scheme that Dan Ingalls devised for the later Smalltalks overlapped with Lisp's, because Dan wanted a programmer to be able to parse any Smalltalk program at sight, no matter how much the semantics had been extended. Similarly, there was a long debate about whether to put in "normal" precedence for the common arithmetic operators. The argument that won was based on the APL argument that if you have lots of operators then precedence just gets confusing, so just associate to the right or left. However, one of the big complaints about Smalltalk-80 from the culture that thinks parentheses are a good idea after "if", is that it has a non-standard precedence for + and * .... A more interesting tradeoff perhaps is that between Tower of Babel and local high expressibility -- for example, when you decide to try lots of DSLs (as in STEPS). Each one has had the virtue of being very small and very clear about what is being expressed. At the meta level, the OMeta definitions of the syntax part are relatively small and relatively clear. But I think a big burden does get placed on the poor person from outside who is on the one hand presented with "not a lot of code that does do a lot", but they have to learn 4 or 5 languages to actually understand it. People of my generation (50 years ago) were used to learning and using many syntaxes (e.g. one might learn as many as 20 or more machine code/assembler languages, plus 10 or more HLLs, both kinds with more variability in form and intent than today). Part of this could have stemmed from the high percentage of "math people" involved in computing back then -- part of that deal is learning to handle many kinds of mathematical notations, etc. Things seem different today for most programmers. In any case, one of the things we learned from Smalltalk-72 is that even good language designers tend to create poor extensions during the heat of programming and debugging. And that an opportunity for cohesion in an extensible language is rarely seized. (Consider just how poor is the cohesion in a much smaller part of all this -- polymorphism -- even though it is of great benefit to everyone to have really strong (and few) polymorphisms.) Cheers, Alan ________________________________ From: Julian Leviston <[email protected]> To: Fundamentals of New Computing <[email protected]> Sent: Sat, June 4, 2011 10:44:07 AM Subject: [fonc] languages Hi, Is a language I program in necessarily limiting in its expressibility? Is there an optimum methodology of expressing algorithms (ie nomenclature)? Is there a good or bad way of expressing intent? Are there any intent languages in existence? Are there any pattern or algorithm languages? Is a programming language necessarily these two combined? These are the questions I've been finding myself pondering lately. For example, expressing object oriented concepts and patterns in C, while possible, proves rather "uncomfortable". Some things are almost impossible unless one "builds a world" inside C, but this is essentially building another language and using C as the meta-platform for this language, no? This would have to do with the fact that the design intent of the language didn't have this as its original intent, surely? Is there a way of patterning a language of programming such that it can extend itself infinitely, innately? Was smalltalk the first attempt at this? Does it fail by being too "large" in structural organisation? In other words, would a "language" (or exploratory platform for programming) inherently require being "ridiculously simple" in terms of its structure in order to fully be able to represent any other "language" (or rather than language, simply more complicated structures) clearly? Is Ometa an example of this? Julian. _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
