Hacker News new | past | comments | ask | show | jobs | submit login
Redline Smalltalk V1.0 (indiegogo.com)
155 points by fredwu on Nov 26, 2012 | hide | past | web | favorite | 139 comments

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:


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?


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.

I'm backing this.

For those who say that no Smalltalk implementation has ever embraced the native OS and always sought to replace it, check out Dolphin Smalltalk [1]. It might be a little outdated now. I haven't kept up with it, but it was (is?) built by a 2-man company and at one time almost closed it down due to poor sales. But before .NET, it had even better support than Visual Studio for COM development and debugging, as well as integrated natively with Windows control in a nice framework.

If you have a copy of Windows around, you really owe it to yourself to spend an hour or two, to download and play around with the evaluation version.

[1] http://www.object-arts.com/

thank you for your support.

Have we not realised that the future of programming languages is likely to be increasingly functional?

What does SmallTalk do to restrict side effects, to support emerging NUMA architectures, lack of cache coherency, parallelism etc that we are looking at working with more and more at all levels?

> Have we not realised that the future of programming languages is likely to be increasingly functional?

Next to the Lisp dialects (and perhaps Haskell), Smalltalk is by far the most transparently functional language I can think of.

Smalltalk is really easy to pick up if you're familiar with the lambda calculus (whether in theory, or via a Lisp or Haskell). Just think: object <-> closure/higher-order function; messages <-> functions; chaining messages <-> currying functions.

The wrapping/syntactic sugar around the functional counterparts in Smalltalk is pretty transparent, by design.

EDIT To expand on that, Alan Kay (the "inventor" of object-oriented programming) has said that Smalltalk is one of the only two truly object-oriented languages that he's ever seen.

The other? Scheme (a Lisp)! So just because Smalltalk is "purely OO" doesn't mean it can't be as functional as a Lisp at the same time.

As OO languages go, Smalltalk is very functional. The way Clojure works would be at least as natural in a Smalltalk language.

It's Smalltalk, not SmallTalk.

I would hate to live in a world in which people do functional programming because they heard on a forum somewhere that it is the future, rather than because they understand the benefits and tradeoffs and have chosen functional programming intentionally. The problems you're describing aren't universally relevant.

I strongly doubt that the big programming languages of the future are going to be as homogeneous as the big languages of the past.

One of my pet thought projects is actually to imagine what an immutable smalltalk look like. It seems to me that a simple DSL to provide a smalltalk veneer on top of clojure/datomic is worth exploring.. but I've already said too much.

> One of my pet thought projects is actually to imagine what an immutable smalltalk look like.

Honestly, Haskell as it stands comes pretty close.

I assume you're talking about pure immutability (for which Haskell is famous), and Smalltalk's message-passing is really just a way of currying functions (with a slightly different syntax).

You could probably stitch something simple together with Haskell + Parsec fairly easily.

I think that any new programming language must specifically address at least some of the modern software development challenges. For client-side languages those will be browser and mobile-device deployment, and for server-side languages (and, actually, for client-side as well) it's concurrency.

A possible marginal improvement in productivity just won't cut it. We need languages like Clojure and Erlang that help developers write software for the modern age.

This isn't specific to Redline, but do take a look at the RoarVM http://soft.vub.ac.be/~smarr/renaissance/ a many core research implementation of the Smalltalk VM that does some very interesting things with non-determinism. Also there are Javascript implementations of Smalltalk that run inside browsers like http://amber-lang.net/ although I haven't had the nerve to actually deploy code to users written in Amber.

Am I the only one who's a little skeptical of this guys plan? Looking at this from an objective standpoint, and losing focus on the idea that Smalltalk is a great language that deserves this chance, the focus of this funding is being put on an individual who requires $20,000 for 4-6 months of work? Where do you factor in 2 months of wiggle time with a budget that low? Didn't he run the numbers? I have to imagine he took a look at his month to month expenses, subtracted luxuries, kept some "just in case I need a hospital visit" money? It seems like a 30 year dev would have a little money in the bank to keep himself working on /whatever/ passion he desires for at least 4-6 months?

I just think the whole financial aspect of this is fishy. And presuming that he raises enough money to get this project to the public, what if there's another 3 months of work before we can all really use it because of some oversight? Does the community need to kick him another $10,000?

His development architecture seems relatively sound from the 90,000ft. view, but there's not enough detail here to make me think he can actually pull off a 6 month development cycle of a new JVM based Smalltalk language. I don't really see any evidence apart from being a smart guy and passionate tinkerer that he could take a project to a community, maintain and grow it collaboratively, then end up with something thoughtful and elegant. While I wish this project all the best, he's done a very poor job of convincing me to give him money and I don't think that's just my obstinate view of failed crowd-funded development projects talking.

I had the opposite take. It seems to me he's modeling his approach on Perl Foundation grants, which pay hackers for part-time or full-time work for a specific set of deliverables.

These grants are generally deemed successful in terms of delivery (in part because they go to highly experienced developers who have already been contributing for years).

Maybe I misunderstand the Perl Foundation grants model, but, isn't a great deal of that success due to the highly experienced developers who have already been contributing for years? Would the same success apply when the codebase in question has had little or no iteration?

Not to mention that TPF is a group of many committees who report to an entire board?

If there was mention of a governing board of developers who want to establish committees for developing the language further, I think that'd be a much more sensible and focused use of the funds. My perspective of his proposal was basically, "Pay a minimum rate for my time over the next 4-6 months and see where I can take this language". Something that leaves me even more uneasy is his ability to communicate the finer points of where this funding might be directed, or what the promise for delivery actually is. I have to believe there is some kind of metric for his progress thus far and his projections for progress moving forward; anything less is bush league panhandling for a hobby passion.

Just my two cents, obviously, and no offensive to the aims of the project author, which I actually think are interesting and probably worthwhile; but interesting and worthwhile are not cause for donation.

>>there's not enough detail here to make me think he can actually pull off a 6 month development cycle of a new JVM based Smalltalk language

Redline Smalltalk runs today and compiles Smalltalk source into bytecode in Java Class format. The funding is to flesh out the runtime classes and tooling.

>>he's done a very poor job of convincing me to give him money I appreciate this feedback. Could you elaborate on what sort of things would convince you?

- James.

>> Could you elaborate on what sort of things would convince you?

What the money would actually be used for, which you just shed some more light on. It was really vague exactly which aspect(s) of the development the funds would be focused on, aside from "bringing the project to release", and you didn't really clarify how that's qualified. It's a highly technical project, I'd expect a little bit more meat.

Overall, I felt like there was some detail lacking with regard to the "how" of you getting to the goal. In theory, every funded development plan has some form of timeline(schedule/plan) and milestones, hopefully with some really vague dates or estimates. I just wasn't persuaded you had planned that far ahead yet. The project, based purely on the Indiegogo page, seemed to still be a hobby project that you enjoyed playing with. I simply can't justify adding to a $20,000 development fund based on the concept that you'll continue to flesh things out as you go along.

I haven't seen a serious track record of highly adopted open source projects from you(if I was looking in the wrong places or mistaken about the popularity of some of your projects, please correct me) and that doesn't persuade me to take you at your word. I'd need some meat in terms of what I'm actually funding and not what you hope to build. I can't in good conscience fund a project based on the end result or deliverable, I have to fund your process, planning ability, architectural consideration and senior experience; I could really only trust the last point, and not as much as I would have liked to.

I still appreciate what you're aiming to do, and that you've put so much energy into the concept already, but I don't appreciate it enough to contribute dollars. If you were looking for donations to continue to evolve the project after release and there was a community behind it saying good things, I'd be inclined to take the "end goal" as enough explanation and review the history of how things have evolved to see if I think you're reliable enough to fund. In this case, you want money to deliver an initial release, and I'm going to need to know how you want to get there.

In a cursory glance it appears to be MIT licensed for anyone else who was curious:


I imagine I'm not the one who generally is unwilling to pay for development tools or languages that are closed source unless they are directly relevant to my job (of course, then my employer would be paying for them) or backed by a robust company (e.g. JetBrains).

It is indeed MIT licensed.

One of the biggest advantages, I thought, was the Smalltalk programming environment. Obliterating the notion of dealing with files, and interacting directly with definitions and objects. If I use the same tools today, but just with a different language, what benefit am I getting?

On a side note, I actually have been working on something like the smalltalk environment for another popular language. I'd love to know more about how Redline deals with images (if at all) -- that is, does it snapshot memory and dump it to a file like the original smalltalk? Or is this a JVM compiler for the smalltalk language?

It is a compiler right now. It is file based like GNU Smalltalk. We are still working out how to bring in image based development (as an option, not a requirement).

We are working on integrating with existing tools but having the resumable exceptions that you get a 'standard' smalltalk environment. The ability to poke and prod the objects, inspect them, change them etc. The basis for it all is there, now it is about exposing it first through existing tools like eclipse and intellij and hopefully, eventually, other tools as well.

This could lead to a rather long conversation for which HN isn't the best platform, feel free to email the mailing list or me directly if you want to discuss more in depth.



Awesome, will do. Thanks for your response :-)

i stopped reading when i saw "JVM".

i really dont get it why this is so popular... maybe it makes your code faster yes but it comes with all the cluter that is the JVM.

The JVM is a big black box and I think its veryhard to see whats happening inside.

have someone tried to write a patch for the JVM? no? then try!

Integration, ecosystem, exit strategy.

Integration so that you can easily integrate new Smalltalk code (in this case) with existing JVM code that your organisation/product might have.

Ecosystem because you don't need to kickstart a massive community of developers, open source libraries, a standard library, and so on, to have a useful language. Basically, by making a language that targets an existing platform (such as the JVM, CLR or JavaScript), you're "batteries included" from the very start. Better yet, the batteries will be familiar to shares of developers. This is major. Ever wondered why Lisp was only used by a couple of men with beards (and pg) until Clojure? I can promise you, it wasn't the square brackets.

Exit strategy because you want to be able to get out as easily as you got in. If you build non-hobby software with Redline Smalltalk, and for whatever reason the whole thing blows up in your face (e.g. big performance or security problems, project ends up unmaintained with large nuisances, and so on), you can migrate code to another JVM language bit by bit.

True, and I would also add the best performance of any managed runtime and the best profiling of any runtime.

Unless your language's main features coincide with the very specific pain points poorly addressed by the JVM (like struct arrays or mobile-phone deployment), I'll say that the JVM is the default target choice. It is any other choice that will need to be justified.

I could say exactly the same for any source-to-C compiler, and/or any system allowing decent FFI with C. Unless there is some different reason than the JVM itself, C has an even larger code base.

In a way, C can be considered an "existing platform" in much the same sense. I didn't include it in my list of examples because I really don't want to have to fight build tooling and cross-platform dependency hell in 2012 if I don't absolutely have to. With e.g. the JVM, you can get a jar from somewhere (or maven it in), and -poof- it just works, everywhere. This is a major advantage to the whole "ecosystem" point.

I understand why people choose the JVM, I'm sure it gets people up and running very quickly, and maybe if you're an enterprise java programmer then getting set up on the latest cool JVM based language is quite easy. But speaking as a Python/JS/.Net guy who once spent a few evenings trying to build something in Scala, the JVM just seems so painful to use.

I lost hours trying to set up Maven to download one library and build my project. All the documentation pages seemed to point to other documentation pages. I ended up trying to download about 30 jars manually, but the versions seemed to clash. I am convinced that the best thing a programming language can to do improve adoption is not to create a JVM version, but to create a package management system like pip/npm/NuGet.

In all fairness, it does come across as "well thought out" and "solid"; similar to the way that Java comes across as well thought out and solid. I can tell it does a lot but I have to be completely initiated into the JVM way of thinking before I can get anything done. The quickstart page has some 6000 words, which describes how to set up an XML file containing all sorts of stuff. I'm introduced to things like a standard directory structure, Archetypes, CLASSPATHs and Project Object Models. All because I finished the Scala tutorial and then tried to use a library that wasn't installed on my machine already.

With Python, in the past things were a little trickier with easy install, but these days the library's web page would probably have told me to type:

    pip install third_party_library
And that's about it. Even if you haven't got Pip it's quite obvious what to do, the terminal tells you it doesn't know what pip is, so you Google "install pip Windows/Mac/..." and pretty soon you're up and running.

The first couple of days with a language can be painful. People have trouble getting python libraries to work too. Maven is really quite well thought out and solid.

> People have trouble getting python libraries to work too

Aside from developing on Windows with C extension libraries, those are increasingly rare. Pip + virtualenv works wonders, and the latter has been folded into the most recent official release of CPython (3.3), so it's now officially the right way to do Python package management, as opposed to simply the de facto approach.

As someone who's had to use both, I will say that my experience with even the most basic, functionality in Java's package management is a nightmare, whereas learning how to use the same basic functionality in pip/virtualenv was so easy, I wondered why I'd been putting it off so long.

> The first couple of days with a language can be painful.

It doesn't have to be:


> I lost hours trying to set up Maven to download one library and build my project.

You should check out Apache Buildr (http://buildr.apache.org/). It gives you the power of Maven repos with a Ruby "front end". And, yes, I know it's imperative and not declarative but I find that the build files tend to be small and understandable.

I know it's not considered a good thing to do, but I also have problems with Maven, mostly because I so seldom use Java.

But I found JarFinder in IntelliJ to be a good replacement for many needs. You just start using a class and it suggests a couple of jar's to download and reference. :)

> pip/npm/NuGet

Well actually all of those you mentioned are awful compared to Maven ;-)

Have you tried writing a patch for one of the large C compilers? and getting it into mainline? not trivial either.

For the JVM there are choices. IBM, Azul, Oracle, OpenJDK and many other more academic ones. With different tradeoffs and costs. I have switched massive code bases from one to the other with minimal effort.

Switching C compiler is more invasive than switching JVM providers. And many other languages only have a single sanctioned runtime.

Sure the JVM eco system is far from perfect. But it is dependable!

   "The JVM is a big black box and I think its veryhard to see whats happening inside."
Good software engineering is very much about standing on the shoulders of giants.

   "have someone tried to write a patch for the JVM? no? then try!"
How often do people need to do this in everyday development on the JVM?

Any language that someone is arguing should be "the next big language" should take things other than everyday development on the JVM. Nevertheless, wanting to be able to patch the JVM has been a part of my "everday development" several times.

"everyday development"? Really? Could you explain which behavior needed patching? Garbage collection, I'm guessing?

I'm not saying the JVM is perfect but I'm inclined to think that if the JVM is causing you problems, you already had them in your architecture.

One thing that held me back from Smalltalk is something I heard once that the 'system image' (or whatever its proper name is) had become something of a binary blob, no longer bootstrappable from the original sources. This sounded like a version control nightmare to me.

I assume this is no longer the case with this project?

I can't speak to all Smalltalks, but I know that isn't the case with Pharo. GNU Smalltalk can construct an image from source. Redline doesn't yet have an image, we are still working out how that would work with our play nice in the jvm ecosystem ideals.

What it means to have 'original sources' though is a rather long and complicated historical answer. There have been a couple of good Smalltalk version control systems ( Envy & Monticello come to mind ).

I don't want to go into a long explanation of what the image is and the various ways different people use it, so I'll just leave it at.

All smalltalks support some form of version control ( some svn like, some dvcs like, some git, etc etc ). Redline isn't tied to an image and we don't intend to make it a requirement to use.

This is the single most significant difference between Smalltalk and other languages. Several Smalltalk dialects use images that were last bootstrapped from scratch sometime in the late 70s. If you insist on using git for version control, yes, this is a nightmare. On the other hand, there are several high-quality version control tools for Smalltalk, and in practice, it's not a problem.

It is pretty weird for nubies, though.

>>I assume this is no longer the case with this project? Correct. Redline Smalltalk does not require an image file. Your source is kept in files just like you would Python or Ruby source. - James.

I thought that a lot of Smalltalk's power was in the mutability of its objects, notably the debugger and "become:" features. Does the JVM really support that?

while there are some tricky parts, we haven't run into anything where the jvm prevents us from doing anything that is smalltalk.

the magic of the smalltalk debugger is largely based on 'thisContext' which reifies the stack into a first class object; implementing thisContext was trivial. we have more work to do around exposing that to debuggers but don't forsee any huge issue.

james did a short, 30 minute presentation at ESUG in 2011 about implementing Smalltalk on the JVM that might answer some questions:


Excellent video, thank you.

(SmallTalk is my favorite language that I'll never ship a product with :-/ )

Dare to dream.

I wonder, if this is just an other version of a little Smalltalk. For those who want Smalltalk in JVM, look at:


Interesting. I did my CS Master's work on Little Smalltalk, adding a debugger and documentation mostly because it didn't seem like Budd was doing much with it anymore (this was early 90s). Is SmallWorld more feature-complete than Little Smalltalk?

Unfortunately Budd started a new a little Smalltalk at least 5 times. None of them are for production use, but only to look, how a Smalltalk could be implemented.

It's not. It's a new implementation that compiles from smalltalk source directly to jvm bytecode.

Thank you everyone for contributing these comments.

Quote> If the Smalltalk community wants to remain small, insular and essentially irrelevant .... 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. <Quote

Well said. I DON'T want Smalltalk to be irrelevant and breaking out of the image and working with 'your' tool chain and being free is how Redline is taking stock of the rest of the world. You won't find us insulting other languages.

Please give Smalltalk a try, it is a fun language to develop in and the barriers to getting started are being smashed by Redline.

- James.

Why this and not Squeak/Pharo?

because we believe that being on jvm will be smalltalk to a wider audience and over time we can leverage the concurrency libraries, profiling libraries etc etc etc that the jvm has to offer and build a smalltalk for the future.

we share the same goals as pharo, just a different idea of how to get there.

Makes sense. Have you considered porting Squeak itself to JVM? This would get the JVM benefits, and the similar "take advantage of existing stuff" from the Smalltalk side.

Just to be clear: I'm not in any way invested in Squeak or Pharo, just curious about your approach. Well, this and also perhaps a bit skeptical about implementing new stuff when similar stuff exists.

I wrote tool that can export classes from pharo/squeak in the syntax that redline expects. My original idea with this was to aid people who want to develop in Pharo and deploy to redline. In order to make that happen, there would have to be a lot more work done.

There have been several discussions about using that tool to export large chunks of pharo and using that as the basis for the redline class library. I personally have tended to resist that (and swayed many people) because it brings along with it a ton of cruft. That said, we all have full time jobs and I'm starting to think that it would be better to start with cruft and remove rather than starting clean and build up. Which side of that I fall on, really varies from day to day. I'm thinking of taking a chunk of pharo and seeing how hard an export of modify would be vs. doing the implementation from scratch.


Well, Dan Ingalls did something a like that. He implemented a Squeak VM in Java. It's six years old, and even then it didn't run a current Squeak image, but it works pretty well.

Announcement here:


JAR file here:


Thanks for this. I didn't know that existed.

versioning, code collaboration, and as other people mentioned ecosystem off the top of my head.

Versioning actually tends to work better in Pharo/Squeak because once you have a version system dedicated to one language you're free to go ahead and understand the syntax of that language. I'm not sure how much of that they take advantage of today but there was talk several years ago of doing things like this.

i think you might be referring to this:


i haven't really watched monticello 2, but last I remember you're essentially merging packages in and out of your vm.

it really depends on what your goals are, and I guess the old discussion of visual and non visual programming also applies a little bit to the vm, non vm smalltalk discussion.

personally i like to avoid magic whenever i can

What's wrong with monticello? Ecosystem is a valid point, but I don't see problems with collaboration and versioning

Especially with the work that has gone into have a git backend for Monticello.

well as i mentioned above the whole idea behind monticello goes hand in hand with the idea of having to program a/in a vm. you may like the vm/object structure more than a file based structure, but ymmv.

not to mention that when we were evaluating squeak a year or so back git was nothing more than a half assed gsoc project.

but even so, the fact that you can pipe anything into git one way or another doesn't change the fact that they are conceptually different, but if it does, feel free to correct me.

If anything, Monticello and many of the collaboration practices in Smalltalk were intellectual forerunners to git.

I thought the frontrunner to git was bitkeeper, which as all the other versioning systems grew out of the experiences from DVS, which i guess refers to what you said, but bitkeeper was built long before monticello.

how does git backend for monticello work? does it turn objects into text so they can be versioned in git? if so that's exactly what dvs was doing for cvs.

Perhaps you are confusing vm and image?

Funny circling back since the first java IDE were interpreters written in visual age smalltalk (iirc).

VisualAge for Smalltalk was pretty impressive. A little nugget of history: IBM's VisualAge for Java was based on VisualAge for Smalltalk — which was acquired along with OTI — and ran a Smalltalk VM that ran both Smalltalk code and Java bytecodes. It carried over the whole paradigm from VAS, you had the code browsers, etc, as well as the very powerful GUI builder that VAS had. A pity the product never caught on.

They rebuild the product in Java, which later morphed into Eclipse, which despite all its plugins never provided the productivity boost that VAS (or even VAJ) provided.

Yeah I've read that a Eclipse was much of a regression when it appeared. Never used it but it seems that VA looked like a prowess. Ahh, modern times.

  -- sent from my emacs client.

Apparently there already is a Smalltalk for the jvm, but it is closed and used internally by Roose Instruments Inc. It's called rtalk - but as far as I can figure out there is no other relation to redline smalltalk.

Very interesting talk on the implementation details:

JVM Language Summit, July 2011: Rtalk - Smalltalk on the JVM


JVM Language Summit, August 2012: RTALK - A Smalltalk 'Live' Environment Built on the JVM


I investigated RTalk with interest and exchanged a few emails with Mark Roos. RTalk is nice but has a different goal.

Redline wants to support you and your existing tool chains, editors and environments that exist around the JVM. We want the best of Smalltalk in that environment (Redline), not a Smalltalk environment (RTalk) on the JVM. A subtle but important difference.

- James.

I'm not sure I see how Smalltalk would be very useful without a complete environment? Are you just implementing a Smalltalk(syntax) to bytecode/jar compiler? No support for dynamic execution/compiling code in any text-form? No adding behaviour to gui-object? No highly iterative development?

We are doing almost all of that.

You can already do dynamic execution and compilation. We just need hooks into ides like eclipse etc.

We have no near term plans to do anything GUI wise initially. But we would very much welcome someone taking that on.

The iterative development will be there. We support 'thisContext' which makes supplying a smalltalk style debugger with resumable exceptions, debugger driven development etc possible. It is just a matter of hooking into existing ones and working out any kinks.

We are not trying to be able to boot a full pharo environment while running on the jvm. version 1 roadmap is for integration with tools that already exist in the jvm ecosystem. if others want to run ahead and work on other environments ( including brand new ones ), we will lend a hand where we can.

Hopefully this answers your questions, if not feel free to join the mailing list and ask away in terms of questions. Or email me personally if you want, sean@monkeysnatchbanana.com And even if this does answer your questions, feel free to fire away with new ones on the mailing list or to me.

Apparently rtalk will be/is under a MIT licence too -- but so far the only code is for the jvm-side, buried at:


Why do you want/need money from me to create yet another programming language?



One of the greatest things about computing is that everyone has a chance to prove that their idea is better than everyone else. One of the worst things about computing is that everyone thinks their idea is better than everyone else's.

Smalltalk isn't a new language. It has been around for decades. What he's doing is making the language run on the JVM.

Because there's a sucker born every minute.

The logo is unfortunate. Looks like he's flipping everyone off.

I'd never noticed that it looked like that at a smaller size.

As you can see; he isn't: http://www.redline.st/image/duke-large-404.png

Gives me more impetus to come up with a better logo though.

i just changed the logo on the campaign for the small size so it isnt quite so unfortunate. it isn't the great image ever but, there ya go.

good catch

Have been watching redline for a bit now, very promising. I would like to see what the plan for integration with Amber is.

we'd love to hear ideas. feel free to join the mailing list and give us your thoughts.

Nowadays I prefer to wait until a language is more widely used before I will spend more time on it. The most recent language that caught my eyes is Go. Although I may not agree with some of the trade-offs and design decisions, this language is well-thought of and tries to solve real-world problems.

Even the statement

     true become: false
is valid in Smalltalk, although executing it is not recommended.


so in most smalltalk representations, true and false are implemented as primitives so that wouldn't actually do anything but in theory, yes, you can turn true into false and variety of other things.

as an aside, people who don't use smalltalk are often drawn to the 'become' functionality which is almost never seen in the wild.

Pretty neat. I've been wanting to do something like this on my own for a while, but never got around to it. I had to write a few Smalltalk programs for a class and immediately fell in love with the language.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact