
Ruby Is Defined by Terrible Tools - davidcelis
http://devblog.avdi.org/2015/07/08/ruby-is-defined-by-terrible-tools/
======
saosebastiao
I tend to think that the sophistication of the tools reflect the extent that
the language is broken. Valgrind doesn't need to exist for the Java user. You
don't need class boilerplate getter/setter generators for Scala. Nobody needs
NPE static analyzers for Rust. The need for rename refactoring tools is
drastically diminished by the existence of type inference, almost to the point
where `:%s/Foo/Bar/g` is entirely adequate.

The non-existence of tools that you find in other languages _might_ signal an
immature ecosystem, but it might also signal a diminished need for them.

~~~
rictic
It's been a while since I wrote much Ruby, but I can vividly recall wanting to
find the definition of a method and being frustrated at how difficult it often
was.

~~~
dragonwriter
> It's been a while since I wrote much Ruby, but I can vividly recall wanting
> to find the definition of a method and being frustrated at how difficult it
> often was.

Given Ruby's open classes and per-object metaclasses (which are _still_ open),
I'm pretty sure a general solution to "find the definition of the method being
called at this point in the code" is impossible (and not just, "there is a
single correct answer, no general solution is available" impossible, but
"there is no guarantee that there is a single correct answer, and even for the
subset of cases where there is, no general solution is available" possible.)

~~~
pjmlp
Ever used Smalltalk, Dylan or Common Lisp commercial tools?

~~~
hire_charts
Personally, I haven't -- is there a way that the benefits of these tools could
be translated into a ruby-based environment? Are such solutions already
available? Would be interested to know more.

~~~
pjmlp
Then this might interest you:

[http://devblog.avdi.org/2015/05/11/in-which-i-make-you-
hate-...](http://devblog.avdi.org/2015/05/11/in-which-i-make-you-hate-ruby-
in-7-minutes/)

------
kazinator
> _And yet, in the early 2000s, long before Rails drove throngs of people to
> learn Ruby, very smart people who knew about Lisp and Haskell and good
> tooling, fell in love with Ruby. People like Dave Thomas and Martin Fowler
> and Jim Weirich._

This is probably because very smart people don't need tools, so they can let
themselves fall for the appearance of raw textbook examples of the source
code.

Very smart people probably have written programs in low-level languages and
gotten them right with only the help of print traces, and raw stack/register
dumps.

~~~
marssaxman
I have no idea whether it correlates with "very smart" in any particular way,
and suspect that it probably doesn't, but I have definitely observed
significant differences in preference when it comes to the use of
extralinguistic tools. It's easy to see how there are some people better
suited to early adoption of new languages than others, because they are
comfortable with and may actually prefer a minimal-tooling environment, while
others will find it so unbearably primitive that they won't be able to get
anything done.

I've had coworkers who believed anything that can be automated should be, and
therefore one should learn and use all available tools. In this view, anyone
failing to take advantage of all possible automation is wasting their time on
grunt work and therefore being less productive than they could. One guy at my
last job was notorious for his incredibly long and frequently misspelled
identifiers; I could not understand _how_ he was failing to notice these
problems until I realized that he literally never typed out a full identifier
more than once, and typically generated as many bytes of source code via
intellisense as he did by typing.

I am out on the opposite end of the spectrum; when I'm coding I don't want to
think about tools at all, and a tool had better be absolutely spot-on
_perfect_ or its rough edges will waste more of my time by distracting and
irritating me than its features will save by automating something I would
otherwise have had to do with my brain. I sometimes use IDEs depending on the
project, but I always disable code indexing / completion, because the little
timing hiccups you get as the tool does its thing break my flow and irritate
me. Instead, I put more time into making consistent names and simple APIs so
there is less to remember, and do a bit of extra grepping when I can't recall
what I need. For me this feels easy and natural; for other people it seems
like going the hard way, and they don't understand why I won't let the machine
help.

These differences extend all up and down the tool chain; some people love
their sophisticated debuggers and write all kinds of complex scripts that
produce interesting results, while I tend to just throw in a lot of printfs
and debug by reading logs. Not to say I won't use a debugger when it's
available - just that I know the log approach will always work, and it can be
less work to fall back on something simple that I don't have to think about
rather than taking the time to remember where all the debugger's knobs and
switches are. On the flip side, I will make heavy use of all available
language tools for abstraction and code simplification - lambdas, namespaces,
interfaces, whatever's handy, my goal is to build every interface, no matter
how minor or internal, in such a way that it's difficult to use it improperly.
This has irritated people I've worked with who are happy with simple
boilerplate because they rely on automated refactoring tools; to them, these
esoteric abstractions were aggravating because it left them struggling to see
the forest for all the unfamiliar trees.

Some of this may be a function of experience, particularly experience with
low-level environments. I've written plenty of debugging, logging, grepping,
and reporting tools over the years, so I know I can always just bang together
what I need in the moment, and the prospective payback from learning some
existing do-it-all tool feels correspondingly reduced. But is this a smarts
thing? I am not so sure - I mean, I do think I'm pretty smart, but it could
just be preference; I really like digging into the foundations of things and
have therefore invested a lot of time learning how to work in those
environments. Someone who actually prefers to live at a higher abstraction
level might well be wasting their time by thinking about this sort of thing,
and while that's not my bag I certainly wouldn't argue that high-level work is
unnecessary or of lesser importance.

Some of it may also be a function of age. I've seen so many tools come and go
that it has come to feel like a waste of time to learn one deeply until it has
become stable and ubiquitous enough that I can reasonably expect the time I
invest in it to pay back over at least 5-10 more years. If it doesn't meet
that threshold then why bother? There will just be something else coming along
later. I'll learn it if I need to use it, but because of the above-described
confidence that I can get the job done regardless of tooling, I'm less likely
to hit the bar for "need to use it".

The weakness of the heavy-tooling approach is that tools always have flaws and
blind spots, and one can get stuck thinking through the tool's mindset and
have trouble when there's a problem it doesn't solve particularly well. But
the weakness of the light-tooling approach is that tools shape mental models,
and mental models shape language, and software development is really more
about communication between humans than it is about communication with
machines; if you don't adopt the mental frameworks your coworkers are using it
may be more difficult to interact with the systems they are building.

(also, a moment of brag: one of my proudest debugging feats was when I wrote a
bootloader for a brand new embedded architecture using no feedback but a
single blinking LED. There was no stack trace, not even a serial line for a
printf log, because none of the drivers had loaded yet.)

~~~
realharo
Regarding misspelled identifiers, I've experienced the exact opposite problem.
Code I had to work with that was clearly written in simple editors often
contained misspelled words (though it was also usually written by non-native
English speakers) and even bugs arising from using a wrong variable name.
Errors that with proper tooling would be near impossible to make, because the
tool would immediately underline the variable as either containing a spelling
error or not being defined. Not to mention it also lead people to using
generic non-descriptive variable names and abbreviations.

I also watched some people trying to printf-debug a problem, and it's usually
a fest of "Was the problem here? Hm, not here, ok, let's put these statements
over there. Hm, not over there either, what about here... (repeat several more
times, depending on how deep the calls go)" Having to do something like this
would really feel like stone age to me, when you could just get all the
relevant information in one quick pass without having to modify any code.

Another thing is documentation. When you know that you can just bring up a
method's documentation with a single keystroke, you are much more motivated to
document your own methods in the same way. If it's just "some generator will
create a bunch of static html pages later on that most people likely won't
ever read", some people will not bother.

I do agree about flaws in tools being a huge issue though. Especially with
refactoring tools, if you can't trust it to not accidentally mess up parts of
your code, you might as well not use it at all. Similarly, if you can't trust
a "find usages of this method" to find ALL of its usages, the utility
diminishes severely.

EDIT: oh, and perhaps the most simple, but most important feature of all,
being able to Ctrl+click a function to navigate to its definition means that
people are going to dive into the code a lot more often, even
framework/library code, which is obviously beneficial to learning how things
work under the hood. The less friction there is to doing something, the more
readily people are going to do it.

~~~
MrBra
Why my request for a TL;DR got downvoted? I thought, if you had that much to
say, it could be am interesting opinion, but I didn't have enough time to go
through it all.

~~~
JadeNB
I didn't downvote, but I read a TL;DR, especially one directed _at the
commenter_ , as saying "my time is more important than yours; could you spend
your time purely for my benefit, despite my not being willing to put in my
time to read what you've said?" All else aside, it probably takes longer to
ask for, and then complain about downvotes on, the request than it does to
read 4 short paragraphs.

~~~
MrBra
Since when TL;DR's have an obligatory hidden meaning? You can speculate on
that, but it's. just your speculation and nothing more and it can be at the
compete opposite side of my intentions. So don't tell me what you read in my
two words "TL;DR".

There is no way I should justify a request for summary in the first place I
just did that afterwards in order to undetstand reasons for downvoting and if
that was that someone else is giving their own interpretation to my request,
then it's not a valid reason for me.

Their downvote does not make me learn anything new and I just observe how
obtuse and flawed their mental process was. They were probably angry for
having to read all the long comment I referred to and for not accepting
someone else could get away with a shorter version of it. It's called envy and
it sucks.

TL;DR:

I don't give a shit about your downvotes if you give your own interpretation
to my request in order to support your envy for the fact that I could get away
with a shorter version of the original text.

------
matthewmacleod
Hmm, I'm not so sure about this.

Ruby's tooling is obviously not as advanced as a language like Java, for many
reasons. But _terrible_ isn't the adjective I'd use. It's pretty easy to use
editor integration to provide pretty decent automatic formatting, linting and
code completion. Pry-debugger is pretty great, and generally I don't find
working in Ruby to be markedly more taxing that other languages.

I guess YMMV, though.

~~~
braythwayt
> automatic formatting, linting and code completion

You are describing tooling that is used to _write_ code, but not to read or
debug it. And Ruby is exceptionally easy to write without any tooling
whatsoever.

The hard problem with dynamic languages is reading the code and understanding
what it is doing at run time. And that is where TFA suggests Ruby is terrible.

~~~
Gibbon1
One the way to reading about something else, I read an essay by a language
developer complaining about type erasure. In functional languages.

In short, when you get to the point in implementing a language where you can
do type erasure, you're golden because it usually means you have things nailed
down. Unfortunately then people actually implement type erasure and now there
is no way to link data structures in memory with a piece of code at run time.

Or at least very easily.

As an example C/C++ does erase type information. There often being nothing
that tells you what an object in memory is. But compilers take great pains to
preserve that information in the generated output formats. Which allow you to
write debuggers. I'm sure languages like Java and .net do the same.

------
davexunit
I write both Ruby and Lisp frequently, and I must agree that Lisp tools are
vastly superior. Ruby, despite being a dynamic language, has a sorry excuse
for a REPL which really hampers my workflow. For example, Rails watches your
Ruby files for changes and reloads them in development mode, but if it was
easy to re-evaluate arbitrary expressions from your editor (a la SLIME or
Geiser) such a feature would never be needed. Then, of course, there's
typically so much magic happening that it's often impossible to find the place
in which a symbol was defined by searching for that symbol, which makes
debugging overly difficult.

~~~
cpitt
When you say "sorry excuse for a REPL", you are referring to the built in repl
and not pry ([http://pryrepl.org/](http://pryrepl.org/)), right? because pry
is freaking awsome!

~~~
davexunit
The same issue is there. This is a language issue. I want to edit a file and
re-evaluate arbitrary expressions with a keystroke. Writing the code and then
copy/pasting it into a REPL prompt is not sufficient. Lisp programmers have
had excellent live coding environments for a very long time, but with Ruby I
must make do with Rails auto-reloading files for me.

~~~
vidarh
> I want to edit a file and re-evaluate arbitrary expressions with a
> keystroke. Writing the code and then copy/pasting it into a REPL prompt is
> not sufficient.

This suggests to me you've not spent much time with Pry. Are you aware of
this:

[https://github.com/pry/pry/wiki/Editor-
integration](https://github.com/pry/pry/wiki/Editor-integration)

It's not perfect - doing it perfect with Ruby is a hard problem, as a method
can have been defined and redefined in multiple places. But it works very
well.

~~~
davexunit
>Example: Jump to line 10 in the file, Pry will reload the file after you have
finished

It's still just reloading a file. That's not what I want.

~~~
vidarh
Then what _do_ you want? The file can be either the original source file, or a
file containing _just_ the method you wanted to edit, or anything else.

Why do you think you need more?

~~~
davexunit
>Why do you think you need more?

Because I have access to something much better any time I write Scheme.

~~~
vidarh
Better in what way? How is it better than a buffer to put arbitrary code in to
get executed?

So far, from what you've pointed at, you seem to have picked the most
restrictive simplistic examples of what Pry is capable of as a counter-example
to explain why it isn't enough for you, rather than explain what it is you
believe is actually missing.

Point is: You have access to much better than the examples you've pointed at
with Pry as well.

------
endlessvoid94
I wrote a Smalltalk-esque System Browser for manipulating class definitions
without the need for a filesystem awhile ago (here's a rather crappy
screencast of it:
[https://www.youtube.com/watch?v=2xC5B5t5Rq8](https://www.youtube.com/watch?v=2xC5B5t5Rq8))

It was a LOT of fun, and I wish I had the time to resume it. The feedback loop
was so much faster, and I can say that there is serious cognitive overhead we
all carry by manipulating the definitions of things in files rather than just
the objects and classes themselves.

It was a fun experiment.

------
bascule
This is one of the things I've always liked about JRuby. You can use the
excellent tooling of the JVM ecosystem (e.g. YourKit, Coverity Dynamic
Analyzer) to understand the behavior of your JRuby applications, and even
attach directly to running production apps to debug them.

I've found tools like this essential for debugging multithreaded JRuby
applications, and there's simply nothing else like them available for MRI.

------
graffitici
How would people that use both Python and Ruby compare the tooling for both
languages? I only am familiar with Python, and I end up using IPython most of
the time. I'm curious whether I'm missing out, or maybe Python also has
"terrible" tooling..

~~~
boardwaalk
This is pretty specific, but Ruby has pretty terrible support for parsing
Ruby. Libraries are either unmaintained or broken or for old versions. Python
is great for parsing ('import ast'), compiling ('compile(...)') and executing
('exec(...)'). So it's much easier to write code generators, write linters and
autocompletion tools and such.

~~~
cremno
>but Ruby has pretty terrible support for parsing Ruby

[https://github.com/whitequark/parser](https://github.com/whitequark/parser)

Neither unmaintained, broken nor just for old versions. It has some really
minor incompatibilities though:

[https://github.com/whitequark/parser#known-
issues](https://github.com/whitequark/parser#known-issues)

The same person also wrote a Python parser because apparently the ast module
doesn't provide precise location information of tokens:

[https://github.com/m-labs/pythonparser](https://github.com/m-labs/pythonparser)

------
jasim
One of the biggest success stories in recent times where language support has
made tooling awesome is JSX.

The success of JSX shows that developers are happy to write HTML inside code,
and there are clear benefits of doing so compared to using a dedicated
templating language. But the reason why this wasn't popular till JSX showed up
was that it is impossible to parse the HTML built in code through string
munging. JSX makes XML-inside-Code parseable, which makes it possible for us
to use IntelliJ's excellent IDEs to work seamlessly with it.

~~~
anon4
For those confused:

JSX is a statically-typed, object-oriented programming language designed to
run on modern web browsers. Being developed at DeNA as a research project, …

[https://jsx.github.io/](https://jsx.github.io/)

~~~
a-priori
I think the parent is actually referring to this JSX:

[https://facebook.github.io/react/docs/jsx-in-
depth.html](https://facebook.github.io/react/docs/jsx-in-depth.html)

------
braythwayt

      > People in the industry are very excited about various ideas that nominally help you deal with
      > large code bases, such as IDEs that can manipulate code as "algebraic structures", and search
      > indexes, and so on. These people tend to view code bases much the way construction workers view
      > dirt: they want great big machines that can move the dirt this way and that. There's
      > conservation of dirt at work: you can't compress dirt, not much, so their solution set consists
      > of various ways of shoveling the dirt around. There are even programming interview questions,
      > surely metaphorical, about how you might go about moving an entire mountain of dirt, one truck
      > at a time.
    
      > Industry programmers are excited about solutions to a big non-problem. It's just a mountain of
      > dirt, and you just need big tools to move it around. The tools are exciting but the dirt is not.
    
      > My minority opinion is that a mountain of code is the worst thing that can befall a person, a
      > team, a company. I believe that code weight wrecks projects and companies, that it forces
      > rewrites after a certain size, and that smart teams will do everything in their power to keep
      > their code base from becoming a mountain. Tools or no tools. That's what I believe.
     

—Steve Yegge, "Code's Worst Enemy" [http://steve-
yegge.blogspot.ca/2007/12/codes-worst-enemy.htm...](http://steve-
yegge.blogspot.ca/2007/12/codes-worst-enemy.html)

I'm not quoting this to refute the idea that Ruby has terrible tooling, or to
suggest that tooling doesn't matter. But rather, to give some context for this
idea:

When we first embraced Ruby, we were writing web apps in Java. Ruby allowed us
to write those same apps with fewer lines of code, by fewer people, in less
time. That was a triple-win, and there were all sorts of secondary positive
effects.

Fewer people on a team means less necessary process. It means less money
required. YCombinator wouldn't exist today if you couldn't have done something
meaningful with $18,000 over a few months. Less time means you can be lean and
iterate, rather than spending time and tons of money trying to analyze what a
market wants in advance.

Those factors were massive wins for the startup culture. There are similar
effects within companies, but I needn't list them out here.

But one negative effect is that with small teams writing fewer lines of code,
in a startup culture, there is much less emphasis on tooling. It's a "nice-to-
have," because app complexity does not make the difference between shipping
and not shipping.

So yeah, there's some tooling, but it is not very good. Really, it's not. But
it was good enough.

But as time went on, our apps and teams grew. Most businesses are in a Red
Queen's Race against their competition. It is very hard to stay small and
focused and have a single responsibility in a market. So our code grows and
grows, until it reaches a kind of equilibrium with how many lines of code a
company can support. Which means we expand until we're back to having big code
bases, with many engineers.

And guess what? One million lines of Java is easier to understand than one
million lines of Ruby. Doubly so when you have better Java tooling than Ruby
tooling, and when Ruby does things that demand better tooling.

So now we're in this place where successful companies have big apps, but we
don't have a "big app" culture, so we don't have the tooling required to
support this many lines of Java, much less this many lines of Ruby.

\---

p.s. Here's a very nice person saying the same thing at WebRebels:
[http://vimeo.com/76141334](http://vimeo.com/76141334)

~~~
steveklabnik
I don't disagree with the thrust of this post, but

    
    
      > When we first embraced Ruby, we were writing web apps in Java.
    

Avdi's reference to people coming to embrace Ruby is specifically in the pre-
Rails time period. So you're talking about different, though absolutely
connected, things.

~~~
braythwayt
I was there too. You know... It was possible to write web apps in Ruby before
Rails and Sinatra, although today that feels like a party trick, like writing
FizzBuzz in Lambda Calculus.

~~~
steveklabnik
Pssssh. :)

Anyway, I'm hoping that the new static typing proposals can help make Ruby's
tooling better. Ruby's greatest strength is also a huge weakness, it's just so
hard to tell what's happening with all the dynamism. As someone who's been
back to static typing for a while, but wrote a lot of JavaScript over the past
few weeks, that's the angle I've been thinking about in this area.

I haven't been able to properly articulate why I never feel the need for these
tools in Ruby, yet in other languages, they feel indispensable. Human brains
are amazing: you can hold two completely contradictory opinions
simultaneously. (Though maybe the different context means that they're not
actually contradictory, even if it feels like it)

~~~
dragonwriter
> Anyway, I'm hoping that the new static typing proposals can help make Ruby's
> tooling better.

Probably not. Keeping the language in place and focusing on tooling would make
the tooling better; as others have pointed out, there are dynamic languages
with better tooling.

And, its not like people who want the costs and benefits of static typing are
ill-served by the current marketplace of computer languages.

------
beat
The author touches on something important when comparing Ruby to Unix, and why
we love them more than more structured systems.

 _Rigorous language is the enemy of expressive language._

That's not to say you can't be expressive within a rigorous system - it's just
more difficult. And you can only express the things that the rigorous language
is capable of expressing. So less rigorous, less formal environments, like
Ruby and Unix, allow for a great deal of fast and intuitive expressiveness.

~~~
falcor84
> Rigorous language is the enemy of expressive language.

That's an interesting statement. I couldn't find it on the web, is this your
own, or a paraphrasing/translation?

~~~
beat
Yeah, I just made it up.

------
PythonicAlpha
I don't know, if the statement is true, since I did not work with Ruby really
till now.

But I definitively would support this statement:

> Programming languages cannot be considered separately from their ecosystems

I think, one of the main reasons for the success of the C system was not the
language itself, but the standard C library. Standard Pascal did not have such
a thing (Borland Pascal had and was more successful as any other Pascal),
Modula 2 -- a superior language at its time, did not have it (the library that
was standard for Modula 2, was just to clunky for wide usage) and also other
languages did not have it.

C, when it started, had not only the library, but also a -- for that time --
superior development environment: Unix.

From this, I would strongly agree, that the ecosystem is decisive -- and the
bar has risen since the times of C. Today, you need top compilers or
interpreters, top of the notch libraries -- best to have a framework (like
Rails) for a good use-case to use the language and tools around that support
your programming.

With all those good languages around today, any new language must have an
appeal and the ecosystem and if possible the community, to be successful.

~~~
pjmlp
I came to view UNIX as the actual C runtime, they just decided to split it up
into ANSI C and POSIX standards.

------
yesdocs
This argument rings true and has been in the back of my mind for quite a
while. To take this into a different context... for example if you were
building a house per se.

Houses were built out of wood for years (and still is), but we slowly built
tools to make it easier (Hand held saws, levels, nail guns). Now a new
material has hit the market... plastic (for instance) and it is a better and
more pliable medium to build a home, but we lack the tools to make it easier.
It is as though we have no hand tools that will cut through it, or no nail gun
that will penetrate it. Yes, it (Ruby) seems to be a better material to have a
structure built with, but when you are building a lot of homes or even a
mansion, it seems silly to use a material that limits what you can do to
manipulate it. The argument that "Ruby is so cool, I don't need tools" seems
quite silly and misguided. That may be OK if you are building treehouse in
your back yard, but if you are building an entire housing district, you are
going to lose money in the development costs.

~~~
beat
The best quality, long term lowest cost roofing material is copper. But we use
asphalt shingles, which are short-lived and expensive in the long term. Why?
Because they're cheap in the short run, they require little expertise to
install, and they're easy to customize.

Sound familiar?

------
rquantz
So what's a language that has much better tooling than ruby, but still has a
web stack as good as Rails? Does one exist?

~~~
lelandbatey
Some people would say "Python", since the tooling for Python is generally
excellent, but I don't have enough experience with Python web stacks to say
that they're better or worse than Rails. There's certainly less _" magic"_
with Python, but I'd argue that's a good thing.

~~~
mtarnovan
I think all the criticism from that article applies to Python as well.

~~~
andybak
Not all of them. Python is often stricter in some aspects of the language and
in community norms.

Someone can correct me if I'm wrong but the module namespacing helps mitigate
this complaint via Twitter:

> Can't figure out how a simple thing works in a codebase with a zillion tiny
> objects and a billion levels of indirection?

i.e. unless you've gone out of your way to be too clever - you usually know
where things in the current namespace came from.

------
mark_l_watson
So wrong. The author has probably never tried RubyMine (or IntelliJ with the
Ruby + Rails + etc. plugins).

I was hacking with Pharo Smalltalk just yesterday, so I get what the author
means by the niceties of Smalltalk, but Ruby tools from Jetbrains are very
nice.

~~~
lukeholder
Please read the article before posting. He mentions rubymine.

~~~
mark_l_watson
Thanks for the correction! I missed that he relies on Rubymine for his work.

------
yoklov
> "In Smalltalk, everything happens somewhere else." \- Adele Goldberg

Am I the only one that thinks this sounds like a maintenance nightmare?

I don't understand how this could ever be a good thing.

~~~
akud
It can be beneficial for maintenance as it helps avoid overly-large methods
and monolith objects.

------
nchelluri
EDIT: I realize I left out my main point: I definitely agree with several of
the points in the article. I have long wished for some way to traverse
ObjectSpace easily and to know what code is being actually executed at any
point in time. Lack of use of or availablity of comprehensive static analysis
tools in our programming today is a huge problem, IMO. </end edit>

I don't have much experience with Ruby debuggers, as I rarely use them.

I do use RubyMine, every day. It's got powerful inspections and is an
incredibly valuable tool for me. But, I originally used IDEA many years ago,
and I don't think that RubyMine is anywhere near as powerful, because of all
the dynamism inherent in Ruby.

I personally think that Ruby is far too flexible a language. I use
metaprogramming, monkey patching, and `method_missing` exceedingly sparingly,
if at all. I try to never make code any less traceable than possible. But, I
use Rails, and while I don't dive into the Rails source very often, I'm sure
there's a lot of hidden stuff in there. All sorts of methods added to classes
(ActiveSupport - inflections, time zone helpers, ... - and all the core
extensions that have made their ways into gems that do not even require
ActiveSupport), and all of my URL helpers which use method_missing to "define
methods" that never existed. In a word, Ruby's dangerous (and can be made to
be very hard to reason about).

I have been watching [http://crystal-lang.org/](http://crystal-lang.org/)
every once in a while. I think one of the core strengths of Ruby is how
concise and elegant it is or at least can be, and how readable it is or at
least can be. It's pretty damn nice in a lot of ways. The community support is
of course incredible as well ([https://github.com/bbatsov/ruby-style-
guide](https://github.com/bbatsov/ruby-style-guide) is great, [http://slim-
lang.com/](http://slim-lang.com/) has made markup a non-arduous task, etc).
Maybe we can do better.

EDIT: Incidentally: a lot of my complaints about Ruby are things that I would
say about JS as well, but I have considerably less experience there. I just
know that I've half-learned sooo many JS patterns. While I don't know Python,
one of the things I've really liked hearing about it is how there's supposed
to be "one right way" to do stuff. I think this is good. Code serves a
purpose, it's a functional tool - IMO, it's not like written language where
you really need a bunch of similar-but-different ways to get the same meaning
across.

~~~
Retra
The Python "one right way" is a bit of a myth. It's a design goal that is
unrealizable in practice. However, the documentation is very good and (in my
experience) it lends itself to solving problems in very obvious ways.

~~~
nchelluri
Thanks. I had my suspicions, but some things are best left to the imagination
:)

------
crimsonalucard
For a second I thought that subtle background on the site was actually
something physically happening on my screen.

------
MrBra
everything within our knowledge in the material world can be fixed with enough
resources. maybe for Ruby you could need more resources at the beginning given
how it has been designed, but once you build up a good land upon which it will
be easier to make other changes, (possibly even with a Kickstarter for a new
kickass ruby implementation?) then the resources required for other changes
will be comparable with the same needed in other languages. In the meanwhile
in Ruby we have been profiting from nice syntax and object model, which in the
end, IMHO is what paired the balance and still made us use it. This article
was great in the sense that highlightinged the right approach that we would
need in Ruby to make it grow to a "state of the art language". I really hope
this will happen but for some reason I feel a great amount of opposing force
to it and I am not sure it only comes from rational thought. I'd like to see
someone have their say on this aspect at a deeper level.

~~~
MrBra
Refactoring my own comment above (I apologize but I can't delete it anymore).

Everything in the material world within our knowledge can be fixed with enough
resources.

Given the current design, maybe for Ruby we could need more resources at the
start of this process, but once a good base is layed out it will be easier to
make other changes. Or could it all start with a Kickstarter for a new Ruby
implementation???

Anyway, at that point, the resources required for successive changes will be
comparable with the same needed by other languages.

So far in Ruby we have been profiting from nice syntax and object model, which
in the end is what paired the balance and still made us use it.

This article was great in the sense that highlightinged the right approach
that we would need in Ruby to make it grow to a better implementation. I
really hope this will happen but for some reason I feel a great amount of
opposing force to it and I am not sure it only comes from rational mindset.
I'd like to see someone have their say on this on a deeper level.

------
justinzollars
The hipster backlash on Ruby continues.

~~~
jballanc
Considering that the author's primary source of income (to the best of my
knowledge) is a video series on tips and tricks for Ruby development, I
wouldn't chalk this up to "backlash" so much as "call to arms".

