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.
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.
When I did Smalltalk development, documentation was never an issue. In fact, in always every development environment/language that I've programmed, I'd always felt handicapped if I was not able to browse the source. Given the choice, I'd definitely prefer sensibly written source code over written documentation.
That said, perhaps this doesn't work for the significant chunk of professional programmers, and most would agree that Smalltalk's chance to take over the world has passed. We should also ask ourselves if we dumb down every tool so it is usable by a significant chunk of programmers (note that I don't say professional programmers, because that's besides the point here), what are we left with? There's plenty of tools to choose from.
I like being able to browse the source too--in fact, I depend on it for debugging Java programs. But that has never been considered "the" documentation for Java, and in many cases (I'm looking at you, Morphic) it is the case with Smalltalk.
If the Smalltalk community wants to remain small, insular and essentially irrelevant then they shouldn't change anything. However, if they want to win people back, it would be a good idea to take stock of what the rest of the world is up to and consider adopting it rather than insulting it. Clojure is conquering the Lisp world today largely by absorbing modern FP techniques, a modern base and adding clever bits of syntax--changes that would have been heavily derided as unnecessary by the traditional Lisp community.
When your community is small, self-selected and indignant, it's hard to know what changes will make your product more appealing. But defending a lack of progress and chalking low usage up to the inferiority of other programmers is insane, especially in a world with increasing numbers of Haskell programmers.
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.
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.
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.
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.
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.
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:
> 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)
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.
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.