All the discussion on the "Ship it with Squeak" and "Belling the cat" threads has reminded me of my more favorite use for Squeak.
There are at least two uses for programming. The common one that most people optimize for is building applications or other software to sell. The other one is "ad hoc" programming, where you use programming for yourself, perhaps for learning or maybe just demonstrating ideas (the way people sketch today). (As people I pester on the SqueakAudio list know, my current personal focus is learning computer music with Squeak.) It's not at all clear that these are similar kinds of activities or even if you'd want to use the same language for both. For the former use, you worry about code repositories, adequate documentation of your interfaces, and well factored code. For the latter...Ha! Who's going to see my code? I'm throwing it away as fast as I write it!
More seriously, the issues of how one creates an expressive, easy-to-learn, and widely-applicable programming language for the latter kind of use are not explored much nowadays. Those issues used to be hot, and programming language experts used to explore different languages that helped people in different ways. Nowadays, efficiency and provability seem to have taken over programming language conferences, which are much more former-use issues than latter-use issues. Maybe because former-use has more economic benefits than latter-use...until you get close. Then the common-daily-use market is MUCH larger than the applications market.
Andy diSessa, a longtime proponent of "Computing Literacy," tells a great story about what it takes to make programming really take off in the common-daily-use sense in his book "Changing Minds." Newton's intellectual achievement of inventing calculus to demonstrate his scientific points about motion was astounding. But Leibnitz invented calculus at about the same time, and it's his notation (the dx/dt stuff) that we use today. Why? Well, Leibnitz's notation is easier to use and it makes expressing some hard theorems almost simple. But does it matter all that much? It took almost two hundred years for Calculus to become commonplace part of the curriculum. It was in the early part of the 1900's that teachers tried to teach Calculus to undergrads, and succeeded enough that later classes assumed Calculus knowledge: it became infrastructural. But what if, Andy asks, Calculus was 10% harder? What if it was harder to teach it and people were less successful learning it? Would it have still become commonplace?
It's an interesting conjecture, but I'm not sure that I agree with it. Andy is using the story to argue that "Once we get the right notation, perhaps programming WILL become commonplace." Yet, it's clear that we are hopelessly unsuccessful teaching programming, and we still require a great many undergrads to study programming. (Everyone at Georgia Tech must take a first course in Scheme.) The fact that we are hopelessly unsuccessful teaching programming is quite well supported in research and experience. Only about 30% of the students who come out of a college-level intro to programming class know how to write a program to average positive integers, avoiding the negative ones until a flag value comes in. Only about 50% of the CS majors in their Sophomore year can write that one without screwing up the negative or flag test. (If you're a teacher, I challenge you to try this or a similar test on your own students! We just did at Tech last year, and we're all still reeling from the results.)
The part I completely agree with Andy on is that common programming languages are nowhere easy enough to learn yet, and I hope that the right notation does lead to common-daily-use. And while I applaud the efforts to come up with a Squeak that's great to write applications in (and my group would certainly use and perhaps contribute to such an effort), it's the potential for using Squeak toward that common-daily-use that I find so intriguing and daunting.
Mark -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 Associate Professor - Learning Sciences & Technologies. Collaborative Software Lab - http://coweb.cc.gatech.edu/csl/ (404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
Mark Guzdial wrote:
The part I completely agree with Andy on is that common programming languages are nowhere easy enough to learn yet, and I hope that the right notation does lead to common-daily-use.
I've been thinking myself along the lines of using Python's indentational block structuring with Smalltalk's keywords, and a minimal of punctuation to create an easy reading notation.
So in "PaulTalk" :-) notation, for example, if I understood your requirements correctly:
define MyClass>>averagePositiveIntegers: aCollection until: flag "average positive integers in a collection up to but not including a flag" |sum numPositiveValues average| sum := 0 numPositiveValues := 0 for value in aCollection if value == flag break elif value > 0 sum := sum + value numPositiveValues := numPositiveValues + 1 if numPositiveValues == 0 Dialog show: 'There were no positive values' type: #Alert ^0 average := sum / numPositiveValue ^average
Note the absense of periods which are not needed when there is one statement per line. Periods could of course be used optionally to seperate statements on one line.
You mention ease of learning. What I want personally more than anything is transparency of the system as much as possible from the high level language down to the VM and the machine code it runs. This is for political and philosophical reasons.
The thing that is nice about avoiding them or limiting them to the PocketSmalltalk sense (great job guys!) is that I could easily put this sort of system on top of a Forth based VM with a conventional stack.
Here is a VM call example which compiles easily right into something like Forth.
define Integer>>timesInteger: otherInteger "assumes double dispatching so arguments are correct types" VM push4: self byteArray. VM convertSmalltalkIntegerToNativeInteger. VM push4: otherInteger byteArray. VM convertSmalltalkIntegerToNativeInteger. VM integerMultiply. VM convertNativeIntegerValueToSmalltalkInteger. ^VM pop
Polymorphic methods (the normal case) might translate to sequences like: define Object>>send: receiver message: selector VM push: receiver. VM push: selector. VM polymorphicDispatch.
Also if you declare certain methods as non-polymorphic, perhaps making assumptions about argument types, you can flatten entire trees of "PaulTalk" method calls into a single Forth word. For numerical computations (an interest of mine for educational simulations) this might be a big win.
(Actually, since this language is a hybrid of Python and Smalltalk, it might best be called "Pytalk" or "Smallthon".).
This approach might be more easily maintainable and relatively portable, even if it is slower than an highly optimized VM system produced using a C compiler. In the system I outlined, I could trace the correspondance of every statement down to the machine code it runs.
-Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com
On Sun, 2 Jul 2000, Mark Guzdial wrote:
There are at least two uses for programming. The common one that most people optimize for is building applications or other software to sell. The other one is "ad hoc" programming, where you use programming for yourself, perhaps for learning or maybe just
It's an interesting conjecture, but I'm not sure that I agree with it. Andy is using the story to argue that "Once we get the right notation, perhaps programming WILL become commonplace." Yet, it's clear that we are hopelessly unsuccessful teaching programming, and
Just a couple of observations on this:
i. an awful lot of people write an awful lot of quick shell scripts to do simple jobs
ii. not too long ago, I knew a lot of non-computer people who wrote lots of HyperCard stacks -- this seems to have died down with the lack of backing for HypeCard
My point is, that when the tools are there - shell scripts, perl for the more technically inclined, HyperCard for the less technical - people seem to use them.
************************************************************************** Network Technology Corporation PO Box 600618 Miles R. Fidelman, President Newtonville, MA 02460-0006 mfidelman@ntcorp.com 617-558-3698 http://www.ntcorp.com fax: 617-630-8946 **************************************************************************
squeak-dev@lists.squeakfoundation.org
-
Mark Guzdial -
Miles Fidelman -
Paul Fernhout