Slashdot Mirror
Michi Henning on Computing Fallacies
Karma Sucks writes "Check out this summary of a keynote at Linux.conf.au by Michi Henning of CORBA fame. It really hits the nail on several points. I especially liked the point about people constantly rewriting letters in these modern times, as opposed to say 1945 where it just wasn't worth the pain of re-typing a letter. The only point that didn't made sense in this summary was the one about "source code being useless"."
Penicillin - 1920's technology
Iowa/Yamoto class battleships - 1920's technology
Apollo moonrockets - 1940's with a dash of 50's
Polio vaccine - 1880's with a dash of 1940's
Transistor - 1930's
Bulk transport system, rail - 1860's
Bulk transport system, car/truck - 1920's
Airplane - 1910's
Fast airplane - 1950's
Yup, makin progress fast.
sPh
> Nerd culture is counter-productive
.. very creative, with a propensity to desire to push boundries. Their influences may not be approrpiate for the masses, but they lay the frame work for those who compute and program (or write pop and rock) to achieve practical purposes. Practical people see no value in thinking outside the boundries of current methods, but are more than happy to stand on the shoulders of those that do (as well it should be.)
Nerds are the computer equivilent of the Enos, the Yoko Onos, the Peter Gabriels
Whats wrong with different people born for different goals? Even if you don't directly contribute the masses, most changes in fundemental social systems (and technical systems) starts with someone rejecting the norm. As well it should be. Leave them alone and let them nerd!
"Old man yells at systemd"
From the article:
"The best UI people on the planet are those working in the car industry.
We need to make it a criminal law to change certain API's. There are potentially
huge impacts. When we produce a new drug, we can't just release it to millions of
people without some sort of testing."
yeah, but how long should the testing cycle be? For example, we hear all the time about drugs being recalled because of illnesses caused by its use. Beta testing is a great way to do this, however, even then you can't know until your program is running on a lot of machines in different environments, with different variables.
So, what can you do? Well, you release the software after doing as much testing as possible, and wait to see the results...then patch, patch, patch..which is the way it's being done now. That's why early adopters know (or should know)what they are getting into, and why most of the companies I have dealt with, (running win2k) waited for SP2 to come out before upgrading.
Or, you could establish some sort of body, like the FDA does, that tests the heck out of software for a while before shipping. Problem with that though, is that by the time it is approved, its obsolete.
Other than that, this was a most excellent read.
Sent from your iPad.
"Don't write software because 'it's cool'. That only leads to burnout. Write it for money. At least you get something back and don't ruin the market for the rest of us."
Um, no, doing stuff you don't like to do just "for the money" is what leads to burnouts. Nobody ever says "Boy am I burned out playing around carefree...I gotta take a vacation and do some drudgery!". That said, the concepts of *sound design*, *quality*, *maintainability*, *lifespan*, etc., have to be built into the "programming curriculum". I mean, they don't just hand soldiers a bazooka and say "Ok, if you can pull the trigger, you're ready! Off you go!".
It's 10 PM. Do you know if you're un-American?
"If the people who designed and wrote the software can't find the bugs, what makes you think that throwing somebody at it in their spare cycles is going to help? We want software that works, so we can do our business. Our business is not writing this software."
Well that sounds good, but it's been proven wrong in practice.
At this point, with all of the incredible software that has been produced by open source methods, I don't think it leaves people much room to attack the open source design philosophy. It clearly works and works well, it just works differently than people expect.
Sigs are awesome huh?
Nerd culture is counter productive??
Hello?... 'nerds' are the whole impetus behind the electronics industry. Without nerds wanting to show off with faster processors, cooler video boards or better OS's a few billion dollar industries wouldn't exist today.
Hell, Star Wars would have earned $1.50 at the theater without nerds creating the cult that propells it. Nerds created pong on a friggen mainframe just to goof off and sparked the video game industry, quickly gaining as the most widespread form of mass entertainment on the earth.
I am nerd, hear me calculate!
*sigh*
source code isn't necessarily about bugs
it's also about insulation from change or situations the author couldn't see, test, have predicted, have known about.
I may never READ the source code for 99.9% of my apps but they day something get's changed and Eric's OSS projects fails I can go find o.ut why and fix it. Without the source I'm screwed.
And as it happened I did exactly that yesterday when the plan9 imap file server didn't get along with Courier. By having the soruce code I was able to track down the problem to it being a wrong assumption in the code AND a config problem in Courier.
If I'd had no source code I would have been screwed.
So Mr Henning can't be that clever if he can't even see what the potential is
He's making the classic mistake of saying something is worthless to everybody when he means it's worthless to him
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
He claims:
99% of all documents are written to be printed on paper.
Hell, no! 99% of documents (besides programs) I write are emails.
I'm not nitpicking, this is a major flaw in the argument.
"Computers Allow People to Do things They Could Not Do Otherwise"
How is this a fallacy??...He cites perhaps the handful of examples in which it may NOT be true, but leaves out the seemingly unending numbers of examples in which it is in fact very true.
- Telephone switching
- All the sophisticated computers running those F16s we see in Afganistan
- Power grid / sewage / water / gas control (in most areas)
- The entire Internet
- The level of visual effects in movies
- Computer and video games
- Thousands of different manufacturing processes that need to be computer controlled to get the level of accuracy needed
- Protein folding research
- and so on...
"The only point that didn't made sense in this summary was the one about "source code being useless"
It would have been better, perhaps, to say "for most users, source code is useless."
I remember when I was first getting started, and I head about Open Source. "Hey, cool, I can teach myself to write a word processor!" The truth, though, was that I couldn't. The code to any non-trivial program is going to be very hard to follow if you don't have someone walking you through it, or loads of time to work it through. And that's if you're a programmer. If you aren't, all the source code is good for is taking up space on your hard drive.
Thomas Galvin
While I think many of his fallacies have some truth to them (and I find them amusing), I think that his arguments only apply to business, or more specifically, they DON'T apply to a lot of areas where computers have revolutionized the way people do things, for example, in music composition, graphic design, scientific research, etc. - not to mention communication.
Let's consider Fallacy 2: Computers Allow People to Do things They Could Not Do Otherwise. This is not a fallacy, it's true. As an amateur composer, I can compose and print a piece of music in a tenth of the time it would take me to do by hand. I am not taking advantage of any automatic composition or any silly A.I. technology. I'm just taking about using Finale 2000 to enter in the notes using my MIDI keyboard, edit them quickly with the mouse, and listen to the result through my speakers to make sure I didn't make any musical "typos".
How about scientific research? Scientists now have amazingly powerful tools at their disposal. I know plenty of people who do need to perform a Fourier analysis on a daily basis (see Fallacy 7) and for people like this who are leading experts in Physics but know little about computers, a book like "Learn Matlab in 21 days" is all they need. I agree that you can't become a good DB programmer or QA person by reading a quick book or studing at DeVry, but most people who use computers aren't programmers and don't need to be.
While we were taking about scientific researchers, clearly "Computers are Getting Faster" is NOT a fallacy for them!
Finally, what about the Internet? Yes, the dot-com bubble bursted, but note that all major companies still have websites. It's silly to even consider a company not having one. E-mail definitely allows you to do things that weren't possible (or at least weren't realistic) before, like collaborate on a book or article with someone who lives halfway around the world.
Also, statements like "Programmers are Getting Better" are hard to really analyze. One problem is that there are hundreds of times more programmers now than there were twenty years ago. As a natural consequence, the average level of expertise has gone down a lot. But the best programmers today are a lot better than the best programmers twenty years ago - because they're building off of the best ideas of the last twenty years. And there's no question that even below-average programmers are far more productive today than below-average programmers twenty years ago, simply because there are more high level tools available to them. People who write Visual Basic scripts for internal company programs may be very poor programmers, but if they can get the job done, who cares?
< / RANT >
Sorry. Computers have definitely made my life better, and have enabled me to do many things I never could have done without them, so I get upset when people try to argue that computers suck and that things are basically the same as they were before computers.
It's not counterproductive to have people pushing the envelope, it's counterproductive to have people outside of the mainstream dictating to those in it what their needs are.
Despite advances in UIs, computers are still designed as general-purpose hobby devices, rather than for the specific functions for which the majority of their sales are used. When users complain that it doesn't make sense to have to log in to a system or to "start" a word processor, or to "double-click" to "open" a file through a graphical icon, they're simply told that they don't understand the technology. Same when they have to figure out [to avoid being scammed] what kind of RAM they need with their new P4 processors.
The point is that for products to be useful and effective, they need to be designed with more consideration for the needs of the user; and much of the time, that which is "neat" to enthusiasts has held sway over design at the expense of what would be useful [see featurebloat].
BTW: impractical thinking is not necessarily visionary. It might just be impractical.
Larsal
There are good points but I've got a problem with what looks like the unwritten assumptions that programs are all the same and are targetted at the same people. Let's see who uses:
-Word
-Matlab
-Apache
-Linux/Embedded
-AutoCAD
...
While you (should) want to make Word as simple as possible, you want to let Apache users configure everything, you want to let people modify the source to Linux(Embedded) to exactly fit their needs. AutoCAD needs lots of features, but not necessarly source code ('cuz there are less programmers in mec. eng. than ee)
So I'd add fallacy #11: Programs are all the same
-Software management should be done the same way, regardless of the software being produced
-All programs should focus on simplicity, not features
Opus: the Swiss army knife of audio codec
Money is not the only motivator for people to do work -- even skilled labor. Doctors who work in well-paid jobs in cooshy suburban hospitals routinely donate their efforts to free clinics and programs like Doctors Without Borders. Lawyers take on pro-bono cases for causes they believe in. Programmers write Free software. They all do this not for money, but for personal satisfaction, out of a sense of duty, or to gain experience they wouldn't get in their day jobs. Why do you feel it's appropriate to praise the doctors and lawyers who donate their hard-won professional knowledge to the world, but to deride and ridicule the programmers who do so.
Consider this - a volunteer doctor or lawyer can only help one person at a time, whereas an infinite number of people can benefit from the efforts of a volunteer programmer.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
I wonder just how far we've come in automotive technology since the 1950s?
/help documentation.
I mean, the cars don't actually go any faster. The speed limits aren't much higher, and if anything, the increased traffic makes us drive slower. Environmental improvements from catalytic converters and the like are nullified by the increased number of cars producing pollution. We add rear-window wipers and CD players, and instead of buying (or building) a more efficient vehicle we demand (and get) SUVs from every last manufacturer on the planet.
So, are cars actually any better, when any technological improvements are effectively nullified by the people driving them?
Well, yes, they are. Cars are more popular every decade because they're easier to use, cheaper to own, and more comfortable for everyone inside. They may not be "better" from a numerical perspective, but anyone driving a 2002 model right after driving a 1962 model will immediately notice the difference.
Computers are the same way. The faster they get, the more we expect them to do. The more people that use them, the fewer things they are used for. Developers get sloppier about optimization and APIs get changed with every iteration of the OS. It takes longer to start up this year's computer as it did 1979's, and people still do the same basic things with them.
But look at how much they've changed: graphical UIs make it easier for anyone to use a computer, instead of having to know what to type in at a text prompt. WYSIWYG doesn't happen 100% of the time, but 98% is a fair sight better than 0%. I may not get anything more interesting using a cable modem than I could using a 14.4 and a BBS, but at least all the commands are on screen instead of hidden behind a hundred scrolling screens of
So people are using all this computing power for nothing more than playing video poker and typing papers. So what? 90% of the population never needed it to do anything more; at least in 2002, they can do it for a lot less money and with a lot less reading. Companies and users may throw away countless man-hours developing skins and pretty interfaces, but at least they're successful in making computers familiar, comfortable, and desirable to the common man.
And besides, look at all the things we can do with a PC today that we couldn't ten years ago: access millions of pages of esoteric information online. Take photos digitally and organize them on CD-R discs, taking up 1/100th of the space for about the same cost. Listen to a thousand songs from a single digital jukebox, no vinyl or tape required. IM your mom across the continent without spending a penny on long-distance. Order anything from the Sears catalog without having to own the catalog. Find a new job. Locate a special interest group. Print a map. Comparison shop.
Or, just write and print out your resume. But at least nowadays, as with Henry Ford's first cars, you're not stuck with "any color you want, as long as it's black."
Or if you ask me. This guy has a few interesting points and a bunch of useless or fundimentally flawed points.
The one "decent" point is that people spend too much time dicking around with fonts and colors. But that's a problem that doesn't sit on a hard drive - it sits in the chair in front of the computer.
Fallacy 1: Computing is Easy, he shows by pointing out that there are "Teach Yourself" and "for Dummies" books. These are merely titles. He then points out things like "Air Traffic Control for Morons" is silly. Yes, it is, if you're going to be a professional ATC. But then, if you're seeing if you're interested in the field, or possibly getting caught up on a new system, it makes sense. These are industry specific publications - grabbing a copy of New Riders "Essiental Python" won't teach you Python if you've never programmed, but it will get you going quickly if you've done C++, Perl, etc before.
Fallacy 2: Computers Allow People to Do things They Could Not Do Otherwise This is not a fallacy. I don't have a typewriter, lightboard, razors, specialized photography equipment and a printing press. But I've used a multitude of layout programs and a printer, which is far cheaper and quicker to use. The fallacy he *is* showing is the concept of "Software automatically makes me an expert", which is not a common credo at all. In fact, most office workers will activly try to avoid learning new software because they don't understand that that field.
Fallacy 3: Computers Increase Productivity
Walk into an engineering firm or archetect firm and ask them if they want to go back to sketching blueprints. See if most small businesses have a CPA on hire anymore. He says: "It only took five hours to format this memo". If that's the case, the problem sits in the chair, not in the software. Your HR department should take care of that, not IT.
Fallacy 4: Programs Help Their Users Which he then says is a false because they are only focused on upgrades, money and crushing the competition. And yet, later he'll say why open source is useless. Um.
Fallacy 5: If It's Graphical, It's Easy CLI might be more "powerful" in the hands of a skilled user (I won't give mine up), but well done GUIs can be self explanatory (assuming you know the conventions of that UI). Again, he's phrasing this so it is self-fufilling. Of *course* there are lousy graphical interfaces out there. There are also quite a few easy ones. And I think the metaphor of windows is a very very good one in a computing environment when you are moving from task to task constantly (Letter, Email, Check the intranet for some numbers, back to the Email, task list, look up an phone number, make a call, pull up client records and make note, check email, write a letter). For very deticated tasks, it's less useful, but many real world users need to jump around in tasks. Even if it's a spreadsheet and solitare, as a receptionist listed as her "necessary applications".
Fallacy 6: Computers are Getting Faster Computers are getting faster, the experience is not. On my Apple ][, I could turn it on and in a matter of several seconds, be typing in a word processor. But then, it didn't have spell checking, fonts, and I couldn't make a spreadsheet larger than something like 32x64. Humans can only work so quickly, so as long as the computer can keep up, the coders will add new features. There is the issue of "snappiness", but that's a feel issue less than a task speed issue.
"We have come along and destroyed all the gains we have made in hardware" - no, we have leveraged them into more flexability.
Fallacy 7: Programs are Getting Better
He asks how often I make pie charts. Me? Very seldom. But for the guy down the hall who does financial pitches to clients, he really really needs that ability. How often do I embedd live info into a document? Not often - but the guy who manages the intranet does it all the time. How often do I perform a Fourier analysis? Pretty damn often - when I was in college. Had I gone into a different field, I would be stone dead if I couldn't.
His wife was trying to save a 2.2MB for a 2 page Word document on a floppy disk. Plain text, default font, left aligned. There was one email address, underlined. After 17 minutes of searching, he found a way to turn off this email address highlight off. The document was then saved at 800KB.
My comment: Then it wasn't plain text! We all *know* that Word's doc format sucks... so use something else (and yet open source has no advantages in creating sane standards).
Fallacy 9: Programming is About Date Structures and Algorithms
No... Program = Data Structure + Algorithms. Knowing how they work makes you a better programmer. Period. And Michi? I wrote a program using linked lists last week. Some of us do low level code for specific reasons.
Fallacy 10: Open Source is the Answer I agree with this one - again, because he phrased it carefully. Open Source is an answer, not "the" answer.
Fallacy 11: Standards all the Solution Right then, what is Corba?
Fallacy 12: We are Making Progress If you bought the shite at the beginning, I assume this makes sense.
Fallacy 13: The Industry Knows Where it is Goling Name an industry that does know what is in the future. Hell, name a *person* who is certain of the future and is not delusional.
This guy is a twonk, and almost dangerous: The best UI people on the planet are those working in the car industry. And yet people die all the time because the controls for AC and radio are off to the side and different in each car. I get into a new car, and I have to play for a minute to figure out the lights, shifting, etc... and I just forget about things like cruise control unless I'm on a road trip - and then I ask.
And finally, the biggest thing that shows what an idiot this guys is: We have to stop doing things just because they are fun. If you don't enjoy your activities and you aren't pursuing alternate activites, that's a pathalogical condition. You are mentally ill.
Me? I enjoy my profession, *and* do the best damn job I can do to make powerful, easy to use and useful solutions for my users.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
That's only a "fine point of design" to a 15-year-old. No, scratch that; it's not design at all. Any decent or even semi-decent compiler or interpreter should be able to make that particular optimization all by itself. A real fine point of design is whether to use events or threads, update or invalidate, distance vector or shortest path, this class hierarchy or that class hierarchy, this module layering or that module layering...stuff that can't be automated or even delegated to an inexperienced programmer.
Dream much? Ever hear of specialization? You're right that QA tends to get the short end of the stick in a lot of ways. QA engineers should have some programming experience, should attend (some) development meetings, should have more authority wrt the disposition of bugs...but they should not be checking in production code. Good QA is hard work, requiring its own specialized set of knowledge and skills. Any QA engineer who's making (and, one would hope, unit testing) their own changes to the production code is not going QA, and QA needs to get done. Hire another developer or extend the schedule, but don't take good QA engineers away from the necessary task that they do best to have them do someone else's job.
Slashdot - News for Herds. Stuff that Splatters.
I'll take this in reverse...
Our business is not writing this software.
I work for a law firm. Our business is to produce legal documents and legal arguments. Our business is not accounting, yet we have accountants on staff. Our business is not records management, yet we have records management specialists on staff. Our business is not facility maintenance, yet we have facility maintainers on staff. Our business is not programming, yet we have programmers on staff.
We want software that works, so we can do our business.
All commercial software is broken in some way (exceptions number in the single digits). Source code hinders your ability to have software that works. It follows that source code hiding hinders your ability to do your business.
what makes you think that throwing somebody at it in their spare cycles is going to help?
We have 400 attorneys. A bug (misfeature, non-optimized routine, poorly designed UI, etc.) that costs us three minutes per attorney per day costs us $3000 daily. (average billing rate is $150/hr)It may be worth our while to hire a programmer at $50/hr to fix the problem. Without source code availability, we have no choice but to burn money on a daily basis.
If the people who designed and wrote the software can't find the bugs
The bug may be specific to the way we use the software, or it may be preventing us from using the software the way we want. Perhaps we want a dialog box organized in the way that is most efficient for us. Maybe a program has its data path hardcoded and we want to store data someplace else. One program we have produces a hash that is used for the filename; I'd like to see a differenct algorithm used (for reasons to complex to go into now.) I'm hardly a programmer (I know a bit of C, a bit of VB), yet I'm confident that I could, by studying code, determine if these changes are feasible and locate where code needed to be changed. A pro could be hired to validate my opinions (or deny them!); another pro could be hired to do the work.
Here's another reason why source-code availability and the right to modify and recomile it is a good thing to have: companies go out of business. We use a program called Wealth Transfer Planning that is pretty cool; it automates the creation of wills, trusts, estate plans, etc. The company that makes it has disappeared. We are stuck with ALL our bugs and NO possibility of improvement to either the content or the engine.
The public benefit of open source and free software has nothing to do with economics. It has everything to do with learning and progress, and free access to source code is the key to advancing past the current stagnant backwater that computer science has become.
Let me explain.
Imagine that you're a young student who wants to become a writer. You ask your teacher, "What do I need to do in order to become a great writer."
Your teacher, if she has a bit of sense about her, will tell you to read all the works that you can, by the best writers, and learn from them. By recreationally reading and studying the works of great writers, as a young person, you will learn to recognize and understand, from experience, what differentiates good writing from bad writing. This is the educational process that, if you are both diligent and lucky, will turn you into a talented writer.
Contrast this advice with the world of computer programming. In the world of software, programs are distributed as object code -- meaning that you can't learn from them by reading them. Plus, they contain "licenses" that proport to deny you the right to study them to learn from them. Any programmer who obtains surreptitious access to some major program's source code is running a serious risk of being unemployable -- as a legal liability.
It is as if our original hypothetical budding author were told:
"If you want to be come a author, you must be sure to never, ever read anyone else's books, especially popular books by great authors. The way to become an author is to wait until you are of college age, then enroll in a two year "writing school", where you will learn grammar and spelling, sentence structure, and then write a series of short essays. For your final project, you will write a single chapter of a book co-authored by the entire class. Once you are completed with this two year course, you will have your degree, and, having only studied textbooks, will be fully qualified and ready to join the workforce as a writer, uncontaminated by exposure to real-world writing experience.
If this were the way we taught writing, then our novels would show the same lack of quality -- and lack of progress as our software does right now!
So how do we fix this problem?
I believe that the answer is to reform copyright law. The current system of closed source, proprietary programming technology -- and the lack of any noticable progress in the craft of programming -- reflects the complete failure of copyright law brought on by the extension of copyright protection to proprietary software.
Patent and Copyright law are supposed to promote progress by placing the best examples of science and technology into the public domain, where they can be studied and learned from. If I want to learn about any physical science or engineering discipline -- if I want to catch up to the current state of the art, all I need do is go to the patent databases and -- right there, are thousands of examples of the latest, real-world scientific technology, written by actual scientists working in actual companies on actual products -- all there for me to study and learn from, and, 17-20 years after disclosure, to freely draw upon and use.
This is the public benefit of the patent system -- the dissemenation of practical engineering and scientific knowledge. This is supposed to be the public benefit of the copyright system. Copyright is supposed to be a tradeoff. Copyright is supposed to provide monopoly benefits in exchange for publication -- public disclosure. This works just fine in the case of natural language writings, because the source code is the product, but not for object code, where the product can only, for all practical purposes, be used -- not studied and learned from.
Copyright law could and should be used to leverage a similar public benefit, however, in the case of software, our legislators have completely missed the point of having copyright in the first place. The purpose of copyright is not to protect authors. The purpose of copyright is to create the next generation of authors -- to "promote progress" -- by encouraging the publication of works.
Imagine an alternate universe in which copyright protection were only afforded to software that was distributed in conjunction with full, buildable source code. Companies would have to choose between copyright protection, and DRM protection, instead of the current dysfunctional system, where they are able to effectively obtain copyrights on works that are at the same time, in effect, trade secrets.
In such an alternate universe, young programmers would start out as computer users. However, if they became curious about how their software worked, they would find the source code to their programs waiting for them.
Like the young, would-be writer with a library full of books, they would have the entire world of software to read, study, analyze, and learn from.
One objection to the source code requirement for copyright protection that I have heard is that it would encourage code theft. If companies distributed the source code to their products, I have heard it said, other companies will steal their work and incorporate it into their own code.
The answer to this objection is that, under such a system, they would not be able to do that because it would be trivially easy to detect such theft. If I were to steal a portion of the Windows source code and add it to my program, then went to market my program, in order to obtain copyright protection, I would be forced to distribute my source code -- with the stolen Windows source code imbedded. Microsoft would discover it and shut me down.
In this way, mandatory disclosure of source code would severely limit, or effectively end the practice of code theft. Who's to say who is stealing code today? It's nearly impossible to tell, when only object code is published.
Fortunately, free software, and to a lesser extent open source software is bridging this gap. Yesterday's young budding software writers had little to work from. The new generation of young software writers -- and I am talking about high-school age students -- have the entire GNU/Linux/Gnome/KDE system to study and learn from. Free software is the only software that earns its copyright. It's the only software that "promotes progress", because it's the only software that can be freely studied by the general public. It's a functional replacement for the public domain that has been lost/destroyed by misguided, failed copyright law.
In other words, just as having access to a library of great books is everything to a young, budding writer, having access to quality, real-world source code is everything to a young, budding programmer.
In a certain sense, it's probably the only thing that really matters.
But, the people that design and position the steering wheels, pedals, shifters, turn signals, gauges and door handles in such a way that *anyone* can go from one car to another without *any* difficulty or re-education
The example I give is this: I once drove a friends car in the dark. I drove it on city streets for close to an hour before I realised the turn signal lever wasn't a lever, but a little switch on the dashborad. However that switch was right where my fingers expeced it to be, and worked just the like the turn signal lever of any other car I ever drove so I didn't know that it was a completely different implimentation!
Unfortunatly not all things are like that. When I drive my dad's truck I often trun the headlights off on a rainy day, his headlights switch is where the whindshield whipers on most cars are.
Another point is that
function bob( varlist ) { $var = $joe + 12345; return $var; }
and
function bob( varlist ) { return $joe + 12345; }
might actually be the same number of operations. Not because of the compiler, but just because of the way that the machine works.
Regardless, as said before, this kind of micro-optimizing is pointless and dumb. It is not programming it is coding. Coding is a mechanical process. Programming is an art. You can optimize your code, but it is almost imposiable to optimize an API. Designing APIs is where I think all modern languages have totatly failed us. It is way too easy to write a bad api with todays languages. I've had to implement too many crazy interfaces written by people who didn't think them through. I've also created interfaces that later I went back and scrapped because they were dumb. This is the way programming is and it doesn't make any sence.