Smalltalk: Welcome to the Balkans.

Never blog when you’re mad. This is an excellent rule that I’m breaking right here.

For fun and education I started a MongoDB driver in Smalltalk. I wanted to learn about a NoSQL database from the ground (-ish) up and potentially provide something useful.

Step one: get it running in VisualWorks. Not a problem. I’ve used VW for 15 years. Lots of details to get right, but I’m a programmer. Details are slops in which I wallow.

Step two: find a customer. Again, not a problem. Someone has an application they would like to have populate a MongoDB database for later processing by other tools. Problem: the server is in Squeak.

Step three: port to Squeak. The pain begins. Just getting the code out of VW was a pain. I discovered Monticello, which is a nice concept for source control, sort of a Smalltalk-y version of Git (in the sense that they are both distributed SC systems). VW interface to Monticello is broken. Discussion with author resolves the issue. Code has escaped VW.

Loading into Squeak is no problem, but the Squeak programming tools are just too painful to use. Look no further for a shining example of the tragedy of the commons. Design requires inhaling–adding features, trying experiments, tweaking, going off in crazy directions–but it also requires exhaling–taking similar things and making them the same and deleting experiments that didn’t work out or at least moving them out of the core. Back in the olden days the limitations of the VM drove this, which is why the core concepts in Smalltalk were so refined. If you wanted space for your application you had to find a way to rationalize existing code.

On to Pharo. Pharo has a more coherent set of tools than the cacophony of Squeak but the base language/libraries are the same. The cleaner look was a relief although the paint splatters seem a bit indulgent. Whatever. I run the tests. They all break. Not a big surprise.

What’s broken? First, numbers. Syntax for literals. “16rff” in VW needs to be “16rFF” in Squeak. Sigh. No Double class because all floats are doubles, so Float is actually Double. No way to access the bytes in a Float. Then, dates. No built-in way to turn a Java timestamp into a timestamp. Different conversions required between Squeak and VW. Next, UTF-8 conversion. Grease to the rescue here. It’s the compatibility layer Seaside uses. Finally, sockets. At least this is no big deal. One class replaced by another. Except the Squeak version doesn’t support retrieving the position in a socket stream. Quickly fixed.

Now, I don’t particularly care for Java. Erich will tell you that I’m not productive until I’m swearing at Java. But credit where it’s due: the basics are portable. Numbers, sockets, strings, source code structures. You don’t have to worry about those moving from one platform or another. The vendors have found other battlefields on which to fight.

All the tests pass in Squeak finally. I’ve been making the changes in place, figuring I’ll make some kind of GratuitousDifferences class to capture the, well, you know. 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. I told you not to blog when you’re mad.) I go to load into VW. Kaboom. The meta information is snarled. The monkey patches are gone. Merging does nothing sensible.

And that’s where I sit, blogging because I’m too mad to think. I’m not just mad because I’m stymied. That’s frustrating but not out of the ordinary. I’m a programmer after all. What I’m mad about is the gratuitous balkanization of Smalltalk. Here’s a language and platform that still has a lot to offer the programming world. There are lessons there about programmers being humans and users being humans that could be profitably absorbed by computing in general. And they won’t be, not if you can’t even move code between versions. Who would rationally invest in Smalltalk code if they weren’t already locked in?

I looked up Nash Equilibrium because it seemed appropriate. A Nash Equilibrium is (broadly speaking, look it up if you want accurate details) when none of the players in a game can change their strategy without losing something. The Mexican Standoff (as long as I’ve insulted Eastern Europeans I may as well insult our neighbors to the south as well) is a classic example. No one wants to be the first to lower their gun. The Smalltalk vendors seem to me to be in the same boat. Everyone has taken their “ANSI standard” Smalltalk in different incompatible directions, but to move towards compatibility would be a loss. Hence, no one is going to change.

The thing about a Nash Equilibrium is that what is rational from within the game can be absurd from an outside perspective. I’m calling bullshit on the state of Smalltalk. Vendors, you’re acting crazy. 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.

I know this can’t be a sensible proposal. There must be huge, insurmountable problems with it. After all, I’m too mad to think straight. But it would have made my job a lot easier today.

Written with all the love I can muster,



James FosterFebruary 10th, 2010 at 9:46 pm

While I’d agree with the general description of the problem, I’m inclined to see the glass as half-full rather than half-empty. While you see vendors going in different directions from ANSI, I see ANSI as an attempt to converge–and at some cost to existing customers. GemStone changed the return value of #’add:’ so that it answers the argument rather than the receiver. This was a major upheaval. For another example, all the vendors adopted the VSE approach to Exceptions; in many cases requiring non-trivial VM changes.

I don’t see any vendor adopting a Microsoft-like attempt to be non-standard in order to lock-in customers. Even Cincom (which I assume has the largest install base and the most to lose from easy migration) has provided some level of Monticello support. James Robertson frequently cites Seaside’s portability as a selling point (“Don’t be afraid of being locked-in!”). Dale Henrichs promotes the idea of developing in Squeak/Pharo and porting to GemStone if and when needed for scalability. John O’Keefe makes frequent contributions to Grease in order to improve code portability.

GemStone, in particular, tends to have a symbiotic relationship with the other vendors because essentially all of its paying customers are also customers of the two major commercial vendors. Because of the way GemStone customers use the products, they often demand that vendors fix incompatibilities so that their code can run unmodified in both the client and the server. For example, I know of a good deal of negotiations that went on so that VW and GS would have the same internal implementation of SmallDouble.

There is certainly more to be done, but I see more converging over the past decade than diverging. This is being driven, in part, by the non-commercial dialects. As compared to 15 years ago, when the cool things came from VW (e.g., Refactoring Browser), the cool things are now coming from Squeak/Pharo (Seaside, Magritte, Pier, etc.). This gives the commercial vendors strong incentive to make an easy migration path while still adding value (see Web Velocity for an outstanding example).

Sebastian KübeckFebruary 11th, 2010 at 12:51 am

> Never blog when you’re mad.
You disproved your rule with this post. ;-)

I think that if the Java vendors could turn back time they would have created their own Java dialects. Incompatibilities are the glue in our industry that binds the customer to the vendor.
If there are standards and the customer can exchange technology, he’ll usually buy the cheapest. As a result prices are going down. Incompatibilities help the vendors to ensure that customers have no alternative and hence have to pay the prices the vendor dictates.

I don’t like that too but I haven’t made the rules.

Good Luck!

JulianFebruary 11th, 2010 at 1:52 am

> 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.

This *is* precisely the goal of Grease (+ Monticello for code-loading), and I am confidant we will make progress over time, but it is certainly a slow battle. You really do need a common core set of functionality you can rely on, and gratuitous differences in the implementation of common things are just annoying.

That said, Seaside runs on all major platforms with only minor differences, so it *can* be done. :)

Dave WoodwardFebruary 11th, 2010 at 5:26 am

I’ve had a great time using Pharo to build a project for work. At one point I thought maybe I should port it to VW or maybe switch it to Gemstone to make it scalable.

I got a sense that what you experienced here would happen, so I rationalized that I should just stick with “all open source Smalltalk”, and stayed with Pharo and I’m using Magma. You don’t want to hear it but thanks for verifying my suspicions that it’d be more trouble than its worth :)

I am however pretty interested in your MongoDB work. I also have a Rails application, and it’d be nice to run both off Mongo. I made it a point to not start new projects on MySQL which is why I’m using Magma in Pharo.

Are you building a ORM-ish interface, or are Mongos’ documents a 1-1 mapping to objects? I imagine it’d be pretty trivial to serialize at least an object’s inst-vars into a Mongo doc…

chaetalFebruary 11th, 2010 at 6:39 am

Java and C# are very close in their philosophy and approaches. Does anybody expect Java program to be portable to C#?

Osvaldo Pinali DoederleinFebruary 11th, 2010 at 6:50 am

Well, Microsoft _did_ try this strategy with VisualJ++; it’s great that it didn’t work, although the resulting fragmentation (the whole new .NET platform) was arguably much higher. With some vendors you just can’t win. ;-)

But it’s remarkable that Java vendors continue to behave well, even better as the platform matures. There is a ton of JCP-standard APIs (increasing inclusive SE/EE specs), but there’s a ton^2 of non-formal-standard frameworks and languages – from multiple FOSS groups, vendors, etc. The fragmentation that we have is usually just excess of choice, e.g. twenty web frameworks or ten ORM engines or five advanced collections packages, etc. But these are typically portable cross JVMs and even across appservers, the only problem is that community resources, training etc. are watered down by too many partly-redundant options of some things. Eventually these choices coalesce as something “wins”, then we have a new standard, e.g. Hibernate->JPA. Overall it’s a good model, with strong competition and standards that are just fast/good enough to not pull too much of one’s hair off. :)

Steve FreemanFebruary 11th, 2010 at 8:31 am

Don’t forget the history. Smalltalk vendors turned down an offer to put Smalltalk on every workstation. Twice (Sun and HP). We need never have given Java its foot in the door — or at least we could have had decent collections.

adminFebruary 11th, 2010 at 8:55 am

That’s the kind of commonality that I would like to see in Smalltalk–common core, diverse fringes, easy portability. I disagree that this process is inefficient, though. That’s true in the micro sense–why would you need two ORM frameworks–but the diversity keeps the community from getting trapped in local maxima. The duplication of effort is the cost of safety and progress.

adminFebruary 11th, 2010 at 9:01 am

The first layer of the MongoDB driver is a pretty close reflection of their API, although I chose a collection (in the Smalltalk sense) metaphor instead of a stream/cursor metaphor. That is, you say:

root := Mongo default.
database := root databaseNamed: ‘test’.
collection := database collectionNamed: ‘example’. “This is the built-in structure: server ->* database ->* collection”

Now you can do collection-ish things to the collection: size, do:, inject:into:, select:, add:, remove:, etc. I’m happy with it so far.

I’m suspicious of automatically translating objects into MongoDB documents (which are basically Smalltalk dictionaries with strings as keys). I’d want to build some applications first. If I find myself building the trivial mapping several times, then I’d offer a default mapping.

NicolaiFebruary 11th, 2010 at 9:13 am

I hope you feel better now, Kent.

adminFebruary 11th, 2010 at 9:29 am

I do. Thanks. I still can’t move my code around but I feel better.

Giulio PiancastelliFebruary 11th, 2010 at 10:05 am

On a different scale, and in a different environment, what you describe here reminds me of Prolog. The language is an ISO standard, but the various implementations still diverge from it in some details. I struggle to find the right words to describe the mess that the loading mechanism and features of libraries are. An example: a Prolog vendor lets you use list-related predicates without importing anything; another one require you to import a library; another one require you to import a library, too, but using a different instruction. Another example: a Prolog implementation features an HTTP server, but lacks a regexp library that I can use to mangle the text of the response; that regexp library is included in another implementation, but this one lacks the HTTP server; and there’s no evident and/or clean way (e.g. a way that doesn’t involve C programming or VM recompilation) to port one or the other library to one or the other implementation. The development community seemed to be willing to solve these problems by merging rather than standardizing and then competing, but that was more than a year ago, and I have yet to see the results.

Alan KnightFebruary 11th, 2010 at 10:17 am

I think part of the difference here is the question of what the “vendors” are competing on. Calling Squeak a vendor isn’t really right. They’re not a company selling something, they’re a community doing things. And part of what they’re doing is trying to figure out better ways of doing computing. Java’s all the same because early on, Sun said we’ve got all this basic stuff right, here are the libraries, you’re not allowed to change them on pain of death. It’s not like you have a bunch of Java vendors who have different libraries and have worked to make them compatible – they’re just using what they were given.

On the other hand, Squeak, or at least a portion of the Squeak community, says that we need radically better ways of doing computing, and we need to experiment on those. And people working on reinventing computing probably aren’t overly concerned with whether it’s 16rFF or 16rff (I feel obliged to note that VW would accept either), or how to convert Java timestamps. They haven’t standardized, say, collection libraries because they’ve rewritten the collection libraries to use Traits, at least in some versions.

And yes, all of that’s at odds with the people who just want to get something done, or just want to port their code from one thing to another easily, and some of the differences are silly. But especially in the case of Squeak, there are more fundamental philosophical issues than just laziness or being stuck in a bad equilibrium.

MegFebruary 11th, 2010 at 10:50 am

chaetal, no one expects C# to port into Java because the point of C# was to be non-portable Java.


Torsten BergmannFebruary 11th, 2010 at 12:08 pm

Java separates too … have a look at Android with Dalvik VM from Google vs. Sun Standard JDK.
You always have to decide – even in Java (Swing vs. SWT, NetBeans runtime vs. Eclipse RCP).
At least Java has a common base – Grease is a start in Smalltalk.

Stephane DucasseFebruary 11th, 2010 at 12:33 pm

Yes never blog when you are mad. You give a bad impression and not only of others.
Now the pharo mailing-list is open and you can report bugs and improvement.
You sign the license agreement and we accept the code and may be we include it.

Now what is the solution.
get stuck with a ANSI bad standard?
get with vendors evolution that are not optimal?

what if we do not like VW Namespace ?
what if we would like to have first class instance variables?
Vendors like parceplace did not really ask the community about the changes they did.

Now Seaside is developed on pharo and run on nearly all the dialects so there
is a path. It is not easy.
Now if would be better to think that what is the future of smalltalk.
- scripting
- first class instance variables
- new look at the MOP
- better modules system
- …
and we will not to that with ANSI kind of standardization process.


Stephane DucasseFebruary 11th, 2010 at 12:41 pm

have a look at:

Improvements can be as simple as that. Now the first level is to communicate with people and let them know that they can improve if they want. So we will probably fix that in Pharo. If somebody provides a fix it can be fix in 2 min.

The goal of pharo is to create an innovative Smalltalk that can be use to make business but also to reinvent Smalltalk. And this will not be done without breaking stuff. We do not want to live in a museum. for more information and vision statement.

PaulFebruary 11th, 2010 at 3:43 pm

I’m not a Smalltalk programmer (not yet anyways, I’m working on it), but I disagree with the notion expressed in some comments that this doesn’t grievously wound the language and its community. Nothing prevents me from convincing my partners that Scheme is a reasonable language choice for our projects than its similar balkanization.

Andreas RaabFebruary 11th, 2010 at 4:46 pm

@Paul: No surprise. Balkanization occurs if there isn’t a strong central power. In the case of Java, Sun controls the brand and went to court with Microsoft over precisely these issues. There is no such force in the Smalltalk world (and listening to you neither in the Scheme world). Python, OTOH, has the BDFL who is effectively the authority controlling the brand, Matz plays the same role in Ruby. They probably couldn’t withstand an assault along the lines of Visual Python++ from Microsoft but short of that they define what the brand is and what isn’t.

IanFebruary 11th, 2010 at 5:22 pm

I think what’s always bothered me about Smalltalk (and to a lesser extent Java) is that they all live off in their own world, and pretend like the operating system doesn’t exist. The problem is, it does exist, and if you pretend like it doesn’t than your app is just going to look weird, and act weird, and generally be unpleasant to use. I’m glad that Pharo and VisualWorks have made strides to be closer to the host OS, but it’s not enough — they’re still very obviously not part of the system. If you try to make an app with them, it will look and feel weird.

I love Smalltalk the language, but I really wish someone would come up with a decent free implementation that uses native windowing widgets and acted like the host OS. And I don’t buy the cross platform argument — wxWidgets in python manages to use native widgets and still run across multiple platforms.

adminFebruary 11th, 2010 at 5:27 pm

Or admit that Smalltalk’s niche is Seaside so widgets really don’t matter. It would be ironic if Smalltalk, which introduced so much of the visual vocabulary we use every day, turned out to be headless.

Keith NicholasFebruary 11th, 2010 at 5:43 pm

It seems with languages what you need to make it work is a massively dominant vendor to set the standard.

Where there isn’t, it seems you have mammoth pain and effort to develop a shared standard.

Giles BowkettFebruary 11th, 2010 at 5:58 pm

This is why I don’t spend more time on things like Seaside and Scheme even though I want to. All these things you have to do yourself by hand in Smalltalks and Lisps, you get for free with minimal effort in Ruby and/or Rails. These are “classical languages”; the more popular alternatives have huge advantages in ease of use. Pretty much any time I learn anything about or from the classical languages, I’m much more likely to use it as a technique in some other language.

adminFebruary 11th, 2010 at 6:14 pm

The question is whether it’s even possible to have a standard without a dominant player. C++ seems to be the existence proof that shows this is possible, or perhaps Bjarne is the massively dominant vendor :-)

Keith NicholasFebruary 11th, 2010 at 8:08 pm

Never said it was impossible.

C++ would be my example of the pain a language goes through to get it standard and to progress the language….and the impatience of the community to get it to progress.

even now its problematic hard to write cross platform C++, not to mention trying to distribute it as a buildable unit across platforms

ClausFebruary 12th, 2010 at 5:11 am


feel free to wrap wxWidgets for Smalltalk :)

Other than that, I feel that the native widgets argument is on the brink of dying. Like it or not, the web has won. All what your GUIs will be is html plus javascript.

I am using Java these days, and I am using SWT whenever I can because I like the way it works and how closely related (concept-wise) to Smalltalk I perceive it to be.

Generally spoken, if the Smalltalks could at least have the same Collections framework, then everything would be better. I still perceive VS to be the best Smalltalk due to its impossibly close integration to the host OS. Granted, windows only, but for Desktop applications, do the other OSes really count?

Tom SattlerFebruary 12th, 2010 at 6:23 am

Kent, the one thing pointed at by all Smalltalk programmers is the openness of the system; all source code is provided and we are free to do whatever we find necessary. If you would like to write a “commonality” layer for all current Smalltalk dialects, through which any object could be exchanged with any other Smalltalk dialect, I would encourage you to do that. Instead of saying “Damn those Smalltalks, they don’t work the way I want them to.”

Basically you have three options: 1) Get mad, 2) Accept it as it is, 3) Fix it.

“Once I asked why someone doesn’t do something. Then I realized that I am someone.”

Step up!

James RobertsonFebruary 12th, 2010 at 6:52 am

I posted my thoughts on this here:

and, as is often the case with a complex topic, my thoughts have evolved since. Michael and I discussed this on the “Industry Misinterpretations” podcast last night, and that will be posted Sunday. When that goes out, if you want to comment, feel free to send us a textual or voice response.

adminFebruary 12th, 2010 at 8:34 am

My solution for now is to work around it. I’m not happy about the duplication of effort, but it’s hardly the hairiest yak I’ve ever seen.

sebastianFebruary 13th, 2010 at 7:35 am

Alan you did well in exposing the costs of your development.
It’s not supposed to be that hard.
There is something broken about us.
What I think is broken is the overrated flexibility that leaded to unwanted complexity

GeertFebruary 13th, 2010 at 12:08 pm

Hi Kent, I have to say that I am very impressed at how your “vent” post managed to stir the feathers amongst the Smalltalk community … I had a little giggle at some of the comments but it actually proves that there is still a lot of very passionate Smalltalkers out there :)

I loved how you mentioned in one of your comment replies that “… it would be ironic if Smalltalk, which introduced so much of the visual vocabulary we use every day, turned out to be headless.” because somehow I think that it would be exactly the direction Smalltalk could succeed in. Cincom’s WebVelocity is probably a first decent attempt in that direction, but to me seriously lacks in several areas.

Although Smalltalk is considered old, to me it still has the core and concepts right but needs to “catch-up” … no, let me re-phrase that, “lead again” … on other fronts. Smalltalk was way ahead of its time on user experience and usability with the invention of the GUI, the mouse, the IDE and is now still in a great position to show how people can efficiently use computers to invent, innovate and share the results again. The IDE of today however should include so much more … requirements, source control, ticketing, deployment, continuous integration …but more importantly, it should not be limited to programmers but probably should be used-by and engage management and system users for feedback etc.

adminFebruary 13th, 2010 at 4:04 pm

I would be glad to participate in followup discussions. I understand that mine is just one perspective, that of someone who’d like to contribute to Smalltalk and wants to make sure that my limited ability to invest goes as far as possible.

Carlos CrosettiFebruary 14th, 2010 at 5:43 am

Kent, waht is the ETA of the alpha version of the Monngo DB layer?

adminFebruary 14th, 2010 at 8:34 am

It should be ready for simple uses now. There’s no error handling or performance tuning, but you can get data into and out of a database. The basic usage scenario is:

root := Mongo hostName: ‘’ port: 1234.
database := root databaseNamed: ‘xyz’.
users := database collection named: ‘users’.
“Users now acts like a real collection whose elements are dictionaries whose keys are strings and values are ints, floats, dates, strings, arrays, or similar dictionaries”
users add: (Dictionary new at: ‘first’ put: ‘Kent’; at: ‘last’ put: ‘Beck’; yourself).
“To query, use select:”
becks := users select: (Dictionary new at: ‘last’ put: ‘Beck’; yourself).
“You can also use do:, inject:into:, size, and remove:”

This will work in Squeak and VisualWorks by loading the Monticello Mongo-* packages from

If you try it let me know how it works out.


The Smalltalk Archipelago « (gem)Stone SoupFebruary 14th, 2010 at 2:00 pm

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

Jecel Assumpção JrFebruary 15th, 2010 at 5:46 am

Kent, perhaps this can’t be a sensible proposal, as you said, but it was more or less what I had suggested to the new ANSI effort -

Ron SpenglerFebruary 16th, 2010 at 10:04 pm

Mr. Beck,

As an advocate of TDD, you stand as a hero of mine. And I’m really just adding a footnote here, but I will reiterate what I said on the Squeak list not long ago, before I found this post.

It’s Balkanized, you’re dead right. Who’s going to change that? ANSI? I doubt it. The standard is ancient. It doesn’t speak to the problems the community has now.

What we need, and I can see that you’re in agreement, is an *executable* standard. TESTS. ANSI won’t ever give us that. I’d like to see it happen any damned way, and I would contribute any way I was able; but I have neither the reputation, the time, nor the experience to lead such an adventure.

Hint, F-ing HINT, man! Don’t complain idly, take action. Most Squeakers are annoyed with what a fantastic research-refuse mess it’s become. We’re working really hard in our own ways to clean that mess up. Commercial vendors will do what is in the interest of their bottom lines; open source people will get behind things they believe in.

I’ve recently asserted that the requirements of the applications (e.g., Seaside) that Smalltalk developers are interested in must define what tomorrow’s standard should be. I will hold to that. I think that the Seaside test suite is more interesting than Squeak, VW, or Pharo. Maybe we should be looking at fixing things that are broken with those tests? Adding tests. Enhancing existing tests. Because the tests *must* define the platform. No one, nothing else will.

Everyone disagrees about what the standard should look like. I say: start with ST-80, and diverge where it makes sense to support the applications we care the most about. Write tests that support this philosophy. Forget about ANSI, ANSI is dead.

I hope I haven’t just fanned the flames of your frustration? We could really use your help, man.

- Ron

Alejandro ReimondoFebruary 17th, 2010 at 5:02 am

I think the real problem is that you are trying to port source code; that way you are not exploiting capabilities of Object Systems.
The only reference to “vendors” in your text is to Cincom… imo you are missing interesting alternatives to produce smalltalk based systems.
There is a lot of smalltalkers today that insist considering smalltalk as a (dynamic) language. That way they are constrained by the simulation paradigm, that do not let move outside the global path (the commons and the freedom to replicate code [*]).
Hope this words can help to start a search on real(productive) alternatives.
What are smalltalk based companies doing to sustain new efforts to make smalltalk the best platform for development of object systems (again)?

adminFebruary 17th, 2010 at 6:53 am


Thank you for the encouragement. I hoped to add value to the Smalltalk community by making it easy to access and manipulate large volumes of information. That task was made unnecessarily expensive by gratuitous (from my perspective) differences between Smalltalks. I can see that those differences serve the interests of other parties. My hope is that the individuals in the community will make informed decisions to either live with or eliminate these differences.

Improving Ruby « Metaphysical DeveloperMarch 31st, 2010 at 7:49 pm

[...] declare than Smalltalk’s. After readingthis in-depth comparison of both, and Kent Beck’sarticle on the incompabilities of Smalltalk’s VM implementations, I realized that I was generally [...]

Leon SmithMarch 13th, 2012 at 11:21 am

Hey Kent, I know this thread is ancient, but just stumbled on it.
Have you checked out Amber yet ? They try to use Pharo syntax, but work with Javascript seamlessly. The main appeal to me is the lack of bloat. I was really getting tired of that. I’m having a lot of fun with it, sure you would too. Developing Smalltalk apps in a Browser is damn near nirvana.

sebastianOctober 29th, 2012 at 5:50 am

I agree with Leon Smith here.

The trend of spreading V8′s and now Dart is fabricating a blossom of dynamic technologies.

Amber and S8 are quite interesting for new projects.

For migration of stuff? probably not