Slashdot Mirror

Have a look at the activities of Mark Guzdial and the Collaborative Software Laboratory at Georgia Institute of Technology.

And - yes, they are using Squeak, an open source implementation of Smalltalk-80 which is lead by many of the original Smalltalk inventors including Alan Kay.

The interface that "put you off" is the original Smalltalk Human Interface. It is the same reaction that caused Apple to change that Human Interface to the one they created for their Lisa and Macintosh. Smalltalk-80Mac v0.x was one of the original Xerox License One Virtual Machines of the Smalltalk-80 image along with Dec and TI. That also means it had 100% of the source and all of the Changes as opposed to the dialects of Smalltalk that have since been derived from the code that was published in the books.

The "new" Morphic interface has been inside the image since it was renamed to Squeak and licensed by Apple as Open Source. The Squeak3.0 production release is the first to launch into a Morphic Project, and you will find the quality of the demonstration projects completely different from those in Version2. And yes... there are still some other new human interfaces hidden in the image that are being developed. Think of them as Easter Eggs, that include all of their source.

The Dolphin Education Center Information is great source of information and patterns about Smalltalk though the free version has not changed since 1998. Their document explaining the issues with the Model-View-Controller model in Squeak and the Model-View-Presenter approach used in Dolphin is an excellent explanation of both models. I am not aware of a Mvp Project being created for Squeak, yet.

• Squeak
  http://www.squeak.org/
• Dolphin 2.1
  http://www.object-arts.com/Downloads2.htm

First off Kawa exists for java. (I'm too lazy to track down the link.)

Secondly, Smalltalk has the portability of java explained in the following post. Moderate it up!

Go to computerjobs.com or whatever and do a search for smalltalk you will see that smalltalk is still used as a programming language.

Refactoring is a large part of the (deservedly) hyped Extreme Programming. Squeak(smalltalk) comes in with a built in refactoring browser. It can *automatically* refactor code. I believe it finds dupblicated code, and makes large methods smaller. Incredible.
Go to www.squeak.org and download smalltalk today.

Now to go offtopic a bit...
Finally, I'm a bit sick of the omnipresence of Java. ( flamearmor.setON() ) I know and have enjoyed the benefits of java. But I'm a little bit tired of people convincing me how great jsp pages are, javabeans, ejb etc... without knowing much about any of the alternatives. It seems like there are some great platforms out there zope/php, open-acs/tcl which allow people to build powerful flexible websites much cheaper then the java solution. Unfortunately those other ones get no coverage as Java's marketing is incredible.

here and here

nobody bothered to solve the interesting problems that Java addressed - perfect portability of source and byte codes, a single standard and just-in-time compilation

No, that isn't the case. The free Disney R&D implementation of Smalltalk, Squeak addresses these issues, in some cases profoundly better than does Java.

Indeed, Java hardly offers "perfect portability," the "write-once, run anywhere" claim is marketing hype at its best. It is, in practice, quite difficult to get identical results from any but the most trivial Java programs.

In comparison, a multimedia GUI-based application in Squeak runs pixel-for-pixel IDENTICALLY across a vast array of platforms. I wrote a video game for my wife's birthday in Squeak, complete with animation sound and graphics, from the machine at my Office, a Dell PC Laptop. I sent the image by e-mail to my home, flipped it on her iMac while she slept, fired it up, and it just worked. Identically.

On the other counts, Squeak has a JIT (plus many other nice internal features including object send caching, a sweet and super-fast generational garbage collector), and there is, in fact, an ANSI standard.

Indeed, Smalltalk's source code is virtually identical across implementations. (The syntax, which --in this sense only-- is super-elegant, can be trivially described in a handful of rules). Except for one religious issue (closures for code blocks). Differences in and interoperability problems between implementations derive primarily from the underlying framework libraries provided with those codes -- a problem hardly unique to Smalltalk.

There has been efforts, most notably the (currently inactive, I believe) static typing SIG, which would make it possible to make code that could be efficiently translated to machine code (also known as "compiling"). Static typing is by no means required to translate to machine code, but it would probably make that faster.

An interesting option might be something like Squeak did, with a subset of the language that can be efficiently translated into C (and then compiled). This is something like what the static type SIG was aproaching -- not quite Python, but something that could run in the conventional CPython interpreter, wouldn't necessarily require any knowledge of C or assembly, but could run fast.

Of course, it is also possible to simply compile Python into system code just as it is (well, if someone wrote the compiler). There is nothing that makes Python inherently interpreted. The problem, however, would be in the efficiency of that code. A naive attempt to do this would probably be slower than CPython. OTOH, compilers for Scheme (which have many similar issues as Python) have produced very fast code (on par with C). In particular, Stalin is very fast (though there are others which are very fast as well) -- sometimes faster than C. Python doesn't have any of the huge flaws that languages like, say, Tcl have in this regard. Some operations are difficult in compiled environments -- like getattr or eval -- but they could still be possible, or they could be left out (since much code doesn't use them). OTOH, all the best Python code uses them.

The future of the Internet is in what I call "rational programming" derived from a revival of Bertrand Russell's Relation Arithmetic. Rational programming is a classically applicable branch of relation arithmetic's sub theory of quantum software (as opposed to the hardware-oriented technology of quantum computing). By classically applicable I mean it is applies to conventional computing systems -- not just quantum information systems. Rational programming will subsume what Tim Berners Lee calls the semantic web. The basic problem Tim (and just about everyone back through Bertrand Russell) fails to perceive is that logic is irrational. John McCarthy's signature line says it all about this kind of approach: "He who refuses to do arithmetic is doomed to talk nonsense." More on this a bit later, but first some history, because he who fails to learn from history is doomed to repeat its nonsense:

When I invented the precursor to Postscript (an audacious claim that I can back up -- it started as a replacement for NAPLPS which I proposed while Manager of Interactive Architectures for Viewdata Corp of America back in November of 1981 -- the Xerox PARC guys found my approach of what they called a "tokenized Forth" communication protocol to be an intriguing way to encode text and graphics), I was interested in having a Forth virtual machine migrate into silicon (ala Novix) so it could evolve from mere graphics rendering into a distributed Smalltalk VM environment (ala Squeak) as videotex terminal/personal computer capacities increased. But I was _not_ interested in object-oriented programming as the long-term semantics of distributed programming environments. (I still have some of the hardcopy of the communiques with Xerox PARC and others from this period.)

Rather, relational semantics were what I saw as the ultimate direction for distributed programming. I had a bit of a go at Tony Hoare's "communicating sequential processes" paradigm and its Transputer realization because he was, at least, starting with the hard problem of parallelism rather than making like the drunk looking for his keys under the light post the way everyone else seemed to be doing (and still are, save for Mozart, since threads, etc. are always an afterthought). But, because there were other hard problems like abstraction, transactions and persistence that he ignored, I christened his approach "Occam's Chainsaw Massacre" in my communiques (in honor of his distributed programming language "Occam") and dropped it in favor of relational programming, which has inherent parallelism resulting from both dependency and indeterminacy. (BTW: Dr. Hoare seems to have finally come to his senses about this issue.)

Unfortunately, the only researcher doing hardcore work on relational programming (meaning, getting to the root of relational semantics in a way that Codd had failed to do) at the time was Bruce MacLennan, then, of The Naval Postgraduate School, and he just didn't have the glamour of Alan Kay at places like Xerox PARC to attract the attention of guys like Steve Jobs. Bruce had a bit of a blind-spot, too, when it came to transactions and persistence, which I attempted to remedy by bringing David P. Reed's work on distributed transactions for the ARPAnet to him, but although he wrote a white paper on a predicate calculus (close to a relational) implementation of Reed's thesis (MIT/LCS/TR-205), he didn't really "get it", IMHO. Reed and MacLennan abandoned their work for other pursuits (ironically, Reed was chief scientist at Lotus while Notes was being developed but did not contribute his ideas on distributed synchronization to that development despite the fact that we had a mutual acquaintance from my Plato days by the name of Ray Ozzie -- so, I share some of the blame for this failure) even as Steve Jobs botched the embryonic object oriented world by abandoning Smalltalk and giving us, instead, a lineage consisting of Object Pascal on the Lisa/Mac which begat Objective C on Jobs's NeXT which begat Java at Sun via Naughton and Gosling's experience with NeXT.

This brings us to the present -- a world in which Javascript-based technologies like Tibet promise to not only salvage the object oriented aspect of the Internet from the birth defects of Jobs's spawn, but actually provide an advance over Smalltalk in the same lineage as CLOS and Self. But it is also a world in which there is growing confusion over the proper role of "metadata" in the form of XML -- particularly when it comes to speech acts and distributed inference. I would call Tibet "the next major Internet advance" except for the fact that the basic idea for a Tibet-like system has been around and well understood since the early 1980's. When it is finally released, Tibet (or a system like it) will put the Internet back on track. I call that a "recovery", not an "advance".

We are now poised to move forward with type inference based on full blown inference engines, thereby dispensing with the nonterminating arguments over statically vs dynamically typed languages that allowed Steve Jobs's spawn to get its nose in the tent. If you want to declare a "type" in a declarative language, just make another declaration and let the inference engine figure out what it can do with that information prior to run time. See how easy that was? Well, there is more to it than that, but not that much: Assertions have implications and assertions made prior to run time have implications prior to run time. Live with it and don't repeat the mistakes of the past.

The confusion over semantic webs, and the reason Berners Lee et al will fail, is essentially the same as the confusion that has beleaguered all inferential systems such as logic programming and "artificial intelligence" over the years: logic is irrational and the real world demands rationality -- otherwise nothing makes sense. By "rationality" I mean that reasoning must literally incorporate "ratios" -- or, as John McCarthy would put it, doing arithmetic so things make sense. By making sense, I mean there is a sense in which one interprets the sea of assertions that clearly dominates for a particular purpose. With logic not only are you limited to 0 and 1 as effective quantities; you have no adequate theoretic basis from which to derive more accurate quantities with which to make sense by taking ratios and determining which inferences are dominant.

Fuzzy logic and expert systems incorporating probabilities have typically failed because they are not based in the first principles of probability and statistics. As Gauss, the premiere probability theorist put it, "Mathematics is the study of relations." He didn't say, "Mathematics is the study of multisets." There are good reasons that relational databases, and not set manipulation languages, have come to dominate business applications -- and Gauss was aware of these differences when he began to derive his laws of probability. Subsequent axiomatizations of mathematics based on set theory were similarly misguided and have led to the idea that "fuzzy sets" are the way to introduce rationality into programming. Rather than sets, relations are the foundation, not just of mathematics but of rationality in the same sense that Gauss realized when he derived his theory of probability from the study of relations.

Rationality allows for judgment which is recognized as inherently fallible -- but which allows one to procede without exponentiating all possible paths of inference. Judgment also allows various identities to limit sharing of information to that needed -- thereby creating speech acts and a basis for rational measures of credibility associated with those identities. Since credit-rating is a degeneration of credibility, it should come as no shock that the invention of negative numbers, originating as they did with the Arabic invention of double entry account keeping, has its analog in something that might be called "logical debt" with which negative probabilities are associated.

And now we have come to the "quantum" aspect of rational programming. It is precisely the "credibility debt" aspect of rational programming that corresponds, in mathematical detail, to the various equations of quantum mechanics and their negative probability amplitudes. (Von Neumann's quantum logic failed to properly incorporate logical debt which has led to much confusion.) Logical debt is important to distributed programming for the same reason debt is important to financial networks. Logical debt is a way of handling poor synchronization of information flow in the same way that financial debt is a way of handling poor synchronization of cash flow. As in any rational system, there are both limits to credit and limits to credibilty that influence one's judgments and actions, including speech acts.

The object oriented folks may, in a sense, have the last laugh here because when we divide up inference into identities that engage in speech acts, we are reintroducing the notion of objects that hide information via exchange of speech act messages that can be thought of as "setters" (assertions) and "getters" (queries). However, I believe it is only fair to recognize that the excellent intuitions of Johan Dahl and Kristen Nygaard did need the added insights and rigor of philosophers like J. L. Austin and T. Etter.

• Even the few valid criticisms they had of X have been addressed: X now has antialiasing, transparency, and scalable fonts. (Yes, they are extensions, and that is quite proper: you want to be able to have low-footprint implementations of X without those features.)
• Java/Swing is an almost literal implementation of the Berlin manifesto: instead of C++, it uses Java, instead of Fresco, it uses Swing, and in addition to CORBA, it also has RMI, SOAP, and a lot of other RPC mechanisms. It turns out that in practice, Java/Swing isn't usually used in the simplistic way envisioned for Berlin (although IBM has a remote AWT implementation). Once you bother with RMI, it's more efficient and simpler to run much more code on the display server. Unlike Berlin, Java/Swing also has a safe and efficient "display-side" extension language--Java itself.
• Systems like Qt and Gtk+ now work directly on the framebuffer, and with VNC, the resulting system can even be accessed remotely.
• (And, incidentally, Fresco is a nice toolkit, and it runs nicely on X11.)

I think Berlin has missed the boat. X11 has caught up, and better implementations of Berlin's ideas already exist. This is not the time anymore to loose another C++/CORBA thing on the world.

The frontiers in toolkits is elsewhere anyway. If you want to play around with a powerful, extensible toolkit, spend some time digging into Squeak. It's a research system and on the surface, it looks like a pretty unappealing and cumbersome system with a bunch of oddly colored windows. The documentation is so-so (take a look at the Wiki, it contains some tutorials). But Squeak and its toolkit, Morphic, are also extremely powerful, a window system in which everything is open to inspection and modification, in which everything can be made to interact with everything else, and in which there is a huge number of tools, browsers, and development tools. The whole thing can run on a plain frame buffer (it also runs fine under X11, Windows, or MacOS), and everything is built in Smalltalk.

I find it hard to believe there is any demand for this. Indeed, it may make the less savvy people out there think of Linux as an expensive choice, especially when you realise that the vast majority of Linux users are shall we say "careful" with their cash!!!

One more example of big corporations setting out to destroy the open source revolution. I am saddened. What do others think ?

Totally beautiful -- in my case it took someone who understoon object-oriented principles and had done a bit of C++ in small 6-week to 3-month college projects into the culture of real O-O development.

Caveats -- after doing Smalltalk, C++ will get really painful and you'll keep snickering every time you read Java code.

Surprised nobody mentioned smalltalk code.

See Squeak for example, even the bootstrap C code is generated from squeak itself.

Once you get used to the syntax, the code is so much easier to understand for the same functionality compared with ones in other languages. Thanks for the OO nature, the code is easier to maintain as well.

I don't want to start another comp.lang war. I like C, I like Haskell, I use java/python quite a lot, but for purity and elegance, nothing comes close to Smalltalk.

The fact is..
no matter how closely I study it,
no matter how I take it apart,
no matter how I break it down,
It remains consistant.
I wish you were here to see it.
I like it.
- King Crimson [Discipline] "Indiscipline"

Don't get me wrong: those systems had their own share of problems, not the least of which was that they required expensive hardware to run well. They also lacked some of the niceties and safety check of modern programming languages (by which I mean languages like ML, not C++).

So, what can you do? Don't blindly use C/C++ for everything. Those languages have their place, but they require you to spend a lot of time on stuff that isn't related to getting the job done. Learn something new, and learn about the history of all this. Here are some suggestions:

• Learn about functional programming with Haskell and OCAML, and SML/NJ
• Learn about logic programming with one of the Prolog implementations.
• Read up on CommonLisp, Flavors, CLOS, and the Lisp Machine Window System. You can get CommonLisp implemenations at cons.org
• Read up on Scheme and get a Scheme programming environment. PLT Scheme looks pretty good.
• Read up on Smalltalk-80 and its programming environment (you can get a so-so Smalltalk-80 implementation at Squeak).

While those systems may or may not help you in your day-to-day work, they teach a lot about what programming can be.

For your day-to-day work, consider using languages and environments like Python, Perl, and Java. They aren't quite as convenient as the more academic systems I mention above, but they still let you focus much more on the problem rather than the mechanics of programming.

Try it out, it's really cool (and completly open, unlike this crap). It runs on Linux, Win32, Win CE, MacOS, MacOS X, OS/2, DOS, BeOS, NeXT, most commercial unices and a few PDAs. (hmm.. who have i left anyone out? :)

-henrik

Try it out, it's really cool (and completly open, unlike this crap). It runs on Linux, Win32, Win CE, MacOS, MacOS X, OS/2, DOS, BeOS, NeXT, most commercial unices and a few PDAs. (hmm.. who have i left anyone out? :)

-henrik

"any serious OO programmer knows that an OO language without multiple-implementation inheritance is a crippled husk of a language." I guess Smalltalk is not a serious OO language? But C++ and Perl, which do allow multiple inheritance, would be considered real OO languages? Seriously though, would someone please moderate Socializing Agent's post down to "Flamebait"?

Java the language is adequate.

Java' VM is very immature (the could take a page or five from the Smalltalk people who've been improving theirs since 1980,) and it shows.

Java the suite of libraries is in the same state as the VM and again could learn from the folks who've been at it a lot longer.

Java the IDE is pathetic except for IBM's VisualAge for Java which is almost as good as Smalltalk's IDE (VisualWorks, VisualAge for Smalltalk, Dolphin or even the late, lamented VisualWorksSmalltalk.)

Basically C++, C#, Java and Smalltalk (even Perl, CLOS and php,) as languages are roughly equivalent and its possible to write translators between them.

The IDEs are what make the difference and if you want a look at the best, check out Squeak to see just what you can get for free.

Don't let the syntax defeat you. Its actually the correct one for an object-oriented expression. If you can understand RPN calculators, you have the mental equipment to grok Smalltalk.

In my objects and design class that I took this summer at Georgia Tech, the professor told us that either Sony or Sega (I think Sony, but I am not sure) has licensed the Squeak programming language for their game platform. Since you are not really writing standalone entities when you do this but really adding onto a OS-like image, he seemed to think any game you wrote would also fall under that license

His take on it was that since Disney (The chief developers of the language, a modern, free implementation of smalltalk, which is really owned by Apple, but is cross-platform) is the one who asked for the licence, that Sony (or Sega) just gave it to them without really paying attention to what exactly Squeak is. Anyone know if its the Playstation or the Dreamcast that this license was granted for?

--gte910h

Frankly, at that level, they should be teaching programming concepts using an environment that gives immediate gratification.
Squeak is an excellent modern example of Smalltalk-80, which was invented for just this purpose.

Certainly the most time lost in programming is debugging. (well, maybe not by the programmers of certain software companies who seem to do no debugging at all...) And debugging *demands* a console. What is simpler, 'printf("got to xyz, variable xpto has value %d\n", xpto)', or setting breakpoints, opening variable display windows, scrolling to the variable you want, etc, in a debugger? I seldom use debuggers at all, the printf way is so much better.

My condolenses. Y ou're probably used to crappy C++ debuggers, and simply are ignorant of anything better.

No, debugging doesn't require a console. I don't doubt that gdb and other very primitive debuggers do. (I've only used gdb in the C world) In Smalltalk, even Squeak, with a relatively primitive debugger (at least compared to IBM's VisualAge Smalltalk) it light years ahead of the trash you C++ coders have to deal with.

Oh well, i suppose it comes with the job.

So, what should Linux people be doing? Sitting back and waiting for Palm to be the source of All Good Things?

Hey, I didn't say I wanted perl on PalmOS. I make no claims for other slashdot readers, however. :-)

I really don't know what Palm developers should be doing. There are still many undiscovered killer apps nicely implementable on PalmOS. Go forth and hack!

One of the big mysteries on the horizon is the Big ARM Switch coming up---how many more apps will the new architecture will allow, or in what areas we should be working? What new kinds of capability will come with the new OS?

And I think that leads to something I was trying to say with the phrase "Linux people".

The Linux community doesn't have to wait around to see what some company is going to ship, nor is it stuck with one particular goal or vision imposed from outside.

Sure, some perl weenies are going to drool over PocketPerl. But I'm not gonna stop them from implementing it. Rebuild a minimalist OS on eCos? Sure, why not. Java PDA? On its way. X on a machine running on AAAs? And how about Smalltalk, for that Dynabook spirit?

Some of these are probably bad ideas. I think a perl-centric PDA environment is a really bad idea. :-) But I don't make that decision, and neither does any other single person or organization. What will eventually decide it is whether a) someone thinks it should be done and does it, and b) enough people like it to keep it alive---even if it doesn't dominate the market.

Heck, eCos and Squeak don't need Linux, and that's a sign that Linux itself may be a bad idea in some cases. So me saying "Linux people" was a mistatement. I hope you get what I meant.

If the Linux developers are having a tough time figuring out what to do , a much more useful pursuit would be developing a better way of syncing a Palm device to Linux.

Personally, I'd be a lot more interested in working on this if the Palm devices spoke some standard, open protocol for synchronization. Other people are more motivated than me, though.

Want an aquatic robot? Check out the MicroSeeker. It's not commercially available, but it seems like it will be someday. What makes this robot interesting is that it runs Smalltalk, as opposed to a crappier language like the variants of C and BASIC most robos run. There's PIC/Smalltalk for the motor control, a Handspring Visor running PocketSmalltalk for high-level control, and the simulator is written in Squeak. A veritable cornacopia of Robotics and Smalltalk.

To oversimplify, there are two big reasons

• The first is that the syntax and the environment are a shock for people raised on file-based, statically typed, "edit it in vi" type of languages.
• The second and more important are the business reasons. Smalltalk was doing quite well commercially in the early 90's, but mostly in the high-end corporate developer space, with costs of thousands of dollars per developer seat. IBM had a big push behind it. This frightened the two other big commercial vendors, who attempted to merge, failed disastrously, and left IBM almost alone in the market, a position it didn't want to be in. With the high-price policies there was no low-end or open source base to sustain it. Then Java came along and picked up a lot of the pieces.

Nevertheless, Smalltalk has refused to go away. Significant open source efforts have started with things like Squeak and Camp Smalltalk, and even in the commercial world VisualWorks has a free download and Dolphin Smalltalk is an inexpensive very nice, clean windows environment. For a language that doesn't get used much, it runs fabs, auto assembly lines, massive payroll systems, and untold numbers of financial systems including a very respectable fraction of the stock trades in the United States.

Disclaimer: I recently quit a Java startup (WebGain) to go work for Cincom on Smalltalk development.

Try download Squeak. It's a very easy install on any platform you're likely to be using (WinCE/NT/95/98/2000, MacOS, Linux, BSDs, BeOS, etc.) It comes with many demos, including an interactive VR authoring environment.

Smalltalk has a strong tradition of being cross platform. The most notable example is Squeak which runs on almost every platform out there. Most importantly, most of the big Unices (including Linux), Mac OS, and Windows. With binary compatibility. C as a portable assembler is a myth, and C code needs to be written with portability in mind.

I don't use LISP/CLOS or Smalltalk or Prolog for the same reasons that I do use Java for my home hacking: The textual representation of a Java class as a single source file will all details collected really works for me, and the typing system leads to self-documenting and correct-by-construction code. Sure, a single file can get cluttered. That's what JavaDoc fixes. On the other hand have you ever tried to grep a SmallTalk VM? Yes, builtin object browsers are cool, but I'm a hardcopy code reader. Same goes for LISP/CLOS. There isn't sufficient structure in the syntax to be self-documenting. Strong typing is also a big feature for me. I'm lazy, compile-time type checking is my friend. With SmallTalk you have to figure out why that message wasn't found rather than know ahead of time that it won't be found. Prolog just gives you a "No".

VMs really are very cool. My favorite hack on the Lispm was to search for CLOS methods that weren't polymorphic and recompile them automatically as defuns for efficiency, AND modify the source code to reflect the change. These days when I write code I just want to get the job done. SmallTalk doesn't get me there because the textual representation doesn't support the way my brain organizes and retrieves program structure.

You might as well ask "why don't more people use any functional languages?" The simple fact of the matter is they're a lot more difficult for people to wrap their head around at first. This may have something to do with the fact that most CS curriculums start students out with procedural languages (C, C++, Java) and barely give them a cursory glance at functional programming (which is kind of a shame).

You are wrong on several counts.

Smalltalk is an Object Oriented Language. As are C++ and Java. C is a procedural language.

Having used all four I can state that in my opinion the reason Smalltalk has never caught on is due to a.) Lack of speed b.) Lack of libraries c.)lack of decent IDEs d.) Lack of compilers e.) Lack of good books/documentation (this in my opinion is the biggest flaw).

Of course, the Squeak Project plans to change this.

You are allowed to change Squeak, write extensions to Squeak, build an application in Squeak, and include some or all of Squeak with your products. You may distribute all of these things along with Squeak, or portions of Squeak, for free or for money. However, you must distribute these things under a license that protects Apple in the way described in this license.

If you modify any of the methods of class objects (or their relationships) that come with Squeak (as opposed to building on top of the classes in the release), you must post the modifications on a web site or otherwise make them available for free to others, just as has been done with Squeak. The same is true if you port Squeak to another machine or operating system - you must post your port on a web site or otherwise make it available for free to others under the same license terms.

This device looks very promising as a Linux PDA. While I've seen plenty of posts from people whining about it's specs (66MHz CPU, 8MB RAM/2MB ROM, 16 shade greyscale screen at 240x160), they seem to be missing the point. The base model will cost $149! The iPAQ, Yopy, and other Linux-capable WinCE machines cost an order of magnitude more than $149.

That's it's strength, to me. I'd much rather have a small, cheap unit like this with OK battery life than an expensive, big (size and weight) and battery eating hog.
It's also as cheap as Palm and Visors cheapest offerings, but with a considerably faster CPU, more RAM and a bigger screen. Such is my argument (sans bigger screen) for another Linux capable PDA, the Helio.

I think it's pretty silly to put X on it, but I wouldn't call it a mistake, per se. Why? Because you can always take X off and put in Nano-X, Squeak, W, or Microwindows in instead.

Now, does anyone want to help me port Squeak to the Linux framebuffer for use on a PDA like this, so we can dump X?

Congratulations, you've just reinvented Genera. Or Squeak, if you like "objects" better than "functions", or if you want to run it on top of an existing OS, or if you don't want to be tied to a specific (dead) hardware architecture. And ETH Oberon is yet another OS based on the same ideas. In any case, that you don't see it everywhere doesn't mean it hasn't been invented yet - and that it's (not) popular doesn't mean it's (not) good. (For the first case, see Haskell - "groundbreaking" parametric polymorphism in the late 80s; for the second case, see Windows.)

In any case, it will do you no good to use CORBA as it is today. Instead, use a dynamic, high-level language for user-level functionality, and just let applications people deal with objects in the language's natural idiom, making no syntactic distinction between "local" and "remote" objects.

In any case, have fun, and don't let those Unix weenies tell you that systems research is dead - if it were for the conformists and the naysayers, we'd be rendering polygons with abaci!

The state of language design these days is down right depressing. The world can't seem to move beyond all of those silly Algol-derivatives like C, C++, Java, and now C#, making Smalltalk- a language designed throughout the 70s and finialized as Smalltalk-80 in 1980- still the height of language design.

What does C# add to Smalltalk, and contribute to the the innovation of language design? Not much. It has "attributes," which are nothing more than embedded XML comments; COM integration (good if you're on Windows, but you could always use Dolphin Smalltalk for that; SOAP integration (Dandy, but it's available for almost every language around); compilation (you can do this with Smalltalk MT); and the ability to regress back into C-pointer mode to write "unsafe" code, to make sure the incompetent GC doesn't eat your objects (which were never rooted, probably by an incompetent programmer).

Many of these things are neat and useful, but reek of the sad state of language design nowadays, and available elsewhere with or without add-on packages.

What's almost as sad, is that a lot of programmers are in awe at the power of C# and Java, with their heads too buried in the sand of C's syntax to see the innovations that Smalltalk (cf. Squeak) made 20 years ago.

I am one of these Linux to Mac converts. I used Linux as my primary OS since 1995, then finding NeXTSTEP, OpenStep and Rhapsody a few years later. I began to use OpenStep for a lot of general computing, but sadly, a lot of what I wanted to do had to be done under Linux (POSIX support was flaky in NeXTSTEP and dropped in OpenStep). I much preferred the clean OpenStep environment and API to the schizofrenic nature of Linux.

This went on until early 2000. I sold my Linux/x86 box and bought myself a G4, expecting to use Mac OS X Server in the interim. I started off using Mac OS X Server most of the time, but for somethings (games) I had to go into Mac OS 9. As one who hates rebooting, even for the sake of switching to another OS, I began using Mac OS 9 more and more, and was honestly surprised how decent it was, not from a UI standpoint, but that it actually did crash a lot less than Windows.

I too expect some Linux users (and Windows users, for that matter) to switch to the Mac when Mac OS X comes out. For me, OS X allows me to do all the things I did/do on Linux (program in Python and Squeak, among other things) but allowing me to shut out all the Unixisms and just get work done if needed. At the same time, I can always just drop to a shell if I want. It is this which I think will attract more like me to the Mac. I know they'll enjoy it just as much as me. :)

Ward Cunningham designed the first such web site of which I am aware (called a Wiki, or a Wiki-Wiki) several years ago. Co-webs have been in use for quite some time, though they tend to be somewhat more sophisticated than a mere place to dump ftp -- usually providing editors and "smart" pre-parsers to facilitate collaboration by newbies.'

See, e.g., this swiki page.

Despite the skepticism, these things work very well and are rarely the subject of abuse. A sandbox is provided for people who just want to play, and folks are generally quite courteous as a matter of practice. We use one for the Squeak Smalltalk open source community, which you can access from the main (traditional) web site page for Squeak.. The Swiki is one of the primary repositories of information for the Squeak community.

We have found cowebs an excellent vehicle for collaboratively creating documentation for open source projects that have run too long without doco support.. While it is not a great place to build final documents, it is a great place to gather information, and over time mold into the same.

Sure thing. Here's Squeak; it's an all-in-one high-level OS, virtual machine and user interface based on a Smalltalk variant. Also interesting is ETH Oberon, another high-level OS based on the Son-of-Modula of the same name. Both sites have screenshots; both systems can run as applications on top of most popular OSs.

While it isn't FP, Squeak is a Smalltalk system which is somewhat of it's own desktop environment. Not only does it have many features of a modern GUI system, it also has many other functions which are usually part of an operating system, like multi-tasking and process management.

It has been ported to bare metal a couple of times (to an embedded Mitsubishi SH3 chip, and x86) and can stand alone like it's own OS. Also, work it being done by me to get it working via the Linux framebuffer (the current Linux/Unix version requires X), so you could easily have a version which would be it's own OS on almost any archetecture.

Squeak Smalltalk itself runs on many platforms- including, but not limited to: Mac OS (classic), Mac OS X, Linux and most other Unixes, the Acorn RiscOS, Windows 95/NT, and DOS (graphics via VESA). The Smalltalk image file is binary compatible as well.

Also, since this is about FP, there has been recent discussion of FP, Aspect Oriented Programming, MOP, and similar concepts on the Squeak mailing list now. Smalltalk also has block-syntax which is similar to lambda.

...I've found that most of my debugging needs are solved by:

Typechecker (~97%)

Fine-grained inspection of the system (objects and execution state) are what make for a good debugging system. gdb is okay -- certainly better than print statements and Deep Thought. Squeak still has the most pleasant and helpful debugger I've used -- in part because it was never an afterthought, being a language not created by mathematicians with fantasies of Correctness.

I don't think static typing is very mathematical anyway. Most higher math deals with things in terms of properties, not types. The analog in CS is methods. If something implements mathematical operations then it's a number, what the object actually is isn't terribly important.
--

These MS languages aren't the "in" languages of the day. The "in" languages over the next few months will be Python and Squeak

C fans won't like it, but reasonable people will see the advantages of using Sheep to reimplement a lot of their software. System level software especially will benefit from be reimplemented in Sheep due to the far shorter development times it will produce.

gcc will be coming out with a sheep compiler, gsp, (or something similar), in a few months. Java will be totally replaced as well, because if you think about, who needs an interpreted (bytecode interpreted then, whatever) WORA language, when there's a compiled language that does away with the #ifdef's of C, yet is faster than C and cleaner than both C and Java?

This new system will mostly be a clone of BeOS, but because of the better language, it will surpass BeOS is every way - and truly bring Open Source to the masses. It will combine the best elements of BeOS with the best elements of FreeBSD and Linux. A system that, while having a very smart GUI, will not be dependent on that GUI for normal operation, and will also be totally multiuser. C compatibility libraries, written in Sheep, will exist to make the transfer easier, but once reasonable developers start writing in Sheep, they will be sickened by the thought of going back to C.

Soon Squeak Techonology will take over the graphics market. It's way ahead of its time. Check out the latest Squeak technology. This thing handles any colour depth, supports anti-aliased image rotation and is platform independent, as well as fully open source. Its graphics morphing system is also truly exciting. I think that this is the way that consoles should go, a tiny footprint, compared to Microsoft's propreitry bloatware.

So? W and MicroWindows are running on another smaller and cheaper PDA. X on a PDA? Who cares? Let's not bring all of our X baggage with us into the PDA world, which requires mostly PDA-specific apps... Look into W, MicroWindows/Nano-X and Squeak for better GUI alternatives for a PDA. Squeak is exceptional in the sense that it can scale from the PDA, to the desktop, to the server.

• Squeak, a Smalltalk-based language/OS/IDE/VM developed by Disney. Specifically, try to find stuff about Morphic there; it was born in Self, a prototype-based (classless) relative of Smalltalk, but it's been adopted officially as Squeak's UI system. It's pretty innovative, taking the approach of representing all objects graphically on screen through the notion of "morphs".
  
• ETH Oberon, another integrated language/OS hybrid, with a very different UI with some interesting ideas.
  
• Gentner and Nielsen's amazing article The Anti-Mac, which, by starting out with the goal of violating all the reasoning behind Apple's Human Interface Design Guidelines, ends up with a very interesting - and very implementable in the near future - UI design for high-performance workstations.
  

Consider circumstances where the operating system becomes subsumed in application software -- suddenly the concession to reality of permitting distribution of a GPL'd application together with a proprietary application. In the context of some OODL's, this distrinction between operating system and application dissolves.

Consider Smalltalk-80 and modern day open-source derivatives, such as Squeak. In Squeak, all objects, sources and applications co-exist in a Smalltalk "image." Because of the nature of late-bound OODL programming, it is IMPOSSIBLE to combine Squeak with GPL code without infecting each and every application in the image -- this is because the image is not the operating system.

Unfortunately, this makes it legally impossible to merge GPL code with Squeak without rewriting large portions of that code, which while open source cannot co-exist with GPL. Too bad for Squeak, and too bad for the GPL. Moreover, too bad for the community, which is deprived of excellent software that could have been.

Self: a little outdated now but there are still some interesting ideas in it (many of them were used to develop Java). You can find it somewhere on sun's website.

SELF wasn't really a big new paradigm, though. It worked on a few interesting ideas: dynamic compilation (which became Java's JIT), prototype-based OO, and a new widget system (Morphic, which lives on in Squeak).

I think prototypes are an interesting alternative to classes for OO programming, and it's something that hasn't been very seriously pursued since then. It's a purification of OO in some ways, as too is SELF's insistence that all access to instance variables be through method calls.

Alan Kay, who coined "object oriented", said before that he really named it incorrectly, because he felt message passing was a more interesting and powerful concept. I think SELF moved more in that direction.
--

When the original Mac was developed, research was done to determine the best possible type of mouse. At Xerox PARC, the Smalltalk machines generally had three buttons, labeled by color (a naming tradition that continues today in eg. Squeak). It was found that three- and even two-button mice were considered too complex for the target user. There were just too many instances when it was neither clear nor intutive which mouse button you use. Hence, the standard one-button mouse.

Fast forward a bit, and you'll come to today, when Apple is going to unleash it's new set of strokable, squeezable mice on the exact same type of users as the one-button mouse was designed for. Will it be any easier? Do you stroke to copy? Tap to move? Squeeze to check your email? I wonder exactly what sort of "research" they did. The one-button mice has sufficed for Mac users for years, and they are likely to be confused with something new. In fact, it reeks of the way Apple stopped supplying iMacs with floppy disks, perhaps in order to prevent the users from confusing IBM and Apple disks (something which I understand is quite common with Mac users).

Who will be there to hold the user's hands? It will certainly be a big leap for Mac users, and I am unsure whether many of them are capable of handling such a shift so radically. Finally, I think they'll need some big marketing, combined with promises of a "richer Internet experience" to pull this one off.

When I invented the precursor to Postscript (an audacious claim that I can back up -- it started as a replacement for NAPLPS which I proposed while Manager of Interactive Architectures for Viewdata Corp of America back in November of 1981 -- the Xerox PARC guys found my approach of what they called a "tokenized Forth" communication protocol to be an intriguing way to encode text and graphics), I was interested in having a Forth virtual machine migrate into silicon (ala Novix) so it could evolve from mere graphics rendering into a distributed Smalltalk VM environment (ala Squeak) as videotex terminal/personal computer capacities increased. But I was _not_ interested in object-oriented programming as the long-term semantics of distributed programming environments. (I still have some of the hardcopy of the communiques with Xerox PARC and others from this period.)

Rather, relational semantics were what I saw as the ultimate direction for distributed programming. I had a bit of a go at Tony Hoare's "communicating sequential processes" paradigm and its Transputer realization because he was, at least, starting with the hard problem of parallelism rather than making like the drunk looking for his keys under the light post the way everyone else seemed to be doing (and still are, save for Mozart, since threads, etc. are always an afterthought). But, because there were other hard problems like abstraction, transactions and persistence that he ignored, I christened his approach "Occam's Chainsaw Massacre" in my communiques (in honor of his distributed programming language "Occam") and dropped it in favor of relational programming, which has inherent parallelism resulting from both dependency and indeterminacy. (BTW: Dr. Hoare seems to have finally come to his senses about this issue.)

Unfortunately, the only researcher doing hardcore work on relational programming (meaning, getting to the root of relational semantics in a way that Codd had failed to do) at the time was Bruce MacLennan, then, of The Naval Postgraduate School, and he just didn't have the glamour of Alan Kay at places like Xerox PARC to attract the attention of guys like Steve Jobs. Bruce had a bit of a blind-spot, too, when it came to transactions and persistence, which I attempted to remedy by bringing David P. Reed's work on distributed transactions for the ARPAnet to him, but although he wrote a white paper on a predicate calculus (close to a relational) implementation of Reed's thesis (MIT/LCS/TR-205), he didn't really "get it", IMHO. Reed and MacLennan abandoned their work for other pursuits (ironically, Reed was chief scientist at Lotus while Notes was being developed but did not contribute his ideas on distributed synchronization to that development despite the fact that we had a mutual acquaintance from my Plato days by the name of Ray Ozzie -- so, I share some of the blame for this failure) even as Steve Jobs botched the embryonic object oriented world by abandoning Smalltalk and giving us, instead, a lineage consisting of Object Pascal on the Lisa/Mac which begat Objective C on Jobs's NeXT which begat Java at Sun via Naughton and Gosling's experience with NeXT.

This brings us to the present -- a world in which Javascript-based technologies like Tibet promise to not only salvage the object oriented aspect of the Internet from the birth defects of Jobs's spawn, but actually provide an advance over Smalltalk in the same lineage as CLOS and Self. But it is also a world in which there is growing confusion over the proper role of "metadata" in the form of XML -- particularly when it comes to speech acts and distributed inference. I would call Tibet "the next major Internet advance" except for the fact that the basic idea for a Tibet-like system has been around and well understood since the early 1980's. When it is finally released, Tibet (or a system like it) will put the Internet back on track. I call that a "recovery", not an "advance".

We are now poised to move forward with type inference based on full blown inference engines, thereby dispensing with the nonterminating arguments over statically vs dynamically typed languages that allowed Steve Jobs's spawn to get its nose in the tent. If you want to declare a "type" in a declarative language, just make another declaration and let the inference engine figure out what it can do with that information prior to run time. See how easy that was? Well, there is more to it than that, but not that much: Assertions have implications and assertions made prior to run time have implications prior to run time. Live with it and don't repeat the mistakes of the past.

The confusion over semantic webs, and the reason Berners Lee et al will fail, is essentially the same as the confusion that has beleaguered all inferential systems such as logic programming and "artificial intelligence" over the years: logic is irrational and the real world demands rationality -- otherwise nothing makes sense. By "rationality" I mean that reasoning must literally incorporate "ratios" -- or, as John McCarthy would put it, doing arithmetic so things make sense. By making sense, I mean there is a sense in which one interprets the sea of assertions that clearly dominates for a particular purpose. With logic not only are you limited to 0 and 1 as effective quantities; you have no adequate theoretic basis from which to derive more accurate quantities with which to make sense by taking ratios and determining which inferences are dominant.

Fuzzy logic and expert systems incorporating probabilities have typically failed because they are not based in the first principles of probability and statistics. As Gauss, the premiere probability theorist put it, "Mathematics is the study of relations." He didn't say, "Mathematics is the study of multisets." There are good reasons that relational databases, and not set manipulation languages, have come to dominate business applications -- and Gauss was aware of these differences when he began to derive his laws of probability. Subsequent axiomatizations of mathematics based on set theory were similarly misguided and have led to the idea that "fuzzy sets" are the way to introduce rationality into programming. Rather than sets, relations are the foundation, not just of mathematics but of rationality in the same sense that Gauss realized when he derived his theory of probability from the study of relations.

Rationality allows for judgment which is recognized as inherently fallible -- but which allows one to procede without exponentiating all possible paths of inference. Judgment also allows various identities to limit sharing of information to that needed -- thereby creating speech acts and a basis for rational measures of credibility associated with those identities. Since credit-rating is a degeneration of credibility, it should come as no shock that the invention of negative numbers, originating as they did with the Arabic invention of double entry account keeping, has its analog in something that might be called "logical debt" with which negative probabilities are associated.

And now we have come to the "quantum" aspect of rational programming. It is precisely the "credibility debt" aspect of rational programming that corresponds, in mathematical detail, to the various equations of quantum mechanics and their negative probability amplitudes. (Von Neumann's quantum logic failed to properly incorporate logical debt which has led to much confusion.) Logical debt is important to distributed programming for the same reason debt is important to financial networks. Logical debt is a way of handling poor synchronization of information flow in the same way that financial debt is a way of handling poor synchronization of cash flow. As in any rational system, there are both limits to credit and limits to credibilty that influence one's judgments and actions, including speech acts.

The object oriented folks may, in a sense, have the last laugh here because when we divide up inference into identities that engage in speech acts, we are reintroducing the notion of objects that hide information via exchange of speech act messages that can be thought of as "setters" (assertions) and "getters" (queries). However, I believe it is only fair to recognize that the excellent intuitions of Johan Dahl and Kristen Nygaard did need the added insights and rigor of philosophers like J. L. Austin and T. Etter.

Squeak has a lot going for it, but familiarity for Windows users is not on the list. Probably a better choice would be Dolphin Smalltalk; it "feels like Windows" (a good thing in this case), it's a real Smalltalk, it comes with good tutorial documentation, and there's a free (as in beer) version available.

Good news: Smalltalk was designed (back in the 1970s, assuming computers as powerful as we have today!) to be a programming language for kids. Bad news: Really smart kids took to it like fish to water, but most really struggled.

Those of us who cut our teeth on punch cards and Teletypes were used to command line (or worse) interfaces and text programs. Today's kids aren't; even typing Smalltalk programs may bore them.

Consider Stagecast Creator or Toon Talk as a couple of purely visual development environments. They're more suited towards development of games and simulations, but that's a plus if the goal is to get your children excited about programming (probably the right target at first).

Here are a couple of stories about teaching kids to program: This one from Kids Domain has a lot of links to resources, while this one from Suite101.com is an interview (with fewer but entirely distinct links).

It's sad that people don't remember that Smalltalk has been specifically targetted since it's inception for teaching young kids. All the traits of Python that make it good for teaching come from Smalltalk. While Python is actively being developed for the classroom, Smalltalk has a proven track record with kids as young as kindergarten age. Smalltalk also has a more mature class library for kids to learn from and more mature tools.

I posted a reference to Squeak Earlier but it's not as "sexy" in the hacker community as Python, so I'm not moderated up to 5. I could care less about the moderation points, but I REALLY hope people try introducing their kids to programming through Squeak. I know both languages and my SO teaches young children, and I can tell you Smalltalk is the better way to go.

The Smalltalk implementation called Squeak, mentioned in other threads, comes with a workspace (known as a project) that has an Alice 3D graphics demo - it has a little energizer bunny that you can move, pan the camera around, explode, make hop, spin, etc.

I'm biased, but Smalltalk has a long history of being used as a kids programming environment. You may want to look at LearningWorks, which has a simplified interface just for teaching. It is based on VisualWorks Smalltalk.

I'm also experienced - when I have tried to teach my older children programming, I found that they would like to see something. Our first pass ended up being teaching them HTML so they could put up a web page. I am going to try Smalltalk again this summer.

Two languages which are great for kids are Python and Smalltalk. They are both languages with the intent of making computer programming accessable to anyone who might want to program. They're both Object Oriented (Python still allows procedural programming though). Why does that matter? Studies have shown that teaching kids OOPL as a first language makes it easier to switch to or decide to use a procedural language, while those first taught a procedural language like Pascal or C, have a much harder time picking up on the ideas of Object technology.

I personally would stray from teaching them VB, Delphi, or C++. VB and Delphi can produce visual results fast, but teaching Python or Smalltalk could help them get a real handle on what's going on. C++ is simply too complex that it'll just muddle them up, and probably make them bitter little programmers.

Not to start a language/paradigm war, but do your kids a favor, and don't default to teaching them a structured or procedural language like BASIC or Pascal, two typical teaching languages. Like many others, I learned BASIC first. But the fact of the matter is, BASIC was designed back in the day when as a beginner's language, when what you moved on to were Fortran and COBOL. While Fortran and COBOL are still in use today, they're nowhere near being truely modern languages. Pascal would lead to C. I reccommend Python and Smalltalk because they're both comprehensible by kids, but usable in real applications by adults (or kids too, for that matter!).

You can find Python here, and Squeak Smalltalk here. Others have mentioned Alice -- Squeak Smalltalk includes a 3D system like Alice as well, where you can program and intereact with 3D objects. It's a lot of fun! :)

For a free, full Smalltalk version, there is none better than Squeak.

There are a lot of things in UNIX which are still very good, and which should go on in whatever new OS we make, such as the POSIX standard which, it seems, is getting supported almost everywhere. Things like preemptive multitasking, protected memory, true multi-user environments, named pipes, and quite a few other things should obviously be kept. But I think that beyond those basic things we should start over. If we were to create an OS which was going to truly be for the average consumer, we'd want to add things like a unified document format tag in files and dynamically-loadable drivers (à la QNX)--things which currently don't exist in UNIX, and for various reasons would be quite hard to add. Mac OS X has done a lot to add these things to UNIX, but I question whether or not, had OS X not had NEXTSTEP/OPENSTEP herritage, whether OS X would use UNIX. Because the fact of the matter is that, when you implement all of those changes, you really don't have a UNIX box anymore in the traditional sense, but rather something totally different that's loosely based on UNIX technology. Whether there's any particular reason to start with UNIX to implement features like what you're asking, rather than to start from scratch or with another system, is something I would seriously question before the Open Source Community (tm) undertakes a project like this.

Meanwhile, about your complaint about X being the GUI: I think most people agree that X has major problems. Where I think most people fail to see something is that X isn't the only thing that is wrong with Linux GUIs. Linux GUIs are currently pretty much clones of either Windows95/98/NT/2000, Mac OS, or similar environments. Those GUIs were never designed for a UNIX system. If you want to build a GUI for a consumer system, those may be the way to go, but if you want to have a GUI for Linux, you should work to design a GUI from the ground up that is actually suited to Linux. What's better suited for Linux? I don't know. Maybe we just haven't figured out what aspects of Windows95's interface just aren't suited to Linux, which aspects are, and which ones we might be able to learn from but by counterexample and should start anew. Maybe what we need is something like Squeak's Morphic. And there's the definite possibility that a GUI just isn't suited for Linux--at least in its current state. But my point is that the problem lies deeper than X; it lies with the current way we're trying to marry Linux to a GUI.

Squeak! Squeak! Squeak!.

This will be the technology used in embedded applications in the future ! It 's too cute:)