Slashdot Mirror
The Limits of Software
Background
Before I launch into my latest review, I'd just like to say thanks to Hemos and Slashdot on the occasion of my twentieth review posted here. It's been 25 months since the first one (August, '98), and I've really appreciated the opportunity they've given me. Nice excuse to do something I should do anyway! :-)
The Scenario"But it is not the practitioners alone who are so moved. A thousand years in the making, the religion of technology has become the common enchantment, not only of the designers of technology but also those caught up in, and undone by, their godly designs. The expectation of ultimate salvation through technology, whatever the immediate human and social costs, has become the unspoken orthodoxy, reinforced by a market-induced enthusiasm for novelty and sanctioned by a millenarian yearning for new beginnings. This popular faith, subliminally indulged and intensified by corporate, government, and media pitchmen, inspires an awed deference to the practitioners and their promises of deliverance while diverting attention from more urgent concerns. Thus, unrestrained technological development is allowed to proceed apace, without serious scrutiny or oversight -- without reason. Pleas for some rationality, for reflection about pace and purpose, for sober assessment of costs and benefits -- for evidence even of economic value, much less larger social gains -- are dismissed as irrational. From within the faith, any and all criticism appears irrelevant, and irreverent." (TLOS, xxiii)
-- David F. Noble, The Religion of Technology, as quoted in The Limits of Software
I had the privilege of spending a few weeks with a good friend of mine in Eastern Europe back in July. Of course, to go anywhere on a budget in Europe requires a lot of train travel. Alas, there are no bullet trains in Slovenia, which gave me plenty of time to take in some reading when I wasn't chatting with my fellow passengers ...
The Limits of Software is a unique book in many ways, not the least of which is that it reads more like a collection of life stories than a lecturing textbook. Most computer books simply give you data, or even information, in a straightforward manner, hopefully punctuated by some interesting anecdotes. Britcher, instead, has packaged with words slices of time which illustrate various points about where computer programming has been, and where software development is going (note the terminology change). I certainly won't try to describe them all, but theme which runs through the book is illustrated in the opening quotation: software is not our savior. There is no "one great system" that will be able to handle things. The FAA's botched air traffic control system is used as one illustration in the book, but the point is made about all software: we cannot and must not worship it.
There's one point that I find simultaneously funny and sad: It's in the chapter on testing, and the inherent futility of such an activity on complex programs. Britcher discusses the Y2K bug, and mentions the survivalist movement.
"Just as regular folks built bomb shelters in the 1950s and 1960s to add life time to a planet white with nuclear snow, regular folks are now storing large caches of food, water, toilet paper, clothing, and, of course, the American twinship: sacred literature and ammo. One man who agreed to be interviewed for the piece was quoted: 'When you first hear about it, most people are in total denial. They can't believe that Bill Gates won't come up with a magic bullet.' (That the general population believes that Bill Gates has the answers to our programming problems is more frightening than the rollover of the millennium.)" (TLOS, 59)I quote this not as a shot at Bill (although, this being Slashdot, I'm sure some will take it that way), but to point out the inherent risks in the statement, which illustrate Britcher's point. Software is dangerous, because it does so much yet is so fragile. We (even we programmers at times) view it as a holy grail. We cannot understand how our mechanical saviors could possibly fail us. Yet, software failures are rampant, in every facet of our society (see the Risks Digest if you need examples). Software cannot solve our problems. Our problems are inherent within ourselves. As we continue to rely more and more on machines to live for us, we must remember that they, like their creators, are fallible. What's Bad? / What's Good?
When I finished TLOS, my first reaction was to think of the old saw about the life of a fighter pilot: "hours and hours of sheer boredom, punctuated by moments of sheer terror." Britchner's stories seemed to drone on at points. The FAA story was left to the end. Why did he have to go on and on about all this random stuff?
In retrospect, though, I think I have a better grasp of what Britcher was trying to convey. This is not a disaster movie told in the guise of software engineering; this is a story about one man's journey through software, and the conclusions he's come to. Read this as an technological autobiography, and I think you'll appreciate the points being made. As I said earlier, it's different, but rewarding in the end.
So What's In It For Me?A reminder that the Tower of Babel still lives in the hearts and minds of men.
You can purchase this book at Fatbrain.
Table of Contents- Foreware by Robert L. Glass
- Prologue
- Part I
- Early Systems
- Theories of Programming
- The Human Element
- Designing
- Code: The Stuff of Programs
- Testing Computer Systems
- The Impossible Profession
- Life on the Project
- Part II
- Supervision Through Language
- How Technology Changes Methods
- Size and Intellectual Gravity
- The Marketing of Science
- Errors
- The One Great System
- The Government of Programming
- The System to End All
- The End-All of Programming
- Afterward
- Reading List
"hours and hours of sheer boredom, punctuated by moments of sheer terror."
:)
funny, that's pretty much my life.
how about: "hours and hours of coding, punctuated by moments of delirium."
or: "hours and hours of sheer boredom, puctuated by lunch."
Rami
--
rJames.org - illustration
That aside, everyone should check out Bookpool. Their prices are even cheaper than Fatbrain's (most of the time) and I've never had a problem with them.
Just trying to help the little guys,
psxndc
The emacs religion: to be saved, control excess.
I bet there was some ancient Sumerian who gave long lectures on "The Limits of Literacy" warning that we shouldn't worship reading and writing--those skills can't make our lives better. Imagine his face if we were to show him a modern, industrialized nation.
It's a poor workman who blames his tools. If there is a way for an air-traffic to be controlled by a system, and your air-traffic control system doesn't do it, the reason is not inherent in the "limits of software"--there's some problem with your design/implementation. Software is a universal machine simulator--pure algorithms implemented as 1's and 0's. If that idea isn't worthy of awe I don't know what is.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Anyone having used voice dictation software could tell you that.
Pay no attention to the man behind the curtain with all your metadata.
On a related note, the trains in Europe are great places to read. The book seems to be a case of "common" sense. Of course software isn't a magic bullet. Expecting it to be is rather like expecting the royal road to geometry.
I think computers and software should be developed and used to assist us and make our lives easier, however at no point should we become so reliant on software that we would not be able to function without it or have great difficulty doing so. I think we are at that point now. It's a very serious matter. Most of us consider redundant backups for electronic equipment in case it goes down, but what backs up the electronics? Sure, there are those who are very carefull, but we as a society are in bad shape.
my local small town book store has a web site where I can enter the ISBN for any (in print or at least avaiable) book and they will put it in their next order. I pick it up there, but since it is in town it isn't a big deal (and I don't worry about it arriving in the rain). I pay sales tax, but avoid shipping. I support a small town book store that gives me a place to look over books for those that are worth reading.
Now if I just had time to read...
Unfortunately it's a valid point - no piece of software ships with all of its bugs fixed, or even discovered (note that when working for software companies these two things are not synonymous). A decent testing department given a reasonable amount of time can spot many of the more obvious bugs, but for every obvious bug there will be a dozen sneaky ones which ship.
You can guarantee that it'll be the end users that'll find these bugs, and that they'll complain to whoever sold/provided them with the software. Remember, end users can be relied upon to use the software in the most convoluted, even stupid, ways, and when they're doing something in a manner the programmer didn't anticipate chances are they'll find bugs.
This is why I think that for any large software project an open database allowing customers to report bugs is essential. As long as the programmers work on clearing these lists then problems get ironed out over time, and making sure patches are freely available reduces the number of flaws in a program and makes everyone happy.
Another problem that introduces a lot of errors today is the increasing use of third-party components and applications within software projects. These introduce another point of failure, and one in which the programmers have less control over what goes on, and less knowledge about possible solutions. Even if you have the source for the component, it's still much more likely that using it will introduce problems, either in the interface between your app and the component, or in the component itself.
The solution? I don't really think there is one that can guarantee perfect reliability. The best you can do is ensure that the number of problems is kept to a minimum, and that problems that are found are quickly dealt with.
I know people who go to the opposite extreme -- they see the problems with tecnological developments (auto pollution, atomic weapons, and the like) and take the attitude that technology is evil, or that it often is used that way.
Both the worship of techology, and the hatred of technology seems to me to miss the point. Technology is simply a tool. It can be used to create good things, and bad. It can result in good side-effects, and bad.
Speaking specifically of software development, there are times when people outside the field look with awe on the process of creating code. That ignorance of the process may contribute to those extreme ways of thinking about technology. Once you know how something works, it gets de-mystified in your mind and becomes just another tool or skill. Programming, I tell people, is like playing the piano -- it's a skill that can be learned, not magic.
Similarly, technology is a tool, not magic, not a panacea, not the solution to human problems by itself.
________________
________________
Private Essayist
only by the ability of the human mind to manage complexity. I'm tempted to fit Gödel's incompletness of formal systems in there somewhere but that seems to imply an UNlimited condition rather than limited. If 'software' is something inbetween mathematics and hardware, we see that the ability to count toward infinity is limited only by the physical realization of the computer (register size, etc).
As for fragile software, just try to 'diskcopy' a Linux boot disk in NT4-BugFix5, hehehe.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
...Are defective users. ;>
I find it ironic that the opinion that technology can't solve our problems comes right after a story about Dean Kamen, who thinks technology can solve our problems.
My personal feeling is that it can solve a lot of our problems permanently (hunger, disease, etc) however it won't spontaneously happen, it does require people and their priorities to change too. If a large enough portion of this planet decided tommorow that clean burning engines, safe drinking water and better agriculture were the areas they wanted to focus research on instead of the latest electronics gadget, then eventually we would solve those problems. In a certain way, technology is the answer, but only if society puts effort/money into moving technology ina certain direction.
I am definitely going to read this book. It seems to be hitting on one of the biggest problems facing humanity today, which is the elevation to a religion of the scientific method of observation. I agree with some of you that technology itself is only a tool, and that attacking technology is pointless. However, the faith that human beings put in their technology, and in the skills and logics that produce it, is profoundly disturbing. I agree with the reviewer - it's always good to have a reminder that the Tower of Babel will always be somewhere lurking in our collective consciousness.
If more companies used Formal Methods such as 'Z' when designing software, we would not have to endure the current deluge of patches and 'service packs'
The downside is that I know it costs a lot more money to develop using Formal Methods, but isn't it worth it to have better quality software?
I am a programmer and have had problems reported in my apps that were "User Problems". That is the user wasn't using the app as designed. The real problem isn't the user though it is the design of the app. If the app were designed so the user could understand it there wouldn't be a user problem Now I realize that not every app can be usable by every user, but if 90% of problems are the users, then it sounds like the app wasn't designed for 90% of the intended users.
As x approaches total apathy I couldn't care less.
Most of the time the user doesn't spend any amount of time "playing" with the application and getting to know it, or even a complete lack of common sense. The crys to the help desk to ask how to "bold" something pretty much proves that.
Not forgetting the classic help desk query
"where's the any key"
I have long thought that software was just a fad and will fade soon. The old days of designing complex systems with just a few vacuum tubes will eventually prevail and you'll be throwing away those worthless laptops over a Eniac simply because it looks cooler!
Software is fragile -- but that is a problem only if you don't recognize this fact and are unprepared to deal with it.
Yes, the world depends more and more on software. Yes, there is no such thing as a bug-free piece of code. But failures need not be catastrophic. It is perfectly possible to build robust systems, ones which assume that something will crash and are able to deal with it.
It's all really risk management. Software can fail -- but so can mechanical parts. So far, at least, the biggest problems (like Chernobyl) were caused by human error, not a software glitch.
Robust systems can be build out of fragile components.
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
Can I use your icons-in-front-of-shops example in the future?
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
test.c:1: `#include' expects "FILENAME" or
:-P
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
Yep, completely spaced the ;> Sorry.
As x approaches total apathy I couldn't care less.
Right now I'm in the computer lab, on a Dell OptiPlex GX110 with 256MB of RAM (funny, Windows 2000 regcode stickers on each computer's right side, and they have NT4 installed. One step forward, two steps back). And, for some lame reason, the Real Player "Start Center" is in the taskbar. I closed that damn icon on about 3 stations; it's just 3MB of memory being taken up. I kinda hate this; I'm in a college where people are learning the very programming language I've come to hate: Java. I sincerely think that Java is a lazy excuse for the programmers to clip off minutes from their coding schedule just so they don't have to wait through compiling code. I say, program in C++, the compile process is my most favorite! It is the defining moment which determines whether you have made progress or not.
As for the rest of my opinion on software engineers, see my quote, and think of this quote from TRON: "Oh that'll be great. Programs will start to think and the people will stop!"
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
First, thanks for the review.
That said, humans are fallible. What can we expect but that the artifacts they create will also be fallible? There are assuredly limits on software - limits on computability - but the limits I see here are more limits on human ability to describe solutions to problems that become larger and larger as the simpler ones are mastered.
As for technology as religion, it's not religion to me, it's a source of comfortable living.
Now, if only I could stop my VCR from blinking "12:00....12:00...."
668: Neighbour of the Beast
Readng this review brought to mind an anecdote shared by an old professor of mine in a class discussing the need for completeness testing and mathematical proof of algorithms.
The incident related was to do with the testing of a new auto-pilot/terrain following system being installed on the Tornado fighter-bomber (the British air-to-ground attack aircraft). All was going well with the test flight until the aircraft dipped into a valley. Shortly after entering the valley the aircraft inverted and performed the classic 'lawn dart' manouver.
There was of course an insuing investigation and analysis of the auto-pilot software during which it was found that this exact behaviour would occur if the altimeter returned a negative value.
How could this happen? The valley was below sea level.
--
The gift of death metal does not smile on the good looking.
While moving toward the paperless office (Storing all of our records on magnetic digital medium) we are potentially setting ourselves up for catastrophe. We do not know what all exists in space, but lets say something happens, and it sends a _REALLY STRONG_ magnetic wave to earth. BAM! All of our data goes bye-bye. We might not even know it until we've lost all of our data. And then, if the magnetic wave is permanent, we may never get our precious computers back on line. I know this sounds paranoid, but the smaller we get, the more fragile we get as well. I see this as a potentially dangerous trend.
Engineering and the Ultimate
I don't think it's possible to work out all of the bugs in a piece of software, simply because there are too many unseen variables. But I also don't think it's fair to cast software development in a different light merely because it is subject to the same "rules" that govern any complex system. As a means of comparison, consider how long it takes to implement a new commercial aircraft design. Consider how many defense-related projects are, or have been over budget, poorly designed, or scrapped altogether. It was, after all, a hardware "bug" that caused the explosion of the Challenger shuttle. Hell, I'd argue that it's even a hardware "bug" responsible for the Firestone debacle.
Is it fair to hold software development to a different standard? No matter which complex system you're dealing with, it always involves getting from point A to point B, and it's not always going to be an easy ride.
I figured someone would be stupid enough to state the obvious pun in that sentence. Most of us merely noted it and moved on.
________________
________________
Private Essayist
With one piece of hardware (the x86 instruction code, for instance) you can create millions upon millions of software applications. One piece of software, however, can usually only be made to run on a small number of pieces of hardware.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
It's easy to say that we should avoid any risk of failure. But what does that really mean? The real question we should ask ourselves comes down to risk versus reward. Does the potential benefit outweigh the potential risk? Even where the costs of a total failure are high, that doesn't mean we must avoid it.
Take our telephone infrastructure for instance. It's provided society with tremendous and undeniable benefits. Yet the possibility of a total failure is not an impossibility, and certainly wasn't earlier. Would we really have been better off avoiding it because we could never absolutely insure against catastrophe? I'd argue that the costs of avoiding it, of being overly risk averse, far outweigh the benefits that each and every generation has had. Worst case scenario: the telephone networks in the US fail for a couple days. That'd cause some chaos certainly and it might cost the US billions. But I'd argue that having not used it, or having forced excessively costly redundancy [back when before we had digital technology and the like], would have cost the US most of the benefits of the 20th century (i.e., trillions of dollars).
This is not to say that where affordable precautions become available they should be shunned. That factors into a risk/reward equation. Now certanly there is plenty of room for debate about what is an acceptable level of "risk", but the point is to show that even where apparently extremely costly worst case scenarios exist doesn't necessarily mean avenues of progress should be avoided. Nor do I mean to say that everyone has taken a rational approach to risk/reward; certainly there are some instances where it's been totally out of whack. In the vast majority of cases though, it's been my experience that the people that run these systems are nothing if not risk averse. Because they fear failure more than they probably should, the systems generally are acceptably safe.
But you have to pay in time and money.
Read They Write the Right Stuff
A very readable article from a few years ago describing, at a high level, some of the efforts needed to become SEI 5. Use this as a benchmark to measure your software endeavours - and when looking at books describing the fragility of software.
Want to see some proof of this slower performance claim? Go to a Windows machine with Quake3, and go to The ShugaShack. Download the 1.17 DLL files for Quake3 and place the DLL files in the \quake3\baseq3 directory (you'll see uix86.dll and qagamex86.dll, quake3.exe will use these instead of ui.qvm and qagame.qvm). Voila! A 15% performance gain! And all because the DLL files are already compiled, unlike the QVM files which are compiled at runtime (evidence: the console message saying "VM file qagame.qvm compiled to X bytes of code").
Before you arrogantly defend the putrid mug of steaming, flaming code, be sure to study its nature. Ever wonder why the DeCSS code was never written in Java? Want to know why XMMS uses .so files? That's right! RUNTIME PERFORMANCE! I believe that this should be the be-all end-all factor of programming.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
Software is unlimited, or at least a lot more unlimited than this apparently shortsighted book book points out. Over the next 10 years, genetic and evolutionary programming methods will take over where human 'formal' logic programs cannot. According to the creator of Mathematica, Stephen Wolfram, nearly everything is a form of computation. The Earth's complex biosphere is a perfect example that extremely computations are possible. There is no fundmental mathematical reason why software cannot emulate the same degree od complexity.
www.enthea.org
Incorrect math is not math. 'Nuff said.
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!
OK. I thought at first you were trolling, but I've come to the conclusion you are just monumentally stupid. There is a huge difference between Java and Javascript. That 'source code' you are looking at is probably Javascript. Java code is deployed precompiled in .class files, you can't read the source unless someone gives it to you.
"Want to know why XMMS uses .so files?" - No. I don't care.
"RUNTIME PERFORMANCE! I believe that this should be the be-all end-all factor of programming." - enjoy yourself, with your assembly language programming- moron.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Software design is in its infancy, more magical incantation than science.
We start with incomplete design documents, unknown inputs, and impossible to predict interactions. Still, we get complex monstrosities to run with an extraordinary level of reliability. All this using a mechanism that is totally unrelated to the biological processes have built reliable systems for billions of years.
Software will grow up and start solving general problems like biological systems. Throw in the software evolution and software development will have reached the level of maturity where we can truly judge its impact.
- Java does not "always compile on the user (sic) side." It is much more common for Java applets and servlets to be running as middleware on servers these days, for portability and standardization.
- If you're talking about the scripts that are embedded in HTML code, that is javascript, a Netscape invention, and has nothing to do with Java(tm) the Sun programming language. Embedded HTML scripts, of course, are always executed client-side, just like VBScript, ActiveX controls, and DHTML.
- You are so woefully misinformed on this topic that people are mistaking you for a troll. Why don't you go look up the difference between Java and Javascript sometime, instead of just making stuff up that you overheard somebody talking about once?
- If run-time performance is the only thing you care about, perhaps you should take a class in Assembly language. Assembly programs have runtimes on the order of magnitude of 20-100X faster than compiled C code.
I don't usually even bother to respond to people who flame whole languages without even knowing the basics of said languages.The days of Java applets being downloaded and executed in a JVM in the client's browser are long gone. Microsoft killed them by "extending" the Java Virtual Machine that comes with Internet Explorer (which is bundled with Windows blah blah blah), breaking most "cross-platform" Java code in the process.
However, your posts are written as if you think you're some sort of programming expert, which you obviously are not, if you can't even tell Java from Javascript.
Free music from Jack Merlot.
Unfortunately, there will always be a disconnect between specs and code. Programming languages have cruft and artifacts that will always force code != specs.
..., An Experiment in Software Prototyping Productivity" about a programming language experiment. The Naval Surface Warfare Center had programmers implement a "geometric region server" (a component of the Navy's AEGIS system) in their language of choice. Program length and development time for each project are compared for the different languages. The surprise "winner" was an extemely concise program written (by the paper's author, of course) in the functional programming lanaguage Haskell. The other languages have so much cruft that eventually makes the code look nothing like the "human readable" spec.
;-)
Here's an interesting paper called "Haskell vs. Ada vs. C++ vs. Awk vs.
Compare!
LANGUAGE, LINES OF CODE, LINES OF DOC, DEV TIME (HOURS)
Haskell #1, 85, 465, 10
Haskell #2, 156, 112, 8
My favorite quote from the paper:
"In conducting the independent design review at Intermetrics, there was a significant sense of disbelief. We quote from (CHJ93): "It is significant that Mr. Domanski, Mr. Banowetz, and Dr. Brosgol were all surprised and suspicious when we told them that the Haskell prototype P1 is a complete tested executable program. We provided them with a copy of P1 without explaining that it was a program, and based on preconceptions from their past experience, they had studied P1 under the assumption that it was a mixture of requirements specifications and top level design. They were convinced it was incomplete because it did not address issues such as data structure design and execution order."
cpeterso
LANGUAGE, LINES OF CODE, LINES OF DOC, DEV TIME (HOURS)
Haskell #1, 85, 465, 10
Haskell #2, 156, 112, 8
Ada, 787, 714, 23
Ada9X, 800, 200, 28
C++, 1105, 130
Awk, 250, 150
Lisp, 274, 12, 3
cpeterso
Unless I missed something and my world is actually identical to feudal Japan?
That's like that middle ages guy saying, "Let's make it our goal that by 2000 half the world knows how to read and knows how to operate printing presses, binding machines and book distribution."
No, no, it's like him saying "Let's make it our goal that by 2000 we will have invented the typewriter and photocopier", and if more people had thought like that they'd have been here in half the time.
Programming can be a natural human skill that everyone takes for granted, we just need to develop better ways of doing it, ways that make the operation of a program as tangible to an inquisitive four year old as the eviscerated remains of his clockwork toys.
ways that make the operation of a program as tangible to an inquisitive four year old as the eviscerated remains of his clockwork toys.
See, that's what I'm talking about. You're coloring the world through your own filter. You're making an assumption that all children enjoy taking things apart to figure out how they work, and that simply is not true. Yes, most people on Slashdot probably enjoy understanding how things work, but the vast majority of the population couldn't care less. People are different, and have different skills, interests and thought processes.
For example, my wife loves to cook. I hate to cook. I know that I could learn to do it if I really tried, but I have zero interest in learning. It's not because I wasn't given an easy-bake oven as a child, it's simply because I have no interest in it. Conversely, my wife has zero interest in learning how computers work. Absolutely zero. She's extremely intelligent and could learn if she wanted, but she will never care. She learns exactly as much as she needs to know in order to operate a computer, and that's it.
--
Sometimes it's best to just let stupid people be stupid.
Sorry, but you have no idea what you're talking about.
Our present urban population densities cannot be maintained without out present technologies. That's not the same thing as our present level of population. Many of our rural areas have become depopulated over the last decades. Wes Jackson estimates that, according to the best archeological evidence, his area of Kansas supported more population in pre-Columbian times that live there today.
You are presenting your assertion as fact, and laying a classic ad hominem on anyone who might disagree with your "fact."
If today's technologies are unsustainable (and there's good evidence that they are), isn't it "genocidal" to advocate marching forward blindly until the crash happens? Better, I think, to look for "soft landing" scenarios -- which do involve "back to the land" and "rolling back technology."
There are several disproofs by example for your thesis, but I will simply name one -- the Amish. The Amish way supports a higher population density than the "English" techno-agri-business way, with less environmental impact at the same time. Keep in mind that the Amish do innovate technologically -- the key is that they most emphatically do not worship technology, but subordinate their technological choices to their religious and cultural priorities. If only the rest of us were so wise as to keep technology our servant rather than our master.
You could say that writing is a tool, but... Some people would start religious wars about their holy writings (yes I'm referring to the bibles of the real religions, not Emacs vs Vi :-).
nosig today
My programs that require the user to press a key after reading something tell the user to "press a key." If the literal-minded luser reads too much into it, (s)he will press the [A] key (or the [1] key in foreign translations), which obviously works. And it saves a couple bytes too.
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
Gates's law: The speed of Microsoft software halves every 18 months, supposedly to balance out so-called Moore's law. At the current rate (Word needs 600 MHz), the 10 GHz mark will be reached after about four doublings, or six years.
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
The Java Platform's class libraries and security model are not the best: no preprocessor ergo no macros and no #ifdef DEBUG, few or no inlining hints, huge memory overhead per allocated Object, poor String handling (partly because String is final), no destructors (facilitates denial of service), et fucking cetera.
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
Assembly programs have runtimes on the order of magnitude of 20-100X faster than compiled C code.
Assembly language is also one stage in the compilation of a C program. The speed of an assembly program typed by you is no faster than the speed of an identical assembly program generated by a compiler. Besides, nowadays, compilers know their target machines' schedulers more intricately than the average asm programmer does. One of the only times asm would be useful is if you are using bleeding-edge features (e.g. vector processing) that the compiler's language can't take advantage of.
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
Here's a great example: Unreal and Unreal Tournament are written entirely in Java. The mouse has an incessant 30ms lag (and this is a USB mouse), and sound has about the same lag. On the same system, the entire Quake series runs perfectly (no mouse lag at all; with the USB mouse, m_filter isn't even necessary!). How do you explain this, and the 15% performance gain when Q3 is running entirely on C?
I must admit, my definition of Java was too broad, but my main argument of incessant latency still stands.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
That's kinda funny, Sun and Netscape could have been sued by the DOD for creating a breach in national security! Okay, maybe I'm stretching that one, but still, the DOD is a tangible symbol in the argument against Java.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
Civilizations existed quite happily for millenia without the "progess" we think new technologies will bring us
...and were then crushed when progressive civilizations decided to move into their territories.
The purpose of progress is not a more pleasurable life (as many have discovered, and enshrined in religions and philosophies that ought to be considered forms of insanity, perfect eternal happiness is simply a matter of learning to ignore your sensory input), but survival. The societies which progress and become stronger crush those which grow more slowly.
Putting the brakes on and deciding that you've progressed far enough is societal suicide.
--------
found a copy of it here
He considers several improvements to programming including high level languages, OOP, AI, etc. He concludes that many of these improvements will help programmers, but that programming will continue similar to what we know now: both powerful and problematic. While this is somewhat dated material, i think it is still accurate and makes some valid points.
Essentially, as programmers we are blessed to work with some amazing and powerful tools, but they are still tools and we are still human.
I hope this post looks okay, my /. connection at the moment is very crappy and the preview button is not working.
Perhaps this is the next phase of the maturity of the software development profession. (A few years back New Jersey was thinking of this, but mostly as a scheme to raise revenue.) We'll have licensed Software Engineers.
California will have to do it first.
Steve Magruder
Steve Magruder, Metro Foodist
"We should take care not to make the intellect our god. It has, of course, powerful muscles, but no personality."
"..don't you eat that yellow snow."
As for your lag problems, who knows. I have a P-II 350 with an ancient Voodoo2 card that runs Unreal just fine. I'll grant you that the Microsoft Java Virtual Machine is damned slow to start, though.
Free music from Jack Merlot.
the same Department of Defense that got rated a D+ in their security audit last week? And we're supposed to look to them for an example?
heh.
Free music from Jack Merlot.
Fertile soil is created, by nature and by good husbandry, and destroyed by bad farming practices. The world has lost half of its topsoil in the last 50 years. This is a result of technology being applied intensively to the land for the purposes of making money.
Technology is a tool, like a hammer or an explosive, what counts is how it's used. This planet could support a population of 12,000,000,000, using essentially 19th century technology. The changes would have to be social and political.
I know little of Kansas (sorry, Toto), but in the Australian outback one family often struggles to make a living (grow enough to feed themselves and earn enough to pay for other necessities), on land that once supported more than 200 Aboriganal Australians. As for the American Indians "primitive agricultural skills", we are talking about a people who lived in harmony with their land for thousands of years. When you can support yourself in a truly sustainable way, perhaps then you can indulge in looking down on other people. It still won't be a nice thing to do though.
- Derwen
http://fsfeurope.org/
Easy 1) It's not java, it's C++ (small amounts of ASM optimizations
2) The engine sucks, and the renderers, save the Glide one, suck
Tim Sweeney could use a smack with the OpenGL bible........
A D+ without Java is better than a big honking F with Java
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
True enough. Hey, if you're interested in running secure sites, or even just interested in computer security in general, check out OpenBSD. It was designed to be secure from the ground up...
Free music from Jack Merlot.
My auxiliary system is a Celeron 466 with 192 MB of RAM and 2 Voodoo 2's; I figured I could play old school Unreal again. The mouse STILL lagged, and version 205 was, plagued with some bugs (reminds me why I upgraded to 209 when I had the 233MMX with the V3).
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
As I said before, JavaScript has little or no relationship to Java, and in browsers it's implemented by the browser vendor, so you can't really blame any security holes for JavaScript on Sun or Java.
Read my keyboard review.
There is nothing in your rant with which I would disagree, Paul. However I obviously phrased my original post badly as all replies missed the point (or perhaps I shouldn't have jumped into a thread on the Amish, I know little of their supernatural beliefs - my concern is with good husbandry of the soil).
My point related to technology being neither a good or bad thing in itself, merely a tool. To when technology and progress have been regarded as an end in themselves, particularly (my area of concern) when applied to the soil.
Your (good) examples all point to the results of a short-sighted greed . That is why I suggest a more far-sighted approach to land management, if we (the population of earth) are to continue to eat, shelter and clothe ourselves, nevermind the important things we all want. Here is some more locally-applicable info for you.
By the way, I followed the url above your post. I will read the essay when I have enough mental space to consider these issues again.
- Derwen
http://fsfeurope.org/