Where does Ruby go from here?(blog.sefindustries.com)
blog.sefindustries.com
Where does Ruby go from here?
http://blog.sefindustries.com/the-happiness-manifesto/
13 comments
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.
"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.
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.
> 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.
Can we use this as an excuse to drop Node.js, please?
After all, Javascript was created by a homophobe. We should use a more minorities-friendly language and not encourage the use of problematic technologies made by bigots.
Edit: also, someone claimed that a lead maintainer of the Linux kernel is a rape apologist. That's good enough to drop Linux, right?
After all, Javascript was created by a homophobe. We should use a more minorities-friendly language and not encourage the use of problematic technologies made by bigots.
Edit: also, someone claimed that a lead maintainer of the Linux kernel is a rape apologist. That's good enough to drop Linux, right?
`also, someone claimed that a lead maintainer of the Linux kernel is a rape apologist. That's good enough to drop Linux, right?`
If that was proved to be the true, then I would want him or her to work on Linux from jail.
If that was proved to be the true, then I would want him or her to work on Linux from jail.
Doesn't that depend upon the project? What if I want to build for the App Store audience? Should I be shunned by the "community".
I don't like the idea of associating political views with technologies.
I don't like the idea of associating political views with technologies.
"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."
The problem is that it's used too often to shun or control people that don't agree with a political ideology. A good example of this is the Mozilla CEO.
An open and "accepting" community should also accept people they might not agree with..otherwise you should't call yourself open, accepting, or inclusive.
The problem is that it's used too often to shun or control people that don't agree with a political ideology. A good example of this is the Mozilla CEO.
An open and "accepting" community should also accept people they might not agree with..otherwise you should't call yourself open, accepting, or inclusive.
> An open and "accepting" community should also accept people they might not agree with..otherwise you should't call yourself open, accepting, or inclusive.
Being "accepting" does not imply being accepting of those who are themselves intolerant, and indeed the meaning and value of liberalism dissolves into something toothless and even dangerous when interpreted that way.
If the Russel's paradox aspect of this you bugs you, then label the position "accepting of all other beliefs except those which are themselves intolerant." In practice, this is what most liberals, even die-hard ones, subscribe to.
Being "accepting" does not imply being accepting of those who are themselves intolerant, and indeed the meaning and value of liberalism dissolves into something toothless and even dangerous when interpreted that way.
If the Russel's paradox aspect of this you bugs you, then label the position "accepting of all other beliefs except those which are themselves intolerant." In practice, this is what most liberals, even die-hard ones, subscribe to.
Nah, I think that you've still got to accept and engage with people who are intolerant of others--again, you yourself are a member of that group.
It's not usually a big deal if you are interacting in a strictly professional capacity: if they let their bigotry get in the way of good business and engineering and teamwork, you can drop them on those merits alone irrespective of their reasons for being subpar engineers or businessmen.
It's not usually a big deal if you are interacting in a strictly professional capacity: if they let their bigotry get in the way of good business and engineering and teamwork, you can drop them on those merits alone irrespective of their reasons for being subpar engineers or businessmen.
He was CTO for quite some time, so it appears people were OK with him making technical decisions.
Edit: Also, is there evidence that he was a vastly superior choice? I'd accept sufficiently advanced technology even from a wicked murderer.
Edit: Also, is there evidence that he was a vastly superior choice? I'd accept sufficiently advanced technology even from a wicked murderer.
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"
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"
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).
"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).
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.
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.
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.
"I'm willing to give up some valuable-thing-Y in exchange for more X" is a textbook example of a tradeoff.
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.
> 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.
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.
The guy that coined the word in the 1950s used the word in a negative sense. http://en.wikipedia.org/wiki/Meritocracy#Etymology
I must admit I never read the school book definition of the word - so yeah, maybe I'm not understanding meritocracy.
To me it means: The words/opinion of person with the most expertise on a certain topic should have the most weight in a discussion/decision.
In that sense I don't care about gender, skin color, religion, etc. as long as the person knows what he/she is talking about. So I don't see how it would be opposed to diversity or inclusiveness.
To me it means: The words/opinion of person with the most expertise on a certain topic should have the most weight in a discussion/decision.
In that sense I don't care about gender, skin color, religion, etc. as long as the person knows what he/she is talking about. So I don't see how it would be opposed to diversity or inclusiveness.
The idea that expertise matters is fine.
Where meritocracy gets bad isn't the "merit" part, it's the "-ocracy" bit - the idea that people who have the most merit get to call the shots.
It's problematic in all sorts of ways. First, who gets to define merit? Well, probably the meritocrats. If we assume they're rational agents (which we must, by definition), then they will choose to define merit in the most self-serving manner possible, in order to consolidate their own position, status, and power. And even if we don't assume they're perfectly rational agents (which is more likely, if contradictory to the basic idea behind meritocracy) we should still expect to see self-serving definitions of merit that grow organically out of everyone's bias for their own perspective. Consider the history of racial bias in IQ testing, for example.
Second, by the people who merit the highest in a meritocracy have different backgrounds, and therefore slightly different interests, from everyone who's lumped together in the lumpy part of the bell curve. This is inevitable - in a world where education costs money, you'll have a hard time getting to be the most educated at anything without coming from a position of relatively greater economic privilege than others. Pythagoras was no peasant, nor was Galileio or Newton or Einstein or Feynman. Therefore, we should not assume that they will make decisions in accord with the best interests of society as a whole. And their current circumstances are probably sharply different from most others' too. Probably the person who knows more than anyone else about investment banking is himself (I think we can safely assume it's a he - see below) an investment banker. That by no circumstances means that this person is the most fit to dictate investment banking regulation. It's true that he's got the expertise to draw up a set of rules that will encourage almost any outcome, but the outcome we should all be most worried about is the one where investment bankers get outlandishly wealthy at the expense of everyone else.
Finally, it's impressive how effectively people can use their pre-existing merit to influence others' ability to acquire merit. Often their ability to do so is so well-honed that they can wield it almost constantly without even realizing they're doing so. See: White men in academia, white men in fraternities, white men in software development, etc.
Where meritocracy gets bad isn't the "merit" part, it's the "-ocracy" bit - the idea that people who have the most merit get to call the shots.
It's problematic in all sorts of ways. First, who gets to define merit? Well, probably the meritocrats. If we assume they're rational agents (which we must, by definition), then they will choose to define merit in the most self-serving manner possible, in order to consolidate their own position, status, and power. And even if we don't assume they're perfectly rational agents (which is more likely, if contradictory to the basic idea behind meritocracy) we should still expect to see self-serving definitions of merit that grow organically out of everyone's bias for their own perspective. Consider the history of racial bias in IQ testing, for example.
Second, by the people who merit the highest in a meritocracy have different backgrounds, and therefore slightly different interests, from everyone who's lumped together in the lumpy part of the bell curve. This is inevitable - in a world where education costs money, you'll have a hard time getting to be the most educated at anything without coming from a position of relatively greater economic privilege than others. Pythagoras was no peasant, nor was Galileio or Newton or Einstein or Feynman. Therefore, we should not assume that they will make decisions in accord with the best interests of society as a whole. And their current circumstances are probably sharply different from most others' too. Probably the person who knows more than anyone else about investment banking is himself (I think we can safely assume it's a he - see below) an investment banker. That by no circumstances means that this person is the most fit to dictate investment banking regulation. It's true that he's got the expertise to draw up a set of rules that will encourage almost any outcome, but the outcome we should all be most worried about is the one where investment bankers get outlandishly wealthy at the expense of everyone else.
Finally, it's impressive how effectively people can use their pre-existing merit to influence others' ability to acquire merit. Often their ability to do so is so well-honed that they can wield it almost constantly without even realizing they're doing so. See: White men in academia, white men in fraternities, white men in software development, etc.
Ok, I see how this could turn bad. But what is the alternative?
In our current system people "run the show" who are good at politics and know how to use their elbows. In my books that's not any better than what you described.
In our current system people "run the show" who are good at politics and know how to use their elbows. In my books that's not any better than what you described.
The one recurring problem with meritocracy is that there is a strong danger of misdefining the measure of merit.
(In the case of discussions of the tech industry, a common error of this type is the equation of "success in the environment as it exists" with "merit", which makes the claim of meritocracy neatly circular, but its not the only way this can go wrong.)
(In the case of discussions of the tech industry, a common error of this type is the equation of "success in the environment as it exists" with "merit", which makes the claim of meritocracy neatly circular, but its not the only way this can go wrong.)
> "The words/opinion of person with the most expertise"
That's oligarchy, or a hair's breadth away, rather than a recent ideal of meritocracy. The problem is that it's all too easy for the "smart people" to become the ones who just run the show without consideration for others' ideas on their merit. That is, "meritocracy" as applied to individuals vs. their ideas can rapidly result in very different things. And it's not always so easy to distinguish between the two in the moment.
Part of the problem is that over the past few years, we're beginning to learn that our collective sense of who our experts are, who we do/don't listen to, is broken. Even those who would self-describe as being very meritocratic easily end up having massive blind spots based on gender, etc. So the bit about "inclusiveness, diversity, and respect" hits to the community trend towards efforts to acknowledge and deal with these problems.
That's oligarchy, or a hair's breadth away, rather than a recent ideal of meritocracy. The problem is that it's all too easy for the "smart people" to become the ones who just run the show without consideration for others' ideas on their merit. That is, "meritocracy" as applied to individuals vs. their ideas can rapidly result in very different things. And it's not always so easy to distinguish between the two in the moment.
Part of the problem is that over the past few years, we're beginning to learn that our collective sense of who our experts are, who we do/don't listen to, is broken. Even those who would self-describe as being very meritocratic easily end up having massive blind spots based on gender, etc. So the bit about "inclusiveness, diversity, and respect" hits to the community trend towards efforts to acknowledge and deal with these problems.
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.
The way I understand and use the word meritocracy is as an opposition to nepotism (or other forms of favoritism) - i.e. promoting people because of who they are (founders/first/oldest/high-born/...), not because of what they do, as in meritocracy. As such, I see/use "meritocracy" as something purely positive.
Meritocracy is good, but not when it creates a homogenous pool of points of view.
points of view aren't all equally valid. Example: any pov about something that can be factually checked.
Sure, but if you shut out people you'll never find out if they're valid or not.
What does that mean? I can generate an infinite amount of nonsense ideas. Or worse, a good amount of superficially-nice-sounding-but-terribly-flawed ideas. You can't consider every "point of view", if only from the fact that there's limited time.
[deleted]
"We value readable code over runtime performance."
There's a strange, delightful joy in finding that I agree with every statement here and in the original post/repo
I think that's a great idea-want to start us off with a pull request? :)
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.
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.
Really good points-Definitely will add some contrasts to help clarify. Feel free to submit a pull request with your ideas!
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.
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.
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.
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.
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.
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.
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
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
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.
The JVM boot time is a bummer, but beyond that, there's not much to complain about.
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.
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.
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.
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.
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.
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.
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.
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.
"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.
>- 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.
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.
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.
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.
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.
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.
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
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
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...
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...
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?
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.
Just Perl made string manipulation a lot easier then the standard shell. Also Perl got there first, which is slightly important.
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.
Do you have any experience with Python? IMHO I think python fits that niche better than ruby or perl.
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.
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.
Try the python 'sh' module (https://github.com/amoffat/sh). For example:
from sh import git
print git('version')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.
In Python, since functions can be defined anywhere, and decorators can execute arbitrary code (including registering and running the functions they decorate) and be passed variables from the scope they're used, you can make some pretty powerful DSLs. And method_missing delegation can largely be replaced by defining classes at runtime, especially now that people are getting used to passing hashes as arguments (in fact, Rails seems to be slowly deprecating find_by_foo_and_bar in favor of where(foo: _, bar: _)?).
Can you give reasons?
Python is installed by default on most linux distros, from my experience it is rare if ruby is pre-installed.
Python in my opinion is easier to write, and reading it is usually like reading plain english.
Python has a much larger community/ecosystem than ruby outside of web frameworks (rails kills django in popularity).
Python in my opinion is easier to write, and reading it is usually like reading plain english.
Python has a much larger community/ecosystem than ruby outside of web frameworks (rails kills django in popularity).
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.
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.
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.
Chef. Tungsten Replicator-a powerful infrastructure orchestration tool-is all Ruby.
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.
Some Linux distributions are not including Perl now.
Ruby is included in most major distros.
Thats what I use it for.
Ruby replaced Perl as my swiss-army chainsaw a long time 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.
> 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)
What are some examples?
I'll start with heavy number crunching (Go/C) and browser-based apps (JS)
Concurrency (Clojure, Erlang)
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.
There are also some great gems like Celluloid to help. That said, it's not the same as built-in concurrency.
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.
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...
http://madebymarket.com/blog/dev/ruby-web-benchmark-report.h...
I'm sorry, a hello world benchmark is meaningless.
For concurrency-testing-alone it might be not. If it works good at it, then it's a good indication that the concurrency model implemented in the language is not flawed and if there is a problem, then it might be somewhere else in the language.
So that benchmark it's still valuable information in the sense that tells you that that particular language running on that particular runtime its not intrinsically bad at concurrency.
In this particular case (JRuby) moreover, the language gets its concurrency layer thanks to Java, so I'd go really easy with that, unless you really want to say that Java is bad at concurrency or that this is not known and thus a "Hello World" example would not show it.
Which are both wrongly proven statements.
Nonetheless I must admit though that some of those combinations of runtime/server/frameworks are admittedly unstable to replicate or to work with in a real scenario.
So that benchmark it's still valuable information in the sense that tells you that that particular language running on that particular runtime its not intrinsically bad at concurrency.
In this particular case (JRuby) moreover, the language gets its concurrency layer thanks to Java, so I'd go really easy with that, unless you really want to say that Java is bad at concurrency or that this is not known and thus a "Hello World" example would not show it.
Which are both wrongly proven statements.
Nonetheless I must admit though that some of those combinations of runtime/server/frameworks are admittedly unstable to replicate or to work with in a real scenario.
I understand the Go hype, but what kind of "heavy number crunching" have you traditionally done with Go?
> 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
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
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...
Lend your two cents in the comments...
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?
But I don't like that it starts with a machine and code focus. Shouldn't people be first?
It's about taking our main tool as developers and making sure it works for us.
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.
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.
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.
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.
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.
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?
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.
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: