Is there any fundamental technical barrier to compiling to JVM byte codes?
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
If the question is whether there is anything fundamental about /Smalltalk/ that prevents compiling to JVM, we have proof to the contrary today in the announcement on comp.lang.smalltalk of Gravel Smalltalk, which aims to run ANSI Smalltalk on the JVM. It is clearly still in alpha stage, and the developers say they do not expect to implement become: or thisContext. Whether this would cripple Pharo is beyond my knowledge. Further information at https://github.com/gravel-st/gravel . Peter Kenny -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Andy Burnett Sent: 22 December 2013 17:38 To: pharo-users@lists.pharo.org Subject: [Pharo-users] Is there any fundamental technical barrier tocompiling to JVM byte codes? 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
Andy, On 22 Dec 2013, at 18:38, Andy Burnett <andy.burnett@knowinnovation.com> 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
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 <sven@stfx.eu> wrote:
Andy,
On 22 Dec 2013, at 18:38, Andy Burnett <andy.burnett@knowinnovation.com> 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
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.
:) 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
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 <sven@stfx.eu> wrote: Andy,
On 22 Dec 2013, at 18:38, Andy Burnett <andy.burnett@knowinnovation.com> 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
2013/12/25 Stéphane Ducasse <stephane.ducasse@inria.fr>
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.
http://c2.com/cgi/wiki?NotInventedHere is a possible explanation :) Cheers, Sergi
participants (6)
-
Andy Burnett -
kilon alios -
PBK Research -
Sergi Reyner -
Stéphane Ducasse -
Sven Van Caekenberghe