for the smalltalkers here...
Locked
12
12
 
|
If I asked you to explain 'Why Smalltalk?' to someone who hadn't used it, what would you say? |
Re: for the smalltalkers here...
|
|
I wouldn't argue with technical issues, since there is exactly nothing you can do in a Smalltalk environment, that you can't do in an e.g. J2EE/ EJB or Spring environment. And nowadays there is no proof for a correlation of productivity and the usage of Smalltalk.
My main argument for smalltalk is that i love smalltalk. After producing Java code i lean back, look at it and say something like: "ok, it works. next issue" or "great! but i hate that f*cking iterator-pattern. And i hate generics!" When i write Smalltalk code, i look at it and say something like: "ok, it works and i love it - it looks elegant" In my experience smalltalkers love their language while Java-Developers only use it. And due to this fact Smalltalkers create really really cool things and are able to invent the future. Java Developers are more pragmatic and create solutions for problems they hadn't if they were using smalltalk from the beginning on. here i think about frameworks like, common-utils, common-collections or beanutils etc. regards, Stefan
|
|
|
Java doesn't have resumable exceptions.
Java doesn't have closures. I consider those to be technical issues. On Wednesday, November 23, 2011 at 4:36 AM, Stefan Krecher wrote:
|
|
|
In reply to this post by SeanTAllen
From a Java perspective:
I am an active Java developer and love the language (all warts included). Having read some Alan Kay article I picked up Smalltalk just for fun. Lo and behold! A language that combines the elegance and fullness of simplicity with an elegant expressiveness. It is simply a joy expressing Your thoughts in smalltalk. the only things I always missed were: - proper multi-threading - better mechanisms for sealing classes. I know the smalltalk world works more in the spirit of the anarcho hacker world, but having more formal means for saying: "implementation detail dont look dont change" would be nice. - more possibilities for structuring the namespace. One reason why I still find Java inspiring is that it is a hotbed for developing new ideas: AOP, IoC, Hibernate come to mind. But the ironic thing is: many of these developments & ideas lead to new features (Java 5 annotations) in the Java platform, now looking back at smalltalk You realize that the language itself is readily able to express and implement all these things without many quirks and without wanting to change the language spec. I think that is one of the most compelling reasons for wanting smalltalk on the JVM. Oh and if You still need reasons to give smalltalk a try: help Yourself to some seaside time and forget the nighmares of things like JSF/Struts/Grails. |
Re: for the smalltalkers here...
|
|
In reply to this post by SeanTAllen
i would say these are technical differences - no (killer) arguments for selecting smalltalk. i can work with try/ catch/ finaly and i absolutely don't need closures. in forthcoming java versions closures might be supported. AFAIK the Smalltalk language does not support closures. -- Am 23.11.2011 15:15 schrieb "Sean T Allen" <[hidden email]>:
|
|
|
In reply to this post by SeanTAllen
It's the image.
The syntax and semantics of the language are nice, but the real killer feature of Smalltalk is the image. Nothing else comes close.
Java's HotSpot VM can be nice compared to the normal cycle of compile-rest-run-debug, but it's not turtles all the way down. At some point, it won't be able to swap out the classes and you have to restart.
Perl, Python, Ruby, etc have REPLs to support interactive development, but you're still operating indirectly through text. They're missing the sense of direct manipulation that you get in an image.
Lisp and Forth (and JavaScript!) have approached, but none of them have fully bloomed into the hyper-productive environments that the Smalltalks have. Why is the image so productive? I believe it has to do with entering the flow state, or rather with staying in the flow state. The technical barriers are lower and smoother in a live image than they are when you have to switch back and forth between live programs and "dead" code.
To be honest I was dismayed to learn that Redline would be file-based initially. To really live up to the claim that nothing else is as productive, Redline needs to nail having a live Smalltalk image seamlessly on the JVM.
-Aaron On Tue, Nov 22, 2011 at 1:53 PM, Sean T Allen <[hidden email]> wrote:
|
|
|
In reply to this post by Stefan Krecher
Smalltalk has closures.
try/catch/finally is nothing like resumable exceptions. i can't restart after an exception at any point in the execution chain w/ java. that is immensely powerful.
from what i can see, your basic point is that there is no reason to pick smalltalk or any other language except that you like smalltalk. that they are all the same. you can accomplish the same thing in different ways with any language so it doesn't matter how you get there.
would you disagree w/ my reading of what you are saying? On Wed, Nov 23, 2011 at 11:33 AM, Stefan Krecher <[hidden email]> wrote:
|
|
|
In reply to this post by Aaron Olson
On Wed, Nov 23, 2011 at 11:53 AM, Aaron Olson <[hidden email]> wrote: To be honest I was dismayed to learn that Redline would be file-based initially. To really live up to the claim that nothing else is as productive, Redline needs to nail having a live Smalltalk image seamlessly on the JVM. And having just an image w/o having a way to interact with a file based world is a recipe for non adoption. Images can be very important in smalltalk development but I think it has been elevated to a level where the commensurate denigration of file based alternatives isn't helpful. There are problems with image based development just like there are problems with a strictly file based approach.
We will probably never satisfy those for whom the image is sacrosanct because we want to appeal to a wider audience of people who know eclipse and intelli-j and want to continue working in that environment. We want to make it easy to seamlessly use redline in a project that contains java, scala, groovy, clojure or whatever... and that means playing in a file based world.
That story of fitting in with the world of the jvm is always going to be more compelling than the image. I have always envisioned that in the early days when redline is first ready for non contributors usage, that many would use pharo as their development environment and redline as a target platform. We've known from the beginning that decision wasn't going to be popular with some people. I don't think we are heading down the wrong path by addressing first how smalltalk fits into a file based world and the tools on the jvm and then address how do we make an image work in that world.
-Sean-
|
|
|
In reply to this post by Aaron Olson
>>At some point, it won't be able to swap out the classes and you have to restart.
Not with Redline Smalltalk, we take care of this. >>Redline needs to nail having a live Smalltalk image seamlessly on the JVM. There is another project on the JVM that is doing image saving and reload. We plan to make use of this when it is available. On Thu, Nov 24, 2011 at 3:53 AM, Aaron Olson <[hidden email]> wrote: It's the image. |
Re: for the smalltalkers here...
|
|
On Wed, Nov 23, 2011 at 3:41 PM, James Ladd <[hidden email]> wrote: >>Redline needs to nail having a live Smalltalk image seamlessly on the JVM. Do you know anything more about this project? Who's involved? What's the name of it? Where it's hosted? I'd like to know more about it....
I'm with Aaron on the live image being the magic of developing on Smalltalk (perhaps some of the simplicity of the syntax also has to do with flow).
|
|
|
I will find out and post a.s.a.p - I don't remember the name off hand.
On Thu, Nov 24, 2011 at 7:59 AM, Kevin Driedger <[hidden email]> wrote:
|
|
|
Not sure if it's the same thing, but there is this one:
http://robilad.livejournal.com/81047.html http://www.wiki.jvmlangsummit.com/images/e/e5/Roos-Rtalk.pdf On Nov 23, 4:02 pm, James Ladd <[hidden email]> wrote: > I will find out and post a.s.a.p - I don't remember the name off hand. |
Re: for the smalltalkers here...
|
|
In reply to this post by SeanTAllen
Am Mittwoch, 23. November 2011 18:27:31 UTC+1 schrieb Sean T Allen:
just to clarify - i think that you won't convince an experienced Java/ C++/ $whatever Programmer to use Smalltalk, because it has closures or resumable exceptions. Yes: because he can do the same things with "his" language. And also you won't convince a business person/ project manager to decide to use smalltalk in his next project because it is more productive. I can't imagine that a team of experienced Smalltalk-Developers will develop an enterprise application faster with higher quality than a team of experienced JEE Developers (i'm not saying that the JEE Developers will be faster/ better). I believe that the only way to increase the usage of smalltalk is to get developers to try out smalltalk. They will see that smalltalk-development is fun and they will love it. And maybe a few years later, when those developers are in the position to deceide which platform to use, they could select smalltalk. Redline is a great way to achieve this goal. Java Programmers will try it and they will love it. You can develop clean and maintainable Applications in Java and you can build cluttered and ugly applications in smalltalk. From my point of view, the difference is that smalltalk-programmers love "their" language and have more fun producing nice code. I think redline could bring back the fun to software-development. |
|
|
In reply to this post by Kevin Driedger-4
On Wed, Nov 23, 2011 at 3:59 PM, Kevin Driedger <[hidden email]> wrote:
I think there are two things that go with a 'live image' and need to be broken apart for the sake of discussion: 1: inspecting and interacting with objects during an individual session of a program.
2: long lived objects that continue to exist from one run to another, ie the persistence story. I'm far more interested in getting #1 in place than number 2. Number one is hugely important.
The 'live' environment while you are touching it and it is part of what we are working on. Resumable exceptions, 'this context' etc don't mean a whole lot without that live environment.
The ability to snapshot the state of that environment and bring it back ( what many people mean when they refer to the image ) is less important of a story to me personally. I think it is a nice to have but in terms of all the things that need to be
worked on, I can live without it for a while. Yes, I love hitting a bug, saving the image and sending it to other people for help. That is awesome. I love saving my environment in mid debug and bring it back up later when I'm fresh to work on it.
But, these are things I can live without for a while. Story #2 to me is harder to fit into the jvm world than #1. #2 requires more thought about how to do it seemlessly.
Recreating a locked in image on the jvm that can't play nice w/ clojure, groovy, java etc isn't a big win, it's an opportunity lost. Story #1 can and will be done. On a base level it isn't horribly hard ( it isn't horribly easy either )- the big part of that story will
be tooling. I wish I could say tooling was going to be easy, but we all know that ends up being a pain. If story 2 is important to you, we welcome contributions of all sorts. Heck, if story #1 or some other story is important to you, we'd
love to find a way to get your contributions. We were once 1, then 2 etc. There are 4 of us now working on different parts, we'd love it to be more. -Sean- |
|
|
In reply to this post by Stefan Krecher
>>I think redline could bring back the fun to software-development.
That's going strait to twitter! On Thu, Nov 24, 2011 at 8:28 AM, Stefan Krecher <[hidden email]> wrote: Am Mittwoch, 23. November 2011 18:27:31 UTC+1 schrieb Sean T Allen: |
|
|
In reply to this post by SeanTAllen
On Wed, Nov 23, 2011 at 4:28 PM, Sean Allen <[hidden email]> wrote:
This is heartening. Will you be able to poke at objects created outside of Redline?
I think you're making the correct choice by favouring smooth JVM adoption over image purity; I guess my dismay has more to do with the reality that it's the right one!
-Aaron -Aaron |
|
|
On Wednesday, November 23, 2011 at 4:58 PM, Aaron Olson wrote:
Can you clarify what you mean by 'poke at objects' created outside of redline? You mean something created in clojure/java/scala/groovy etc? |
|
|
On Wed, Nov 23, 2011 at 5:17 PM, Sean T Allen <[hidden email]> wrote:
|
|
|
On Wednesday, November 23, 2011 at 5:36 PM, Aaron Olson wrote:
We work on the bytecode level. We should be able to do lots of poking. I'd don't want to say much more beyond that because we have done very little poking so far. In theory this should work well. The goal is to interoperate with java, clojure, groovy or whatever else. You can do this now. It just isn't very pretty. Pretty will come later. -S-
|
|
|
I have done a LOT of poking.
You can issue whatever bytecode the JVM supports, meaning it the JVM can do it, you can too. What we done want to show yet is the mechanism for emitting the bytecode as it is verbose and we want to clean it up. On Thu, Nov 24, 2011 at 9:57 AM, Sean T Allen <[hidden email]> wrote:
|
«
Return to Redline Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |