I like both Smalltalk and APL. I disagree with the assumption that operator precedence is a big hurdle for people learning Smalltalk. At least I find mathematical expressions in Smalltalk to be clearer than their counterparts in Lisp. I like the following example:
[:n :k | (1 to: k) inject: 1 into: [:c :i | c * (n - k + i / i)]] (defn choose [n k] (reduce (fn [c i] (* c (/ (+ (- n k) i) i))) 1 (range 1 (+ k 1)))) Okay maybe they're both hard to understand; nobody said math was easy. Lisp has seen a huge resurgence in popularity thanks to Clojure. Smalltalk has also seen nice growth, although on a much smaller scale, and sadly it's not generally considered viable for enterprise software development anymore (which is generally the kind of code that matters to me, boring as it is). But math operators are a red herring. No programming language really does math well (except maybe APL). Accountants, engineers and scientists have got on well enough using whatever lets them do their calculations, but by and large these operations are a very small part of any reasonably-sized program. After spending the better part of the past year poring over a very large Smalltalk code base, I think the biggest conceptual barrier is that understanding Smalltalk code requires tools that leverage the language metadata to dynamically analyze what's going on (I'm talking about menu commands to search for senders and implementers of various methods, and similar beasts). I think these tools offer a mechanism that will eventually give you a conceptual understanding of what the code is doing. Maybe that can be formalized or be proved equivalent or superior to the explicit type information provided in more conventional programming languages, maybe not. Personally I don't think grep and javadoc are better, but the vast majority of programmers in the world must disagree with me. Type systems are for reasoning about code, whereas most programs are written with a computational intent that is generally not formalized or even formalizable. While it's nice to have programs that can be formally proved, if you can't prove that your specification is correct too, there's not much point in it. Ultimately what matters is fitness for purpose, a big part of which is social utility and communicating the intent to someone far removed from the original implementation. In short, it's the libraries and how you can manage the dependencies amongst your "units" of code that really matter most. Cheers, Steve On Sun, Jun 5, 2011 at 3:55 PM, Alan Kay <[email protected]> wrote: > 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 > > _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
