@all:
Maybe we should divide the inventions in CS (as broadly spoken as possible) between pure CS abstractions (data structures, compilers, languages,…) and engineering solutions to CS problems or simply enablers (transistor, CMOS, networks (those would fit into abstractions too), mouse, GUI,…)
???
It seems that the concept at least of routines existed in the earlier posted PacMan code - unless this is a recent rewrite.
;; Indirect Lookup table for 2c5e routine (0x48 entries)
36a5 1337 ; 0 HIGH SCORE
I also like the next line 
don’t call and ret count as a routine? isn’t therefore the concept of a routine even older than programming languages themselves? what about doing it by hand? pushing an address, jumping then jumping back when done?
Personally i think the jump from assembler mnemonics to a language with grammar was the biggest development in programming… its a highly non-trivial conceptual leap, where as routines seem like a natural side-effect of a person writing code… I think most coders, not necessarily even a good programmer, would invent them as needed and probably there are multiple “inventors” of the routine.
In essence its just an elaborate parallel to things like headed paper or mail merged letters… people recycle everything that costs them something to make, whenever they can. Laziness is a big driving force for invention.
“What do you think the single greatest invention in computer science is?”
Honestly I just don’t care. There is no satisfying answer and thinking about [with dark, booming voice] THE SINGLE GREATEST INVENTION IN CS doesn’t make me a better programmer. It isn’t important. Every invention (OOP, subroutine and so on) has advantages and disadvantages. You must which one is best suited for your current problem while avoiding falling into the old trap “If you have a hammer, every problem looks like nail.”
"How long should this routine be? How long is too long?"
If the routine is longer than a screen page, it’s too long.
"How short is too short?"
Maybe if the routine name is longer than the code it contains?
"When is code “too simple” to be in a routine?"
Wrong question. Are you writing the same three stupid lines of codes over and over again? Put them into a routine and call it several times instead.
"What’s a good name for this routine?"
Okay that’s a hard one. My general rule of thumb: routines called more frequently get shorter names. Yes I’m lazy. But hey I can always refactor it later.
"How will I know if the code in this routine succeeded? Should it return a success or error code? How will exceptions, problems, and error conditions be handled?"
If it encounters a problem, let it throw an exception. If things go wrong - and they will - at least you know where the error occured first. It’s dangerous if you application seems to run flawlessly but internally has faulty data.
Just some suggestions
Ah finally someone who read beyond the first line of the article.
bull; “How long should this routine be? How long is too long?”
“If the routine is longer than a screen page, it’s too long.”
Hmm… can’t say I agree with that one. Too vague for a start. How big is a screen page exactly? Are we talking a 24x80 character xterm or 9-point text on a 2560x1600 pixel WQXGA screen?
The usual suggestion is between 50 and 100 lines. But an arbitrary limit seems too, well, arbitrary. Routines should exhibit strong cohesion. As long as the body of the routine is only concerned with a achieving a single goal then longer may be appropriate - though even then I would typically try break that down into logical ‘steps’ and create private routines for each step.
bull; “How short is too short?”
I don’t think there is a simple answer for that one. It may be entirely valid to have a method that does nothing at all, especially when using interfaces and polymorphism.
bull; “If it encounters a problem, let it throw an exception.”
I would say “If it encounters a [unexpected] problem [that cannot be handled internally], let it throw an exception.”
I wouldn’t be pleased if a FindInArray() routine threw an exception when it couldn’t find the item, or if a Set.Add() threw when I tried an object that was already there. These are both expected ‘problems’ and their status should be conveyed without using exceptions.
Likewise if I call File.Delete() and file cannot be found then (arguably) that problem can be handled internally and the method can return success.
I’m a little surprised that the arguments around the greatest invention reolve around languages, subroutines, compilers, and microprocessors. As a programmer I agree that many of the things mentioned here have made huge strides in computing, but I don’t any of these things would be possible without the sharing of information via the internet (otherwise I would have never read this post).
@Suresh:
Neither Ajax nor Adobe AIR is a programming language, so it looks like you stopped at JavaScript. 
From the post: “Good programmers – regardless of whatever language they happen to be working in – understand the importance of crafting each routine with the utmost care.”
What a blithe thing to say. Not all good programmers have the resources (= time) to craft each routine with the utmost care every time it needs to change. If you are working in a decent language (I use Python and JS, there are others) then not every routine has to be perfect the first time. Often they are, but I find that my routines often break the 2nd or third time I change them, but it usually doesn’t take very long to fix them if you have exception tracebacks (Python has them by default, you can get them in JS with custom code). Just because Steve McConnell says it doesn’t make it true.
@David: “Not all good programmers have the resources (= time) to craft… it usually doesn’t take very long to fix them if you have exception tracebacks”
There are plenty of studies that cover the relative expense of fixing bugs at different times in the development cycle and I think pretty much all of them agree that spending extra time getting the code right to start with is still cheaper than debugging later. So the argument that you don’t have time doesn’t really work.
Besides, if you rely purely on “exception tracebacks” to find your errors then what about the logic errors that don’t cause exceptions? And how do you even ensure you have found all your possible exceptions? Just fixing the exceptions that appear when you run it sounds like a recipe for producing code that “usually works”.
“(I use Python and JS, there are others)”
Aaaah… well that explains it. He did say GOOD programmers 
I disagree with most of the article.
I wouldnt use routines until they are adopted by a significant number of programmers and know for sure they are a good coding practice.
Er, last comment should’ve read
Sebastian on June 12, 1948 02:19 PM
Isaac Z. Schlueter basically hit it.
The answer is the invention of formal proofs in geometry by Pythagoras. After “writing” my first FORTRAN program on punch cards I was struck by the similarity it had to the geometry proofs I did in 9th grade. Recall the way a proof in geometry unfolds in your mind and on paper or papyrus. The abstraction and use of formal language in a sequence of the clearest logic. How is it different in any way from what a coder produces ?
Do you recall that in the greek Olympics, Geometry-Proof-Skill was an event?
The question posed here is an historical question, in essence, and we are all the children of pythagoras, euclid, thales and aristotle.
You have to give Babbage an honorable mention though. The audacity to create a machine out of wood, metal, cloth and paper that could do complex calculations ? That was thought to be pretty much insane at the time.
cheers
Jeff, do you even have a bachelor’s degree in computer science? HOW can you ask this question and then write an entire post on just programming languages?
Aaaargh.
@Kevin Z: Most of the inventions mentioned here (with the exception of a few not particularly revolutionary languages) were indeed possible, and actually existed long before the Internet.
@AL Pareigis (and others): None of the descriptions here of the early card-programmed mechanical machines mention anything that worked like a routine (callable from various points in a main sequence, often with parameters) - the most advanced structure seems to be the loop.
The invention of the Turing Machine by far is the most important invention of Computer Science.
Well,
While I thought this when I first read it I am glad that I am not alone in the idea of the compiler being the most important “invention” in computer science. While they could not be made without the use of routines, what’s more important as a field wide invention the nuts and bolts or the final project? Personally I say the final project.
I noticed some were saying that wired routines (like in chip sets), may be the most important, but I would put that in the “computer itself” category as it is hardware.
Just my opnion, but then again that is what blogs and comments on blogs are for right?
These individuals must have been contributors to: “The Greatest Invention in Computer Science” both in hardware or software:
Computer Hall of Fame
http://www.computer-museum.org/hof/
It includes Grace Hopper. But I’m surprised it didn’t include Donald Knuth - “The Art of Computer Programming”, TeX.
http://en.wikipedia.org/wiki/Donald_Knuth
The AS400 (Silverlake project) and ReXX (Michael Cowlishaw) are pretty cool.
When I first read the question, I thought about OOP.
I thought about structured programming too, but what I like about the OOP concept is something that is a connection with CS with the real world. Routine is pure CS, but OOP took programming to other level, more connected with how things are in reality, under a human conception, obviously.
I kind of like when programmers demonstrate they can look away from their computers and make associations. Routine is just a way of doing the same things, but better. OOP involves a philosophy behind.
But… it’s just a matter of my likes, of what one thinks it’s more important. Definitely the routine paved the way for a sustainable work… but, hey, what about the variable?
I agree OOP is the next big leap after routines structured programming.
Exception handling is also a big leap (but not when used for validation errors! or as a method to pass back an alternative return type).
IBM had simple exceptions in PL/I a long time ago. It took ages for that to be superceded with the current model I first saw in Delphi.
‘Intelligent’ IDE’s that OOP makes possible are a massive leap too.
OOP involves a philosophy behind.
Loose data coupling and data hiding were around long before OOP. All OOP allows is a new way of sharing code/data which makes practical an extra level of indirection/abstraction allowing more complex taskes to be programmed. sadly it can lead to a lot of unnecessary fiddliness coz it gets used so badly so often!
In the early 1980’s I worked on a very old PL/I or COBOL program (I can’t remember which language). At 1st it looked horrible with GOTO’s everywhere. Then I realised it was using label variables to branch to code that would branch back to the line after the invoking line.
The programmer had implemented routines and was doing structured programming before the language had a call statement - or else he was a structured assembler programmer who didn’t know about the call statement!
I hold the (admittedly unconventional) view that object orientated programming is actually hurting the industry. Object orientated thinking causes you to overly obsesses over the object model and focus less on the computation you’re trying to perform.
Does anybody out there agree with me or am I just a raving lunatic?
Nope - you are the prophet that seems like a lunatic to the herd!
I have long had misgivings about OO in business programming - the over-use of objects and ‘design patterns’ and abstractions that make life harder not easier.
Business programming has become technical and complex partly due to the horrendous coding required (or used for flashness) for browser interfaces and partly coz of OO. I read ages ago some guru saying if you look at the design mess of large COBOL applications you wonder what these guys will do with OO! My brother used to say of C++ ‘you just can’t use average programmers’. But business computing wants de-skilled programming - coz they are cheap and fast to train. it also wants ‘shallow’ logic - that can be understood by average programmers quickly.
I believe if dates and times were stored as char strings (in ISO format?) and manipulated with stateless static methods dates would be a doodle. A date is data not an object. But look at java calenders!
The object paradigm is rather irrelevant in most business processing. You can’t have 1 customer object owning all customer data and operations.
I tried implementing an object model for financial transactions and it made it far more complicated.
The unit of code for much business processing is the transaction which operates on a data store. When all code for a transaction is together and uses subroutines it is easy to follow. When it is scattered thru an object hierarchy and across xml/object/data store layers it is harder to follow. People have object models where things look like they are peers when one is a slave/service to the other.
The static stateless method (subroutine) that changes parameters is the simplest logical structure hence the best to use. My systems would have maybe less than 50% of code inside objects.
So I am another lunatic.
PS OO is great for GUI widgets for sure! And for some frameworks if designed well - if the logic is kept ‘shallow’ and simple.