Practical Git for Smalltalk: STIC 2012

The video of my STIC 2012 talk “Practical Git for Smalltalk” is available. You can view the slides on SlideRocket or as pdf.

Photo by http://www.flickr.com/photos/unavoidablegrain/3277754772 / CC BY-NC-SA 2.0

Who needs objects?

Bob Nemec responds to Dave Thomas‘ statement that object abstraction is too complex for the majority of programmers.

From Bob’s post:

There are two types of programmers: the toolsmiths (abstractionists) and the tool users (constructionists). Smalltalk developers seem to all be abstractionists.

…

Most programmers are constructionists. They have a job building and maintaining business applications. As Smalltalkers we ask ourselves: how can we get these programmers to use Smalltalk, to see how much more productive and enjoyable our environment is? The answer, I believe, is to reduce barriers to entry.

Photo by http://www.flickr.com/photos/markchadwick/6549846977 / CC BY-NC-ND 2.0

Kaliningrad: Developing with Amber, Seaside and Monticello

[1]

Kaliningrad oblast (sometimes called Yantarny krai which means “The amber region”) is located on the coast of the Baltic sea and is the site of the world’s largest amber deposits.

Kaliningrad Project

I created the Kaliningrad project because I want to use Monticello to manage the code that I write in Amber.

Kaliningrad automatically maps Amber package names to Monticello package names, so Kaliningrad is pretty easy to use.

Kaliningrad is based on Seaside 3.0 and uses the Seaside File Library and the Seaside-REST package to serve and store the Amber .js and .st files.

To load Kaliningrad execute the following expression:

Gofer new
    url: 'http://ss3.gemstone.com/ss/Kaliningrad';
    package: 'ConfigurationOfKaliningrad';
    load.
((Smalltalk at: #ConfigurationOfKaliningrad) project version: '0.1') load.

The Kaliningrad configuration loads only the most basic packages for Seaside 3.0, so you’ll need to load up one of the adaptors (Swazoo, Comanche, or Zinc) before you can connect.

Using Kaliningrad

Once you’ve got the Seaside server running, hit (user/password : admin/tool):

http://localhost:8080/tools/amber-browser

to bring up the Amber Browser:

If you want save your Amber code into a Monticello package follow these steps:

1. Create an Amber package (‘tODE-AmberClient’) in the Amber Browser.
2. Create a Monticello package with the same name (‘tODE-AmberClient’) using the Monticello Browser in your image.
3. Register the Monticello package with the KOAmberBrowser class:

    KOAmberBrowser addMonticelloPackage: 'tODE-AmberClient'

Thereafter, when you hit the Commit package button for ‘tODE-AmberClient’ in the Amber Browser, the .js and .st source will be saved in the ‘tODE-AmberClient’ Monticello package.

Thats it!

The class KOAmberBrowser is also a good example for how to integrate Amber code into a Seaside component.

Importing classes into Amber

If you want to import a class from your Smalltalk image into Amber, you can evaluate an expression like the following in an Amber workspace:

KOImporter importClass: 'TOSession' intoModule: 'tODE-Amber'

Be aware that there are differences between Amber Smalltalk and other Smalltalk implementations (see the section entitled Differences with other Smalltalk implementations on the Amber documentation page). KOImporter does not check for correctness.

Summary

Kaliningrad 0.1 is based on Amber 0.9.

I’ve been using Kaliningrad with Pharo for a couple of weeks now, but the code should run in GemStone and Squeak.

If you run into problems, let me know.

—–

[1] Photo by http://www.flickr.com/photos/paul_garland/5133520694 / CC BY-SA 2.0

Why I love Smalltalk

Smalltalk love from J. Pablo Fernández:

…Look all the code we wrote without having to memorize any keywords! What’s even more important is that by now you essentially know Smalltalk. That’s all there is, but like LEGO bricks, this simple and small building blocks allow you to build whatever you want….

Photo by http://www.flickr.com/photos/yenstefanie/2660443781 / CC BY-NC-SA 2.0

Who looks at Smalltalk?

Bruce Badger hits the nail on the head with his Who looks at Smalltalk? post:

The C guys looked at Smalltalk and said they didn’t need object orientation….

Photo by http://www.flickr.com/photos/fdctsevilla/4052593758 / CC BY 2.0

Smalltalk: Simple but Expressive

Daniel Lyons writes about his initial experiences with Smalltalk:

Smalltalk seems like a good environment for learning better OO design, but it makes you wish Java or whatever you’re using were as fast, easy and simple.

Thanks to Randal Schwartz for the pointer.

Photo by http://www.flickr.com/photos/jjjohn/2387534678 / CC BY-NC-ND 2.0

[ Smalltalk ] Google Summer of Code Call for Students

If you are a student and are interested in getting a stipend to write some Smalltalk this summer then have we got a deal for you!

Check out the GSoC Smalltalk Call for Students for details.

Photo by http://www.flickr.com/photos/axolot/ / CC BY-NC-SA 2.0

GLASS Beta Update: Metacello, GemTools, GLASS, Cha, Cha, Cha

[1]

Well the time has finally come, or nearly come.

It’s been nearly a year since I’ve released a GLASS Beta Update. Last April, when I released the SOAP Preview for GLASS, it was obvious to me that the days were numbered for the GLASS.230-dkh umbrella package and that I would have to find a better solution for making releases in Smalltalk. I just didn’t realize that the number would top 300:)

In my defense, starting in November of last year I did initiate a series of Bootstrap releases (1.0-beta.0, 1.0-beta.4, and 1.0-beta.5), but over the last 10 months I’ve really focussed on getting Metacello up to snuff.

The good news is that I am in the final steps of the year long release cha cha.

Metacello 1.0-beta.25

Metacello is nearly ready for 1.0, but there are a handful of things that have to be done before release. I’ve outlined most of them in The road to 1.0. I will release 1.0-beta.25 later today (fingers crossed) and will spend a day or so writing up additional documentation on some of the new Metacello features.

GemTools 1.0-beta.6

Once Metacello 1.0-beta.25 is out the door, I will polish up GemTools 1.0-beta.6.

The big news with GemTools 1.0-beta.6 is that I have transitioned to using the Help System for documenting the update steps for GemTools and GLASS. I will continue to announce releases on my blog, but the details for doing an update will be included in a Help System browser available via GemTools. This means that you won’t have to try to cross reference the versions of GemTools and GLASS with ancient blog posts to figure out how to upgrade to later versions.

Continuing the process started over a year ago, you will need to update to GemTools 1.0-beta.6 in order to update to GLASS 1.0-beta.8.

BTW, when Pharo releases version 1.0, we’ll release a new one-click for GemTools.

GLASS 1.0-beta.8

I plan to push GemTools 1.0-beta.6 out right before I release GLASS 1.0-beta.8. At this point I’ve got most of the major port and testing load behind me:

• update path from Pier 1.0.17 to Pier 1.2.1.3 tested
• update path from GLASS.230-dkh.164 tested (Appliance 1.0-beta11)
• update path from GLASS.230-dkh.177 tested (GemStone/S 64 Version 2.3.1)
• Seaside 2.8.4.4, Magritte 1.2.1.4 and Pier 1.2.1.3 ported to GemStone
• Seaside 3.0.0-alpha5.5 ported to GemStone/S 64 Version 2.4 (Pier2 and Magritte2 not yet ported to GemStone)
• Gofer and Gofer Project Loader ported to GemStone

There are a few more details that I need to cover and quite a bit of documentation to write about for 1.0-beta.8 before release, but I thought it was worth letting you know that I am in the final approach for releasing 1.0-beta.8

—–
[1]Photo by http://www.flickr.com/photos/experiment33/ / CC BY-NC-ND 2.0

GemStone/S, Maglev talk in Cincinnati on March 2nd

Joel Turnbull will be giving a talk entitled Gemstone and Maglev at the Agile Round Table in Cincinnati on March 2nd, 2010:

What is Gemstone? How do I get started with Gemstone? Why would I get started with Gemstone?

All of these questions will be answered!

We’ll do object persistence in Gemstone. We’ll persist objects from a web application. We’ll talk about Maglev and GLASS…

If you’re in the Cincinnati area and are interested in hearing about a production GLASS (GemStone/S, Linux, Apache, Smalltalk, Seaside) installation, then the Agile Round Table is the place to be!

Photo by http://www.flickr.com/photos/davidclow/ / CC BY-NC-ND 2.0

The Smalltalk Archipelago

So you’ve read Kent Beck’s Smalltalk: Welcome to the Balkans:

The Smalltalk vendors seem to me to be in the same boat. Everyone has taken their “ANSI standard” Smalltalk in different incompatible directions

I don’t think the real issue is standardization.

It’s true that each dialect of Smalltalk has quirks, but version differences are not unique to Smalltalk. It can be challenging to move Ruby programs between different versions of Ruby and it can be challenging to move C code between different operating systems and compilers.

Seaside is proof that a significant body of code can be written to be portable across at least 7 different Smalltalk dialects. It takes a hefty glob of Grease (a Smalltalk portability layer), but it can be done.

Aida and Swazoo are additional examples of significant applications that have been ported to multiple dialects of Smalltalk. They are built on top of Sport (another Smalltalk portability layer).

Writing portable Smalltalk is a solvable problem.

Kent’s proposed solution is a good idea in and of itself:

Have the tiniest possible core defined in terms of test cases. Build a shared library on top of that, implemented in terms of the core. Include numbers, collections, meta-objects, code structure, and code loading. None of this parcel/bundle/package/pundle/category nonsense. Compete on VMs, graphics libraries, and enterprise-y tools.

But expecting a set of vendors to agree on the the “tiniest possible core”, when they can’t agree on a set of common methods is unrealistic.

Here’s what sent Kent off on his diatribe:

All the tests pass in Squeak finally. I’ve been making the changes in place…I load my code back into Monticello … I go to load into VW. Kaboom. The meta information is snarled. The monkey patches are gone. Merging does nothing sensible.

and it’s sent me off on my own diatribe:)

I’ve been working in Smalltalk for 25 years and this problem is just as bad now as it was 25 years ago! It is virtually impossible to do cross-dialect development in Smalltalk. It was unfortunate for Kent that Monticello was partially ported, because it gave him the illusion that cross-dialect development was possible:

And that’s where I sit, blogging because I’m too mad to think…if you can’t even move code between versions. Who would rationally invest in Smalltalk code if they weren’t already locked in?

Right on, Kent! Existing customers may not demand cross-dialect development, but prospective Smalltalkers are being turned away and turning your back on cross-dialect development is turning your back on the Smalltalk community.

You know the story of the Smalltalk balloon:

The cover of that issue depicted the “land of Smalltalk” as a remote island, and that triggered a connection for me out of which was born the fanstasy of liberating Smalltalk from the ivory tower by balloon ascent.

Smalltalk isn’t just balkanized, Smalltalk is an archipelago where every dialect is stranded on its own island! It would be a luxury to have a hot air balloon to transport code modifications back and forth between dialects!

It is technically feasible to port Monticello to every dialect of Smalltalk.

It is an idea whose time has come and gone about 50 times! You can claim that a file-based Smalltalk wouldn’t have this problem, but Monticello is file-based development for Smalltalk.

Monticello makes cross-dialect development possible.

The Monticello code base has not had the attention to portability that Seaside and Aida have, but seriously, Monticello isn’t under active development. A one off port is perfectly adequate. I did a one off port of Monticello to GemStone in December of 2006. It’s not incredibly difficult and it has not required a lot of maintenance.

Monticello has withstood the test of time in the Squeak community and it does a pretty good job:

I load my code back into Monticello (I love SqueakSource, BTW–easy to use, free, what GitHub would have been if they’d stopped developing after a month….)

Envy and Store are not viable candidates. Monticello is a light-weight solution compared to Store and Envy.

If you can afford to port Seaside, then you can afford to port Monticello.

So why don’t we just do it?

It isn’t realistic to expect all Smalltalk dialects to live on the same island, but to continue to perpetuate the current isolationism between dialects is just pathetic:

I’m calling bullshit on the state of Smalltalk. Vendors, you’re acting crazy.

Thank you, Kent for the kick in the butt!

And Happy Valentines Day!