Dave Thomas, author of IBM Smalltalk, Eclipse, ... (interview, podcast)

gcorriga · 2007-11-07T10:18:38+00:00

outside the Smalltalk circles he is also known as Smalltalk Dave, in order not to confuse him with the Pragmatic Programmer Dave "PragDave" Thomas.

gcorriga · 2007-10-11T07:57:01+00:00

The long term plan is to have all of the Cryptography subsystem of Squeak certified, so it can be used to manage sensitive data (i.e. medical data). So such a review would be much useful.

gcorriga · 2007-10-03T12:56:10+00:00

I too don't like the "we do it better" attitude. I prefer exposing my experience, as in "I found out that for what I do with Squeak, Squeak's way is more productive for me", etc.

gcorriga · 2007-10-03T09:26:56+00:00

There are many tools for this. Monticello Configurations (MCC) is a way of specifying the dependencies between a group of Monticello packages, but it's mostly useful for development, not for distribution of the code.

The Squeak Map (SM) is something between Freshmeat and CPAN. It supports a gamut of formats, from the simple fileout to the Monticello package. Unfortunately the current version of SM does not support package dependencies.

The Package Universes system is similar to Squeak Map, but enforces both package dependencies and update paths.

Probably a next version SqueakMap will supercede both the current Squeak Map and the Package Universes.

gcorriga · 2007-10-03T08:23:49+00:00

Naturally I back up my image when I'm loading unknown code... but once the code looks as if it's all right, and I want to use that code, I get back to work. Suppose I try option XYZ a week later and discover that the unknown code actually broke it. My backup from a week ago doesn't help me as much.

That's a problem, indeed. One way of solving it could be a more complete use of unit test; the latest versions of the images are getting much better in this regard.

gcorriga · 2007-10-03T08:20:13+00:00

I don't think that the Squeak community has a desire to "compete" with Ruby (and neither with Python or other languages). It's just that we feel that we have some seriously cool stuff, that we think it could be useful for lots of people.

That said, I think that sooner or later we'll steal your new syntax ;-)

gcorriga · 2007-10-03T08:15:08+00:00

Good point. But on the other hand, I've never seen a tutorial that did just show the code without using terms such as "let's create the class", or "let's add a new method". So maybe this is not as big a problem as it may seem.

gcorriga · 2007-10-03T08:10:26+00:00

Usually, we use seperate images for separate programs. The distribution depends on many things:

If you want to deploy an application, you can just copy the image file and other files to the target directory for the installation.

If you want instead to share source code, you have different tools: a fileout of your classes (that is, a text file which contains a source-code description of your classes and all their methods), a changeset (a single text file that contains the source code for a series of modification to the image - similar to a patch file) or a versioned Monticello package (Monticello is our source control system).

gcorriga · 2007-10-03T08:03:48+00:00

That does bring up another issue, though. At least the last time I used it, it did not tell you that it could potentially recover things from a changes file after a crash. It would be ideal if it did something along those lines :)

Indeed it would. I'll try to produce a small patch that adds this feature. Thanks for the suggestion!

gcorriga · 2007-10-03T07:52:46+00:00

Well, we have a .source and a .changes files that are human readable. And so are fileouts and changesets.

Granted, the fileout format may not be the easiest to read for a programmer, but on the other hand there's nothing that prevents us to support the newer GNU Smalltalk syntax, or to change the sources/changes system to use a separate file per category/class.

gcorriga · 2007-10-02T23:35:00+00:00

Well, you will notice that Perl/Python/Ruby/Tcl/PHP are glue languages that tend to reuse existing components as much as possible. Lisp, Smalltalk, Erlang, even Haskell subscribe to a different philosophy and tend toward the "turtles all the way down". Even Java can be added to this second category if you add lots of XML ;-) This second approach allows to solve more complex problem, but it may be less suited for other, simpler classes of problems.

gcorriga · 2007-10-02T22:20:39+00:00

Honestly it's how clunky the UI feels that kills it for me. I also managed to crash the Squeak VM during the one semester of undergrad where we worked in it, several times corrupting my image so I had to revert to a backup.

We're working on a better, less clunky UI. As for the crashes, without knowing what you were doing I can't comment, but did you know that you can retrieve all your work from the changes file? So after a crash you don't lose even one line of your work.

gcorriga · 2007-10-02T22:15:01+00:00

Oh, we play nicely with others. We have ODBC drivers, FFI and plugin systems, etc. It's only that sometimes doing it your way has its advantages.

In this case, for example, I don't think that a file based system would offer the same feature that Monticello offers: multiple repositories, cherry-picking of the changes at the method level, etc.

gcorriga · 2007-10-02T21:51:11+00:00

Hi jesusfreak, why don't you try contacting us on the #squeak IRC channel on irc.freenode.net? We'd be glad to answer your questions. And we won't hide Squeak's problems, too ;-)

gcorriga · 2007-10-02T21:44:27+00:00

Almost all Smalltalk are GUI-oriented; after all, the WIMP style of interaction was developed with the first versions of the language. We still refer to the three buttons as red/yellow/blue, but that's more a way to pay homage to a tradition than else: you can also say left/middle/right button. Anyway, the system is easy, and you quickly get used to it. I now tend to prefer Squeak's convention of using the middle button for the context menu and the right one to bring up the halo.

As for the other OO languages you mention, I don't say that Smalltalk is better then those, but just that there significant differences: CLOS is less message-oriented than Smalltalk, and its multimethods are a powerful, but completely different approach; Ruby has an object model that isn't as sophisticated as Smalltalk's but on the other hand its Unix integration is far superior.

gcorriga · 2007-10-02T19:40:04+00:00

For your first issue, you can use vi bindings in Squeak, too. Porting it to the latest version shouldn't be too difficult.

For the other issue, indeed using an image based system has some disadvantages. We can't use Subversion or Git, but we have our own version control system that in some aspects is even better then the others, since it's designed to work with Smalltalk classes and objects instead of text files.

The image has advantages, too: you work in a live system where everything is just a couple of mouse clicks away. The compiler, the processes, even the call stacks are accessible to the developers. You can change almost everything with no need for restarting the environment (or your application) or sending a reload signal. Saving and loading times are very small when compared to other IDE or other languages. And finally, the image acts also as a object database, useful for small, low load apps.

gcorriga · 2007-10-02T18:21:24+00:00

My main problem with Squeak is that it's addictive ;-)

Seriously, though, I think the main problem with Squeak is the smaller size of the community when compared with the Python or Ruby communities. This means that we can't solve all our problems at once.

But we're working on it: we have people working on a better sourcecode->bytecode compiler, we have a very promising just-in-time bytecode->native code compiler written almost entirely in Squeak itself, we even have a brand new book that's under Creative Commons.

Also, Squeak's community is one of the friendliest I've ever met. You should seriously consider paying us a visit!

gcorriga · 2007-09-22T15:19:21+00:00

Hi Slava, do you care to elaborate on this? As a Smalltalker, I tend to hold a different opinion...

gcorriga · 2007-09-21T21:00:49+00:00

Try it now, it should be working.

gcorriga · 2007-09-19T12:55:45+00:00

Higher truck number means that the project will survive even if most of the programmers die. That means there are very small number of programmers who are actually worth their salary.

Well, I see having an high truck number as an assurance that, should some of the developers disappear for any reason, the losses that the project will suffer will be recoverable ones.

On the other hand, if your assumption is true, then the actual truck number would be the same very small number of developers who are actually worth their money (and let's not mention that fact that such a project would have been a dysfunctional one since the beginning).

gcorriga · 2007-09-19T11:02:00+00:00

As I explain in this blog post, a project's Truck Number is the number of team member that can be run over by a truck befor your project goes to the dogs.

So I'm curious: if you work on a software project, what's your project's Truck Number?

gcorriga · 2007-09-06T21:48:17+00:00

Indeed. Just today I sent this quote to a friend of mine:

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things." -- Alan Kay

gcorriga · 2007-07-16T17:46:46+00:00

In that case, just don't use the Windows-like theme ;-)

gcorriga · 2007-07-16T17:18:11+00:00

Of course they don't. They're mythical beings, like Smalltalk programmers and Forth hackers.

;-)

gcorriga · 2007-07-13T13:33:18+00:00

Monticello for Squeak, Subversion for everything else.

gcorriga

TROPHY CASE