

What Arc should learn from Ruby - acangiano
http://antoniocangiano.com/2008/10/26/what-arc-should-learn-from-ruby/

======
jwilliams
I'm not sure a lot is gained from this comparison (caveat: I've used neither
language in anger).

PG states that Arc is intended as a 100-year language, so getting your core
axioms and constructs right is pretty key. This kind of approach has a higher
activation energy, but momentum can continually build.

The philosophy for Ruby is getting things done _now_ , although arguably it
gained a lot from it's time in the Japanese niche. It's a fantastically
productive language and favoured by a lot of productive "lets get it done"
people (not to say Arc isn't...). This philosophy accelerates quickly, but
tends to eventually hit conceptual limits. In my view this happened with Java
- but this doesn't mean it's a bad thing.

I'm struggling with some of the same problems (in microcosm, maybe nanocosm in
comparison). For example, if you build an exception mechanism - do you make it
an ultimately flexible signal system, or do you constrain it to certain norms?

The latter favours rapid growth as all your libraries have consistent
exception mechanisms. I can build a library and integrate it easily with
another library. The same applies for a whole bunch of other constructs, such
as network models, concurrency, etc, etc. So what you have done is constrain X
to allow growth in Y... (A lot of what a language is about is what it
_doesn't_ let you do, rather than what it allows).

The former may result in some nasty mutations in the short-term - For example,
libraries that aren't interoperable because they have different exception
mechanisms. However, if you are taking a long term evolutionary view then this
approach may yield a much more innovative, stable mechanism in the long term.

So really, they are just two different philosophies with different start and
end points - that's how I read pg's quotes also.

~~~
jacobscott
Does a hundred year programming language make sense at all? Is it possible to
have the faintest clue what people will want to be programming then? Feel free
to point me to prior responses :)

~~~
jwilliams
For the background, take a look at: <http://www.paulgraham.com/hundred.html>

------
pg
He makes it seem as if I said libraries are a bad thing. To do that he
conveniently truncates the quote just before

    
    
      I'm not saying that languages *shouldn't* have 
      powerful libraries, btw, just that they may not 
      be 100% upside.
    

If he'd included that, it would have been clear to everyone that there was no
counter in this counterpoint.

~~~
acangiano
I edited the post to include the whole quote.

------
maxwell
I was hoping from the title that this would be an article about language
features, instead it's more like "what Kubrick should have learned from
Spielberg (in terms of box office success)"

I don't write Ruby personally; are there actual features (as opposed to ways
of generating ephemeral hype) that could make Arc better?

------
Taifu
Wow! Great reading!

