Slashdot Mirror

From what I read here, systemd is a lot less modular by bundling in a lot of services. Linux has had the virtue of modularity at is core, as exemplified by narrow-focus command line tools piped together to get work done. Modularity is something like cleanliness. If you leave crumbs all over your kitchen all the time, it generally isn't itself the problem. The problem is when roaches and mice move in and you can't get rid of them due to the crumbs you still leave everywhere. Granted, cleanliness (and modularity) can perhaps go too far (the person who scrubs the kitchen flour every five minutes). So, what is a healthy balance here? I don't know enough about the details to weigh in on that. You ask for specific problems, and while a reasonable sounding request, that is also a bit like asking people to send pictures in of specific roaches and mice. The specific problems are important of course, but what is at stake is the bigger picture, not stamping out each individual roach. What matters is increased risk. The more general issue is the management of risks from complexity, whereas modularity is one of the best (but not the only) approach for doing that.

I've seen how lack of modularity can damage other software communities -- particularly the early Squeak community, like I wrote about here
http://lists.squeakfoundation....
"I sympathize. I think the biggest issue of Squeak is issues with modularity and managing complexity. These issues translate to frustration for maintainers (and users :-). Anyway, I had related frustrations to yours many years ago and they are why I ended up doing a lot in Python and Jython on the JVM in the last decade, even to the point of working on PataPata. ... I think the most important single issue in maintaining any large system is managing complexity (documenting intent maybe comes next, including well-named variables and methods and functions). This has never been a priority for Squeak IMHO. ...
There are several ways to manage complexity, which include:
* modularity (namespaces, packages like Java or GNU Smalltalk or Debian, letting someone else do that hard work by leveraging libraries or VMs or languages, like Squeak does by using a C compiler to generate the VM)
* cleverness (brilliant redesign, like traits was hopefully going to be)
* laissez faire, and also to each his or her own image (that is what we have now, and it is not that bad an idea, if the *core* is small and well thought out, like Spoon, so the *image* instance becomes the *module*. But alas, it is not, witness how confusing Morphic is to unravel).
Modularity is the one way to manage complexity which seems to work best in practice, although the others have their role. However, if Squeak images could easily talk to each other and share some state, and we had Spoon-like remote debugging and development, then we could have just one application per image, and that would be easier to maintain (it would be modular to a degree but in an unusual way). But I would still suggest such a system built on well-though out (clever) modules would be more powerful and easier to use than a mess of spaghetti code, even if we had only one application per image."

With roots back to here in 2000:
http://lists.squeakfoundation....
"Squeak complexity in 2.8 has become a complex cat from the simple kitten complexity of 1.13(?) in 1996. Back then, Dan Ingalls wrote on 10 Nov 1996 those prescient words: "The Squeak team has an interest in doing the world's simplest application construction framework, but I suspect that we will get sucked up with enough other things that this won't happen in the next two months (but who knows...)."
Squeak 2.8's complexity is now quiet (in terms of walkbacks) and stealthy (in terms of growing between

From what I read here, systemd is a lot less modular by bundling in a lot of services. Linux has had the virtue of modularity at is core, as exemplified by narrow-focus command line tools piped together to get work done. Modularity is something like cleanliness. If you leave crumbs all over your kitchen all the time, it generally isn't itself the problem. The problem is when roaches and mice move in and you can't get rid of them due to the crumbs you still leave everywhere. Granted, cleanliness (and modularity) can perhaps go too far (the person who scrubs the kitchen flour every five minutes). So, what is a healthy balance here? I don't know enough about the details to weigh in on that. You ask for specific problems, and while a reasonable sounding request, that is also a bit like asking people to send pictures in of specific roaches and mice. The specific problems are important of course, but what is at stake is the bigger picture, not stamping out each individual roach. What matters is increased risk. The more general issue is the management of risks from complexity, whereas modularity is one of the best (but not the only) approach for doing that.

I've seen how lack of modularity can damage other software communities -- particularly the early Squeak community, like I wrote about here
http://lists.squeakfoundation....
"I sympathize. I think the biggest issue of Squeak is issues with modularity and managing complexity. These issues translate to frustration for maintainers (and users :-). Anyway, I had related frustrations to yours many years ago and they are why I ended up doing a lot in Python and Jython on the JVM in the last decade, even to the point of working on PataPata. ... I think the most important single issue in maintaining any large system is managing complexity (documenting intent maybe comes next, including well-named variables and methods and functions). This has never been a priority for Squeak IMHO. ...
There are several ways to manage complexity, which include:
* modularity (namespaces, packages like Java or GNU Smalltalk or Debian, letting someone else do that hard work by leveraging libraries or VMs or languages, like Squeak does by using a C compiler to generate the VM)
* cleverness (brilliant redesign, like traits was hopefully going to be)
* laissez faire, and also to each his or her own image (that is what we have now, and it is not that bad an idea, if the *core* is small and well thought out, like Spoon, so the *image* instance becomes the *module*. But alas, it is not, witness how confusing Morphic is to unravel).
Modularity is the one way to manage complexity which seems to work best in practice, although the others have their role. However, if Squeak images could easily talk to each other and share some state, and we had Spoon-like remote debugging and development, then we could have just one application per image, and that would be easier to maintain (it would be modular to a degree but in an unusual way). But I would still suggest such a system built on well-though out (clever) modules would be more powerful and easier to use than a mess of spaghetti code, even if we had only one application per image."

With roots back to here in 2000:
http://lists.squeakfoundation....
"Squeak complexity in 2.8 has become a complex cat from the simple kitten complexity of 1.13(?) in 1996. Back then, Dan Ingalls wrote on 10 Nov 1996 those prescient words: "The Squeak team has an interest in doing the world's simplest application construction framework, but I suspect that we will get sucked up with enough other things that this won't happen in the next two months (but who knows...)."
Squeak 2.8's complexity is now quiet (in terms of walkbacks) and stealthy (in terms of growing between

I have casually following discussions on zope. The package seaside keeps coming up as also doing what zope trys to accomplish. Has anyone here compared the two. Has anyone ever used either before?

Sounds like you might be interested in Squeak-E.

Croquet's needs the Squeak VM to run (at least, currently). Unfortunately, there's some debate over whether the Squeak License (which is from Disney, out of Apple) is free or not.

Here's a thread on the problem, linked to in the middle of the conversation, where Alan Kay is giving his own reasonable, but perhaps a bit naive interpretation, that licenses don't matter - yet.

Rule #1: To each his own.

Just a guess: Did you go to GaTech or some other school where they use Squeak in a class? A lot of people seem to get bitter after that, especially if they didn't like the prof.

I'm with Abcd on this one. Myself, I prefer Squeak to any other desktop environment. I get absolute power over my GUI environment, but I don't have to exercise any of that power if I don't want to. I can use the standard config and GUI preferences. But I don't. Squeak affords me total control over my environment, in a way that doesn't exist on the other GUIs of Mac OS X, Linux or Windows. The GUIs of Mac OS X, Windows and Linux are all so much more confining and limiting. There are some perks to any given one of em, but nothing that touches Squeak.

Pre-Macintosh windowing system? Methinks you haven't used Squeak in a very long time. Sometime before Morphic was usable, and you were in MVC, which actually was the windowing system that pre-dated and fathered the Mac OS. These days, Squeak's GUI system/toolkit- called Morphic, and Morphic has very few real rivals. Sure, there is Self's Morphic, but that doesn't really count. :P

On Mac OS X, Linux and Windows, people have been getting giddy over tools like Konfabulator. Don't get me wrong, they're fun extensions to the desktop. But I'm pretty non-plussed. I've been doing the same thing in Squeak for a long time now, without needing anything special. If I want to put up a widget showing the temp and cloud cover icon for my zip code, it's pretty trivial... Drag out the appropriate Morphs, write a couple lines of Smalltalk code to grab the sunny/cloudy/raining cloud gif and display it.

And no, people don't have to do that every time they want a little weather monitor. I can save the object and share it with others, so that they can get their weather updates without having to do anything more than click "install" in SqueakMap.

See this for a photo of a more modern Squeak. This is still a little old, though, from around a year ago. I can use any IceWM theme with Squeak. I wish I had a screenshot of the weather widget I used to use, it was purty.

Another great example- check this out. What we have here is a Windows-like taskbar. Nope, that isn't stock Squeak. First, I installed an IceWM theme (easy as pie) and then I wrote up that little taskbar. See, a newbie popped into IRC (irc.freenode.net - #squeak) and said he wished he had a taskbar like Windows has for managing his open and minimized windows in Squeak. Always up for a small challenge to show someone new how great Squeak can be, I wrote that up for him. The whole process- between updating the people on #squeak as I wrote the code, playing around with colors, doing the actual coding *and* putting it up on SqueakMap for easy download and install took 45 minutes. About 20 minutes of that was spent doing the last step- I had never put any code up on SqueakMap before that, so I had some docs to read to find out what to do. But 25- or even 45- minutes to write up a Windows taskbar? You have to admit that's not too shabby. I can't imagine how long it'd take for something similar to be whipped up for, say, WindowMaker.

That's the kind of power Squeak gives me, a feature I use all the time to make my enviornment more useful.

If you need to communicate with someone, Squeak is not the way to go. Send an email using one of the millions of other solutions.

Why not use both? After all, Squeak does come with an email client, though it does SMTP+POP3 out of the box, IMAP (over SSL to, I think?) was added a while back as well. Nothing weird about it- it's just regular email.

And it goes beyond that. Squeak has a number of fun methods of communication, all very easily installable using SqueakMap. SqueakMap is like Debian's apt-get

You are wrong on several counts.

My understanding of the algorithm is that Xerox devides the Graffiti area into 9 ``blocks.'' The recognition algorithm tracks which block the stylus starts in, the end block, and the blocks through which the stylus travels. The recognition is fast and accurate, because each letter is simply an encoding of (start, end, intermediate blocks).

That recognition algorithm (and numerous variants of it) goes back to the 1960's and has been described in standard textbooks and papers (one example is the Ledeen recognizer, discussed here).

It is also not what Xerox patented. The Xerox patent is not about the recognition algorithm, it is about having the writer indicate when one character ends and another one starts; one instance of that approach is to use a single stroke for each character.

In fact, many recognizers using this old algorithm happened to also be unistroke recognizers--it's an obvious idea--which is probably why the unistroke patent got thrown out, and that's a good thing.

Palm copied PARC's Graffiti alphabet because the algorithm was so elegant.

If only they had, but unfortunately, Palm did not copy PARC's Unistroke alphabet. Unistroke is a much more effective alphabet than Graffiti 1 or Graffiti 2 and not significantly harder to learn.

Keep in mind that Xerox had a Palm-like device several years before Palm, complete with networking. Furthermore, the original Palm technical staff apparently knew the PARCTab work quite well. With their patent, Xerox was effectively trying to protect some of their pioneering work in this area, but they failed. That's not necessarily bad, since bad patents may be overall worse than no patents at all.

But keep the history of this in mind: Palm invented very little of what they are shipping. And, to this day, judging by their nearly non-existent publication record, Palm seems to be doing little or no research. Places like Xerox PARC are in trouble, while Palm has more than half of the handheld market. If companies like Palm keep building businesses on other people's ideas but don't invest in research, who is left to pay for the research?

That being said, I think that Verse is far too low level for the things it is designed to do. I think the Open Croquet project holds far more promise, both because it has a very well developed object-oriented model of virtual worlds (it's based on top of Squeak Smalltalk), and because the scheme it is using for networking has some very good ideas and promises to scale quite nicely (it is based on David Reed's PhD thesis, and it's pretty surprising it hasn't been "rediscovered" before). You can see an impressive (but now quite a bit out of date) video of Alan Kay and another Croquet developer (sorry, I forgot his name!) giving a presentation on the project. Unfortunately, the early demo of the project received a lot of negative attention from some quite ignorant people, and as a result the development of Open Croquet is not currently open to the general public (although if you don't mind becoming a Squeak developer you can certainly participate in it).

Now as to what I think of the funding. It's certainly a lot of money, but I don't entirely agree with the purpose. I think too much of it will be spent on implementation (not that it's a bad thing, as it's all Free Software), but I don't think that either Blender nor Verse foster enough research. Mostly they are doing what has already been done, and at that I don't think they are doing it particularly well.

Can you give an example of your first point? I've looked in the past, and only ever really found Seaside and Borges (a Ruby implementation of Seaside) as real-world examples of the use of callcc.

(I understand CPS as an optimization technique, but that doesn't require or typically use first-class continuations like callcc, so it's something of a different issue, I think.)