On the other hand, nowhere in Perl's documentation is it fully documented what
$a = $b + $c;
does. Compare this with languages like C or Scheme or (I think) Python that have a formally defined and documented semantics (even if C allows for some cases that are explicitly implementation-defined or undefined behaviour).
There was a Sam'n'Max cartoon - disappointing, Sam's voice wasn't done by the same guy (who? any relation to the Inspector Gadget voice?) and it wasn't funny. So I don't have high hopes for your forecast 2034 summer movie.
You could have an editor where you type arbitrary characters and which then warns if they veer off the DTD, as you suggest. But this would get annoying since if you are typing 'hello' then the document is not well-formed from typing the first character until you have typed the last. So you'd get lots of warning lights all the time.
I think it would be better to make the editing commands depend on the DTD, so rather than typing < a > to begin an <a> element, there is a toolbar with all the elements that can validly be included at this point in the document. Pressing the toolbar 'a' button creates the element, creates any mandatory sub-elements inside it, and positions the cursor at the first place you'd need to enter text. It could also have 'add attribute' buttons for each attribute allowed at the current point.
What do you mean by 'cram a stateless protocol into a state-filled paradigm'? I thought classical NFS runs over UDP (although you can make it use TCP instead if you think your network is unreliable).
If you want an example of such 'cramming', look at HTTP.
I think there may be a licence incompatibility in that any work derived from the BSD code must give credit in docs and help screens, but the GPL does not have any such restriction, so if you tried to distribute the work under the GPL then you would have lost the restriction about giving credit, and (by some legal theory I don't understand and which may or may not exist) the people who get the code from you and try to exercise their rights under the GPL would be infringing the copyright on the BSD-licensed code.
Similarly, if I had some code that said 'you can use this but only while doing a handstand' and tried to combine it with GPL'd code, I couldn't distribute the resulting work under the GPL because people receiving it wouldn't know about the handstand condition. I would have to distribute it under 'GPL plus handstand' - but then this wouldn't be allowed by the GPLd code I started with, since you're not allowed to add extra restrictions.
Writing a program that a computer can interpret is the easy part. The skill is in making it understandable to a human too, and that is where programming becomes an art. If writing a factual article in a newspaper is art then so is writing a program which clearly shows the programmer's intention and guides the reader to understanding how it works.
I think craft is probably a better term though, because of the functional aspect and the fact that the end product has to 'work'. Art doesn't have to work or _do_ anything.
I haven't debugged a program like that, but I was able to tell (on the BBC Micro - of course - what other machine would it be) whether the CPU was busy or not by listening to hum from the speaker, and to tell what kind of memory access it was doing (a simple infinite loop sounded different from accessing many different memory locations).
But for high-level debugging I don't think you could get anything useful. Very very few people code close enough to the metal that listening to where the CPU is branching to would give a clue about whether the code is correct. Unless you start instrumenting the code to produce 'bad' sounds when bad conditions are detected, but if you know how to do that, you might as well stop the program and drop into the debugger...
The primary difference is that keys on a keyboard are binary input while piano keys are analog.
So a computer keyboard is more like an organ or a harpsichord. ISTR that one of the BBC Micro's Welcome programs was called 'organ', and straightforwardly turned the top two rows of keys into white and black notes. And I wrote similar things myself at various points, recording input music and playing it back or trying to generate a similar-sounding tune using simple probabilities of which notes follow each other.
This kind of thing as a basic programming exercise (pun not intended) seems to have died out these days, mostly because sound programming is no longer as simple as it was, which is a pity. Almost all computers have some kind of beeper. Perhaps some day we'll get back to the level of twenty years ago and be able to say % perl -MSound 'beep 256, 1'
to play middle C for one second.
Yes, it's well known that you can't mix old-style BSD and GPL, which is why Debian is avoiding the new licence, because it is a bit like old-style BSD in this respect.
You're completely right, I was confusing Apache and XFree86... why do these similar news stories come along at the same time? It's as if we were supposed to pay attention or something.
It prevents you including GPL-licensed code in an X server derived from XFree86; that is enough reason for Debian to avoid the new release, it seems.
Interesting that the FAQ now acknowledges that the 1.1 licence does not permit redistribution under the GPL; before, the XFree86 people were insisting that in their opinion it was allowed. Unless I'm confusing two different licences here.
Why don't these companies wake up and realize the paradigms have changed? It's not like there isn't ample opportunity to make money with the new technology. Why stick to the failing methods of yesteryear?
They are adapting to new technologies, and that is the problem. Under the 'failing methods of yesteryear', you would buy a record and then be able to play it when and where you wanted, subject to copyright law's restrictions on public performance. When you'd listened to it enough you could sell it to a secondhand record shop, or maybe even donate it to a library.
What the record / movie companies would like to do is to use new technologies to stop all that. They are moving with the times, just not in the way that you would like. Progress is not always a good thing.
Breaking it is by definition unwise
on
iPod Mini Autopsy
·
· Score: 3, Insightful
He that breaks a thing to find out what it is has left the path of wisdom. -- Gandalf
Unfortunately in the world of television there are all sorts of restrictive contracts with actors and content providers, for example repeat fees, and making programmes freely distributable might infringe those. (I don't work in broadcasting but this seems fairly obvious.)
I think it would be best if the BBC could avoid getting tangled up in such contracts, but that would mean paying more up front, and I don't think the organization is ready to gear itself towards free content. They're still thinking of making shows for broadcast television and sticking any bits and pieces online afterwards if they can do so without paying much more.
OK, supposing that you took the ASF's statement as good enough and distributed their code under the GPL. You might have a solid legal basis to do so (doctrine of estoppel or whatever - IANAL).
But what happens if a third party makes some change to Apache and releases it under the Apache licence? You would also need that third party's written statement to distribute the whole under the GPL. Whereas if the Apache licence were more obviously and transparently GPL-compatible, such that it didn't need these disclaimers, there would be no problem combining APSL-licensed code from different sources as part of a GPL'd program.
The annoying thing is that the fix is really simple. All the Apache people need do is dual-license the code under both their own licence and the GPL, as happens with Perl. If they really believe that the APSL allows GPL'd distribution anyway, they should have no problem doing this, however it helps the rest of the world who don't find the APSL's wording quite so obvious.
(Third parties would still have the option of distributing a modified version under APSL only, but at least it would be obvious and simple what you need to do to allow GPL distribution of your changes.)
If the Apache copyright holders think that the software can be distributed under the GPL, they should make this explicit in the copying conditions.
'This is free software; you may distribute it according to the Apache Software License version 2 or later, or (at your option) the GNU General Public License version 2 or later.'
Problem solved.
Re:Best learner's C++?
on
Practical C++
·
· Score: 2, Interesting
I found Stroustrup's book The C++ Programming Language to be quite good, at least if you already know some of the language. It's not quite a tutorial and not quite a reference manual but works nicely as a blend of both.
There needs to be some way to get manufacturers to put their money where their mouth is when they say 'hardware item X is reliable'.
One way is by a warranty - if they give a long warranty, they're reasonably sure the device is reliable since otherwise they would lose money (and no company wants to do that). However a warranty might be a bit _too_ strong - it is too expensive for the manufacturer to honour and so the extra price a consumer pays is too high. Besides, what you get from a warranty isn't usually what you want. A replacement unit is awkward for the manufacturer to provide, and they price the warranty accordingly, but the cost to a user of a disk failure is not the loss of a lump of hardware but the inconvenience of downtime. You could go out and buy a replacement disk anyway, and surely would rather than wait two weeks for a warranty claim to be processed. And the manufacturer has to do some kind of checking on each and every warranty return; although this gathers data on reliability, it adds to the expense. So you pay a relatively large amount for a warranty that isn't that useful except as a test of how confident the manufacturer is about reliability.
What could happen instead is some kind of 'reliability bond'. When the device is launched and for a year or so afterwards the manufacturer sells certificates. After five years an independent testing lab works out the mean time before failure of the device. Then the holder of each certificate is entitled to a payout which increases with the device's unreliability. (If the MTBF is greater than some threshold - so the device has good reliability - then no payout is made.)
This gives you a way to check whether the manufacturer is being honest. The price they want to charge for a certificate indicates their judgement of reliability - or at least gives a good indication. So if the manufacturer says 'this disk is specified for an MTBF of 4 years', you can ask 'OK, how much is the certificate which pays out $1 for each month less than that?'. If they price these instruments higher than, oh, say $3 each, then they're obviously not that comfortable with the claims of their marketing department.
This also lets you hedge against failure of the devices - eg if you are an OEM considering whether to use Seagate hard disks in your PCs, you might want to insure against large numbers of them failing.
The difficulty is finding an independent testing agency and a quantitative measure of reliability across all disks sold.
Slashdot Mirror
On the other hand, nowhere in Perl's documentation is it fully documented what
$a = $b + $c;
does. Compare this with languages like C or Scheme or (I think) Python that have a formally defined and documented semantics (even if C allows for some cases that are explicitly implementation-defined or undefined behaviour).
Obligatory Futurama quotation:
Fry: I'm good at video games and bad at everything else. That's why I wish life were more like a video game.
Farnsworth: Can you put that in the form of a question?
Fry: Uh, what if that thing I said?
There was a Sam'n'Max cartoon - disappointing, Sam's voice wasn't done by the same guy (who? any relation to the Inspector Gadget voice?) and it wasn't funny. So I don't have high hopes for your forecast 2034 summer movie.
You could have an editor where you type arbitrary characters and which then warns if they veer off the DTD, as you suggest. But this would get annoying since if you are typing 'hello' then the document is not well-formed from typing the first character until you have typed the last. So you'd get lots of warning lights all the time.
I think it would be better to make the editing commands depend on the DTD, so rather than typing < a > to begin an <a> element, there is a toolbar with all the elements that can validly be included at this point in the document. Pressing the toolbar 'a' button creates the element, creates any mandatory sub-elements inside it, and positions the cursor at the first place you'd need to enter text. It could also have 'add attribute' buttons for each attribute allowed at the current point.
What do you mean by 'cram a stateless protocol into a state-filled paradigm'? I thought classical NFS runs over UDP (although you can make it use TCP instead if you think your network is unreliable).
If you want an example of such 'cramming', look at HTTP.
Of course, this proposed GPL+obnoxious advertising clause wouldn't solve the particular problem of combining with vanilla GPL software.
I think there may be a licence incompatibility in that any work derived from the BSD code must give credit in docs and help screens, but the GPL does not have any such restriction, so if you tried to distribute the work under the GPL then you would have lost the restriction about giving credit, and (by some legal theory I don't understand and which may or may not exist) the people who get the code from you and try to exercise their rights under the GPL would be infringing the copyright on the BSD-licensed code.
Similarly, if I had some code that said 'you can use this but only while doing a handstand' and tried to combine it with GPL'd code, I couldn't distribute the resulting work under the GPL because people receiving it wouldn't know about the handstand condition. I would have to distribute it under 'GPL plus handstand' - but then this wouldn't be allowed by the GPLd code I started with, since you're not allowed to add extra restrictions.
Writing a program that a computer can interpret is the easy part. The skill is in making it understandable to a human too, and that is where programming becomes an art. If writing a factual article in a newspaper is art then so is writing a program which clearly shows the programmer's intention and guides the reader to understanding how it works.
I think craft is probably a better term though, because of the functional aspect and the fact that the end product has to 'work'. Art doesn't have to work or _do_ anything.
I haven't debugged a program like that, but I was able to tell (on the BBC Micro - of course - what other machine would it be) whether the CPU was busy or not by listening to hum from the speaker, and to tell what kind of memory access it was doing (a simple infinite loop sounded different from accessing many different memory locations).
But for high-level debugging I don't think you could get anything useful. Very very few people code close enough to the metal that listening to where the CPU is branching to would give a clue about whether the code is correct. Unless you start instrumenting the code to produce 'bad' sounds when bad conditions are detected, but if you know how to do that, you might as well stop the program and drop into the debugger...
So a computer keyboard is more like an organ or a harpsichord. ISTR that one of the BBC Micro's Welcome programs was called 'organ', and straightforwardly turned the top two rows of keys into white and black notes. And I wrote similar things myself at various points, recording input music and playing it back or trying to generate a similar-sounding tune using simple probabilities of which notes follow each other.
This kind of thing as a basic programming exercise (pun not intended) seems to have died out these days, mostly because sound programming is no longer as simple as it was, which is a pity. Almost all computers have some kind of beeper. Perhaps some day we'll get back to the level of twenty years ago and be able to say
% perl -MSound 'beep 256, 1'
to play middle C for one second.
Yes, it's well known that you can't mix old-style BSD and GPL, which is why Debian is avoiding the new licence, because it is a bit like old-style BSD in this respect.
You're completely right, I was confusing Apache and XFree86... why do these similar news stories come along at the same time? It's as if we were supposed to pay attention or something.
It prevents you including GPL-licensed code in an X server derived from XFree86; that is enough reason for Debian to avoid the new release, it seems.
Interesting that the FAQ now acknowledges that the 1.1 licence does not permit redistribution under the GPL; before, the XFree86 people were insisting that in their opinion it was allowed. Unless I'm confusing two different licences here.
They are adapting to new technologies, and that is the problem. Under the 'failing methods of yesteryear', you would buy a record and then be able to play it when and where you wanted, subject to copyright law's restrictions on public performance. When you'd listened to it enough you could sell it to a secondhand record shop, or maybe even donate it to a library.
What the record / movie companies would like to do is to use new technologies to stop all that. They are moving with the times, just not in the way that you would like. Progress is not always a good thing.
He that breaks a thing to find out what it is has left the path of wisdom. -- Gandalf
Unfortunately in the world of television there are all sorts of restrictive contracts with actors and content providers, for example repeat fees, and making programmes freely distributable might infringe those. (I don't work in broadcasting but this seems fairly obvious.)
I think it would be best if the BBC could avoid getting tangled up in such contracts, but that would mean paying more up front, and I don't think the organization is ready to gear itself towards free content. They're still thinking of making shows for broadcast television and sticking any bits and pieces online afterwards if they can do so without paying much more.
I find delta can often be useful for automatically narrowing down a large test case to a small one.
And BTW, it's 'Dijkstra'.
OK, supposing that you took the ASF's statement as good enough and distributed their code under the GPL. You might have a solid legal basis to do so (doctrine of estoppel or whatever - IANAL).
But what happens if a third party makes some change to Apache and releases it under the Apache licence? You would also need that third party's written statement to distribute the whole under the GPL. Whereas if the Apache licence were more obviously and transparently GPL-compatible, such that it didn't need these disclaimers, there would be no problem combining APSL-licensed code from different sources as part of a GPL'd program.
The annoying thing is that the fix is really simple. All the Apache people need do is dual-license the code under both their own licence and the GPL, as happens with Perl. If they really believe that the APSL allows GPL'd distribution anyway, they should have no problem doing this, however it helps the rest of the world who don't find the APSL's wording quite so obvious.
(Third parties would still have the option of distributing a modified version under APSL only, but at least it would be obvious and simple what you need to do to allow GPL distribution of your changes.)
If the Apache copyright holders think that the software can be distributed under the GPL, they should make this explicit in the copying conditions.
'This is free software; you may distribute it according to the Apache Software License version 2 or later, or (at your option) the GNU General Public License version 2 or later.'
Problem solved.
I found Stroustrup's book The C++ Programming Language to be quite good, at least if you already know some of the language. It's not quite a tutorial and not quite a reference manual but works nicely as a blend of both.
There needs to be some way to get manufacturers to put their money where their mouth is when they say 'hardware item X is reliable'.
One way is by a warranty - if they give a long warranty, they're reasonably sure the device is reliable since otherwise they would lose money (and no company wants to do that). However a warranty might be a bit _too_ strong - it is too expensive for the manufacturer to honour and so the extra price a consumer pays is too high. Besides, what you get from a warranty isn't usually what you want. A replacement unit is awkward for the manufacturer to provide, and they price the warranty accordingly, but the cost to a user of a disk failure is not the loss of a lump of hardware but the inconvenience of downtime. You could go out and buy a replacement disk anyway, and surely would rather than wait two weeks for a warranty claim to be processed. And the manufacturer has to do some kind of checking on each and every warranty return; although this gathers data on reliability, it adds to the expense. So you pay a relatively large amount for a warranty that isn't that useful except as a test of how confident the manufacturer is about reliability.
What could happen instead is some kind of 'reliability bond'. When the device is launched and for a year or so afterwards the manufacturer sells certificates. After five years an independent testing lab works out the mean time before failure of the device. Then the holder of each certificate is entitled to a payout which increases with the device's unreliability. (If the MTBF is greater than some threshold - so the device has good reliability - then no payout is made.)
This gives you a way to check whether the manufacturer is being honest. The price they want to charge for a certificate indicates their judgement of reliability - or at least gives a good indication. So if the manufacturer says 'this disk is specified for an MTBF of 4 years', you can ask 'OK, how much is the certificate which pays out $1 for each month less than that?'. If they price these instruments higher than, oh, say $3 each, then they're obviously not that comfortable with the claims of their marketing department.
This also lets you hedge against failure of the devices - eg if you are an OEM considering whether to use Seagate hard disks in your PCs, you might want to insure against large numbers of them failing.
The difficulty is finding an independent testing agency and a quantitative measure of reliability across all disks sold.
That's GNU/Lin----, dammit!
Or even ---/Lin---- where --- stands for "---'s not ---".
Six billion items... how does that compare with other search engines like Alltheweb or Teoma, or even the venerable Altavista?