Slashdot Mirror
Why Software Still Sucks
atlantageek writes "The man who brought you (or somebody else) virtual reality speaks to upside about the sorry state of Software." "The Guy" is Jaron Lanier, and the article covers a fair amount of stuff. This isn't a super smart technical article, but its got a lot of interesting comments on subjects ranging from software, Linux, open source, Unix,
DeCSS, and more.
The thing about software is that you, dear reader, can create it. We should _expect_ that fact, the fact that anyone can do it, to cause exactly the chaos and prevalence of mediocrity and plain badness that is being complained about here.
...") that we find it hard to resist. And all this time it just all seems so _possible_. In a theoretical sense, it is--but the razorlike reefs are right there under the waves. Even when we are going down we often don't see why we failed.
Consider the huge difference between software "products" and other machine/tool-like things. Suppose you want to make something--say, a can opener. Most of us understand, in principle, how a can opener works. I think most of us can look at any given can opener (they're pretty much open source, after all) and understand its design. But what would it take to create one ourselves? Lots of money, basically. Not-commonly-available tools, parts or the tools to make them, space to put all of that stuff. Who's going to do that in their garage? Maybe some person with a vision of the perfect can opener and dreams of changing the way everyone opens cans? But, of all the people that dream of changing the way everyone opens cans (already a tiny number of people, I would guess), how many of them could even afford it, or could convince someone to fund it?
It's just not likely to happen. So can openers, by and large, are going to be designed only by companies with access to the materials and tools _and_ a bottom line to worry about--meaning that they're not going to do it half-assed.
Now switch your brain to the world of software tools, and instead of a can opener, think of a recipe database. Heck, I wrote one one day, and I thought the other day about web enabling it so my family could share recipes over the web. It doesn't, as has often been observed, mean that I _should_--but I can, I know that I can, and all it's going to take is a little time (but "little" is, of course, _very_ deceptive). The tools are right in front of me--except for the hardware, that you could probably get for almost free, everything is free. All it takes is time. And I have (at least some) time. So I can. So I might. And so, many people do.
Okay, that explains a lot of the crap that's out there, but what about the commercial stuff that's also crap?
A similar thing happens at software companies--although the perception is not correct, they _think_ they can. That same "we have the tools, we just need to write the code" mentality is alive and well at software companies. It's relatively easy for an engineer to say "okay, metal gears of this size and spec will cost this much, but it will be this much if you want plastic. if we eliminate this button we save X dollars and get rid of some possible breakage issues which we rate as an X% probability in normal use". Quick, how much does a javascript function to validate input on a form cost? There's no easy way to answer that, no book to look up the numbers in. Because "all" it takes is for someone to sit down and write those lines out, and because, once those lines are written, producing the next copy of them costs nothing, designers are led down a very deceptive path to a hugely complicated structure that quickly becomes hard to understand, hard to coordinate the interactions of the different parts of, hard to test thoroughly, and hard to deliver on time.
Once you get into that situation, you have to cut corners, slap stuff together, do the absolutely necessary stuff, and suddenly you're plagued with a poor user interface (because that takes time, understanding, and developer buy-in to get right), ugly bugs (because you didn't have time to develop, much less run through, an exhaustive set of test cases), etc, etc. And then is when you come up against the wall, and you find out that, while all this time you were thinking out oculd, because the tools were right there, you actually _can't_, because you _don't_ have enough time.
Basically, the feature sirens are always calling us to the rocks, and the song is so beautiful ("We could make it compatible with
--
Liberty uber alles.
Of course, you really want to be saying to a computer "put that file somewhere around my home directory" or "Format that hard drive, make it about a third of the drive" or "Cad program, make that sewer pipe about this long" (holds hands apart).
Computers are an exact thing, they need to be handled in an exact way. The command line provides that exact way. The number of times I've been using Corel Draw and wished I could just type in "box, 2in x 1in" rather than have to click and fiddle with the mouse, having it jump 0.1" bigger when I release the mouse button. Angles in circles are even worse.
Rich
Ever seen OS/2? OS/2 is butt-ugly. It's config.sys makes DOS/Windows look elegant by comparison. But you would never guess this from the UI, which puts all other UIs to shame. How did they do it? They put a powerful layer in between: SOM.
The same sort of thing can be done with Unix, it's just that no one has. Oh wait, someone has: Apple has done it with Aqua. A very different approach than OS/2, but still, the UI is completely divorced from the inner workings. I haven't used Aqua yet, but I know that when I try it, my reaction is not going to be, "This is Unix. I know this."
The open source movement hasn't done anything like this yet, because they are too busy trying to compete with Windows. As long they keep looking to the worst UIs for inspiration (e.g. MS Windows Explorer) and try to infiltrate the corporate world by blending in (e.g. Miguel's mailer that looks just like MS Outlook), that's just how it's going to be. But it doesn't have to be like that. The GNOME/KDE guys have set their sights very low.
Could have? That sounds like present-day OpenBSD and Linux, respectively.
As for my explanation as to why software sucks, I think it's pretty simple: the economy has judged that software that sucks but is cheap, is preferable to software that doesn't suck but is expensive. Quality takes time, and time is money. I write software-that-sucks for a living, and whenever I give a customer a choice between something that sucks for 8 hours or something that sucks less for 16 hours, they almost always take the cheaper choice.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
-rwxr-xr-x 1 root root 158740 May 1 1999 /usr/bin/pico /usr/bin/joe /usr/bin/jed /usr/bin/vim
-rwxr-xr-x 1 root root 180484 May 1 1999
-rwxr-xr-x 1 root root 256972 May 1 1999
-rwxr-xr-x 1 root root 503832 May 1 1999
Any of those small enough? How about
-rwxr-xr-x 1 root root 47656 Apr 30 1999 /usr/bin/ed
The problem here is the fact that a weird OS like Linux is effectively bringing the Unix-world back like a plague that won't be exterminated.
*giggle* 'snort' heheI... BAAAAAAAAhahahahahahah 'snof' hehhe.. What, um.. makes you think it ever disapeared?
Dirty Pirate Hooker
While it's probably the case that software today is too complex to get all the bugs out, the situation could be vastly better than it currently is. There is a lot of discussion of current software problems and what to do about them in Risks.
It is frequented by many esteemed experts in software architecture, reliability, security as well as just plain folks. The bug anecdotes reported there are often pretty funny but sometimes frightening and sobering too.
I think anyone who works with computers in any substantial way should read Risks.
Michael D. Crawford
GoingWare Inc
-- Could you use my software consulting serv
Heck, I was born here in the USA, and I've been trying to speak English for ~23 years now (some would say that Americans can never learn proper English, but that ain't right ;-) So, it took me (let's say) 10-12 years to master English, but I can "Learn Perl in 21 Days" and "Learn C in 7 Days"... or, if you want to be picky, a good semester course in Models of Computation could have one fairly fluent in C, Lex, Yacc, and a few others in a fairly short time. Programming / scripting lanuages are more direct and precise, since computers aren't very adept at guessing what we really mean if we are ambiguous...
I think I had a point, but I must have forgotten it by now... shoot, it probably just boils down to a "Me Too!" post by now.
--
"It's tough to be bilingual when you get hit in the head."
Meeting at the beginning of the week to determine which new features/bug fixes would get implemented that week.
Three days of programming, followed by a cut to CD-ROM at the end of the third day. This cut could be at any time, once it occurred after midnight.
On Friday test everything to make sure it worked, including 100% components that had not even been touched in the previous month. Ship to customer no matter what was found, but report bugs at the following Monday meeting.
No wonder the software never worked properly. Problems were being introduced due to tired developers. Not enough time was spent squashing some really evil bugs. And one developer was so utterly hopeless he should have been fired.
I don't understand that one. I never want to sit in front of my computer and hope it works this time.
Understandable. Perhaps it's more easily understood another way: How much time, effort, and money are you willing to put into the reliability of this app? Is 99% enough (quick and dirty hack), 99.9 (some actual engineering), 99.99999 (detailed regression analysis of every posable input and verification that the output is correct, multiple redundant everything, years of work and still not 100%).
The answer depends on what the software does. If it maintains your life support it MIGHT be in the many nines category or you might decide it's better to go for 99.9 and provide manual controls (the Mir approach). It might be software to fly a negative stability jet that cannot be controled manually at all. In that case, the 99.9 solution won't work.
If it's just a 1 time need to process some text file, 99% is overkill. Just bang it out in awk, sed, or perl and call it good.
I don't want my browser to ever mis-format anything or crash, but I'm not willing to pay $1000 for that.
What I found most interesting about this article (and I have read the original Edge paper, too) is that Jason Lanier believes that Unix's "Command Line" somehow pervades the whole operating system, forcing a structure and perhaps attitude onto all higher layers of the the operating system. Needless to say, he doesn't like that structure much (although he probably understands the Unix CLI much better than most people here.)
.png files, raw 600-dpi scans that are 100MB each. And then I have another directory of .png files that are all 256 x 256 textures for a 3-D game.
But nonetheless, I think he's wrong. I can give two counterexamples that show that the Unix command line structure does NOT force a "Unix-y" structure in a GUI:
1. OS-X (Macintosh Aqua on BSD).
2. Quake III (Easy to use UI that looks and works the same on Windows, Linux, and Macintosh.)
I think the real straitjacket that UI designers on Linux constantly have to fight against is X Windows, which is my favorite candidate for "What's Worst About Unix". I don't want to rant about that right now. I have a different rant.
I would like to see Linux innovate more, and I agree with Jason Lanier that some real user interface capabilities do depend on the lower level properties of the system. For example, both Windows and Linux both essentially understand the "type" of a file by looking at the last few letters of the file name: ".exe" or ".tar.gz". At least Linux has a separate attribute for "executable", but still, this is a pretty pathetic way to identify files. A step in the right direction would be to store a little extra information in the file system, like the mime-type of the file, and the name of the program that created it. User interfaces could put that information to really good use.
Given a directory full of pictures, some with the extension ".jpg", and some with ".png", at least the user interface can guess that they are all graphics. But what if you put a new file in the directory and mistype the name, calling it "pgn". Well then, it won't show up in dialog boxes that are looking for graphics files, and when you double-click on it in a file manager, who knows what will happen? Mime-types in the file system would fix this.
Another example: Suppose I have one collection of really huge
Right now, if I double-click on these in a file manager the same program will be used to open both of them. But I might want to use different programs to view and edit these files. Having to open the program first and then hit the File,Open,Browse, view another list, select the file, etc. when I was just looking at it in the file manager is stupid.
So that's one example of how Linux could innovate. Of course Macintosh fans are snickering right now. I suppose "Resource Forks" can do this sort of thing. I wonder how those are implemented on the OS-X file system?
So how about we put mime-types and other useful data into one of the new filesystems - ReiserFS, Ext3... Journaling is not the only improvement to file systems worth doing.
Torrey Hoffman (Azog)
Torrey Hoffman (Azog)
"HTML needs a rant tag" - Alan Cox
Ironically, Linux gets an "F" in this regard, or at best a "D", and Windows gets an "A". The API documentation in Linux is effectively absent. I know I'd be a whole lot more productive if I had as good documentation as what Windows programmers take for granted.
--
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
I'm not so sure the hardware realm is as pure as it seems. I'm far from a hardware designer, but I've perused some of the Linux kernel source and have seen many comments about broken hardware designs. Of course, the obvious examples are probably the various Pentium bugs (FDIV, FOOF, etc.) but I was initially thinking of my (t)rusty Intel etherexpress board.
Maybe it doesn't matter to anyone other than driver writers, since performance is improving.
In other words, bad design or implementation impacts users of the interface that an object provides. So a crappy piece of hardware gives headaches to driver writers, but a buggy word processor gives headaches to end users (and their IT support staff...)
And if it's running windows, you get an extra "Blue-Screened Monitor Paperweight" at no additional charge!
--The space between my ears was intentionally left blank--
I think that you are right about the design issue. When we are taught computer science, that is stressed very heavily, and you spend most of your time designing software, and working out logic, flow of information, data structures, etc...
But that is not how the software that _people use_ is built. Many companies have discovered that by having a flashy new feature or a higher version number out on the market _faster_ they will attract users like flies to sh*t. The problem is that designing software takes time, and users are antsy and want it now, so they put up with shoddy software (and even hardware) just so they can get the latest feature. I tend to prefer designed programs that i don't have to upgrade every 5 minutes, but then as a programmer i have a skewed view. If i were a normal consumer sort of person, i'd be going ape about the fact that i'm still running a browser that's a version old, and i'm still using a UNIX variant that's built on "30 year old technology". UNIX was designed, people sat down and thought it out before writing it, and that is the only reason it's held up so well; It still solves the problems it was designed to solve. Most people who are constantly cusring UNIX are just not aware that they are asking it to solve problems that would be better solved by some other OS that fits their needs.
That being said, software will get better when the average user demands it. The computing community already knows how to make software that works reliably, stays useful, consistant, and solves the problems it was designed to solve. The problem is that users keep buying software that doesn't work. This may be because they don't know or can't express what problems they really want the computer to solve. The author even states that a lot of his frustration with UNIX (as a good example piece of software) comes from trying to implement VR under UNIX. The trick is that the operating system under a VR rig needs to solve a very different set of problems than the operaying system used for a time-share application server. VR wants realtime, prioritized execution, lots of small asynchronous tasks, wheras UNIX solves the problems it was designed to solve (sharing resources fairly among users, networking, and being a portable base upon which to write software for computational taks). This may be a communication issue between users and developers, or it could be an artifact of agressive marketing and the need to keep users running the upgrade tredmill to keep the bottom line up. In either case, i think that the main problem with software is a human communication issue, from what i've observed.
---
Play Six Pack Man. I
It seems to me, hardware is engineered better (or just simply *more*), because the barrier to entry is high. You don't just create a graphics chip by typing at a keyboard. You need a logical design. Written/drawn down, entered through some circuit construction program. You need real physical materials. You need to undergo an expensive process to make those materials into a physical embodiment of your logic. If you screw up, well, back to the drawing board.
Software on the other hand has a very low barrier to entry. Got a compiler? Got an editor? Great. You're now a software "engineer"! Tappity tap. Hello world. Tappity tap. Hello enterprise. Tappity tap. Hello critical infrastructure. It is simply too easy to "just" fix this, or change that. What if every civil engineer decided that they would "just" tweak this or that parameter and see what happens? Or maybe they'd "just" fix the one faulty bolt. It doesn't happen (plus, a major advance of the industrial age was standardized building components, which software still has very little of). Software engineers, managers, and the industry, need to think of the bytes that make up their software as important as an actual constructed, engineered structure, that one shouldn't make whimsical changes or additions to without much consideration and peer review. Because literally, badly designed software ends up costing just as much, or more, than real physical structures.
It's 10 PM. Do you know if you're un-American?
...this guy is a great example.
First, the usual false statements ("Ultimately UNIX is a command line system", "UNIX was so primitive in the 70's compared to other systems...")
"CPUs are so ideal...software is such a lagger" If that's true, go build a corporate web page in one day with nothing but transistors, ass. It's been done with development tools on the market today.
Ahem, many UNIX library calls have no CLI influence whatsoever...they existed BEFORE the shell!
Primitive to what systems? DOS? DOS disn't exist in the seventies...digitals' RTX? Quite like DOS really. The call infrastructure is cleaner under UNIX according to most old timers I've talked to.
Windows2000? I've used the win32 api...golly, many of those system calls look like they were lifted right from Unix. Just what OS is so superior to Unix?
What a bunch of fanboy crap. Here's my official response: "Wannabe dreadlock-hairstyled, artificially-color-enhanced-contact-wearing musicians who hang out in tribeca coffee shops yapping about how much software they didn't write sucks...should be shot for being the asses they are"
Anyone wanna refute that?
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
I think actually the kernel is of very high quality, compared to competing operating systems like the windows kernel or the Mac OS system, but it does take a long time for the kernel to get the kinks worked out.
I realized when I got onto the Linux-Kernel mailing list to report a bug in 2.4.0-test a few months ago that people who were less hardcore developers would probably be put off by the process of reporting bugs to the kernel, and suggested this database to the kernel mailing list. It was generally well received.
In the long run, I'd like all of Free Software to be more rigorously tested for quality. This is just a start - but the database source, and parts of the database itself could be reused for other projects.
If you'd like to participate, please email me at crawford@goingware.com
Michael D. Crawford
GoingWare Inc
-- Could you use my software consulting serv
So I take it there's more freelance hobbyist programmers out there but zero freelance hobbyist QA people? Darn. Wonder if I could make some money doing freelance testing of other people's open source work.
Excuse me?
Your list of questions applies to *any* engineering field. You need to ask the same questions if you're building a bridge. Does this mean that we should try to keep the field of "engineering" from fragmenting? Sorry; it already has.
"Software engineering" (somewhat of an oxymoron, IMHO) will fragment, just like any other field, as the skill sets needed for the various aspects of programming drift apart. Would you want a pacemaker designed by a video game programmer? Would you want a video game designed to medical implant standards?
BTW, your last question is not really a matter of engineering, software or otherwise. How does a pacemaker "decrease the amount of repetitive work that humans have to do"?
--
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
Ask emulator authors how complex a processor is. While marketing departments talk up the pipelines and cache aspect, it's not very complex at all. It's just a big state machine. Software implementations of processors are very good. But who wants just a processor?
The point is, hardware is split up into discrete packages. Your CD-ROM drive cannot, no matter how much it wants to, write directly into your processor's cache control bits. You cannot edit the value stored in the 13th pipeline status area. They are protected! In hardware, you cannot break the API. It's pins on a chip, there's no other way in to the silicon!
But in software, you can access everything about the API, and 'hack' it. Bleah. Software, to be as safe as hardware, needs full Java-like encapsulation, where you cannot poke inside the box at all.
Furthermore, there are far more varied software components depending on each other than you would ever find in a hardware device. Imagine a desktop computer running a web browser and word-processor. There are thousands of individual widgets in both programs. One requires a TCP/IP stack and network driver underneath that. Both require user-interface APIs which in turn require graphics APIs and input APIs, which in turn require drivers. Just imagine a hardware device with 500 Pentium 4, 120 StrongARMs, 50 Z80s, 20 6502s, 100 MC68000s, 12 different bus protocols, hundreds of ways to access the hardware devices (forget those ATAPI, IDE and SCSI standards...)
In short, even the simplest looking computer system is a nightmare under the hood. Even if I simplified all _my_ code, I would still have far more code running from _other_ people that I cannot change at all. That's why it sucks. Hardware guys have it easy.
Does my bum look big in this?
Generally I frown on "Oh yeah? Write it yourself!" responses but in this case they're appropriate. You think people are opposed to the idea of a new paradigm that makes life perfect? It's just a lot harder to come up with them than it is to sneer at and berate people for doing things the old way.
And having Joan Baez endorse Jaron Lanier's views on software engineering doesn't make me take him more seriously. On the contrary.
Yes, but when I drive my car, do I *TALK* to it? No, I use appropriate controlling devices for the situation: a steering wheel and pedals. Yet my bicycle handles and pedals are very different. As are airplane controls. The point is, there is no one *perfect* interface. CLI is just wrong for some things. As is a particular type of GUI, etc.
It's 10 PM. Do you know if you're un-American?
Both you and your pro-GUI respondents are entirely correct.
When one wishes to converse/command, one talks or writes.
When one wishes to wield a tool, one grabs it and manipulates it.
What is the right way to use a computer? I don't know, but I bet it involves each of them at different times.
"You can't get something for nothing." - my grandfather, on the stock market and Reaganomics.
... is because he is partially correct.
:)
:-(
Most software does suck. (You'll have to forgive me if I tar all software with one brush.) Windows has it's problems, Linux has its problems. Anyone who can't critically analyse the deficiencies in their favorite software is either living in a dream world, a zealot, or blind. (No flames intended.)
The root of the problem is: bloat.
Every time we get faster hardware, we build bigger programs. We're doing so much more with the hardware nowadays -- who was doing speech recognition 20 years ago? Heck, we can partially do it in real-time now ! The latest 3D games are certainly a good example of this. Lots of nice eye-candy. *cough* Alice *cough*
The software we are building, is MANY MANY times more complicated then a 740. And the fact that we don't have off-the-shelf standarized components certainly doesn't help.
Which leads me to my next point:
The software has SO many code paths, there is NO way we can verify and spend enough time on quality assurance. And there will ALWAYS be bugs in the code we write. That sucks just as much as the bugs do.
Lastly, how many programs spend and designate time to develop a good user interface. That's also part of the problem - too many programmers (open source/closed source, doesn't matter) couldn't put together a good gui layout if their life depended on it. How many have taken a UI design course? How many are asking management to allocate time in the schedule for "polish." (As a game developer I'm just as guilty. Beta = fix all the important bugs, and ignore the small ones since we don't have time to correct it. Maybe we'll do a patch, if not. Next game to start developing.)
And I think the greatest tradegy of all, is that people have come to expect computers as being unreliable.
Why can't we apply and have a "process for engineering high quality software" ? Is code that nebulous? Is it because we keep over-complicating the systems?
People aren't perfect, which means code isn't either. But it wouldn't hurt if more people took the time to say "how can I write this code, so it's easier to maintain, and something to be proud of, instead of something that is hacked together, works, and would be an embarrasment to show to your peers."
What are other people's views?
> What's the average age of a gung-ho Open Source development team? 21? ... I'm not talking about old standbys like Perl and Apache and so on
Are you saying that if you filter out the projects where the average age of the developers is older, you are left with an average age of 21 on the unfiltered projects?
--
Sheesh, evil *and* a jerk. -- Jade
pov-ray creates it's images based on an interpreted language (Yes, it's not a CLI as such but neither would you create an image with a graphical shell so I took your allusion to somewhere sane).
Many times with a technical illustration, I've wished I could create an image with words ("box 0,0,3.5,2;circle 3.5,2,1" would be so much easier than "try and draw a box to the right dimensions with mouse, try and center circle somwhere on the top right corner of the box. Guides are a help but start to fall down with anything complex.
Rich
I've seen solid hardware from several different vendors that almost does exactly what it is supposed to... but even that is usually the third time (or more) that the chip has been put in silicon (whether full A-RITs or just more B-RITs, for those who understand that TLA).
Hardware, especially in a development cycle, is a moving target - granted, the changes don't happen as quickly as a code rebuild, but often the subtleties are a lot harder to notice...
--
"It's tough to be bilingual when you get hit in the head."
So why, if I may ask, does open source projects suffer from the same problems?
No, this is not flamebait. This is for real -- although there are a few open source projects out there that really shine, you've to admit a lot of open source projects are kinda buggy, and seem to suffer from the same problems as proprietary software (although you could argue they are less so because problems are easier to fix when anyone can see the source -- but the problems are still there). And this is for people who are coding because they like it, not because they are under pressure.
I think there's more to software quality than just pressure from upper management, etc.. Like other posters have said, and like the article said, there must be something more fundamental about software that we still don't quite grasp.
Poll Mastah
First of all, "All operating systems" doesn't mean Unix and Win*.
I've considered this point quite a bit over the years. There is no way of a GUI getting entirely away from the command line as long as the base OS is still based on the command line. None!
The other side of the coin is that the command line falls naturally into place with a heirarchal file system. As long as we have the one, we'll have the other.
The Macintosh (of all things!) did it right in many ways. The command line is an extra tool--not the base level of the operating system. The Mac GUI _is_ the OS, to a greater degree than any other system out there.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Cruising at +1, and on this topic, I'm a little surprised to find that this was the only reference to Ada.
Ada gets a bad rap for it's roots in government, its verbosity, and the rather straitjacket nature of strict typing. But guess what... it wasn't designed for rapid programming, or to make programming easy. Ada was designed for the 20+ year lifetime that code may well have after it's put into use.
The same things that slow the start of coding help the lifetime and maintenance. It takes the willingness to accept some discipline and take a longer-term view.
Think of the people who never thought their code would survive to Y2K.
The living have better things to do than to continue hating the dead.
OK. But a CD player is called on only to do a small number of tasks. Most cd player apps for computers duplicate a similar interface. I think the issue becomes how you handle more complex stuff.
Who is to say that a command line driven cd player wouldn't be better (or a better example, a cd jukebox or mp3 player with lots of storage).
Pushing icons one after another would imho be far more cumbersome than simply typing (or saying)
mp3> play all songs by Nirvana in random order followed by the predefined mix entitled "punk-party mix", then around 2:30 AM switch to the predifined mix entitled "bach-piano-concertos"
The challenge is to devise a command line language that is both intuitive and powerful -- such projects as the latin perl project offer some hope in this regard.
The command line has gotten a very bum rap, primarilly because no thought went into devising a coherent language. Instead cl languages have consisted of a small collection of arbitary commands, akin to the grunts and gestures of our cave dwelling ancesters.
I find it more than a little ironic that, as computers take on more and more capaabilities, the language the users uses to interact with them becomes more and more dumbed down. I suspect we are going down the path where we replace alphabets with pictograms because pictures are easier for an illiterate to grasp, only to discover that, when that same user later wishes to write a novel, they are forced to use something akin to egyption heiroglyphs in order to communicate their ideas: a writing form vastly more complex and difficult to use than the 26 letter alphabet the illiterate in question should have just learned in the first place.
The Future of Human Evolution: Autonomy
I'm betting you'll find just as many closed-source projects that are as bad, if not worse. Open-source is not a magical cure for all your coding woes, but it does help with a lot of things and has many high points. As you pointed out, Perl and Apache are well-engineered, as are the Linux and/or BSD kernels (dependant on opinion, though) and many other standard tools.
Yes, there are bad open-source projects started by people who are 20 or 21, but consider how much they'll probably learn in the course of those projects. Especially if some more experienced programmers get interested and start showing them ways to improve their processes and code.
-RickHunter
It appears he hates Unix, not software as such. But he makes the same error as most other who do, he equates newbie unfriendly with user unfriendly. Which are not the same at all.
> The vast majority of software is a question of implementation, not algorithmic logic. It seems like it's a lot more complicated to prove implementation than algorithms.
Actually, it's rather straightforward for a mechanical prover to read the source code.
> There are currently a very small number of people with both the analytical skills and the severely rational temperment required to do these proofs.
Much of it can be done by machine. Also note that there once was a very small number of people who could write programs, but now millions can. Why not set out on the same path for the methodology of creating formal proofs?
> And that correctness (or, more likely, bugginess) lives in the code, and in the code alone, so that's where you have to weed it out.
Per above, you have proposed a solution to what you thought was the problem.
> It just seems like it'd be no fun.
No one said QA was "fun". The question is, do you take enough pride in your product to make sure it's right? Also, per above, mechanical provers is the way to go.
--
Sheesh, evil *and* a jerk. -- Jade
And if pico isn't powerful enough give nano a try, it's got the same friendly interface with some added features.
I do not have a signature
I think we just need to realize that 100 amateur programmers writing and reviewing code, ad-hoc, is not necessarily better than 10 professional software engineers working closely together, using some semi-formal procedure for specification, requirements, collaberation, and coding.
A lot of the most successful open source projects, were originally created by professional programmers (Unix flavors, including BSD; Apache; Mozilla; GNU utilities in general), and still retain some form of regimentation. Linux would not be were it is if Linus et al. let every single developer add their patches in, or modify code, whenever they wanted. Unfortunately this is exactly what happens in many new open source projects under the banner of "freedom"...which ends up producing remarkably mediocre code.
It's 10 PM. Do you know if you're un-American?
what i got out of this was that Lanier thinks we are stuck in some tech-limbo, one where neither the software nor the laws governing the use of software are very useful. well, that and UNIX is old and ugly. Big deal, people still use it, and that doesn't automatically mean that it sucks.
And his comments about "humanity" not knowing how to make software, or even what software is, were just plain over-dramatic, hippified philosobabble. After all, why is he discussing it then? Is he not a part of humanity? Or, is he better than us mere mortals?
Plenty of people know what software is and how to make it. The focus is to make it more intuitive, faster, and less prone to Bad Design.
sig not found
Duh, it's a story, it's *not real* dummy.
If you want some semi-plausible explanation, try that as I recall, they actually address the thing "Computer do this"
And back to your point about instructions in foreign language, you have to remember that the conventions of pictograms are a learned thing as well. There's nothing "natural" about an arrow meaning "this direction" (ask any Floridian) and if you've ever tried to learn something by watching someone do it, if they don't describe what they're doing, it's very easy to get it wrong (e.g. "Insert this rod into this hole but make sure it's the end with the blue mark". If you weren't told, you may not have noticed the blue mark )
There's a reason that Macdonalds cash registers have pictures of food on it while any serious programmer works in words. And that is because words convey more information in a less ambiguous way.
Rich
Well, I think one of the reasons that software sucks is a disparity of ambition and attention span.
I often think of software as a branch of practical philosophy -- at its heart, it is simply applied reasoning. The idea that software engineering is the solution to software quality is as flawed as saying that moral or political reasoning just boils down to plain logic. Logic and software engineering are necessary in their spheres but not sufficent.
A good piece of software is one which is good in many dimensions -- in its data structures, decomposition, architecture and expression, to be sure, but also excellent in other ways:
* Understands the user's characteristics and motivations
* Understnads non-users who are affected by the system.
* Fills a void in the range of available products.
* Peforms well in terms of stroage, speed or latency.
* Utilizes sustainable technology (i.e. is reasonably future proofed with respect to platform and interface issues).
* Has an excellent user interface.
* Has excellent graphical design where appropriate.
* Fulfils any ethical obligations it has (e.g. handling of sensitive private data; protection of human lives).
As an aide, Asimov's Laws of Robotics kind of encapsulate the some of this -- a robot has to follow orders (suitability to task, user interface), a robot may not harm or by inaction allow a person to come to harm (ethical and societal concerns), a robot must protect itself (sustainability and robustness)
Getting back to the issue at hand, the number of dimensions to be optimized is daunting, and requires time and deep thinking -- the kinds of things that go out the window under a deadline or in hierarchical organizations with pressure from superiors with very limited perspectives.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Short of coming up with a new definition, the only hope for improvement is to shove developers' noses in the problem until they finally get the point.
IMHO, neither of these will help.
I've worked with some really brilliant programmers in my time, and those people collarboarted to produce some of the crappiest code you can imagine. All of us knew that what we were doing was going to hurt us in the long run, but we did it anyway--not because we wanted to, but because we were told to.
It's a good developer's natural inclination to take the time to properly design code and not release it until it's ready. Unfortunately, that runs counter to every business and management rule there is.
If you work for pay, your boss is always going to pressure you into taking shortcuts, putting in quick hacks instead of designing real fixes, skimping on documentation, etc. Their main goal is to put out whatever fire is in front of them before their boss gets called in. That situation is repeated at each higher level, and at each level, it's less and less likely that the person making the decisions knows building software from laying bricks. Ultimately, the main direction of your development process is set by people who aren't concerned at all about the quality of the code.
When the process sucks, the code will suck. When the code sucks, the quality will suck. But as long as you keep closing bug reports fast enough, your boss will think you're doing a great job.
IMHO, this is one of the key reasons free (in both senses) software will always drift to a higher quality level than commercial software. Dollars cause bugs. Take the money out of the picture, and the a lot of the incentive to write crap goes away.
That sounds communist, but I don't mean it that way. I simply mean that we should be prepared to accept the inevitable consequences of the way most software is developed today. If you want to change the state of software, either change the incentive, or (since money is an awfully good incentive), change the way that incentive is given.
IMO, the biggest reason for sucky software (and a reason that I haven't seen mentioned yet), is the *lack* of market pressure for quality software. Lets face it, users are at a point of almost expecting their apps to crash.
Should this come as a surprise when software comes with an EULA which disclaims any wartentee, forbids examination, (unapproved) benchmarking, etc?
In the US this position is being bolstered by new laws such as UCITA and DMCA.
Thanks to the lack of robustness of widespead OSes like Win95, the average user has had to deal with enough crashes/inconsistencies and general oddities, that they don't expect much, so thats what alot of companies deliver.
Whilst Windows may or may not be easy to use it is definitly difficult to administer and fault find...
As the author of the article points out, hardware is getting more complex and better. But hardware is designed. It's designed, tested, built upon, etc.
And while we're all taught that we shoudl use proper design for software, few of us take it whole heartedly. Sure, we might do a few object models, flow charts, etc. But how many of us use propositional logic and predicate calculus to prove our software will work as it is intended? And still further, how many of us have unbiased testing of our software?
I think the larger the corporation, the more of these practices might be enforced. But it is still up to the programmer to truly adhere and take these to heart. I don't think we quite have the discrete tools that hardware designers have. Nor do we have the worry that once the circuit is printed, you can't easily "fix" it.
Garbage.
I had to use a W98 machine the other day, and if froze. I'd never used W98, and wanted to kill the task which had disappeared up its own arse.
How do I run the task manager? Or is that "TaskMgr", or "TaskMan", or the other "TaskMan" (NT has 3 executables with that kind of name!).
Right mouse button click on the Task Bar (ooh, "task" bar - may be there's a task manager on it?) failed to offer me a task manager. Crap. Hmm, is there a keyboard method?
In NT it's C-A-Del, but in older Windows that rebooted the system. Dare I press C-A-Del?
Eventually I had to, as there was nothing else I could do. OK it worked, but that was guesssork.
I don't know if it would work on W95, and hope to never find out.
The graphical system - being different in each evolution of Windows, completely failed me.
On a command line Unix system I only need to know 3 things, which have been constant since time immemorial
a) ps b) kill c) if all else fails - man.
Which is easier to learn
"on 3.11 do XYZ, on W98 do ABC with the mouse or PQR with the keyboard, on NT do JKL with the mouse or NMO with the keyboard"
or
"ps then kill"
You've chosen your method. You can have it. I'll chose my own thank you.
(Haha, 32MB video card, and I spend 99% of the time in the text mode consoles, as they are more efficient for me!)
FatPhil
-- Real Men Don't Use Porn. -- Morality In Media Billboards
Also FatPhil on SoylentNews, id 863
When you get home at night, and you MOTAS/roomies ask how your day was, do you
When you have to describe a particular method of doing something, do you
A. Draw lots of pictures?
B. Use numbered steps with words?
I remember a book by an AT&T fellow about data compression and information theory. Two teams had to put together a mechanical device, one team member had the instructions, one had the parts, and they were separated. One team only had an oral link, the other team had video, too. There was no difference in the amount of time needed to build the device, the added video link added nothing.
HDF does Lanier plan to interact with his computers, pretty pictures? Waht ajoke.
> I think we just need to realize that 100 amateur programmers writing and reviewing code, ad-hoc, is not necessarily better than 10 professional software engineers working closely together, using some semi-formal procedure for specification, requirements, collaberation, and coding.
Agreed. But how many of the COTS products loaded onto the average workstation were developed with that degree of professionalism?
--
Sheesh, evil *and* a jerk. -- Jade
Niggly Software
TCP/IP specs, BIND, ipfilter
Jiggly Software
xv,mpeg_play (for viewing pr0n)
Stupid Software
VB, Perl (oh, how the flames roll in...:)
Sexy Software
AI^H^H CD-ROM^H^H^H^H^H^H Web Brows^H^H^H^H^H^H^H^H^H B2C^H^H^H B2B^H^H^H P2P^H^H^H uhh... Gnutella?
Pain in the Ass Software
office integration suites
Soul-sucking, Time-stealing, My-project-will-be-three-months-late Software
Everquest, Quake, Half-Life, Tetris, xboing
Brain-bangingly Tiresome Software
Oracle
Vapor Software
a real GUI for Unix, a command line for Macs, a crash-resistant Windows
Potato chips are a by-yourself food.
In my experience, there are only human impediments to successfully creating healthy software. Technologies are sufficiently developed in most languages that most software can be written fairly efficiently using a wealth of frameworks and libraries. So why does software suck?
Combine time-pressures, market pressures, upper-management pressures, and a lack of training and professional standards, and you have a whole class of employee (the project manager) who has only incentives to lie and hedge, and no incentive to be honest about schedule, feature set, state-of-the-project, internal project problems, etc.
Assume a project of 15 people, with a 3 million dollar budget, and a project manager leading four teams. That's pretty complex stuff to manage. Now what if it's business critical, and he's getting letters from board-members and C*O staff imparting the import of the project unto him from on high. Can you say pressure cooker?
Now consider that three developers are fighting, and every teaser this manager has sent up the chain about problems has resulted in a standard "we expect you to solve this on time and on budget" no-help answer.
Now imagine that some contractor or 3rd party vendor that the architect and project manager had made noises about to upper management lied about their capabilities.
Now imagine that his buddy frank was fired three months ago after a fiasco project in their other business line.
Now imagine that he's not vested, but will be vested by the last month of the project.
Now imagine why this person would ever ever ever say there's a slight problem with the project until it's almost over. Or worse, he'll "two week" the project for months over time, over budget, and they'll release buggy, crappy, untested code to the customer in a beta which amounts to an alpha, expecting the customer to catch and report all the bugs.
It's no life at all, and certainly no way to get quality software, but it's a scenario I have seen repeatedly over the last few years.
i - This sig provided by
Particularly the specialization things. Software is too complex and complicated today to learn all of it. While you may be able to learn many fields, none of them well. Specialization will result in higher quality products I think. Another problem is time and deadlines. The industry is moving faster than us developers can keep up with. Resulting in shoddy, untested software. At some point though, it's going to slow down.
-
Actually, most of these questions apply to the design of everything in the world. If I'm building a bridge, a car, a building, a plane, a chair, an adhesive, anything at all, these questions apply. So, by your logic, all design tasks should be subsumed under a single profession: engineering. This whole idea of having "Chemical Engineering" and "Software Engineering" and "Civil Engineering" and "Structural Engineering" just has a poor effect on the base strategies that all engineering tasks share. Right?
The software that runs your pacemaker is not even considered for a moment to be the same sort of entity as the software that you use to write music. ... If your interpretation of software is that it's like a bridge [and] people need to know what they're driving on, then yes, a little peer review could help. If you think of software as literature, if you're somebody like Ted Nelson, say, then what you really want is groups of people who are emboldened to try wild things.
I have a lot of respect for Lanier, and I particularly thought One Half a Manifesto was a useful and badly needed bit of skepticism against what he terms "cybernetic totalism". But I think he's off on this point.
To be sure, different parts of software have different needs. If you're designed space shuttle guidance software, go ahead and engineer for five nines (99.999% uptime). A script that pages you when you get an e-mail from your girlfriend is probably a lot less mission-critical.
But there are certain questions that are useful to the software engineering process, regardless of what code you're writing. To think of a few, off the top of my head:
Every successful software project needs to ask these questions, preferably sooner than later. Fragmenting software engineering would have a very poor effect on the development of these base strategies, so hopefully it'll never happen.
Do domain names matter?
And how many of those projects really matter? Do you know how large the software industry is? Do you realize how many commercial products and in-house systems there are that don't follow good development and testing guidelines?
There are two ways you get quality in software: have developers who feel proud about their work and put as much quality in it as time allows, and have developers who are paid to put quality in their software it by management who has enough sense to think beyond a single quarter's expenses.
Right now, the former is a superset of the latter and is probably ten times the size, if not more. In open source projects, the lack of money means everything is by the former, so you end up with really high quality stuff, like Linux and Apache, or crufty stuff that pays a lot of attention to testing, like gcc, perl, and XFree86. It makes perfect sense, since you gotta love what you're doing to work on something for free, or at least, for a fraction of what you could make as a hired gun.
Sure, you also have all the dreck on freshmeat. But since no one was paid to write the dreck, there really is no loss. Most of us are not under the illusion that a weekend project is comparible to production-quality software. Besides, the yung'uns have to start somewhere.
--
Bush's assertion: there ought to be limits to freedom
Yeah, it'll be great when users are exposed to quality stable Linux projects like Netscape. From an end user's perspective, there's no real difference between the operating system being taken out by an application and the X session being taken out by an application. If you're lucky you have another computer in the room so that you can telnet to the locked box and kill X. Otherwise, you have little recourse besides the reset switch when the mouse and keyboard don't respond anymore. Either way you lose any unsaved work in open applications, just like in a Windows crash. When running Linux instead of windows however you run the risk of doing quite a bit of damage to the file system during a reset.
_____________
I don't want free as in beer. I just want free beer.
When I was 12, I found a box containing a bunch of old issues of Hustler in a lot behing the local 7-11.
I began to feel sensations I'd never felt before.
Being a scientifically minded young fellow, I immediately ran home and examined one of the low angle money shots through my microscope.
That's when I made the horiffying discovery that women are composed of red, yellow and blue dots.
I've been trying to live with the implications of that discovery for years now, and I haven't been able to care much about code quality.
--Shoeboy
but why is the Linux kernel compressed? Wouldn't that make the loading process longer because it must be uncompressed?
Rotating storage is slow. Executable compression products such as free UPX take advantage of the fact that loading a compressed file and unzipping it on a modern CPU-memory system is often faster than loading the same file, uncompressed, from rotating storage media such as hard drives or {C|DV}D-ROM drives.
Also, I wish that Linux could have a much smaller text editor. Windows Notepad is only 34KB in Windows 95
You could:Tetris on drugs, NES music, and GNOME vs. KDE Bingo.
Will I retire or break 10K?
... and it is Testing! Instead of making deadlines and release dates right before testing, they should be made 15/16th the way through testing. Software is not -nearly- tested well enough. Any QA department will tell you they are always strapped for time. Testing should last longer than the development of the software. Software companies should test like there is no possibility for a patch.
--
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
So how does a company grab the biggest slice of the marketplace pie? They do so by getting to market first. How do they get to market first? By cutting every possible corner imaginable to meet a ridiculous deadline and releasing a product of poor quality.
All other reward systems stem from this one. Imagine the case where a company has two programmers. The first hacks a bunch of code together and makes the ridiculously short deadline. The second programmer misses the deadline but produces a much more stable product. Now once the first programmers code starts to fail, the first programmer has to "save" the company by providing short-term quick fixes to the code, reducing the quality of the code further. Management views this individual as a key individual; key because they can't operate without him. The second individual is hardly noticed, except for delivering late, which is considered aberrant behavior.
So imagine the case where both of these programmers are leaving the company. Which individual do you think the company is going to bend over backwards to keep?
Economics, being the ultimate reward system for business, dictates that software development will never be able to do what hardware engineers have been doing for years, create micro-components. In hardware, you can create an AND gate and package many of these gates into a chip. This chip can be mass-produced and sold at a reasonable price. Every time a circuit is produced with this part, the manufacture make a little money for each part purchased.
In software, we can't make a simple component and standardize on it. If we created a component, e.g. a component that compares two dates to see if something has expired, and tried to sell it, what would people pay for it? Maybe a dollar. Most people would look at this component as so simple, they'd rather develop their own. But even if they did buy it, they can make millions of copies of this component with no additional cost. It would be the analogy of instead of buying an AND gate for 50 cents, you bought the AND gate factory for 50 cents. The hardware industry would have gone out of business years ago under such a system.
Software suffers from the economics constraints more than language problems, management issues, bad programmers, etc. Anyone can buy book after book on proper techniques for managing a team of developers using a myriad of development processes. The reason we see management pay only lip service to process is because the reward system for businesses doesn't reward quality or standards.
This is the real problem to solve (if there is a solution). Would companies pay royalties for components that were used in their products? Highly unlikely. Will people stop paying for new software because it is too buggy? Maybe, but it is usually better to use buggy software than no software at all.
After almost 20 years, I have given up on the software industry. As soon as I can get out, I will. The better you get in software design and development, the harder it is to operate in this environment. I don't blame companies for operating the way they do. They are rewarded for doing so.
So if you want to change behavior then change the reward system. Good luck.
...speaking as someone who supplied some patches to DeCSS, and writes telecoms network management software for money, I see little reason why people cannot be multi-disciplinary. Very few people nowadays are expert in all fields of software, and no one pretends to be, but we can be masters of many areas rather than just one.
His comments about Linux and Unixes were also off point - he fails to realise that the command line environment is an extremely efficient one for an experienced operator. Point and click environments are great for newbies, but I've yet to meet one that increases productivity for an operator who knows his onions. I do use GUIs and they're great when I'm not too familiar with what I'm doing, but when I know the area inside out its Shell Time.
I came away from this article feeling he just wanted to be inflammatory; if he'd posted this as a Slashdot comment he would've got so many (-1 Troll/Flamebait) mod points that his karma wouldn't have recovered till the fourth millenium!
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
Because these same pressures...
Combine time-pressures, market pressures, upper-management pressures, and a lack of training and professional standards, and you have a whole class of employee (the project manager) who has only incentives to lie and hedge, and no incentive to be honest about schedule, feature set, state-of-the-project, internal project problems, etc.
... also apply to the people who write those "sufficiently developed" "wealth of frameworks and libraries." I resent people who say that the tools are good but the work we do with them is shoddy. The tools are merely another level of software which, unfortunately, often has all of the same problems as end-user apps.
Take the apple WebObjects framework, for example. More specifically, the EnterpriseObject backend. Basically this has to do with an OO interface to database transactions; neat stuff. So why was my application crashing every couple of days after eating all the machine's available memory? Because there was an outstanding issue in the framework which failed to deallocate internal database objects. My app crashed and it wasn't my fault, and I'm still trying to find a workaround.
"How I hated Unix back in the '70s -- that devilish accumulator of data trash, obscurer of function, enemy of the user,"
Think he's a little angry? I agree that most software production sucks. always has, and the future isn't looking too bright either. I'ts all because it's writen by people, not machines. People make mistakes. I can't remember the last time I was able to install a program without having to screw around with it in some way. between crashing, unreliability and the anoying habbit of breaking other software on my systems, I usualy spend more time fixing problems with these packages than actualy using them.
Dirty Pirate Hooker
When user interfaces are designed, which is the better design? The simple pictoral design? (Like thos books for kindergardners), or a powerful and complicated design?
:)
In evolutionary terms, it's the simple design, because it's easier to learn. Unfortunately, this is a flaw, it will forever hobble us from creating the most powerful design.
Do not forget, most people in western civilization have to master an incredibly complicated, unnatural, non-intutive task. This task is INCREDIBLY difficult. Most people spend 10 years mastering literacy.
We force our kids to master a complicated and un-intuitive interface because simpler interface don't offer the power, and flexibility.
I like powerful tools for powerful and difficult tasks. Pictures can express instructions or handle simple tasks, but only words can express abstract relationships. Without words, there can be no mathematics, no algebra, because pictures cannot express the concept of a 'variable'.
If you know of UI research that gets around this, I'd love to hear it. Please give me a counterexample.
It's true that machine language code is non-object oriented, but that's not the issue here. The main objective is to build software components that have known behavior in all circumstances. It's not practical to do that with procedure oriented programming. There is ALWAYS some side-effect in a non-trivial program which leads to bugs.
Implementing interfaces with known boundaries using the object paradigm is a rugged, well known way to isolate the effects of a software defect to a single section of code. With procedures and functions free to grab at all the available variables, any line of code can take out the whole works.
It's like using Grade-8 hardware instead of whatever happens to be in the bin at a hardware store. You get a high-strength, durable, part with guaranteed specifications. While it wastes some CPU cycles, it's an acceptable tradeoff for 100% reliablity.
--Mike--
Vim is an _awesome_ vi derivative. Syntax highlighting and a million other cool features blended into a very smooth programming and editing environment. It's pretty small too (~1.8Mb stripped) given all the things it can do. The syntax is pretty easy, in practice (with recent vim versions) all I need is ESC to get to command mode, and i to go into insert (i.e. edit) mode. in command mode :w writes out the file, :q quits, and :wq writes and quits. That's, what, 5 commands? I bet notepad has more menu options than that... :-)
The first thing I do on a new system is install vim and symlink vi to it. The second is usually transitioning to qmail.
--
News for Geeks in Austin, TX
KDE2 actually does this, if it can't determine the filetype from the name it runs file(1) on it to determine what the proper MIME type should be. I believe that this information should be stored with the file meta-data, it would seem to be too much of a performance penalty to scan the file every time it is accessed. The MIME type could be determined when the file is created and whenever the file is closed after writing.
Just my $0.02
-- Remember: Wherever you go, there you are!
I read the linked article as well as Lanier's very long essay in Wired.
Lanier proposes that someone who writes software for a pacemaker be prohibited from writing software for music composition. He compares such mixing to a brain surgeon running a tattoo parlor on the side. I disagree with this idea. I think the mixed backgrounds of programmers provide valuable cross-fertilization.
The focus of the Wired essay was Lanier's disagreement with 'futurists' who predict techno-utopias or dystopias. He points out correctly that software is far too primitive to power the dreams or nightmares of these writers.
One thing I found irritating in the Wired article is that Lanier is clearly a Windows user and ascribes many of Microsoft's shortcomings to some deep-rooted problem in software development, when they're actually just caprices of the gnomes in Redmond. If you read the essay, you'll see what I mean.
Also, he calls Unix 'that devilish accumulator of data trash'. Jaron, maybe you need to take a look at the man pages for crontab, find and rm.
Now, now, now, don't take that as a flame. But what's the average age of a Slashdot reader? 20? What's the average age of a gung-ho Open Source development team? 21? Realistically, you don't have much software engineering experience at that age. Heck, how many Open Source projects have regression test suites? Two?
I'm not talking about old standbys like Perl and Apache and so on, but most of the other projects that get started by young coders and garner press simply for being "open source" without code quality ever being an issue. I don't want to name names, but examples are plentiful. Having a relatively simple project with 5 megabytes of *compressed* source code should scare anyone off.
Visual C++ is NOT object oriented in a nice way, Delphi is much better, but still not there... Everything is still doing function calls with parameters, dangling pointers all over the place, and the number of layers is going up all the time. It's no wonder that the stuff breaks more often instead of less.
--Mike--
No matter how refined computers become, no matter how many orders of magnitude of AI we pile on top of each other, no matter how elegant and compact and all-encompassing thing become, there will always be a need for someone who understands the underlying components. Somebody will have to know what is inside of the black box. There will always be McGiver situations where a more elemental understanding of the technology is necessary.
Obviously, components are the first step, more Lego-ing and less handcrafting of software. But I disagree with anyone who thinks hardware is way out in front of software. If hardware speed were indeed so far out in front, then games would be written in VB or Java or Python or Smalltalk or Modula-2. As it stands today, we're still facing a large performance gradient. Make the gradient go away, i.e., make it so that bulky, overhead-intensive-but-elegant languages fly just as well as tight, super-optimized C or Assembly, relatively speaking, and then you can talk about hardware's arrival.
I believe GNU/Linux is successful mainly due to politics, but partly due to "technological honesty". Sure, the overall user/developer experience of the Unixae is more primitive than, say, Microsoft Windowses, but what sort of progress has MS really brought? Phony, glitzy bells and whistles is not necessarily progress. Besides COM, MS really hasn't much to offer in terms of elegance.
Another aspect of the open source/free revolt is that this is the first time true freedom in the computer world has appeared. Back in the late '70's at my university, if you weren't a 3.5 math major, you didn't get into the CS emphasis, and, hence, you never got your hands on a computer; you were just a peasant. Microsoft Windows changed that with Peztold's tome on Windows 3.1 programming, and now, finally, GNU/Linux has broken the field wide open. We really haven't had much time to flex our muscles yet. The world simply hasn't hit its software development stride yet.
All in all, a few more years of open/free software and true universal hardware speed will turn things around.
--- WWSD? What Would Strider Do?
First off, I wanted to thank you for the Jurassic Park reference, which made my laugh out loud when I heard it for the first time in the theatre.
I also wanted to agree and expand on the idea that software sucks because the market says it's OK for it to suck. In general, the market now thinks it's OK for a LOT of things to be pretty mediocre - cheap plastic merchandise, McDonalds, TV. Software fits right in that group.
On the other hand, because it has been OK for software to suck for so long, I totally agree with the point made in the article that humans, as a group, have not really figured out how to make software. We haven't really needed to. I feel all current ideas on managing software projects are pretty much wrong at the core of things, and until we figure out why there's a lot of floundering to be done.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Lanier said,
"Basically, if you heard your brain surgeon also had a tattoo parlor, you'd probably demur. Right now we think of them as the same thing. We think it's perfectly all right for people to go back and forth. I don't think it is."
This is a fascinating suggestion and I think, aside from the flamebait in the article for Linux lovers, this may be the most important idea expressed in the interview.
That idea is that the people writing software should not only be generalists but software specialists(though I'm sure generalists are needed in software engineering just as in medicine). In this statement he both elevates software engineering to the level of medicine (which it certainly deserves given its importance in so many settings), but also calls for a more systematic approach to the social role held by coders.
Granted, while physicians are not perfect, their professional development model might not be a bad one to follow in the field of software development. Study fundamentals and then actual applications. Work under the tutelage of those more experienced. Increase professional independence. Share new ideas with peers and undergo peer review.
I think that a shift of this nature would definitely help propel software development leaps and bounds. And though it may be a good idea, what can be done to push things this way?
food for thought anyway...
In the beginning there was nothing, and then all of a sudden there was a big explosion and nothing became time and space. Twelve to twenty billion years later a bunch of creatures that use their two limbs to stand straight and the other two to masturbate and click on the NEXT button of their pr0n site are arguing about quality of something as abstract as software development process.
Things have most certainly changed.
Before the 1995 hundreds of software writers breathed, ate and shitted with Assembler and C. The only few clear moments in their lives worth remembering were the times when they found solutions to some obscure computer problems at the lowest level - at the hardware level - these were the junkies who coded bit by bit, only caring about performance; computers were slow.
Today armies of so called IT professionals are really trying to make guesses, as well educated as they possibly can, about scalability of multitiered web and wireless based systems, that must serve millions of customers, mostly in real time (rarely with back bone batch processes.) These are different breed of people, they don't need to know too much about the Assembler behind their Java and VB virtual machines.
Obviously it is hard to design software that works like Star Treck's does but it does not mean that software today sucks, it only means that this software is the proto software, it is the evolution that uses simple patterns with countless iterations to produce complex systems that at some point in time will most certainly be integrated together into one huge breathing software monster. There will be no question about AI anymore, the software will live its own life all around us. Be prepared.
You can't handle the truth.
The solution is to analyze the contents of the objects. Like the Unix "file" command, which runs rules that examine the starting bytes of a file to determine what it is. The advantage here is that when the file is copied somewhere, it's "type" is preserved, because it is part of the data.
What is missing is a file system where accessing the first 100 or so bytes of a file is as quick as reading that file's name, so that we could display the type as quickly as the current filename or attribute based hacks. Does ReiserFS or anything do this?
There should be a command line program to do exactly what "open" does in Explorer, or clicking a file in KDE, and we should require GUI's to exec this program so that all the GUI's agree on this system.
He might as well have bitched over the binary nature of computers. Like so:
I mean, everything in computers is ultimately based on binary interactions. You can try to overcome that, but it's very hard. The whole philosophy on how to do internal management and how to manage timing is based on that set of assumptions, so you have to fight it at a thousand levels.
Friends don't help friends install M$ junk.
I don't get it. How am I supposed to write "much better" software with a faster computer. Did anyone ever believe that "quality of products" and "horsepower" are related?
All humans are mortal. Socrates is a human. Socrates is dead.
I have always thought of creating a program like making a samurai sword. I know it sounds weird, but here's why. A sword is supposed to be an elegant and simple tool or weapon that really has many uses. Software, likewise should be the same way. You wouldn't want a sword that was mostly handle would you? what would be the point of that? In the same respect you wouldn't want a web browser that was all buttons and had a small windows for looking at a web page. And you wouldn't want a heavy sword, that's dull and breaks all the time would you? (think netscape 6). This is how I would break down some of the software that I use, using the sword analogy.
1. Windows - Large sword, somewhat dull, extra protrusions that make it only fit in their custom sheath. Dullness makes it harder to cut yourself, so it is more for those who don't want to develop enough skill to use a sharper sword, don't think they need one, or are scared or cutting themselves.
2. Linux - balanced different, awkward at first, but better once you get used to it. Really sharp, really durable, doesn't break, cuts through most problems easily. Not for the uninitiated. Blades everywhere, flexible but complex. Not just one knife, but lots of specialty knives designed for cutting through anything, each one for something different.
3. Winamp - a sharp, solid dagger, lightwieght, customizable with different blades, different designs for the handle.
4. IE - seemingly small handle, large blade, elegant but very fragile.
5. AIM - cuts through most of what it needs to, but is getting kind of heavy (bloated) not as bad as ICQ I think.
6. Gimp - Solid, sharp small handle, long blade, even comes with tools for sharpening. (think script-fu)
This Wiki Feeds You TV and Anime - vidwiki.org
For starters, let's say that I've a lot of respect for what Mr. Lanier achieved in the early 90s with VR, and understand that whole pop-semiotics/Mondo 2000/Boing Boing/Modern Primitive/Cyber-everything vibe he's coming from.
But allow me to reiterate that HARDWARE has a DEFINED FUNCTION. Bits go in, other bits go out. Key gets turned, engine starts. I buy a car and a plane and a boat - I don't expect to buy one vehicle that can fly, swim and roll on dry land. His problems with modern software stem from his paradoxical and contrary wishes for software engineering.
Lanier seems to have a scattergun theory as to why software sucks. It's either "the engineering isn't there" (definition A) , and/or "what it does for the customer doesn't empower him" (definition B).
To the first part I say software is considered by its mercurial nature not only something that CAN'T be engineered, but MUSTN'T be engineered. Cause if you make plans and stick to them, then marketing can't decide at the 11th hour to retool everything to include holographic agents and a Star Trek like voice input (after a night of cocaine and "brainstorming"). To whichever jackass points me to "if programmers built buildings a woodpecker could destroy civilisation" I say "make up your goddamn mind whether you want a condo or a three storey house BEFORE we pour the concrete, and we'll talk." No other form of engineering comes up with the ludicrous idea that plans are mere suggestions and subject to change at any time, to produce a product with no real set function (is Word a word processor, a typesetting program, or an HTML editor? MAKE UP YOUR MINDS). However, coming up with small, ruthlessly efficient software entities sounds like UNIX, which he says sucks by definition B of his rant.
As for his ideas that programming languages and interfaces should be humancentric, let me put it this way - computers process DISCRETE SYMBOLIC pieces of information, humans process PATTERNS and CONVOLUTIONS. I don't expect my shovel to shovel my walk for me, why should I expect my computer to respond to me drawing out what I want with magical icons and lines and all other forms of strange ideas when it comes to PROGRAMMING? (Visual Language?) Any machine that can accomplish such a feat would have so much software bloat by definition it sucks by definition A. A computer is a tool, not a mystical genie that's going to solve my problems for me. If I want a secure Internet connection, it behooves me to either learn how TCP/IP works, or hire someone who does. The answer is not to have a big red button that says "secure my system" cause I can assure you, on a system like that, someone's working on a big GREEN button that says "hack this system."
Most software sucks because people don't want to take the time to figure out what it should do or who wants it. Marketing seems to think that rather than research what a product should do and who to sell it to, it's just there to listen to every potential customer ("I want a minivan". "I want a sports car." "I want a quarter ton pickup") and spit back every ludicrous request ("We've got to come up with a sports quarter ton minivan!"). Management seems to think that rather than getting specific specs by a specific deadline and then staffing the needs of the project, giving the engineers and testers the tools, and then getting the hell out of the way, it's all about constant "meetings" and Microsoft Project bar charts.
--- Jump!! Fire!! Bullet time!! - Lego version of the Matrix
Its a sad commentary for the industry but certainly a good one for a quickly-growing economy. If you take the time to carefully plan, stick to the guidelines initially laid out, and test thoroughly enough that you are 99.44% bug free -- guess what -- you release and fail. Why? Because 3 or 4 other companies released months ago and dominate the market. No matter how good your product is, youre going to have an extremely difficult time getting people to switch if they are used to another product.
Now with the Internet, it is even more important than ever to be the first. That is the reason so many companies are willing to take huge losses their first couple years as they build up to a "critical mass of users", the point after which, they should, in theory, start to receive increasing economic returns to scale. (Yes, many are failing, but if you look closely, they are the me-too companies. Even amazon got caught up in this, and they should do better having pared their toys and other depts they added because they just could.)
Unfortunately, the reality of the times dictates that the only good choice is to develop a pretty good app, release it, and hopefully gain the name recognition and market share. Once you have market saturation, you can concentrate on making your product the best and upgrade to make your customers really happy, and then beat the other 2 or 3 companies out there doing the same thing.
The ivory tower has never had to reach so h
DISCLAIMER: Java(TM), JavaScript(TM), and JavaZealots(TM) are trademarks of Sun Microsystems, Inc., LLC, CRAP, etc.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
Yup. I've seen too much of it, too. Don't forget that the programmers (the guys on the bottom) get blamed for anything that goes wrong. The managers (at all levels) have their Teflon suits on.
Now go back and assume your project is a bridge instead of a program. Nobody within hollering distance of their right mind would put up with this kind of crap. Build a bridge that way, and it will collapse. Very publicly.
What's the difference? Only about 4000 years of experience. People in the management chain have a feel for what is needed for a bridge to "work", and know that they can't interfere in the process without risking disaster.
Software is newer and much harder to quantify. A bridge either falls down or it doesn't. A computer system has zillions of "degraded" modes that it can get into and still sorta work. It can be really hard to tell if a program is meeting its goals.
Because of this, managers can get away with all manner of crap. Software engineering will not be a real engineering field until a typical "software engineer" can say something to his manager like "Testing is going to take six weeks, period. I don't care if you miss Comdex, it doesn't get released until it goes through Test, and that will take six weeks." *AND HAVE IT STICK*.
I'm not holding my breath.
--
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
The difference between current cars and ones to which you can say "go to work" is not the difference between a CLI and a GUI - it's the difference between advanced AI and a lack thereof. A more appropriate analogy for the difference between a GUI and a CLI is the current GUI model wherein you use pedals and wheels to drive your car, and a CLI model wherein you say things like "speed up to 46 mph, turn left 1.2 degrees, slow down by 3 mph, turn on left blinker, turn left 5.6 degrees, center car again, turn off left blinker" etc. Obviously the GUI model in this case is much simpler, and this makes a good analogy to managing simple computer tasks with a GUI vs. arcane shell commands.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Well then you should just learn to fucking write, or stop bullshitting.
Paragraph 7: "Another method I use is factories. I have objects that construct related objects and return a handle to just the interface. This way other code that I write is never directly accessing the implementation of the object."
Paragraph 13: "Another method I use is factories. I have objects that construct related objects and return a handle to just the interface. This way other code that I write is never directly accessing the implementation of the object."
Ditto, as we go down.
Now you could have either a) cut and paste this from somewhere else, b) written as an original comment the exact same thing two times or c) are so incompetant that not only did you accidentally cut and paste your entire comment into the textarea, then posted without previewing, then decided to act without thinking with your response, so you couldn't even tell why I used the term "double-paste".
Sorry if my criticism offends you, but until you stop stealing your comments and denying it, you'll never make it in the real world.
The real world is treating me just fine.
--
"Don't trolls get tired?"
On the other hand, the problem with keeping the "file type" data (or any other data) in the filesystem as I suggested is that then you have to update dozens of programs to deal with it properly - at least tar, gzip, bzip, cp, mv, etc, etc. And as soon as you ever put one of those files on a filesystem that didn't support it, you would lose all that data.
But if you bit the bullet and started putting that stuff in the file system, there's a lot of other data that would be nice to track. The mime-type is just one. My argument is basically: We already track a lot of this stuff in the file system, so why not track more? Ext2 and every other Unix I know tracks the following:
- File owned by (user id, group id)
- File last modified on (some date)
- File size
- File name
- File permissions (read,write,execute for user,group,all, and suid)
It would be great if file systems also tracked the following data:- File created by user (real user id) acting as (effective user id) using program (X)
- File last modified by (real user id) acting as (effective user id) using program (X)
- Mime-type (X)
I'm sure there's lots more. Unfortunately, this may be a case where backwards compatibility with the existing installed base of Unix systems will doom us to the limited capabilities that were designed into the BSD filesystem twenty years ago or more.Torrey Hoffman (Azog)
Torrey Hoffman (Azog)
"HTML needs a rant tag" - Alan Cox
A. Draw pictures and icons of how your day went. B. Tell them in words how it went.
You do both.
You draw a picture of the events in your head, and sequence along as you go. And then you describe the pictures of each step in that sequence in words. If your friend doesn't get it, you back up and use other words, until finally the message has made it across space and time to the other side. Sometimes, you might even fall back to drawing a picture - certainly, this is how most linguists worked when encountering foreign members of other races, and it's an effective process of achieving communication, when needed.
Words function as a means of communicating significances and concepts. Pictures also function as a means of communicating significances and concepts.
They are not mutually exclusive of each other, and usually the better computer science types, and thus the better programmers, producing quality software, can function with either communications methodologies just fine.
It's the guys that get stuck on one method, and one method only, that produce crap software...
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
But if a programmer gets a single line out of millions wrong it can prevent the whole program for working. There may be thousands of faults in big software systems, but they are by far the most complex things we build, and have by far the least tolerence for mistakes of any field of human activity I can think of.
I think that considering how difficult a task it is we do damn well and should feel proud that we do.
Of course none of this means that we shouldn't do everything in our power to make software even more reliable and free of mistakes. Software is tens or hundreds of times as complex as it was ten years ago. Modern techniques and the right disciplin help, but I don't believe that software development in general has a bad record at all.
If anyone can think of another field where a mistake of a single mistake in hundreds or thousands of hours work is considered a bad record, I'd be suprised.
</rant>
Sig is taking a break!
Oh, those groupings allready exist! At least there are names for the persons creating different type of "software":
:)
Webslave - Person creating HTML, JavaScript and PERL CGIs and perheaps some database bindings. "Software" with high user-expressive (I won't use the term expressive power as the author, since IMHO, even a sorting algorithm contains a lot of such) content.
Sysadmin - high-level programs merely interconnecting big entities. Not so high user-expressive-power, not so high engineering-power neither. This is more like the person planning where to bild the bridge, what islands to connect with bridges, etc.
Script-kiddie - like sysadmin, but with different big buildingblocks, and different intentions...
KDE-hacker - programmer creating everything in one place, low-level low-user-expressive and themes and widgets all in one place.
Forgot someone?
Yes, this is meant to be a troll, but a funny one, at least
--The knowledge that you are an idiot, is what distinguishes you from one.
I cant figure out it its a bad article or he has nothing really interesting to say.
He says software sucks, but I'm not sure if he's addresses the quality (bug wise) or the quality (user interface wise). I'm inclined to think he's addressing the suckyness of user interface since he's into VR.
Now, anybody who is complaining about the ability of humans to design user interface should not be even mentioning unix. If your going to complain about user interface complain about the best interfaces developed, MacOS, BeOS, etc, not the worst (in terms of the general user)
If he's complaining about the quality of the user interface of unix (shell, X, etc) then I think he is making the wrong point. Can I complain about the quality of a BMW or Lexus because it doesnt fly? It does what it does, and it does it quite well. As far as I can tell, being an administrator for a web site mentioned in my sig, linux/unix does what it does perfectly.
Now, if he's complaining about the quality of software in terms of bugs as compared to hardware, I dont think this is a fair comparison. Although I'm not an expert of hardware/chips/etc I'm pretty sure that the "paths" that execution can take through hardware is much smaller than through software. Hardware is a low level sub set of the way to execute logic, software is above this and necessarly has more complexity and variablity. Software is also often cranked out a lot faster, and can be patched a lot easier, and microsoft doesnt make chips
Sneakemail is to spam filters what an ounce of prevention is to a pound of cure.
Well, I started with a CLI (MS-DOS) and still often prefer one, but I disagree with the general "CLI is better" sentiment. For many common tasks I now use a GUI simply because it is a better interface, even though I already know how to do the task in a CLI. Thus the "hard to learn" has nothing to do with it - I've already learned, but still prefer the GUI. A trivial example is view files in an archive. If i want to view a textfile in a ZIP archive, i can either double-click on it then double-click the textfile to view (GUI) or type "pkunzip zipfile.zip filename.txt" and then "edit filename.txt." The first step is much easier, IMHO, especially if I want to browse through multiple files. (of course you can also "pkunzip zipfile.zip filename.txt|more" but that's not equivalent, as more doesn't let you scroll up/down and edit the textfile).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
heh, yea I saw that, I typed it in a different window because this little box just sucks big time, I double-pasted my own comment. I didn't see it and I "over reacted" about the double-paste. But the comment is my own, and if you would like to have a technical discussion about it I hang out in irc.openprojects.net. I hang out in #c, #c++ and #linux, my handle is the same as slashdot "infodragon". I try to help out when time permits. So if you ever would like to chat then please join. I'd be glad to have a discussion about my technical merrits. See you there.
If at first you don't succeed, skydiving is not for you.
The problem is that this introduces all kinds of back-compatability problems in that any file format that cannot have an arbitrary-length comment imbedded within the first 4 characters or so would have no attributes or name (it could be opened by using the correct index into the directory).
There are also obvious security problems with a system where anybody can change the owner and permissions of a file. Permissions would have to be an "and" of those in the file and of all parent directories leading to it.
I think the ResierFS has talked about things like this. The problem they are having with their "many tiny files" design is that the required file attributes is far larger than the size of the files themselves.
An intermediate form is to have such a system, but have all "back compatable" files be directories. Inside this directory is a "name", "data", "permission", "date", etc.
As for Microsoft, they just created their own clone, and called it JScript.
Software sucks because you make more money with the first software to market than with the ideal product. It's a proven business strategy to come out with the first thing, and throw quality to the wind. Operating systems suck because computer scientists don't design the operating systems... companies with $$ invested in a couple different directions do. Companies are not in the business of making software. They're in the business of making money. Microsoft is a good example of this. They're an excellent company. They make lousy software. A good operating system could be made, they could play well with others, fantastic new standards and protocols could be developed, open to all, and beautiful software could be built that makes us all proud to have CS degrees. But if the money's in keeping the OSs the way they are and shipping software that breaks, but shipping it before anybody else and making buckets of money, well, that's what's going to happen. And although I'd like decent software, I don't know that I could blame them for picking the $$$ being that I've never had to make that choice. Whee. But since I posted this late, two people will read it.. hmm.. oh, well. I feel better anyway.
They are annoying, time destroying, silicon paperweights.
Much, MUCH better.
You have to admit, he has some certainly good points.
He wasn't ripping on Unix except to comment on the inherent complexity of trying to get anything NON-unix done on it. That's like saying I am having a bitch of a time getting my toaster to do the dishes. It's the best damned toaster I could find, I read all the manuals forward and backwards, but I want to get my dishes done.
And you have to admit, for a 30+ year old interface, it's not only held ground, it's advanced considerably. Funny how english is like that.
What I can wholeheartedly agree with is his comments on software sucking. It does. Duh. How many pieces of software have you used that a) do exactly what you want b) never crash or even participate in the cascade crashes any OS is susceptible to and c) costs what you like it to cost AND d) is available when you want it. I've worked for several software companies and everyone knows what goes on behind the scenes.
But, he's not taking into account the fact that software designers are all working on limited resources and limited budgets and time crunches. Hardware is cool. (Generally) it either works or it doesn't. It's not, "Hmm, I wonder what happens if a user jacks this into 220? Ooooo. Smoke. Let's build a safety into this. I wonder what happens if they throw the toaster into the house that's on fire? Will their toast be ok?" There's so much common sense in hardware. If you plug it in in the bathtub, be prepared for a shock. Everyone knows that. What people don't understand are the intangibles that software designers take (and are sometimes FORCED to take) for granted. If you are running 17 instances of Oracle on a 16 meg machine, don't expect your data to have any integrity. If your OS goes tits up, don't expect your letter to your grandson to still be there when you get back.
I guess I'm rambling. I mean, in short, that there are too many intangibles and too much that is hard to control in the software industry. We're trying to sell something epheremal to people who don't understand the basic concepts. You can't explain what ipchains is to someone and have them be satisfied with it unless they understand ALL of these other things - about IP about networking about NAT about firewalls about ruls about... But with a car, it's simple. You grow up with it. It's there. It goes. It stops. It guzzles fuel. No fancy crap and you don't expect anything more of it because you know the limits. But with software... ok, now I'm getting a headache.
--The statistical likelihood of your existence is so small as to render you impossible.
Any sufficiently well-organized Government is indistinguishable from bullshit.
I believe you are thinking about the Virtuality system from W Industries, Ltd. Lanier had nothing to do with this system directly (ie, he didn't develop it - he probably only inspired the developers). On another note, W Industries became Virtuality, Inc (or Ltd?), they are now known as CyberMind, Ltd.
Lanier developed high-end VR systems (ie, the VPL dataglove was a very expensive piece, on the order of $8000 US - they were also instrumentive in the design of the Mattel Powerglove for the Nintendo), with gloves, bodysuits, HMDs, and software, running on SGI workstations (IIRC - someone correct me if I am wrong). High res, high speed (for the time), and highly immersive.
Jaron Lanier is far from an idiot - though his latest views have me a little stumped. Why he doesn't like *nix and such - he kinda clears it up in this article, but I still get the feeling he hasn't really played with it much. Back when he was doing his VR stuff, there wasn't any form of real-time *nix (real-time OS's are nearly mandatory for immersive VR work), now there are several available, many free.
I don't think we should discount everything he has to say just yet - it might just be a case of "throwing the baby out with the bathwater"...
Worldcom - Generation Duh!
Reason is the Path to God - Anon
Since you know someone is watching you code, you cannot fool yourself that some lame hack will be OK because the other person will (presumably) call you on it! ;)
cpeterso
I don't think JL had much of anything to do with a-life - besides, much of a-life can trace its origins back to John Conway's LIFE "game" (a ruleset based primitive a-life).
Did JL bring us VR? Well, he wasn't the inventor of it - like many "inventions", VR was developed by a long series of independant inventors and inventions - ranging way back to the Victorian-era stereoscopes and panopticons, possibly even further, as people tried to bring and recreate an artificial or real world, via an external interface.
Prior to JL, was Sutherland and his "Sword of Damocles" (sp?), years later NASA and thier pilot training and simulation HMDs (big ugly things, but all off the shelf). JL saw this, and thought that he could do it too, and became the first to popularize and market HMDs, Datagloves, and Virtual Reality in general. In the end, his venture failed, and most (or all?) of the patents were bought up by Thompson - and sat on. Someday (actually, it should be someday soon - maybe in 10 years), those patents will expire, and alternate interfaces may take off then (VPL, JL's company - had patents that virtually blocked off all alternate implementations of the glove interface, at least the ones that were most flexible, easiest to use, and easiest to wear and adjust)...
Worldcom - Generation Duh!
Reason is the Path to God - Anon
Actually, he was right in blaming *nix, at the time - since there wasn't any good form of a real time *nix available then (mid-late 80's).
I agree with your sentiment that he should get off his butt and do something - but his VR ideas are not terminally flawed - immersive VR is a different interface for a computer, one no better or worse than, say, a CLI - both have their purposes and applications.
Q3A could easily be imagined as a desktop-based VE (virtual environment) - where the principle use is to run around, have fun shooting at others, and maybe - between frags - talk to another player. Wrap an HMD on your head, allow the software to detect you looking around and aiming your gun with the 6DOF tracked wand - think about it now...
Worldcom - Generation Duh!
Reason is the Path to God - Anon
Lanier's paper, One Half of a Manifesto, is actually several months old. The article referenced at Slashdot is a fluffy interview with the author which includes out-of-context fragments of the original paper. Please read the full paper rather than posting about how shallow the article is.
I agree that this was the most important single statement in the article. However, who is/are "we"? Perhaps I'm kidding myself, but I think that practitioners of the technology appreciate the differences quite well. Sure, I sysadmin my own few Linux boxes... badly. I have a lot of respect for professional sysadmins, who don't really aspire to coding apps (or much else for that matter), but they sure manage a heterogenous network...
Thisn't isn't to say that someone can't be multitalented as an individual, either. (For instance, just try to categorize Larry Wall. :-) ) But the disciplines within IT are certainly very identifiable.
Maybe the "rest of the world" has a tougher time figuring out that software-based IT is multi-faceted. Sure, we all know that doctors and lawyers and engineers each have specialties, and as soon as you need something else done, you have to go to a different one. So why isn't this realization out there in the publics' mind with IT as well? Maybe it's because the public doesn't deal directly with software people -- it deals directly with their software, but not with the people who create it. On the other hand, people do deal directly with lawyers and doctors. So there's a lack of opportunity for education in that sense.
Another possibility is that the legal structures that have built up around the other professions (assuming you can call software a profession) virtually mandate specialization, so that risks can be controlled and liability assigned: you're just not allowed to ask an electrical engineer to build a bridge. Until legal needs enforce structure upon software producers and their profession, software producers won't admit that there are professional categories that need to be maintained... at least, not when such an admission can lock you out of that next juicy contract or product you're aiming for...
Yet another possibility might have to do with the general nature of the people involved in software production: they're young, and likely introverted. They don't handle human-human confrontation well. So, when your boss cows you into being X for a day, then you try to be X, even when you're really Y. The bosses of the world, as all us Dilbert readers know, are thick as bricks and therefore a) come up with dumb requests, and b) don't know any better from their own personal experience. If the "software guy" can't point out the error in their thinking, then why should anyone expect them to figure it out on their own?
Cheers,
Richard
Look at Bob vs. Windows 3.11 vs. DOS 6.22. All are interfaces to the same thing (DOS OS services). They interact with the user in totally different ways. The user cannot possibly judge the real OS inside because he never sees it.
If someone built OpenBob for Linux with click and go for various major apps (WP, spreadsheet, draw prog, etc.), that people like the author would hail it as great.
And while Linux is often slammed for its difficult installation process, who, among those complaining, actually installed windows on their PC? It came pre installed fer crying out loud? You're comparing pre-installed WinOS to the Linux installation process? That's clueless.
I'm not going to disagree with you that FAT is a really bad filesystem, but it is a little more tolerant of improper unmounting than ext2. The obvious solution is to use ReiserFS. It seems to be quite good at recovering from improper unmounting and resumes normal operation very quickly upon reboot. I had the opportunity to try this out last week when I accidently pulled the wrong cord out behind my desk.
_____________
I don't want free as in beer. I just want free beer.
Exactly right.
Proper definition of the problem with solid requirements is an essential part of the design process. If the problem is understood, and the target is clear, everything else can go much more smoothly, and (barring changes from fiscal problems or owners of certain football teams) once solid requirements are delivered, they tend not to be changed nearly as often as soft ones... "Well, we think we'd like this, so why don't you get going on that, and we'll let you know the week before we ship that we decided to change the interface."
PPPPPP! is a very true phrase, especially for software systems.
--
"It's tough to be bilingual when you get hit in the head."
There is no such thing as unbiased testing.
Let engineering test a product, and they make sure that it has no serious functional flaws.
Let Support test a product, and they make sure that there are no issues that could generate a phone call (personally, they have the best stake, but I'm a support person).
Let marketing test a product, and they'll make sure that all the splash screens and icons look pretty.
Let customers test a product, and they'll make sure it gets the job done.
NONE of these groups is qualified to fully test and debug a piece of software to what you'd consider traditional "engineering" standards. The closest you can come is if you get them all together to design a standard suite of tests to run a product through. With all of these subgroups having a stake in software design, all pulling in different directions, it's no wonder everything's coming apart at the seams.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Bottomline, when it reaches some sort of Uber Utopian Ideal(tm), where there is no learning curve, when there is no effort needed to use it, when it does it all for you and anticipates your every need (including *those* needs too), then maybe software will not suck.
this sortof goes against the main premise of what it means to be a geeks or something.
It is a road to laziness and slavery of the mind due to incredible mental limpness. (We will do all of your thinking for you, etc.)
But it seem that this is something that certain Large Software Companies(tm) are aiming for.
"It is a greater offense to steal men's labor, than their clothes"
I've read a lot of similar rants by a lot of similar VR Hippies in the past and I get the feeling that they want the computer to magically do all their work for them. No matter how advanced this field becomes, I can't ever see that happening, so the VR Whiners will continue to whine about how much software sucks, no matter how much the development process and the designes themselves improve.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?