Monday, April 21, 2014

Quote o' the day: If that's in my future I may be in trouble

A fortune I recently received:

If that tells me anything about my future, I think I want to stay now.

Saturday, April 19, 2014

Best of mcguire: ruthless simplicity

A few days ago, the article Boring Systems Build Badass Businesses appeared on Hacker News. In one comment, idlewan wrote, "It's not about the end result, it's about using better tools to get to it," arguing the case for specialized tools, in this case some CSS compiler. In response, mcguire wrote:

How old is your CSS compiler?

After gaining a fair amount of experience with various technologies over the years (by which I mean, getting burned (especially by things that seem wonderful and then cease to exist for a variety of reasons or change their nature drastically)), that has become the single most important question I ask about a new technology. If it's been around for ten years, it'll probably still be around in ten years. If it hasn't then it may not, especially in a form recognizable as related to today's.

C and Java are, well, not horrible, but not good. However, C has been C for my entire career. And I'm fairly sure that if I write something in simple, plain Java, in five or ten years when the whatzit needs some significant work then that work won't start with a complete rewrite.

(or at least he would have, if he'd bothered to reread and perhaps edit his comment.)

Faced with a response of, " long as you are satisfied with the current feature set, the code isn't going to disappear...I'll still be able to use it 5 years down the road...", he responded:

I was merely using the CSS compiler as an example. For something like that, just put a copy in your source repository and forget about it—in the worst case, it'll be fine for a couple of generations of browsers, until the "best current practices" have gone beyond deprecation. Hopefully, you won't mind throwing away your proto-CSS source at that point.

In the mean time, I'm sitting here looking at a JRuby on Rails application using JRuby 1.1.4 and a suitably ancient version of Rails (2.2, maybe?). This application has been in production for roughly five years and has received essentially no major love during that period; it Just WorkedTM. (Certainly a monument to the skill of the original author.) However, the poor sod who was responsible for it and our one other Rails application, our one and only Rails developer, finally managed to move on to other things.

At this point, security issues and (more likely) the inability to slather on new features have percolated up the chain of command and it has been agreed that Something Must Be Done. Since the upgrade path seems to recapitulate the phylogeny of Rails, our options are to rewrite the applications in a modern Rails and kick the can down the street, hoping it'll work better this time, or rewrite it using our common tools around here (and because I've got something to do with it, in the simplest manner possible). (And against the usual "never rewrite anything, ever" meme—which isn't an option—that project is going reasonably well.)

As for C, yes, it's feature set has been more-or-less frozen, which is good. It's environment is not. I was reasonably happy with the first version of gcc I used; call it 1.37 or so. Do you think you could use gcc 1.37 today?

* * * * *

Oh, and on a New York Times article on the death of Gabriel García Márquez, mcguire commented:

In his novels and stories, storms rage for years, flowers drift from the skies, tyrants survive for centuries, priests levitate and corpses fail to decompose. And, more plausibly, lovers rekindle their passion after a half-century apart."

"Less plausibly"! "Less plausibly"!

Geeze. Someone needs to teach these goobs to write.

But perhaps he's been reading too much Myles na gCopaleen lately.

Friday, April 18, 2014

Quote o' the day: pitfalls

...we do not yet have the perspective of sufficient time to get over the prejudices and fashionabilities that influence our everyday behavior. We also tend to discount or oversimplify historical, sociological, and psychological aspects. We are too operational and too win-lose oriented. We come out simplistic and opinionated.

Leland Allen, quoted in Polywater, by Felix Franks.

Wednesday, March 19, 2014

Quote o' the day: excessive?

Araq wrote on proggit,

Disclaimer: I'm nimrod's "one guy".

  • Nimrod is being dogfooded too, the compiler and all of its infrastructure are written in Nimrod.
  • Nimrod is not only me, we're 3-5 depending on how you count. It's true that I'm the BDFL and that there is no company behind it and getting paid for it would really help a lot.
  • What does it offer over Rust? Lots of things just like Rust offers quite a lot over Nimrod, but these comparisons will be more meaningful when both reached version 1.0. Short list: exceptions tracking, an effects system, typesafe bitflags, excessive compile time evaluation, a taint mode, and quite a different concurrency model. The latter took a long time to develop and its implementation in its infancy, but I'm mildly optimistic we found a good "worse is better" solution, which is safe enough in practice while still remaining quite simple.

I can't really argue with that.

Saturday, March 15, 2014

Link o' the day: A Note on Distributed Computing

I just had cause to look this up, and I had a devil of a time finding it.

"A Note on Distributed Computing", Jim Waldo, Geoff Wyant, Ann Wollrath, and Sam Kendall. SMLI TR-94-29, Sun Microsystems Laboratories, Inc., Nov. 1994.

We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure....

We conclude by discussing what is required of both systems-level and application-level programmers and designers if one is to take distribution seriously.

This is one of the most important papers in network protocol history, and one that nobody seems to have read.