Where does Ruby go from here?
blog.sefindustries.com
blog.sefindustries.com
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."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'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.
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.
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.
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.
Edit: Also, is there evidence that he was a vastly superior choice? I'd accept sufficiently advanced technology even from a wicked murderer.
I don't like the idea of associating political views with technologies.
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?
If that was proved to be the true, then I would want him or her to work on Linux from jail.
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"
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.
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.
(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.)
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.
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.
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.
"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).
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'm willing to give up some valuable-thing-Y in exchange for more X" is a textbook example of a tradeoff.
"We value readable code over runtime performance."
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.
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.
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.
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
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.
The JVM boot time is a bummer, but beyond that, there's not much to complain about.
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.
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.
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.
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.
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
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...
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.
from sh import git
print git('version')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).
Just Perl made string manipulation a lot easier then the standard shell. Also Perl got there first, which is slightly important.
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.
What are some examples?
I'll start with heavy number crunching (Go/C) and browser-based apps (JS)
There are also some great gems like Celluloid to help. That said, it's not the same as built-in concurrency.
http://madebymarket.com/blog/dev/ruby-web-benchmark-report.h...
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.
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).
Lend your two cents in the comments...
But I don't like that it starts with a machine and code focus. Shouldn't people be first?
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.