because we believe that being on jvm will be smalltalk to a wider audience and over time we can leverage the concurrency libraries, profiling libraries etc etc etc that the jvm has to offer and build a smalltalk for the future.

we share the same goals as pharo, just a different idea of how to get there.

Makes sense. Have you considered porting Squeak itself to JVM? This would get the JVM benefits, and the similar "take advantage of existing stuff" from the Smalltalk side.

Just to be clear: I'm not in any way invested in Squeak or Pharo, just curious about your approach. Well, this and also perhaps a bit skeptical about implementing new stuff when similar stuff exists.

I wrote tool that can export classes from pharo/squeak in the syntax that redline expects. My original idea with this was to aid people who want to develop in Pharo and deploy to redline. In order to make that happen, there would have to be a lot more work done.

There have been several discussions about using that tool to export large chunks of pharo and using that as the basis for the redline class library. I personally have tended to resist that (and swayed many people) because it brings along with it a ton of cruft. That said, we all have full time jobs and I'm starting to think that it would be better to start with cruft and remove rather than starting clean and build up. Which side of that I fall on, really varies from day to day. I'm thinking of taking a chunk of pharo and seeing how hard an export of modify would be vs. doing the implementation from scratch.

https://github.com/redline-smalltalk/redline-smalltalk/tree/...

Well, Dan Ingalls did something a like that. He implemented a Squeak VM in Java. It's six years old, and even then it didn't run a current Squeak image, but it works pretty well.

Announcement here:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-...

JAR file here:

http://weather-dimensions.com/Dan/SqueakOnJava.jar

Thanks for this. I didn't know that existed.

versioning, code collaboration, and as other people mentioned ecosystem off the top of my head.

Versioning actually tends to work better in Pharo/Squeak because once you have a version system dedicated to one language you're free to go ahead and understand the syntax of that language. I'm not sure how much of that they take advantage of today but there was talk several years ago of doing things like this.

i think you might be referring to this:

http://www.esug.org/wiki/pier/Conferences/2010/Talks/Montice...

i haven't really watched monticello 2, but last I remember you're essentially merging packages in and out of your vm.

it really depends on what your goals are, and I guess the old discussion of visual and non visual programming also applies a little bit to the vm, non vm smalltalk discussion.

personally i like to avoid magic whenever i can

What's wrong with monticello? Ecosystem is a valid point, but I don't see problems with collaboration and versioning

Especially with the work that has gone into have a git backend for Monticello.

well as i mentioned above the whole idea behind monticello goes hand in hand with the idea of having to program a/in a vm. you may like the vm/object structure more than a file based structure, but ymmv.

not to mention that when we were evaluating squeak a year or so back git was nothing more than a half assed gsoc project.

but even so, the fact that you can pipe anything into git one way or another doesn't change the fact that they are conceptually different, but if it does, feel free to correct me.

If anything, Monticello and many of the collaboration practices in Smalltalk were intellectual forerunners to git.

I thought the frontrunner to git was bitkeeper, which as all the other versioning systems grew out of the experiences from DVS, which i guess refers to what you said, but bitkeeper was built long before monticello.

how does git backend for monticello work? does it turn objects into text so they can be versioned in git? if so that's exactly what dvs was doing for cvs.

see: http://www.stic.st/conferences/stic12/stic12-abstracts/pract...

Perhaps you are confusing vm and image?