17 ms·

Redline Smalltalk V1.0

155 points by fredwu 14y ago

lampe 14y ago
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!
- skrebbel 14y ago
  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.
  - supar 14y ago
    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.
    - skrebbel 14y ago
      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.
  - pron 14y ago
    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.
- wr1472 14y ago
  "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?
  - TallGuyShort 14y ago
    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.
    - jbooth 14y ago
      "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.
      - deleted 14y ago
        [deleted]
- jerven 14y ago
  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!
- d4nt 14y ago
  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.
  - justinhj 14y ago
    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.
    - stcredzero 14y ago
      > The first couple of days with a language can be painful. It doesn't have to be: http://xkcd.com/353/ http://xkcd.com/353/
    - deleted 14y ago
      [deleted]
    - deleted 14y ago
      [deleted]
    - deleted 14y ago
      [deleted]
    - deleted 14y ago
      [deleted]
    - deleted 14y ago
      [deleted]
    - deleted 14y ago
      [deleted]
PommeDeTerre 14y ago
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?
- dysoco 14y ago
  Well, the same happened to LISP languages. They never seem to get a lot of traction... until Clojure appeared.
  - jerf 14y ago
    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".
    - deltasquared 14y ago
      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 http://clojure.org/special_forms#Special Forms--(recur exprs*)
praptak 14y ago
Why this and not Squeak/Pharo?
- rjzzleep 14y ago
  versioning, code collaboration, and as other people mentioned ecosystem off the top of my head.
  - nextputall 14y ago
    What's wrong with monticello? Ecosystem is a valid point, but I don't see problems with collaboration and versioning
    - spooneybarger 14y ago
      Especially with the work that has gone into have a git backend for Monticello.
      - rjzzleep 14y ago
        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.
        stcredzero 14y ago
        If anything, Monticello and many of the collaboration practices in Smalltalk were intellectual forerunners to git.
        rjzzleep 14y ago
pattynatty 14y ago
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?
- flyinRyan 14y ago
  As OO languages go, Smalltalk is very functional. The way Clojure works would be at least as natural in a Smalltalk language.
- fusiongyro 14y ago
  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.
- chimeracoder 14y ago
  > 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.
- shaunxcode 14y ago
  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.
pron 14y ago
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.
- smithbits 14y ago
  This isn't specific to Redline, but do take a look at the RoarVM http://soft.vub.ac.be/~smarr/renaissance/ 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/ http://amber-lang.net/ although I haven't had the nerve to actually deploy code to users written in Amber.
csmatt 14y ago
Why do you want/need money from me to create yet another programming language?
- mibbitier 14y ago
  Because there's a sucker born every minute.
- drivingmenuts 14y ago
  Because http://xkcd.com/927/ http://xkcd.com/927/ 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.
- vivin 14y ago
  Smalltalk isn't a new language. It has been around for decades. What he's doing is making the language run on the JVM.
t4nkd 14y ago
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.
- rjbond3rd 14y ago
  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).
  - t4nkd 14y ago
    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.
endlessvoid94 14y ago
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?
- spooneybarger 14y ago
  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. https://groups.google.com/forum/?fromgroups#!forum/redline-smalltalk https://groups.google.com/forum/?fromgroups#!forum/redline-s... sean@monkeysnatchbanana.com
  - endlessvoid94 14y ago
    Awesome, will do. Thanks for your response :-)
kephra 14y ago
I wonder, if this is just an other version of a little Smalltalk. For those who want Smalltalk in JVM, look at: http://web.engr.oregonstate.edu/~budd/SmallWorld/ReadMe.html http://web.engr.oregonstate.edu/~budd/SmallWorld/ReadMe.html
- spooneybarger 14y ago
  It's not. It's a new implementation that compiles from smalltalk source directly to jvm bytecode.
- TomMasz 14y ago
  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?
  - kephra 14y ago
    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.
mememememememe 14y ago
Can I be a little harsh? From a developer standpoint, why on earth do we need so many new languages? Learning a new language and waiting for it to improve is a nightmare already. When Go first came out, I was interested in it and I had to make my own modules (which was pretty fun to be honest). But because Go was developed by Google, the project can sustain itself for a very long period of time. I say we have more important things to do: we have many software with broken security. Let's focus on that. Let's improve existing languages' concurrency model. I am NOT trying to say this is useless, because I can't write it myself, but there are better things to do. Read about what Kenneth has to say about Python. We need people to contribute to Python ecosystem by abstracting commonly used libs into more humanane packages.
naner 14y ago
In a cursory glance it appears to be MIT licensed for anyone else who was curious: https://github.com/redline-smalltalk/redline-smalltalk 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).
- spooneybarger 14y ago
  It is indeed MIT licensed.
kabdib 14y ago
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?
- spooneybarger 14y ago
  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: http://www.youtube.com/watch?v=rX8OeNvgFcs&feature=youtu.be&a http://www.youtube.com/watch?v=rX8OeNvgFcs&feature=youtu...
  - kabdib 14y ago
    Excellent video, thank you. (SmallTalk is my favorite language that I'll never ship a product with :-/ )
    - spooneybarger 14y ago
      Dare to dream.
happywolf 14y ago
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.
doki_pen 14y ago
The logo is unfortunate. Looks like he's flipping everyone off.
- spooneybarger 14y ago
  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 http://www.redline.st/image/duke-large-404.png Gives me more impetus to come up with a better logo though.
- shaaaaawn 14y ago
  good catch
- spooneybarger 14y ago
  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.
shaunxcode 14y ago
Have been watching redline for a bit now, very promising. I would like to see what the plan for integration with Amber is.
- spooneybarger 14y ago
  we'd love to hear ideas. feel free to join the mailing list and give us your thoughts.
vivin 14y ago
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.
agumonkey 14y ago
Funny circling back since the first java IDE were interpreters written in visual age smalltalk (iirc).
- hboon 14y ago
  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.
  - agumonkey 14y ago
    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.
hboon 14y ago
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/ http://www.object-arts.com/
- spooneybarger 14y ago
  thank you for your support.
jamesladd 14y ago
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.
e12e 14y ago
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 http://medianetwork.oracle.com/video/player/1113248955001 http://medianetwork.oracle.com/video/player/1113248955001 JVM Language Summit, August 2012: RTALK - A Smalltalk 'Live' Environment Built on the JVM http://medianetwork.oracle.com/video/player/1785452097001 http://medianetwork.oracle.com/video/player/1785452097001
- jamesladd 14y ago
  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.
  - e12e 14y ago
    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?
    - spooneybarger 14y ago
      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.
marshray 14y ago
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?
- jamesladd 14y ago
  >>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.
- spooneybarger 14y ago
  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.
- cwp 14y ago
  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.
marshray 14y ago
Even the statement true become: false is valid in Smalltalk, although executing it is not recommended. https://en.wikipedia.org/wiki/Smalltalk https://en.wikipedia.org/wiki/Smalltalk
- spooneybarger 14y ago
  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.

155 points by fredwu 14y ago

lampe 14y ago

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!

skrebbel 14y ago
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.
- supar 14y ago
  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.
  - skrebbel 14y ago
    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.
- pron 14y ago
  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.
wr1472 14y ago
"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?
- TallGuyShort 14y ago
  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.
  - jbooth 14y ago
    "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.
    - deleted 14y ago
      [deleted]
jerven 14y ago
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!
d4nt 14y ago
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.
- justinhj 14y ago
  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.
  - stcredzero 14y ago
    > The first couple of days with a language can be painful. It doesn't have to be: http://xkcd.com/353/ http://xkcd.com/353/
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]

PommeDeTerre 14y ago

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?

dysoco 14y ago
Well, the same happened to LISP languages. They never seem to get a lot of traction... until Clojure appeared.
- jerf 14y ago
  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".
  - deltasquared 14y ago
    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 http://clojure.org/special_forms#Special Forms--(recur exprs*)

praptak 14y ago

Why this and not Squeak/Pharo?

rjzzleep 14y ago
versioning, code collaboration, and as other people mentioned ecosystem off the top of my head.
- nextputall 14y ago
  What's wrong with monticello? Ecosystem is a valid point, but I don't see problems with collaboration and versioning
  - spooneybarger 14y ago
    Especially with the work that has gone into have a git backend for Monticello.
    - rjzzleep 14y ago
      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.
      - stcredzero 14y ago
        If anything, Monticello and many of the collaboration practices in Smalltalk were intellectual forerunners to git.
        rjzzleep 14y ago

pattynatty 14y ago

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?

flyinRyan 14y ago
As OO languages go, Smalltalk is very functional. The way Clojure works would be at least as natural in a Smalltalk language.
fusiongyro 14y ago
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.
chimeracoder 14y ago
> 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.
shaunxcode 14y ago
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.

pron 14y ago

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.

smithbits 14y ago
This isn't specific to Redline, but do take a look at the RoarVM http://soft.vub.ac.be/~smarr/renaissance/ 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/ http://amber-lang.net/ although I haven't had the nerve to actually deploy code to users written in Amber.

csmatt 14y ago

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

mibbitier 14y ago
Because there's a sucker born every minute.
drivingmenuts 14y ago
Because http://xkcd.com/927/ http://xkcd.com/927/ 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.
vivin 14y ago
Smalltalk isn't a new language. It has been around for decades. What he's doing is making the language run on the JVM.

t4nkd 14y ago

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.

rjbond3rd 14y ago
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).
- t4nkd 14y ago
  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.

endlessvoid94 14y ago

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?

spooneybarger 14y ago
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. https://groups.google.com/forum/?fromgroups#!forum/redline-smalltalk https://groups.google.com/forum/?fromgroups#!forum/redline-s... sean@monkeysnatchbanana.com
- endlessvoid94 14y ago
  Awesome, will do. Thanks for your response :-)

kephra 14y ago

I wonder, if this is just an other version of a little Smalltalk. For those who want Smalltalk in JVM, look at: http://web.engr.oregonstate.edu/~budd/SmallWorld/ReadMe.html http://web.engr.oregonstate.edu/~budd/SmallWorld/ReadMe.html

spooneybarger 14y ago
It's not. It's a new implementation that compiles from smalltalk source directly to jvm bytecode.
TomMasz 14y ago
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?
- kephra 14y ago
  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.

mememememememe 14y ago

Can I be a little harsh? From a developer standpoint, why on earth do we need so many new languages? Learning a new language and waiting for it to improve is a nightmare already. When Go first came out, I was interested in it and I had to make my own modules (which was pretty fun to be honest). But because Go was developed by Google, the project can sustain itself for a very long period of time. I say we have more important things to do: we have many software with broken security. Let's focus on that. Let's improve existing languages' concurrency model. I am NOT trying to say this is useless, because I can't write it myself, but there are better things to do. Read about what Kenneth has to say about Python. We need people to contribute to Python ecosystem by abstracting commonly used libs into more humanane packages.

naner 14y ago

In a cursory glance it appears to be MIT licensed for anyone else who was curious: https://github.com/redline-smalltalk/redline-smalltalk 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).

spooneybarger 14y ago
It is indeed MIT licensed.

kabdib 14y ago

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?

spooneybarger 14y ago
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: http://www.youtube.com/watch?v=rX8OeNvgFcs&feature=youtu.be&a http://www.youtube.com/watch?v=rX8OeNvgFcs&feature=youtu...
- kabdib 14y ago
  Excellent video, thank you. (SmallTalk is my favorite language that I'll never ship a product with :-/ )
  - spooneybarger 14y ago
    Dare to dream.

happywolf 14y ago

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.

doki_pen 14y ago

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

spooneybarger 14y ago
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 http://www.redline.st/image/duke-large-404.png Gives me more impetus to come up with a better logo though.
shaaaaawn 14y ago
good catch
spooneybarger 14y ago
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.

shaunxcode 14y ago

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

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

vivin 14y ago

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.

agumonkey 14y ago

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

hboon 14y ago
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.
- agumonkey 14y ago
  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.

hboon 14y ago

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/ http://www.object-arts.com/

spooneybarger 14y ago
thank you for your support.

jamesladd 14y ago

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.

e12e 14y ago

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 http://medianetwork.oracle.com/video/player/1113248955001 http://medianetwork.oracle.com/video/player/1113248955001 JVM Language Summit, August 2012: RTALK - A Smalltalk 'Live' Environment Built on the JVM http://medianetwork.oracle.com/video/player/1785452097001 http://medianetwork.oracle.com/video/player/1785452097001

jamesladd 14y ago
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.
- e12e 14y ago
  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?
  - spooneybarger 14y ago
    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.

marshray 14y ago

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?

jamesladd 14y ago
>>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.
spooneybarger 14y ago
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.
cwp 14y ago
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.

marshray 14y ago

Even the statement true become: false is valid in Smalltalk, although executing it is not recommended. https://en.wikipedia.org/wiki/Smalltalk https://en.wikipedia.org/wiki/Smalltalk

spooneybarger 14y ago
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.