mtomczak

How does refraining from collecting sales tax make Amazon look cheaper than Barnes and Noble? The sticker price doesn't factor in the sales tax; on an item-by-item comparison, the prices would look the same if B&N could match Amazon.

Based on this observation, I find the explanation that Amazon's not interested in spending the money to track state and local sales tax policies to be more plausible.

I wonder if there's correlation between below-average physical activity and insomnia? I assume that a lot of coders---by necessity of their task and the tools they use---spend most of a week sitting as opposed to, say, a mail carrier or store clerk. Given that we're a species that evolved to leverage mobility for our survival, it's not a stretch to imagine that our bodies developed a dependency on lactic acid buildup and other "fatigue toxins" as one of the signals that sleepytime is at hand.

Has anyone done this study? It seems like a pretty straightforward study to do if some grad student out there is looking for a paper.

Thanks to the general availability and utilization of vaccines against smallpox and polio, massive improvements in sanitation and emergency response, and long-term cardiac therapy, the death rate due to cancers is radically up.

Cancer is a horrible disesase. Which one of those changes should we not have made to end up in the situation we're in today?

My experience with the legal system has been limited to a handful of vehicular violations and one tour of jury duty. But from that limited perspective, I cannot see why the justice system should minimize useful facts.

Apart from the laws that protect other rights incompatible with perfect knowledge.... As a maxim, justice should never hide from evidence.

Is it possible that the difference between 1984 and the world into which we could be moving is that Big Brother recorded all motions and activities of the citizenry, but the reverse wasn't true?

Perhaps that's where balance lies.

I've heard this approach described as a failure continuation, and it's a good approach. It's much easier to do in a language that allows for easy creation of closures. Such a system wouldn't be impossible to construct in C++; you could create an ErrorHandlers object that is passed as the last argument of every method and contains instances of some kind of "RestartCase" object. But I cringe at the amount of boilerplate that would be required to support such an approach.

Property values are significantly lower in Pittsburgh, which makes property ownership easier. And the top-quality colleges in the city continue to graduate excellent candidates for tech company employment.

Although a graduate can ship out west, the lower costs in Pittsburgh make the path to ownership shorter. I'll be interested to see if the economic downturn will give graduates pause when thinking about shipping themselves three timezones away into an expensive location, when the cheaper prices in Pittsburgh could offer a lifestyle with less debt.

Slightly off-topic, but if you're installing ODE on Windows, you're in for a world of hurt. I never had the chance to try any other dynamics packages that build on Windows, but I'd recommend shying away from ODE; this is a "devil I know, devil I don't" situation where the devil I know is pretty evil.

You'll find that ODE can be downright Windows-hostile in pieces of its implementation that have nothing to do with GNU toolchain issues. Take a look at http://www.ode.org/old_list_archives/2003-October/010046.htm... for the most common problem; they don't care that the stack has different restrictions in Windows and Linux. You'll also find ODE to be downright thread-hostile; the entire library is non-reentrant (they built their own non-threadsafe layer on top of malloc inside the engine; you can't trust any two functions to be callable from separate threads, even if they have logically nothing to do with each other).

ODE is the first physics package most people seem to suggest, but I think it's more trouble than it's worth.

I'm sure I'll get accused of having no sense of humor, but I have to observe that from a usability standpoint, this is unhelpful. It gives me no clue as to what I've done wrong, it wastes my time, and it offers me no help in correcting my behavior. I might install this on my personal machine for fun, but as a system administrator I have no business touching this.

Responding to invalid input by actively mocking the user is about the worst decision you can make for discoverability. It's this kind of user interface thinking that can lead to a toolchain being rejected regardless of how powerful or useful the tools could be.

I think this is the flip-side of the startup coin that many people forget about. The quote from the article that stuck out most for met was "But most of all: nothing is more motivating and inspiring than the sense of ownership and self-direction only a startup can provide."

Having decided to walk away from the startup I helped to found, I couldn't disagree more. The three things mentioned by larsberg are three things I'd grown to sorely miss. In particular, no-one is around to teach me test-driven design, and when I'm already putting in 120% during the day, I'm deadened to the desire to self-learn through books and scavenging on the internet.

There are similarities between Facebook and AOL. But one significant difference is the interface. AOL had a proprietary client to access its service network. It made sense at the time, but it was often clunky, had not-insignificant bugs, and generally behaved like an application separate from the rest of my user experience. The client also wasn't nearly as ubiquitous as a web browser (though AOL CD's were so common that we used them as coasters and frisbees).

Facebook itself may be a closed network, but it's a closed network running in an open client---my web browser, which works on all my computers and my cellphone. Since the Facebook team doesn't have to build the end-user software, they can focus on their core competencies of the network and the user experience inside the browser. That takes a lot of the complexity off of them that AOL had to embrace (in my experience, the Mac client was never as reliable as the Windows client, for example).

Facebook could go into the business of making its own client apparatus (such as a branded phone), but why bother? The web is serving quite well for them as a transport medium. I think that AOL suffered badly when the state of the internet became "There are these closed networks, and then there is everything else, and you need two end-user clients to access the two separate systems." As walled-in as facebook is, I still use the same client to access it as I use to access the rest of the web, and hyperlinks inside facebook and the larger web can still interoperate between each other seamlessly. That's an architectural strength that AOL didn't get to leverage.

Interesting point. But if we aren't going to trust SSL, what should we trust for commerce over the Internet?

In the short run? Flash Player.

If your browser doesn't support Flash, you are still getting a more fragmented web experience than the person running Windows XP on her $250 netbook.

I use my netbook mostly to write small web server applications in Ruby and Python.

This device is not "for" me.

For the record (though as other commenters have pointed out, this rant on LabView is off-topic): LabView is a very successful tool that is used by many programmers in various fields, not just instrumentation. LabView does have compiler errors and syntax error highlighting; they don't look the same as in a text-focused language, but since G is a programming language, it has its own syntax and errors can occur.

Programming languages are an abstraction. G is just another abstraction. I've used BASIC and C compilers with terribly cryptic, useless errors too; the errors had more to do with flaws in the compiler and IDE than the language itself. If errors in LabView are cryptic or obtuse, I would assume something similar.

For his baby-momma to keep the baby in, of course.

I believe that I see your point, and I would agree that the verbosity of HTML leads to sharability, and that is a strength.

But the verbosity is also one of its weaknesses for large projects; it adds a great deal of overhead in terms of keeping track of the tags, especially if the HTML needs to be re-arranged. And with no language-supplied rules for how much whitespace to use or where (beyond "all adjacent whitespace is compressed"), there is too much flexibility for a large team to work smoothly. My usage case doesn't mesh with your example, because I'm working in an environment with version control and multiple developers. The guy using Notepad will be told to get a tab-aware text editor, because his changes will mangle the whitespace in the file and lead to unnecessary noise when he commits.

When structure in your whitespace is already desired (to avoid making your version control noisy), you can leverage the fact that you are structuring the whitespace to make it a semantic element. This greatly decreases typing, makes the code easier to eye-scan, and allows details such as proper closing bracing to be left to the compilation tool and not to the developer. I agree with commenters who have noted that HAML has been proven useful for some developers.

I would categorize both SHPAML and HAML as tools that let you be more productive with HTML.

They are functions you can make up on the spot. That's usually the extent of my explanation.

Surprisingly, most of the people I talk to assume that the "fancy" parts of closures (such as variable value capture and upvalues) are the way such a construct should work and require no further explanation to use them. People who are surprised by capture (and assume, for instance, that the variable will take on the most recent value assigned to it by outside code instead of "remembering the value when the closure was made") get a more lengthy computer science-esque explanation. But I generally find that explanation to be unhelpful if a person can't see why closures are useful; "An anonymous function with some teeth" is often how people I talk to come to closures first, so it's how I let them think about it until the model is no longer helpful.

Sounds like fun. I'll be in for that.

How do we know where to find each other?

I can't help but wonder if it's a mistake to try and push widespread adoption of Linux distros in the desktop space. It's possible there's insufficient money to be made in that space--Apple is a hardware company; Microsoft is a de-facto monopoly but rumor has it that they're going to have to struggle to recoup costs on their desktop OS in a world that cares less and less about the details of the host system.

Maybe the right solution for desktop adoption is "If you want to run Linux on your desktop machine, that's neat. But don't think you're going to be pushing Windows off of your neighbor's desktop."

Sadly, I think the issues mentioned in this comment are exactly the point, primarily the last issue. Most desktop consumers using Windows and MacOS aren't used to dealing with a product that isn't a household name.

While lack of vendor support and advertising (no "one right way to do things") appeals to those of us who can invest time learning to maintain our software, people like my parents need someone to call when things go wrong. And it is extremely important that the person they call be courteous and accepting to a fault; my experiences with Dell customer service have been nothing but unhelpful, but none of them have ever chewed me out for failing to read the manual. My experiences with people apparently acting as volunteer service-providers for GNU software online (via IRC) have been both unhelpful and insulting. Perhaps the fault is mine for trying to find help on IRC; sadly, with a lack of a well-advertised vendor offering support, I'm left to scrounge help wherever I can find it.

To be fair, it is perhaps reasonable to ask the question of whether people in charge of most Linux distros actually should want to dominate the desktop. But if people do want to create distros that would move in on that space, they should understand that it's exactly these sorts of "subjective" assessments of the OS that would block widespread adoption. This isn't a technical problem. It's a sales problem---a problem of not investing as much time and money into the people-to-people interactions as into the people-to-technology interactions. Both are needed for widespread adoption.

Yep. Working at a startup company in the city right now, in fact.

Not a bad article. But the article summary on HN is pretty much a lie; I'm pretty sure you can cure NS with various techniques, including blunt-force-trauma to the cranial region.

This news and Google Apps coming out of beta in the same day?

I can't take all this sudden and drastic change!

I strongly suspect that's the point. What does "beta" mean on a web service that is continually updated by the developers in essentially realtime? The only real meaning I can think it has is the liability concerns that others in this thread have mentioned.

Here is the thing I wish someone had told me my freshman year of high school.

If you're interested in computer science, study topics in discrete mathematics, real algebra (the algebra where you compute with symbols instead of numbers, look into "rings", "groups", and "fields"), and some statistics. And if you have to scale back on something to make room, scale back on trigonometry.

Discrete is a subset of math that was barely touched on in my school, and it was a massive culture-shock to get to college and never have seen many of the staple discrete problems. Statistics is useful in real-time problem solving and analysis and is at the core of some of the neatest modern algorithms, including those in cryptography. Trig, on the other hand, is something that you will likely have pre-written libraries to support and is just not as important to most computer work. It's useful, but unless you're going into computer graphics and games it's maybe not as necessary.

These days, I can tell you the area of a triangle from its vertices but I still get thrown easily in a crypto discussion. If I had high school to do over, that's what I'd do differently.

I've seen Mono used to great effect in the Unity 3D game engine (http://unity3d.com/). Game engines are one of those interesting spaces where speed matters quite a bit, but so does ease of modification; you want your developers to be comfortable enough to implement whatever crazy ideas are designed up for game mechanics, and you need to be able to make sweeping changes to game logic quickly. But you need those implementations to be fast as well. With its multi-language support and JIT-compiled nature, Mono seems to sit at an interesting saddle-point that makes it attractive to applications like this. It's also cross-platform compilable, which in this age of multiple consoles-plus-PC-plus-mobile platforms is extremely attractive.

I couldn't tell you why they wouldn't use Java, however.

It's funny, because I have a simple AppJet app that I was considering re-implementing in Rails, having recently learned the basics of the framework. AppJet has just helped me make the decision. Thanks, AppJet!

Greetings! I'm one of the regular readers of codinghorror who had never seen news.ycombinator.com until just today. With respect, the original poster (pollster?) is painting with a rather large brush. Could we please at least be allowed to get in here and see what's going on before the assertion that we will "contribute very little to the website" is leveled?

On the other hand, it's refreshing to see the comments of someone who doesn't think that a simple count of users is the be-all and end-all of a website's worth. That attitude is intriguing and makes me want to learn more about this site.