Syntax Coloring and auto-indentation is a baseline that every text editor should support. IDE's parse your code and give you useful information about it. They parse your comments (xmldoc for C#) and use them for tooltips. They help you find function declarations. They help you refactor your code. They help manage your files. They integrate into your version control system. And so on.
To go slightly off topic, I think intellesense was the best invention ever. It gives a programmer a very strong incentive to comment their functions and parameters because those comments show up right away in the IDE.
If you were starting a new project would you base it on Perl5 when you aren't sure Perl6 is just around the corner? No offense to anybody, but Perl6 is a classic example of the second system syndrome and serves as an excellent reminder of why it is never a good idea to rewrite code. While they were busy rewriting code, PHP, Ruby and Python cleaned their lunch.
Perl 6 is already out
It isn't out until I read about its release on Arstechnica and Slashdot.
1) Good IDE's like eclipse or Visual Studio make a programmer more productive. They have refactoring tools, they analyze your code and make it easy to track down where stuff is, they parse your comments to provide very useful tooltips that describe function parameters (intellesense). Without such tools, it takes significantly longer to learn how a new project fits together. Just being able to right click on a bit of code that calls a method and say "goto definition" is worth the price alone. 2) Nonsense. PHP runs on IIS, why shouldn't perl. IIS has a lot of cool stuff going for it these days that apache doesn't. 3) Good. 4) #@$% 5) Ponies my friend, ponies.
Took a while for that distinction to sink in. Here is another container format you'll be hearing about a lot more in the coming months. QAM and ATSC. QAM is only a signal modulation and can be used to stream any kind of container format--usually some variant of ATSC. Think of it, I guess, as like the low-level ethernet stuff--ethernet doesn't care if you use TCP/IP or IPX/SPX. ATSC is kind of like TCP/IP or IPX/SPX, it defines how information is sent over the low-level stuff, but for the most part it doesn't care what the information is (MPEG2, H.264). ATSC typically only carries MPEG2, but I guess it has been updated to carry H.264/MPEG4. I guess it can only carry AC-3 audio streams and not mp3.
If you really want to force yourself to learn about video and audio codecs and containers, force yourself to use ffmpeg on the command line for a while. It's docs and number of switches can seem daunting at first, but just remember what you are trying to do is tell it what codecs to use, what bitrates to use, and any modification to the video/audio stream (aspect ratio, resolution, framerate, etc). If you type "ffmpeg -formats | less", you'll get a list of what your version of ffmpeg can read and what containers and codecs it can write to. Keep in mind not every container can hold all the codecs; you'll have to consult wikipedia for that. The whole exercise will make you think about every aspect of your transcoding experience.
PS: is it me or does chrome have a horrible spellchecker?
DivX is the best format to use for archiving TV shows you've recorded. It will usually half to third the size of a one hour show and the quality reduction isn't very noticeable(as in, the lady doesn't notice). It is a native format of the media extender and its bigger, high-def brother.
However, I do have to somewhat agree with you about both DivX and Mp3 getting their roots in piracy. I distinctly remember the first time I heard one of those new fangled mp3's in like 1997. Sneaker Pimps 6 Underground. The whole song, 4 megs and tons more on this new fangled XDCC thing on IRC. What could possibly go wrong:-) DivX? Years later, random Simpsons episodes, 50->100 megs a piece with a tolerable reduction in quality. Also available on that new refined XDCC thing.
@joedcc list !joedcc "Blah blah blah.mp3" ... or something. It has been a long while.
1) Better tools... improve EPIC. Perl lacks a good IDE. 2) Get perl running on IIS using ISAPI (basically, mod_perl for IIS). 3) Either finish Perl6 or give up. Nobody cares about the CLR thing, give us Perl6 the language. The delay in shipping Perl6 is killing the language. 4) ???? 5) Create a branch in CPAN called Ponies::*. There are many libraries for ponies such as Ponies::Little or Ponies::Fast.
It took a lot of cursing to get used to speaking OS X, but once I did I could appreciate it. You just have to go "okay, I'm in someplace with a different culture then my own. Lets step back and just take things in without getting upset". Not that "dont get upset" is easy:-)
C is not a "scripting" language and is as much of a problem as an assembly language attitude
Indeed. Look. C is nice. I love playing with pointers. It can produce some fast friggen code that is great for improving performance in critical areas of your system. But damn is it not up to the task of even basic GUI programming. You shouldn't *have* to worry about memory for most things (unless performance is critical). And if the language is going to mandate you worry about it, the damn thing should provide more tools then just a pointer/array thing. It should at least give you a way to figure out the size of the memory block you've allocated (rather then leaving it to you to re-invent). In fact, if it had just centered around pascal strings instead of friggen null terminated ones--that alone would have made it vastly more secure and suited to hostile environments. And yes, sure I can roll my own damn pascal string library, but why didn't the standard library do it for me?
And why the hell is the language so damn stupid that I need to create function declarations so the brain-dead linker can find my stuff? Why can't it just figure that out like every other language on the planet?
Every time I program in C these days, I just get pissed off. I thought I loved you C, but dammit, I've been spoiled by better lovers and I think I've moved on.
But wouldn't you say the level at which the complexity takes place has also changed? It hasn't shifted to the right or left, but really shifted *up* to higher levels. Yes all the examples you gave are complex, but to be honest none of them solve any usefully problem. They were complex because they systems they were developed on weren't powerful enough to take on that level of complexity for you.
I guess you can make a paralell to farming and industrial revolution. Farming was and still is complex. Back in the day most of humanity was busy doing it. They were all so busy farming they didn't have time to "thing about stuff". It wasn't until farming became a skill that only a small number of people needed to learn that we really started doing cool industrial stuff. Once the chore of collecting food was gone, we created machines and took on new more interesting types of complexity. Then we came up with computers to remove a lot of that complexity and brought on an even different level and type of complexity. Now we have powerful computers who can "solve" that complexity so we are free to invent even new complexity.
Hopefully that analogy makes sense. Basically we "solved" the complexity in your example so we could be free to solve more useful types of complexity.
I think OO has major flaws that people gloss over. For example, OO doesn't map worth shit to any kind of database. I'm also getting the feeling it doesn't quite map well into the massively parallel future we seem to be headed.
Prototyping? A wise old programmer once said to me "If you can't write it down, you can't pull it off". That applies to the code, the database schema and most important the UI.
Design patterns, use cases... are crutches for those that wont think.
Naw. You gotta start somewhere. Design patterns are kind of like the programming equivalent of the Rule of Thirds in photography. You should adhere to it until you are good enough know when and were it doesn't apply.
But given the number of people on slashdot who seem to think the examples you gave are what we should be doing now, you can probably understand me mis-reading you.
The amount complexity may not have changed, but what is complex has. Is that what you are saying?
I'm not a million years old, but I've been around the block a little. Once upon a time, I used to do stupid programmer shit, but not anymore.
It is not stupidity or unwillingness to embrace the latest beta, it's more a matter of preferring that which is known to work over that which may work better eventually but will cause problems now.
That was me a while ago, but these days I never run beta anything (unless there is a very compelling reason to do so). While I built my computer, I dont even know or care what speed it was or anything, all I care about is that it was high quality "boring" hardware (pretty much pure Intel).
What makes me laugh though is when people, especially tech people, get so god damn cranky and laggard they can't accept anything. I remember working with somebody who had to write some UI stuff in Visual Basic (gag me with a spoon) and he just couldn't get over the fact VB managed all the memory. All the time he'd mumble about how it must be a huge waste of resources and "Microsoft" must be doing something shady under the hood.
The thing is, I think a lot of us "kids" (i.e. under say 40) learned computers when they were just becoming mainstream instead of when they were mysterious things in basements. I think we see them in slightly different ways. Computing going mainstream was huge. Everybody had one and they are to this day so new that none of us really know what the hell we are doing it. We still have a lot to learn, things like usability, "development process" and such are still things we need work at.
Good times. But dammit, anybody who says back in their day code never crashed lies. Shit back then crashed *all the time* for no good reason at all!
Who cares about any of your examples. Memory is like $30/gig and all you did was describe something that was a hack around a limited system. Customers don't buy shit because you write hand-optimized assembler. And if you self-modify your code, their virus scanner will remove it. Every example you gave describes shit we just dont need to do anymore. Worse, if you did any of that crap on a modern system, you'd be wasting a huge amount of time and money not to mention making the system that much harder to maintain down line. These days programmer time is far more expensive then computing time. Much better to waste CPU and memory then waste the time of a programmer. Every second you spend optimizing your code instead of buying hardware is time you cannot spend making new features for your paying customers.
When is the last time your fortran code had to interface with a random, quirky browser using a different language (javascript), a message format (json), a document language that is lacking (HTML), a database, a template language, and god knows what else I forgot? Oh yeah. Never. You were busy worring about squeezing the last byte of memory out of a system instead of focusing on huge problems.
And you know the best part, "gramps",? I dont even have to worry about memory because the programming tools I do it for me and let me operate at a much higher level then what you describe. If I had to operate at the level you describe, it would take much longer to develop software and the end result would be a brittle mess of crap that would be impossible to maintain.
There is a reason I'm typing this is because of modern programming tools. The complexity these tools have to deal with is much more complex then the ones back then. Just think of how fucking complex this web crap is. So many, many dependencies and things that are impossible to test. So many moving parts. We now have new, more exciting problems (release processes, testing the untestable, etc) and interesting attempts to solve them like unit testing or hell even XML.
Reverting to waterfall isn't a solution anymore then saying "the solution to global warming is to stop driving". Why not stop living in the past, acknowledge that the problems of today are on a vastly different level then of yore and come up with solutions that will help us scale to even larger things. Waterfall, assembly code and self-modifying machine instructions will not solve anything:-)
If you were a startup, would you use waterfall your first release? Who is your stakeholders in a startup? Oh wait, you are the stakeholder. That and your users, but since you are a startup on a shoestring budget, you can't afford to do proper usability research yet. Who is the "management"? Oh wait, since you are like programmer #1 or #2, odds are you are pretty much the management.
Go ahead, take your waterfall model that works so well for mission critical things like, well, whatever and apply it to web-anything. Go ahead, design your system The Right Way (tm). Let me know if your 1000 page thick binder containing The Specifications(tm) creates a product customers will buy, even when I'm positive you dont yet know what they will. And if for some reason you actually manage to ship a product before your competition, who aren't using waterfall, let me know how long it takes to ship the next version (or is your Master Specification so perfect you will never need a second version). And if hell freezes over and you IPO, let me know so I can short your stock.
Blah. Whatever. Waterfall probably works for some boring mega-project that needs a million different bureaucrats to sign off on any minute change. I'll stick with something that works in a more lively environment where where the cool stuff happens.
When you were working on those punch cards, using your green screen console (kids these days with color monitors and mice), what were you doing?
Did you ever transcode video and then upload it to some website called Youtube on "the internet"? Did you then play it back in a "web browser" that reads a document format that your grandma could probably learn? Did your mainframe even have "ethernet"? Or is that some modern fad that us kids use but will probably pass and we'll all go back to "real" computers with punch cards.
Did you ever have to contend with botnets, spyware or any of that? And dont say "if we used The Right Way Like When I Was Your Age, we wouldn't have those things because software would be Designed Properly". because if we used "The Right Way" like you, software would take so long to develop and cost so much that we wouldn't even have the fancy systems that even make malware possible.
Old timers crack me up. Ones that are skeptical of object oriented programming. Ones who think you can waterfall a huge project. I'd like just one of them to run a startup and waterfall Version 1.0 of their web-app (which, they wouldn't because the web is a fad, unlike their punch cards).
Sorry to be harsh, but get with the times. Computing these days is vastly more complex then back in the "good old days". Your 386 couldn't even play an mp3 without pegging the CPU, let alone a flash video containing one.
I've seen their workflow and how fast it works for them and I can see if they "modernized" it would cripple their productivity.
Until they try to bring in new-hires. How long does it take to train somebody who is used to modern office programs to use a DOS program like wordperfect? You think they'll ever get as proficient when what they see isn't what they get (a fad, I bet, right?)
Again, sorry to sound so harsh. You guys crack me up. Dont worry though, soon enough we'll see the errors in our ways and go back to time honored methods like waterfall. We'll abandon "scripting languages" like Ruby or C and use assembler like god intends.
They aren't to blame. They dont care. That is fine.
Rule number one of being a programmer: nobody but you gives a shit about what you've done. They only care if it works (using *their definition of works, not yours*), it is is fun, and it is easy to use.
This rule is a tough pill to swallow because dammit sometimes you just feel proud of whatever crazy coding stunt you pulled off. But the sooner you learn nobody but you cares *how* something was done the happier you will be. Happy you say? Yes happy. Why? Because maybe you'll refocus your efforts into things that *will* make your users happy instead of tech-crap like shaving.25ms off a database query (one of my favorite jobs). Things like a good interface or fixing a silly but annoying bug will make them way more happy then refactoring your pile of spaghetti code.
Happy users = happy programmer. The reciprocal isn't always true. Sure swapping out the template system for something cooler is fun and makes you happy, but unless if adds something new or fixes something for the user, you've wasted your time.
If people [refused to do|started doing] XYZ, [everything would be better].
Anytime you say "If people do blah", the problem isn't with the people, it is with your argument. "If everybody did blah" means "what I want is impossible, so maybe I'm the one who is wrong".
Waterfalling your entire project will doom it to failure. But that doesn't mean you you don't use waterfall on a small level. Most modern techniques are iterative versions of the waterfall model. You take a small chuck, plan it, spec it and ship it. If somebody thinks you scale waterfall to an entire project, well, get with the times gramps.
Scaling waterfall to a large project is a huge waste of resources. It would require your usability dudes, marketing dudes and stuff to do the plan and then sit idle for the remainder of the project. Likewise your programmers would only be usefully in the middle part and your testers in the final stages.
Lord help you if something changes. And guess what, it will change because this is reality and not the "good old days when I was a kid programming on punch cards uphill in the snow" that gray-beards wax poetic about. Unless you are designing an "about box", nobody knows the problem nor its solution initially. It takes many iterations to get to both a definition and a solution.
Waterfall died long before I ever entered the scene and it cracks me up when I hear people still promoting it as a good idea. These days we just sit down in front of the keyboard and click buttons in fancy "IDE's" using un-proven things like "Object Oriented Programming". Kids these days... we don't even manage our memory, the garbage collector does it for us.;-)
In the future, everything will be in the cloud. The problem right now is hip bloggers and tech trend setters are moving to the cloud while healthcare companies are barely running at Web 1.9, let alone Web 2.0.
Really though, your question is silly. The answer is "Cloud Computing" (and XML (and AJAX (and Push Technology (and Portals)))).
Your problem is that the standard doesn't have enough XML in it. Take that thing you pasted and make it more Web 2.0. Once you've upgraded it, make sure it runs on a couple cloud computers (I read in Gartner they are going to get *big* in 2009), then we'll see it take off.
The problem with health care is we aren't leveraging modern MVC techniques nor are we using Ruby. Too much planning and corporate drones, not enough Getting Real. Just write the damn code already! Paper prototypes, meetings, offices are all just getting in the way of agile programming.
Little Timmy doesn't need them at all for his cold or stomach ache. Antibiotics aren't candy and we should treat them with more respect then we give them.
And lord only knows what kind of super-bugs we are gonna get with the latest antibacterial-everything craze.
For other industries because I disagree strongly with this:
Here, for some reason beyond my understanding, medical records have become almost the equivalent of classified documents in terms of how they are protected
Sorry if HIPPA is making your programmer/IT-job harder, but quite frankly that isn't my problem. If anything, all our important digital information should be regulated under something like HIPPA. The whole point of HIPPA is to protect your privacy. Without HIPPA, you'd see companies calling up a hospital requesting your medical records. You'd see weird scam companies purchasing your records in bulk and then mailing you miracle cures. No HIPPA and when some celebrity gets ill, the press could call the hospital and get all the juicy details and the patient could do nothing.
HIPPA is needed. We need to HIPPA'ize our credit history, our phone bills, our whatever. Even it costs money, and even if it makes prices go up a little. Privacy and control over your life-story is a price worth paying.
Slashdot Mirror
You mean emacs? *cough*
Syntax Coloring and auto-indentation is a baseline that every text editor should support. IDE's parse your code and give you useful information about it. They parse your comments (xmldoc for C#) and use them for tooltips. They help you find function declarations. They help you refactor your code. They help manage your files. They integrate into your version control system. And so on.
To go slightly off topic, I think intellesense was the best invention ever. It gives a programmer a very strong incentive to comment their functions and parameters because those comments show up right away in the IDE.
I agree with you on this. I've yet to see a really good "best practices for perl deployment".
That said, wait until you deploy a PHP application only to find that PHP wasn't compiled with some feature you were using. Good times.
emacs and vim aren't the same. Syntax coloring and auto-indentation are only 10% of what makes an IDE useful.
If you were starting a new project would you base it on Perl5 when you aren't sure Perl6 is just around the corner? No offense to anybody, but Perl6 is a classic example of the second system syndrome and serves as an excellent reminder of why it is never a good idea to rewrite code. While they were busy rewriting code, PHP, Ruby and Python cleaned their lunch.
It isn't out until I read about its release on Arstechnica and Slashdot.
1) Good IDE's like eclipse or Visual Studio make a programmer more productive. They have refactoring tools, they analyze your code and make it easy to track down where stuff is, they parse your comments to provide very useful tooltips that describe function parameters (intellesense). Without such tools, it takes significantly longer to learn how a new project fits together. Just being able to right click on a bit of code that calls a method and say "goto definition" is worth the price alone.
2) Nonsense. PHP runs on IIS, why shouldn't perl. IIS has a lot of cool stuff going for it these days that apache doesn't.
3) Good.
4) #@$%
5) Ponies my friend, ponies.
Took a while for that distinction to sink in. Here is another container format you'll be hearing about a lot more in the coming months. QAM and ATSC. QAM is only a signal modulation and can be used to stream any kind of container format--usually some variant of ATSC. Think of it, I guess, as like the low-level ethernet stuff--ethernet doesn't care if you use TCP/IP or IPX/SPX. ATSC is kind of like TCP/IP or IPX/SPX, it defines how information is sent over the low-level stuff, but for the most part it doesn't care what the information is (MPEG2, H.264). ATSC typically only carries MPEG2, but I guess it has been updated to carry H.264/MPEG4. I guess it can only carry AC-3 audio streams and not mp3.
If you really want to force yourself to learn about video and audio codecs and containers, force yourself to use ffmpeg on the command line for a while. It's docs and number of switches can seem daunting at first, but just remember what you are trying to do is tell it what codecs to use, what bitrates to use, and any modification to the video/audio stream (aspect ratio, resolution, framerate, etc). If you type "ffmpeg -formats | less", you'll get a list of what your version of ffmpeg can read and what containers and codecs it can write to. Keep in mind not every container can hold all the codecs; you'll have to consult wikipedia for that. The whole exercise will make you think about every aspect of your transcoding experience.
PS: is it me or does chrome have a horrible spellchecker?
DivX is the best format to use for archiving TV shows you've recorded. It will usually half to third the size of a one hour show and the quality reduction isn't very noticeable(as in, the lady doesn't notice). It is a native format of the media extender and its bigger, high-def brother.
However, I do have to somewhat agree with you about both DivX and Mp3 getting their roots in piracy. I distinctly remember the first time I heard one of those new fangled mp3's in like 1997. Sneaker Pimps 6 Underground. The whole song, 4 megs and tons more on this new fangled XDCC thing on IRC. What could possibly go wrong :-) DivX? Years later, random Simpsons episodes, 50->100 megs a piece with a tolerable reduction in quality. Also available on that new refined XDCC thing.
@joedcc list
!joedcc "Blah blah blah.mp3"
1) Better tools... improve EPIC. Perl lacks a good IDE.
2) Get perl running on IIS using ISAPI (basically, mod_perl for IIS).
3) Either finish Perl6 or give up. Nobody cares about the CLR thing, give us Perl6 the language. The delay in shipping Perl6 is killing the language.
4) ????
5) Create a branch in CPAN called Ponies::*. There are many libraries for ponies such as Ponies::Little or Ponies::Fast.
It took a lot of cursing to get used to speaking OS X, but once I did I could appreciate it. You just have to go "okay, I'm in someplace with a different culture then my own. Lets step back and just take things in without getting upset". Not that "dont get upset" is easy :-)
Indeed. Look. C is nice. I love playing with pointers. It can produce some fast friggen code that is great for improving performance in critical areas of your system. But damn is it not up to the task of even basic GUI programming. You shouldn't *have* to worry about memory for most things (unless performance is critical). And if the language is going to mandate you worry about it, the damn thing should provide more tools then just a pointer/array thing. It should at least give you a way to figure out the size of the memory block you've allocated (rather then leaving it to you to re-invent). In fact, if it had just centered around pascal strings instead of friggen null terminated ones--that alone would have made it vastly more secure and suited to hostile environments. And yes, sure I can roll my own damn pascal string library, but why didn't the standard library do it for me?
And why the hell is the language so damn stupid that I need to create function declarations so the brain-dead linker can find my stuff? Why can't it just figure that out like every other language on the planet?
Every time I program in C these days, I just get pissed off. I thought I loved you C, but dammit, I've been spoiled by better lovers and I think I've moved on.
But wouldn't you say the level at which the complexity takes place has also changed? It hasn't shifted to the right or left, but really shifted *up* to higher levels. Yes all the examples you gave are complex, but to be honest none of them solve any usefully problem. They were complex because they systems they were developed on weren't powerful enough to take on that level of complexity for you.
I guess you can make a paralell to farming and industrial revolution. Farming was and still is complex. Back in the day most of humanity was busy doing it. They were all so busy farming they didn't have time to "thing about stuff". It wasn't until farming became a skill that only a small number of people needed to learn that we really started doing cool industrial stuff. Once the chore of collecting food was gone, we created machines and took on new more interesting types of complexity. Then we came up with computers to remove a lot of that complexity and brought on an even different level and type of complexity. Now we have powerful computers who can "solve" that complexity so we are free to invent even new complexity.
Hopefully that analogy makes sense. Basically we "solved" the complexity in your example so we could be free to solve more useful types of complexity.
I think OO has major flaws that people gloss over. For example, OO doesn't map worth shit to any kind of database. I'm also getting the feeling it doesn't quite map well into the massively parallel future we seem to be headed.
Prototyping? A wise old programmer once said to me "If you can't write it down, you can't pull it off". That applies to the code, the database schema and most important the UI.
Naw. You gotta start somewhere. Design patterns are kind of like the programming equivalent of the Rule of Thirds in photography. You should adhere to it until you are good enough know when and were it doesn't apply.
But given the number of people on slashdot who seem to think the examples you gave are what we should be doing now, you can probably understand me mis-reading you.
The amount complexity may not have changed, but what is complex has. Is that what you are saying?
I'm not a million years old, but I've been around the block a little. Once upon a time, I used to do stupid programmer shit, but not anymore.
That was me a while ago, but these days I never run beta anything (unless there is a very compelling reason to do so). While I built my computer, I dont even know or care what speed it was or anything, all I care about is that it was high quality "boring" hardware (pretty much pure Intel).
What makes me laugh though is when people, especially tech people, get so god damn cranky and laggard they can't accept anything. I remember working with somebody who had to write some UI stuff in Visual Basic (gag me with a spoon) and he just couldn't get over the fact VB managed all the memory. All the time he'd mumble about how it must be a huge waste of resources and "Microsoft" must be doing something shady under the hood.
The thing is, I think a lot of us "kids" (i.e. under say 40) learned computers when they were just becoming mainstream instead of when they were mysterious things in basements. I think we see them in slightly different ways. Computing going mainstream was huge. Everybody had one and they are to this day so new that none of us really know what the hell we are doing it. We still have a lot to learn, things like usability, "development process" and such are still things we need work at.
Good times. But dammit, anybody who says back in their day code never crashed lies. Shit back then crashed *all the time* for no good reason at all!
Who cares about any of your examples. Memory is like $30/gig and all you did was describe something that was a hack around a limited system. Customers don't buy shit because you write hand-optimized assembler. And if you self-modify your code, their virus scanner will remove it. Every example you gave describes shit we just dont need to do anymore. Worse, if you did any of that crap on a modern system, you'd be wasting a huge amount of time and money not to mention making the system that much harder to maintain down line. These days programmer time is far more expensive then computing time. Much better to waste CPU and memory then waste the time of a programmer. Every second you spend optimizing your code instead of buying hardware is time you cannot spend making new features for your paying customers.
When is the last time your fortran code had to interface with a random, quirky browser using a different language (javascript), a message format (json), a document language that is lacking (HTML), a database, a template language, and god knows what else I forgot? Oh yeah. Never. You were busy worring about squeezing the last byte of memory out of a system instead of focusing on huge problems.
And you know the best part, "gramps",? I dont even have to worry about memory because the programming tools I do it for me and let me operate at a much higher level then what you describe. If I had to operate at the level you describe, it would take much longer to develop software and the end result would be a brittle mess of crap that would be impossible to maintain.
There is a reason I'm typing this is because of modern programming tools. The complexity these tools have to deal with is much more complex then the ones back then. Just think of how fucking complex this web crap is. So many, many dependencies and things that are impossible to test. So many moving parts. We now have new, more exciting problems (release processes, testing the untestable, etc) and interesting attempts to solve them like unit testing or hell even XML.
Reverting to waterfall isn't a solution anymore then saying "the solution to global warming is to stop driving". Why not stop living in the past, acknowledge that the problems of today are on a vastly different level then of yore and come up with solutions that will help us scale to even larger things. Waterfall, assembly code and self-modifying machine instructions will not solve anything :-)
If you were a startup, would you use waterfall your first release? Who is your stakeholders in a startup? Oh wait, you are the stakeholder. That and your users, but since you are a startup on a shoestring budget, you can't afford to do proper usability research yet. Who is the "management"? Oh wait, since you are like programmer #1 or #2, odds are you are pretty much the management.
Go ahead, take your waterfall model that works so well for mission critical things like, well, whatever and apply it to web-anything. Go ahead, design your system The Right Way (tm). Let me know if your 1000 page thick binder containing The Specifications(tm) creates a product customers will buy, even when I'm positive you dont yet know what they will. And if for some reason you actually manage to ship a product before your competition, who aren't using waterfall, let me know how long it takes to ship the next version (or is your Master Specification so perfect you will never need a second version). And if hell freezes over and you IPO, let me know so I can short your stock.
Blah. Whatever. Waterfall probably works for some boring mega-project that needs a million different bureaucrats to sign off on any minute change. I'll stick with something that works in a more lively environment where where the cool stuff happens.
Define Quality. Define "Secure" and define "Stable".
For extra credit, define them in terms of engineering cost/benefit. I'll wait.
PS: Any student who blames Microsoft will automatically fail the test.
When you were working on those punch cards, using your green screen console (kids these days with color monitors and mice), what were you doing?
Did you ever transcode video and then upload it to some website called Youtube on "the internet"? Did you then play it back in a "web browser" that reads a document format that your grandma could probably learn? Did your mainframe even have "ethernet"? Or is that some modern fad that us kids use but will probably pass and we'll all go back to "real" computers with punch cards.
Did you ever have to contend with botnets, spyware or any of that? And dont say "if we used The Right Way Like When I Was Your Age, we wouldn't have those things because software would be Designed Properly". because if we used "The Right Way" like you, software would take so long to develop and cost so much that we wouldn't even have the fancy systems that even make malware possible.
Old timers crack me up. Ones that are skeptical of object oriented programming. Ones who think you can waterfall a huge project. I'd like just one of them to run a startup and waterfall Version 1.0 of their web-app (which, they wouldn't because the web is a fad, unlike their punch cards).
Sorry to be harsh, but get with the times. Computing these days is vastly more complex then back in the "good old days". Your 386 couldn't even play an mp3 without pegging the CPU, let alone a flash video containing one.
Until they try to bring in new-hires. How long does it take to train somebody who is used to modern office programs to use a DOS program like wordperfect? You think they'll ever get as proficient when what they see isn't what they get (a fad, I bet, right?)
Again, sorry to sound so harsh. You guys crack me up. Dont worry though, soon enough we'll see the errors in our ways and go back to time honored methods like waterfall. We'll abandon "scripting languages" like Ruby or C and use assembler like god intends.
Sheesh.
They aren't to blame. They dont care. That is fine.
Rule number one of being a programmer: nobody but you gives a shit about what you've done. They only care if it works (using *their definition of works, not yours*), it is is fun, and it is easy to use.
This rule is a tough pill to swallow because dammit sometimes you just feel proud of whatever crazy coding stunt you pulled off. But the sooner you learn nobody but you cares *how* something was done the happier you will be. Happy you say? Yes happy. Why? Because maybe you'll refocus your efforts into things that *will* make your users happy instead of tech-crap like shaving .25ms off a database query (one of my favorite jobs). Things like a good interface or fixing a silly but annoying bug will make them way more happy then refactoring your pile of spaghetti code.
Happy users = happy programmer. The reciprocal isn't always true. Sure swapping out the template system for something cooler is fun and makes you happy, but unless if adds something new or fixes something for the user, you've wasted your time.
Anytime you say "If people do blah", the problem isn't with the people, it is with your argument. "If everybody did blah" means "what I want is impossible, so maybe I'm the one who is wrong".
Waterfalling your entire project will doom it to failure. But that doesn't mean you you don't use waterfall on a small level. Most modern techniques are iterative versions of the waterfall model. You take a small chuck, plan it, spec it and ship it. If somebody thinks you scale waterfall to an entire project, well, get with the times gramps.
Scaling waterfall to a large project is a huge waste of resources. It would require your usability dudes, marketing dudes and stuff to do the plan and then sit idle for the remainder of the project. Likewise your programmers would only be usefully in the middle part and your testers in the final stages.
Lord help you if something changes. And guess what, it will change because this is reality and not the "good old days when I was a kid programming on punch cards uphill in the snow" that gray-beards wax poetic about. Unless you are designing an "about box", nobody knows the problem nor its solution initially. It takes many iterations to get to both a definition and a solution.
Waterfall died long before I ever entered the scene and it cracks me up when I hear people still promoting it as a good idea. These days we just sit down in front of the keyboard and click buttons in fancy "IDE's" using un-proven things like "Object Oriented Programming". Kids these days... we don't even manage our memory, the garbage collector does it for us. ;-)
In the future, everything will be in the cloud. The problem right now is hip bloggers and tech trend setters are moving to the cloud while healthcare companies are barely running at Web 1.9, let alone Web 2.0.
Really though, your question is silly. The answer is "Cloud Computing" (and XML (and AJAX (and Push Technology (and Portals)))).
Your problem is that the standard doesn't have enough XML in it. Take that thing you pasted and make it more Web 2.0. Once you've upgraded it, make sure it runs on a couple cloud computers (I read in Gartner they are going to get *big* in 2009), then we'll see it take off.
The problem with health care is we aren't leveraging modern MVC techniques nor are we using Ruby. Too much planning and corporate drones, not enough Getting Real. Just write the damn code already! Paper prototypes, meetings, offices are all just getting in the way of agile programming.
Little Timmy doesn't need them at all for his cold or stomach ache. Antibiotics aren't candy and we should treat them with more respect then we give them.
And lord only knows what kind of super-bugs we are gonna get with the latest antibacterial-everything craze.
For other industries because I disagree strongly with this:
Sorry if HIPPA is making your programmer/IT-job harder, but quite frankly that isn't my problem. If anything, all our important digital information should be regulated under something like HIPPA. The whole point of HIPPA is to protect your privacy. Without HIPPA, you'd see companies calling up a hospital requesting your medical records. You'd see weird scam companies purchasing your records in bulk and then mailing you miracle cures. No HIPPA and when some celebrity gets ill, the press could call the hospital and get all the juicy details and the patient could do nothing.
HIPPA is needed. We need to HIPPA'ize our credit history, our phone bills, our whatever. Even it costs money, and even if it makes prices go up a little. Privacy and control over your life-story is a price worth paying.