|
|
|
|
|
|
by jcromartie
5581 days ago
|
|
|
> I haven't been happy with Squeak Smalltalk in a fast-paced production environment... however it has been fun for other reasons. Could you expand on this? I've been looking at Pharo w/Cog + Seaside for production software and I would love to hear about any pitfalls. |
|
|
When you upgrade to a new version of Pharo, you're upgrading your IDE with it. When there is a bug in your system its easy to fix but its pretty tedious to make sure you track every little patch and make sure they're re-applied the next time you build a fresh image. The style of putting your overrides into a method category named the same as your package doesn't sit right with me. There are a lot of conventions like that that are hard to discover that you're expected to "just know". You're expected to peruse mailing lists frequently.
For example I found it really easy to hack in emacs-like key bindings for cursor motion... but I never load those changes into new images just because my code is slightly different from new code and I don't feel like tweaking it every time there are image updates... I've just given in and use the images as-is in the interest of moving forward.
If you run into a memory leak or slip up with some bad code in development, all of those leaked objects hang out in your image until you re-build a new image, or can manage to destroy them manually (I've had mixed results with the latter).
I repeatedly have been bitten by doing something stupid in development and have my image balloon to hundreds of MBs. You can't just Ctrl-C out of that situation... you better hope you have a backup image hanging around and that your most recent changes were committed to Monticello, or else you'll have to go recover them all manually and commit, then load them into a fresh image.
A lot of the libraries you'll find are half-baked. It is a lot easier to whip up something in Smalltalk than other languages (like say, Java), however the community isn't large enough to get enough people doing enough things for the platform to get some good quality work going outside of a few main projects (like Seaside).
Smalltalk's image-based nature does not play well with the host OS. There are some great packages for interfacing to the OS, but you'll be spending some time learning the unique ways they 'smalltalk-ize' typical OS interface areas differently than a language such as Ruby.
Now I still think Smalltalk is awesome. But I'm a lone developer at a tiny company and its akin to using a Formula-1 car to commute to work. One would be more comfortable in a boring Honda Civic. I just don't have enough resources to use it in production is all. F1 cars require large teams, but they're awesome technology!
Lately I've gone back to using Ruby, Rails, and a little Node.js for this company as those are more pedestrian technologies right now. I know one would object to Node.js being "pedestrian", but it really is pretty simple to wrap your mind around, its just Javascript and has decent documentation and isn't too much code to look over.
Smalltalk on the other hand has code for everything, so if you're averse to reinventing the wheel you'll find yourself reading a lot of (good quality) code to figure out what is where and what you should use that is already there. There also isn't a great way to get an idea of what is in libraries you might find on SqueakSource without reading through all of the code, most of it is poorly documented.
In the end, Smalltalk is awesome and frustrating at the same time. Image-based development is both a blessing and a curse. Some conventions of the culture I think are bad practices (e.g. "the code is the documentation, so we don't need to write documentation").