When I was a kid I loved computers and I saved my paper route money and bought Borland C++ and tried to learn C++ from the manual. I failed utterly and I had no one to teach me. Now kids can learn easier languages that do cooler things on cooler hardware and they have the Internet to learn from.

Great things are possible and computing has made great leaps forward. Enjoy it!

As challenging and frustrating as it can sometimes be for me to get the application stack working, it's nothing compared to the aggravation and sheer misery I'm eliminating from my users' workflow.

One group sits close enough to me that I can actually hear the reduction in swearing each time I replace a shitty old tool they have to use with something that was actually designed with their needs in mind. That's a pretty nice feeling.

I'm just not buying into this "oh, life is so hard to set stuff up nowadays" routine...

Rather, the point is that it is easier and more pragmatic to rush ahead with an imperfect technology stack and achieve great things than it is to spend the time and effort to reach "a better place".

I love how far technology has come, I love writing iOS software and appreciate the resources at my fingertips via Google. However I have a similar range of experience as the article's author, and I completely agree that while great things are being done with technology as it is today, it's very sad that we have limited ourselves to only reach where we are now rather than where we may have been.

I'm with you.

Go build a new computer architecture, Zachary Morris. It seems you have the knowledge and the support. Put it on kickstarter and I'll give you money. Godspeed.

The problem here is that you can argue this either way, so let me clarify. When we do systems analysis, we first focus on "happy path" scenarios. You want something, there's no exceptions, you push a big red button and it shows up. Life is good.

For those kinds of behaviors, say provisioning an entire linux stack on AWS, things are rocking. Want to code? Type in a couple apt-gets and you are on your way. There is a huge section of happy path scenarios where things are truly much better than before -- easily enough that many startups can totally stay on the happy path and do awesomely. (And that's exactly what they should do.)

But, alas, because of the dozens of layers of abstractions, and dozens more API, tooling, and hardware configurations, if you are doing anything technically difficult you can easily leave the happy path and get lost in the woods. It's very easy to get into a situation where you are using a combination of a dozen things in such a way as to be almost unique. Yes, each thing is awesome and easy to use, but the scenario you find yourself in is not. It's not called "sad path" A better name for it would be "terrible path of shame and destruction" Ever work inside a problem where you're dealing with multiple edge cases in several layers of complex system that has parts that are inscrutable? Ouch. I've plowed through complex and poorly-written C++ frameworks line-by-line and it's not as bad as that.

The author spun out one such scenario for writing iPad apps, but you could find a hundred of these cases easily. Boards are full of guys asking questions about combining A, B, C, D, E, F, and G into a situation where they are having problems, and responses are usually along the lines of "Hey, I know A, C, F, and G, and here's what worked." Sometimes that's helpful. Sometimes not.

I'm fairly new to linux, although I'm an old .NET/Win32/C++/COM hound. About a year ago, I thought about writing a mono app in F# to do functional reactive programming for the web as a side project. Basically Node. After poking around for a few days, I finally gave up. As far as I could tell, I couldn't find an entry point into a mono app such that I could load the app and hold it in memory, then re-enter from Apache (It probably could be done directly from the command line, but I didn't want to give up Apache) I wanted the speed associated with re-entrency.

Now perhaps somebody will reply and tell me the magic formula to make all of that happen. If so, awesome. But it was just too much bullshit. Finding stuff on Apache? Easy. Setting up a linux box? No problem. Loading up mono? Piece of cake. Getting F# up? A bit of a hassle, but I worked it out. Tying it all together in that unique combination in a configuration not commonly used? A very painful thing. I'm not saying it was impossible. I freely admit being a wus and giving up. But this kind of frustration is all too common any more.

Another example. I help teams a lot. Many teams I help are starting out on their project in a greenfield environment -- it's a new project and everybody is starting fresh. It's not unusual for them to spend a week just getting their environment set up. Now here's the deal: yes, you and I could cherry pick tools and such so that we could set them up in an hour or two, but many times the organizations they are part of have already made these choices for them. So no, it's not git. And no, it's not a plain-vanilla IDE. And so on. I really feel for these guys.

So sure, you can show all kinds of examples where things are a lot easier now than before, and I completely agree. But many folks do not live in that world.

I would venture that anyone who works in a large corporation is not in this world. Which is a loss; large established corporations have some of the most interesting problem spaces...

Of course, this assumes you have plenty of time to spend on such projects. ;-)

That thing he's talking about with non-sequential placement of bytes on the drum is well before that.

4K? Luxury! I started with 1K and that included the screen memory!