
Where does Ruby go from here? - scottefein12
http://blog.sefindustries.com/the-happiness-manifesto/
======
tmorton
I think this is a great idea. The ruby community is a wonderful thing, and
part of that is reflected in the technology.

However, the original Agile Manifesto was powerful because it made tradeoffs.
"We value X over Y", even when Y is a valuable thing. For this HDD thing to
take off, it has to make the similar tradeoffs explicit.

For example:

    
    
      We value readable code over runtime performance.
      We value open-source frameworks and libraries over developing for popular ecosystems.
      We value inclusiveness, diversity, and respect over pure meritocracy.
      We value teaching, learning, and improving our craft over short-term productivity.
      We value creating wealth over capturing wealth.

~~~
zak_mc_kracken
The Agile Manifesto is the opposite of tradeoffs.

"We value X over Y" is not a trade off, it's a dogmatic claim.

"We should do X in these conditions and Y otherwise" is a trade off.

For each of the items you list above, I can come up with a few scenarios where
doing the opposite of what the Agile Manifesto says would be the better
approach (and that's probably one of the main reasons why hardly anyone takes
that Manifesto seriously these days).

~~~
bunderbunder
There's that bit at the bottom of the Agile Manifesto: "That is, while there
is value in the items on the right, we value the items on the left more." I
think the spirit of it is to try and discourage outright dogmatism. That said,
I'm coming to think of the Agile Manifesto as a collection of four rather ugly
false dichotomies. It's the assumption that those 4 pairs of things are
somehow separable that's what's really dogmatic about the manifesto.

For example:

Processes and tools can often be one of the best ways to improve interactions
among individuals. See Scrum, which is hardly a panacea but sometimes it works
wonders.

For a large project, comprehensive documentation is essential to producing
working software. Ideally the documentation should be so comprehensive that it
pervades the very fabric of your application in the form of good factoring,
command-query separation, etc.

Contract negotiation can be an important first step in customer collaboration.
Everyone needs to know where everyone else's needs, boundaries and comfort
zones are.

Without a clear plan, how can you be sure of the best way to respond to
change? See: Duke Nukem Forever, WinFS, RIM.

------
jtbigwoo
If you're writing a manifesto, you should be able to test future decisions by
running them past the criteria in the manifesto. The first four statements are
great in that regard, but the next six are a little fuzzy.

It might help if the manifesto is clearer on what you don't value. Mission and
vision statements are often meaningless because you can stretch a positive
statement to include almost anything. The Agile Manifesto is great because it
uses contrast to clarify what it values most.

In some of the statements, the contrast seems to be implicit and that's fine.
("I value an environment conducive to all levels of experience." I assume that
means we don't want an environment for only beginners or only experts.)

Other statements, though, are harder to figure out. ("I value software
development as a craft." Does HDD cater to "craftsmen" as opposed to
hobbyists? Or is this in opposition to "professionals"? Or are we talking
about relationships and apprenticeship?)

I think this concept has a ton of potential. Can't wait to see where it goes
next.

EDIT: It appears tmorton was thinking the same things and used far fewer words
to say it.

~~~
scottefein12
Really good points-Definitely will add some contrasts to help clarify. Feel
free to submit a pull request with your ideas!

------
JonnieCache
I don't want to leave ruby, but at the end of the day, it's slow. Jruby is
pretty decent, but the clunkiness of the JVM takes the fun out of it.

Maybe it's just the lack of a corporation pouring billions into it like google
did with V8, but I suspect that ruby can never be fast, due to ObjectSpace and
the like. That awesome/insane object model we all like so much is just
impossible to optimise. All the other weird shit ruby can do doesn't help.

[http://blog.headius.com/2012/10/so-you-want-to-optimize-
ruby...](http://blog.headius.com/2012/10/so-you-want-to-optimize-ruby.html)

Still, for stuff that doesn't need to be fast, ruby is still a joy to use, and
always will be. The enumerable API feels so fluid, it's only really surpassed
by languages like clojure in my experience.

As you might be able to guess, I'm looking forward very much to swift becoming
a general purpose language. If apple are all funny about it and try and neuter
the ecosystem for some reason, I will be a sad panda.

~~~
Pxtl
Now I'm starting to wonder if it would be possible to adapt V8 directly to use
other dynamically-typed scripting language, like the Parrot project was
intended to do. A language parser at the front, V8 in the middle, and the
language's standard library in the back.

Node.js demonstrated the power of V8 with an alternate stdlib, perhaps an
alternate language in front is possible too? Then again, probably V8 is at the
very least heavily entangled with Javascript's type-system.

~~~
lobster_johnson
Apple's FTL [1] is probably a better way to go. It's a high-level, general-
purpose JIT for LLVM that is being used by Apple's own JavaScriptCore in
WebKit. There was a discussion about it on HN a while back [2]

Last I checked, V8 was highly JS-specific, and you would have to rip out and
replace large parts of it.

[1] [https://trac.webkit.org/wiki/FTLJIT](https://trac.webkit.org/wiki/FTLJIT)
| [https://www.webkit.org/blog/3362/introducing-the-webkit-
ftl-...](https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/) |
[http://blog.llvm.org/2014/07/ftl-webkits-llvm-based-
jit.html](http://blog.llvm.org/2014/07/ftl-webkits-llvm-based-jit.html)

[2]
[https://news.ycombinator.com/item?id=7740925](https://news.ycombinator.com/item?id=7740925)

------
programminggeek
I wish "I value performance and user experience" was on there.

I'm not sure how happy you should be as a self centered developer with no
empathy for the people using your software.

Sometimes software can and should be ugly if it makes for a better end
product.

~~~
scottefein12
Full free to submit a pull request. The idea is to make sure the tools and
practices make it so a developer is happy writing good, performant code with a
good user experience. If the code is ugly and hard, people won't do it.

~~~
EpicEng
"Make a pull request" is an awful suggestion and, honestly, a cop out. Most of
don't have time to tune a programming language or framework, we'll just use a
better tool and move on. Slow but pretty code is a brain dead goal.

------
MichaelGG
>\- I value respect and tolerance to all in my community

What does that even mean? If a Time Cube guy shows up, does it mean I'm just
supposed to politely ignore/shadowban him?

Does it mean I can't use "master-slave" replication?

I _think_ what that line is supposed to mean is "I value not being needlessly
abrasive to people" and "I value ignoring unrelated-to-my-project aspects of
people".

That is, even if you have some belief or participate in an activity that I
find abhorrent, if it's not relevant to the project we're working on, I value
avoiding talking about such things so we can focus on the project.

------
Chris_Newton
No doubt promoting happiness in the development community is a worthy goal,
but there is a lot of variety in what makes different software developers
happy, and inevitably their priorities will sometimes conflict.

For example, the principle that a programming language should be optimised for
the programmer and not the computer seems reasonable. However, what if a
programmer works on projects where performance matters, and we haven’t figured
out how to implement certain language features in an efficient way yet? It may
be true that under some conditions saving a programmer time is more valuable
than shaving a few seconds off at run-time, but there are many situations
where this is not the case.

More subtly, programming languages that are easy to parse, that represent
their source code in a well-structured way, and that have clean semantics are
friendly to tool developers. I imagine many programmers are happier with a
language that has good refactoring, debugging, profiling and testing tools
available, and which plays nicely with their favourite editor, diff and
version control systems, and code review tools. Again, there might be a trade-
off between adding a new language feature, which in itself might be useful for
the programmer, and keeping the language simpler or more cleanly structured,
which might encourage effective automation and tooling.

~~~
scottefein12
It's a community at the end of the day, and having conflict like that is
actually good. We should have people with different use cases and problem sets
sitting in the same room sharing ideas. That's how we can improve as
developers.

~~~
Chris_Newton
No argument there from me. I’m just not sure it’s possible to have a single
manifesto you can promote in that environment, because the goal of the
manifesto is essentially to represent a consensus that can’t exist. What you
wind up with is the least common denominator, but the most interesting and
useful discussions are usually in precisely the areas where there are
reasonable differences of opinion or priorities and therefore significant
decisions to be made.

------
nchuhoai
I think the single best thing that Ruby can do in terms of making me even
happier is to make concurrent programming easier.

I love Ruby and the Parallel gem
([https://github.com/grosser/parallel](https://github.com/grosser/parallel))
makes certain stuff easier, but I feel like every month or so I spend hours
just trying to figure out the proper way on how to parallelize

~~~
kyllo
Have you looked at the Julia language?
[http://julialang.org/](http://julialang.org/)

It has semantics very similar to Ruby or Python, but it has strong built-in
language-level support for parallel computing:
[http://docs.julialang.org/en/latest/manual/parallel-
computin...](http://docs.julialang.org/en/latest/manual/parallel-computing/)

------
danso
I would love Ruby to become the goto "glue" language between different
platforms and applications. I confess to not being more than a layperson in
Perl, even though Ruby is heavily inspired by it...could Ruby ever replace
Perl as the "Swiss-army chainsaw of scripting"? Or are their technical hurdles
(such as performance) that would keep Ruby from being that kind of status quo?

~~~
Igglyboo
Do you have any experience with Python? IMHO I think python fits that niche
better than ruby or perl.

~~~
humanrebar
Ruby is generally more concise and easier to write though probably harder to
maintain.

For example, when shelling out, ruby lets you do it many ways, including the
familiar backtick syntax. In python, you shell out with popen -- you need to
contruct argument lists, wire up stdout and stderr, etc.

Python's way might actually be better (more explicit, less ambiguity, easier
to handle errors) but often you might just want something that's simple and
readable.

For the record, there are nicer python APIs and safer ruby APIs. These are
just general comments on the different ecosystems.

~~~
rch
Try the python 'sh' module
([https://github.com/amoffat/sh](https://github.com/amoffat/sh)). For example:

    
    
      from sh import git
      print git('version')

------
gioele
All I need from Ruby is an extension that allows sections of programs to be
completely static typed thanks to explicit type hints. Not for the speed, just
for the ability to catch errors at compile time.

------
eik3_de
_> But we have technology needs that aren’t going to always be well served by
Ruby_

What are some examples?

I'll start with heavy number crunching (Go/C) and browser-based apps (JS)

~~~
gphil
Concurrency (Clojure, Erlang)

~~~
MoOmer
Not MRI, but JRuby + [http://akka.io/](http://akka.io/)

There are also some great gems like Celluloid to help. That said, it's not the
same as built-in concurrency.

------
scottefein12
Github Issue #2: What do we do after we value something?
[https://github.com/scottefein/the-happiness-
manifesto/issues...](https://github.com/scottefein/the-happiness-
manifesto/issues/2)

Lend your two cents in the comments...

------
dustinupdyke
I like the sentiment of this manifesto.

But I don't like that it starts with a machine and code focus. Shouldn't
people be first?

~~~
scottefein12
It's about taking our main tool as developers and making sure it works for us.

------
bam365
The Happiness Manifesto? Happiness-driven developers? Enough, already. This is
an interesting time for computer programming and computer science in general.
We're witnessing the coming of age of a very important profession. We owe it
to ourselves to advance this profession by developing a body of knowledge
based on scientific, mathematical, and engineering principles, as well as
empirical observation of what has worked and what hasn't. What we don't need
is cultural manifestos and middle-management buzzwords.

~~~
scottefein12
We're talking about a community where some of the brightest minds already
don't come from a traditional background. Several well-known Rubyists have
degrees in Theatre and Music. The community is where all the value is-that's
where the innovation is coming from. People build products, so culture is
essential.

~~~
carterehsmith
As for the Theatre and Music... we can see the results... and the results are:
Ruby is going from 1% people using it to 0.1%. The people that actually have
to make things work have left Ruby.

