Re: [fonc] languages

Sun, 05 Jun 2011 17:40:40 -0700 

On 6/5/2011 4:48 PM, Steve Wart wrote:

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))))
both are generally hard to understand, especially for someone not already well familiar with either language. 



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.


it adds up quickly though...
a little more pain here, a little more pain there, and eventually there is pain all around. much of what is done in creating a language or API isn't really big hard problems, the vast majority is actually cutting off sharp corners and edge cases, making everything a little nicer and a little more generic, which is then done recursively (and often over many layers). 



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.
dunno... if these could be applied to aide with more conventional languages, maybe all the better.
it is worth noting though that many IDEs already do provide a lot of tools to aide with things. 



Personally I don't think grep and javadoc are better, but the vast
majority of programmers in the world must disagree with me.
many people go for tools like Visual Studio and Eclipse, which do provide a lot of niceties (auto-complete, ability to see documentation-comments and possible argument lists as tool-tips, ...).
granted, I still use grep sometimes, but mostly because I do most of my coding in C with standalone (non-IDE) tools (mostly as, IMO, IDEs often provide more drawbacks than they are worth, usually because IDEs are often not terribly flexible or customizable).
maybe 90% of the time, one can remember where the code they are looking for is located. granted, this is subject to the use of good code organization and naming practices. 

I would personally like to see an IDE which was:
more-or-less language neutral, to what extent this was practical (more like traditional standalone editors); not tied to or hard-coded for particular tools or build configurations (nearly everything would be "actions" tied to high-level scripts, which would be customizable per-project, and ideally in a readily human-editable form); 
not being tied to a particular operating system;
...



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.


yeah.
usually though, if one knows that the program works, and is "reasonably" bug free, this is sufficient.
the "extra mile", namely making code entirely bug-free, universally portable, ... is not generally worthwhile for most things (since it adds far more cost for relatively little apparent gain). 

so, most things are tradeoff...
if it crashes sometimes, but at most these are at most a minor inconvenience, or the thing will not build or work on some uncommon target, then it may well be more cost-effective not to bother (and focus effort instead on any more immediate concerns). 



In short, it's the libraries and how you can manage the dependencies
amongst your "units" of code that really matter most.



ok.



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




_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Reply via email to