Jon Raynor added this comment to my previous post about keeping up with the pace of change in software development:
I think it becomes clearer to think of a programming language as a set of screwdrivers rather than making the each-programming-language = a-single-type-of-screwdriver analogy. Because certainly many programming languages utilize that standard, multi-purpose flat-head, but some add unique, niche-type screwdrivers, etc.
Otherwise, I agree. It gets very tiring trying to stay abreast of things. Maybe for the whiz-bang uber-programmers it’s no problem, but for some of us(i.e. me), it’s hard to maintain, muchless, excel. There’s just too much, even if you’re trying to specialize.
Kenneth
Part of the problem, of course, is that manufacturers keep using oddball screws. Why on earth is my laptop screwed together with tiny little philips head screws, but the hard drive inside of it is secured with torx screws that are exactly the same size? The screws look identical except for the place where you put the screw driver. Woludn’t it have been cheaper and easier to use screws with the same head? (OK, I’m sure there’s some technical reason, but it certainly looks silly from my point of view.)
I see this same sort of thing with software development, as well. Things like, “the new version of our application was built with a newer compiler, so if you want your plugins to continue to work, you need to rebuild them with the newer compiler, too.” Great! Thanks! I didn’t have any other things I wanted to work on anyway. Ugh!
So it’s not always that developers want to use the latest and greatest, but that we’re often forced to by the OS/app/whatever that we work with.
something is not right here…
Windows = operating systems you can open and close to get air
Apple = Something fresh and healthy to eat
whiz-bang power screwdriver = ruby
paint can = development instructions
hammer and nails = MS .Net ?
… ehh I dont get it Jeff, are you the keymaker? 
but some add unique, niche-type screwdrivers, etc.
Like, say, this one?
Dude, you own way too many screwdrivers.
I think the problem is not one of new screwdrivers, but of interdependent screwdrivers.
If you look at C# and compare it to how I learned to program (Fortran 77, 6502 assembly and Basic), there are more differences than just syntax and memory protection. Even moving to my first professional programs, at a very fundamental level, the way I approached programming in DOS on a 386 CPU using C and assembly differs radically from how I program today.
a) I have a relational database that runs independent of my code.
b) I have an operating system that handles half of the infrastructure I used to code by hand.
c) I have libraries that cover the other half of the infrastructure I used to code by hand.
d) I have a GUI builder that makes light work of user interface layout.
e) I have different paradigms (objects, distributed computing, recoverable transactions, etc.) that underly the work itself.
The interesting thing isn’t the toys that allow my focus be laser like on business logic, but the fact that trying revert to “the old ways” the house of cards collapses. The GUI builder relies on partial classes, inheritance and a huge library to make it work. The libraries are possible because objects made organization of complex reusable code blocks easier. The relational database exists because I can afford to burn CPU freely and it in turn relies on the operating system to provide a stable platform to ignore many issues that are abstracted away.
What we have today is built atop the structure that each prior platform gave us. In most cases, the old platforms don’t entirely vanish, but instead act as supports for the new platform until the new platform stable enough to succeed. NTKERNEL still has assembly at the core, and C code around it. Windows is still C with C++. Many applications today are written in higher level languages, but they still require that C/C++ underpinning.
Back on topic, the point is not only we need to acquire and learn new screwdrivers, but those screwdrivers are interdependent in ways that mean you are going to eventually drag the entire infrastructure in a given direction. By using .NET 2.0, I found myself upgrading to the new application blocks, a new version of my object relational mapping tool and SQL 2005 to get the full benefits of the new platform. I didn’t upgrade my screwdriver, I upgraded my toolbox.
As for Ruby, it is an interesting language which has much to commend itself. Likewisem, Rails does much to place the programmer at a higher level of abstraction when dealing with a specific application type (the data driven web app). However, because it is being built “alongside” the powerhouse application stacks I have to wonder about its long term success. Ruby on Rails has to maintain the entire stack above the OS/Web Server level as well as providing a library, which as it grows may be the undoing simply because of the overhead.
Working with screwdrivers for all these years is giving me RSI
actually, the Robertson is a better screwdriver. Canadian, too.
language development was quite stable for a long time, the COBOL years. one learned a bit of syntax for a few months at some store-front programming school (or the US Armed Forces), then spent years churning out the same stuff for a particular industry. no CS degree, or even 5 minutes in a college. the methods of AutoCoder, FlowMatic, and COBOL from the 1950s and 1960s live on today. and in the enterprise world, there is a good deal of effort to move all that “software investment” to microprocessors and linux.
and, there really should be a 3): hordes of wanna be Elite Programmers spewing out silly procedural code wrapped in OO syntax; aka Apache.
and these are the truly evil ones, since they generate so much noise that folks just start going along. in economics there is Gresham’s Law; bad money drives out good. the same can be said of languages.
My gut reaction was to agree - why don’t we just master the tools we have instead of creating new ones all the time? Then I thought about the path from Commodore BASIC to Visual Basic to VB.NET. Each one was a major improvement not only in language features, but what you could do with it.
Obviously changes in the underlying platform drove and enabled these improvements, but I think it would be difficult for anyone to claim that each wasn’t needed, and a step for the better.
The same is true of software testing tools. Test teams sometimes get trapped on the “test tool merri-go-round.” They have a tool that’s working fine for its intended purpose, but then some new, whiz-bang widget comes out that they MUST move to. So they do. Then a year later, the next big thing comes along and so they move to that. Of course, none of these changes are made quickly – they involve countless hours of tool evaluation, followed by education, porting of test scripts, etc. Often times, sticking with one tool and leveraging the heck out of it (even though it isn’t perfect) turns out to be the better long term strategy.
Tools are a means to an end. But it’s easy to lose site of that end when one is hypnotized by shiny objects.
My first reaction to the title was to say, “Because we have so many screws, and not all people use them the same way.” Universal conformity may be great from an intellectual standpoint, but it just doesn’t work.
That aside, I have to agree with Jon’s quote. Ultimately it’s all just ones and zeros. I’ve been fortunate to have been able to adapt to new ways of making ones and zeros, and I find things to love and hate about each method. However at the end of the day, it really just doesn’t matter.
From David Heinemeier Hansson’s perspective, the Ruby language and the Rails framework are not a silver bullet but a means to it. He claims that programmer motivation is the silver bullet. The way to motivation is happiness. The way to programmer happiness is beautiful code. A way to the most beautiful code is Ruby and Rails.
I agree with him more and more every day.
Agreed that we all need various tools in our toolkit. Extremely powerful and expressive languages like Ruby and frameworks like Rails are must-have toolboxes we all ought to be opening up frequently.
Insert Jim Adams joke about the size, length, and tip of screwdrivers…
Rather have Visual Basic over QBASIC. How about between Visual Basic and FreeBASIC?
A way to the most beautiful code is Ruby and Rails
It’s one way. But you can write FORTRAN in any language:
I think Brooks’ observation is still valid:
I predict that a decade from now, when the effectiveness of [Ruby] is assessed, it will be seen to have made a substantial difference, but not because of any particular language feature, nor indeed because of all of them combined. Neither will the new [Ruby] environments prove to be the cause of the improvements. [Ruby’s] greatest contribution will be that switching to it occasioned training programmers in modern software-design techniques .
Rather have Visual Basic over QBASIC. How about between Visual Basic and FreeBASIC?
Suicide Booth: "Please select mode of death. Quick and painless or slow and horrible."
Fry: "Yeah, I’d like to place a collect call?"
Suicide Booth: "You have selected slow and horrible."
Bender: “Great choice!”
Hey, don’t diss the Robertson. They are by far the best all-purpose screws you can buy.
http://discuss.joelonsoftware.com/default.asp?joel.3.219431
“As it turns out, if you make only one kind of hammer, capable of performing all the same tasks as all those different kinds of hammers, then it isn’t very good at any of them. Driving a nail with a sledgehammer isn’t very effective. And, if you want to kill your ex-girlfriend, there’s really no substitute for a ball-peen hammer.”
“That’s true. So, if nobody buys Universal Hammers anymore, and if you’re no longer selling all those old-fashioned kinds of hammers, what kinds of hammers do you sell?”
“Actually, we don’t sell hammers at all.”