Where does Ruby go from here?

http://blog.sefindustries.com/the-happiness-manifesto/

by scottefein12 • 12 years ago

103 91 12 years ago

blog.sefindustries.com

danso• 12 years ago

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?

elliotec• 12 years ago

Thats what I use it for.

Igglyboo2• 12 years ago

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

humanrebar• 12 years ago

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.

rboling91• 12 years ago

I think that both Python and Ruby can serve this purpose well, but both the block and method_missing functionality in Ruby can result in highly flexible and concise APIs. Correct me if I'm wrong, but I don't think there's a precise analog in Python to the Proc/Block syntax found in Ruby, maybe with the exception of lambdas. Furthermore, delegation using method_missing can result in APIs/libraries being very concise and readable.

wtetzner• 12 years ago

Can you give reasons?

valarauca1• 12 years ago

Perl, Ruby, Python all have the necessary toolkit to fitful this roll. And all run within the same ballpark of speed. Honestly most of these scripting languages (or even perl in most of these cases) is doing the same thing a shell script can do.

Just Perl made string manipulation a lot easier then the standard shell. Also Perl got there first, which is slightly important.

kcorbitt• 12 years ago

I think Ruby already serves this use case well. When I have to do file munging or sysadmin tasks that are a bit too complex for bash, Ruby always seems to have an elegant and readable way of getting done what I want to do. It's a combination of the syntax, standard library and ecosystem, and it does a great job.

ufmace• 12 years ago

I'm already using Ruby for this. It's great for making little scripts and utilities to automate things and glue things together. Being able to interface with just about anything without much boilerplate while also having all of the tools of a high-end language make it really nice. Performance may not be as great - I don't know how it compares to Perl - but it's rarely an issue for these sorts of tasks. You could be 10x slower and still not notice the difference.

scottefein1212• 12 years ago

Chef. Tungsten Replicator-a powerful infrastructure orchestration tool-is all Ruby.

veesahni• 12 years ago

Ruby replaced Perl as my swiss-army chainsaw a long time ago.

ayrx• 12 years ago

The advantage that Python or Perl has over Ruby is that they are included by default with most major Linux distros. I don't think (I may be wrong) that Ruby is. This might hurt adoption somewhat.

oinksoft• 12 years ago

Some Linux distributions are not including Perl now.

elektronjunge• 12 years ago

Ruby is included in most major distros.

scoot• 12 years ago

One of the (many) great features of the Amiga was ARexx. Most non-trial productivity applications had an ARexx port (API), allowing workflows to be scripted, tasks to be automated, and functionality to be extended.

True preemptive multitasking probably also helped.

AppleScript doesn't come close, and on Windows sketchup is the only app I know of with anything similar, which happens to be Ruby. But you can't create great workflows in an ecosystem of 1, and I expect that ship has long since sailed.

eik3_de• 12 years ago

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• 12 years ago

Concurrency (Clojure, Erlang)

MoOmer• 12 years ago

Not MRI, but JRuby + http://akka.io/

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

scottefein1212• 12 years ago

If you need a lightening fast API, anecdotal evidence suggests you just can't get it down to the speeds you see with Go. Rack/Ruby just isn't going to cut it.

programminggeek2• 12 years ago

You can get close if you don't use Rails. Seriously, Cuba + JRuby + Torquebox 4 is fast, nearly as fast as Go.

http://madebymarket.com/blog/dev/ruby-web-benchmark-report.h...

chimeracoder• 12 years ago

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

Be careful to distinguish between the language and a particular implementation or runtime environment.

Go, for example, runs perfectly well in the browser[0] except for channels (which are very difficult to implement reliably given the Javascript concurrency model).

If Google decided to allow Go as a language for manipulating the DOM in Chrome, there's no reason that it couldn't serve this role equally well. (This is what Google has done with Dart, so they're unlikely to do it with Go, but this is simply illustrative).

[0] https://github.com/gopherjs/gopherjs

mahmoudimus• 12 years ago

I understand the Go hype, but what kind of "heavy number crunching" have you traditionally done with Go?

tmorton3• 12 years ago

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.

scottefein1212• 12 years ago

I think that's a great idea-want to start us off with a pull request? :)

tmorton3• 12 years ago

Done! https://github.com/scottefein/the-happiness-manifesto/pull/7

muchabi2• 12 years ago

There's a strange, delightful joy in finding that I agree with every statement here and in the original post/repo

angersock2• 12 years ago

That's a really nice feel-good list, but it also doesn't make a lot of sense in several cases:

"We value open-source frameworks and libraries over developing for popular ecosystems."

Most popular ecosystems nowadays are all open-source frameworks and libraries? Unless you're talking about Windows or Mac OSX, I guess?

"We value inclusiveness, diversity, and respect over pure meritocracy."

These are not mutually exclusive goals--even if they are, I'd rather have really good code, even if written by a racist or sexist, than bad code (period). Again, I'm not sure we have to make that choice.

"We value creating wealth over capturing wealth."

What does this even mean? This is a programming language, ffs. Your statement makes sense in, say, the heyday of APL or Smalltalk or some other very vendor-specific language, but that's not quite the case today. Are you talking about not doing data-mining to monetize your fellow man? About not creating yet-another analytics or ad platform? What then, exactly, are you driving at?

"We value teaching, learning, and improving our craft over short-term productivity."

Again, not mutually exclusive. Also, part of learning and improving your craft is knowing when a quick hack is the right answer instead of a full solution.

tmorton3• 12 years ago

I think this comment shows exactly what I was getting at. If no one disagrees, the happiness manifesto will die in a sea of nods and shrugs. :)

I'd rather have really good code, even if written by a racist or sexist, than bad code (period).

That's a perfectly valid choice. In some cases, it's a completely correct choice. But that's not the tradeoff that I want to make.

Take a look at the original Agile Manifesto: http://agilemanifesto.org/

Sometimes you can have it all: good process, good tools, good individuals and interactions. But when they conflict, the AM says that we should favor the individuals over the processes.

I'm saying that as a development community, we should favor inclusiveness and respect, even at the cost of (some) technical merit. Similarly, we should favor open-source infrastructure, even at the cost of the App Store audience.

muchabi2• 12 years ago

I read it as "given a choice between A and B, I'll choose A". So...

When choices are available for a software library, pick an open-source one over a well-tested black box, and perhaps even contribute. If the black box is the only reasonable thing out there, then use it.

Rather than try to hire by a strict ordering of skill, create an environment with varied viewpoints that can all be heard. (Of course you still hire among the top candidates, and avoid bad coders)

When choosing between two jobs, one of which creates a new product that people love, and the other cuts into someone else's profits through algorithmic/technological superiority, pick the first one. If you don't have such a choice, it's not relevant.

Last one I'm not sure about, but one possibility is "go learn Haskell/Lisp or experiment with the latest algorithms/libraries in the evening rather than work 18 hour days for your job." If you really have to get something done for work, by all means do it.

It's not "always do this", but rather "when you do have the freedom to choose, pick this"

kybernetyk3• 12 years ago

We value inclusiveness, diversity, and respect over pure meritocracy.

Heh, until not long ago a "meritocracy" was seen as something good and desirable. Nowadays it seems to be something bad (at least in some circles). Funny how things can change.

scottefein1212• 12 years ago

Meritocracy is good, but not when it creates a homogenous pool of points of view.

FraaJad• 12 years ago

The guy that coined the word in the 1950s used the word in a negative sense. http://en.wikipedia.org/wiki/Meritocracy#Etymology

lostcolony• 12 years ago

I think viewing it as a pure good is the odd view. Most people recognize that, A. It's impossible (who is doing the evaluating?), B. That it leads to a single vision/set of experiences dominating, C. That it ultimately leads to dissatisfaction amongst the majority.

zak_mc_kracken• 12 years ago

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

rubiquity• 12 years ago

It is interpreted as a dogmatic claim but it wasn't intended to be one. After all, the very essence of the Agile Manifesto is to always be thinking.

bunderbunder2• 12 years ago

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.

apetresc• 12 years ago

I think you might be confusing "tradeoff" with "compromise".

"I'm willing to give up some valuable-thing-Y in exchange for more X" is a textbook example of a tradeoff.

EpicEng2• 12 years ago

  "We value readable code over runtime performance."

Yes, well, that's obvious given Ruby's God awful performance. I think this is a mistake that puts Ruby squarely in the "toy language" bucket.

JonnieCache2• 12 years ago

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

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.

scottefein1212• 12 years ago

Ruby is a lot faster than it use to be. But it's a matter of Ruby being complimented by other languages for their best attributes.

JonnieCache2• 12 years ago

Oh it's definitely faster than it used to be. It used to be really slow. But object instantiation is ultimately still very expensive, and in a language whose design encourages the creation of huge numbers of objects, that's a problem.

Pxtl• 12 years ago

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• 12 years ago

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://www.webkit.org/blog/3362/introducing-the-webkit-ftl-... | http://blog.llvm.org/2014/07/ftl-webkits-llvm-based-jit.html

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

AlexeyBrin• 12 years ago

Ruby is not inherently a slow language. An ideal setting, will be a Ruby open source compiler (similar with what RubyMotion does) that could be used to package your code. I would use the the interpreter to test/develop the code and the compiler to actually package it.

MrBra4• 12 years ago

Exactly. People is on Ruby because of its semplicity to test ideas and craft things. That's the same reason so many devs started using Rails.

So, one immediate solution that would drive again Ruby to a stellar embracement and adoption could be preserving, in development, this immensely useful hyper-reflective environment which gives us hyper productivity and then have a parallel production environment where all of this is stripped down and code compiled without it.

In the wait for better solutions this could be a possible path, and I am sure a lot of people and software in the Ruby ecosystem would still prefer to adapt to this, rather than having to code in a more performant but ugly language.

cheald• 12 years ago

JRuby's really revived my love of Ruby. It's fast, it's powerful, and it's much easier to extend than CRuby. Jruby 9k and Truffle are both promising some pretty insane speedups, as well.

The JVM boot time is a bummer, but beyond that, there's not much to complain about.

djur• 12 years ago

ObjectSpace isn't really a major issue. JRuby disables (most of) it by default for performance reasons and I've never had to turn it on for any real code.

Ruby has been a major source of improvements in software, especially tooling and web development, over the last 10 years. A lot of the newer languages have borrowed concepts popularized by Ruby (gem-style package management; bundler-style dependency management; same-language build tools like rake; rails and sinatra-esque web frameworks). And a lot of tooling for other languages has been written in Ruby (sometimes later replaced by same-language tools). I'd compare the role Ruby has played to Perl in the '90s.

I certainly hope Ruby doesn't go down Perl's path. It may be protected from that fate by two differences. First, there's no Perl 6-like project to distract attention and effort from the actively used version. Second, Ruby remains by far the best general-purpose language out there for those of us who like Smalltalk-style OO languages (everything an object, message passing, extreme late binding).

I too would really like to see Swift escape the Apple ecosystem, for a number of reasons, even though I'm unlikely to use it myself.

jtbigwoo• 12 years ago

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.

scottefein1212• 12 years ago

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

nchuhoai• 12 years ago

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) 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• 12 years ago

Have you looked at the Julia language? 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...

Chris_Newton2• 12 years ago

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.

scottefein1212• 12 years ago

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_Newton2• 12 years ago

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.

programminggeek2• 12 years ago

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.

scottefein1212• 12 years ago

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.

EpicEng2• 12 years ago

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

scottefein1212• 12 years ago

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

Lend your two cents in the comments...

dustinupdyke• 12 years ago

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?

scottefein1212• 12 years ago

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

bam3652• 12 years ago

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.

scottefein1212• 12 years ago

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• 12 years ago

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.

GFK_of_xmaspast• 12 years ago

Has there been a time in the last 50 years that your paragraph wouldn't have been just as appropriate? Why is today, September 4th 2014, special?

bam3652• 12 years ago

No, there really hasn't. And it's a little embarrassing. Lawyers, doctors, carpenters, electricians, engineers, etc. don't feel the need to produce countless rhetorical manifestos. I'm not sure why our profession (or craft, or whatever you want to call it) has to come with so much cultural baggage, especially when there are so many real problems left to be solved.

oldmanjay• 12 years ago

Ruby has always been a little cultlike in its approach. I don't necessarily mean that as a negative, I'm just not sure what other word I can use - and it's true of so many other platforms as well, it's not solely a Ruby thing by any means.

I've always viewed computers as lowly tools meant to do my bidding, so I don't really understand this sort of emotional attachment that people get, but it's definitely a real thing that people feel. The only pragmatic way forward is to accept that this happens and figure out how to incorporate it into the larger context of software engineering.

gioele• 12 years ago

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.

MichaelGG3• 12 years ago

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

Where does Ruby go from here?

Related Stories