31–40 of 93 posts
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.
Meritocracy is good, but not when it creates a homogenous pool of points of view.
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?
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.
The guy that coined the word in the 1950s used the word in a negative sense. http://en.wikipedia.org/wiki/Meritocracy#Etymology
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.
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…
> 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.
Earlier quoted context omitted.
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.
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 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…
> 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.
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…
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…
"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).