On the Smalltalk Browser
By Ramon Leon - 17 June 2007 under Lisp, Programming, Ruby, Seaside, Smalltalk
Some of the comments in the Barrier To Entry post bring up the point that maybe the Smalltalk IDE itself is one of those barriers.
It's an interesting thing, the Smalltalk browser. Unlike most IDEs, it's optimized for reading code rather than writing code. Other IDEs allow you to see any number of methods all at once, cutting and pasting text giant chunks at a time, they sure make you feel like you're working. They don't however, allow you to navigate the semantic structure of the code very well nor do they encourage the writing of well-organized code.
Modern IDEs are getting better at this, but they're doing it by copying Smalltalk. Smalltalk's various code browsers (hierarchy, method, inheritance, senders, implementors, protocol, category, package, refactoring) let you explore the structure and relationships between existing code and its tools (transcript, workspace, method finder, message names) make finding and using existing code, or understanding existing APIs vastly easier than any other language I know of. Seeing the structure of code is always but a context menu or hotkey away.
Smalltalk's browser is rather opinionated, luckily, thanks to Rails, opinionated software seems to be having somewhat of a revival. When it comes to writing code, the browser forces you into a certain mindset, one that other languages don't force you into. When I create a method in Java/C#/Ruby, I have to choose little more than what file and class it belongs in. I can organize the code well, but there's little incentive to do so and my unit of work is rather undefined, I could be slicing and dicing methods, classes, namespaces, etc., usually with the full screen devoted to code across various files or even god forbid in one giant file. This encourages a code now and organize later approach. Sadly, later often never comes, and the code is left functional but messy.
Smalltalk on the other hand defines my unit of work as the method and by doing so forces me at every turn, to continually organize my code in semantically meaningful ways. When I create a method, I have to choose a class category, a class, and a method category to put the method in. If I don't, Smalltalk kindly categorizes the method for me in a protocol called "as yet unclassified". It's almost an insult, but it's also a not so subtle reminder than I'm writing code sloppily, faster than I'm thinking. It reminds me to slow down, think for a second, where does this thing belong.
It only takes a second to pick a meaningful category name, and these names are idiomatic, I see them all the time when I'm looking for code. Aha, we've linked writing code to reading code. By taking the time to properly categorize my methods I also learn where to look for code later, when I'm in reading mode. It's a feedback loop, the more I read the better I write and the better I write the more I learn to read with accuracy, looking only where necessary. It's as if the code itself is a concise form of documentation hyperlinked by semantic meaning using things that Smalltalkers call browsers. Browsers and hyperlinks, bah, that'll never work!
And RDoc, what the fuck is that, looks curiously like a Smalltalk browser to me, but why should class comments be anywhere except on the class itself? Oh, that's right, Ruby doesn't have a Smalltalk browser, they code in files, how quaint.
As for editing the method itself, I work on and view only one method at a time, and only the lower half of the browser is for editing code which punishes me if I write long methods that can't fit into that tiny pane. Smalltalk at every turn encourages me to read more code than I write, reuse more code than I otherwise might, and write smaller simpler methods than I likely would in a text editor.
Writing smaller methods forces me to give them meaningful names. Giving them meaningful names and putting them in meaningful places makes the code easier to read and easier to find. Code that is easier to read and easier to find, is easier to reuse, easier to understand, and easier to compose into new solutions. It's called bottom-up programming, the foundation of which is small composable methods.
I keep using the word small, maybe that's a mistake on my part, what I really mean is concise. Methods with a single purpose that is clearly summed up by their name. These kinds of methods happen to be short in general, but that's a side effect of their being focused on a single task. The Smalltalk browser encourages these kinds of methods by making writing long methods or paying attention to too many methods painful. Text editors are general-purpose editor aimed at text, that could be anything from a blog post to a novel. Surely an editor intended only for code, and only for a particular style of code, can be made much more domain-specific.
The Smalltalk browser is such an editor, its domain is highly factored heavily structured bottom-up style object-oriented code. If that's the style of code you like to write, you'll find the Smalltalk browser wonderful, if not, you'll find it painfully opinionated and rude.
Take a peek at decompiled .Net framework sources, or Ruby sources and what you'll find, are average line per method counts in the 50+ to even 100+ ranges. In Smalltalk, around 10 or so. To me, this is a clear indication that text editors are the wrong interface for writing clean simple well-factored reusable code. Sure, I just pulled these numbers out of my ass, but they reflect my experiences and even then, I'm being polite, 1000 line methods are not at all uncommon in .Net.
Maybe adjusting to the Smalltalk browser is similar to adjusting to Lisp's parenthesis. It's something you desperately want to fix as a newbie and make it work like other languages. In Lisp's case, trying to design an infix Lisp while in Smalltalk it's a text and file-based editor. In both cases, once you stop fighting the language and realize the difference is actually a great strength of the language rather than something that needs to be fixed. You realize it's you that needs to change, you open your mind, accept that sometimes different is good, and take advantage of the new power these tools give you.
Experienced Lispers love their parenthesis and experienced Smalltalkers love their browsers. Rather than seeing the Smalltalk browser as a barrier, maybe, just maybe, you'd be better off seeing it as a new toy to play with. Something new to learn.
UPDATE: Here's a few admittedly cramped screenshots of the various browsers. They do of course look much better maximized on your monitor.
Comments (automatically disabled after 1 year)
The issue with the browser, the first one, is that it's not well suited for reading the code. It's well-suited for reading the methods. But a smalltalk application seems in general to have nothing pointing to "start here", and rarely has any overall structure that can be deduced simply by reading the code in the browser.
Charlie, there's the facility to add documentation to the class. The problem is that so little advantage is taken of the opportunity.
The Squeak browser isn't that clunky, once you get to know it, one might criticize vi the same way. How many newbs get stuck in vi and can't exit.
Charlie, reading the methods is reading the code, and ideally they're named well enough that you don't need to look at their implementations to use them.
As for where to start in an application, these are object oriented programs, there is no main(); Start anywhere, it's about getting to know the objects and how they interact.
"rarely has any overall structure that can be deduced simply by reading the code in the browser"
That's not true at all. In a framework, start with the classes you're required to subclass, look at their hierarchies in the hierarchy browser and see how they're specialized. Browser users of the classes to see how they're generally used. That's the whole point of all these browsers, they show you that overall structure that you couldn't other see in text files.
I would have to agree with Marcin here. I don't have a problem with the smalltalk browser concept and all the rest you are talking about, but I can't seem to get my head around Squeak. Where does one start, where is what, hows this image thing work, how do you share code, deploy ... ?
Squeak is clunky and ugly alright. I don't think an IDE should be compared to vi. An IDE should be intuitive, vi was never designed to be intuitive.
I hear your point, but I would also like to see what you are talking about with screenshots to make what you are saying more concrete.
Once you get started, vi is easy to learn as you go. You find out how to do something when you need to.
Learning to use Squeak, on the other hand, seems more difficult to learn as you go. When people tell you that the browser confuses them and they struggle with "where do I start?" it is because it is not clear to the newbie.
Rather than telling new users "that's just the way it is, for good reasons that you don't understand yet", how about telling us "this is how you start a ... type of project"?
I've already seen some awesome things about Squeak (and VisualWorks), so I am convinced that this is something I want to learn. Now all I want is a clear path that shows me some examples, documentation, and tutorials, and then tells me how I can apply some of these in my own projects. Perhaps this should have been placed under your "barriers to entry" post, but there it is.
I already understand vi and bash and csh and cmd, am acquainted with C and C++ and Java and Python. James Robertson's video series is pretty helpful for learning how to accomplish specific tasks using VW. Perhaps a similar series for the Squeak newbie would do the trick.
It sounds like you haven't really used any modern IDEs in depth recently. Eclipse, Netbeans, IntelliJ's IDEA, and emacs run circles around Squeak's browsers in multiple ways. Install Eclipse and look at what you can do with the refactoring tools alone.
I was really intrigued by Squeak. I was wowed with what Avi has done with Seaside. The promises, ideals, and religion of Squeak are very, very appealing. Reading some of the things Kay has written and watching the videos are very inspiring. I like the Smalltalk community.
I checked out Squeak for about a year, writing several Seaside applications with it. It's the usability of Squeak that sucks.
I don't know how many times I got errors annoyingly popping up when trying certain things. The refactoring tools are incredibly limited (isn't Smalltalk the birth place of refactoring tools?) and buggy. The editors in the browsers are too simplistic. Everyone complains about the look, and they are right. There is a whole world outside of Squeak that has been evolving and improving, and Squeak seems to not want to take advantage of any of it.
It's not that I haven't used them, even the polish that the IntelliJ guys applied to Visual Studio with their Resharper plugin is amazing, I use it daily. I'm not saying Squeak is the pinnacle of Smalltalk, it certainly isn't. VisualWorks or Dolphins IDE is much more modern looking, and polished, but Squeak is where Seaside is at, and the tools are sufficient, especially since the language is Smalltalk.
IntelliJ, no matter how great it is, is still an editor for the turd that is Java, and while the state of refactoring with the assist of static code analysis has gone beyond what Smalltalk pioneered, it means crap to someone who rejects manifest typing.
None of those tools work on dynamic languages, and as far as I'm concerned, dynamic languages are where it's at. Smalltalk gives me a great language, and great tools, compare them to Ruby or Pythons tools for an apples to apples comparison.
Thanks for the screenshots!
Browsing is not a problem, but how do you write code into this browser? I made hello world program in Workspace window and i see result in Transcript window. I have no idea how to make in squeak a package, new class, add method and then browse it with squeak browser. Also, how can i add my code to version control system, and how to look into change history? For java and ruby i use subversion.
Ramon wrote: >That's the whole point of all these browsers, they show you that overall >structure that you couldn't other see in text files.
A screencast showing off such a analyze run with all these browser on a non-trivial codebase would be really helpful i guess.
I too have issues following the flow of smalltalk applications.
Btw. the best documentation i could follow regarding ST in general was:
http://www.exept.de:8080/doc/online/english/TOP.html
Seaside doesn't seem to be available on smalltalk/x though.
If you say that java is turd then i can say as well that smalltalk is turd.
@ e "I have no idea how to make in squeak a package, new class, add method and then browse it with squeak browser"
just open popup menus in browser panes , u will come to know.
"Smalltalk gives me a great language, and great tools, compare them to Ruby or Pythons tools for an apples to apples comparison."
Here's the thing: you can't. In Squeak, you are forced to use this ugly, usability nightmare of an IDE that requires a mouse. Things are hidden from you and you have to click your way through a bunch of popup menus and windows to find what you are looking for.
In Python/Ruby/Lisp, you open up a REPL (on the host machine or remotely--doesn't matter--there is no requirement for a graphical vnc-like tool) and start talking to the interpreter.
The first problem I've had with all Smalltalk browsers I've tried working with can be summed up in one word, Mouse.
I have to stop to move my hand (from keyboard to mouse and back) every time I need to do an action. This movement takes time and a shift in focus (even if minute). ST needs control from the mouse and the keyboard (Humane Interface http://rchi.raskincenter.org/index.php?title=Home).
Next, IDE's let you work across many methods because they are using the concept of a grid of characters that you can mark and work against. This is a powerful metaphor that works, why abandon it?
There is no reason why you can't have a view of a class with the text of multiple methods and still keep the methods in a image based system; Emacs or Firefox (javascript) anyone?
Most of your arguments for the benefits of a Browser system are not real, they come from the language itself not the Browser. Smalltalk is a powerful language don't belittle it by saying it's only strong because of it's smallest implementation feature.
And the last thing to add is personal so that it with a grain of salt: Programmer Art.
The interface is just ugly, there is something to be said for taste. These tools could benefit from some HCI work, maybe even a little "Apple" love. They were designed an implemented in the 80's and it shows.
- my 2 cents
@Anonymous, you seem to have too many expectations that Squeak should act like every other tool you already know. If that's what you want, you're going to be disappointed, because it isn't.
Yes, you have to use a mouse. Yes, it's ugly. Yes, it invented it's own awkward windowing system so it could be cross platform. Yes, it requires graphical interaction. I've complained myself about many of these things, but they are trivial things in the grand scheme. Instead of looking for things that are wrong with Squeak, of which there are many, try looking for what's right with Squeak.
Let me say it clearly... Squeak is NOT for the mainstream, it's for early adopters that don't mind the rough edges because it offers them something they can't find elsewhere, the latest and greatest Seaside.
There are many bumps along the road, Squeak will NEVER be the slick polished development environment that you find in IntelliJ, Eclipse, or Visual Studio. No one is funding Squeak UI development and the community is very small, you have to adjust your expectation accordingly.
Slick however, is not equal to functional. Squeak is quite functional once you figure it out. Squeak rarely gets in my way. Developing in Squeak beats the pants off developing in all those other environment because it's a live system. I can create an instance of an object, pull up an inspector on it, and play with it while continually changing the code, adding and removing instance variables and it dynamically changes on the fly. No compile/run/debug cycle at all, it's instant. Btw, REPL's are nice, but workspaces are better.
There are slicker prettier more polished Smalltalks, but they aren't free and Seaside isn't developed in them. If you want to use Seaside, you're going to want to learn to get along with Squeak.
http://www.dabbledb.com/
Developed under Squeak.
And, of course, Squeak, is more than Seaside.
Of course Squeak is more than Seaside, it's just Seaside is the primary reason many of us want to use Squeak.
"There is no reason why you can't have a view of a class with the text of multiple methods and still keep the methods in a image based system; Emacs or Firefox (javascript) anyone?"
Other browsers that do such things exist in Squeak, some swear by them, I don't.
"Most of your arguments for the benefits of a Browser system are not real, they come from the language itself not the Browser. Smalltalk is a powerful language don't belittle it by saying it's only strong because of it's smallest implementation feature."
I'm hardly belittling Smalltalk. I love Smalltalk, but I also love the Smalltalk browser, and it's not a small implementation feature, most Smalltalk have a very similar browser, it's a core idea of how code should be edited, and there are benefits to the approach.
@Leon, I would love to learn Seaside/Smalltalk/Squeak (probably in that order) and focus on what is good in Squeak. I think most people replying on your blog do otherwise they wouldn't be reading it.
I do however wish that someone would lower the barrier and I believe you are on the right track to start this process.
I would say start by removing everything (how does one remove something from an image anyway?) that's not relevant to developing seaside web apps (eToys, Morphic...?). I would love to browse through the existing code, but there is so much of it that I have no idea where to start and what is relevant to seaside web apps.
Everyone agrees that Squeak is bloody ugly which is not beneficial for newcomers either. I don't think it needs to look like the OS, but I reckon some small improvements (I have no idea how to do it though) could make a big difference; - Why are the default fonts of a Squeak image so ugly (this is the only customisation I did manage to do). Something that works on all environments; something like BitstreamVeraSans or the font you have in your dev image is not bad either. - The Icons of the Tools (the browsers) all look the same. The icon does not tell you what the tool is for. - The default window borders are way too thick. Can you make them all have the same colour too? - The min/max/close window icons are too awkward looking. - The buttons on the browsers are inconsistent and should look like buttons - The tooltip balloons just look ridiculous, what about a simple square tooltip box? - Can all actions not relevant to developing a web app be hidden?
Anyway, just some ideas :)
Great details, I really appreciate it. I used SmallTalk browser once and I agree about the similarity with RDoc. Adi
@No one is funding Squeak UI development and the community is very small, you have to adjust your expectation accordingly.
So may be strip all this crap like Tetris, Morphics, Alice and others out of default image? I bet nobody rotates browser on 30 deg.
"So may be strip all this crap like Tetris, Morphics, Alice and others out of default image? I bet nobody rotates browser on 30 deg."
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.
"What's wrong with this picture?", I ask.
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?
@Joao
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...
I think it's more just the unfamiliarity. It takes a while to get used to it.
I wish the docs were better, though. More screencasts would be a definite improvement.
@Joao, you misunderstand me, I wish dynamic language like Ruby and Python all the luck in the world, we're all on the same side. I like and use many languages, each best for given uses.
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'm following squeak about more than 1 year ago I think. And some times, I posted on dev maillist thath could be good for Squeak, a little change on the look'n'feel, or/and more screencast like other says here.
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.]
Maybe I'll have to be a bad Squeaker for a moment, but if you want to write end user applications, personally, I don't think Squeak is really fit for that. It's too weird for end users, hell, it's too weird for most developers. There are much better Smalltalks for end user applications like Dolphin or Visual Works.
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.
I listened to a webcast with DHH recently and he said one thing that matches with what you said, Ramon; that the Ruby community has certain things that are acceptable to it, and things that are not. There's a certain aesthetic about it that is reinforced in the community. One of the examples he brought up was an emphasis on naming things well. He said there are certain things about Ruby and the community that turn some people off, and that's okay. He said the community sets the standard for the language and the Rails framework, and people can join with it, or not. Squeak/Seaside is the same way.
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.
Very true, and I agree with DHH about a language having an aesthetic and using it to filter out those who don't fit. If you really really really like files and your existing tool chain, Smalltalk isn't for you, move along, find something else.
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.
Let's just stick to the Smalltalk/Squeak subject and refrain from comparing/defending it with other languages, as that was never the purpose I thought.
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.
I don't think Dan Ingalls meant any random individual, only that a system shouldn't be so big and complex as to be incomprehensible to everyone.
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.
I think what's hard to find is the right target for the message that Squeak and Seaside are to be used.
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. :-)
@Geert:
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.
I like the Smalltalk idea that (almost) every part can be changed. I would love to find out more on how to do this. I think by inspecting what is in Squeak now and changing and tweaking it to how I want it to be, will teach me more about Smalltalk at the same time. Where can I learn/find more info on how to add to and remove stuff from an image and other things I mentioned in one of my earlier comments to customize the image ?
@Geert
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.
For tweaking the look and feel, you might start with: http://wiki.squeak.org/squeak/1008.
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).
Ramon thanks for another insightful post on smalltalk and squeak.
Getting back to the central theme of this post, "Smalltalk Browers" and the "Barriers to Entry", it seems the only true barrier is your mindset. Yes, documentation could be better, yes Squeak could be prettier, but these are not barriers. Ultimately these seem to be the excuses for holding on to particular mindset.
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)
You make a good point which can be summed up with a general principle, the beginners mind.
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.
Hey everybody! Who (Alan Kay and folks ?) and when (1972 ?) invented "Class Browser" pattern? I've seen exemplar in MacOS 10.x (finder) but of course it is not the root. Anybody info on this subject? Thanks!
"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." Why is it hard to remove stuff like eToys?
Great post! This remind me my first Object Orientation Enlightenment with the Smalltalk browser. This actually changed the way I program, even with Java/C#.
http://www.notarianni.org/index.php/2005/09/17/objectorientationenlightenment
@Geert, removing those things is difficult because a Smalltalk image is a runtime system and Smalltalk allows open classes.
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.
Thanks for the info Ramon. I'll have a look at the alpha version of 3.10
aaaaah the browser :)
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.]
@Bernard Notarianni:
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.
[...] On the Smalltalk Browser [...]
I played with version 3.10 and i did like it.
I think the problem with adoption is all of the unknowns.
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.
God, the Smalltalk IDE is U-G-L-Y. Powerful, but it looks 3 decades old. No wonder no one uses it anymore. Image and marketing matters more than substance. I wish someone would get real and do something about it.
phillip
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/
You're getting rather preachy here. I don't think that most people find the browser as such the problem, but rather that the squeak browser is a clunky implementation of this concept.