Redline Smalltalk V1.0
indiegogo.com
indiegogo.com
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?
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.
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.
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.
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.
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.
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.
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
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)
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".
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. ;-)
At first glance, the two languages seem similar, but not as much as Clojure is to CL (or any other lisp).
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.
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)
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).
javascript:void(function(){a = 1; {var a = 2;} alert(a)}())
The point being: JS implements full and proper lexical scoping; implementing lexical scoping for every block is not a requirement for having lexical scoping.
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.
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.
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?
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.
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.
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.
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.
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.
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).
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.
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.
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.
https://github.com/redline-smalltalk/redline-smalltalk
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).
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?
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.
https://groups.google.com/forum/?fromgroups#!forum/redline-s...
sean@monkeysnatchbanana.com
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 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.
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.
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!
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.
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
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.
It doesn't have to be:
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.
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. :)
Well actually all of those you mentioned are awful compared to Maven ;-)
"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!"
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.
I assume this is no longer the case with this project?
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.
It is pretty weird for nubies, though.
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:
(SmallTalk is my favorite language that I'll never ship a product with :-/ )
http://web.engr.oregonstate.edu/~budd/SmallWorld/ReadMe.html
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.
we share the same goals as pharo, just a different idea of how to get there.
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.
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.
https://github.com/redline-smalltalk/redline-smalltalk/tree/...
Announcement here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-...
JAR file here:
http://www.esug.org/wiki/pier/Conferences/2010/Talks/Montice...
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
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.
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.
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.
-- sent from my emacs client.Very interesting talk on the implementation details:
JVM Language Summit, July 2011: Rtalk - Smalltalk on the JVM
http://medianetwork.oracle.com/video/player/1113248955001
JVM Language Summit, August 2012: RTALK - A Smalltalk 'Live' Environment Built on the JVM
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.
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.
http://wiki.jvmlangsummit.com/Building_a_Dynamic_Language_on...
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.
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.
true become: false
as an aside, people who don't use smalltalk are often drawn to the 'become' functionality which is almost never seen in the wild.