Is there any fundamental technical barrier to compiling to JVM byte codes?

nothing is impossible if you give it either infinite amount of resources or infinite time. I think it would be a great idea, most likely doable with a good team . That would mean probably the redesign of all FFIs but it would gives us the ability to run tons of java libraries out of the box. Would pharo be the same thing ? who cares, same is boring the real fun is to move forward and improve constantly. 

Personally I dont care if pharo moves to JVM or not , I only care that it moves forward and seem people excited and having fun with it. 

Of course I would never sacrifice the very things that make Pharo special like live coding, in favor of popularity. I have said before and I will say it again I have zero issues with pharo not being popular, I tasted popular, boring and annoying as hell. I am here because pharo is special and I want it to remain special, a rebel , a fun way to code, an alternative way of thinking. 

If I wanted popular I would be coding in Java. 

On Tue, Dec 24, 2013 at 3:13 PM, Sven Van Caekenberghe <[hidden email]> wrote:

Andy,

On 22 Dec 2013, at 18:38, Andy Burnett <[hidden email]> wrote:

> I am sure it would be a huge amount of work, and may not be a good idea at all.
>
> However, given the number of dynamic languages that now compile to JVM
> byte codes, I am curious whether there is anything about Pharo that
> would make this impossible?
>
> Cheers
> Andy

This is a complex subject area which touches on many things/issues. I am not capable of producing a good writeup, but I’ll try to give some kind of answer.

It is really hard to define what makes Pharo (or Smalltalk) unique compared to so many other environments. As you know, it is the special combination of language, library, IDE and VM that constitutes the real magic: a live, dynamic, late bound language with meta level capabilities, including many libraries, frameworks and tools, written in itself.

Like with Lisp, many/most of the features of Smalltalk can be found here and there in other languages. Like with Lisp, there are many implementations of some kind of Lisp/Smalltalk. This has all been done before.

Moving Pharo (or Smalltalk) away from its own VM is certainly possible (up to a point), but the question is: is it still the same thing ? If you can no longer write your own debugger implemented in the same language ? If you cannot read code all the way down ?

Regards,

Sven

<<<From: St?phane Ducasse <[hidden email]>

The fun is important.
What we want is well designed and powerful libraries that enabled people.
For the JVM question: it is a question of resources + the fact that jvm do not really support well some key smalltalk operations.
Now I do not understand why people develop their own vm instead of joining forces.
Doing in the long term something and finishing a task are the most difficult things.
Stef

ᐧ

>>>

Thank you to everyone for your comments. I am replying to Stephane's email, just as a catch all.

I am curious to know more about the limitations in the JVM. My thinking was sparked - in part - by Mark Roos's work on RTalk.

I realised, after my post, that he had actually worked the other way around, i.e. I think he built a Digitalk bytecode layer on top of the JVM, rather than compiling to JVM bytecodes.

Either way, what I was vaguely wondering about was how difficult it would be to have a 'compile to JVM' option in Pharo. I could probably live - quite happily - developing in 'real' Pharo, and then deploying an app to e.g. Google App Engine, as a compiled Jar. Obviously, it would be much better to retain all the dynamism of a true Smalltalk environment even when the app has been deployed, but it it gave simple hosting, and scaling, it might be a reasonable trade off.

I agree with Stephane, it would be great for people to join forces around a vm. Would make like so much easier.

Cheers

Andy