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!
This is probably the single most irritating thing to me as a developer. And, the most frustrating part is that this aspect often turns a simple project or a curious dive into a new technology into a knock-down, drag-out brawl with configuration files and dependencies that in the end produces frustration instead of working code.
- Need a webserver and database setup? Easy, a few clicks on Heroku and I'm good to go.
- Need to learn how to program something that you can then deploy to Heroku? Easy, just follow these 13 steps and you're on your way:
http://learnpythonthehardway.org/book/ex0.html
WTF is so painful about this?
That's a different path entirely, though not necessarily a bad one. The full stack isn't under your control on Heroku.
Oh, so you have the ability, time and motivation to rewrite your firmware, operating system, network stack, database and web server and implement it on a CPU you designed yourself?
No? Then the full stack isn't under your control either. Get over it.
That's a different path entirely
You know what? It's not a different path at all. The convenience of Heroku is no different in principle to using closed source hardware.
Look, I'm a freedom-zero[1] type of person. I run Ubuntu - not OSX - and I admin my own servers. BUT the chains of convenience of apt-get are much closer to the chains of convenience of something like Heroku than many would like to admit.
To get more control one should move to AWS. But wait, I don't control the network card on the server with AWS. Hmmm... I know! I'll get a colo. Now I can purchase and build my own machine and have control over the network card. But wait, I don't control the backup power system. Hmmm.... I know! I'll rent a building, get an internet backbone piped into it, buy some generators, and control the backup power system. But wait, I don't control the...
I guess what I'm getting at is, why is this an entirely different path? Why isn't using a service such as Heroku "the path" until you hit it's limitations and need to spend a bit more time going to the next step in the process.
One could easily make the statement of "blah isn't under your control on blah" for anything. Where does it stop?
:)
No, software installation today is an absolute breeze compared to what it used to be, no matter which platform you're on. On Windows, DLL hell is largely a solved problem. You can just double-click the Installshield EXE and take a coffee break. On Linux, you can invoke the package manager for your system and have an even more seamless experience. Heck, even programming tools offer their own package management systems now. Want to install django? Pip install django. Want to install rails? gem install rails. It's definitely easier than unzipping files, setting configuration settings, finding (and, in some cases, installing) dependencies, and then crossing your fingers and typing make.
You need not use all of your capabilities all the time. My A/C can go to 50 degrees. Maybe there will come a day when I need that. Until then, I'll keep it above 70.
This is a great rant. Nice emotional content, lots of technical details, the author qualifies his credentials, etc. Easily one of the better articles I've read in the past few weeks.
One of the things he mentions is the pain of setup -- something I've painfully watched develop over the years. Used to be you could go from a dead stop to programming something useful in about 10 seconds. Now, as he points out, it's not unusual to spend weeks digging around through vendor requirements, obscure dialects, rumor and configuration nightmares simply trying to get started. It's crazy. We've complicated the plumbing to the point nobody knows how to work the damn shower any more.