41–50 of 93 posts
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 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 framew…
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 exclus…
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"
Lend your two cents in the comments...
> 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)
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.
http://madebymarket.com/blog/dev/ruby-web-benchmark-report.h...
Earlier quoted context omitted.
> 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.
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.
Earlier quoted context omitted.
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 wa…
from sh import git
print git('version')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…
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.
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?
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.
Earlier quoted context omitted.
Do you have any experience with Python? IMHO I think python fits that niche better than ruby or perl.
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 a…
But I don't like that it starts with a machine and code focus. Shouldn't people be first?