
Redline Smalltalk V1.0 - fredwu
http://www.indiegogo.com/smalltalk?a=1793720
======
PommeDeTerre
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?

~~~
spooneybarger
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.

~~~
fusiongyro
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.

~~~
hboon
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.

~~~
fusiongyro
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.

------
hboon
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/>

~~~
spooneybarger
thank you for your support.

------
pattynatty
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?

~~~
shaunxcode
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.

~~~
chimeracoder
> 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.

------
pron
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
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.

------
t4nkd
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
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
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.

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

<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
It is indeed MIT licensed.

------
endlessvoid94
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
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-s...](https://groups.google.com/forum/?fromgroups#!forum/redline-
smalltalk)

sean@monkeysnatchbanana.com

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

------
lampe
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!

~~~
d4nt
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
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.

~~~
chimeracoder
> 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.

------
marshray
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?

~~~
spooneybarger
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.

------
kabdib
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
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...](http://www.youtube.com/watch?v=rX8OeNvgFcs&feature=youtu.be&a)

~~~
kabdib
Excellent video, thank you.

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

~~~
spooneybarger
Dare to dream.

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

~~~
TomMasz
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
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.

------
jamesladd
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.

------
praptak
Why this and not Squeak/Pharo?

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

~~~
flyinRyan
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.

~~~
rjzzleep
i think you might be referring to this:

[http://www.esug.org/wiki/pier/Conferences/2010/Talks/Montice...](http://www.esug.org/wiki/pier/Conferences/2010/Talks/Monticello)

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

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

~~~
hboon
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
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.

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

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

<http://medianetwork.oracle.com/video/player/1785452097001>

~~~
jamesladd
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
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
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.

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

~~~
drivingmenuts
Because

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

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

~~~
spooneybarger
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.

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

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

------
happywolf
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.

------
marshray
_Even the statement_

    
    
         true become: false
    

_is valid in Smalltalk, although executing it is not recommended._

<https://en.wikipedia.org/wiki/Smalltalk>

~~~
spooneybarger
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.

------
vivin
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.

