Goto and the folly of dogma (2018) - <AUTHOR> https://manybutfinite.com/post/goto-and-the-folly-of-dogma/ <comment><USER2> Over my first five years of professional programming, I've been thirstily chasing the dragon of "perfect description". Early on I thought it was OOP. Then entity/component. Then FP. Then it was _really_ about the type system.

Possibly the biggest lesson I've learned - both from the kiln of real-world project requirements (within a multi-paradigm language) and from my intentional ventures into other different and diverse programming languages and frameworks - is that there's no such thing. There's no perfect way of describing, not within a domain and certainly not across them. It's not just a matter of abstracting farther and farther from real-world concerns, sacrificing optimization until you're in descriptive nirvana. There are many good ways to describe a given thing in code, and there are many more bad ways, but there's no perfect way. Once I grasped that I became a much better (and less stressed) programmer.

<comment><USER3> Yes definitely. The essence is finding the right abstraction. The computer doesn't care if you get this wrong, and the code could work perfectly, but it can be a pain to maintain something if something is abstracted the wrong way. And aiming to reduce the file size of your source files by "Don't Repeat Yourself" isn't the necessarily always the best way to make code maintainable. I've breathed a sigh of relief when I saw a code base that was your usual scaffolded MVC app rather than something with a tonne of metaprogramming. I've seen both, and the Keep It Simple principle has some merit.

Infact the best abstraction may depend on the team who will be maintaining that code - so whether to use Tech A or B or Pattern X or Y might have, as an important factor, whether you are moving office from one city to another, and whether the job market is good or bad, affecting flow of people in or out of the company etc.

</comment></comment><comment><USER4> I feel like engraving this paragraph in a wall:

 _Taboos tend to accrete over time. For example, overzealous object-oriented design has produced a lot of lasagna code (too many layers) and a tendency towards overly complex designs. Chasing semantic markup purity, we sometimes resorted to hideous and even unreliable CSS hacks when much simpler solutions were available in HTML. Now, with microservices, people sometimes break up a trivial app into a hard-to-follow spiderweb of components. Again, these are cases of people taking a valuable guideline for an end in itself. Always keep a hard-nosed pragmatic aim at the real goals: simplicity, clarity, generality._

From Java's "AbstractFactoryBuilderDelegator" insanity to "nanoservices", the common thread to me seems to be overzealous decoupling, to the point where I need to look in 10 different locations just to find out what happens during a single request.

<comment><USER5> When you get more experienced most of these things make me laugh or cry (depending on the siuation); it does not matter what companies like FB, Google do; people on HN or Reddit will take it and do it to the extreme: we now 'need to' use React for everything; if it does not fit, just beat it with a hammer until it does. Kubernetes and microservices must be used for every tiny little part if the app even if it causes a lot more overhead in performance/memory use (computers are cheap and fast!) or debugging. Abstract almost everything! (Java + OOP, Javascript and the npm mess) to Abstract almost nothing! (Go w/o generics), Make everything reusable (left-pad), Rewrite everything in JS!, Rust!, Go! etc etc. Everyone is running after eachother and doing it more extreme and the end result is just as shit as if you would not have done that at all and just thought about it bit before opening some IDE and codegenerate you million lines of boilerplate with the instable and slow framework-du-jour. As an older coder I sigh when a codebase is taken out of the 'mothballs' even 6-12 months after creation and people cannot get it running because everything they used is outdated because the framework and library authors move fast and break everything all the time. And ofcourse it is in an outdated language / framework(Ruby on Rails is soooo pase) so noone knows anything , it uses the 358 most popular DSLs (350 unmaintained since january) at the time so unless you drank the same coolaid it is a nightmare spelonking adventure.

At least Dijkstra had sound mathematical reasoning for his arguments and wrote about them eloquently (and with good humor I may add); most of what is peddled in the hipster coding circles is a smooth talk by a gifted social media frontman that has no solid basis in anything besides that the person is popular. I do not even understand how people dare to put their name on complete messes like npm or one line npm packages unless it is a joke. I assume things like leftpad are in fact a joke; if they are not I would have to cry myself to sleep every night. So I just lie and say it is funny.

Only when someone codes something without any of that and it gets popular or makes a lot of money, people come with 'it was best for this occassion'. The best example I can think off being anything Arther Whitney (k/kbd+) does; his softare makes a ton of money, it is faster, smaller and, in my opinion, easier to debug and uses less resources than most things I have ever seen passing here (including what people call embedded; no people, something with a gig of memory is not emdedded) and yet it pukes over almost all rules and styleguides that everyone loves so much. Not to mention: he does something a lot of programmers are jealous off (including me); he makes money with a programming language and is always used here as a counter example when people shout that programming languages that are not opensource and/or are commercial (even very costly) do not work.

I wanted to write one sentence; it became slightly more, but I guess most of it is on topic.

<comment><USER6> I'm probably going to take a lot of heat from all the young whippersnappers out there for this, but I absolutely love your comment about React. I'm going to save it. It totally describes my experiences with other developers. They want to use React to re-write major portions of our codebase that work perfectly well as is, just because React is super awesome! Can you guess how many of our customers have complained that our website isn't a single page application? I'll give you a hint, it's less than one. The devs will also make little teeny projects that would take less than an hour to write in Vanilla JS and make this big 20 hour development project that has a monolithic codebase that all the sudden needs routers and back button integration and url mangling and gigantic switch statements to draw the correct "page." Oh and don't forget you have to set up all that webpack and and compiling routines so that you can compile all that garbage into other garbage. And then you also have to do that build over and over again for every change. This is JavaScript. Script is in the name. It's not meant to be a compiled language. And contrary to our dev's beliefs, React does not run or draw faster than Vanilla JS, unless you are constantly redrawing the whole page in Vanilla JS, which no one does. I hate React.

<comment><USER7> In the United States the management layer doesn't have a clue so if you don't keep up on React, GraphQL, etc etc - you're seen as a curmudgeon.

They're not the ones learning it but they're still attending all of the conferences for it and with a non-practiced engineering capability they're back to cargo cult BS.

Best to keep learning the new hotness or it's career suicide. Just remember, for almost any 9-5 it's about the _narrative_ of work more than it is about the work. Rewriting/changing huge portions of your already-working tech stack is job security. I truly believe a huge portion of engineers engage in their own "make-work" to justify their existence/paycheck.

<comment><USER5> Keeping up with something does not imply showhorning it into using it everywhere but I agree with you.

</comment></comment></comment></comment></comment><comment><USER8> I was surprised by the number of gotos in the Python runtime. The link in the article was down so here:

[https://github.com/python/cpython/search?q=goto](https://github.com/python/cpython/search?q=goto)

There's a lot of "goto exit" which is obviously a CPython runtime convention - fair enough. However there's plenty of classically bad code, example:

[https://gist.github.com/ridiculousfish/ffe4fa2a17c831ed06e57...](https://gist.github.com/ridiculousfish/ffe4fa2a17c831ed06e57cfb2c467b25)

These are old-school-bad gotos: `if` statements would do the job more clearly. Is this a broken-window phenomenon: one planted `goto` opens the door for the rest? Or is there a deeper motivation for this style?

<comment><USER9> This feels less like 'folly of dogma' and more like these (C/C#) programming languages don't have the constructs to safely and properly express what the programmer is trying to do. 'goto exit' is an unsafe and dangerous version of Rust's '?' operator.

> We should be willing to break generic rules when the circumstances call for > it. Keep it simple.

I argue we should instead iterate on the programming language design to make sure we don't need to make these kinds of trade-offs.

<comment><USER8> C++ has solid "cleanup" constructs so I wonder why CPython is in C instead of C++. Is it portability, compilation speed, complexity control, transition cost, something else...

<comment><USER10> All of those, but also python came out in 1991 when C++ was still in its infancy. Even if C++ had been mature though C is still a better choice, python is often embedded in other programs and doing that with C has a lot fewer headaches (simpler linking, better compiler support)

</comment></comment></comment></comment><comment><USER11> Dogma is a real problem in this industry. When OO came up suddenly everything had to be objects. So instead of writing

A=add(B,C)

You had to write

Adder AA; A=AA.Add(B,C)

I remember endless discussions about this and people always argued that functions are not OO whereas I said OO is about state so no OO needed for adding two numbers.

Same with goto. In FORTRAN it was an essential tool but suddenly it became illegal and you had to write complex if statements and other things just to get the same effect.

I guess software is so complex that it's very to always understand all drawbacks and advantages of something so you have to live by a set of rules that usually work and follow them blindly.

<comment><USER12> > Adder AA; A=AA.Add(B,C)

Did anyone actually ever do that or is this just a huge red herring?

Also, the above looks more like a data flow language where adders are necessarily components in the wiring diagram (try building a CPU without adders!).

Add can be a virtual method on B (so B.add(C)), but then you really want Dylan-esque multidispatch on both B and C. But those kind of debates fell out of style with the 90s.

<comment><USER13> Borland C++ windows toolkit back in the early nineties would do that sort of thing, if memory serves.

Really deeply convoluted OO.

<comment><USER14> And way better than MFC or ATL ever were.

</comment></comment></comment></comment><comment><USER15> This rant kind of has it backwards, and Dijkstra's argument against GOTO has been the victim of its own success. The use of GOTO statements he was critiquing doesn't really exist in the wild anymore, so people see the tamed version of GOTO we use to break out of nested loops and so on, and wonder what the big deal was.

It's almost like an anti-vax argument. "This disease doesn't exist anymore, why are we cargo-culting by vaccinating against it?"

The argument in the original rant was about the limits of our ability to reason about code, and remains a deep and useful insight. The fact that we don't really have examples of non-structured codebases to point to in 2019 shows how essential the invention of it was to our work.

<comment><USER16> GOTO is an easy target due to its cultural notoriety (regardless of how it actually looked in the past), but the overarching argument is indeed against dogma. To quote Donald Knuth:

"In the late 1960's we witnessed a "software crisis", which many people thought was paradoxical because programming was supposed to be so easy. As a result of the crisis, people are now beginning to renounce every feature of programming that can be considered guilty by virtue of its association with difficulties. Not only go to statements are being questioned; we also hear complaints about floating-point calculations, global variables, semaphores, pointer variables, and even assignment statements. Soon we might be restricted to only a dozen or so programs that are sufficiently simple to be allowable; then we will be almost certain that these programs cannot lead us into any trouble, but of course we won't be able to solve many problems."

It's a problem as old as time itself: A smart person makes an observation based on deep understanding, and the rest, rather than go through the cognitive load of learning its fundamental roots, convert it to an easy statement of morality and dogma, shrouding it deeper and deeper with ceremony and pomp to create a mystique that none dare investigate.

Thinking is hard, and takes much energy. Most people prefer to keep that to a minimum, thus our superstitions, dogmas, cults, and priesthoods.

<comment><USER17> "GOTO is an easy target due to its cultural notoriety (regardless of how it actually looked in the past), but the overarching argument is indeed against dogma."

I agree.

But I think it's worth pointing out that if we're going to use reluctance to use goto as an example of dogma, it strengthens the anti-dogma argument _even more_ to point out that the dogma isn't even correct _on its own terms_ ; the goto that the dogma is rejecting historically isn't the same goto that exists today.

Under many dogmas lies a kernel of truth. That kernel can be worth extracting, and is often quite enlightening, unlike the dogma.

</comment></comment></comment><comment><USER18> It has been decades since I was tempted to "goto". This not because of dogma or "drinking the kool-aid". It is because I use an expressive language that has constructs that mean what I mean, so don't need to be cobbled up out of such fragmentary primitives.

That so much C code is littered with them just demonstrates a deep weakness in C, and not any kind of fundamental principle. I admit surprise that C# turns out similarly weak.

<comment><USER19> Would you also consider the assembly code that is generated by your high level language to be so "littered" with jmp instructions, arising from a "deep weakness"?

It's one thing to prefer to work with another abstraction, but this is awfully judgmental phrasing that denies or unfairly maligns a usefulness and _necessary_ ubiquity at a different level.

<comment><USER20> Yes, assembly language is a language of deep weakness. There's a _reason_ we don't use it unless we have to - it's too hard to write anything in assembler. In fact, assembler weaker than C - in C, you can usually avoid goto if you want to bad enough, but in assembly, it's impossible.

<comment><USER19> > it's too hard to write anything in assembler.

And yet, everything you run is written in it. (By a compiler or a JIT, sure.) The goto is a useful abstraction _for its layer_. It doesn't have to be your favorite layer, but it's there, and ubiquitous.

I feel like discussions around memory safety are similar. I can't get a lot of people around here to admit that in order to be blessed with memory safety at one layer it needs to not exist somewhere else, and that's OK.

<comment><USER20> You seem to be having a different discussion than most of the rest of us. You're claiming that it's fine for its layer, and the rest of us are saying that _we don 't want to work at that layer_.

Yes, jmp is useful at the assembly layer. Yes, everything eventually gets run on assembly (on the way to microcode, and then transistors, and then quantum mechanics). That doesn't mean most of us want to work there, though.

And goto is the same. Having seen that we don't have to work in that way, we don't _want_ to work in that way. We can work with larger abstractions so that we don't have to deal with that kind of detail.

<comment><USER19> > You're claiming that it's fine for its layer, and the rest of us are saying > that _we don 't want to work at that layer._

Correct. This is what I said all along. Glad to see you're up to speed.

Meanwhile, every time you write an if statement ... May you think, acknowledge, appreciate: "I'm adding a goto!" Or possibly several of them. [I am pretty sure I have had discussions with people who say they are also against if statements, but I don't think that's quite as common.]

<comment><USER18> Everyone is always perfectly and completely aware of the jmp instructions that implement their if and while statements. Talking about them does not make you cleverer than anyone else.

What you are missing, and is the fundamental essence of the whole discussion, is that these jmp instructions don't just jump to any old place, like a goto. They jump to only very specific places corresponding to the boundaries of our if and while statements. The compiler will never generate an undisciplined branch, absent an actual goto in the source.

Beneath the jmp instructions there are register transfer machines, and beneath them are logic gates, and beneath them are transistors and wires, and beneath them are charge carriers and fields, and beneath those are atoms and crystalline structure.

At each level you can find the correspondence with structures in the next level above and below. In no case does the lower level violate the structural rules of the next level up, despite that in principle, it could. That is how we get systems that can be understood, and work.

<comment><USER19> > Talking about them does not make you cleverer than anyone else.

Please don't assume that any notion of my own cleverness is the crux of what I am saying or has anything to do with it.

> At each level you can find the correspondence with structures in the next > level above and below. In no case does the lower level violate the > structural rules of the next level up, despite that in principle, it could

Disagree, especially since you went so far as to talk about the physics. There is a lot of order created from chaos, and the structural rules are largely fiction, taking some effort to impose them.

<comment><USER18> But they are, in fact, imposed, or you would not be able to read this; thus, fictional only in that they were invented.

But in any case, and to the point, there is nothing fundamental about jmp instructions. They, and the sequential execution they interrupt, are a way to help organize state machines. It is a triumph of decades of effort that we have succeeded in making state machines of such complexity behave in comprehensible ways, and a deep failure that we have not found any better way.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> It's funny how Go limitations made me go back to using GOTO statement to deal with errors in an http handler.

</comment><comment><USER22> There is some nuance here that the author misses. Goto jumps to a location in program text. Other techniques, like (single shot) continuations, jump to program state. The former is dangerous. Not just because you can write spaghetti code, which was the original critique against goto, but because you can make jumps that have no meaning. For example, you can jump to a location that has not been initialised yet. With continuations you can still write complicated control flow, but you can only make jumps that are meaningful.

So I argue the issue is not with goto per se, it is with the lack of better tools provided by the languages in question to express complicated control flow. Like many things in programming languages, better tools are well studied but not available in most mainstream languages, which are stuck in ~1980s paradigm.

</comment><comment><USER14> > When Linus Torvalds started the Linux kernel in 1991, the dogma was that > "monolithic" kernels were obsolete and that microkernels, a message-passing > alternative analogous to microservices, were the only way to build a new OS. > GNU had been working on microkernel designs since 1986. Torvalds, a > pragmatist if there was ever one, tossed out this orthodoxy to build Linux > using the much simpler monolithic design. Seems to have worked out.

Except that desktop is the only place standing where microkernel haven't fully catched up, and even then macOS and Windows have a kind of compromise between monolithic and microkernels, with plenty of stuff running on userspace, increasing with each release.

Even Project Treble pushes several drivers into userspace processes, with Android IPC to talk with the kernel layer.

Had Hurd gotten the same love from IBM, Compaq, Oracle, Intel,.... as Linux did, and it might have turned out quite differently.

</comment><comment><USER23> Having saved myself a headache earlier by parsing some HTML with regex, I'm appreciating this post. On the other hand, if you don't obey dogma, it may impair the delivery of your cargo. Everything is a tradeoff.

<comment><USER24> There's a difference between admitting that corners need to be cut sometimes and arguing that cut corners are _correct_.

You didn't "parse HTML" with a regex; you created a solution to fix a very narrowly circumscribed problem by pattern matching on some string inputs. Big difference. Were an easy to use HTML parser (or likely lexer) readily available there'd be little excuse to cut corners as the proper solution would likely be far easier to prove correct (formally or informally) than the regex hack. (Full disclosure: I've written an HTML5-compliant streaming HTML lexer precisely so I--and others--would have less reason to depend on regex hacks in security scanners.)

The article says that the Linux approach proved good enough. No, it didn't. Linux has turned into a nightmare of security vulnerabilities, on par with Windows 95, just as originally prophesied. We only tell ourselves it's good enough because we're unwilling to admit we're where at. Remember when Linux and open source were paragons of security? Man, how times have changed....

But now we have a formally verified operating system in seL4, which is... [wait for it...] a microkernel. Of course, it's difficult to use as a general purpose OS, though not far from where Linux was in the 1990s. In time we'll get there. In the meantime no good comes from lying to ourselves about the nature of our solutions.

<comment><USER25> > Linux has turned into a nightmare of security vulnerabilities, on par with > Windows 95, just as originally prophesied.

What exactly are you talking about ? What was 'originally prophesied' ?

<comment><USER24> That monolithic kernels are more susceptible to attack because they're less resilient to programming errors. This was one of the arguments in the famous Linux v MINIX debate(s), but the notion that microkernels were more secure goes back to before the term microkernel was even coined (i.e. before 1980s).

</comment></comment></comment></comment><comment><USER26> Isn't "keep it simple" also dogma?

<comment><USER27> It can be. Sometimes the requirements are complex so any expression of them in code would also be complex. Then another person sees this complex code and automatically assumes that it is bad and should be made less complex while completely ignoring the fact that it would break the requirements. And to the person who is now going to interject that the requirements should be simpler. I am all for that if possible, but in many cases it is not. E.g., if they are written in contracts. Of course, bad programmers will create complexity where none is needed.</comment></comment>


Don't use the greater than sign in programming - <AUTHOR> http://llewellynfalco.blogspot.com/2016/02/dont-use-greater-than-sign-in.html?m=1 <comment><USER2> It's better to write your code so that it's easy for a later person to understand it while reading.

To that end, use a greater-than sign if reading the code makes more sense that way.

E.g. if the method name is `findAllUsersOverAge18()` then it'd be more sensible to have a check such as: `if (userAge > 18)` than to have a check for `if (18 < userAge)`

Both statements are technically correct, but the one makes a huge difference in terms of reading it and understanding it, without a Q/A: "Why is this conditional turned around?" "Well, Steve is opposed to ever using greater-than signs so we have to invert all our logic".

I also can't help but pointing out- except for certain conventions such as loop iterator variables, it's a much worse programming practice to use non- descriptive, single variable names, such as `x`.

<comment><USER3> Also known as yoda conditions [1]. Some linters have options to enforce non- usage as a best practice [2].

[1] [https://en.wikipedia.org/wiki/Yoda_conditions](https://en.wikipedia.org/wiki/Yoda_conditions)

[2] [http://eslint.org/docs/rules/yoda](http://eslint.org/docs/rules/yoda)

<comment><USER2> Nice. I was aware of the style, but not the name for it.

Also liked the first line of the criticisms: `Critics of Yoda conditions see the lack of readability as a disadvantage that outweighs the benefits described above`

</comment></comment></comment><comment><USER4> This post is basically saying "the simpler way is what I think is the simpler way", while in reality everyone see a way simpler then other.

Since it doesn't hurt the performance there's no need to advice a way over another, the first way that come up on your head is the simpler for you. Go ahead and finish your project fast mate.

</comment><comment><USER5> Have you ever in real life hear someone say "If 80kg is less than your weight, then you are overweight."

Probably not. We say: "If your weight is more than 80kg then you are overweight."

When talking we are used to first mention "x", and _after_ that the numerical value we compare it to. No matter if it's less than or larger than what we want to compare it to.

If you swap these around, then whoever listens to you - or reads your code - will take a few seconds longer to understand what you mean.

<comment><USER6> The argument is mostly about double comparisons, i.e., checking for belonging to an interval.

</comment></comment><comment><USER7> I spotted the incorrect one instantly. Why? Because there are two good ways to write this correctly, and he chose to not use one, and to use the other incorrectly in in his example.

5 < x && x < 10

10 > x && x > 5

Both seem equally readable to me.

His argument also seems predicated on the assumption that numbers are always increasing.

If x > 10 relax() else countdown(x) // easier to read "if timer is greater than 10, relax, otherwise, countdown"

If 10 < x relax() else countdown(x) // harder to read "if 10 is less than timer, relax, otherwise, countdown"

</comment><comment><USER8> Rubbish! greater than is useful if it makes code clearer. Yoda conditionals, no thanks.

</comment><comment><USER9> This leads you to use '0 < x' to test if a number is positive, which to my eyes looks a bit unnatural.

<comment><USER10> This. I prefer these rules: variable first sorted by size of comparison.

x > 5 && x < 10

</comment></comment><comment><USER6> In Python you even have the shortcut 5 < x < 10.

<comment><USER11> This is the first programming hangup I can remember having. Thinking "Why can't I just write it like this?"

<comment><USER12> You just triggered an old man anecdote.

We got our first computer on the morning of Dec 25th. We figure out how to plug it into the TV and we turn it on. It turns on, and we get a flashing cursor. Now what? Aren't you supposed to be able to play games on these? The only other thing we have is the BASIC manual. Let's start reading this. So I play with it for a bit, writing programs like '10 print "Bryan is the Master of the Universe"; 20 goto 10'. On the 26th I decide that the first program I should write is a program to randomly pick BINGO numbers. It looks something like this:

10 X=RND(75) 20 IF X=1 OR 2 OR 3 OR 4 OR 5 OR 6 OR 7 OR 8 OR 9 OR 10 OR 11 OR 12 OR 13 OR 14 OR 15 THEN PRINT "B" ...

It took me a couple of hours to get IF statement to work. But I did, and here I am over 30 years later...

</comment></comment></comment><comment><USER13> Argument is for improved code clarity, not performance etc. Definitely something to think about. Thanks for the post.

</comment><comment><USER14> I do exactly this in my own code, for one-sided bounds like "if (0 <= x)" as well as for two-sided bounds like "if (0 <= i && i < length)".

But when collaborating with other programmers, I follow the majority style. There are lots of programmers who prefer to write comparisons with the varying item on the left and the constant item on the right, and "varying item is on the left" is just as valuable a hint to them as "lower item is on the left (if expression is true)" is to me.

So I wouldn't elevate a personal stylistic preference to a rule: this will lead to pointless arguments. Writing code that's clear to all the programmers on a project should be the goal.

</comment><comment><USER15> Is this satire?

</comment><comment><USER16> I can see the utility for intervals, but for simple checks I think clarity of intent trumps all. Sometimes if foo.value > bar makes more sense. THis is especially true when foo is the subject of the method.

Someone already submitted a PR to the Ruby style guide for this, and I can't express how strongly I disagree. [https://github.com/bbatsov/ruby-style- guide/pull/546](https://github.com/bbatsov/ruby-style-guide/pull/546)

</comment><comment><USER17> For the range case, languages like Python got it right because the statement "1 < x < 5" means exactly what it would seem to mean.

For other languages I'm not sure it matters for inequalities.

For equality though, I always use the form "if (constant == x)" as opposed to "if (x == constant)" because in C it _guarantees_ that the compiler will trip over an accidental-assignment typo. That is, "if (constant = x)" is a compilation error but "if (x = constant)" might be missed.

<comment><USER18> Also known as Yoda conditions.

[https://en.wikipedia.org/wiki/Yoda_conditions](https://en.wikipedia.org/wiki/Yoda_conditions)

</comment></comment><comment><USER19> I picked up the "always use the less-than sign when you're comparing" rule of thumb from something written by Bjarne Stroustrup, though I can't find an online reference to cite. I don't always do it for single comparisons, but I do whenever there are multiple ones such as checking for whether a value is in a certain range.

</comment><comment><USER20> Except then you start using floating-point and then the transformations do not work anymore.

> 1 < nan

=> false

> nan > 1

=> false

</comment><comment><USER21> Cute, but start by lobbying the Mathematics field and once they do away with ">" the programming field will naturally follow.

</comment><comment><USER22> It's all about programming practice. I do like the suggestion `between(x1, x2)`.

<comment><USER23> When someone says that, I always get confuse as to whether you meant an inclusive or an exclusive between. I think the mathematicians uses the square brackets to indicate that intention.

<comment><USER24> That could actually be an interesting linguistics problem. In spoken languages, "between" is usually inclusive unless context suggests otherwise. It can easily be a source of misunderstanding if the context clues are insufficient or the recipient has trouble picking up on them. I wonder if there are any languages that have different words for inclusive/exclusive "between" so people don't have to rely on implicit clues.

<comment><USER25> One possible convention would be to use "in-between" for the exclusive between. It's probably impossible to convince the whole English-speaking world to adopt it, but it would be more natural than "exclusive between" in code.

</comment></comment></comment></comment><comment><USER26> But '>' > '<'?

</comment><comment><USER27> Wow, I completely do not understand.</comment>


Ask HN: What minor/major would compliment a CS degree? - <AUTHOR>

I am looking to tack on a minor to my CS major, and I am curious to hear what opinions you guys have. It would be easy to do a math minor as well, but pure mathematics isn't my thing. Other common majors/minors include IS, physics, statistics, etc..
I mainly want to know if you have run into developers with a unique major that has actually benefited them - even if just in a niche area.
I am very much interested in Philosophy, I love writing, and written/oral logical. However, this seems really "out there" for a CS major to pick up. Other options include business degrees, which I think is somewhat common, however I feel with a strong background in a technical area I could pick up an MBA if I wanted to later in life. Right now I plan to continue web development, and get into entrepreneurship real soon.
Do you know someone with a random major that can apply those skills to programming? <comment><USER3> Marketing. People that go into CS major usually have great ideas and love to build them. However the majority of them have very little insights in how to bring it to consumers. Marketing will bring that missing ingredient into the mix.

<comment><USER4> I majored in CS and did Business Administration as a minor. I would say all courses were very helpful especially if you consider having your own startup. But if that isn't the case then may be applied math or stats would be a better fit. My honest advice is to go with something you like and enjoy other than CS(your major) but you didn't have the time for it.

</comment></comment><comment><USER5> I majored in both math and philosophy and they have been useless in my career as a software engineer. If you want to do another quantitative discipline I'd suggest statistics. Non-quantitative, I'd suggest something like art history over Philosophy, or even graphic design if you wanted a more "practical" minor.

<comment><AUTHOR> So would you say math/philosophy would be useful in more of a research type position? In that case you would probably need even higher levels of math - <USER2> the logic behind philosophy might be useless either way?

<comment><USER5> Applied math is very useful to software engineering and many other fields. However, I majored in pure math, which is not useful. Philosophy is interesting (depending on your personality) but is mostly irrelevant. Philosophy major logic courses will help you ace the LSAT if for some reason you want to go to law school.

</comment></comment></comment><comment><USER6> I am going to address some of the sentiments expressed in this thread.

1\. This is not a choice between having a minor and not having a minor. This is a choice between having a minor and having a certain amount of free time slots available for any combination of 1)random electives, 2)part-time internships/employment, 3)freelancing, 4)side projects.

2\. As far as your career goes, a minor will have very little impact. It will just be a line on your resume. However, side projects and work experience is going to be much more impressive.

3\. If you are interested in certain fields (philosophy, economics, business), then you could consider just taking a selection of interesting courses from each, rather than tying yourself down with a minor.

</comment><comment><USER7> I personally wouldn't focus so much on your career. If you're doing well in your CS program and internalizing that material (and learning how to program), you'll be fine there.

Instead, I would do something "out there" that interests you. If you're like most people, this is about the only time you'll be able to learn about philosophy or literature directly, in-person from subject-matter experts. I've studied philosophy a bit on my own, and with others, and let me tell you, it's a very dense, difficult subject for self-study. It might not benefit your career, but it will benefit your life.

</comment><comment><USER8> This is actually quite simple,pick up a minor that interests you. If you like basket weaving, take a basket weaving minor, maybe you can disrupt the whole basket weaving industry in the future...who knows. What you take as a minor has little impact on your job later in life, unless it's something you really enjoy which will give you some direction to apply your CS degree.

<comment><USER9> Go with something you enjoy for the present better times. You can never predict how useful something will be, calligraphy classes Jobs took lead to good fonts.

</comment></comment><comment><USER10> A minor is really not worth the trouble if you plan to get an MBA in the future. Take all the courses that seem interesting to you. Down the road the lessons you gain will broaden your thinking immensely.

Some course ideas:

      Economics (Trade Theories)
      Business (Marketing Research + Stats)
      Philosophy

Good luck,

</comment><comment><USER11> I second the economics vote. It can really help you with your entrepreneurial desires. If you are really wanting to go out there, try out some law classes and see what you think. Not necessarily for a minor but they help you think about problems and issues differently.

</comment><comment><USER12> I work for a big national lab. Bs/ms in cs. Take a hard science major as well (make the cs a minor or double major). The best programmers/CS people I know are cross-disciplinary and are able to adapt CS approaches to hard problems in other fields.

</comment><comment><USER13> The post title should use the word 'complement' instead of 'compliment'. If answered literally, it would be something like an English major/minor complimenting a CS degree for being practical.

</comment><comment><USER14> If you're in to web development and are currently more focussed on the development side then I think some design courses would be really beneficial!

</comment><comment><USER15> I would pick business. I have 2 degrees CS and math and the math one hasn't been that valuable so I'd avoid that.

</comment><comment><USER16> I recommend doing a BA - I did a BS and wasted a lot of time in engineering courses. I enjoyed taking Japanese.

</comment><comment><USER17> Being very much interested in something is a pretty damn good reason to study it.

</comment><comment><USER18> If you like writing low level software, you should double down and minor in ECE.

</comment><comment><USER19> Communication is always a good one.

</comment><comment><USER20> Philosophy and/or art/design.

</comment><comment><USER21> Calligraphy?</comment>


Reminder: secret_token.rb is named so for a reason - <AUTHOR> http://biggestfool.tumblr.com/post/24049554541/reminder-secret-token-rb-is-named-so-for-a-reason

<comment><USER2> Wow. Please, please tell me that these are just hobby projects which have this happening. I can understand a beginner who doesn't understand git ignore doing this, but if there are people building products with this ignorance, that is troubling. I can see why a lot of greybeards hate frameworks, because someone who builds web apps with a much more bare bones framework, (Sinatra, Webapp2, Express, etc) most likely understands the fundamentals of encryption/hashing simply because of the fact that lighter frameworks require understanding the fundamentals in general.

This isn't to say that a developer for one of these frameworks couldn't easily overlook adding the files with secret_tokens in them to the .gitignore.

<comment><USER3> I could see lots of people doing it, only because Rails auto-generates the secret_token.rb file -- it's easy to just not think about it, forget it exists, put your whole source tree in the repo -- remember to keep database passwords and such out, but not ever even think about secret_token.rb, it just ends up in there.

Rails does the right thing by putting the secret token in it's own file that's even _called_ secret_token.rb (it could have just jammed it in the middle of config/application.rb or something instead, where it would be even easier to miss and/or not realize it should be kept private). So I don't know it's people who don't 'understand' it -- whether you understand it or not, the file is named "secret_token", if you actually look at a file listing and think about "should this be kept secret?", the answer is obviously yes even if you know nothing.

But... there's still a lot going on, and it's something easy to forget about, since you ordinarily _never_ need to think about the secret_token.

<comment><USER4> A file named "secret_token.rb" looks to me like "ruby code to operate on secret tokens", just like a file called "sha256.rb" would be expected to compute hashes, not contain them.

Should have been called "secret_token.yml". Should live in the config, or even better, a "secret_config" top level directory, not a subdirectory.

<comment><USER3> yeah, that might be an improvement, that perhaps should be considered since it's clearly a developer usability problem.

But I think it's not unreasonable to have expected it was clear that ./config/initializers/secret_token.rb was a file to initialize a secret token, that included a secret token in it.

</comment></comment></comment></comment><comment><USER5> It'd be nice if github would suggest adding secret_token.rb to .gitignore when it's uploaded.

<comment><USER6> No thanks. The last thing I want is my version control host getting opinionated about my application domain.

<comment><USER5> Care to elaborate on why?

Github's tagline is currently "Build software better, together." Wouldn't this help people create better software?

I'm not saying they should automatically add secret_token.rb to gitignore, just that they could let you know you might not want to do that.

<comment><AUTHOR> I don't think the answer is having GitHub do anything about it. The word has to be spread, yes. But not that way. Developers need to know about the importance of all their files and their security at development, else just think of what will happen when GitHub is not around or when they use another form of Git, etc. Problems need to be solved from the root and that means teaching developers to be more security aware, not making tools that will make said awareness easier to forget.

<comment><USER7> But wouldn't this be teaching developers? They upload the file and Github explains to them that it should be kept secret, and the developer has the opportunity to revoke the file. That sounds like the ultimate way of 'spreading the word', and if Github does disappear, they will have made people more aware. Not to mention it won't affect people who have been doing this all along.

<comment><USER8> Out of the 3000 repositories which I estimate to be affected by this issue (using Google and eliminating some common techniques used to circumvent the problem), I estimate 1600 of them are not on Github. Even if Github does its best to remove the issue completely, I don't believe it will have a huge impact.

I believe that a better idea is to fix this in Rails. Why is a secret key loaded from the configuration directory? I agree with ajross's comment (<http://news.ycombinator.com/item?id=4970347>).

This isn't to say that Github should do nothing to control the problem, but more must be done than just that.

<comment><USER9> Warning half of the project owners/maintainers that this is a problem won't have a huge impact?

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Note that this was published back in May 2012, so it's not entirely recent (which is OK, just thought I would note it). However, this seems to have been public by February 2011 ([http://stackoverflow.com/questions/5132152/when-you- have-sec...](http://stackoverflow.com/questions/5132152/when-you-have-secret- key-in-your-project-how-can-pushing-to-github-be-possible)). I don't think the issue is entirely widespread, and a different key is likely used for production.

<comment><AUTHOR> Yes, it is an old issue, the problem is that it's still there. Developers keep doing it for production, it is common knowledge for people involved in security, but not for developers, which is worrying. Take a look at this results <http://www.lmgtfy.com/?q=inurl:secret_token+filetype:rb#>

<comment><USER8> I have no problem with old issues or vulnerabilities being posted, of course, especially when they are very widespread such as in this case.

Note that not all of those results are necessarily vulnerable, for example, [https://github.com/hotsh/rstat.us/blob/master/config/initial...](https://github.com/hotsh/rstat.us/blob/master/config/initializers/secret_token.rb) loads the secret key from the environment, and [https://github.com/GreenplumChorus/chorus/blob/master/config...](https://github.com/GreenplumChorus/chorus/blob/master/config/initializers/secret_token.rb) loads it from an ignored file (like the article). I would estimate the real number of projects to be somewhere less than 3000, with about 1400 being on Github. This also assumes that these are all actually production keys.

Just to reiterate, I do believe that this is a legitimate problem even now, but I just wanted to note the age of the article and to refute the claim that this is the first mention of the issue.

</comment></comment></comment><comment><USER10> What is the advantage to hashing a user id and storing it in the cookie over simply generating a random session code and storing it in a db table against the user's id and then checking every request? Is the overhead of an extra db read the only reason people don't do this? (Honest question, not trying to be smart)

<comment><AUTHOR> Well, in order to protect the hashes in said cookies you would end up doing something similar to prevent malicious users from just spoofing them. If you use id/hash tables the way you propose the hash is acting just like an id and is then vulnerable to the same issues. The problem is not that the id is there, but that you need a method to make it hard to spoof.

<comment><USER10> No, you have mosunderstood me. I'm NOT storing a hash in the cookie. Instead im storing a random string. Because this string is random, there is no way that a malicious user can guess what the session code will be for a particular user id.

</comment></comment></comment><comment><USER11> Why don't more people keep configuration / api keys / etc in the database?

1\. Your configuration is backed up along with your data.

2\. You can share configuration with multiple applications easily.

3\. Use postgresql's LISTEN/NOTIFY to tell your applications about new configuration changes in real-time.

4\. Your configuration is as secret as your data.

<comment><USER12> If you're vulnerable to a sql injection or something similar, though, then you've potentially made all of that data web accessible.

<comment><USER11> If you are vulnerable to sql injection, you are completely screwed anyways.

<comment><USER12> that's probably true.

</comment></comment></comment></comment><comment><USER13> As hgimenez said, the best way is to not store your secrets in your source tree at all (12factor.net style). Keep them in the environment. Here's a great example:

[https://github.com/democrats/voter- registration/commit/2fa87...](https://github.com/democrats/voter- registration/commit/2fa8796658fdbf18490cd2a3d7bf173e53b1cab8)

<comment><USER14> Is that a good example? It doesn't warn if the env isn't set.

<comment><USER13> No, it doesn't warn, it raises an error and prevents the application from booting: [https://github.com/democrats/voter- registration/commit/2fa87...](https://github.com/democrats/voter- registration/commit/2fa8796658fdbf18490cd2a3d7bf173e53b1cab8#L1R8)

</comment></comment></comment><comment><USER15> We use the Figaro gem to setup ENV variables per project without messing with your system Path.

It also pushes your ENV vars to Heroku with one command. Pretty neat and simple.

In case you want to check it out <https://github.com/laserlemon/figaro>

</comment><comment><USER16> Why doesn't rails add this to the .gitignore generated from `rails new myapp`? And maybe include a rake task to generate a new secret token. That's why I've been doing ever since I found out about this.

<comment><USER17> Because that doesnt solve the problem properly. Perforce users are still vulnerable, and Mercurial users, and (assuming any still exist) CVS users.

Secrets (keys, passwords, tokens, etc) don't belong in the source tree. If you put them there by default, one day you (or one of your users) is going to "forget" and be in a world of hurt.

</comment></comment><comment><USER18> I would argue this is even worse for Django projects. Django secret keys are in the settings file by default, which definitely needs to be put under revision control.

</comment><comment><USER19> Exactly!

<https://github.com/LePartiDeGauche/pgonror/issues/2></comment>


Analysis of longevity of code across many popular projects - <AUTHOR> https://erikbern.com/2016/12/05/the-half-life-of-code.html <comment><USER2> It looks like the exponential model isn't a good fit at all -- in all cases it undershoots the decay at the start of the graph and overshoots at the tail end. So while it might "look close" there is some systematic that your model doesn't account for. In particular, I don't agree that all code in a codebase has a constant risk of being replaced -- most projects have different components that are developed at different rates. Some components are legacy code that is likely to never change, while other parts are under rapid development. In fact, I'd argue that's why the tail is so long -- legacy code is called "legacy" for a reason. And the tip of the graph dives down so quickly because code being rapidly developed has a higher chance of being replaced.

<comment><USER3> Agreed; you can reject exponential decay a priori: a code base has some minimal set of functionality that it specifies and there is some minimal set of lines required to provide that functionality. If you believe this, then the "decay" curves, must illustrate an asymptote. The asymptote only gets reduced by breaking backwards compatibility. Such an action would include projects like Angular that go ahead and throw away a ton of core functionality in moving from 1.x to 2.x.

The decay isn't actually decay at all, but represents the complement of lines that define peripheral functionality. Lines defining peripheral functionality typically require modification (refactoring) as additional functionality is added. The asymptote which all the curves illustrate but the fit cannot capture represents the proportion of irreducible core functionality.

Simply adding a constant to the fit might fix all the problems.

<comment><USER4> This is a close fit to Fechner's Law (not Weber's) relating perceived intensity to stimulus in animal vision. Also, thanks so much, author.

</comment></comment></comment><comment><USER5> I'd posit that the reason is a nuance of #2, more thought was put into older code on the design of how it should work before making it work. Now we write code so fast that we have to scrap it all and do it again a second time to fix the mistakes of the first time [0]. I'm of the mind that upfront planning would've likely taken less time, but that's simply my opinion and I don't have anything to back it up besides anecdotal experience. The current practice of "move fast and break things" very well could be a better approach.

[0] I'm only mentioning this footnote due to the article picking on Angular (fairly or unfairly), but the point I made that this is footnoting is relevant to them potentially.

<comment><USER6> > The current practice of "move fast and break things" very well could be a > better approach.

It's all about context. What's the cost of "breaking things"? Does your not- yet-monetized social network startup go down for a couple of hours? Or does someone die?

Also, I have witnessed first-hand the slowdown in productivity that a "move fast and break things" approach has when what you are breaking is your team's ability to work quickly and confidently with the code base.

</comment></comment><comment><USER7> Results for WordPress [https://blog.yoavfarhi.com/2016/12/06/half-life- wordpress-co...](https://blog.yoavfarhi.com/2016/12/06/half-life-wordpress- code/)

<comment><USER8> It's interesting that it seems better engineered projects tend to retain more initial lines of code. Almost no first version code exists in WordPress and that project's codebase truly is hodge bodge, where as Git is considered a better piece of emgineering. In fact, Linus has been asked specifically about the good design of his programs and how he achieves it.

</comment></comment><comment><USER9> Just Amazing.

I wonder if there any research articles discussing the correlation between code-change and other metrics like product quality, change frequency of team members, estimation success, etc.

<comment><USER10> This is not a research article? What is the difference between this article and one printed in PDF with more complex words and uglier images?

My question sparked for your request of a RESEARCH article and not a "normal" blog post.

I would like to know why you want a "research" article, that I assumed being an academic article, instead of a blog post.

<comment><USER9> What I interested in was not the "research article" part but the comparison case.

This article comes up with a tool measuring the half-life of the code and demonstrates it on some project. What I was requested as an addition is the discussion of correlation of this metric with other metrics.

Being said that, a "paper" makes a difference compared to a "blog post" at some cases. Sometimes, in order to convince your directors and project managers about your change proposals to the programming processes, you need to support your idea with more serious work.

For example, in my previous company, I could use such an academic research in order to demand more time budget for "code-cleanup" periods where the team focuses just to re-writing the parts of legacy code, instead of bugfixes and new features.

I am surprised that this small request offended someone.

<comment><USER10> Nono, I was not offended, sorry if I gave such impression.

What left me wonder is the assumption that an academic paper is more serious than a blog post; I frequent the academic and that is just not true, especially in our field.

Then, of course, upper management may not share this point of view.

</comment></comment></comment></comment><comment><USER11> Look at how consistently the lines of code grow for these projects. I doubt that is surprising but think about the implications. Linux is a pretty old open source project and still on balance the lines of code just grow.

How many lines of code will it be in fifty years? Will we have to come up with new systems to manage the fact that individuals only really understand smaller and smaller pieces of it? Will it reach a mass where like a black hole it collapses from some uncomprehensible failure?

There have never been things like this that just grow in complexity forever.

<comment><USER12> I think one of the main reasons that something like Linux keeps on growing is that it needs to support more drivers as they come onto the market. So unless you want to remove support for older hardware, you're more or less going to grow endlessly.

<comment><USER11> Right, but nothing can grow endlessly. Yet these projects do grow relentlessly, almost never getting any smaller, for as long as we have kept track. It can't go on forever, so how can it end?

<comment><USER13> The industry could converge on standards which allow certain classes of "repeated but different" code (drivers?) to collapse. By collapse, I mean they could share a generic version of code, thus reducing the overall line count.

Or a new implementation (or OS) could come along, with compelling advances and no baggage. The old code doesn't so much collapse as become obsolete.

</comment></comment></comment></comment><comment><USER14> My rule of thumb is that if a line of code survives its first five years it'll live forever. The age of a piece of code is the single greatest predictor of its future.

</comment><comment><USER15> Code from year one may still be the same code but when it gets moved or reformatted its cohort is updated. If a bad change is reverted, will the cohort for those lines of code also be reverted? The effect of understated longevity is not so obvious when it is gradual and organic. Sometimes an event in a project's history makes the effect very obvious.

[https://blog.yoavfarhi.com/2016/12/06/half-life-wordpress- co...](https://blog.yoavfarhi.com/2016/12/06/half-life-wordpress-code/)

</comment><comment><USER16> I really like this. Suppose we were to accept the suggestion that perhaps linearly decaying code is better built, and more robust, than exponentially decaying code.

Would this give newbies a great new tool to answer their question of which framework or language to learn?

Rails or Django? Django lasts longer. Angular or React? VueJs just a trend?

You could answer all these questions with this kind of analysis.

If someone wants to make a genuine contribution, a blog post contrasting the various decays of Javascript frameworks would be a hit.

<comment><USER17> Ditto. That would be useful to know as newbie, I'm hoping someone can give an answer or atleast point into the right direction.

</comment></comment><comment><USER18> Clojure takes a remarkably stable and additive approach to maintenance and growth. Graph for it is here: [http://imgur.com/a/rH8DC](http://imgur.com/a/rH8DC)

</comment><comment><USER19> I'm not a dad and I actually appreciated the "Git of Theseus" pun. The ship is an interesting thought experience on identity, maybe you can modernize it to introduce philosophy to computer science students ^^

But more on-topic, nice article, well done!

</comment><comment><USER20> Good job and great tool. Thanks.

This might actually be an interesting metric in regards to project architecture and/or project management.

Totally agree that exponential model explanatory power is great.

</comment><comment><USER21> Great stuff here.

Definitely some merit to reason #3 - people are more willing to work on something that they can easily build on top of.

</comment><comment><USER22> A lot of projects I've worked on have utility libraries consisting of mostly stateless, pure functions -- I have a theory that these constitute some of the longest lived code. That, and database models, which tend to be easier to expand than to contract. I'd be curious to see some analysis along these lines.

<comment><USER23> Nice hypothesis! Reminds me of the shearing layers from Foote & Yoder's "Big Ball of Mud" — [http://www.laputan.org/mud/mud.html#ShearingLayers](http://www.laputan.org/mud/mud.html#ShearingLayers)

</comment></comment><comment><USER24> Interesting, but it is not surprising that git and redis are more stable than node and angular. Git and redis are well defined problems that won't change that much. Angular is a framework and node is a platform. They should change more. But then again... javascript fatigue is a thing from what I heard.

</comment><comment><USER25> The simplest explanation is that the exponential model is not a good one (does not correspond to the underlying dynamics), and so the half time value is not an inherent (time-independent) property of the codebase, but depends on its age. It seems to me that in most projects, the code evolves quickly in the beginning and then stabilizes on a slower linear decay. This would explain the observed dependence of the fitted half life on age. It might be more meaningful to fit a linear dependence at the beginning of the project and in the asymptotic regime and also look at their ratio. This should be more stable, would tell you how well was the project designed from the beginning, and would also indicate whether the project has already stabilized or not.

<comment><USER5> He addressed this partly in the article. Even when looking just at the early days of the more mature projects the code churned much less than projects less mature now.

</comment></comment><comment><USER26> Would love to see this restricted to which lines are actually executed in a typical use. I.e. ignore dead code which is still in the repo.

Probably wouldn't be too hard for the interpreted languages.

</comment><comment><USER23> I wish we could capture the "inventiveness" of a particular project — how well the problem was understood when the project initiated.

There had been _many_ *nix'es by 2006, so the territory had significant prior art and with it collective deep understanding of the problems being solved. Angular sprouted alongside a number of other SPA frameworks in an ecosystem that was experiencing a "growth-spurt" (using that term loosely) — lots of variables.

</comment><comment><USER27> This is awesome. I ran it on pyramid for fun. [http://imgur.com/a/KZ9KR](http://imgur.com/a/KZ9KR)

<comment><USER28> A catastrophe based model seems more appropriate. You see big refactoring taking place. Only in a big number sum those Poisson-like events turn into exponentials.

<comment><USER27> 2010 was a major transition for pyramid as it was re-branded from repoze.bfg and merged with the pylons project.

</comment></comment></comment><comment><USER23> Another feature of the model could be stability of product vision. Is there a correlation between the half-life of committer membership and that of the code? How has the problem space of the product changed over time?

Perhaps we could talk about "intrinsic churn" vs. "accidental churn". The former results from the codebase keeping up with the "drift" in the problem space; the latter comes from having to learn.

</comment><comment><USER29> There are still AAA games shipped with code written by id Software 20 or more years ago. Tools too :)

</comment><comment><USER30> Super interesting.

But it doesn't seem fair to directly compare 2005 14 year old stable 2.6 Linux to projects which did basically foundational initial releases and not mention it.

</comment><comment><USER31> Great work. Would be interesting to compare by language - see if particular languages need more or less refactoring.

</comment><comment><USER32> So its true... Angular is the code abyss, my colleagues said it was a legend but I have seen it with mine own eyes.

Thank you

</comment><comment><USER33> Would be interesting to see the results as a function of repository size.

</comment><comment><USER34> Maybe Linux is not rewritten because it doesn't have tests

<comment><USER28> It is being rewritten all the time, but new code per arch or driver dwarfs common.

<comment><USER34> Still, without a high and good test coverage that makes sure that the drivers don't break when the core is changed, it's not worth to do refactoring just to make the code cleaner. Still, it's amazing how much extra functionality was possible to be added</comment></comment></comment>


Designing Great API Docs - <AUTHOR> http://blog.parse.com/2012/01/11/designing-great-api-docs/ <comment><USER2> One of the most important and easy ways to avoid frustrating API docs is to check them periodically to make sure nothing is out of date.

Last year I started using Amazon's Flexible Payment Service (FPS) and their docs were so out of date that they linked me to a PHP library that was over three years old and already deprecated. I spent weeks getting my billing system working and then as soon as it went live I got an email from Amazon telling me that I was using a deprecated library that was being phased out in the next few months.

I also had the same experience with Twilio, although luckily with them the old library didn't work at all so I didn't waste time developing with it.

Updating basic things like links to helper libraries can save your customers countless hours of headaches and frustration.

<comment><USER3> For this reason I would say you need to automate as much as possible. Maintaining quality documentation is expensive, and although much of it requires a human eye there should be plenty of opportunity for machie verification too.

For instance, code examples (snippets or sample projects) should be actually compiled and tested, automatically, every time the docs or the API itself changes. Think of it as CI for your documentation.

</comment></comment><comment><USER4> Another great resource:

<http://jacobian.org/writing/great-documentation/>

</comment><comment><USER5> Soundcloud's API docs are quite impressive esp. their use of apigee console to test things out in the browser: <http://developers.soundcloud.com/docs/>

There's also a startup dedicated to (startup) API docs :) <http://turnapi.com/>

</comment><comment><USER6> This is just as crucial as building your API _properly_ , IMHO. I should be able to piece together my API integration from a mixture of examples, good documentation of deep features and caveats, and intuiting API methods.

For example, this API method (comes from real docs) is far from RESTful and leaves me guessing; what's the path for POST-PUT-DELETE (note, when I looked in the docs, API paths for those methods were not named POST/PUT/DELETE like this one is named get...)?

        https://myapp.com/api/v2/USERNAME/KEY/xml/company/get

I won't rant about API design as some HN'ers have posted excellent articles on proper RESTful API design already.

Docs that are out of date (I loathe developers that don't keep API docs up-to- date), misspell in examples or have un-tested examples, or generally are confusing to navigate are ridiculously unfriendly.

</comment><comment><USER7> In relationship to this post whats everyone thoughts on smart docs like Posterous has? aka Mashery I/O docs, Swagger?

It takes the API explorer model to the next level....and integrates with documentation.

You get up to date docs + API explorer + code stubs. Is this the future?

</comment><comment><USER8> What tools are out there to generate an HTML doc of your api? I don't necessarily need it to parse my code, but I want to take the busy-work out of coding HTML.

<comment><USER5> A bit out of date but I have used rapi-doc in the past: <https://github.com/sabman/rapi_doc> for some of our internal API reference docs, for quickly reminding ourselves of the current state of our API's. It's for Ruby on Rails though, so if you are familiar with RoR, it will parse your controllers looking for API related comments for each controller action. Here's an example <https://beta.spacialdb.com/apidoc/layers.html> But I am sure there are better tools out there, I'd be keen to learn about them.

</comment></comment><comment><USER9> I so wholeheartedly agree. I was just thinking about writing about the decline and fall of documentation.

It seems to me that as open source software has risen, good documentation has declined. That is probably inevitable, but it doesn't make it good.

If you can wrap your mind around making your documentation every bit as elegant as your code, you'll win friends and score career points.

</comment><comment><USER10> this is a good description of the individual concerns, but it's missing a really important consideration that most API designers seem to ignore: what's the ideal way (or ways) for someone to use your API? once you have some answers to that, you can start designing an onramp to your API that subtly guides developers towards the kinds of idioms that you want them to learn. it's not just a matter of following the right form in the right example, but overall organization--what concepts are introduced as being related, the kinds of examples you have at all, etc.

</comment><comment><USER11> Are there any decent open source applications that I can launch to create pretty API docs?

I see that GitHub says their API is Open Source, but is that the actually contributing to the API examples, or the actual code?

</comment><comment><USER12> I wanted to invest in Twilio after I saw the documentation.

<comment><USER13> I wanted to work there after I saw the docs. Now I work on the docs and libraries at Twilio :)

<comment><USER12> (Now I'm an investor in Twilio too :)

</comment></comment></comment><comment><USER14> And don't forget to include a reference to day9.</comment>


Data Visualization with JavaScript without D3 - <AUTHOR> http://dry.ly/data-visualization-with-javascript-without-d3

<comment><USER2> This is all fine and good because the data isn't changing, but what about when you decide to have updating data?

d3's "main" feature is data-binding, i.e. it associates a set of data to a set of DOM elements, and when the data changes, d3 figures out which DOM elements correspond to disappeared data, which data elements are new to the set , so that you can create new DOM elements, etc.

Ironically in this example, if you were to use d3 it wouldn't really change that much.

<comment><AUTHOR> Actually, I can think of more common/simpler reasons to use D3 (axis and scaling helpers come to mind).

For updating data, the simplest (not most elegant) way to do it would be to just re-render the whole thing on data change -- which would be trivial to add.

The article isn't advocating not using D3. The point is to learn the concepts with mostly vanilla JS so that one can better utilize a tool like D3 and appreciate the things it gives you, like data-binding.

<comment><USER3> For updating data, the simplest (not most elegant) way to do it would be to just re-render the whole thing on data change

You are right that it is the simplest way to deal with updating data. But one of the nice parts of D3 is the built in transitions. They make for some eye- popping real-time visualizations!

</comment></comment></comment><comment><USER4> I recently finished an in house visualization project in which the original spec called for D3 to be used. This is no particular fault of D3, but for whatever reason, the d3 visualizations that our freelancer built (mostly simple chart types) was not only not working on pre-IE8 (which was to be expected), but was iffy in certain edge cases for IE 10.

So in a panic, I rewrote half of the suite in Google interactive charts, my goto solution for quick easy interactive charts. It was ok, except that GCharts has always had an awkward API, but even worse, was very hard to customize.

So in another fit of panic, I tried out Highcharts

[http://www.highcharts.com](http://www.highcharts.com)

In a single day, I was able to rewrite all of our visualization code AND make them look like the photoshop specs...and the charts worked flawlessly across browser testing and apparently will work with IE 6.

I've known about highcharts for awhile, but have never seriously used them. Maybe it's because I'm an elitist douche who finds their homepage to be too reminiscent of early-2000s PowerPoint and Excel design...yet in terms of software, I could not be any more pleased with them.

Again, not a knock against D3, which I will continue to learn for the bespoke stuff I want to build. But in terms of interactive common charts, Highcharts is pretty slick...I'll likely never use Google Charts again.

edit: I should emphasize...the problems we had with D3 were not inherent to d3. But as you probably know, D3 is not well suited for common charts out of the box. I am only saying that if the situation does not call for D3, then Highcharts may work just fine for you right out of the box. Highcharts also has an extensive API for bespoke work but I did not venture into it

<comment><USER5> That's interesting. I have yet to have any issues with D3 working in IE8 and above. Don't really care about anything below that but so long as it support SVG I would imagine it works.

And I've also found HighCharts extremely limiting. I ended up having to break things in HighCharts to meet some requirements. Granted that's a project problem not a HC problem, but D3 made much more sense for me.

To each their own :)

<comment><USER4> Let me be clear...for my own personal projects and works, D3 is the way to go. It makes the most sense for the crazy ideas I have, and from my limited perspective, just seems to be the best API among all viz libraries.

But in the domain of common chart type that areperfectly serviceable, clear, and customizable...there's not much choice. Google Charts seems like an easy win because hey, it's Google. It'll definitely be around for at least a few years, as it seems to be the dogfood tool for Fusion tables and other Google products.

But other than that, there's not much else that seems to be widely adopted. Raphael is more of a visualization library and seems to be going by the wayside after D3. Highcharts, in this context, seems to be an all-out winner compared to Google Charts, and against most of the D3-chart-wrappers that I've seen so far (Rickshaw, nvd3, etc).

<comment><USER6> Have you looked at bokeh? [http://bokeh.pydata.org/plot_gallery/burtin_example.html](http://bokeh.pydata.org/plot_gallery/burtin_example.html)

Note: I'm a core dev on bokeh.

<comment><USER4> I've heard of it but thought it was for the domain of python development...which is not a downside, per se, but doesn't always fit the project requirements of "here's some data, now throw some javascript on a page and show that data"

</comment></comment></comment></comment></comment><comment><USER7> Surely a bar chart could be made to work in Firefox…

<comment><AUTHOR> Today's the day I learn that FF doesn't have event.toElement. Fixed.

<comment><USER7> I believe .toElement is deprecated, the spec says event.relatedTarget.</comment></comment></comment>


Coursera Adds Honor Code Prompt in Response to Reports of Plagiarism - <AUTHOR> http://chronicle.com/blogs/wiredcampus/coursera-adds-honor-code-prompt-in-response-to-reports-of-plagiarism/39328

<comment><USER3> It's worth noting that this isn't the addition of an honor code. Prior to this, every student already agrees to an honor code when they visit the active class page for the first time. The new part is that they're adding a click- through reminder about the honor code when you submit an essay for grading.

</comment><comment><USER4> "A large part of the plagiarism arises from lack of understanding of the expected standards of behavior in U.S. academic institutions"

Or maybe it arises from perfect understanding of the standard of behaviors in US academic institutions. As article notes, 43% in the US admit to cheating. Truth is probably even higher. I'm not faulting Coursera for doing what they think will work to curb cheating, but this idea that cheaters are the "other" from countries where they don't know any better is ridiculous.

<comment><USER5> > "As article notes, 43% in the US admit to cheating."

Actually, the article references another article on their site which references a survey:

[http://chronicle.com/article/High-Tech-Cheating-on- Homework/...](http://chronicle.com/article/High-Tech-Cheating-on- Homework/64857/)

The second article states the survey, done by "Center for Academic Integrity", found 22% admitted to cheating on tests, which is the traditional idea of cheating, and 43% admit to "unauthorized collaboration on homework".

Unfortunately, the article does not properly cite its sources. In particular, it does not name the survey, who did the survey, how many participants were involved, what the range of errors is, what the definition of "unauthorized collaboration" is, how the question was phrased, or which of numerous "Center for Academic Integrity" was involved. The most prominent according to Google seems to be the "International Center for Academic Integrity" at a Clemson University, but I was not able to find a reference on their site to such a study.

This is a good example of the problem with not properly attributing one's sources such as "The Chronicle of Higher Education" is doing. Readers can not evaluate the quality of claims in the article if they can not reliably locate the sources and read the parameters and constraints of referenced surveys and studies. It's very unprofessional not to properly cite sources in formal publications and articles.

> "this idea that cheaters are the "other" from countries where they don't > know any better is ridiculous"

In my experience (personally as an adjunct professor, and in frequent discourse with other college professors making the same observations) most students in US engineering courses for the last 25 years are nationals from various asian nations. In many other countries collaboration on homework is expected and normal and students are not taught that failure to show sources is plagiarism. Only copying answers on a test is considered cheating in much of the world. Because of this, the majority of cheating in engineering classes is done by foreign students. Much of this is unintentional because they are simply unaware and were raised in a different system. In some cases, students receive sophisticated assistance from their home country, for example Chinese students in some courses have bound Chinese language translations of class- and-professor-specific course materials, including appendices full of past course exams for a given class, with answers and explanations. Making use of any and all resources one has access to, without feeling the need to attribute or explain its provenance is considered common sense, not cheating. Explaining US standards of academic behavior at least provides those who are unaware of these standards an opportunity to adjust their behavior to conform to US (or possibly western) standards of what is considered cheating.

 _Cautious readers will at this point be observing with delighted skepticism and awareness of irony that - as I post anonymously using an alias - <USER2> personal history claims above are not a reliable source and barely qualify as anecdotal._

</comment></comment><comment><USER6> A lot of people do not understand what plagiarism exactly means. Of course, there are those who do and brag about it but there are a set of students who do not understand what it means to plagiarize. Plagiarism is a wrong path to tread and this should be explained - perhaps a course on History of Plagiarism by Coursera?

</comment><comment><USER7> It's adorable watching professors try to inflict their honor codes on the entire world. Honor codes only work in the context of a community. Universities can have honor codes because they control economic penalties if you violate them (failure/expulsion/non-transferrable records).

Is there any disadvantage to cheating on an anonymous website course (other than personally not knowing the material)?

You can't compare the motives of an upper middle class suburban American kid with the popular view of China/India/"Over There" where everything is copied, cheated, and broken down in a dog-eat-dog society.

Their official statement shows obliviousness to cross cultural issues and societal norms: _"A large part of the plagiarism arises from lack of understanding of the expected standards of behavior in U.S. academic institutions, especially among students who have not been trained in such institutions," said Daphne Koller, a co-founder of the company and a Stanford University professor, in an e-mail interview. "We believe that this language will be quite helpful."_

Is the answer truly "U.S. academic institutions are infallible and the world must comply to our standards?"

<comment><USER8> >>"Is there any disadvantage to cheating on an anonymous website course (other than personally not knowing the material)?"

Is there any _advantage_ to cheating in Coursera? Coursera doesn't offer certification.

>>Is the answer truly "U.S. academic institutions are infallible and the world must comply to our standards?"

No the answer is "Students shouldn't be plagiarizing because they won't get any of the benefit from actually doing their homework."

<comment><USER9> > _"Is there any advantage to cheating in Coursera? Coursera doesn't offer > certification."_

Yeah. I thought the whole purpose of the open courseware initiative was placing the learning of content ahead of the "credit". If you choose to cheat, who cares? You are only hurting yourself.

<comment><USER10> Coursera emails you a certificate of completion when you finish a course. From comments in their discussion forums, it seems like some students are using these certificates to get partial credit towards courses at their own university, or to show to employers as a proof of their development, etc. So unfortunately there _is_ an incentive for some people to cheat on the courses.

<comment><USER11> Maybe to promote the "learning over credit" model, Coursera shouldn't attempt to stop any kind of plagiarism. This would make the certificate essentially worthless, which would promote learning only for the sake of learning.

</comment></comment></comment></comment></comment><comment><USER12> Hmmm. I think I must have clicked through this the other day when I signed up for the machine learning class. There was something that looked a bit like an EULA.

</comment><comment><USER13> To people that think that this is about societal norms and people from Asia not understanding plagiarism is unethical ... How can you really believe that? That's just multicultural BS. They understand it is unethical, they just don't care for whatever reason -- they aren't that naive. You'd have to be mentally very childish to not to understand that. The same goes for corruption, people in the third world understand it's not good - they aren't deluded everyone.</comment>


Ask HN: Do Udacity nanodegrees get anyone a job without academic background? - <AUTHOR> For example someone with limited programming knowledge ? https://www.udacity.com/course/c-plus-plus-nanodegree--nd213 <comment><USER2> No one is going to hire you because you have a degree, whether from a university or from Udacity. They'll hire you because:

A) your overall resume is impressive

B) you either have a portfolio of things you've built, or else you agree to do a take home assignment and successfully complete it

C) you can pass both technical and non-technical interviews

To get hired you need A && B && C. Doing Udacity will probably help with each of those things, but no one is ever going to hire you because of an academic credential alone.

<comment><USER3> 15 years ago I went to MIT for a 1.5-month internship, while still in my high school. Companies still ask about that.

As much as I would like it to be otherwise, signaling (namedropping of famous universities, companies, and people) works a lot. I guess mostly because people prefer to delegate decision making. The backside of that is that unless you finished (or dropped out) from a well-respected univ., you have an uphill battle of proving one's worth.

<comment><USER4> RSI? Well that's a bit of an exception. I personally interpret it as a more enduring meritocratic signal than attending any specific college.

<comment><USER3> Yes, RSI! :)

Though the ones who set "oh, you were at MIT" didn't know about this program.

<comment><USER5> If I see any resume with RSI on it, here's how I read it:

* I think less than 1% of the high school students in this country (the US) are aware of summer programs such as RSI. Knowing about RSI, let alone being selected into it, is a strong signal that in your pre-college years you were very invested in math and STEM.

* even if you don't have a very prestigious college degree is not a negative signal anymore from my point of view. At 17-18 we are all very fragile beings (and we keep being fragile until at least 25), so lots of things could explain why you didn't get into a top university. I would inquire about that, but I would expect to hear some reasonable explanation (and I wouldn't mind if you simply told me it's personal and you don't feel comfortable going into those details).

* I would ask you if you participated in any math or CS competitions in high school/ college.

From here, lots of ways to have a pleasant chat for about 30 minutes.

<comment><USER3> I am not from the USA (there is some number of international participants). So applying there is considerably more difficult than for a US person (and the effort goes in non-STEM things such as the application procedure).

When it comes to signals, I like your approach for looking at them as hints, rather than judgments.

</comment></comment></comment></comment></comment></comment><comment><USER6> When I come across an applicant with a nanodegree, it almost sends a negative signal. If anything, do the course, leave it off your resume, and if you get an interview, you might impress your interviewer with all this unexpected technical knowledge.

<comment><USER7> I'm surprised that it sends an negative signal. Is there a reasoning for it? Does completing an online course signify unwanted behavior/personality? I feel like if you leave it off your resume, you probably wouldn't be able to land the interview to begin with.

<comment><USER6> I've done online courses myself and found them immensely useful.

Unfortunately, I think that to some extent, it signals that "I'm interested, but not committed enough to get a full degree."

Your nanodegree realistically will never come close to competing with a formal CS degree. So don't bother with listing it. List your github projects and apps you've released. Get the interview. "Oh and by the way, in my spare time, I've self-studied XYZ."

That'll impress me.

<comment><USER8> >>Unfortunately, I think that to some extent, it signals that "I'm interested, but not committed to getting a full degree."

This seems quite short-sighted, because the underlying assumption is that not getting a full degree is a signal for unwillingness to commit, as opposed to _inability_ to commit.

Not many people can up and quit their "real life" to pursue a degree. With your mindset, you are definitely discriminating against, for instance, people who have medical bills to pay and are stuck at their current jobs, but are also ambitious and dedicated and want to switch to better careers and are willing to do whatever it takes to do it.

<comment><USER6> I'm extremely sympathetic to that situation since I was an unemployed college grad looking to get a developer job when I took my first Udacity course ("How to build your own search engine" - 2012).

The problem is that it's a competitive field out there and to give people false hope that a nanodegree will get them a job is disingenuous.

I've also listed the alternatives for self-taught developers to help them stand out. I think ultimately, if you weren't going to get the interview, a nanodegree won't help you. If you were maybe going to get the interview (by showing impressive original work in the form of projects and apps), a nanodegree might help you the slightest bit.

</comment></comment></comment></comment></comment><comment><USER9> I find it impressive when I see applicants that have completed online courses. It takes a lot of discipline to self study.

</comment><comment><USER10> seeing nanodegree on CV would be neutral for me.

I'm software engineer without a degree, i've done ML nanodegree recently. I don't plan to shift my career to ML and did it only to gain high level understanding. I didn't have to put a lot of effort to complete. I wouldn't consider myself hireable for ML role but i've seen that other people treating nd courses much more seriously than myself putting a lot of effort and producing great projects.

In the end is about the skills you have and a way to present them. I think udacity courses do teach relevant stuff but it's up to you to put the effort in

</comment><comment><USER11> I did a nanodegree, it was a complete waste of time for me.

It was impossible for me to get a job with those (basic) skills. A lot more is needed.

I have been on the other side also as a hiring manager. I would never screen (let alone hire) anyone just on the basis of the nanodegree

<comment><USER12> I do wish there were more advanced courses available. Tons of great intro material, but its harder to go deep

</comment></comment><comment><USER13> Ultimately people will hire you if they can understand the value you'll bring to their org. I.e, the dollars you will help them earn, or the impact your efforts will have on a goal that's primary to them. Education is one signal out of many.

That means that if you can get in front of the hiring manager, your resume is going to be less important than the impression you make on that person, and how compelling a case you can make about the value you'll generate.

There are gate keepers out there who will discard perfectly good candidates because their resume doesn't exactly match the job description; focus your energy on discovering ways to skip over those people and get in front of the decision makers — and then be prepared to articulate and demonstrate the value you'll bring.

</comment><comment><USER14> I don't have anything specific to nanodegrees or specific online courses, but its a lot easier if you know specifically what job/industry you're targeting.

In my experience a Master's/Bachelor's/PhD might get you into the interview room because of your resume or recruiters coming to campus, but in my experience I've been disappointed about the knowledge gaps in recent graduates from well-known schools. I've also interviewed Masters/PhDs who studied my field, but were interviewing for user-facing support roles when they're clearly better suited for something more focused on r&d. Or they've focused so much on a specific subset, they're lacking the general knowledge needed for that job. IMHO, degrees don't guarantee anything for me. At most, they're a jumping off point for how your interests and background apply to that job.

More important than the degree are the projects you've worked on, your role in them, and challenges you've overcome. You could take the nanodegree and omit it from your resume, but put the projects on there as personal projects. Just don't misrepresent your work. It can be a surprisingly small industry. Someone might recognize a project as something they saw online, or know someone who worked on it.

</comment><comment><USER15> I think there is a big difference between an academic course that anyone can take (assuming you can pay or it's free!) and a university course that you need to compete with other students to get a place - employers may like that as indirectly the course has done some pre-screening of candidates for them

</comment><comment><USER7> I did the SDC nanodegree and I'm currently doing the deep learning nanodegree. Not sure if it helped me to get the interview but it helped me during the interview. But I mainly rely on my college degree (MSc in MechE) when I'm applying. However, I had no luck getting an interview for any SWE roles.

<comment><USER16> Why do you go for regular SWE roles when you've taken the SDC nanodegree program and are currently going through the deep learning one?

</comment></comment><comment><USER17> You'll probably receive a biased sample from the HN crowd

</comment><comment><USER18> There's a reason Udacity does not release hiring stats

</comment><comment><USER19> I completed the self-driving car nanodegree last year and currently doing the computer vision one. I did not seek a job at the end of the SDC one but I learned a lot and that could be helpful in the near future, either for my startup or if I decide to look for a new job.

</comment><comment><USER20> IMHO the micro degrees, and MOOC courses in general, can help if you already have the needed requirements and use it to support extras listed as 'wants'. Of course if the list of NEEDED skills is more than 5, then they usually do not know what they really need and a micro degree for all of their listed requirements would work. In addition, the micros could provide the difference between two candidates. "Yeah they are about the same, but this one spends time learning more, and you know we are considering opening the left-handed smoke shifter division and his micro skills would be an asset there"

</comment><comment><USER21> I am a product/engineering hiring manager at a tech company. I would love to know about nano-degrees that candidates have completed. It takes just as much grit as brick and mortar college if not more.

Disclosure: Maybe bias as I quit college to be a FT software engineer. And traditional schooling never really worked for me I learned more at home.

<comment><USER22> So... how do you know how much grit it takes for a brick and mortar college?

</comment></comment><comment><USER23> I did a couple. No one cared about those.

Save your money if thats your motivation.

</comment><comment><USER24> OP a better question might be:

"how would I work out whether the current market applicable to me would be willing to hire based on a nano degree?"

It'll invoke fewer platitudes and generalisations from HN.

</comment><comment><USER25> Nope</comment>


UAW Local 735 President Don Skidmore uses Facebook - <AUTHOR> http://features.csmonitor.com/economyrebuild/2009/06/02/at-a-shuttered-gm-plant-frustration-confusionand-flowers/

<comment><AUTHOR> I just found it vaguely funny that on the front page of the CS Monitor was a story about a shuttered GM plant...and Facebook was caught lurking behind the scenes.

</comment><comment><USER2> just so you know. if you would have looked closer, you would have seen that page was his little girls. I was there and belong to that local and people like you should not make assumptions just by looking at a picture. He has a family who was by his side at the time. Grow up!!</comment>


How I Landed a Job at a Hot Startup - <AUTHOR> http://jeffvincent.posterous.com/how-i-landed-a-job-at-a-hot-startup

<comment><USER2> Nice description and congrats.</comment>


Ask HN: What size monitor(s) do you use - <AUTHOR>

I just saw some pictures of Xobni's office and one guy has 3 displays (possibly 20"). I know Mahalo uses 24" iMac's and another widescreen panel on the side.  I use a 30" cinema display, what is your ideal monitor setup? <comment><USER2> 3 19" widescreen @ work. 1 24" Dell at home. However, I spend the most time (not by choice) working on my HP laptop (not even sure the size of the screen, company bought it) I'd like to get 2 more monitors for home but I just don't work enough there to make it worth it.

</comment><comment><USER3> I found the 30" cinema display too large for comfort, for some odd reason. Now I use a 24" iMac with a secondary 23" cinema display to the left. Perfect for me.

</comment><comment><USER4> I have a 14.1" monitor, and I'm thinking of downgrading to a 13.3" monitor. I use multiple desktops in X, but I've never seen a need for an external monitor.

</comment><comment><USER5> A dual-head linux box (two 20" LCDs) and a windows box with a matching 20" LCD. Running Synergy as a virtual KVM so I only need one keyboard/mouse.

</comment><comment><USER6> MacBook Pro in clamshell mode with a 24" Dell Ultrasharp monitor (with Microsoft keyboard and mouse :/)

</comment><comment><USER7> 15" MBP plus 23" Apple Cinema at home. Plus a Mac Mini on a 22" HDTV/LCD combo monitor next to it.

</comment><comment><USER8> I have a 19" and a 28" side by side.

</comment><comment><USER9> 30" lcd flanked by a pair of 20" lcds

</comment><comment><USER10> Dual 22s

</comment><comment><USER11> I got a 15 in MacBook Pro and am getting a 24 or 26 in HD TV to put in my music studio/office space to double as a second monitor (with the first being my laptop screen).</comment>