... Humans self organize and process signals in completely unconscious structures with no sense of pleasure. Humans like the hair dresser, plumber, or IT professional for instance. Self organisation and signal processing is what humans do. We've known for some time that certain types of electrical stimulation (cattle prods) can strengthen a connection where as others (free booze) can weaken a connection. But how this turns into cities and countries, we don't have a clue.
Nonsense. On modern non drive-by-wire cars, the real danger is that the steering lock will freeze the steering. Normally, that can't happen, because the transmission linkage won't allow the key to be turned to "lock" unless in Reverse.
As for loss of power steering, that's no big deal. At highway speeds, you don't need it. I've lost power steering in '67 Oldsmobile Toronado, which is several tons of massive front wheel drive, and it only becomes difficult to steer at less than 10mph. Even then, it's manageable with some effort.
I've lost power brakes, too. Braking requires considerably more effort, but stopping distances are essentially unaffected.
--
You're both wrong. Optimisation is not dependent on syntax, it is ultimately dependent on the semantics encoded in the syntax. The same semantics (say, that of the relational model) may be expressed in innumerable languages. Obviously, some of these languages will be more expressive than others, but all (in theory) will result in the same run time performance. They will not, however, result in the same developer performance or ease of maintenance.
The goal of better syntax is not faster databases. Run time performance is not always the primary aim. The goal of better syntax is faster, easier, and more reliable development, and provably (within reason) correct data management code. For the PHB, that means cheaper development and maintenance.
As for "REL [sic] or any other SQL++ contender" not having much chance, you're right. But I remember when "not much chance" was the typical response of IT directors when asked if they'd ever give up greenscreen mainframe terminals and adopt PCs. The same will always be said about programming languages, too. Entrenched languages do get displaced. For example, how many shiny new applications are being written in FORTRAN?
Anyway, I see nothing wrong with retaining SQL as a protocol for communicating with legacy databases, especially if the SQL code is machine-generated. The external database connection facilities I'm developing for Rel use SQL in this manner. But, just as I'm not sending email by hand-coding SMTP transactions, and not writing complex GUIs in assembly language, I'd rather not develop database applications using SQL. It's simply not an efficient language for writing complex apps.
It works. Almost. I've largely lost interest in it. The reasons why it isn't a practical way to program are legion, and BlueJ is probably a better implementation of the same idea, anyway.
Best feature: You can modify a running program while it's still running.
Back when I was a "computer consultant", one of my clients shoved his new computer at me and said, "fix it."
It wouldn't boot. When I opened the lid, I found the motherboard screwed tightly to the case without standoffs -- just a circuit board on bare metal. Protrusions on the case prevented it from sitting flat, with the result that the motherboard was bent into a sharp 'U' shape.
As a result, the peripheral cards couldn't reach the mobo slots. To address this, the mountings on the case and peripheral cards had been modified with some heavy object (perhaps a tire iron?) resulting in a twisted wreckage of mounting hardware, stray pieces of plastic recruited as supports, glue, cross-threaded screws and the occasional rubber band.
Turns out my client purchased the computer in parts and then assigned one of his employees -- a cashier with a computing hobby and zero prior hardware experience -- to assemble it.
Amazingly, after an hour of remounting and bending sheetmetal into a reasonable facsimile of its original shape, the thing actually worked.
Slashdot Mirror
... Humans self organize and process signals in completely unconscious structures with no sense of pleasure. Humans like the hair dresser, plumber, or IT professional for instance. Self organisation and signal processing is what humans do. We've known for some time that certain types of electrical stimulation (cattle prods) can strengthen a connection where as others (free booze) can weaken a connection. But how this turns into cities and countries, we don't have a clue.
As for loss of power steering, that's no big deal. At highway speeds, you don't need it. I've lost power steering in '67 Oldsmobile Toronado, which is several tons of massive front wheel drive, and it only becomes difficult to steer at less than 10mph. Even then, it's manageable with some effort.
I've lost power brakes, too. Braking requires considerably more effort, but stopping distances are essentially unaffected. --
You're both wrong. Optimisation is not dependent on syntax, it is ultimately dependent on the semantics encoded in the syntax. The same semantics (say, that of the relational model) may be expressed in innumerable languages. Obviously, some of these languages will be more expressive than others, but all (in theory) will result in the same run time performance. They will not, however, result in the same developer performance or ease of maintenance.
As for "REL [sic] or any other SQL++ contender" not having much chance, you're right. But I remember when "not much chance" was the typical response of IT directors when asked if they'd ever give up greenscreen mainframe terminals and adopt PCs. The same will always be said about programming languages, too. Entrenched languages do get displaced. For example, how many shiny new applications are being written in FORTRAN?
Anyway, I see nothing wrong with retaining SQL as a protocol for communicating with legacy databases, especially if the SQL code is machine-generated. The external database connection facilities I'm developing for Rel use SQL in this manner. But, just as I'm not sending email by hand-coding SMTP transactions, and not writing complex GUIs in assembly language, I'd rather not develop database applications using SQL. It's simply not an efficient language for writing complex apps.
Planes do NOT go 'up' because of low pressure above the wing. Otherwise, how would they fly upside down? An entertaining explanation is found at http://www.jefraskin.com/forjef2/jefweb-compiled/p ublished/coanda_effect.html
http://tomatoide.sourceforge.net/
It works. Almost. I've largely lost interest in it. The reasons why it isn't a practical way to program are legion, and BlueJ is probably a better implementation of the same idea, anyway.
Best feature: You can modify a running program while it's still running.
It wouldn't boot. When I opened the lid, I found the motherboard screwed tightly to the case without standoffs -- just a circuit board on bare metal. Protrusions on the case prevented it from sitting flat, with the result that the motherboard was bent into a sharp 'U' shape.
As a result, the peripheral cards couldn't reach the mobo slots. To address this, the mountings on the case and peripheral cards had been modified with some heavy object (perhaps a tire iron?) resulting in a twisted wreckage of mounting hardware, stray pieces of plastic recruited as supports, glue, cross-threaded screws and the occasional rubber band.
Turns out my client purchased the computer in parts and then assigned one of his employees -- a cashier with a computing hobby and zero prior hardware experience -- to assemble it.
Amazingly, after an hour of remounting and bending sheetmetal into a reasonable facsimile of its original shape, the thing actually worked.