I’m guessing by the Smalltalk IDE, you mean Squeak 3.9.

Have you seen Squeak with FreeType installed. It helps a lot.

Also, there is help coming soon:

http://news.squeak.org/2007/07/15/more-eye-candy-coming-soon-to-your-squeak-desktop/

Ruby/Rails exists and it is a very well known technology. More documentation appears every day, books exist, and you can get information about the basics, to advanced, information on scaling, etc. by people who have encountered these issues and how they solved them.

With Squeak/Seaside, it’s a much murkier place. Persistence is not solved. There is no real ‘packaged ready to go’ persistence solution for Seaside. This is a problem. There’s no nice minimalistic image for Seaside, and everyone doing anything real with Seaside is not using the default 3.9 image, they have some custom 3.7 image, which just fuels the confusion. How do I minimize the image, etc. (This is one of the first things they are presented with as a complete newcomer) Then the issue of scaling comes in, etc. and this is just a couple points off the top of my head. There are few answers and the ones that exist are scattered everywhere and not necessarily generally applicable.

The accessibilty as well complicates things… to just mess around with ruby/rails and put up something public to see what happens all you need is a hosting play for 8$ a month. With Seaside, you need to invest in some VPS plan at $40 a month and it probably won’t even perform as well as the $8 hosted plan. This is an issue.

Squeak/Seaside is just very large and definitely not for the faint of heart. The amount of effort to put in before any results are realized is HUGE. This is the problem. It’s like throwing all your eggs in the basket and just hoping its all going to work out. I realize its for early adopters and people to make a difference, so we shouldn’t be baffled by the fact that people aren’t adopting Squeak/Seaside in droves… and the ones who might adopt, its tough, cause they are already probably invested somewhere else so they’re just continuing to improve that. The learning curve is huge, and its hard to justify the gain for the work that is necessary to achieve it.

Referring to your post on the standard code browser, I’ve been striving for this goal: naming things properly. It makes such a difference. One of the things I’ve discovered is that unlike other languages, in Squeak I can pass a message to a class/object even though the method doesn’t exist yet. Squeak will point out to you “Hey, what method are you talking about?” when you go to compile the code you’re writing, and it will offer some potential corrections you can put in its place, but you can just tell it to accept the message you wrote. It doesn’t seem like it goes ahead and creates scaffolding for the method. It just warns you “Are you sure you want to do this? It doesn’t exist yet.” You can then write the target method later. What this allows you to do is to set up your names from the top down, if you want, so you can get an idea of how well they will represent what you’re doing. Paul Graham has talked about doing this in Lisp as well. He says sometimes he prefers to go bottom-up, creating low level functions first, building up to higher level abstractions, and other times he does it top-down, where he defines the language he wants to use first, and then fills in the details of it later. Sometimes he does both.

I used to think that when you name things well it almost obviates comments. I’ve changed my view on that some. I think comments are still necessary at certain levels of code, but it should be minimal.

Someone commented on here that often there are no obvious start points for things like Morphic apps. (which do have start points). Ramon’s answer is mostly correct that you can “start anywhere”. The situation where you need a start point is when you reach a point of specialization, called an “application”. Things like the code browser, Monticello, are apps. within Squeak, and they all have their start points. In terms of using the code that is there for something you want to do, Ramon is right that you can really start anywhere. I think I’ve finally understood what reusability really means, because I can add methods to standard classes that I want to use for a specific application I’m writing. What’s awesome is that loose coupling is built in, pretty much. I can reuse those methods I’ve created in other projects. They look no different than the methods that are already part of the existing classes. So as I build apps. in Squeak, I’m building up a code base that I can use for other projects.

I’ve reached a point (learning curve) where I reaally like it and appreciates its power… The only boring think is I find it tiring to use (maybe I’m a bit lazy too ;) ).
To me there is to much mouse movements. Selections ares ok but when you end up with plenty of opened browser, I find myself spending a lot of time in opening, closing, bringing to front browsers instances… And when it’s late, it’s tiring … Also, moving code panes, shrinking, expanding windows is way to long…

I don’t know well how to solve that, but to me, the barrier (in squeak) is all a question of ergonomy… When you first look at menus, you just want to leave…

Of course there are some tools and directions that can help:

- there are addons to shortcut like alt+tab…
- there is a cascading implementor/senders browser…
- there is a way to organize windows (morphs ;) ) so as not to overlap (reverseWindowStager). It’s not bad but you need a big screen…
-… and of course, you can tweak the UI to fit your needs…

Anyway, no real standard ways of doing… Maybe a post on good UI a la smalltalk practise could help decide what is the way to go … after what we could “implement” a simpler and more ergonomic developer UI that will fit damien efforts…

Globally, I think that would very nice to consider ergonomy as much as documentation, but squeak community is small… and mainly composed of builders or hobbyist like me…

FWIW, Cédrick

ps: oh and I forgot, there are too many browsers… OB is probably the one to choose (but slow with some options). I like also the package pane browser.

Compare Smalltalk to Ruby, which also has open classes but isn’t a runtime system but rather a file based system which rebuilds its runtime each time it starts up. Ruby makes packaging easier since you can simply not include something like eToys on the next run.

Smalltalk however, being image based, makes it much more difficult to seperate what *is* eToys from what *isn’t* because it’s been in there so long that lots of other code depends on things that were added to the image by eToys.

Monticello, our current source control system that allows us to package our code external to the image and share with other developers came along much later, so many things written before that weren’t written that clearly drew boundaries between packages like they do now.

Of course, now that we have Monticello, the community is trying to push everything in that direction and tear apart the dependencies of all the older stuff and make the base image much more modular. That and testing is in fact the primary focus of the next version of Squeak, 3.10 headed up by Ralph Johnson. 3.9 was the first version of Squeak to use Monticello as its primary code distribution mechanism, prior to that development was done via the update stream and changesets.

http://www.notarianni.org/index.php/2005/09/17/object_orientation_enlightenment

One of the fastest ways to pick up new things quickly is to learn to set aside your preconceptions and prejudices, they just get in the way of learning.

Squeak isn’t hard to learn. Smalltalk isn’t hard to learn. It’s just the things we’re accustomed to are hard to unlearn.

Squeak doesn’t have that corporate/big project fit and finish many like, but it does have an openness and freedom few have experienced, it’s turtles all the way down. You can hack and customize anything in it to work however you want it to work.

When Avi Bryant wanted to use continuations in his web framework, a feature Squeak didn’t have at the time, he simply added it in about 15 or so lines of code. He didn’t have to wait a couple of years for the language to evolve, and adding continuations isn’t exactly trivial in most languages.

For anyone that has read the classic sci-fi book Ender’s Games, remember the enemy’s gate is down! :) Or from the Matrix… Do not try and bend the spoon… that’s impossible. Instead only try to realize the truth… There is no spoon. Ok I watch too much TV. My point is… Don’t try to bend or look/learn Smalltalk in the light of other language environments… that’s impossible.

If you approach Smalltalk with an empty and open mind you’ll begin to see is true simplicity, power, and beauty. With this approach, anyone is able to learn Smalltalk, Squeak, and Seaside much much faster than they could learn Java, Servlets, JSP, JavaBeans, Reflection, Generics, Tomcat, XML, Struts, ANT, and an IDE. Let’s not even discuss J2ee. With Smalltalk you’ll code better and have a lot more fun.

Oh yeah… I use Eclipse daily. And Smalltalk Browsers are far easier to learn & use than any of the major Java IDEs.

How to learn Smalltalk, Squeak, and Seaside?
1. Empty your mind
2. Make sure your mind is empty
3. Start with the learning Smalltalk and Object Thinking (links to free pdf books are on squeak.org)
4. Learn Squeak with books (amazon.com) and by discussing on online
5. Learn Seaside via online tutorials and reviewing code examples
6. Ask for help (tons of discussion groups)

Note: Everything you do in Squeak is modifying the running image. If you save and quit, you’ve created a new custom image. If you leave a web server running when you save the image, it will start back up when you open it. People do that with Seaside presentations in Squeak so that the localhost server is running in the background.

Start with tweaking Preferences. If you want more look stuff, review LookEnhancements. If you want to write an “IDE” start with the papers on OmniBrowser and try to write a new tool.

The harder part is bundling up your customizations so you can quickly load them into another image. Best if you can make them easily unloadable. Save that for later.

Eventually, you’ll want to use Monticello for version control, SqueakMap, and PackageUniverses. But Squeak has OK version control built in and Monticello is really a simple thin layer on that. (Read the docs).

Re: adding and removing stuff from an image

For the simplest form of what you’re talking about I’d take a look at Monticello. You can use it to add and remove some packages. Ramon wrote a post and created a screencast on using Monticello here. There appears to be good written info. on Monticello here. If you want to remove other stuff, like eToys, it’s better to just get a pre-built image which has stuff like that removed, which you can find here (look at the Pre-Configured Images section).

For learning more about Smalltalk and some of the tools, I found a site here that has some description of these things. It has a Squeak tutorial, called “BankAccount” (under the “Programming” link). It seems like it was a site designed for use inside Squeak, but you can read it in whatever web browser you have. Most of the menu selections just talk about what Squeak is and how wonderful it is (bladdy-bla). You’ve probably gotten your fill of that here. :) If you want to dive right in I’d start with the “Language” selection, and then move on to “Programming”.

As is the case with many sites on Squeak some of the links are dead. One of the dead ones on this site is supposed to point to a site with links to free books on Smalltalk. The current, good link for that is here. Just keep in mind that probably not everything you read in these books is going to apply to Squeak. I suspect that most of it will though. That’s what I’ve had to deal with with Squeak. The most current information out there is usually on mailing lists or blogs. Going to a static site to get current information on Squeak, or Seaside for that matter, is hit or miss. You can get some valuable information from them, but some of it is going to be out of date.

The guy who made the site has a decent write-up on his experience with Squeak. He explains some things I think you’d like to know, like for example, “Squeak is not well documented”. And he says for the uninitiated the commercial Smalltalks (like VisualWorks or Dolphin Smalltalk) are better, mainly because they have much better documentation. Incidentally both VisualWorks and Dolphin offer free versions for developers. You’d have to take a look at their licenses, but I suspect they don’t want you using the free version for commercial use. I don’t know what “help” documentation the free versions come with, if any. You may have to do a purchase to get decent doc’s.

Anyway, hope this helps.

A lot of the objections to Squeak/Smalltalk have to do with aesthetics or the fear of being “locked in” to an environment that dictates rules to them. If somebody wants to create a mod for Squeak that allows people to use their own editor, use files, etc., they can do that. The whole thing is open source. The entire system is written in Smalltalk, even the VM (though it’s kind of a special case). There’s nothing preventing anybody from creating the system they want with it. It’s just a matter of somebody taking the time to learn it, and then modify it. I know this is a turn-off (believe me, I know!), but there’s a saying in the open source world that goes, “code talks”. If you want to see it happen, make it happen. Unfortunately, probably with the exception of the Mozilla project, you can’t just appeal to an authority to get your desires realized unless you can convince someone more knowledgeable that your idea is a great idea and should be implemented (you inspire the desire within them to create it). Otherwise there’s just you, and whoever agrees with you, to help make that vision become reality.

Here’s what I think is going on. When Alan Kay, Ingalls, and Goldberg first designed Smalltalk they did it with an educational focus in mind. The first people they showed it to were kids in school. Squeak still has that focus. It is a serious tool that can be used for serious things. It has the power for it, but in terms of approachability to the user interface, their primary focus was on making it easy to draw, put text and graphics on the screen, and make it easy to manipulate. The intent was to gradually introduce people to programming and the tools associated with it, not to get them doing that right away. It appears that little effort was put into providing that same level of accessibility to adults with a different agenda. Maybe they don’t want to draw and put things on the screen just for the sake of being creative. Maybe they want to accomplish a particular set of tasks. Doing any of that takes instruction. It’s not immediately approachable the way the “kids stuff” is.

There was a discussion about this over at Giles’s blog not too long ago. Elaborating on what I said earlier, RoR has an appeal to web developers because, given the skills they have, it provides an “instant gratification” that’s very real for them, in the same way that Squeak does for graphics and text. In that way it’s approachable. That approachability makes it “worth the trip” to learn about more of it. Seaside lacks that approachability right now. Not to say that it’s less useful or powerful–not by any stretch, but that people tend to become passionate about it for other reasons first.

For me, it was the language. I got introduced to the language (not the whole Smalltalk system) years ago, and really liked it. I was also really impressed with the legacy of the Smalltalk system, the fact that almost 30 years ago it inspired Apple to create the Lisa and the Macintosh, and ultimately Microsoft to create Windows. Neither Apple nor Microsoft really captured the essence of what made the Smalltalk system powerful. They used it as a model to make computers more accessible, but they left out the aspect of letting people bend the system to their will, to customize it to be just what they want. Their systems were really an object-oriented facade over a traditional, non-object-oriented system. They lacked a consistent metaphore of everything being an object. The web has been even more stultifying in this regard (I mean the web interface), though Firefox has helped some, so I hear, with the concept of browser extensions. Maybe there was a reason for this.

DHH in the same webcast I mentioned earlier said that the “blank page” philosophy of some tools and environments doesn’t work so well with developers. They tend to be less productive. He said what Rails does is create a “filing cabinet” metaphore so that everything has its place. It guides people in the right direction. I think there’s a rationale for that. I saw this same thing in action when I used Visual Studio. I wouldn’t say it has the same “filing cabinet” metaphore, but through its design interface and code generation capabilities it did lead me down a path. The problem was sometimes the path it led me down wasn’t what I needed, and made the job harder, not easier in the long run.

Even Seaside “leads you down a path” in a way through the task and component structure it proscribes, but to me this approach allows me to make choices, because it’s in code. It’s minimalist as well. I’m not working in an environment that tries to coax me into taking the “easy path”, which ends up not being so easy later on. Not to say that ASP.Net wasn’t a good experience for me. It helped me get used to writing web applications in a non-threatening environment, but I’ve grown beyond that now. I desire more power and flexibility.

For example, someone experienced can create his own Web framework, text editor, IDE, ORM, template engine, and so on, so he is not restricted to what is given to him by others.

On the other hand, someone relatively new to Web programming for example, may find that he doesn’t have the skills to create too much custom CSS, JavaScript, database CRUD operations, and so one, so he would be looking for a tool like Seaside to provide as much of such things out of the box as possible.

And the way I see you Ramon, who promotes Seaside/Smalltalk, is not a lot different than the way some newcomers to Rails/Ruby who promote them… Even if your tools are superior given your perspective, someone who has used Rails to create several applications/sites may also think that it is superior enough to not be bothered with “alternatives”.

For example, Rails has many hosting companies nowadays which help you administer your sites/applications. I was checking out on the Scala mailing list (Java language alternative), and someone asked if anyone knew some good and inexpensive hosting solution, to which the consensus was that it would be better to rent a virtual space/machine and to install what he needed himself. Now, as far as I know, many Rails hosting solutions are thriving in comparison.

The Seaside creator also created IOWA in Ruby before creating Seaside in Smalltalk, and IOWA is maintained by someone who uses it on a dialy basis to power his commercial services/company for several years already.

It’s all about finding the audience. I know someone who used to promote Squeak and even a little of Seaside as well, but I was always more hardcore then he is. I’ve created my own Web framework in Ruby and am now creating my own JavaScript library, and I have already created a “Data Grid” and a custom “ComboBox” with a drop-down list and autocompletion, but I am in the process of re-coding the Data Grid to break it into smaller components which could be easier to reuse and test.

Thus, I don’t think I am part of your audience, but I am always trying to learn something new as well. :-)

Squeak BTW, has alternative IDEs like the Whisker browser that lets you see and edit several methods at once via stacked editing panes.

Let’s not mistake me for a Smalltalk/Squeak expert, that I’m not. I’m just Joe random programmer who picked it up and liked it and have learned to use it within my domain. I’m not at all saying these things shouldn’t be fixed, I’m a realist, I’m saying don’t hold your breath. Learn to like it as it is, and then contribute what fixes you think you personally can make.

I don’t have the skills to fix many of these issues, especially since many of them deal with Squeak’s Morphic UI, but these things don’t need to be fixed for Squeak to be useful, especially in the context of Seaside apps.

In my barriers to entries post, I was looking for where people need to be taught things, not what needs fixed in Squeak. I can’t fix all of Squeak’s ills, but I can help teach people who are interested, how to use it as it is. In time, you will learn to like it, I did, as have many others, it grows on you.

In the “Design principles behind Smalltalk”, Dan Ingalls talks about that Smalltalk should be entirely comprehensible to a single individual and that any barrier that exists between the user and some part of the system will be a barrier to the creative expression of that individual. In the “Barrier To Entry” post, most of these barriers seemed to refer to the usability of the Squeak IDE. What puzzles me is that Smalltalk/Squeak experts seem to like to say that Squeak is not for everyone and that they like (or don’t mind) the way it is now. Squeak is designed with a minimum set of unchangeable parts but if the Squeak community still intends to adhere to these design principles they will need to address these barriers, because newcomers don’t have the skills yet to do it themselves.

As for the “Oh yeah, Java Server Faces has all that”, no it doesn’t, it’s not a continuation based framework like Seaside, and I doubt many Java developers are even well enough informed about what Seaside can or can’t do to even render that judgment.

There’s Seaside, Borgs, UnCommon Web, and the PLT Scheme Web Server *that I know of* that are continuation and offer the same benefits more or less as Seaside. The others being Ruby, Lisp, and Scheme, I doubt any of them even have a community the size of Seaside. Other frameworks crudely “fake” some of the benefits, but only crudely, and only some of the benefits, and none of them offer the environment Smalltalk offers.

The way to get the benefits of the language and the framework is to “change your mind” about what software development is. I’m still in the process of doing that. I think the best way to do that is to get a book on Squeak or Smalltalk. Get familiar with the environment and its way of thinking first. Then move on to Seaside. A book I got that really helped set the groundwork for understanding Squeak for me is “Squeak: Object-Oriented Design with Multimedia Applications”, by Mark Guzdial. I’ve heard several people say, “Squeak should take the multimedia, Morphic stuff out”. Don’t be turned off by the title of the book. It teaches the basic tenets of Squeak and what tools you need to become familiar with to do development in it. It also teaches the language. It does have a text and graphics focus. It doesn’t talk about using it for the web much. Once you get familiar with the language and the tools, then you can break away from it and learn Seaside, the web framework, and Monticello, which is a version control system for Squeak. Guzdial’s book doesn’t talk about either of them.

Squeak kind of has its own rudimentary VCS system built in. It keeps track of stuff you change in code by itself, and you can always revert back to a previous version of a method if you want. “Undo” is one of the features that Smalltalk pioneered. What Monticello adds is the ability to attach a release version number to a package of classes, and the ability to restore the package to that version if you want it to. Monticello works on a package basis, not a class basis (or file basis–you don’t refer to classes or methods by filename, but by whatever you named them in the system).

The best reason I can think of that RoR has taken off is that it has qualities that developers of more traditional languages like, particularly the ease and quickness of getting a site up and running. This alone makes learning the rest of it (the language and the framework) “worth the trip” for them, if they even get that far. I’ve been tracking Giles’s blog, and he’s talked about some RoR developers who don’t know that much about the language–they don’t have to, apparently. Those who do want to delve into the language have to get over static typing, but since it has Perl-like qualities, there are many developers who are familiar with that, and there are many web developers who have had some experience with Javascript. It also doesn’t have the best IDE, from what I hear. That’s another possible barrier. Other than that it’s file based, so at least that’s familiar.

Giles covered this in his blog, that part of the decision-making behind RoR was a marketing focus: Create something new and more powerful, but at the same time familiar enough that people could get used to it. So Ruby is an intermediate step between Java/Perl/Python and Smalltalk. It’s another step in the learning process. As I’ve said before, I think things are converging to where Smalltalk is, over time. People don’t understand it now, but they eventually will. People learn by extending beyond the edge of their knowledge just a little bit. They use bridges between what they’re familiar with, and what is new, to gain knowledge. Squeak for many is a bridge too far. Even though Ruby is hot now, it still has a long way to go to get to a point of general acceptance. Even though it makes an effort to bring people along, it may also be a bridge too far for most developers.

Also, from what I understand Seaside has lost some of its distinctiveness. Last week I got together with a friend and I was describing the qualities of Seaside to him. He said, “Oh yeah, Java Server Faces has all that, even persisting session state for you.” I told him about how easy flow control was in Seaside, and he said JSF has that, too. I don’t know if he was just glossing over some important details, but I was a bit surprised that the JSF developers had, it sounded like, managed to create many of the advantages Seaside had, in Java. Not that I particularly like Java as a language at this point, but this could create a barrier to people moving to Seaside or even RoR, because people will say, “I have that where I am now”, though I think Rails and Magritte/Glorp still offer advantages in terms of accessing a database. Hibernate is still a bitch, from what I hear.

By the way, from what I understand Seaside works in VisualWorks (sold by Cincom Software), if people are interested in a more polished Smalltalk implementation. That’s been the case for quite a while. I believe developers can download VW for free. They just can’t use it for commercial purposes without a purchased license.

Squeaks place is in experimental UIs and VMs where it’s openness and flexibility let you try out *new* idioms and modify the language however you see fit, things like Sophie and Croquet. It also works in server based scenarios where it can run headless as a server, like with Seaside.

Using Squeak for end user applications however, is just going to be a painful road full of hurdles, that’s just not what it’s good at.

See: http://drupal.lordzealon.com/node/39

About a year ago, I didn’t started a project yet (i’m only as observer and don’t have time) but I have the same problems.

More screencasts about projects for users (no developers) could be good for the community.

At the moment, I need to start a POS (Point of Sale) project (not webbased at the moment), and, is good the NewCompiler posts and all the other, but this, don’t help me to learn and start with Squeak. Squeak is used for experimental projects, and this is good, but, what happen with people like me thath I need, now, something to offer to my clients, and don’t know how to start with Squeak/Smalltalk?

All the information on the Net, is about “browsing the image” to learn, but nobody, go to the important thing (al grano en español).

I, and others I think, don’t need at the moment knows how NewCompiler or Nebraska or althoug SeaSide works, we need to know how to develop app’s to the end user. And this is a missinformation in the Squeak World.

Browsing the image is not always the best solution, and practice examples yes.

I think this is all are speaking about, Ramon, and you, and others good Squeakers can help us with this.

If I ever appear to be dogging on those languages, I’m not, I’m dogging on users of those languages expectations that Smalltalk needs to conform to that model. I don’t care a bit that Smalltalk isn’t popular, in fact, I rather prefer it. I only care that it’s popular enough to maintain a community of passionate developers.

The things that make me love Smalltalk are exactly the things that also make it unpopular. Image based development, the isolate environment where everything is an object, the lack of files, the custom and more advanced source control tools that are language aware, the completely open environment where I’m only a hotkey away for the source code for any framework I use, the *code is the documentation* attitude of the community.

In essence, deep down, I’m a purist, and I *like* that Smalltalk doesn’t compromise itself to fit into the world around it, it doesn’t need to. I like when I work in Seaside that I don’t have to work in any language or markup other than Smalltalk.

The last few posts have gotten quite a few enlightening responses, I have much to think about, as do quite a few other Smalltalkers who I’m sure are following some of this. I honestly didn’t realize people found Squeak so damned confounding.

I wish the docs were better, though. More screencasts would be a definite improvement.

What’s wrong with this picture is exactly the purpose of the post. The question is why is the Smalltalk (particularly Squeak) so jarring. It keeps people out.

Squeak is strange. It is the only IDE I’ve ever used that I could figure out how it works by tearing it apart while it is running. Want to know what code to write to save the image? Bring up a halo, drill into the specific menu item, inspect it, and see what method the click fires.

Squeak isn’t mainstream. Smalltalk isn’t mainstream. They both have things to admire.

Ruby and Python are both cool. I hang out at the local Ruby group (I’d go to the local Smalltalk group, but it would just be me). Ruby as a language has a lot to admire.

Cool language, but the tools are all Unix-y. Not that there is anything wrong with that.

In Squeak, the language is cool and the environment is cool. But they are both very strange.

The trouble is, the strange is the cool…

For one thing, you yourself said that it’s not for mainstream use, and that you use VS.NET with ReSharper and like it, but you also like Smalltalk and Seaside, but you seem to dislike the idea of dynamic languages like Python and Ruby being much more popular than Smalltalk, and you might even hate that Web frameworks in those languages are much more popular than Seaside ever will be if it doesn’t become mainstream.

What’s wrong with that?

And I’ll say it again… that’s a lot of tedious work, and no one is funding it. There are those doing it, Pavel’s mini image is about 7 meg with no UI and only a REPL. DabbleDB is hosted using one of these as its baseline image.