[Pharo-project] Redline Smalltalk on heroku ....
Redline Smalltalk is easily deployed to Heroku, a cloud service. So writing web apps in Smalltalk and deploying them to the could just got a whole let easier. https://stout.herokuapp.com/ Please support the Redline project here: http://www.indiegogo.com/smalltalk/x/1366536 YES - We are providing classes to make deploying Pharo app to Redline a snap. Heroku work was done by Will Leinweber His github repo has the project and code.
On Nov 30, 2012, at 10:08 PM, James Ladd <james_ladd@hotmail.com> wrote:
Redline Smalltalk is easily deployed to Heroku, a cloud service.
So writing web apps in Smalltalk and deploying them to the could just got a whole let easier. https://stout.herokuapp.com/
Please support the Redline project here: http://www.indiegogo.com/smalltalk/x/1366536 YES - We are providing classes to make deploying Pharo app to Redline a snap.
We will see⦠it's hard to implement a real smalltalk in Java (think about #become:â¦), but I fear it will be even harder to follow where Pharo is going⦠(We can discuss that over a beer sometime :-) Marcus
I am one of those developers coding Java for a living, but day-dreaming of using Smalltalk instead. As such, the Redline project of course cought my attention and took a look at it. I am no authority on Redline, but I think there is some confusion here that I could clarify. 2012/11/30 Marcus Denker <marcus.denker@inria.fr>:
We will see⦠it's hard to implement a real smalltalk in Java (think about #become:â¦), but
I think Redline is not trying to be a full-fledged Smalltalk (not like the Squeak port to the JVM). It is more in the spirit of Amber. A Smalltalk-to-Java compiler, with some underlying runtime support. It does not aim at supporting the full enchilada :-) Are there some vital things that are impossible if #become: is missing? (no irony in my question, I just don't know)
I fear it will be even harder to follow where Pharo is goingâ¦
Again, I think the comment was meant to mean that Pharo-based projects could be exported to the Redline source format, and made be to run there also. Not that Pharo (core) code will/can run automatically on Redline. Many things just will never run or not make sense at all (Fuel, Monti-/Metacello, Polymorph/Spec, NativeBoost, etc.) I for one welcome the possibility to be able to run Smalltalk in one more runtime-environment. Smalltalk should run everywhere! :-) On the other hand I am also aware that the experience of coding in Maven/Eclipse projects is just not the same as in an environment like Pharo. It is just... different. I found joy and sorrow on both sides ;-) Cheers, Sebastian
Are there some vital things that are impossible if #become: is missing? (no irony in my question, I just don't know)
Changing a class on the fly. #become: is used behind the scene Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Ok, wow. Didn't know that. So, whenever I change a class, I have both the old version and the new version co-existing? And then the instances are told to become: instances of the new class? Thanks for the info. 2012/12/1 Alexandre Bergel <alexandre.bergel@me.com>:
Are there some vital things that are impossible if #become: is missing? (no irony in my question, I just don't know)
Changing a class on the fly. #become: is used behind the scene
Ok, wow. Didn't know that.
So, whenever I change a class, I have both the old version and the new version co-existing? And then the instances are told to become: instances of the new class?
Yes Alexandre
2012/12/1 Alexandre Bergel <alexandre.bergel@me.com>:
Are there some vital things that are impossible if #become: is missing? (no irony in my question, I just don't know)
Changing a class on the fly. #become: is used behind the scene
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi guys just for your information this mailing-list is Pharo-development. You can discuss a lot of topics in Pharo-users but in Pharo-dev we would really appreciate to get a bit focused. I try to read all the mails to be able to help people but it means processing a lot of mails :) and I really have a lot of duties that are not pharo related and I would appreciate to get my pharo time for pharo. Stef On Dec 1, 2012, at 9:52 PM, Alexandre Bergel wrote:
Ok, wow. Didn't know that.
So, whenever I change a class, I have both the old version and the new version co-existing? And then the instances are told to become: instances of the new class?
Yes
Alexandre
2012/12/1 Alexandre Bergel <alexandre.bergel@me.com>:
Are there some vital things that are impossible if #become: is missing? (no irony in my question, I just don't know)
Changing a class on the fly. #become: is used behind the scene
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
You're right, sorry :-) 2012/12/1 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi guys
just for your information this mailing-list is Pharo-development. You can discuss a lot of topics in Pharo-users but in Pharo-dev we would really appreciate to get a bit focused. I try to read all the mails to be able to help people but it means processing a lot of mails :) and I really have a lot of duties that are not pharo related and I would appreciate to get my pharo time for pharo.
Stef
On Dec 1, 2012, at 9:52 PM, Alexandre Bergel wrote:
Ok, wow. Didn't know that.
So, whenever I change a class, I have both the old version and the new version co-existing? And then the instances are told to become: instances of the new class?
Yes
Alexandre
2012/12/1 Alexandre Bergel <alexandre.bergel@me.com>:
Are there some vital things that are impossible if #become: is missing? (no irony in my question, I just don't know)
Changing a class on the fly. #become: is used behind the scene
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Dec 1, 2012, at 10:19 PM, Sebastian Nozzi wrote:
You're right, sorry :-)
:)
2012/12/1 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi guys
just for your information this mailing-list is Pharo-development. You can discuss a lot of topics in Pharo-users but in Pharo-dev we would really appreciate to get a bit focused. I try to read all the mails to be able to help people but it means processing a lot of mails :) and I really have a lot of duties that are not pharo related and I would appreciate to get my pharo time for pharo.
Stef
On Dec 1, 2012, at 9:52 PM, Alexandre Bergel wrote:
Ok, wow. Didn't know that.
So, whenever I change a class, I have both the old version and the new version co-existing? And then the instances are told to become: instances of the new class?
Yes
Alexandre
2012/12/1 Alexandre Bergel <alexandre.bergel@me.com>:
Are there some vital things that are impossible if #become: is missing? (no irony in my question, I just don't know)
Changing a class on the fly. #become: is used behind the scene
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 30 Nov 2012, at 23:33, Sebastian Nozzi <sebnozzi@gmail.com> wrote:
I think Redline is not trying to be a full-fledged Smalltalk (not like the Squeak port to the JVM). It is more in the spirit of Amber. A Smalltalk-to-Java compiler, with some underlying runtime support. It does not aim at supporting the full enchilada :-)
IMO, the secret of Smalltalk is a delicate combination of elements, take some out and the magic is gone. Java/JVM makes a distinction between int and Integer (and so on), cannot add methods to closed classes, has some meta capacity but not all, needs much more typing, cannot change many things at run time, and so ⦠The question is: how much do you need for it to be this magical Smalltalk thing ? Objective-C is also clearly Smalltalk inspired, more so than Java, (dynamic typing / messaging) but you can hardly call it a real Smalltalk system/experience. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On Dec 1, 2012, at 8:36 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 30 Nov 2012, at 23:33, Sebastian Nozzi <sebnozzi@gmail.com> wrote:
I think Redline is not trying to be a full-fledged Smalltalk (not like the Squeak port to the JVM). It is more in the spirit of Amber. A Smalltalk-to-Java compiler, with some underlying runtime support. It does not aim at supporting the full enchilada :-)
IMO, the secret of Smalltalk is a delicate combination of elements, take some out and the magic is gone.
Another aspect is that what got me hooked to Squeak back than was the idea to go further than Smalltalk. To take what humanity learned since 1978, to take the hardware advances, and to build a system that is Smalltalk by *Spirit*, yet just *much* *much* more so. How can you do that if your main concern is "how do I get it to run on the JVM?". And why does it matter? In 2000, Java was hype. Now Java is the new Cobol. Do I want to spend the rest of my live to get a dead language to run on a boring platform? I, personally, decided that there are more interesting things to do. Just imagine what you could build instead! Marcus
2012/12/1 Marcus Denker <marcus.denker@inria.fr>:
IMO, the secret of Smalltalk is a delicate combination of elements, take some out and the magic is gone. Another aspect is that what got me hooked to Squeak back then was the idea to go further than Smalltalk. To take what humanity learned since 1978, to take the hardware advances, and to build a system that is Smalltalk by *Spirit*, yet just *much* *much* more so.
Can you share what you have/had in mind...? I find it very interesting, and could be inspiring for others...
How can you do that if your main concern is "how do I get it to run on the JVM?".
Well... you... don't... :-D I think it's not what the aim of Redline is. They want the language, some of its semantics (modifying classes of the fly should be supported, the author told me) and it should run on the JVM. It's a... pragmatic approach, if you want. I don't know what you guys do for a living - I used to program Java for the last 10 years, now I do Ruby at my current workplace; better, but still not Smalltalk. In order to extend and integrate with the current codebase I would even be grateful if there was, say, a Smalltalk-to-Ruby compiler. It would be nowhere the same as using Pharo, but it would be a start. But even then I don't know if my boss would approve (there's always the fear: "what happens once this dev is gone? who maintains his code?" - which is also sad, being Smalltalk so easy to pick up).
And why does it matter? In 2000, Java was hype. Now Java is the new Cobol. Do I want to spend the rest of my live to get a dead language to run on a boring platform?
What do you mean exactly by "dead"? (the "boring" I have no problem understanding ;-) As to mattering, well... it matters to the guys wanting to code Smalltalk and forced to do projects on a JVM basis... ;-) I think I agree with you that no great amount of innovation will come out of the JVM pretty much soon... maybe that's what you meant by "dead". It's just not the VM for innovative stuff. I, for example, am delighted about Cog, NativeBoost, Helvetia, distributed computation (like Croquet did?) etc. Very hard to do (or impossible) in a VM like the JVM...
I, personally, decided that there are more interesting things to do.
I also decided to give it a shot. And that's why when I see that one of the (if not *the*) goals of Pharo is to make possible to use Smalltalk professionally, it gave me hope. If I could program Smalltalk for a living, then... I would reach career nirvana. But for now I have to pay my bills :-(
Just imagine what you could build instead!
I'm trying, and it looks good! :-) Cheers, Sebastian
On 1 December 2012 19:36, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 30 Nov 2012, at 23:33, Sebastian Nozzi <sebnozzi@gmail.com> wrote:
I think Redline is not trying to be a full-fledged Smalltalk (not like the Squeak port to the JVM). It is more in the spirit of Amber. A Smalltalk-to-Java compiler, with some underlying runtime support. It does not aim at supporting the full enchilada :-)
IMO, the secret of Smalltalk is a delicate combination of elements, take some out and the magic is gone.
Java/JVM makes a distinction between int and Integer (and so on), cannot add methods to closed classes, has some meta capacity but not all, needs much more typing, cannot change many things at run time, and so â¦
I'm not sure that's a limitation of the JVM (not being able to extend classes, that is): in Clojure you can happily extend existing types through extend-type: (extend-type clojure.lang.IPersistentVector ComparableParser (eq [this that] (reduce #(and %1 %2) (map eq this that)))) comes from a library I'm working on. What's more, this extension is limited to this particular namespace. I _think_ this means that these extensions map selector namespacing. At any rate, you don't have the problems we have with overrides, because you can only use these functions when you import them (through require or use).
The question is: how much do you need for it to be this magical Smalltalk thing ? Objective-C is also clearly Smalltalk inspired, more so than Java, (dynamic typing / messaging) but you can hardly call it a real Smalltalk system/experience.
Indeed, that is the interesting question. (I don't really know the answer. "Aliveness" is part of it, but even trying to define aliveness is tricky. frank
Sven
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
2012/12/1 Frank Shearar <frank.shearar@gmail.com>:
I'm not sure that's a limitation of the JVM (not being able to extend classes, that is): in Clojure you can happily extend existing types through extend-type:
(extend-type clojure.lang.IPersistentVector ComparableParser (eq [this that] (reduce #(and %1 %2) (map eq this that))))
I'm no Clojure expert, but it looks like what you're doing is implementing an interface at runtime. If that's the case, the JVM has no problem doing that.
2012/12/1 Sven Van Caekenberghe <sven@stfx.eu>:
IMO, the secret of Smalltalk is a delicate combination of elements, take some out and the magic is gone.
Fully agree. Only a "pure" or "classical" Smalltalk would give you that "magic", the true "experience". But I think, and hope, that the Redline developers are aware of that. I can imagine that they are trading off some of the "experience" in order to gain library support and toolchain integration (like deploying to heroku, in this case).
Java/JVM makes a distinction between int and Integer (and so on), cannot add methods to closed classes, has some meta capacity but not all, needs much more typing, cannot change many things at run time, and so â¦
Yes, ok, but you are comparing Java to Smalltalk, which is not the case. You have languages running on top of the JVM, like JRuby, that also kind of conform to the Smalltalk idea (no primitives, everything is an object, you can modify classes at runtime, extend/open them, etc.)
The question is: how much do you need for it to be this magical Smalltalk thing ?
The question is: how much of the "magic" of Smalltalk can you live WITHOUT. If your answer is "zero" then Redline is clearly not for you ;-)
Objective-C is also clearly Smalltalk inspired,
Being it a compied language, for me the experience is also lacking.
more so than Java, (dynamic typing / messaging) but you can hardly call it a real Smalltalk system/experience.
Yes, completely agree. For me just because it has to be compiled. The second I have to re-start the application to see the changes reflected the magic is gone. If I cannot interact with objects, add/remove methods/variables, change the class hierachy, etc. while running, the magick is gone. Nothing beats Smalltalk's "experience". Cheers, Sebastian
On 1 December 2012 20:22, Sebastian Nozzi <sebnozzi@gmail.com> wrote:
2012/12/1 Sven Van Caekenberghe <sven@stfx.eu>:
IMO, the secret of Smalltalk is a delicate combination of elements, take some out and the magic is gone.
Fully agree. Only a "pure" or "classical" Smalltalk would give you that "magic", the true "experience".
But I think, and hope, that the Redline developers are aware of that. I can imagine that they are trading off some of the "experience" in order to gain library support and toolchain integration (like deploying to heroku, in this case).
Java/JVM makes a distinction between int and Integer (and so on), cannot add methods to closed classes, has some meta capacity but not all, needs much more typing, cannot change many things at run time, and so â¦
Yes, ok, but you are comparing Java to Smalltalk, which is not the case. You have languages running on top of the JVM, like JRuby, that also kind of conform to the Smalltalk idea (no primitives, everything is an object, you can modify classes at runtime, extend/open them, etc.)
The question is: how much do you need for it to be this magical Smalltalk thing ?
The question is: how much of the "magic" of Smalltalk can you live WITHOUT. If your answer is "zero" then Redline is clearly not for you ;-)
Objective-C is also clearly Smalltalk inspired,
Being it a compied language, for me the experience is also lacking.
Smalltalk _is_ compiled.
more so than Java, (dynamic typing / messaging) but you can hardly call it a real Smalltalk system/experience.
Yes, completely agree. For me just because it has to be compiled. The second I have to re-start the application to see the changes reflected the magic is gone. If I cannot interact with objects, add/remove methods/variables, change the class hierachy, etc. while running, the magick is gone. Nothing beats Smalltalk's "experience".
But this is, I think, the nub of your argument: it's not about compiling or interpreting. It's about the interaction with a running system versus write-run-pray. Ruby is in many ways very close to Smalltalk (even though it has a horrific syntax), but the usual way of writing it (in my experience at least) is much like working in Java: write something, run something, examine the output. frank
Cheers,
Sebastian
Lisp does from what I have seen and quite easily so. Probably I would be using common lisp is it was so much against GUIs and its graphics libraries were more mac friendly. How much important is smalltalk on JVM. Extremely ! Dont go far , just take at Clojure. Its rapidly becomes the new popular lisp and is super actively developed. What Clojure author was very smart not only did not compete with common lisp but bring to the table things that generally lisp libraries dont focus on, concurency. I think if Redline wants to be sucessful smalltalk that will even overtake other smalltalk concurency is something that can gives it alot of traction. Also we should not forget JVM and huge amount of libraries that comes with. I have a project in mind calling "Atlas" its mission is to allow smalltalk to use python libraries via sockets, it will be integrated to Ephestos which is my main project. I could make the bridge compatible with JVM libraries too. I dont know how much interest there is the community for using python and java libraries , and there is certainly disadvantages and sacrifices for doing so. But on the other hand why not have more options than pure smalltalk options. Especially when those option makes you avoid porting your code to python and java ;) ________________________________ From: Sebastian Nozzi <sebnozzi@gmail.com> To: Sven Van Caekenberghe <sven@stfx.eu> Cc: Pharo-project@lists.gforge.inria.fr Sent: Saturday, 1 December 2012, 22:22 Subject: Re: [Pharo-project] Redline Smalltalk on heroku .... Â Nothing beats Smalltalk's "experience". Cheers, Sebastian
participants (8)
-
Alexandre Bergel -
dimitris chloupis -
Frank Shearar -
James Ladd -
Marcus Denker -
Sebastian Nozzi -
Stéphane Ducasse -
Sven Van Caekenberghe