You're debating which language is better based on whether a one-liner takes 9 lines or 12 to code?! If it were that easy, we'd all go back to writing in BASIC.
I do not like C++ as a language though. C's use can be justified for low-end systems, but C++ is in more of a quandary, since its architecture has been superceded by newer languages
The problem is that actually, it hasn't, although it surely should have been a long, long time ago. Alas, the bulk of the software development industry is so driven by marketing hype and buzzwords that it has collectively failed to develop a new language that is a serious choice as a general purpose programming language spanning many problem domains.
A lot of newer languages imitate C++'s approach in terms of design tools, most obviously Java, C# and now Visual basic.Net. However, the beauty is only skin-deep; these languages often lack the solid, underlying framework and reasoned design decisions that have gone into C++, with the result that most of the time they are lucky to be as good, never mind an improvement. The addition of generics to Java several years later is an obvious demonstration of what happens when you go for buzzwords and you meet someone who went for solid design principles.
Many other languages have something valuable to offer developers, but then go and spoil it in some other way, ultimately winding up with something that might fit certain niches, but isn't suitable for major development projects across a wide range of areas. Some common examples come immediately to mind:
Java
Pro: emphasises safety, readability, and portability; con: sacrifices low-level control (and with it performance) and only supports a limited number of programming techniques, encouraging over-engineered, component-based designs
Perl
Pro: quick, flexible, useful for rapid development of useful tools; con: terrible scalability and unfriendly (to both programmers and tools) syntax restrict it almost exclusively to quick-and-dirty projects
Haskell
Pro: elegant and powerful syntax, serious support for powerful programming tools like higher-order functions; con: overly academic community, and puts purity above pragmatism, making it hard to use in real-world projects where things like UIs are involved
The list goes on, but the important point is that while each of these has good applications, they all have obvious flaws as well. Java is the closest to a serious general purpose language, but even today most of the serious Java code is restricted to server-side back-ends driving databases or some thinly disguised variant on that theme.
C++, for all its sins, remains a pragmatic, balanced choice for a general purpose language that can be effectively adapted to a diverse range of applications. Is it a perfect language? Of course not. It has gaping flaws in any number of areas. The problem is that no-one has yet produced an alternative that beats it on all of them without significant compensating weaknesses.
Not just sad - it will set a very dangerous precedent for all Linux corporate offerings in the future!
There was always going to be a big test of the free software ideal in the business world sooner or later. After all, despite what some evangelists may choose to believe, it's clear that most of the major development work on most of the big FOSS projects is still done by a relatively small group of people working for a relatively small number of sympathetic companies. Most of the funding comes from elsewhere in those companies, and they support the free software development for commercial/economic/PR reasons.
The catch is that often, those reasons don't seem to be well-understood or fully thought through. While it's not free-as-in-speech software, Sun's continued support of Java is an excellent example of this. These are still businesses looking to make a profit, so if they don't see a return on their investment, they are inevitably going to kill the project (or stand by it and lose money, which is not sustainable).
So, at the risk of committing Slashdot Heresy(TM)... If Novell do fail because they couldn't support a business model based around Linux, would the precedent really be "dangerous", or simply realistic? It's funny how when we're talking about things like the **AA losing out to P2P, there's little sympathy for a "doomed business model", yet when we're talking about a company trying to sell free-as-in-beer software and (perhaps unsurprisingly?) not making much profit, the spin tends to be rather different.
It gives me an idea how things will look to search engines, and is also a decent first pass at testing text-to-speech browsers.
I was going to raise the accessibility issue, but you beat me to it.
One of the problems with using images for text is that it makes it very difficult to render properly in a non-visual browser. Even with alt tags, you don't have the usual accessibility-friendly CSS to indicate whether things should be read normally, spelt out (as for abbreviations), etc.
It would be nice if a future (X)HTML standard could provide a slightly more general "accessible alternative" for non-text data, be it images or embedded content like Flash. At least then those who are visually impaired would have a fighting chance of understanding the content. In the meantime, I'll take an approach that at least degrades gracefully because the text is in there somewhere.
If you're running with something like Firefox's Flashblock extension then it doesn't degrade at all gracefully.
If I configure a proxy to prevent downloading of image files, I can block most of the ads on the web, yet some pages do not display as the designer intended. Is that their fault for using images, or mine for deliberately blocking content that might be legit?
So that you can isolate a test case and send it to the library vendor so that they can fix it.
I'm not sure my customer will understand that, as I explain to them why we've just lost their whole day's data when our software crashed...
Maybe, but, for the library user, I don't see how that's better than an assertion.... If you replace "if(/*test*/) abort();" with "if(/*test*/) { set_error_code(); return;}", you're still paying the runtime price with no added benefit for the end user.
Not at all. What if there is more going on in the system than just the thread that called the abortive library function? It might only be appropriate to terminate that one thread. Even then, you might want to do so after attempting to preserve as much user data as possible so that the situation can be salvaged later on, and aborting instantly denies you any chance to implement such defensive programming techniques.
Now, there are cases where a user could legitimately try to recover from a broken state, but generally it's better to halt. Other posters in this thread have done a good job of explaining some of the reasons for that.
As I've said elsewhere, that's not the library code's decision! If you can show me a compelling argument that it should be anywhere in this thread, please do, because I certainly haven't seen one. As I've noted before, forcing this kind of draconian response violates the basic principles of modularity and encapsulation that underpin any strong design.
Assuming the programmer does not want to recover from a broken state (which is common), the legitimate uses of exceptions are in/exceptional/ cases that do not really indicate a bug.
I'd argue that trying some recovery action is very common today, and moreover that your perspective of exceptions as a design tool is overly narrow. The motivation for exceptions is to separate identifying an exceptional condition from dealing with it. Where libraries are concerned, that separation of responsibilities can provide the calling code with the opportunity to take recovery action if it wants to. If not, it can always let the exception propagate unhandled (which will abort a C++ program by default anyway) but at least it gets the choice.
In some languages (e.g. C), it is considered perfectly acceptable for libraries to use assert(), which can terminate the application, to notify the caller of improper usage.
Perhaps a decade ago, but not today. In all that time, I have neither seen a real world project, nor talked to a real world programmer, that suggested this was acceptable practice.
Unfortunately, in C and C++, the standard way of informing you that your code needs fixing is assert(), which aborts the program.... You can argue that one's better than the other, but most people are going to stick with whatever approach is considered the standard.
Well, assert is indeed standard, but the principle is much more general, and I've never yet worked on a production project that actually used the standard macro rather than a customised version.
I think a more accurate way to state that would be: No library code should ever cause the whole application to abort when the application is being used by an end user.
That's not a more accurate statement, it's simply a different one.
Under development it's a completely different situation. The top goal isn't running cleanly at all cost; the top goal is finding anything that might be a bug.
Perhaps, but if I'm the application developer and you're the library developer, then that's my decision, not yours.
I might have all kinds of clever diagnostic code running in my application, direct comms with the debugger, other activity going on in different threads, acquired resources, or 101 other reasons that I don't want to kill my application dead, even if your library encounters a serious problem. By all means tell me about the problem, and then if I want to, I can dead-end everything to make it obvious while I'm testing. But don't tell the rest of my application, about which your library has no knowledge, how it should handle an error in one part of the program. That is the worst sort of catastrophic failure, and violates every principle of modularity and encapsulation in the book.
So what stops a library vendor from shipping two binaries -- one with NDEBUG defined and the other without?
Well, nothing, I suppose, but why would you ever want to use the one that kills your app when some internal test fails?
It doesn't help you, the library user, to determine what the problem was, other than possibly which API call actually blew up. Whether the data you gave to that one was the cause of the explosion is a different question, of course.
If you're talking about NDEBUG, presumably we're in the world of C and/or C++ here. In that case, surely it would be much better for libraries to at least return a proper error code if something goes seriously wrong, or (for C++ libraries) to throw an exception, a tool practically tailor-made for this situation?
Interestingly, the performance hit seems to be almost negiglible on an AMD Opteron in 64-bit mode with gcc 3.4, as long as the assertions themselves are trivial.
For one-off assertions at strategic points in your code, sure. The potential problems start when you have a "one-off" assertion that's tested inside nested loops and the like. As with so many performance issues, it's not what you do, it's where (and how often) you do it...
Seems to me that the library is telling you that you are caling it wrong, and you should fix your code.
Perhaps, but no library code should ever cause the whole application to abort, ever. There are few absolutes in software development, but this is one of them.
The library code is entitled to screw up whatever internal data it likes, and to give me whatever garbage out if I put garbage in, but it is not allowed to screw the rest of my program (and thus to circumvent any graceful-shutdown error-handling system I have in place there).
More seriously, assertions that can be disabled can potentially hide little errors altogether. Consider what happens if evaluating the condition for your assertion has side effects, but in release builds that condition is never evaluated. Oh, dear: now you can test quite happily on your diagnostic build, but the one you ship to your customer has an extra bug.:-(
I have always been under the impression that assertions were only ment to be active in debug versions... Most of the compilers I have used turn them off for "release" builds.
That is indeed common practice, and the traditional use of assertions. Whether it's the best practice is a different question.
In recent years, there has been a general acknowledgement within the software development community, and indeed among end users, that bugs happen. It's simply the nature of the beast. In most fields (excluding those where bugs simply aren't allowed, ever, and vastly higher investment is made in quality control) what's more important is that the application handles the situation gracefully when a bug does occur, and that when a bug is found, it is swiftly and effectively fixed.
Now, obviously you don't normally want your end users seeing the intimate details of your code, but the idea of having run-time sanity checks for internal errors even in release code isn't absurd by any means. After all, as an end-user, wouldn't you far rather your e-mail client noticed early that something wasn't quite right and shut down relatively cleanly, potentially allowing you to back up your data and/or obtain a tool to recover it before the problem went too far? The alternative -- continuing as if nothing's wrong, but based on some bad data -- could easily lead to more serious corruption and permanent data loss, with a bug report only getting filed when it's too late to do anything about it.
Of course, using assertions heavily can incur a significant performance hit, which may or may not be acceptable in your particular application. However, I would argue that the basic idea of assertions is just as valid in production code, and perhaps it's better to leave at least a key subset of assertions in your finished product, with handlers that shut down cleanly and ask the user to pass on certain key information to the developers in order to fix the bug.
Re:IPv6 Not Enough?
on
The Next Net
·
· Score: 2, Informative
I've read that people plan on embedding ips on everything from lights and toasters to make them work in concert so if every device were to need an ip address I don't think that IPv6 would hold up.
I can't remember which is greater, the number of available IPv6 addresses or the estimated total number of atoms in the universe, but either way you can rest assured that there will be more than enough IPv6 addresses to handle any foreseeable addressing needs we're going to have any time soon, even if everyone winds up with dozens of personal IP-assigned devices.
Interesting quote
on
The Next Net
·
· Score: 5, Interesting
From part-way down TFA:
"The top priority is to ensure that the standards that make the net work, are open and free for anyone to use and work with."
Interesting for many here that the new guy at the head of the IETF seems to give this issue such emphasis.
The claim was that P2P would be illegal, not that we would stop using the technology.
Sure, but suppose this case did go the wrong way for P2P. We can probably assume that shortly after the SCOTUS "vindicated" the media industry position, we'd see H.R. 666, a.k.a. the Piracy To Piracy Solicits Users' Extreme Zero Royalties Zero Payments Acts or P2P Sux0rz Pact for short.
Seriously, I'm pretty sure P2P use in the US would die out real fast if all ISPs were required by law to disclose the name and address of any users whose computers are involved in sending or receiving data on some arbitrary set of ports, to be specified and updated by some government agency without further changes in the law. (Notice that if they managed to get that open-ended concept into the law, on the no unreasonable basis that P2P would just switch to use another port otherwise, then there would be serious implications for any use of the Internet.) Couple that with, say, an automatic $10k fine or 6 month prison sentence for anyone convicted, and it would just be too risky for most people to bother, and without the volume of users P2P is dead.
It would be a very bad day for a promising range of new technologies if something like this happened, which is why it's so important to separate the technology from the acts of the user in law. The argument is just as valid here as it is when you protect car makers, knife makers, etc.
Strangely, the media industry actually did seem to have come around to doing this until this case, going after those who were clearly distributing copyright material illegally. I would have thought bringing this case, which apparently could give permanent legal support to P2P networks that might be used as a defence in lesser cases in future, was a big risk. Then again, IANAL and neither do I know which big names the industry does and doesn't directly influence over in the US.
At the risk of going all serious, to a degree I actually disagree with this, and the conclusions of TFA.
I used to spend a lot of time helping out on a couple of technical newsgroups for newbies to programming, web design, etc. They were small communities, but very helpful to those who found and took advantage of them. However, those who contributed their advice obviously had limited time to volunteer. While most posts did get an answer from someone, those that were clearly written were far more likely to receive a detailed response.
By the nature of the groups, we attracted quite a few of the IM/txt msg generation. Some of their habits (dropping all the capital letters, for example) were simply annoying, and most posters did actually start writing in reasonable English when a polite request was made pointing out that this made responding more pleasant for those who would like to help. However, sometimes the poster was so caught up in their own L337sp33k that we simply couldn't understand what was being asked. In a discussion about a technical subject, often filled with jargon with precise meanings and code snippets that obviously have to be written exactly correctly, using random abbreviations because you can't be bothered to type an extra couple of letters and then expecting someone who's volunteering their time to spend even longer trying to figure out what you meant isn't a great way to encourage helpful replies!
You're creating a straw man here. Let's think about the differences between DRM and rental.
Well, OK, but my point wasn't to equate the two, merely to demonstrate that there can be useful and successful business models that do not involve any permanent transfer of content ownership.
1. Renting costs less than buying. DRM content is the same price or more than non-DRM content.
Sorry, but I just don't get that. Buying a CD single from my local record store costs me about £4. Buying that same single from an on-line vendor costs me less than one pound. Unless you're claiming the CD cover art is worth the difference, the DRM'd but downloadable content is far cheaper.
3. If my rented movie didn't work, I could take it bck to the store. If my DRM content doesn't work, it's probably because I violated the DMCA.
They might get away with that for the immediate future, but ultimately if serious amounts of DRM'd content doesn't do what it was advertised to do, someone's going to get shafted for false advertising and all the DMCAs in the world won't help them in the aftermath.
So, why not invoke the DMCA? This is a copyrighted work being republished without consent.
Because we're in the UK, and the effort involved would be prohibitive. However, my point wasn't that they couldn't sue to get the information removed if they really wanted to. My point was that once the illegal duplication had occurred, the damage was done, and a large amount of inconvenience was inevitably going to result. Whether that inconvenience arises through taking legal action to get the illegal copies removed from the archives or simply through the more mundane act of going through several hours of tedious discussion with the publisher's lawyers, it's now actively unpleasant for these guys to publish advance copy on the web, so they aren't. No-one won here.
Ergo, if we are to view this mark-up as unethical, we ought not be constrained by what IS "legal". Instead, we should be discussing what OUGHT to be legal.
In that case, you'll be wanting my other post instead.:-)
What we need is precedent that holds people harmless for cracking this stuff in order to exercise their legal rights.
I'd suggest that first there needs to be clarification of what people's legal rights really are. At present, there are a lot of exemptions to copyright law such as the US "fair use" provisions, but most of these only say that you're not guilty of copyright infringement if you make a copy. They don't guarantee you any right to make such a copy, nor require the individual or organisation supplying you with copyrighted material not to inhibit your making of such a copy.
Now, in the days when making a copy was easy for anyone (pretty much anything pre-DRM relative to today's popular media types) that distinction didn't really matter, because it never stopped someone from making a copy legally under the fair use provisions. However, today's DRM is seeking to inhibit making those copies, and further (courtesy of the DMCA, EUCD, and other similar legislation) to prevent the consumer circumventing those inhibitions, effectively blocking that consumer from fair use by the back door. This imbalances the system.
IMHO, before any sort of legal weight (or further legal weight) is given to DRM technologies, there should first be a moratorium to consider what rights (and I mean that this time) consumers should have, which the content supplier may not lawfully prevent them exercising. The right to make a usable back-up copy of any media I purchase such that if I have to replace any hardware I can still access the content in the same way as before might be a sensible starting point. The right to transfer the data to a different media format, but still for personal use by the same individual, might be another reasonable thing to secure in law.
OK, stay with me now...:-)
As soon as we start down that path, it's going to become really obvious that copying for some purposes is reasonable, while for other purposes it defeats the principle of copyright, and it will be very hard for any purely technological solution to distinguish between the two. The closest idea I've seen so far is the limited numbers scheme, where you buy a copy of something and get "five lives" to make copies for back-ups, transfer, etc. Of course, that's somewhat flawed in itself because the number of copies remaining has to follow the content, but the first duplicate and second duplicate can't know how many times the other has been used. You could milk a total of 15 copies out of this scheme if you really wanted to, but at least it's limited, and (if it could ever be done reliably) would prevent mass illegal distribution a la P2P. This seems pretty close to what current approaches to DRM are aiming for.
Of course, if my hard drive really does crash 20 times, I should still have the right to play my content. This is where the current imbalance comes in: there was a post here in one of the recent threads on this subject where someone said after malware took out their system, iTMS support wouldn't give them a means to access the content they'd paid for again. With suitable consumer rights (not copyright exemptions) codified in law, this would be illegal, and it would be incumbent on any organisation producing content in a DRM'd form to provide a free (or at least not-for-profit) and easy-to-use means for consumers to regain access to their content if whatever DRM scheme was in place failed to honour the consumer's legal rights. It would probably also be necessary to place an open copy of the content in escrow somewhere to guarantee that the rights were never unfairly restricted if the supplier folded and took their reactivation scheme with them.
At that point, we'd have a workable system where honest consumers weren't screwed by having to repurchase the same content in new media formats and so on, yet suppliers could still make a fair amount of money (i.e., what the market was prepared to pay) from their content without fear of widespread
Oh noes, we'll have to keep the status quo of actually being able to purchase a DVD or a CD, and be able to do what we want with them.
DRM wasn't actually stopping anyone doing that anyway. The media industry makes far more money off a CD/DVD sale than an electronic download at a fraction of the cost, so it's unlikely they're going to give up selling them any time soon.
However, for many people it's now easier and cheaper to use a legal download service and burn their own CD than to go out and buy a ready-made one. Why are so many people here so determined to undermine a system that benefits a lot of consumers? No-one's forcing anyone to use it, nor likely to any time soon (see above).
Or how about DRM allows video producers to have a video be playable only from their web site and for a certain amount of time before it expires?
But I don't want that! I want to be able to download and save video I view on the net.
I hesitate to post a counter-opinion, since doing so on these threads seems to be worth about (-2, I Disagree So You're A Troll), but what the hell.;-)
What if the alternative is not being able to download legally at all? I don't know whether it's officially acknowledged or not, but it's a good bet that legit services like Napster's or Apple's are only allowed to distribute the content by the recording industry after agreeing to apply DRM technology to it. If they gave up, or the DRM proved to be ineffective, there probably wouldn't be any legal download services at all. At that stage, some people reading this may be quite happy to break the law and risk becoming a statistic/example case so they could still download music, but a lot of people would lose out through being unwilling to commit a crime.
Not everything in this world comes down to absolute ownership. The rental model has been working well for videotapes for years: if you just want to watch a film once, but don't want to keep the tape, you can pay a smaller amount but you have to give it back a couple of days later. Most of the arguments in posts like the parent would basically rule out such a model, despite the fact that it is welcomed by many and of benefit to them.
I have archives of several pages that I wouldn't be able to see anymore if I hadn't been able to save.
And I know two people, completely independently, who had trouble securing book publishing deals after draft content that they put on their web site temporarily for the benefit of those who were interested wound up republished (without their consent, or even notifying them) on so-called archive sites that have decided they are above copyright law (which I suspect may become an expensive mistake the first time they try this with a megacorp).
Neither of these people publishes anything whatsoever on the web any more, because the resulting tedious negotiations with their publisher's lawyers over distribution rights just aren't worth it. Ultimately, it's not the authors who have lost out here, it's the people who were benefitting from having their content at a much cheaper rate. That was the very distribution of work that copyright and similar concepts are intended to promote, and when copyright wasn't respected, it stopped. Go figure...
Slashdot Mirror
You're debating which language is better based on whether a one-liner takes 9 lines or 12 to code?! If it were that easy, we'd all go back to writing in BASIC.
The problem is that actually, it hasn't, although it surely should have been a long, long time ago. Alas, the bulk of the software development industry is so driven by marketing hype and buzzwords that it has collectively failed to develop a new language that is a serious choice as a general purpose programming language spanning many problem domains.
A lot of newer languages imitate C++'s approach in terms of design tools, most obviously Java, C# and now Visual basic.Net. However, the beauty is only skin-deep; these languages often lack the solid, underlying framework and reasoned design decisions that have gone into C++, with the result that most of the time they are lucky to be as good, never mind an improvement. The addition of generics to Java several years later is an obvious demonstration of what happens when you go for buzzwords and you meet someone who went for solid design principles.
Many other languages have something valuable to offer developers, but then go and spoil it in some other way, ultimately winding up with something that might fit certain niches, but isn't suitable for major development projects across a wide range of areas. Some common examples come immediately to mind:
Java Pro: emphasises safety, readability, and portability; con: sacrifices low-level control (and with it performance) and only supports a limited number of programming techniques, encouraging over-engineered, component-based designs Perl Pro: quick, flexible, useful for rapid development of useful tools; con: terrible scalability and unfriendly (to both programmers and tools) syntax restrict it almost exclusively to quick-and-dirty projects Haskell Pro: elegant and powerful syntax, serious support for powerful programming tools like higher-order functions; con: overly academic community, and puts purity above pragmatism, making it hard to use in real-world projects where things like UIs are involvedThe list goes on, but the important point is that while each of these has good applications, they all have obvious flaws as well. Java is the closest to a serious general purpose language, but even today most of the serious Java code is restricted to server-side back-ends driving databases or some thinly disguised variant on that theme.
C++, for all its sins, remains a pragmatic, balanced choice for a general purpose language that can be effectively adapted to a diverse range of applications. Is it a perfect language? Of course not. It has gaping flaws in any number of areas. The problem is that no-one has yet produced an alternative that beats it on all of them without significant compensating weaknesses.
There was always going to be a big test of the free software ideal in the business world sooner or later. After all, despite what some evangelists may choose to believe, it's clear that most of the major development work on most of the big FOSS projects is still done by a relatively small group of people working for a relatively small number of sympathetic companies. Most of the funding comes from elsewhere in those companies, and they support the free software development for commercial/economic/PR reasons.
The catch is that often, those reasons don't seem to be well-understood or fully thought through. While it's not free-as-in-speech software, Sun's continued support of Java is an excellent example of this. These are still businesses looking to make a profit, so if they don't see a return on their investment, they are inevitably going to kill the project (or stand by it and lose money, which is not sustainable).
So, at the risk of committing Slashdot Heresy(TM)... If Novell do fail because they couldn't support a business model based around Linux, would the precedent really be "dangerous", or simply realistic? It's funny how when we're talking about things like the **AA losing out to P2P, there's little sympathy for a "doomed business model", yet when we're talking about a company trying to sell free-as-in-beer software and (perhaps unsurprisingly?) not making much profit, the spin tends to be rather different.
I was going to raise the accessibility issue, but you beat me to it.
One of the problems with using images for text is that it makes it very difficult to render properly in a non-visual browser. Even with alt tags, you don't have the usual accessibility-friendly CSS to indicate whether things should be read normally, spelt out (as for abbreviations), etc.
It would be nice if a future (X)HTML standard could provide a slightly more general "accessible alternative" for non-text data, be it images or embedded content like Flash. At least then those who are visually impaired would have a fighting chance of understanding the content. In the meantime, I'll take an approach that at least degrades gracefully because the text is in there somewhere.
If I configure a proxy to prevent downloading of image files, I can block most of the ads on the web, yet some pages do not display as the designer intended. Is that their fault for using images, or mine for deliberately blocking content that might be legit?
I'm not sure my customer will understand that, as I explain to them why we've just lost their whole day's data when our software crashed...
Not at all. What if there is more going on in the system than just the thread that called the abortive library function? It might only be appropriate to terminate that one thread. Even then, you might want to do so after attempting to preserve as much user data as possible so that the situation can be salvaged later on, and aborting instantly denies you any chance to implement such defensive programming techniques.
As I've said elsewhere, that's not the library code's decision! If you can show me a compelling argument that it should be anywhere in this thread, please do, because I certainly haven't seen one. As I've noted before, forcing this kind of draconian response violates the basic principles of modularity and encapsulation that underpin any strong design.
I'd argue that trying some recovery action is very common today, and moreover that your perspective of exceptions as a design tool is overly narrow. The motivation for exceptions is to separate identifying an exceptional condition from dealing with it. Where libraries are concerned, that separation of responsibilities can provide the calling code with the opportunity to take recovery action if it wants to. If not, it can always let the exception propagate unhandled (which will abort a C++ program by default anyway) but at least it gets the choice.
Perhaps a decade ago, but not today. In all that time, I have neither seen a real world project, nor talked to a real world programmer, that suggested this was acceptable practice.
Blockquoth the AC:
Well, assert is indeed standard, but the principle is much more general, and I've never yet worked on a production project that actually used the standard macro rather than a customised version.
That's not a more accurate statement, it's simply a different one.
Perhaps, but if I'm the application developer and you're the library developer, then that's my decision, not yours.
I might have all kinds of clever diagnostic code running in my application, direct comms with the debugger, other activity going on in different threads, acquired resources, or 101 other reasons that I don't want to kill my application dead, even if your library encounters a serious problem. By all means tell me about the problem, and then if I want to, I can dead-end everything to make it obvious while I'm testing. But don't tell the rest of my application, about which your library has no knowledge, how it should handle an error in one part of the program. That is the worst sort of catastrophic failure, and violates every principle of modularity and encapsulation in the book.
Well, nothing, I suppose, but why would you ever want to use the one that kills your app when some internal test fails?
It doesn't help you, the library user, to determine what the problem was, other than possibly which API call actually blew up. Whether the data you gave to that one was the cause of the explosion is a different question, of course.
If you're talking about NDEBUG, presumably we're in the world of C and/or C++ here. In that case, surely it would be much better for libraries to at least return a proper error code if something goes seriously wrong, or (for C++ libraries) to throw an exception, a tool practically tailor-made for this situation?
For one-off assertions at strategic points in your code, sure. The potential problems start when you have a "one-off" assertion that's tested inside nested loops and the like. As with so many performance issues, it's not what you do, it's where (and how often) you do it...
Perhaps, but no library code should ever cause the whole application to abort, ever. There are few absolutes in software development, but this is one of them.
The library code is entitled to screw up whatever internal data it likes, and to give me whatever garbage out if I put garbage in, but it is not allowed to screw the rest of my program (and thus to circumvent any graceful-shutdown error-handling system I have in place there).
More seriously, assertions that can be disabled can potentially hide little errors altogether. Consider what happens if evaluating the condition for your assertion has side effects, but in release builds that condition is never evaluated. Oh, dear: now you can test quite happily on your diagnostic build, but the one you ship to your customer has an extra bug. :-(
That is indeed common practice, and the traditional use of assertions. Whether it's the best practice is a different question.
In recent years, there has been a general acknowledgement within the software development community, and indeed among end users, that bugs happen. It's simply the nature of the beast. In most fields (excluding those where bugs simply aren't allowed, ever, and vastly higher investment is made in quality control) what's more important is that the application handles the situation gracefully when a bug does occur, and that when a bug is found, it is swiftly and effectively fixed.
Now, obviously you don't normally want your end users seeing the intimate details of your code, but the idea of having run-time sanity checks for internal errors even in release code isn't absurd by any means. After all, as an end-user, wouldn't you far rather your e-mail client noticed early that something wasn't quite right and shut down relatively cleanly, potentially allowing you to back up your data and/or obtain a tool to recover it before the problem went too far? The alternative -- continuing as if nothing's wrong, but based on some bad data -- could easily lead to more serious corruption and permanent data loss, with a bug report only getting filed when it's too late to do anything about it.
Of course, using assertions heavily can incur a significant performance hit, which may or may not be acceptable in your particular application. However, I would argue that the basic idea of assertions is just as valid in production code, and perhaps it's better to leave at least a key subset of assertions in your finished product, with handlers that shut down cleanly and ask the user to pass on certain key information to the developers in order to fix the bug.
I can't remember which is greater, the number of available IPv6 addresses or the estimated total number of atoms in the universe, but either way you can rest assured that there will be more than enough IPv6 addresses to handle any foreseeable addressing needs we're going to have any time soon, even if everyone winds up with dozens of personal IP-assigned devices.
From part-way down TFA:
Interesting for many here that the new guy at the head of the IETF seems to give this issue such emphasis.
Sure, but suppose this case did go the wrong way for P2P. We can probably assume that shortly after the SCOTUS "vindicated" the media industry position, we'd see H.R. 666, a.k.a. the Piracy To Piracy Solicits Users' Extreme Zero Royalties Zero Payments Acts or P2P Sux0rz Pact for short.
Seriously, I'm pretty sure P2P use in the US would die out real fast if all ISPs were required by law to disclose the name and address of any users whose computers are involved in sending or receiving data on some arbitrary set of ports, to be specified and updated by some government agency without further changes in the law. (Notice that if they managed to get that open-ended concept into the law, on the no unreasonable basis that P2P would just switch to use another port otherwise, then there would be serious implications for any use of the Internet.) Couple that with, say, an automatic $10k fine or 6 month prison sentence for anyone convicted, and it would just be too risky for most people to bother, and without the volume of users P2P is dead.
It would be a very bad day for a promising range of new technologies if something like this happened, which is why it's so important to separate the technology from the acts of the user in law. The argument is just as valid here as it is when you protect car makers, knife makers, etc.
Strangely, the media industry actually did seem to have come around to doing this until this case, going after those who were clearly distributing copyright material illegally. I would have thought bringing this case, which apparently could give permanent legal support to P2P networks that might be used as a defence in lesser cases in future, was a big risk. Then again, IANAL and neither do I know which big names the industry does and doesn't directly influence over in the US.
At the risk of going all serious, to a degree I actually disagree with this, and the conclusions of TFA.
I used to spend a lot of time helping out on a couple of technical newsgroups for newbies to programming, web design, etc. They were small communities, but very helpful to those who found and took advantage of them. However, those who contributed their advice obviously had limited time to volunteer. While most posts did get an answer from someone, those that were clearly written were far more likely to receive a detailed response.
By the nature of the groups, we attracted quite a few of the IM/txt msg generation. Some of their habits (dropping all the capital letters, for example) were simply annoying, and most posters did actually start writing in reasonable English when a polite request was made pointing out that this made responding more pleasant for those who would like to help. However, sometimes the poster was so caught up in their own L337sp33k that we simply couldn't understand what was being asked. In a discussion about a technical subject, often filled with jargon with precise meanings and code snippets that obviously have to be written exactly correctly, using random abbreviations because you can't be bothered to type an extra couple of letters and then expecting someone who's volunteering their time to spend even longer trying to figure out what you meant isn't a great way to encourage helpful replies!
YHBT. HTH. HAND.
FWIW, I can see the same pop-up in Firefox 1.0.2, but it's nothing the Adblock extension can't handle.
Well, OK, but my point wasn't to equate the two, merely to demonstrate that there can be useful and successful business models that do not involve any permanent transfer of content ownership.
Sorry, but I just don't get that. Buying a CD single from my local record store costs me about £4. Buying that same single from an on-line vendor costs me less than one pound. Unless you're claiming the CD cover art is worth the difference, the DRM'd but downloadable content is far cheaper.
They might get away with that for the immediate future, but ultimately if serious amounts of DRM'd content doesn't do what it was advertised to do, someone's going to get shafted for false advertising and all the DMCAs in the world won't help them in the aftermath.
Because we're in the UK, and the effort involved would be prohibitive. However, my point wasn't that they couldn't sue to get the information removed if they really wanted to. My point was that once the illegal duplication had occurred, the damage was done, and a large amount of inconvenience was inevitably going to result. Whether that inconvenience arises through taking legal action to get the illegal copies removed from the archives or simply through the more mundane act of going through several hours of tedious discussion with the publisher's lawyers, it's now actively unpleasant for these guys to publish advance copy on the web, so they aren't. No-one won here.
In that case, you'll be wanting my other post instead. :-)
I'd suggest that first there needs to be clarification of what people's legal rights really are. At present, there are a lot of exemptions to copyright law such as the US "fair use" provisions, but most of these only say that you're not guilty of copyright infringement if you make a copy. They don't guarantee you any right to make such a copy, nor require the individual or organisation supplying you with copyrighted material not to inhibit your making of such a copy.
Now, in the days when making a copy was easy for anyone (pretty much anything pre-DRM relative to today's popular media types) that distinction didn't really matter, because it never stopped someone from making a copy legally under the fair use provisions. However, today's DRM is seeking to inhibit making those copies, and further (courtesy of the DMCA, EUCD, and other similar legislation) to prevent the consumer circumventing those inhibitions, effectively blocking that consumer from fair use by the back door. This imbalances the system.
IMHO, before any sort of legal weight (or further legal weight) is given to DRM technologies, there should first be a moratorium to consider what rights (and I mean that this time) consumers should have, which the content supplier may not lawfully prevent them exercising. The right to make a usable back-up copy of any media I purchase such that if I have to replace any hardware I can still access the content in the same way as before might be a sensible starting point. The right to transfer the data to a different media format, but still for personal use by the same individual, might be another reasonable thing to secure in law.
OK, stay with me now... :-)
As soon as we start down that path, it's going to become really obvious that copying for some purposes is reasonable, while for other purposes it defeats the principle of copyright, and it will be very hard for any purely technological solution to distinguish between the two. The closest idea I've seen so far is the limited numbers scheme, where you buy a copy of something and get "five lives" to make copies for back-ups, transfer, etc. Of course, that's somewhat flawed in itself because the number of copies remaining has to follow the content, but the first duplicate and second duplicate can't know how many times the other has been used. You could milk a total of 15 copies out of this scheme if you really wanted to, but at least it's limited, and (if it could ever be done reliably) would prevent mass illegal distribution a la P2P. This seems pretty close to what current approaches to DRM are aiming for.
Of course, if my hard drive really does crash 20 times, I should still have the right to play my content. This is where the current imbalance comes in: there was a post here in one of the recent threads on this subject where someone said after malware took out their system, iTMS support wouldn't give them a means to access the content they'd paid for again. With suitable consumer rights (not copyright exemptions) codified in law, this would be illegal, and it would be incumbent on any organisation producing content in a DRM'd form to provide a free (or at least not-for-profit) and easy-to-use means for consumers to regain access to their content if whatever DRM scheme was in place failed to honour the consumer's legal rights. It would probably also be necessary to place an open copy of the content in escrow somewhere to guarantee that the rights were never unfairly restricted if the supplier folded and took their reactivation scheme with them.
At that point, we'd have a workable system where honest consumers weren't screwed by having to repurchase the same content in new media formats and so on, yet suppliers could still make a fair amount of money (i.e., what the market was prepared to pay) from their content without fear of widespread
Blockquoth the AC:
DRM wasn't actually stopping anyone doing that anyway. The media industry makes far more money off a CD/DVD sale than an electronic download at a fraction of the cost, so it's unlikely they're going to give up selling them any time soon.
However, for many people it's now easier and cheaper to use a legal download service and burn their own CD than to go out and buy a ready-made one. Why are so many people here so determined to undermine a system that benefits a lot of consumers? No-one's forcing anyone to use it, nor likely to any time soon (see above).
I hesitate to post a counter-opinion, since doing so on these threads seems to be worth about (-2, I Disagree So You're A Troll), but what the hell. ;-)
What if the alternative is not being able to download legally at all? I don't know whether it's officially acknowledged or not, but it's a good bet that legit services like Napster's or Apple's are only allowed to distribute the content by the recording industry after agreeing to apply DRM technology to it. If they gave up, or the DRM proved to be ineffective, there probably wouldn't be any legal download services at all. At that stage, some people reading this may be quite happy to break the law and risk becoming a statistic/example case so they could still download music, but a lot of people would lose out through being unwilling to commit a crime.
Not everything in this world comes down to absolute ownership. The rental model has been working well for videotapes for years: if you just want to watch a film once, but don't want to keep the tape, you can pay a smaller amount but you have to give it back a couple of days later. Most of the arguments in posts like the parent would basically rule out such a model, despite the fact that it is welcomed by many and of benefit to them.
And I know two people, completely independently, who had trouble securing book publishing deals after draft content that they put on their web site temporarily for the benefit of those who were interested wound up republished (without their consent, or even notifying them) on so-called archive sites that have decided they are above copyright law (which I suspect may become an expensive mistake the first time they try this with a megacorp).
Neither of these people publishes anything whatsoever on the web any more, because the resulting tedious negotiations with their publisher's lawyers over distribution rights just aren't worth it. Ultimately, it's not the authors who have lost out here, it's the people who were benefitting from having their content at a much cheaper rate. That was the very distribution of work that copyright and similar concepts are intended to promote, and when copyright wasn't respected, it stopped. Go figure...