"As I was talking to the historian she said something crazy about how the world we live in might have been totally different. There was this guy who got hit by a bus...."
one of the biggest problems facing humanity today... is the elevation to a religion of the scientific method of observation.
Well, it is, you know.
There's absolutely nothing about the scientific
method itself that a priori demands that
you use it to find out things about the world. When you employ the scientific method to find
out how fast (e.g.,) your car will go, you're taking a leap of faith that that's the right way to go about finding out such things.
As it turns out, the "religion of science" does pretty darn well. While I
might go into a mystical trance or search through Biblical revelation or read Tarot cards or try to probe the minds of Car and Driver's editors through ESP to find out what my car will do in the quarter mile, chances are I'm going to be a lot happier with the answers I get if I do what I can to limit confounding variables and run some quarter miles.
But how happy I am with the results I get is wholly outside the scientific method. I might value reliability, consistency with prevailing theories that turn out to be useful in other areas, and so on -- and those things would lead me to choose the scientific method over others -- or I might be in a frame of mind where I value more the communion with the divine I achieve when I examine pig entrails.
So, choosing the scientific method is not only a leap of faith that it's the best way to find out about things, it's a reflection of the values you bring to the inquiry.
The scientific method is terrifically limited. It can tell me time in the quarter mile and gas mileage, but it can only give me vague hints about whether black is a better color than red or whether I ought to buy a car now or later. And as to whether, with millions of people starving, I ought to buy a car at all, science is completely at a loss.
But, like Churchill's famous quote about democracy, when you're interested in practical, mundane things like whether you have time to cross the street before the car that's coming hits you, and you think not getting hit is far more important than the feeling you get when you search the bumps on your head, then the scientific method is the worst possible way to find out, except for all the others.
Which is to say, you can't have your cake and eat it too. If you're totally against science on moral or even epistemological grounds, simple intellectual honesty demands that you close your eyes while you drive. Just let me know when you're planning to do it, though. My poor worldview, deprived as it is of transcendent riches, cautions me to keep well clear when you're proving your faith.
However, if the 'scope will be put to good use for more than _just_ black hole chasing it may be fine.
When pointed toward the earth, MAXIM will be able to use x-ray diffraction to produce a working "X-Ray Specs" effect which will see through people's clothes.
Some psychology guy proposed this decades ago... The Whorfian hypothesis. It is a neat idea, although I don't recall why, it was discounted.
It's called the Sapir-Whorf hypothesis, and Brown and Lenneburg showed in their paper "Hanunoo color categories" (undoubtedly misspelled) that linguistic terms for colors did in fact affect color discrimination.
Now as to the strong form of the Sapir-Whorf hypothesis, that you can't think about things you can't say -- something neither Whorf nor Sapir ever said anything close to, but if they read about the work in deconstructionism that they're being called the originators of, they'd just shit -- of course that's nonsense. But there's enough evidence and has been for years that linguistic constructs affect such fundamental cognitive mechanisms as color discrimination, and we ignore the effects of language on thought at our peril.
Whorf and Sapir were linguists, not psychologists, though the field of psycholinguistics arose (in part) from their work.
Many, many years ago psycholinguistics was one of the things I took more courses in than many others.
The rep Ready Systems had some years ago with people buying real time systems is that if it visibly works in the demo, it will probably work in the product you buy. If the salesdroid talks about it working, it won't. Perhaps that's just in the Southeast US, but their reputation where I work was far from enviable.
In VxWorks one of the things we learned to do early was get the hell out of interrupt level as quick as you could. The driver I ported to VxWorks for an FDDI board, for example, basically shuffled stuff onto a ring buffer that fed the process (at high priority task level) that did the actual work. That's because interrupt level was honest-to-god interrupt level.
Please forgive my ignorance here, but is that the way people are writing Linux drivers? If not, then you're going to have a massive job of driver rewriting before preemption is actually usable for (e.g.,) cyclic schedulers like we use in training simulators and some kinds of hardware-in-the-loop simulations.
Simply turning off preemption every time a process or a driver takes a lock is a far, far cry from usable preemptive scheduling. If I need a 60 Hz scheduling event, then I bloody well need it at 60 Hz, and a pause for a few dozen milliseconds for a filesystem sync (etc., etc.) is right out.
And there was a need for a number of parallel utilities in VxWorks. For example, printf() takes a semaphore, so it's unusable at interrupt level and you have to use another function to print things out at interrupt level. Note the way VxWorks did it: it doesn't let you take a semaphore at interrupt level, which is just the opposite of what Ready is suggesting. Why? Because they believe real-time is important, and it's at the core of the philosophy behind the operating system, not an add-on.
Unless I've badly misunderstood this, it looks like preemption in Linux is going to be a toy.
The concluding paragraph of the article (quoted without permission):
Likewise, if people want music to be free, they should create free music and distribute it. We all have the right and opportunity to create new ways of doing things. Linux demonstrates that such efforts can be highly successful. But we do not have a right to subvert existing systems in the name of free speech just because we have the technology to do so.
Interesting idea: subverting the system.
In fact, that idea could be paraphrased "Systems want to be in control."
The problem is, we confuse systems (as they exist today) with meta-systems that represent different people's actual requirements.
For example, the music meta-system (the set of requirements that give rise to existing and future systems) is:
The artist produces the work she wants people to enjoy
People find out about the work
People obtain the work
People enjoy the work
The artist is compensated for her effort and enabled and encouraged to repeat the loop
The real-world music system is more like:
The artist produces the work she wants people to enjoy
The label massages the work, removing objectionable lyrics for the Wal-Mart version, substituting or rejecting songs, arranging, remixing, etc.
The label generates buzz over radio, MTV, and other media, spending money to do so (legally and otherwise). The channels it uses are mostly mass-market, and the people who find out about it are mostly people with mass-market tastes.
The label spends money to press physical copies of the work and ships them to distributors, who in turn ship the copies through various middlemen and transportation systems to stores
People get in their cars and drive to the stores
People find one of the copies of the work, stand in line, present identification, pay for it, and carry it home
People find that the songs that didn't get played on the radio and MTV suck
The label gets rich and the artist gets screwed
Do you see how far from the meta-system this (all too often realistic portrayal of the) real-world system is? A system this lousy doesn't need to be subverted. It's being discarded -- by consumers now, and eventually by labels -- because it doesn't meet requirements.
Hmmmmm. A design is being replaced because it doesn't meet requirements. Sound familiar?
The Free music effort (note the cap) should be all about not just subverting, but flat out destroying the current system, and the best thing about it is that it doesn't take bombs or slogans. All it takes is a system that meets the design requirements better.
Napster and gnutella also fail to meet requirements. Finding out about a work is harder in that system than in the existing system -- in fact, the Napster system would collapse if the traditional "music industry" system collapsed. Just try to find something you like at mp3.com from an artist you've never heard of.
And, of course, the Napster system fails to compensate the artist. What's important to the labels is that it also fails to compensate the labels, but that shouldn't be what's important to us. The key to the Free music effort is not in repeating the idiocy of the current system. Free (capital F) music shouldn't be free. That just flat doesn't meet requirements.
What we should be thinking about is designing a system that meets the requirements. All the requirements. Do that, and have enough savvy to stay out of the way of the dinosaur's death struggles, and you'll really have something that's worth people's efforts.
This actually happened. I had a user call me up and say he thought the database I'd done (using PHP and MySQL) for participants in one of our programs was really cool, but he thought it would be neat if I could display them by job title as well as by name and location and the other sort criteria I had.
I went on and on about how it was a major change and I couldn't see when I'd have time to get around to it (all the while going clickety-click). "OK," sez I, "hit reload."
The one thing I've never seend addressed in any book dealing with programing for the web is how to seperate 1) programing logic from the html (tho not insanely hard) 2) seperating html from the acutal content. and 3) keeping sane.
My personal PHP style is different from most of the examples I've seen. Once I'm in PHP, I pretty much stay there and use print() to generate HTML. I figure it costs a little something to switch back and forth between the PHP preprocessor and the regular shove-it-down-the-pipe function of a web server.
However, given that almost everything else you do in PHP or with a database surely takes longer than that, a rational person would no doubt conclude that this is just being anal (and needlessly distrustful of what the preprocessor might do to the contents of my variables when it isn't active). Same thing with making sure all my exit paths close the database once it's open. Automatically closing the database on exit and preserving the values in variables sound like things that probably attract quite a bit of the developers' attention and test time.
So write it in PHP when it feels natural and looks readable (and, of course, when you need to, like when the HTML or text contains a variable value). Write in HTML other times. Whatever makes your document easy to read and maintain is probably the best advice.
One thing (just to add further proof of my anality): always, always, always use GetImageSize() if you're serving up images. Don't do it the way they show in the example, though. Check for null in the return value, just in case somebody moved that image.
I've done quite a bit of PHP3 and MySQL, and apart from a few runs to places listed on the PHP links page and PHP FAQts, I've pretty much gotten everything done with the excellent HTML manual.
About the only thing the manual lacks is an index of functions, but a little bit of experience is generally enough to help you figure out the category under which they've hidden the function you're looking for. I see now that the PDF version of the manual is indexed, so newbies to the manual may want to start there.
OTOH, I'm a long-time C programmer, and when I wondered about syntax, pretending that PHP is C with dollar signs in front of the variable names has worked out more often than not.
Since this page is (presently) screwey and I can't figure out how to reply to an individual posting, in answer to "why PHP instead of Perl?", why not?
Oh, all right. Here's a couple of reasons:
PHP runs in the context of Apache (except the Windows version) which makes it outrageously fast on the UltraSPARC II I'm using most of the time, but then so does perl if you use mod_perl. You'll notice I said nothing about "X is faster than Y". I've found PHP/MySQL to be "very fast" in my applications, and let's leave it at that.
PHP has got excellent integration with databases (especially MySQL), but I imagine something similar is available for perl.
PHP is smaller than perl, which means that a PHP mod Apache won't have anything like the footprint of a mod_perl Apache (good to know when you're paying Sun's memory prices)
There's nothing remotely similar to CPAN, and the Free PHP apps I've seen out there aren't that useful, which means that if you're writing PHP, you're probably doing it mostly from scratch rather than extending others' apps. I actually find this useful. I figure if you're doing server-side scripting, speed is the number-one virtue, and reuse -- at least the kind of reuse I've done -- usually incurs a speed penalty.
So if I were buying a PHP book, the first thing I'd look for are applications that are like the application I'm building to see if I could steal some ideas and code snippets. And I'd look for stuff about the big picture that the originators sometimes forget to put into their documents. But I'm not in the market for a PHP book because the manual is so good and because years in the salt mines of C have pretty well taught me how to code a solution to a problem.
Let me hit on one more thing if I may. When you read the source code, you're reading the truth. When you the canonical documents (the language spec or the documentation supplied with the language) you're one step away from the truth. When you read a textbook, you're two steps away from the truth.
I'm generally too lazy to read the source code (not always -- that's how I learned Unix networking, but there were some special circumstances there or I'd just have read a book like a sensible person), but I've been bushwhacked by enough documentation bugs to do as much learning as I can from the canonical documents.
Bunches of reasons, but you nailed it right on
the head -- not in the way you believe, though.
The best thing about VRML is that anybody can make a VRML model. It's plain text (utf8) and marvelous worlds have been built using nothing more than vi or notepad. The worst thing about VRML is that anybody can make a VRML model.
A 200K file for a little bitty building is obscene. You absolutely did not do this by hand. You got it from a modeler that exported VRML, and you figured, "hell, it parses, let's put it on the Web".
I'm not singling you out. Far from it. The thing that was the absolute worst PR for VRML was that easily half the VRML worlds out there were bloated pigs just like your world. That's because hardly anybody valued small, fast worlds, and even fewer knew how to build them. For instance, I've got three VRML decimators (one uses Garland & Heckbert, one uses Hoppe, and I don't know what the third one uses), and I wouldn't dream of publishing a VRML model on the web without sending it through at least one of the decimators.
And don't get me started on color and lighting. Jesus H. Christ, you can do beautiful things with lighting in VRML. You don't have photon tracing (which means the scene will render in your lifetime) but you've got enough effects to make something really beautiful. Not one world in a twenty uses anything but the headlight and primary colors. That alone is responsible for VRML's rep as "cartoonish".
There are many better examples than this one of what you can do with color and lighting when you take a little time, but I might as well toot my own horn.
I think it's important to be a little more careful in our speech about this issue. As Roger McGuinn's testimony reveals, it is common for artists to get nothing from the sale of a CD.
If you believe that artists get a fraction of a penny from CD sales, then you have to conclude that people who use gnutella, etc. are in some sense stealing from the artists. Those fractions of a panny are the only moral ground the major labels have to stand on, and by not treating them as fictional, we play into the RIAA's PR campaign.
Artists get money from CD sales == Microsoft innovates
I don't mind so much about the messenger. It's the message that bothers me. And unfortunately, he's right, at least about one thing. Netscape 4.x sucks so hard that nature abhors it, and yet that's the product they chose to leave out there representing their company to the world for two years.
I'm now a former Netscape user. It's still on my machine, but I use Opera 90% of the time and MSIE 9% of the time, and it's only for things like VRML and some multimedia that I ever fire Netscape up any more.
What really pushed me over the edge was the first release of Mozilla.
Never mind that it took approximately forever to get the downloader to get all the pieces, and never mind that the "smart installer" left all kinds of crap I had to weed out of the registry when it only installed halfway. And never mind that it didn't stay lit long enough to get past the splash screen. This is alpha software, and those faults can be forgiven.
But what can't be forgiven is that Mozilla is even more bloated than Netscape 4.x. And it will never get any smaller.
There is simply no point in a browser being that big. Web surfing is not my life, and it will never be my life. When I can install two good C compilers (which I use, in part, to earn my living) and they take up less space together than a web browser, something's wrong.
Netscape has forgotten a fundamental principle of software engineering: incremental development. Had they released a browser with about the same functionality (and about the same size) as Opera, anybody who had the tiniest bit of savvy and anybody who had the smallest disgust at Microsoft's anticompetitive practices would have jumped right on it and stuck with it as they added functionality.
But as things are, Mozilla is born to be bloatware, and I no longer have room on my machine or in my life for bloatware browsers.
Like you, I've got US$39, which is the price of dinner for two people at an ordinary restaurant. I'll respond elsewhere on why I think Opera is worth the price of a fair meal.
Its amazing how fast I can throw somebody off simply by putting them in front of Opera.
Do what I did to get my wife and kid to switch over: set up the buttons in Netscape's odd order on the toolbar (back, forward, then reload?), and move the URL bar up to the top.
That's all it took, and they were happy.
Just like heihol, I use Opera for information and MSIE for worthless gimmicks, crossing my fingers as I go.
Strange. Whitespace and indentation don't matter in Ada any more than they do in C.
I'll bet the reason your system was set up to ding you on indentation was to make life easier for the TA who had to grade your projects.
On making post-compilation debugging easier, much of the time Ada makes it nonexistent! It's reasonable to expect that if an Ada program compiles, it runs, and runs correctly. CS students and other beginners, who show much more creativity in misunderstanding a problem than folks with more experience, may be an exception to this rule, but not by much.
Back in the day, many platforms didn't even have Ada debuggers, and while it'd be hyperbole to say we didn't miss them, we got to the end of the project without too many suicides or homicides.
Ada, s/w engineering, and s/w integration
on
Why Not Ada?
·
· Score: 1
One thing that's come up in several threads is that Ada is a software engineering language, not a hackish language. I think that's absolutely correct.
I first hired on with my present employer when a large project using FORTRAN was in its integration phase. At the time I hired on, the project had gone six months past the delivery date, and we finally delivered some eighteen months after that.
Being fairly perceptive, I got off that project as quickly as I could and onto a project in Ada that used a software engineering approach, with strict rules about control flow and data flow, encapsulation, and intercommunication between elements. Not that I knew much of that, or even what that was all about, at the time. I was just glad to get off that first project.
The Ada project not only delivered on time, but actually under-ran the hours allocated for integration, even when we had to separate the code into two separate processes and put it on a multi-processor system.
Since then I've worked on projects in Ada, FORTRAN, C and C++, and found that while software engineering discipline could be used on a project in any language, in general Ada seemed to support it better. Whether this was due to the language itself or whether project managers who believe in and understand software engineering happen to pick languages like Ada, I don't know.
I do know one thing: every Ada project I've been on has taken a smaller time for integration than any project I've been on in other languages. This includes one project where four different contractors developed software in three different cities, and when it all went together the first time, it ran.
I've also noticed that in other languages, particularly C++ in the wrong hands, changes made to one part of the system have a far greater tendency to break other people's code than they do in Ada.
Finally, I've noticed that some of the time savings from integration is spent at coding time cursing the compiler and the language for not letting you get away with stuff. But not all the time savings. And it's a lot easier to fix compile time errors than runtime errors.
I don't write Ada for fun. I don't think many people do. And since Ada work has dried up, I don't write it much for a living any more either. But if I had a big project with a tight schedule that we needed to make money on, I'd certainly push to use Ada on it.
Man, I don't know where to begin on this one. Virtually all of the technical information in it is false. Let's take them in order:
Ada doesn't permit dialects and subsets. For a long while you couldn't even use the name "Ada" on a compiler unless it implemented the full language. AFAIK there has never been an Ada compiler that didn't implement the full language.
Ada compilers nowadays aren't any slower than C++ compilers, since they use the same back end. Even in the early days, only a handful of Ada compilers were really slow.
Perfectly true, and the DOD didn't promote it all that much either. I personally disagree that the DOD "endorsement" was that much of a negative.
The machine code produced by most Ada 83 compilers is so good that there have been frequent studies showing it to be faster than the output of C compilers for the same platform. With gnat, as you might expect, there isn't much difference since it uses the gcc back end.
It's called gnat or perhaps GNAT. It's quite true that it was a stupid idea to make US$20,000 Ada compilers at the very time that Sun and SGI were giving away C compilers as standard equipment in their OSs. COBOL is so far from dead there have been frequent jokes about resurrecting COBOL programmers for the Y10K problem.
"Interesting" is unmeasurable. We differ.
I think you misunderstand exceptions. By keeping the exception control flow path separate from the normal control flow path, you always make your program clearer and generally make it faster as well. For a somewhat unfair example, see gzip.c
>Yes, Ada is very productive if you're a university wishing to churn out carefully indoctrinated "software engineers"...
I was kind of hoping you'd follow up on that. I infer from the way that's said that you probably believe that an engineering approach to software isn't of much value to you.
You're certainly entitled to that opinion, if it is your opinion. But I hope I'm similarly entitled to being proud of what I believe is a more fully scoped professionalism.
I do take issue with Ada being mostly academic. My experience with it has been very much in the real world. And I think in academia, the flavor of the month is either C++ or Java.
I just escaped a C++ project at work that was being run by free spirited OO bigots from academia who had never delivered more than a few hundred lines of code on time and on budget. Needless to say, it was a disaster. I'll take professionals over amateurs every time.
This is absolutely not an Ada vs. C++ issue. It's possible to have a bad design and irresponsible practices in any language.
>And yes, it did seem verbose, cumbersome and dull - which was also what individuals became if they programmed in it for too long.
Sorry for such an obvious response, but I'd much rather have the person flying the plane I'm on be a little verbose, cumbersome, and dull.
Ada doesn't have hack nature. Almost nobody writes Ada for fun. People who write Ada usually do it for a living and usually do it in a large project. I'd almost be willing to assert that for quick hacks using Ada is a stupid idea. There are times when you need a fondue fork and times when you use an air hammer.
>Ada was designed, in part, to help keep the programmer from making some kinds of mistakes.
Absolutely true. They realized, to take one small example, that even though programmers should do array bounds checking, in the real world they don't. So they built that into the compiler. I've been called out in the middle of the night on a project in FORTRAN to fix what turned out to be somebody else's code running of the end of an array into where my code was running, so I'm grateful to the Ada designers for that.
>My feeling is that this philosophical influence on a language tends to lead to a more cumbersome language.
I don't know what "cumbersome" means. If it means that it's more difficult to get something out of the compiler than it is in C, I agree. But then my practice in C and C++ is often to compile and link and immediately fire up the debugger without even bothering to see if it runs, because I know it won't. By contrast, if code got out of an Ada compiler, you knew it would probably run and maybe even do the right thing when it ran.
>Indeed, Ada is a complex enough language that it took years to create a certified version of the compiler.
The word is "validated", and I don't recall it taking years.
>NOBODY wanted to use Ada.
Young military officers figured out pretty quickly that:
they wouldn't be in the service forever, and
there were more C++ jobs than Ada jobs in the civilian world.
As a result, they raised hell about the Ada requirement, and program offices were issuing waivers for the equivalent of a case of the vapours.
Re:Why Ada is unpopular
on
Why Not Ada?
·
· Score: 1
>This leads to ALL UPPER CASE PROGRAMMING
Bzzzzt. Sorry. Not that I've ever seen. There may be shops that do that (God knows why), but the language reference manual and "official" style guides are filled with words and examples about capitalization as an aid to readability.
Ada is case-insensitive, perhaps due to this requirement. There are arguments on both sides of that issue, and I can't find myself getting passionate about either side -- this being/., no doubt others will supply this momentary lapse.
There was only one Ada horror from its requirement to be usable internationally and on older machines: "not equal" is written "/=" because some terminal on some machine didn't have a "!".
>Objects came late to Ada.
I really believe that Ada 95 failed to capture a large mindshare for no other reason than because its creators refused to use the simple word "class" and used a weird syntax of "tagged types" and so on to describe what was:
a difficult concept to begin with, and
a concept that other people were already describing with other words.
No doubt some CS PhD had good reasons why "tagged type" and the rest were "better" words. I'm reminded of the couplet to the pigheaded driver:
He was right, dead right, as he sped along
But he's just as dead as if he were wrong
>its blocks are delmited by indentation. Not exactly. Its blocks are delimited by words, not symbols. Otherwise, it's every bit as free-form as C, etc:
with Ada.Text_IO; procedure Hello is begin Ada.Text_IO.PutLine("Hello, world!"); end;
Obvious. But didn't you suspect that there might have been a reason why the other folks on this thread hadn't already done that? Could it have been because they read the part of that page that talks about that?
Besides, the subject line is all wrong anyway. If you've got big enough stones, it doesn't matter what kind of house you live in.
Slashdot Mirror
"As I was talking to the historian she said something crazy about how the world we live in might have been totally different. There was this guy who got hit by a bus...."
In which case, the "if" in the last paragraph returns a false and you branch around the whole thing.
It was a general "you", not a specific one.
Well, it is, you know.
There's absolutely nothing about the scientific method itself that a priori demands that you use it to find out things about the world. When you employ the scientific method to find out how fast (e.g.,) your car will go, you're taking a leap of faith that that's the right way to go about finding out such things.
As it turns out, the "religion of science" does pretty darn well. While I might go into a mystical trance or search through Biblical revelation or read Tarot cards or try to probe the minds of Car and Driver's editors through ESP to find out what my car will do in the quarter mile, chances are I'm going to be a lot happier with the answers I get if I do what I can to limit confounding variables and run some quarter miles.
But how happy I am with the results I get is wholly outside the scientific method. I might value reliability, consistency with prevailing theories that turn out to be useful in other areas, and so on -- and those things would lead me to choose the scientific method over others -- or I might be in a frame of mind where I value more the communion with the divine I achieve when I examine pig entrails.
So, choosing the scientific method is not only a leap of faith that it's the best way to find out about things, it's a reflection of the values you bring to the inquiry.
The scientific method is terrifically limited. It can tell me time in the quarter mile and gas mileage, but it can only give me vague hints about whether black is a better color than red or whether I ought to buy a car now or later. And as to whether, with millions of people starving, I ought to buy a car at all, science is completely at a loss.
But, like Churchill's famous quote about democracy, when you're interested in practical, mundane things like whether you have time to cross the street before the car that's coming hits you, and you think not getting hit is far more important than the feeling you get when you search the bumps on your head, then the scientific method is the worst possible way to find out, except for all the others.
Which is to say, you can't have your cake and eat it too. If you're totally against science on moral or even epistemological grounds, simple intellectual honesty demands that you close your eyes while you drive. Just let me know when you're planning to do it, though. My poor worldview, deprived as it is of transcendent riches, cautions me to keep well clear when you're proving your faith.
When pointed toward the earth, MAXIM will be able to use x-ray diffraction to produce a working "X-Ray Specs" effect which will see through people's clothes.
Is that OK?
It's called the Sapir-Whorf hypothesis, and Brown and Lenneburg showed in their paper "Hanunoo color categories" (undoubtedly misspelled) that linguistic terms for colors did in fact affect color discrimination.
Now as to the strong form of the Sapir-Whorf hypothesis, that you can't think about things you can't say -- something neither Whorf nor Sapir ever said anything close to, but if they read about the work in deconstructionism that they're being called the originators of, they'd just shit -- of course that's nonsense. But there's enough evidence and has been for years that linguistic constructs affect such fundamental cognitive mechanisms as color discrimination, and we ignore the effects of language on thought at our peril.
Whorf and Sapir were linguists, not psychologists, though the field of psycholinguistics arose (in part) from their work.
Many, many years ago psycholinguistics was one of the things I took more courses in than many others.
The rep Ready Systems had some years ago with people buying real time systems is that if it visibly works in the demo, it will probably work in the product you buy. If the salesdroid talks about it working, it won't. Perhaps that's just in the Southeast US, but their reputation where I work was far from enviable.
In VxWorks one of the things we learned to do early was get the hell out of interrupt level as quick as you could. The driver I ported to VxWorks for an FDDI board, for example, basically shuffled stuff onto a ring buffer that fed the process (at high priority task level) that did the actual work. That's because interrupt level was honest-to-god interrupt level.
Please forgive my ignorance here, but is that the way people are writing Linux drivers? If not, then you're going to have a massive job of driver rewriting before preemption is actually usable for (e.g.,) cyclic schedulers like we use in training simulators and some kinds of hardware-in-the-loop simulations.
Simply turning off preemption every time a process or a driver takes a lock is a far, far cry from usable preemptive scheduling. If I need a 60 Hz scheduling event, then I bloody well need it at 60 Hz, and a pause for a few dozen milliseconds for a filesystem sync (etc., etc.) is right out.
And there was a need for a number of parallel utilities in VxWorks. For example, printf() takes a semaphore, so it's unusable at interrupt level and you have to use another function to print things out at interrupt level. Note the way VxWorks did it: it doesn't let you take a semaphore at interrupt level, which is just the opposite of what Ready is suggesting. Why? Because they believe real-time is important, and it's at the core of the philosophy behind the operating system, not an add-on.
Unless I've badly misunderstood this, it looks like preemption in Linux is going to be a toy.
Likewise, if people want music to be free, they should create free music and distribute it. We all have the right and opportunity to create new ways of doing things. Linux demonstrates that such efforts can be highly successful. But we do not have a right to subvert existing systems in the name of free speech just because we have the technology to do so.
Interesting idea: subverting the system.
In fact, that idea could be paraphrased "Systems want to be in control."
The problem is, we confuse systems (as they exist today) with meta-systems that represent different people's actual requirements.
For example, the music meta-system (the set of requirements that give rise to existing and future systems) is:
- The artist produces the work she wants people to enjoy
- People find out about the work
- People obtain the work
- People enjoy the work
- The artist is compensated for her effort and enabled and encouraged to repeat the loop
The real-world music system is more like:- The artist produces the work she wants people to enjoy
- The label massages the work, removing objectionable lyrics for the Wal-Mart version, substituting or rejecting songs, arranging, remixing, etc.
- The label generates buzz over radio, MTV, and other media, spending money to do so (legally and otherwise). The channels it uses are mostly mass-market, and the people who find out about it are mostly people with mass-market tastes.
- The label spends money to press physical copies of the work and ships them to distributors, who in turn ship the copies through various middlemen and transportation systems to stores
- People get in their cars and drive to the stores
- People find one of the copies of the work, stand in line, present identification, pay for it, and carry it home
- People find that the songs that didn't get played on the radio and MTV suck
- The label gets rich and the artist gets screwed
Do you see how far from the meta-system this (all too often realistic portrayal of the) real-world system is? A system this lousy doesn't need to be subverted. It's being discarded -- by consumers now, and eventually by labels -- because it doesn't meet requirements.Hmmmmm. A design is being replaced because it doesn't meet requirements. Sound familiar?
The Free music effort (note the cap) should be all about not just subverting, but flat out destroying the current system, and the best thing about it is that it doesn't take bombs or slogans. All it takes is a system that meets the design requirements better.
Napster and gnutella also fail to meet requirements. Finding out about a work is harder in that system than in the existing system -- in fact, the Napster system would collapse if the traditional "music industry" system collapsed. Just try to find something you like at mp3.com from an artist you've never heard of.
And, of course, the Napster system fails to compensate the artist. What's important to the labels is that it also fails to compensate the labels, but that shouldn't be what's important to us. The key to the Free music effort is not in repeating the idiocy of the current system. Free (capital F) music shouldn't be free. That just flat doesn't meet requirements.
What we should be thinking about is designing a system that meets the requirements. All the requirements. Do that, and have enough savvy to stay out of the way of the dinosaur's death struggles, and you'll really have something that's worth people's efforts.
This actually happened. I had a user call me up and say he thought the database I'd done (using PHP and MySQL) for participants in one of our programs was really cool, but he thought it would be neat if I could display them by job title as well as by name and location and the other sort criteria I had.
I went on and on about how it was a major change and I couldn't see when I'd have time to get around to it (all the while going clickety-click). "OK," sez I, "hit reload."
If anybody's come up with an answer to the question you actually asked, they sure haven't told me about it.
My personal PHP style is different from most of the examples I've seen. Once I'm in PHP, I pretty much stay there and use print() to generate HTML. I figure it costs a little something to switch back and forth between the PHP preprocessor and the regular shove-it-down-the-pipe function of a web server.
However, given that almost everything else you do in PHP or with a database surely takes longer than that, a rational person would no doubt conclude that this is just being anal (and needlessly distrustful of what the preprocessor might do to the contents of my variables when it isn't active). Same thing with making sure all my exit paths close the database once it's open. Automatically closing the database on exit and preserving the values in variables sound like things that probably attract quite a bit of the developers' attention and test time.
So write it in PHP when it feels natural and looks readable (and, of course, when you need to, like when the HTML or text contains a variable value). Write in HTML other times. Whatever makes your document easy to read and maintain is probably the best advice.
One thing (just to add further proof of my anality): always, always, always use GetImageSize() if you're serving up images. Don't do it the way they show in the example, though. Check for null in the return value, just in case somebody moved that image.
About the only thing the manual lacks is an index of functions, but a little bit of experience is generally enough to help you figure out the category under which they've hidden the function you're looking for. I see now that the PDF version of the manual is indexed, so newbies to the manual may want to start there.
OTOH, I'm a long-time C programmer, and when I wondered about syntax, pretending that PHP is C with dollar signs in front of the variable names has worked out more often than not.
Since this page is (presently) screwey and I can't figure out how to reply to an individual posting, in answer to "why PHP instead of Perl?", why not? Oh, all right. Here's a couple of reasons:
So if I were buying a PHP book, the first thing I'd look for are applications that are like the application I'm building to see if I could steal some ideas and code snippets. And I'd look for stuff about the big picture that the originators sometimes forget to put into their documents. But I'm not in the market for a PHP book because the manual is so good and because years in the salt mines of C have pretty well taught me how to code a solution to a problem.
Let me hit on one more thing if I may. When you read the source code, you're reading the truth. When you the canonical documents (the language spec or the documentation supplied with the language) you're one step away from the truth. When you read a textbook, you're two steps away from the truth.
I'm generally too lazy to read the source code (not always -- that's how I learned Unix networking, but there were some special circumstances there or I'd just have read a book like a sensible person), but I've been bushwhacked by enough documentation bugs to do as much learning as I can from the canonical documents.
YMMV, of course.
Absurd example if you know how Windows does this (you are in a maze of twisty little CLSIDs).
But then, this was a troll.
The best thing about VRML is that anybody can make a VRML model. It's plain text (utf8) and marvelous worlds have been built using nothing more than vi or notepad. The worst thing about VRML is that anybody can make a VRML model.
A 200K file for a little bitty building is obscene. You absolutely did not do this by hand. You got it from a modeler that exported VRML, and you figured, "hell, it parses, let's put it on the Web".
I'm not singling you out. Far from it. The thing that was the absolute worst PR for VRML was that easily half the VRML worlds out there were bloated pigs just like your world. That's because hardly anybody valued small, fast worlds, and even fewer knew how to build them. For instance, I've got three VRML decimators (one uses Garland & Heckbert, one uses Hoppe, and I don't know what the third one uses), and I wouldn't dream of publishing a VRML model on the web without sending it through at least one of the decimators.
And don't get me started on color and lighting. Jesus H. Christ, you can do beautiful things with lighting in VRML. You don't have photon tracing (which means the scene will render in your lifetime) but you've got enough effects to make something really beautiful. Not one world in a twenty uses anything but the headlight and primary colors. That alone is responsible for VRML's rep as "cartoonish".
There are many better examples than this one of what you can do with color and lighting when you take a little time, but I might as well toot my own horn.
Rev. Bob "Bob" Crispen
The VRMLworks
I think it's important to be a little more careful in our speech about this issue. As Roger McGuinn's testimony reveals, it is common for artists to get nothing from the sale of a CD.
If you believe that artists get a fraction of a penny from CD sales, then you have to conclude that people who use gnutella, etc. are in some sense stealing from the artists. Those fractions of a panny are the only moral ground the major labels have to stand on, and by not treating them as fictional, we play into the RIAA's PR campaign.
Artists get money from CD sales == Microsoft innovates
I'm now a former Netscape user. It's still on my machine, but I use Opera 90% of the time and MSIE 9% of the time, and it's only for things like VRML and some multimedia that I ever fire Netscape up any more.
What really pushed me over the edge was the first release of Mozilla.
Never mind that it took approximately forever to get the downloader to get all the pieces, and never mind that the "smart installer" left all kinds of crap I had to weed out of the registry when it only installed halfway. And never mind that it didn't stay lit long enough to get past the splash screen. This is alpha software, and those faults can be forgiven.
But what can't be forgiven is that Mozilla is even more bloated than Netscape 4.x. And it will never get any smaller.
There is simply no point in a browser being that big. Web surfing is not my life, and it will never be my life. When I can install two good C compilers (which I use, in part, to earn my living) and they take up less space together than a web browser, something's wrong.
Netscape has forgotten a fundamental principle of software engineering: incremental development. Had they released a browser with about the same functionality (and about the same size) as Opera, anybody who had the tiniest bit of savvy and anybody who had the smallest disgust at Microsoft's anticompetitive practices would have jumped right on it and stuck with it as they added functionality.
But as things are, Mozilla is born to be bloatware, and I no longer have room on my machine or in my life for bloatware browsers.
Its amazing how fast I can throw somebody off simply by putting them in front of Opera.
Do what I did to get my wife and kid to switch over: set up the buttons in Netscape's odd order on the toolbar (back, forward, then reload?), and move the URL bar up to the top.
That's all it took, and they were happy.
Just like heihol, I use Opera for information and MSIE for worthless gimmicks, crossing my fingers as I go.
I'll bet the reason your system was set up to ding you on indentation was to make life easier for the TA who had to grade your projects.
On making post-compilation debugging easier, much of the time Ada makes it nonexistent! It's reasonable to expect that if an Ada program compiles, it runs, and runs correctly. CS students and other beginners, who show much more creativity in misunderstanding a problem than folks with more experience, may be an exception to this rule, but not by much.
Back in the day, many platforms didn't even have Ada debuggers, and while it'd be hyperbole to say we didn't miss them, we got to the end of the project without too many suicides or homicides.
I first hired on with my present employer when a large project using FORTRAN was in its integration phase. At the time I hired on, the project had gone six months past the delivery date, and we finally delivered some eighteen months after that.
Being fairly perceptive, I got off that project as quickly as I could and onto a project in Ada that used a software engineering approach, with strict rules about control flow and data flow, encapsulation, and intercommunication between elements. Not that I knew much of that, or even what that was all about, at the time. I was just glad to get off that first project.
The Ada project not only delivered on time, but actually under-ran the hours allocated for integration, even when we had to separate the code into two separate processes and put it on a multi-processor system.
Since then I've worked on projects in Ada, FORTRAN, C and C++, and found that while software engineering discipline could be used on a project in any language, in general Ada seemed to support it better. Whether this was due to the language itself or whether project managers who believe in and understand software engineering happen to pick languages like Ada, I don't know.
I do know one thing: every Ada project I've been on has taken a smaller time for integration than any project I've been on in other languages. This includes one project where four different contractors developed software in three different cities, and when it all went together the first time, it ran.
I've also noticed that in other languages, particularly C++ in the wrong hands, changes made to one part of the system have a far greater tendency to break other people's code than they do in Ada.
Finally, I've noticed that some of the time savings from integration is spent at coding time cursing the compiler and the language for not letting you get away with stuff. But not all the time savings. And it's a lot easier to fix compile time errors than runtime errors.
I don't write Ada for fun. I don't think many people do. And since Ada work has dried up, I don't write it much for a living any more either. But if I had a big project with a tight schedule that we needed to make money on, I'd certainly push to use Ada on it.
I was kind of hoping you'd follow up on that. I infer from the way that's said that you probably believe that an engineering approach to software isn't of much value to you.
You're certainly entitled to that opinion, if it is your opinion. But I hope I'm similarly entitled to being proud of what I believe is a more fully scoped professionalism.
I do take issue with Ada being mostly academic. My experience with it has been very much in the real world. And I think in academia, the flavor of the month is either C++ or Java.
I just escaped a C++ project at work that was being run by free spirited OO bigots from academia who had never delivered more than a few hundred lines of code on time and on budget. Needless to say, it was a disaster. I'll take professionals over amateurs every time.
This is absolutely not an Ada vs. C++ issue. It's possible to have a bad design and irresponsible practices in any language.
>And yes, it did seem verbose, cumbersome and dull - which was also what individuals became if they programmed in it for too long.
Sorry for such an obvious response, but I'd much rather have the person flying the plane I'm on be a little verbose, cumbersome, and dull.
Ada doesn't have hack nature. Almost nobody writes Ada for fun. People who write Ada usually do it for a living and usually do it in a large project. I'd almost be willing to assert that for quick hacks using Ada is a stupid idea. There are times when you need a fondue fork and times when you use an air hammer.
Absolutely true. They realized, to take one small example, that even though programmers should do array bounds checking, in the real world they don't. So they built that into the compiler. I've been called out in the middle of the night on a project in FORTRAN to fix what turned out to be somebody else's code running of the end of an array into where my code was running, so I'm grateful to the Ada designers for that.
>My feeling is that this philosophical influence on a language tends to lead to a more cumbersome language.
I don't know what "cumbersome" means. If it means that it's more difficult to get something out of the compiler than it is in C, I agree. But then my practice in C and C++ is often to compile and link and immediately fire up the debugger without even bothering to see if it runs, because I know it won't. By contrast, if code got out of an Ada compiler, you knew it would probably run and maybe even do the right thing when it ran.
>Indeed, Ada is a complex enough language that it took years to create a certified version of the compiler.
The word is "validated", and I don't recall it taking years.
>NOBODY wanted to use Ada.
Young military officers figured out pretty quickly that:
- they wouldn't be in the service forever, and
- there were more C++ jobs than Ada jobs in the civilian world.
As a result, they raised hell about the Ada requirement, and program offices were issuing waivers for the equivalent of a case of the vapours.Bzzzzt. Sorry. Not that I've ever seen. There may be shops that do that (God knows why), but the language reference manual and "official" style guides are filled with words and examples about capitalization as an aid to readability.
Ada is case-insensitive, perhaps due to this requirement. There are arguments on both sides of that issue, and I can't find myself getting passionate about either side -- this being /., no doubt others will supply this momentary lapse.
There was only one Ada horror from its requirement to be usable internationally and on older machines: "not equal" is written "/=" because some terminal on some machine didn't have a "!".
>Objects came late to Ada.
I really believe that Ada 95 failed to capture a large mindshare for no other reason than because its creators refused to use the simple word "class" and used a weird syntax of "tagged types" and so on to describe what was:
- a difficult concept to begin with, and
- a concept that other people were already describing with other words.
No doubt some CS PhD had good reasons why "tagged type" and the rest were "better" words. I'm reminded of the couplet to the pigheaded driver:with Ada.Text_IO; procedure Hello is begin Ada.Text_IO.PutLine("Hello, world!"); end;
Besides, the subject line is all wrong anyway. If you've got big enough stones, it doesn't matter what kind of house you live in.
And I find the loser tag very enjoyable, since it's such a perfect illustration of how badly you missed the point.