If this is anything like what Microsoft just did with Visual C++ 2005, where using perfectly good standard library functions results in a wave of warning messages that they are deprecated (by Microsoft, not the standard, mind) and you should use the "safe" versions instead (which only work on the MS compiler, of course) then thanks, but I'll take backward compatibility for 100.
I know you can, if you read enough, identify the appropriate #define voodoo to set in all your projects and shut this lot up, but having just done it on even a single, moderately-sized project, it's just wasted effort I shouldn't have had to expend.
The verbosity of C++ code is nice because you can read it out loud and understand what it's doing. Lambda expressions might be easy to read if your idea of a good time is solving graph theory problems, but otherwise they really aren't clear.
So let me get this straight: an in-place function definition isn't clear unless you like graph theory; but a structure pretending to be a function that takes two pointers to unmodifiable hieroglyphics and promises not to change the data members it doesn't have as it calls another function that belongs to another class or namespace and tests whether the answer is negative is nice because (if and only if you know what all the syntax means) you can read it out loud and understand what it's doing?
Assuming of course that I want to put a lot of complex data into my code rather than load it from XML or a database
Damn, and we used to just use a plain old text file. Why does everything have to be XEverything these days?
XML is a not-particularly-good implementation of a not-particularly-clever idea, whose sole benefit in most cases is that there are libraries to parse it for you. Then again, if your programming language is even slightly good at text processing, you can do enough reading and parsing to handle most configuration files in a line or two of code anyway, and the rest is just overhead.
Or you could just hard-code data that's not really likely to change anyway, and have a much faster, more maintainable program than the guy who wrote more lines to process his XML than there were in the file he was processing. I'm just sayin', y'know, it's a thought.
I doubt the odd name will be much of a problem. After all, C9x hasn't appeared on any requirements lists I've seen so far, and it's been C99 for 6+ years now.
I do find it entertaining when random HR staff ask me how much experience I've got programming with pearls, though.
As long as your library's entry points are not mangled, and use a standard calling convention it makes no odds what language it is implemented in on the other side.
Ah, if only that were true. Suppose you're writing a library in C++, and will be advertising a C-compatible interface (i.e., C calling convention, no name mangling, only POD types used in the interface, etc.). Now consider the effect of using any sort of static object of a type with a non-trivial destructor within your C++ code, even if it's never referenced by the interface.
It's certainly not completely straightforward to write a C++ library that can be called from an arbitrary second language using the C calling convention. However, it certainly can be done, and we do it all the time at work despite the fiftywhatever issues someone else seems to have with it. Maybe we just thought that writing a function called "and" might be a bad idea even before C++ came along.;-)
I'm not sure I follow your criticism of C++ over bugs at compilation time. A compiled C++ program will reveal certain classes of error at compile-time, but you can and should still use assertions, exceptions, and so on to guard against logic errors at run-time.
Sure, you can't 100% guarantee that no-one's code will ever dereference a null pointer or divide by zero, but I don't see that much advantage to having some unexpected "logic error" exception generated in a program running on a virtual machine either. If you thought to catch such an exception at a meaningul level and take some useful recovery action on a virtual machine, couldn't you have asserted that the invalid data shouldn't be there on the way into the module and handled it much the same way in C++, at least the vast majority of the time?
And of course, on several major platforms, you can configure handlers for such fatal errors when the OS detects them, or even treat them as exceptions within C++ exactly as you would under a VM, although sadly this isn't standardised, nor supported on all platforms.
Stringstreams don't overload any operators that I/O streams don't.
But they suffer from the same fundamental architectural flaw in both cases: they force you to write what should be data (the order and formatting of substituted elements in a string) as code. C did better with printf a generation ago, and almost every other half-decent text-processing language I can think of uses some sort of template string and then substitutes, with the template string encoding the order of elements and, often, any formatting requirements. This sort of thing is of vital importance when you're working on internationalised applications, but for some reason I've never understood, C++'s I/O streams and locale support don't seem to have noticed.
In a sense, this example demonstrates both the best and the worst aspect of C++'s approach to libraries: what it has as standard seems to be some sort of designed-by-committee mess that's unusable in a professional environment, but on the other hand professionals are always free to completely disregard it without cost, and to write or bring in an alternative text processing library instead.
To me, D has surfaced to become what I always thought C++ should have been.
Diffr'nt strokes and all that; to me, the design of D is practically a bullet point list of ways to undo the things that Stroustrup and co. understood and got right but Java and friends got wrong. The design gives up most of the flexibility and power, in exchange for what? A garbage collector and, in Java's case, an extensive library (most of which isn't very good)?
If you want a higher-level language with a different balance of power vs. safety, there are many much better choices than things like D. On the other hand, if you want the power and you're smart enough to take advantage of the lower-level features in something like D, you're probably smart enough not to make rookie mistakes in C++ and to use the extra tools it offers effectively. I just don't see the target audience for the middle-ground languages. Java was born of hype, C# was born of exasperation with Java, and D was still-born, as you say yourself:
It might not be ready for full production yet (due to lack of big supporters and libraries, mostly)
Well, if D is to become even a shadow of what C++ is already, it's pretty much going to have to overcome these fundamental drawbacks. It's tough; obviously a lot of hard work has gone into it. But as I said, I think it's a product with no market, trapped between the more powerful and much more established C++ on one side and the more flexible and productive "scripting" languges on the other, and squashed under theoretically sounder academic languages with better underlying programming models for good measure. You only have to look at the... not entirely representative... features checklist on the D language site to see where the design came from.
Perhaps there is a reason that, as the D site itself notes, most new languages appearing today are either from the academic community and showcasing more theoretically robust programming techniques, or from the business community and based on quick and effective development?
IMHO that's rather unfair. When Visual C++ 6 was released, the standard hadn't yet been finalised, and the now-incorrect scoping wasn't uncommon. All more recent versions of VC++ have provided the/Zc:forScope option or something similar that allowed the proper scope to be enforced, and aside from VC++ 7 (the 2002 disaster where using the corresponding option actually broke things like MFC, making it effectively useless to many Windows-based developers) it's worked fine.
Fair enough, if you were constrained in what you could use then what you wrote is indeed pretty much textbook stuff. It's just that, given a choice, I doubt any decent C++ programmer would voluntarily use that. The lack of proper lambda/closure/higher order function support in C++ has always been the thing that meant the initially promising STL stuff never lived up to the hype. With the more recent template wizardry -- the sort of stuff the standards people are trying to build on when they talk about improving support for library writers -- we're finally approaching the point where C++ can do at least some of the clever things that appear in chapter 1 of any book on a functional programming language!:-)
Your C++ is riddled with syntax errors, and appears to be using some hideous naming convention that I've never had to use in my whole C++ programming career. That aside, you do know that something like lexicographical string comparison would be done quite straightforwardly with one line of standard library code, right? And that there are lambda-style libraries that let you write something surprisingly close to a functional programming language's real closures when the operation you're trying to do isn't completely routine anyway?
Your comparison may be apples-to-apples, but I think your C++ apples have been rotting for a decade...
I can't understand why so many programmers stick with C++. It's just not a very good language.
That depends on your benchmark. Mine is pragmatism, where it remains unrivalled for many jobs.
And while C++ has many theoretical design flaws that could be improved in a language without the historical baggage, lack of bounds checking on a vector isn't one of them. Just use at() instead of [] if your implementation doesn't do bounds checking already.
If you type x = y * 3; where x is an unsigned integer and y is a float, a "type safe" language would generate a type-mismatch error at compile.
If we're talking about genuine strong typing, then yes, I suppose that's probably required. I would argue that generating predictable and expected behaviour is a more useful standard a lot more often.
I just got gazillion errors from the spanking new compiler, because the scope change to the variables declared inside for loops.
The one required by a standard that was basically finished about 9 years ago, and which has been supported by pretty much every mainstream compiler for at least two or three versions now, you mean?:-)
OK, I think I understand all of that, but in that case, I think my earlier question remains: if the ex parte mechanism is being used only to ask a court's permission to find information via discovery that can then be used to take legally proper action against a named individual who can properly defend themselves against the subsequent action in court, how is this unreasonable? (I assume that in order for the discovery order would only be granted by the court if the RIAA can demonstrate reasonable grounds for needing the information to be discovered, such as that they have other information to bring a full-blown case against that individual once they're identified.) If you can't seek basic and necessary information to bring a proper court case, via lawful discovery under judicial oversight, how on earth are you supposed to get that information and protect your rights under the law?
If the ex parte actions were to result in an individual actually being ruled against without due process where they could defend themselves, that would be a whole different ball game, but from what you've posted and what I've read elsewhere, that doesn't seem to be the case here.
Similarly, I'll be the first person to object to the whole dodgy settlement offer thing that often seems to follow the discovery of the name, but that again is a separate issue.
Please correct me if I'm wrong on either of the above points.
OK, let's try this again. I'm a reasonable guy, and contrary to the conclusion you seem to have leapt to based on reading a post or two I've made, I have an open mind here; I'm no great fan of the business practices of the big media industries, but I also have little sympathy if people flagrantly break the law and then get caught. You seem to be saying pretty clearly that I don't understand the law properly in this area, which isn't surprising, since I'm not a lawyer and I don't live in your area. If you know more than I do, how about trying to write a nice, informative post so I and others can learn something?
Perhaps you could start by reconciling your first two points for me. AIUI, the industry is using ex parte cases effectively to force ISPs to reveal the names of individuals whose computers have been used in potentially illegal copying through the courts. They are then dropping the ex parte cases and suing the individuals named under their own names, at which point the individual knows about the case and can defend themselves. Is this not correct?
If that's the case, then I really don't see how their action up to that point is unreasonable given the framework the US legal system imposes on them. If someone is ripping them off -- and let's not pretend that it's not happening on a wide scale -- then how else would you propose they defend their copyright effectively? If they were following through on the ex parte cases to the point where someone could be paying damages without even knowing they had been sued, that would be an entirely different ethical position, but AFAICS that's not what they've been doing. Perhaps I've missed something? (NB: In this paragraph, I'm referring only to the way the recording industry is actually using ex parte cases, not to any very dubious settlement offers they may make having got the name instead of using a proper court case, and not to the fact that US law might allow them to do more on an ex parte basis that we might agree is unreasonable.)
Next up, perhaps I'm just missing some technicality of US law here, but why isn't the fact that they're able to make a copy of the file of any weight as evidence? If a file is being advertised as available for distribution on a public network, and the copyright holder can show that the content of the file is protected by their copyright and distribution would infringe that copyright, why is this not enough? It seems to me that saying there's no case because the copyright holder's own actions can't infringe their own copyright and they can't prove to the relevant standard that anyone else has ever copied the file is the worst form of defence by legal technicality. Did the person distributing the material know that the person attempting to download it was working for the RIAA, and therefore that the download would not be infringing? Would they have acted any differently had it been someone else making the download?
Perhaps we're simply applying different standards here. You're applying the legal niceties test; that's your job. I'm applying the reasonable man test; I just want to see a fair outcome based on the information available. But if the results of the legal niceties are wildly in opposition to the results of the reasonable expectation, you can't really expect much support from anyone other than your clients, no matter how "absurd" their understand of the law may be.
Apologies if I came across as condescending; no insult was intended. I was just trying to point out that getting good results by using powerful hardware doesn't really tell us much about the quality of the language itself, since those using less powerful languages would inevitably do the same.
While I am not claiming that those doing this work would deliberately choose an inefficient language, other things being equal, we have to consider that other things are not equal here. For distributed work, Java has a lot of built-in functionality that would make development easier, which languages such as C++ or FORTRAN do not. At the very least, it would be necessary to identify or develop a suitable library in C++ just to get started, and if this is for academic research purposes or an industrial proof of concept, rather than really trying to develop a fast-as-possible application, then that would be wasted effort.
Perhaps we'll just have to agree to disagree here, because we're obviously coming at this from entirely different perspectives, and we've drifted some way off the original topic (where I was simply saying that GC is not the be-all and end-all of programming safely, without regard to performance). FWIW, it looks like your CAD example does some fairly simple mechanical modelling and has a few thousand lines of source code. The kind of CAD applications I work with model planes, or cars, or oil rigs, with thousands of constraints between thousands of geometries, complex interactions between parametric surfaces, somewhat realistic modelling of physics, and so on, and they do it all interactively. Lest I give the wrong impression again, this isn't meant as any sort of slight against the modeller you cited; we're just looking at entirely different scales when we talk about a "CAD program", and thus entirely different performance requirements.
I'd still be curious to see the benchmarks you mentioned, though. I think perhaps you repeated the previous link rather than using the one you wanted in your last post? A lot of things are said about the performance of programming languages based entirely on inappropriate consideration of unrepresentative benchmarks, so it would be good if you've found something that provides a more realistic basis for comparison.
I'm not telling you anything on my own authority; these terms have specific meanings in computer science.
Fascinating. I've studied academic CS, and I've heard of thread safety, type safety, exception safety, memory safety and probably others I've forgotten just now. And yet I've never heard anyone refer to a "safe language" as a blanket term, nor seen any formal definition for "safety" without qualifier. I'm guessing you mean memory safety here, but as someone apparently versed in CS, you of all people should be able to see that there are other safety issues to be considered in language design as well. That's all I'm saying here.
There is little point addressing other problems before one addresses runtime safety.
And there are more aspects to runtime safety than memory safety. There is little point discussing the correctness of a program that will never terminate, for example.
As I was saying: GC is necessary for safety.
I never said it wasn't, though your model presupposes the existence of garbage to collect -- not all languages have explicit or manual memory management in the first place -- and "garbage collection" is a rather imprecise term covering a wide range of techniques for ensuring that memory is guaranteed to be released. In any case, you're the person who introduced the term "safety" into the discussion.
The fact that it is not sufficient is so trivial that only someone completely unfamiliar with the subject would find it necessary to point that out.
If it were as trivial as you make out, the world wouldn't be full of evangelists who think GC is some sort of magic solution to all programming's problems.
And please save your ad hominem attacks for someone who doesn't see through them. I do this stuff for a living and spent several years studying it academically too. You'll make a far more convincing case for whatever you're trying to say if you stick to facts and reasoned argument.
But they're not suing someone without any evidence. Firstly, the ex parte step is being used to find out who the legitimate target for legal action would be, not a suit against a specific individual. Secondly, "We have records that a file was transferred using a computer you own, and the name and size of that file suggest that it is a copy of material to which we own the copyright" is not no evidence, it's a pretty damning case, and I imagine most courts would see it that way too. If the owner can show that the file did not, in fact, have content that reflected its name, or that neither the computer owner nor anyone for whose behaviour they are responsible could have caused the transfer, or convince the court that the file details are not sufficient to meet the burden of proof required, then they have a defence.
I set up a feed to the RSS from Slashdot when it was first available. The problem was that so many new articles get posted here, it was immediately a chore to scan all the titles for discussions of interest. I gave up in less than 24 hours, and reverted to scanning the customised home page for new articles and using the message system to check for replies to threads I was interested in. And that was just with one source; try hooking up to the BBC News feed for ten minutes and see if you can keep up!:-)
On the various bulletin board systems I follow, Slashdot being one, I find a good messaging system is invaluable: they tell me what I really want to know immediately but can't see straight off the home page, which is when someone replies to a comment I've made (ideally, with further options to pick up things like replies-to-replies in subthreads I've participated in, or other replies to comments I've replied to as well). They don't add further clutter I don't want. I doubt any simple "dump every new title to an RSS feed" approach will ever rival the power of a moderately good messaging system.
I think it's a shame that you view artists solely as something to be exploited by society by offering meager rewards for maximal gain, but of course you're entitled to your personal opinion. Mine is that a fair society should reward in proportion to benefit, simply because IMHO it's the right (if not the selfish) thing to do, just as giving to a deserving charity is. If an artist only ever produces rubbish, they don't deserve to benefit from it, but if an artist genuinely brings some happiness to millions of people, I have no problem with them gaining a large reward from it. One must remember that society is ultimately composed of individuals; taken in isolation, a benefit to any individual is a benefit to society.
Regarding the transfer of copyright thing, I would like to agree with you that adults should be free to trade away their rights for any price they deem fair. Unfortunately, thousands of years of history shows us how easily such a system can be abused by the already powerful, which is why many legal systems now hold some rights inalienable, from fundamentals like the right to life all the way down to relatively mundane consumer rights.
If an author or a band truly had the freedom to negotiate a fair price for the copyright they give up to their publisher or record label, that would be one thing, but they don't; in order to even get in the door, they pretty much have to give up their copyright to a mere middleman as the admission charge. There is nothing free about this decision.
Without going into great detail, here's my alternative argument in a nutshell:
Copyright itself should remain with the original artist (or his estate) until it expires.
Copyright should last for a fairly limited amount of time only.
For the duration that it does last, the artist should be able to award exclusive distribution rights to a middleman if he wishes.
Those distribution rights must be limited by law to a very short period, perhaps a couple of years, after which time the artist is free to renew the arrangement or seek alternative collaborators to maximise the return on a successful work within the copyright period.
Thus the artist is the true beneficiary of copyright, for as long as it lasts, and then society as a whole benefits thereafter. During the protected period, only middlemen who offer a service of genuine value will succeed for long. The balance of power shifts back to the artist, and to an extent the public, and away from the huge media middlemen who dominate every copyright-based industry today. The artist is truly free to sell off the benefits of their work at what they believe to be a fair price, as you say, yet at the same time they are immune from the kind of bully-boy tactics in widespread use by major distributors today.
Incidentally, I think certain copying should be prohibited effectively forever, for example privacy of communications between individuals never intended for publication, or official secrets necessary for national security. However, this should be done under other, specific laws, not using copyright. This is my suggested approach for material whose distribution would have little benefit to society but potentially be very damaging to some specific party, so that this sort of argument cannot be used to justify extending copyright durations ad infinitum.
Perhaps your problem is that you don't understand what a "safe language" is.
Oh really? And who exactly are you to tell me, or anyone else reading this, what a safe language is? Your argument is a common logical fallacy -- a weak appeal to your own authority -- and nothing more.
My interpretation of the word "safe", and also the definition given by an English dictionary, would be "not in any danger". Your definition conveniently excludes several common dangers to programmers and focuses only on a single, narrow problem, yet if you are to be completely safe, you cannot exclude anything. Any approach that addresses less than that may be safer, as GC may be most of the time, but it certainly isn't safe.
This is my point: some people focus on GC so much that they forget to address other problems. There are languages that do make guarantees about security, use safe parallelised processing implicitly, make programming much easier, and avoid many other classes of programmer error. Claiming that any language that provides GC but does not do these things as well could possibly be "safe" is irrational, and believing that your code is safe because you use such a language is delusional.
Slashdot Mirror
If this is anything like what Microsoft just did with Visual C++ 2005, where using perfectly good standard library functions results in a wave of warning messages that they are deprecated (by Microsoft, not the standard, mind) and you should use the "safe" versions instead (which only work on the MS compiler, of course) then thanks, but I'll take backward compatibility for 100.
I know you can, if you read enough, identify the appropriate #define voodoo to set in all your projects and shut this lot up, but having just done it on even a single, moderately-sized project, it's just wasted effort I shouldn't have had to expend.
And in doing so, violates just about every sane property of every other container type in the language. D'oh! :-)
So let me get this straight: an in-place function definition isn't clear unless you like graph theory; but a structure pretending to be a function that takes two pointers to unmodifiable hieroglyphics and promises not to change the data members it doesn't have as it calls another function that belongs to another class or namespace and tests whether the answer is negative is nice because (if and only if you know what all the syntax means) you can read it out loud and understand what it's doing?
Wow, you must really hate graph theory. :-)
Damn, and we used to just use a plain old text file. Why does everything have to be XEverything these days?
XML is a not-particularly-good implementation of a not-particularly-clever idea, whose sole benefit in most cases is that there are libraries to parse it for you. Then again, if your programming language is even slightly good at text processing, you can do enough reading and parsing to handle most configuration files in a line or two of code anyway, and the rest is just overhead.
Or you could just hard-code data that's not really likely to change anyway, and have a much faster, more maintainable program than the guy who wrote more lines to process his XML than there were in the file he was processing. I'm just sayin', y'know, it's a thought.
Probably the sort of stuff you'd write directly in a hash in Perl, I guess: months => days in month, perhaps.
I doubt the odd name will be much of a problem. After all, C9x hasn't appeared on any requirements lists I've seen so far, and it's been C99 for 6+ years now.
I do find it entertaining when random HR staff ask me how much experience I've got programming with pearls, though.
Ah, if only that were true. Suppose you're writing a library in C++, and will be advertising a C-compatible interface (i.e., C calling convention, no name mangling, only POD types used in the interface, etc.). Now consider the effect of using any sort of static object of a type with a non-trivial destructor within your C++ code, even if it's never referenced by the interface.
It's certainly not completely straightforward to write a C++ library that can be called from an arbitrary second language using the C calling convention. However, it certainly can be done, and we do it all the time at work despite the fiftywhatever issues someone else seems to have with it. Maybe we just thought that writing a function called "and" might be a bad idea even before C++ came along. ;-)
I'm not sure I follow your criticism of C++ over bugs at compilation time. A compiled C++ program will reveal certain classes of error at compile-time, but you can and should still use assertions, exceptions, and so on to guard against logic errors at run-time.
Sure, you can't 100% guarantee that no-one's code will ever dereference a null pointer or divide by zero, but I don't see that much advantage to having some unexpected "logic error" exception generated in a program running on a virtual machine either. If you thought to catch such an exception at a meaningul level and take some useful recovery action on a virtual machine, couldn't you have asserted that the invalid data shouldn't be there on the way into the module and handled it much the same way in C++, at least the vast majority of the time?
And of course, on several major platforms, you can configure handlers for such fatal errors when the OS detects them, or even treat them as exceptions within C++ exactly as you would under a VM, although sadly this isn't standardised, nor supported on all platforms.
But they suffer from the same fundamental architectural flaw in both cases: they force you to write what should be data (the order and formatting of substituted elements in a string) as code. C did better with printf a generation ago, and almost every other half-decent text-processing language I can think of uses some sort of template string and then substitutes, with the template string encoding the order of elements and, often, any formatting requirements. This sort of thing is of vital importance when you're working on internationalised applications, but for some reason I've never understood, C++'s I/O streams and locale support don't seem to have noticed.
In a sense, this example demonstrates both the best and the worst aspect of C++'s approach to libraries: what it has as standard seems to be some sort of designed-by-committee mess that's unusable in a professional environment, but on the other hand professionals are always free to completely disregard it without cost, and to write or bring in an alternative text processing library instead.
Diffr'nt strokes and all that; to me, the design of D is practically a bullet point list of ways to undo the things that Stroustrup and co. understood and got right but Java and friends got wrong. The design gives up most of the flexibility and power, in exchange for what? A garbage collector and, in Java's case, an extensive library (most of which isn't very good)?
If you want a higher-level language with a different balance of power vs. safety, there are many much better choices than things like D. On the other hand, if you want the power and you're smart enough to take advantage of the lower-level features in something like D, you're probably smart enough not to make rookie mistakes in C++ and to use the extra tools it offers effectively. I just don't see the target audience for the middle-ground languages. Java was born of hype, C# was born of exasperation with Java, and D was still-born, as you say yourself:
Well, if D is to become even a shadow of what C++ is already, it's pretty much going to have to overcome these fundamental drawbacks. It's tough; obviously a lot of hard work has gone into it. But as I said, I think it's a product with no market, trapped between the more powerful and much more established C++ on one side and the more flexible and productive "scripting" languges on the other, and squashed under theoretically sounder academic languages with better underlying programming models for good measure. You only have to look at the... not entirely representative... features checklist on the D language site to see where the design came from.
Perhaps there is a reason that, as the D site itself notes, most new languages appearing today are either from the academic community and showcasing more theoretically robust programming techniques, or from the business community and based on quick and effective development?
IMHO that's rather unfair. When Visual C++ 6 was released, the standard hadn't yet been finalised, and the now-incorrect scoping wasn't uncommon. All more recent versions of VC++ have provided the /Zc:forScope option or something similar that allowed the proper scope to be enforced, and aside from VC++ 7 (the 2002 disaster where using the corresponding option actually broke things like MFC, making it effectively useless to many Windows-based developers) it's worked fine.
Fair enough, if you were constrained in what you could use then what you wrote is indeed pretty much textbook stuff. It's just that, given a choice, I doubt any decent C++ programmer would voluntarily use that. The lack of proper lambda/closure/higher order function support in C++ has always been the thing that meant the initially promising STL stuff never lived up to the hype. With the more recent template wizardry -- the sort of stuff the standards people are trying to build on when they talk about improving support for library writers -- we're finally approaching the point where C++ can do at least some of the clever things that appear in chapter 1 of any book on a functional programming language! :-)
Your C++ is riddled with syntax errors, and appears to be using some hideous naming convention that I've never had to use in my whole C++ programming career. That aside, you do know that something like lexicographical string comparison would be done quite straightforwardly with one line of standard library code, right? And that there are lambda-style libraries that let you write something surprisingly close to a functional programming language's real closures when the operation you're trying to do isn't completely routine anyway?
Your comparison may be apples-to-apples, but I think your C++ apples have been rotting for a decade...
That depends on your benchmark. Mine is pragmatism, where it remains unrivalled for many jobs.
And while C++ has many theoretical design flaws that could be improved in a language without the historical baggage, lack of bounds checking on a vector isn't one of them. Just use at() instead of [] if your implementation doesn't do bounds checking already.
If we're talking about genuine strong typing, then yes, I suppose that's probably required. I would argue that generating predictable and expected behaviour is a more useful standard a lot more often.
The one required by a standard that was basically finished about 9 years ago, and which has been supported by pretty much every mainstream compiler for at least two or three versions now, you mean? :-)
Yours,
A stuffy, not-quite-so-old fart
OK, I think I understand all of that, but in that case, I think my earlier question remains: if the ex parte mechanism is being used only to ask a court's permission to find information via discovery that can then be used to take legally proper action against a named individual who can properly defend themselves against the subsequent action in court, how is this unreasonable? (I assume that in order for the discovery order would only be granted by the court if the RIAA can demonstrate reasonable grounds for needing the information to be discovered, such as that they have other information to bring a full-blown case against that individual once they're identified.) If you can't seek basic and necessary information to bring a proper court case, via lawful discovery under judicial oversight, how on earth are you supposed to get that information and protect your rights under the law?
If the ex parte actions were to result in an individual actually being ruled against without due process where they could defend themselves, that would be a whole different ball game, but from what you've posted and what I've read elsewhere, that doesn't seem to be the case here.
Similarly, I'll be the first person to object to the whole dodgy settlement offer thing that often seems to follow the discovery of the name, but that again is a separate issue.
Please correct me if I'm wrong on either of the above points.
Ah, but it's nothing to the satisfaction you'll give me in this moment, as I point out your rather pathetic proofreading skills. :o)
OK, let's try this again. I'm a reasonable guy, and contrary to the conclusion you seem to have leapt to based on reading a post or two I've made, I have an open mind here; I'm no great fan of the business practices of the big media industries, but I also have little sympathy if people flagrantly break the law and then get caught. You seem to be saying pretty clearly that I don't understand the law properly in this area, which isn't surprising, since I'm not a lawyer and I don't live in your area. If you know more than I do, how about trying to write a nice, informative post so I and others can learn something?
Perhaps you could start by reconciling your first two points for me. AIUI, the industry is using ex parte cases effectively to force ISPs to reveal the names of individuals whose computers have been used in potentially illegal copying through the courts. They are then dropping the ex parte cases and suing the individuals named under their own names, at which point the individual knows about the case and can defend themselves. Is this not correct?
If that's the case, then I really don't see how their action up to that point is unreasonable given the framework the US legal system imposes on them. If someone is ripping them off -- and let's not pretend that it's not happening on a wide scale -- then how else would you propose they defend their copyright effectively? If they were following through on the ex parte cases to the point where someone could be paying damages without even knowing they had been sued, that would be an entirely different ethical position, but AFAICS that's not what they've been doing. Perhaps I've missed something? (NB: In this paragraph, I'm referring only to the way the recording industry is actually using ex parte cases, not to any very dubious settlement offers they may make having got the name instead of using a proper court case, and not to the fact that US law might allow them to do more on an ex parte basis that we might agree is unreasonable.)
Next up, perhaps I'm just missing some technicality of US law here, but why isn't the fact that they're able to make a copy of the file of any weight as evidence? If a file is being advertised as available for distribution on a public network, and the copyright holder can show that the content of the file is protected by their copyright and distribution would infringe that copyright, why is this not enough? It seems to me that saying there's no case because the copyright holder's own actions can't infringe their own copyright and they can't prove to the relevant standard that anyone else has ever copied the file is the worst form of defence by legal technicality. Did the person distributing the material know that the person attempting to download it was working for the RIAA, and therefore that the download would not be infringing? Would they have acted any differently had it been someone else making the download?
Perhaps we're simply applying different standards here. You're applying the legal niceties test; that's your job. I'm applying the reasonable man test; I just want to see a fair outcome based on the information available. But if the results of the legal niceties are wildly in opposition to the results of the reasonable expectation, you can't really expect much support from anyone other than your clients, no matter how "absurd" their understand of the law may be.
Apologies if I came across as condescending; no insult was intended. I was just trying to point out that getting good results by using powerful hardware doesn't really tell us much about the quality of the language itself, since those using less powerful languages would inevitably do the same.
While I am not claiming that those doing this work would deliberately choose an inefficient language, other things being equal, we have to consider that other things are not equal here. For distributed work, Java has a lot of built-in functionality that would make development easier, which languages such as C++ or FORTRAN do not. At the very least, it would be necessary to identify or develop a suitable library in C++ just to get started, and if this is for academic research purposes or an industrial proof of concept, rather than really trying to develop a fast-as-possible application, then that would be wasted effort.
Perhaps we'll just have to agree to disagree here, because we're obviously coming at this from entirely different perspectives, and we've drifted some way off the original topic (where I was simply saying that GC is not the be-all and end-all of programming safely, without regard to performance). FWIW, it looks like your CAD example does some fairly simple mechanical modelling and has a few thousand lines of source code. The kind of CAD applications I work with model planes, or cars, or oil rigs, with thousands of constraints between thousands of geometries, complex interactions between parametric surfaces, somewhat realistic modelling of physics, and so on, and they do it all interactively. Lest I give the wrong impression again, this isn't meant as any sort of slight against the modeller you cited; we're just looking at entirely different scales when we talk about a "CAD program", and thus entirely different performance requirements.
I'd still be curious to see the benchmarks you mentioned, though. I think perhaps you repeated the previous link rather than using the one you wanted in your last post? A lot of things are said about the performance of programming languages based entirely on inappropriate consideration of unrepresentative benchmarks, so it would be good if you've found something that provides a more realistic basis for comparison.
Fascinating. I've studied academic CS, and I've heard of thread safety, type safety, exception safety, memory safety and probably others I've forgotten just now. And yet I've never heard anyone refer to a "safe language" as a blanket term, nor seen any formal definition for "safety" without qualifier. I'm guessing you mean memory safety here, but as someone apparently versed in CS, you of all people should be able to see that there are other safety issues to be considered in language design as well. That's all I'm saying here.
And there are more aspects to runtime safety than memory safety. There is little point discussing the correctness of a program that will never terminate, for example.
I never said it wasn't, though your model presupposes the existence of garbage to collect -- not all languages have explicit or manual memory management in the first place -- and "garbage collection" is a rather imprecise term covering a wide range of techniques for ensuring that memory is guaranteed to be released. In any case, you're the person who introduced the term "safety" into the discussion.
If it were as trivial as you make out, the world wouldn't be full of evangelists who think GC is some sort of magic solution to all programming's problems.
And please save your ad hominem attacks for someone who doesn't see through them. I do this stuff for a living and spent several years studying it academically too. You'll make a far more convincing case for whatever you're trying to say if you stick to facts and reasoned argument.
But they're not suing someone without any evidence. Firstly, the ex parte step is being used to find out who the legitimate target for legal action would be, not a suit against a specific individual. Secondly, "We have records that a file was transferred using a computer you own, and the name and size of that file suggest that it is a copy of material to which we own the copyright" is not no evidence, it's a pretty damning case, and I imagine most courts would see it that way too. If the owner can show that the file did not, in fact, have content that reflected its name, or that neither the computer owner nor anyone for whose behaviour they are responsible could have caused the transfer, or convince the court that the file details are not sufficient to meet the burden of proof required, then they have a defence.
I set up a feed to the RSS from Slashdot when it was first available. The problem was that so many new articles get posted here, it was immediately a chore to scan all the titles for discussions of interest. I gave up in less than 24 hours, and reverted to scanning the customised home page for new articles and using the message system to check for replies to threads I was interested in. And that was just with one source; try hooking up to the BBC News feed for ten minutes and see if you can keep up! :-)
On the various bulletin board systems I follow, Slashdot being one, I find a good messaging system is invaluable: they tell me what I really want to know immediately but can't see straight off the home page, which is when someone replies to a comment I've made (ideally, with further options to pick up things like replies-to-replies in subthreads I've participated in, or other replies to comments I've replied to as well). They don't add further clutter I don't want. I doubt any simple "dump every new title to an RSS feed" approach will ever rival the power of a moderately good messaging system.
I think it's a shame that you view artists solely as something to be exploited by society by offering meager rewards for maximal gain, but of course you're entitled to your personal opinion. Mine is that a fair society should reward in proportion to benefit, simply because IMHO it's the right (if not the selfish) thing to do, just as giving to a deserving charity is. If an artist only ever produces rubbish, they don't deserve to benefit from it, but if an artist genuinely brings some happiness to millions of people, I have no problem with them gaining a large reward from it. One must remember that society is ultimately composed of individuals; taken in isolation, a benefit to any individual is a benefit to society.
Regarding the transfer of copyright thing, I would like to agree with you that adults should be free to trade away their rights for any price they deem fair. Unfortunately, thousands of years of history shows us how easily such a system can be abused by the already powerful, which is why many legal systems now hold some rights inalienable, from fundamentals like the right to life all the way down to relatively mundane consumer rights.
If an author or a band truly had the freedom to negotiate a fair price for the copyright they give up to their publisher or record label, that would be one thing, but they don't; in order to even get in the door, they pretty much have to give up their copyright to a mere middleman as the admission charge. There is nothing free about this decision.
Without going into great detail, here's my alternative argument in a nutshell:
Thus the artist is the true beneficiary of copyright, for as long as it lasts, and then society as a whole benefits thereafter. During the protected period, only middlemen who offer a service of genuine value will succeed for long. The balance of power shifts back to the artist, and to an extent the public, and away from the huge media middlemen who dominate every copyright-based industry today. The artist is truly free to sell off the benefits of their work at what they believe to be a fair price, as you say, yet at the same time they are immune from the kind of bully-boy tactics in widespread use by major distributors today.
Incidentally, I think certain copying should be prohibited effectively forever, for example privacy of communications between individuals never intended for publication, or official secrets necessary for national security. However, this should be done under other, specific laws, not using copyright. This is my suggested approach for material whose distribution would have little benefit to society but potentially be very damaging to some specific party, so that this sort of argument cannot be used to justify extending copyright durations ad infinitum.
Oh really? And who exactly are you to tell me, or anyone else reading this, what a safe language is? Your argument is a common logical fallacy -- a weak appeal to your own authority -- and nothing more.
My interpretation of the word "safe", and also the definition given by an English dictionary, would be "not in any danger". Your definition conveniently excludes several common dangers to programmers and focuses only on a single, narrow problem, yet if you are to be completely safe, you cannot exclude anything. Any approach that addresses less than that may be safer, as GC may be most of the time, but it certainly isn't safe.
This is my point: some people focus on GC so much that they forget to address other problems. There are languages that do make guarantees about security, use safe parallelised processing implicitly, make programming much easier, and avoid many other classes of programmer error. Claiming that any language that provides GC but does not do these things as well could possibly be "safe" is irrational, and believing that your code is safe because you use such a language is delusional.