davesims

But the computer and its physical state has no meaning unless the output is perceived (paging Berkeley). That meaning to the user or coder is more than a function of the position of electrons in silicon, but also, and I would argue primarily, in the meaning conveyed to the subject/user/coder. Certainly there is no meaning without physicality, but physicality without subjectivity is literally meaningless, and that subjectivity brings with it analogies and more content than can possibly be found in a pure reduction to electrons.

I think if we look hard at the structure of CPU instruction sets, GPUs, math coprocessors and the like, we'll see even at the lowest level attempts to present analogies and manage the limits of pure logic as presented to a human consciousness. So even at the lowest level of CPUs, the language of analogy is present, and that implies that a human subject is going to supply the content "between the electrons" as it were.

I've been thinking about this quite a bit myself lately (mostly due to the excellent ongoing discussion Steve Klabnik started here https://groups.google.com/forum/?fromgroups#!forum/philosoph...).

It seems to me a philosophy of code that begins at the "low" level of binary and machine instructions, would ultimately reduce to a contemporary British/American Analytic style of philosophy to the exclusion of all else, seeing as how the core level of communication is binary -- logic, to the exclusion of rhetoric, in the classical sense of both of those disciplines.

If you take a logic class at a basic level in both a Philosophy and CS context (as I did), you'll be struck by the massive overlap -- DeMorgan's theorem, modus ponens, et. al.

Setting aside for the moment the possibility of alternate CS architectures (neural nets, quantum computing and so forth), this would seem at first blush to limit the relationship of all computer languages to a 1:1 relationship with logic.

However this "reductionist" (foundationalist?) approach to finding a true semiotics of CS may not tell the whole story. As we move from the "low" level to the "high", say from the domain of machine code all the way up to, for instance, a rich, expressive Ruby DSL, the question arises, as it does for all language: have we acquired a surplus of content that cannot be simply reduced to core rules? At this point things get less Wittgensteinian and a little more late-Heideggerian, i.e., less analytic and more eidetic/phenomenological.

To remove the fuzziness from this notion, think of how, for instance, a first-person shooter creates the illusion of a smooth, analog reality from a rigid, frame-by-frame progression (as cinema does as well -- and this question has been explored at length in that world). As humans interacting with the result of the code, we infer content between the frames -- we make up the difference and experience the virtual world presented to our senses as continuous analogical rather than chopped-up and merely logical. Code never exists in a vacuum -- it is experienced by humans and humans bring meaning to it, as much as it brings meaning to them.

There's a similar phenomena in OOP, where the meaning of the code is not merely the sum of its final binary product ("true" or "false") in the world of machine instructions, but in the metaphor it presents as a model of an object or event in the world. This code is constantly changing (literally) as it intends towards richer analogies with the world, and we as coders (and users) make up the difference by bringing real-world experience to it when we "read" the code. In other words, code is never "true" or "false" as a function of its binary reduction, but is a constantly-changing artifact of some human being's attempt to analogize the world, read by other human beings attempting to understand and refine that analogy.

In this sense the general problem is, as another poster phrased it so well, semiotic rather than epistemic or even logical. But I'm not sure a "closing over" or reducing towards core CS mathematics helps us understand the ontological status of code, any more than Wittgenstein or the Vienna School has given us a salutary reform of philosophical discourse with pure analytical techniques in search of a perfect, ambiguity-free symbolic language.

Language of any kind acquires a surplus of meaning as human beings interact with it and bring their own analogies to the experience, and I think this applies to code as well. So it may be that it's OK to move towards a philosophy of code that takes a phenomenological approach to the final product -- the code itself -- rather than (or probably in addition to) looking for meaning in the binary rules that compose machine instructions.

OP writes:

>> With this in place we can make certain classifications (in a quais-aristotelian manner): functional languages, object-oriented languages, etc. And perhaps be radically more precise and classificatory than this with key properties serving to increase resolution (run-time-modification of objects, “RMO”: javascript, OO-RMO-HOF-…).

The problem I see with this is that most of these languages are hybrids -- I can do OOP in Clojure and functional in Ruby and prototypal-fuctional-oop in JavaScript, etc. So, to me, again, as in language itself, I prefer an ontology rooted in immediate experience of particular code. Categorization of an Aristotelian type can be very helpful, but like all reductions, it can hide as much as it reveals.

What I would advocate in a philosophy of code is multiple starting places moving towards each other: acknowledging and exploring the rigorous logic implied by the core rules of logic gates (flip-flops made of silicon and so forth), the richer semantics of language structures (the Aristotelian categories of Functional, OOP, Structured, Prototypal), and a Phenomenological approach to particular code (what does this class/method/function suggest as an analogy to the real world?).

If Mosaic had a current version with a rendering engine and enclosing feature set as competitive as the current Opera is vs. Chrome and FF, yeah I might. But, as I said, I don't even use Opera right now, only because FireFox's add-on ecosystem makes it the better choice. But otherwise Opera is still a competitive, high-performing browser, and completely reasonable choice for the discriminating nerd.

I never used IE. Because...IE.

Would you hypothetically not use a fast, super-compliant, feature-rich Mosaic out of an irrational bias?

Everything I like about FireFox (gestures, tabbed browsing, a reasonable bookmark manager), Opera did first. I used Opera for years back when it flat killed Netscape and IE for features and standards compliance. I only left once FireFox implemented all of the same features I had come to rely on in Opera, PLUS developing its growing add-on ecosystem.

Gimmicky? Marginal? Not in the least. Sure, Opera, as a foreign, small, scrappy little software company wasn't able to knock off the behemoths of MSIE, Google/Chrome and Netscape-cum-Mozilla. But so what? The fact that they've been ahead of the feature curve as long as they have and are still in the fight is, to me, pretty dang amazing and quietly one of the most surprising stories in software in the last 15 years.

I've always been a fan of that resilient little Norwegian shop, and I'm sorry to see them (or, more than likely, their lawyers) get dragged into the unseemly world of lawsuits and recrimination. Hopefully this will resolve itself more amicably than it has started.

EDIT: I don't mean to be snarky or mean, but this bit made me SOL (snort out loud):

  "..another slightly incompatible rendering engine?"

Opera's earliest claim to fame, back in the godawful days of the real incompatibility wars, was its near-religious adherence to W3 standards. A lot of web developers in the late nineties/early oughts would use Opera as the benchmark browser, and then resolve various quirks-mode issues from there. If it worked in Opera, you could be reasonable sure the problem wasn't with your code, but with a quirk that you were about to have to fork your code on, for Netscape or IE.

For me this was the 'tl;dr' quote:

"It would be absurd to think that governments never have to worry about their level of indebtedness. The aim of our paper was much more narrowly focused. We show that, contrary to R&R, there is no definitive threshold for the public debt/GDP ratio, beyond which countries will invariably suffer a major decline in GDP growth."

Your attempt to drive developers to Ruby and Rails by playing the role of a typical ignorant anti-rails fundamentalist crusader will fail.

I agree that I probably wouldn't go with Fender low-end (they are crap), but there's plenty of good bargains in the 300-400 range that won't frustrate a beginner. There's probably 4 or 5 Epiphone, Seagull, Alvarez or Ibanez low/mid-range guitars hanging up at your local pawn/small guitar shop right now. Even some old Harmonys, Kays or Silvertones can work out real well, depending on the guitar. My favorite acoustic to play right now is my '53 Kay arch top that I picked up for $400.

I'm just burnt out on that sound. To my ears they lack personality and expressiveness. They have a full sound, they're radio-friendly and they "play like an electric!" so I get why they're so popular and why so many new guitarists walk out of Guitar Center with one, but to me they're the Yellow Tail Shiraz of acoustic guitars.

'you make a big investment (upwards of $2000) and it motivates you not to give up'

I've been playing semi-pro for quite a while, and In My Opinion, this is just as likely to fail as help. Also, I've never owned a guitar that cost more than 700 (except my Tom Anderson Tele which I inherited). And I have a lot of guitars and play quite a bit.

I've seen guys do that -- buy a really expensive Taylor or Larivee or some Guitar Center Shiny and then stare at it with guilt for the next five years, unable to part with it and admit defeat, nor pick it up and practice because it reminds them how much time they've wasted not working with this beautiful neglected instrument.

My advice: buy a serviceable, good acoustic. Find a real musician friend if you have one, a real guitar nut and take him/her to the pawn shops, and as a last resort even Guitar Center (LAST resort) and have him pick something out for you. And stay under 600 bucks for the love of God.

Then a year or two later, when you've decided that you love this guitar thing and want to get serious, you'll spend that 2K+ far, far better -- you'll know to avoid the glossy Taylor-ish nonsense and get a nice LG-1 or LG-2 (I've seen 60s models pop up at pawns shops for < 1500$, seriously twice in the last year) or a nice 70s Martin with creamy-sparkly high ends, warm and well-defined lows, and a gorgeous, aged-in finish that you will sit and stare at with pride for the next 25 years.

With the ability to add static methods and default implementations to an interface, what is now the practical difference between that and an abstract class?

I take it back - I had issues with escaping on irb but not in the app itself. Something new to learn...

No problem, in ruby style is always pretty subjective since there's a thousand ways to do just about everything.

And, just FYI you do need to escape the backrefs or use single quotes, like:

  "\\1<span class=\"nurble\">nurble</span>\\2"

The inevitable ruby style niggling, feel free to ignore: personally I like something a little more concise and inlined, some parts seem to have used more verbose idioms, (like Regexp.new instead of a literal), and also I think you need to escape the backreferences or use single quotes, something like:

  (words - @@nouns).each do |w|
      text.gsub!(/(\b)#{w}(\b)/i, '\1<span class="nurble">nurble</span>\2')
  end

EDIT: oops, backslash. Also, in the example, line 19, where you have 'sub', don't you mean 'pattern'?

Ah, got it. Humor achievement unlocked.

> I work for Microsoft because I really like their web products.

Cool! Good to have gigs we like.

> "step 1. buy a mac". Is that really more enabling to the 2nd and 3rd world developers Jeff mentions?

Eh. Linux is just fine for Rails dev. The Mac thing is mostly a hold-over from earlier days when TextMate was the default editor, and because most Rails shops expect it. In fact one of the most "enabling" scenarios here is to take a cheap, lightweight Ubuntu dev laptop and ssh into a dedicated development server, do all your editing on vim or emacs.

> I also listed some reasons that C# is not really a non-starter for open source.

Yeah, but it's a hard sell is it not? When considering tech stacks to risk your entire project's future on, what's the practical difference between "Not Really A Non-Starter" and "Really, Really a Non-Starter"? Not much.

Are you trying to say that both node and C# are better open source options than Ruby? Or rather that node is better and C# is not as bad as Jeff says?

Either way -- to say that C# would be a better platform for developing an open source project is far-fetched at least (the developments of the last year notwithstanding, although agreed that MS has come light years in that direction from where it was just a short while ago), and to say node would be better is, well, not uncontroversial.

I understand, given your position, this is a point of view you must advocate (although...node? really?), but neither point makes Jeff's rationale anywhere near "all wrong."

Agreed re: SQL Server vs., say, postgres. I'm actually not sure why we don't see that option (ASP MVC + postgres/mysql) a lot more often than we do.

I've been meaning to learn vim for years now. I started a month ago knowing basically how to fudge my way around with arrow keys and save with :w, and that's it. A couple of peepcode screencasts, a bit of daily 5 minute practice on shortcutfoo.com, and a month of pretty disciplined day-to-day coding later and I'm basically back to where I was on TextMate. I'm even using a tmux/vim setup for most of my Android coding, occasionally tabbing back into IntelliJ IDEA if I have to do any heavy refactoring, and even then I have a vim plugin going there.

Is it better? I dunno, hard to say. I like it. I like the tmux-vim combination and it's been a good challenge that's kept my brain engaged.

Now, I have a ton to learn, and that's awesome. But I'm at the point where I'm really comfortable making all of my changes in a vim context, without constant finger stuttering and 3 second pauses like I was doing 3 weeks ago. And it certainly didn't take me 2 years. That's nuts. Maybe 5 years ago before there were so many screencasts, tutorials and practice sites, it may have taken that long. But even then I think any disciplined coder could get up to a moderate proficiency with some daily practice, in a few weeks or months, not years.

This is an old warhorse of a debate that hardly seems worthy of HN, nevertheless here is the conventional wisdom restated: vim vs. idea vs. TM/ST is a question of taste and personal developer happiness, not proven productivity. I know great coders who swear by (EMacs/Vim/IntelliJ/Eclipse/SublimeText) to the exclusion of all others. None of it matters. Was it Knuth who said, "all editor wars lead to madness and early optimization", or something to that effect?

If you're coding mindlessly doesn't that by definition mean you've bypassed your brain?

The top story on HN as of this comment is a Slate article debunking the bacteria claim, validating not only the newsworthiness of the original story, but also highlighting the full-arc drama HNers got to follow by seeing both stories featured prominently on the front page.

On the other hand, let's consider scenarios where your concern might be totally valid -- say, if the same article was simply link-bait to a spammer's penny stock advertisement. In that case the article might pop fast to the top of HN, but likely just as quickly flagged and removed. So, flagging of articles that are crass advertising, flaming link-bait or just plain inappropriate for HN is the remedy there.

The question is -- is there a case where a story is appropriate for HN and not likely to get flagged, but also is not nearly as worthy or compelling as the title suggests?

I'm having a hard time coming up with that scenario, but in true HN-form I'm willing to be corrected. While I disagree with your statement that "It would be a very interesting result IF it were confirmed to be true," (and that seems to be the emerging consensus), I pose the question back to you and HNers -- what would be the scenario where reading the comments prior to upvoting would help improve the quality of story on HN page one, where flagging is also not the appropriate remedy?

This is certainly the dominant perception coming out of SV these days. But since the vast majority of startups fail and have no more time (or rather, will) to collect development metrics than they do to implement TDD, I doubt we'll ever have any kind of real validation of this perception.

I suspect it comes from a combination of a) young coders more likely to find themselves at a startup, who are also more likely not to have developed TDD habits and 2) VCs, angels and the like who, while well-intentioned, likely push this notion that TDD is for "mature" companies and/or, "we'll pay that off later, just get the code out the door." Young CEOs, CTOs, founders and the like who need to validate all of their startups' initiatives and practices probably are swimming upstream if they want to go TDD from the ground up.

For some instances of prototyping and lightweight apps (like Obie mentioned), this is probably fine. In my experience though, the short term effects of playing "shipping" against "craft/testing" settle in within a matter of days and weeks, not months and years, and the mid-term effects of technical debt when a startup moves into "mature" phase (again, a much shorter time span than anyone realizes) are such that the idea of "debt" and "what are we going to do about it" becomes a/the dominant conversation on the team. I've experienced both sides.

My perspective: the cost of TDD is mainly to young coders who need to learn it and find the curve daunting. Teams built around these type of otherwise talented devs really would incur significant up-front cost to booting up a CI/Test server and getting past the curve to the point where the team is moving at a comfortable pace, comparable to where they were before implementing TDD. In this case, TDD is a very hard sell. I don't know how to solve that problem, other than changing the SV/startup culture to the point where those holding the purse strings see the benefits of craft/testing as being as attainable in the mid-to-short term as they are in the long term (and in my experience, they absolutely are).

If you have buy-in to TDD/craft (I can't really separate the two in my mind) from the top-down, and you have experienced coders that can facilitate implementing, in my opinion it's absolutely worth pursuing. The second-order effects of a culture built on these principles kick in with a vengeance right when a startup needs it: at crucial pivot points.

When you have to change your business assumptions quickly -- and this usually happens weeks or months into the starup lifecycle -- would you rather do it on a codebase where, say, your authentication/authorization and user model was tightly coupled to other concerns or not? Would you rather know with a relative degree of confidence that the changes you're making are not breaking core concerns? Wouldn't you rather do this quickly, rather than thrash around in unclear code that you'd rather just rewrite (you know, like it felt when we started!)?

And if you're pivoting, are you not more likely to be less cash-rich, under more pressure and in need of some really good success right now, since pivoting probably implies that former assumptions did not pan out the way you'd hoped? Isn't that exactly the point where you'd like to both reuse the code you need and know that things are still working around your baseline assumptions that seemed so clear a few short weeks/months ago?

I would think at this point the benefits to a startup in this mode, of a clean, fast-moving and validated codebase, of the kind that good TDD tends to produce, should be patently freaking obvious. Just my opinion.

Funny, I had a comment ready before Matt's that started "I can only speak from my experience..."

So, yeah...in my experience this has played out exactly so: in practice, coders who ignore TDD are probably also ignoring a lot of other good practices. The two principles may be "orthogonal" in theory, but the correlation has strong anecdotal support for me.

You've said in a much more concise way what I took far longer with upstream. I can only beg off that I think my coding practices are better in this regard. :)

A few years ago this comment would have made me facepalm, bang my head on the corner of my bulky CRT monitor and look for the nearest ice pick to stab through my eardrums. Kind of like I did when I read the transcript of Joel and Jeff's reaction to Uncle Bob and SOLID.

These days it just makes me sad, for two reasons and not (probably) the ones you think. It makes me sad mainly because, well, in a LOT of ways you're not wrong. You can live (and live, and live) in a comfortable bubble between the time a new codebase is started and the time technical debt settles in and makes new features of nearly any kind far more expensive than they're worth, for an entire career. You can deliver a lot of software that way.

You can also develop some pretty good habits (as they did in the days before TDD frameworks) around manual testing and general experience, that mitigates the onset of technical debt and bad architectures. The further down that path you go, the better you get and the more successful projects you complete, the less TDD will seem like a Good Idea, and more like, as you put it, someone trying to "sell a religion."

I've been in the industry 15 years, and I've worked with a lot of guys like that think like this and gone a long way down that path. Probably like you. Some really, really smart guys that I've learned from and admired. Some of the smartest coders I've worked with. They had unreal IQs and analytical strengths that always knocked me out. They could crank out features very, very fast.

And they wrote some of the worst code I've ever seen. Not dumb code. Bad code. Awful. A trail of debt to make the heart sink and the eyes roll back: long, 300-600 line methods, inlined sorting algorithms because maybe they thought built-in Hash's search was slower than they could write themselves. Early denormalization. Unclear intentions, poorly named methods, and (here's the overall characteristic): non-idiomatic code. Code that doesn't follow conventions, code that is hard to read, impossible to reuse, obviously unclear in its original intent, and therefore brittle, brittle, brittle.

The business consequences in specific instances were more than tangible. Six weeks for a refactoring here. Months added to timelines for new features there. Features actually abandoned. Millions in revenue lost.

There has been an uncanny relationship between these kinds of coders and a common theme of resistance to the following ideas: TDD, SOLID, Design Patterns. The same guys who leave a trail of maddening debt (all the faster because they also tended to be some of the smartest coders on the team), also tended to have a deep suspicion of "high level" thinking, frameworks, big-picture conventions. And always, always, the same old red herring, false dichotomy you present here: "Do you want to ship code or write elegant, well-tested code?" As if the two were opposed. As if the two weren't actually directly related.

Here's the thing: they had a point. The inverse errors -- over-architected, over-tested, over-thought code can be just as crazy-making. Some junior dev who just read Design Patterns in 2005 and thought they'd Seen the Light and starts spraying Bridge Patterns all over the codebase was just as bad as the aforementioned analytical, structured-code debt machines.

I can only go on what I know, and here's what I know: without exception every guy I've worked with that thought this way -- suspicious of TDD, plays "shipping" against "tested/craftsmanship" -- also created code that in the mid-to-long term cost the company far more money than they apparently saved by "shipping fast" and writing untested, unclear code.

The most frustrating thing to me about this is that, once you integrate these practices -- TDD, patterns, SOLID -- into your workflow, once you master them, they cost nothing in terms of time spent. You get practical about it, use it judiciously where it makes sense, don't use it where it's unnecessary and (like a lot of the Design Pattern stuffs) ignore it altogether. But you can only do this if you can see both sides, and you can only see both sides if you've mastered the practices. I spend much less time writing tested code than I would without it. I spend much less time managing well-designed codebases than I would thrashing around in a tangled mess.

It's like learning Vim enough to get proficient. You have to commit to it. Then you get pragmatic about it, learn its strengths and weaknesses and over time get to know the real benefits. But you have to have that willingness to commit to it up front and anticipate the benefits down the line.

And as an aside, in my 15 years, the great coders I've worked with (a few name-drop-worthy dudes in the mix) have, without exception, been committed to a pragmatic, healthy approach to TDD that was neither religious nor slow, and in fact made the entire team faster, the codebase more robust and the software far more shippable.

And while I have run into a lot of guys who have never written a single test - much less mastered TDD to the point of being able to speak intelligently about the pros and cons from a standpoint of actual experience - declare loudly and confidently that TDD is "religious" ("snake oil" is another favorite) and "feel free to ignore", I have never run into an experienced coder who has integrated TDD into their workflow in a credible way, who actually can speak to both sides of the argument say the same thing.

I got addicted to left-pane treeview bookmarks waaay back in my Opera days, imported into FF, still waiting on Chrome (sheesh). But at this point I doubt it would make a difference since the performance advantage has been pretty much erased. FF is fine -- what is Chrome's real advantage these days? Honest question...

And there's still not even a decent extension that does it, which seems really odd to me. Anyone know of one (left pane bookmarks that is)?

"Say, you want to design a protocol with reliable delivery and/or loss detection. You will then have ACKs, send window and retransmissions."

Maybe I'm missing something (likely) but it seems to me any potential replacement for UDP specifically doesn't care about packet loss, acks, etc. The whole point of UDP is speed over reliability, yes?

One way to lose the late-nineties/early-oughts associations with Yahoo: kill the toolbar once and for all. Who uses those things? Is that really a revenue-generator for them? And if so, at what cost to their image as a holdover from a bygone era?

That's fantastic. I use IntelliJ for Android stuff, installing now. They should add a 'Duck' mode that just brings up a big picture of the rubber duck.

A few times a month, I'll look up at one of my colleagues and say, "hey, got a sec? I need to talk to the duck," and they know this means I'm going to talk to their head but they can basically keep doing what they're doing and nod occasionally.

This serves several purposes:

(1) It's less insane-sounding than actually talking to an inanimate object in an open work environment.

(2) It actually feels better and forces me to think more clearly when I'm talking to an actual person -- the cognitive focus is higher when the object of conversation can actually, in theory, think and talk back (YMMV).

(3) And finally, although it does require some focus on the part of the other coder, it's not nearly as taxing to them as actually helping me solve the problem or pairing up with me.

So it's a good compromise somewhere between pair programming and talking to an actual rubber duck. Again, YMMV. Maybe I'll call it "Pair Ducking."

Heh -- stick around, kid. :) Those shiny new greenfield codebases, so full of promise, perfect architectures and unfettered extensibility, can turn into slow-moving, spaghetti-code Leviathans in a matter of weeks. It's not just the decades-old, massive LOC codbases that provoke this dichotomy: chances are very good that the code you're working on right now, that gorgeous, sleek, sexy code -- will be staring at you with its cold, incomprehensible dead eyes within the year, asking you how, how did it come to this, how did you neglect me so, and why do you hate me now?

OK, or maybe not. But it can happen, and it does, all the time, in really good shops with very experienced coders using all the right techniques and best intentions. I know. Dear God, I know.

Of course anyone would rather bootstrap new code and feel the thrill of new object models, shiny, hip new libraries breezing through their editors. But until you've experienced both sides of the equation, the long-term consequences of technical debt growing through a codebase like some kind of...virus...you'll not know how important the second-order effects of refactoring, TDD, and truly clean code really are.

The problem is that in cases like these, invariably the old, crappy code contains documentation and functionality that will never be reproduced by a ground-up re-write. Understanding the old code and rewriting is, in general, just as expensive as refactoring. This is the common dilemma with old codebases like this -- in spite of its horrible, unreadable state, it contains business knowledge too valuable to lose.

As far as making the code "look nice" -- you've missed the point. The goal is to make it functional, readable and extensible again, and doing that to a 1M+ line codebase (which I've had to do) can be enormously rewarding, the business value gained more than tangible.