Comment by PommeDeTerre | Hacker News Reader

Comment by PommeDeTerre | Hacker News Reader

Parent Full thread

While I do think that this has merit, is it actually a viable project that could sustain itself after this initial period of development?

Smalltalk did bring some new ideas to industry back in the 1980s, when we were otherwise still using C, Fortran, COBOL, some Pascal variant, or assembly for most tasks.

These days, however, I'm not so sure that there are any compelling reasons to use it. There are many well-established languages today that offer essentially all of its most practical features, including ones that target the JVM. Its class library does appear outdated these days. Its development environment approach never really proved useful for real-world development in the past.

There are already existing Smalltalk environments of various types, including free and open source ones, but they never seem to get any significant traction, and we never really see them being used for any significant development. What would make this implementation's outcome be any different?

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.

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.

Can I infer from this that you aren't planning on the other changes (interfaces, public/private) I mentioned? :)

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.

Lessons learned by Golang.

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.

Here's a little blog post about Redline Java interop http://www.redline.st/blog/2012/11/20/automatic-java-class-i... Short story: import: 'com.friendly.Greeting' as: 'Greeter'. Greeter new say.

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.

We are indeed working on that. We have given it little 'marketing push' because it is still very immature.

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.

you might find SqueakNos interesting: 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

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?

throw away gmail account perhaps?

> 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)

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

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.

its inability

Well, the same happened to LISP languages. They never seem to get a lot of traction... until Clojure appeared.

I think that's part of what PommeDeTerre is asking; is there any oxygen left over for a JVM Scheme variant in a world with Scala and Clojure? (And an already-existing line of other languages trailing behind them.)

If this were just some other open source project, I'd say go nuts, but we've got a guy here who presumably could get a very good job volunteering to live on raman for 4-6 months to do this thing, so I think this question needs to be considered, even if the answer is ultimately "yes".

The reason you don't see many implementations of Scheme is that Java's calling conventions do not jive well with tail call optimization. This is the same reason that Clojure has the recur keyword: http://clojure.org/special_forms#Special Forms--(recur exprs*)

See also Scala's compiler, which detects and re-writes tail calls as stackless iterations (http://oldfashionedsoftware.com/2008/09/27/tail-recursion-ba...)

Wondering when the "Clojure has a big traction" meme will die already, or at least be qualified with "in HN discussions". I give it a year.

The Smalltalk equivalent of Clojure is Ruby.

Could you elaborate on how you see Ruby as a modern Smalltalk?

Seriously?

Ruby block syntax is straight up lifted from Smalltalk, not to mention much of the semantics and standard library. Ruby seems like what Smalltalk would be if it was built as a scripting language with file-based structure... and then dragged through the mud of Perl syntax. ;-)

No need to be condescending, I was genuinely curious.

At first glance, the two languages seem similar, but not as much as Clojure is to CL (or any other lisp).

As a CL developer with only a bit of dabbling in Smalltalk and Ruby, Smalltalk and Ruby seem much more similar than CL and Clojure.

In particular, Clojure's preference for vectors over lists in many situations, combined with its much stronger preference for immutable objects makes it highly distinct from CL.

The requirement for explicit trampolines to allow efficient tail-calls makes it distinct from any (non-toy) lisp I've ever used.

It's hard to detect if a terse question is a request for information or a challenge. Back to the subject, Ruby's OO is much closer to Smalltalk's vision. Method dispatching in Java is essentially dereferencing a function pointer (found by traversing a class hierarchy) and adding a hidden argument (self.) In Ruby, you can override an object's method dispatching mechanism to be whatever you want it to be (although the default behavior is very similar to Java's.) This makes it a lot harder to optimize, (your JIT compiler can't simply inline those calls) but it opens all kinds of interesting meta-programming possibilities.

For anyone interested in the general topic of implementing a dynamic language on the jvm, Charles Nutter has a ton of good material around invoke dynamic and jruby.

Sorry, I wasn't intending to be condescending. I thought you were making a joke.

Ruby block syntax may have been inspired by Smalltalk, but this is where the similarities end. Ruby block implementation is simply awful (an afterthought?), and no way near as powerful (and simple) as the equivalent in Smalltalk.

> Ruby block syntax is straight up lifted from Smalltalk

Uh... no it's not, it's lifted from C/Perl with a smattering of Pascal.

> not to mention much of the semantics and standard library.

The semantics are as much Perl as they are Smalltalk, if not more so. And many pieces of Smalltalk are missing (first-class blocks to start with, Ruby's blocks are a hack)

Ruby steals the concept of 'everything is an object' from Smalltalk. Compare http://edwinmeyer.com/Release_Integrated_RHG_09_10_2008/chap... with http://en.wikipedia.org/wiki/Smalltalk#Object-oriented_progr....

Also I hear that JavaScript thing is catching on...

JavaScript is Lisp now?

It's pretty damn close. First class functions give javascript great power. Combined with something like sweet.js and underscore, and javascript becomes a language with the functional library of a lisp along with macros. After that, javascript is just lisp with really weird syntax.

Not to be snarky, but that's like saying 'Javascript is just a Lisp except without the only characteristic that defines a Lisp'.

All the dialects of Lisp differ except in their homoiconicity, which is the one thing that gives Lisps their incredible expressive power.

I get frustrated when I hear people refer to languages with first-class functions as Lisp-like, because lots of languages have first-class functions, but that doesn't give them the power of Lisp - Lisp draws its power from homoiconic structure, which almost no other languages have (certainly not Javascript).

Most of my comment comes from the fact that Eich originally wanted to build a homoiconic lisp for netscape and built many of the features into javascript instead. Still no a lisp ,but it was designed to be similar. http://www.2ality.com/2011/03/javascript-how-it-all-began.ht...

Crockford called it "Lisp in C's Clothing" and then created this: http://www.crockford.com/javascript/little.html

I like the comparisons with ClojureScript: http://himera.herokuapp.com/synonym.html The major thing that continues to really annoy me about JS is the lack of proper lexical scoping, other deficiencies are just slight annoyances now (especially with a couple libraries that help the language be tolerable in certain use cases--e.g. https://github.com/coolaj86/futures).

JS has no "proper lexical scoping"? How so? I'm really curious... what your definition of "proper" is here, because JS definitely has lexical scoping.

Paste this into your browser location bar (it won't navigate away):

    javascript:void(function(){a = 1; {var a = 2;} alert(a)}())

That var a doesn't declare a new var within its scope, it declares it in the function, plus it is counterintuitive how that var a "retroactively" makes that local scope. Javascript has lexical scoping, but only within functions, not within all the scopes other languages have.

You want block scoping. Block scoping is coming in ES6 with the let keyword.

Python is the same here, for example, any many other languages too. Making `a` a local variable here is rather ugly thing to do, but it's (somewhat) consistent with how `function` keyword (not an expression) works.

The point being: JS implements full and proper lexical scoping; implementing lexical scoping for every block is not a requirement for having lexical scoping.

> "Lisp in C's Clothing"

And Perl probably has an even greater claim to this because it shares 6 of the 7 What Makes Lisp Different? things described by Norvig.

And the ultimate situational irony being that it's built on the JVM, which was built for Java, which was built on all the great ideas of Smalltalk.

Well, some of them.

Reply on news.ycombinator.com