5 ms·

One of the contributors here, we believe that one of Smalltalk's problems has been it's inability to 'play nice with the outside world'. Smalltalk was designed

One of the contributors here, we believe that one of Smalltalk's problems has been it's inability to 'play nice with the outside world'. Smalltalk was designed to be the OS, the user environment, everything. It was one thing that encompasses what we now consider to be many different things. We are building a Smalltalk to fit into the existing jvm ecosystem. To work with eclipse, intellij, the profilers etc etc while still remaining at its core, a Smalltalk. Are we high? Maybe. But it is our axiom and what we believe in and we are giving it a shot.

flyinRyan 14y ago
Personally, I've always thought Smalltalk's problem was the exact opposite: it tried to be a portion of the OS but not quite enough. I'd like to see a Smalltalk that took some tips from Erlang.
- spooneybarger 14y ago
  you might find SqueakNos interesting: http://squeaknos.blogspot.com http://squeaknos.blogspot.com smalltalk was originally the entire stack, from the hardware all the way up, i agree that for a long time, it lived in a weird in between world where it was sort of an OS and sort of not. working out how to keep what makes 'smalltalk smalltalk' while ironing out those issues is something that both redline and pharo are trying to solve from different angles. i'm interested in hearing more about the taking tips from erlang idea. i'd love to chat more via email: sean@monkeysnatchbanana.com
  - flyinRyan 14y ago
    I actually prefer not to link my HN account to an email. Do you mind if we just discuss it on here or some similar format?
    - spooneybarger 14y ago
      throw away gmail account perhaps?
- masklinn 14y ago
  > it tried to be a portion of the OS but not quite enough That's actually a fairly recent problem (since the 90s maybe?) as Smalltalk implementors had to move onto "third-party" OS. The original smalltalk controlled everything but the hardware, much the same way Lisp Machines worked (yes I'm aware most lisps didn't work that way)
fusiongyro 14y ago
In my opinion, the biggest problem with Smalltalk is documentation (and perhaps rigor). It's the only oral tradition in programming, and you'll never win over a significant chunk of professional programmers with "we have no documentation, just read the source," which has always been the basic state of documentation in the Smalltalk world. Along those lines I would suggest creating a way to formally differentiate between private and public methods and perhaps formally define interfaces, so that you have more opportunities for implicit documentation. That may be detrimental to the spirit of Smalltalk, but unless the spirit of Smalltalk is willing to accept some concessions you're not going to see much change in the status quo.
- padillac 14y ago
  Redline will be nicely documented. Private methods and interfaces...probably not. It's a smalltalk.
- Benferhat 14y ago
  Lessons learned by Golang.
- spooneybarger 14y ago
  I fully agree about the documentation aspect. Redline is very much lacking in that area. When we shore up some code related stuff, I am going to working hard on documentation that exists outside the code.
  - fusiongyro 14y ago
    Can I infer from this that you aren't planning on the other changes (interfaces, public/private) I mentioned? :)
    - spooneybarger 14y ago
      I wouldn't infer that. I can say, we are aiming for 'standard' Smalltalk compatibility in version one and have had many discussions around diverging and becoming more of a 'inspired by Smalltalk' down the road. There have been numerous discussions around things we would like to add, change etc. Ideally, we want to maintain operability with other Smalltalks but that takes a back seat to building a great tool for the future. We'd welcome participation in getting us to V1 (code, documentation, web design, whatever) as well as participation on the mailing list for coming up with what the 'next gen' of a Smalltalk like language would look like.
mtrimpe 14y ago
Talking about fit with the ecosystem; I couldn't find any documentation on: a) how interop with Java is handled b) what kind of performance we'd be getting Based on what I've seen so far Redline could just as we'll be a naive Smalltalk VM written in Java. Clojure does it fairly well showing off interop with a few lines of idiomatic code and addressing performance by showing how close to the metal you can get with type hints and having the garbage collection tweaks ready to go.
- jeffheon 14y ago
  Here's a little blog post about Redline Java interop http://www.redline.st/blog/2012/11/20/automatic-java-class-integration.html http://www.redline.st/blog/2012/11/20/automatic-java-class-i... Short story: import: 'com.friendly.Greeting' as: 'Greeter'. Greeter new say.
  - mtrimpe 14y ago
    That short story is indeed what should receive some more emphasis in the marketing materials ;) Is there also a similar post about interop the other way around, like Clojure's gen-class? For piecemeal migration from Java to Smalltalk being able to compile a class to an existing interface is key since once you have that you can just plug it into the Spring context of any existing Java app and slowly migrate from there.
    - spooneybarger 14y ago
      We are indeed working on that. We have given it little 'marketing push' because it is still very immature.
vixen99 14y ago
its inability
asb 14y ago
Do you hope to support existing Smalltalk codebases, e.g. Scratch/BYOB?
- spooneybarger 14y ago
  We hope to. I'm not sure how realistic that will be. There have been several conversations around providing compat layers. No work has been done on that yet.

flyinRyan 14y ago

Personally, I've always thought Smalltalk's problem was the exact opposite: it tried to be a portion of the OS but not quite enough. I'd like to see a Smalltalk that took some tips from Erlang.

spooneybarger 14y ago
you might find SqueakNos interesting: http://squeaknos.blogspot.com http://squeaknos.blogspot.com smalltalk was originally the entire stack, from the hardware all the way up, i agree that for a long time, it lived in a weird in between world where it was sort of an OS and sort of not. working out how to keep what makes 'smalltalk smalltalk' while ironing out those issues is something that both redline and pharo are trying to solve from different angles. i'm interested in hearing more about the taking tips from erlang idea. i'd love to chat more via email: sean@monkeysnatchbanana.com
- flyinRyan 14y ago
  I actually prefer not to link my HN account to an email. Do you mind if we just discuss it on here or some similar format?
  - spooneybarger 14y ago
    throw away gmail account perhaps?
masklinn 14y ago
> it tried to be a portion of the OS but not quite enough That's actually a fairly recent problem (since the 90s maybe?) as Smalltalk implementors had to move onto "third-party" OS. The original smalltalk controlled everything but the hardware, much the same way Lisp Machines worked (yes I'm aware most lisps didn't work that way)

fusiongyro 14y ago

In my opinion, the biggest problem with Smalltalk is documentation (and perhaps rigor). It's the only oral tradition in programming, and you'll never win over a significant chunk of professional programmers with "we have no documentation, just read the source," which has always been the basic state of documentation in the Smalltalk world. Along those lines I would suggest creating a way to formally differentiate between private and public methods and perhaps formally define interfaces, so that you have more opportunities for implicit documentation. That may be detrimental to the spirit of Smalltalk, but unless the spirit of Smalltalk is willing to accept some concessions you're not going to see much change in the status quo.

padillac 14y ago
Redline will be nicely documented. Private methods and interfaces...probably not. It's a smalltalk.
Benferhat 14y ago
Lessons learned by Golang.
spooneybarger 14y ago
I fully agree about the documentation aspect. Redline is very much lacking in that area. When we shore up some code related stuff, I am going to working hard on documentation that exists outside the code.
- fusiongyro 14y ago
  Can I infer from this that you aren't planning on the other changes (interfaces, public/private) I mentioned? :)
  - spooneybarger 14y ago
    I wouldn't infer that. I can say, we are aiming for 'standard' Smalltalk compatibility in version one and have had many discussions around diverging and becoming more of a 'inspired by Smalltalk' down the road. There have been numerous discussions around things we would like to add, change etc. Ideally, we want to maintain operability with other Smalltalks but that takes a back seat to building a great tool for the future. We'd welcome participation in getting us to V1 (code, documentation, web design, whatever) as well as participation on the mailing list for coming up with what the 'next gen' of a Smalltalk like language would look like.

mtrimpe 14y ago

Talking about fit with the ecosystem; I couldn't find any documentation on: a) how interop with Java is handled b) what kind of performance we'd be getting Based on what I've seen so far Redline could just as we'll be a naive Smalltalk VM written in Java. Clojure does it fairly well showing off interop with a few lines of idiomatic code and addressing performance by showing how close to the metal you can get with type hints and having the garbage collection tweaks ready to go.

jeffheon 14y ago
Here's a little blog post about Redline Java interop http://www.redline.st/blog/2012/11/20/automatic-java-class-integration.html http://www.redline.st/blog/2012/11/20/automatic-java-class-i... Short story: import: 'com.friendly.Greeting' as: 'Greeter'. Greeter new say.
- mtrimpe 14y ago
  That short story is indeed what should receive some more emphasis in the marketing materials ;) Is there also a similar post about interop the other way around, like Clojure's gen-class? For piecemeal migration from Java to Smalltalk being able to compile a class to an existing interface is key since once you have that you can just plug it into the Spring context of any existing Java app and slowly migrate from there.
  - spooneybarger 14y ago
    We are indeed working on that. We have given it little 'marketing push' because it is still very immature.

vixen99 14y ago

its inability

asb 14y ago

Do you hope to support existing Smalltalk codebases, e.g. Scratch/BYOB?

spooneybarger 14y ago
We hope to. I'm not sure how realistic that will be. There have been several conversations around providing compat layers. No work has been done on that yet.