The flipside is, people don't see value in music anymore (gee...I wonder why: Britney, Boy Bands...etc), so they won't pay for it...It's called a free market economy.
Yeah, sure. That's why there are more P2P trades in Britney Spears than all your local indie bands put together.
Really, who are you trying to kid with this sort of argument?
Yes, there may be laws against infringement...etc...but the beauty of the US is that laws can change (just look at Prohibition)...and the People will change what they want...
And, in ten years time when nearly all the music is cheap crap and it's impossible to find any of the good stuff unless you already know the band anyway, they will wonder what went wrong.
This is why IP and Copyright Law is so fascinating...they don't have less property after somebody downloads a song, you have merely infringed on their "right" to control copies of their material.
But you have diminished the value of what they do have. The distributor can make all the copies they like, and you can argue that by copying illegally no-one has taken that away from them, but if they can't sell a single copy because everyone has an illegal version already, their material is worthless.
This is the aspect that many people conveniently choose to overlook when arguing that copyright infringement should not be called theft. No, it doesn't take away anything physical that cannot be replaced, but it does take away the value, and thus the financial compensation that was owed to the legal distributor of the material. In this respect, it is directly analogous to theft, and reasonable to equate the two for many purposes.
By the way, the answer to your implied question about intent to buy is simple. We live in a capitalist society, which uses money as a medium to represent both giving and getting our fair share of things. If you do useful work, you gain money, which you can choose to spend on things you want in return. Illegal copying is taking something without paying the money, which is breaking your side of the bargain, and thus a bad thing. If you don't want the stuff enough to pay for it, you don't take the stuff; that's how it works. People who take something without paying an agreed price are called thieves, hence again the analogy between copyright infringement and theft.
Copyright infringement is not theft. They are different, and file trading should not be considered copyright infringement, it's fair use.
How is wide scale distribution of commercially valuable copyrighted material "fair use"? Please don't tell me you think making an arbitrary number of copies for people you've never met and don't even know is "personal use" or any such crap.
File trading networks are the new radio, and end users don't have to pay to listen to the radio.
No, but the radio station has to pay lots for the rights to play the music on air, typically funded by adverts in between tracks.
We can punish the RIAA ourselves without waiting for a Senate that unamimously passed the DMCA to do it by not buying CDs.
So are you going to encourage people to respect copyright by boycotting P2P as well, or are you just making the RIAA's point for them that there's a whole class of bottom-feeders who just rip stuff illegally over P2P and never do buy even the stuff they think is good legitimately afterwards. Way to go, bullet in the foot for the pro-P2P argument.
Ultimately, while being easy to write does confer a small advantage, being easy to read is much more significant. As the oft-quoted motto reminds us, code is only written once, whereas it's likely to be read many times. A vanishingly small amount of a developer's time is spent typing. Most is spent in design, testing, documenting and such rather than programming, and even of what I'd call programming, only a tiny fraction of the time is spent pressing keys on a keyboard.
New languages may be easy to learn, but they each still take some time to master.
You're right, of course. But there's very little that's so new and different that an experienced programmer couldn't pick up the basics quickly, enough to decide if the tool was more useful to them than what they already knew. If it is, then they can invest more time in really getting to know it.
On the individual level, it's probably worthwhile to make these mistakes. However, it may not have been worthwhile to your company to keep switching languages and making buggy products.
Again, I agree with you, but I don't see why this is a problem. Companies rarely need to keep up with the bleading edge, for the reasons I've given: there's little out there that's so new and improved as to justify investing in learning that rather than improving your abilities with the tools you already use.
I was about to write that it's an evolutionary process rather than a revolutionary one, when I realised that actually, a lot of these new developments really do just go around in circles. I wonder how many more times we have to reinvent LISP, ML, Eiffel or C before we realise that for all their idiosyncracies, languages like these have the goods, and all the C#s and Visual Basics and Pythons in the world are really just popular but ultimately insignificant steps along the way to reaching them?
Taking it a step further, recursive sum types like in SML can be used to define recursive data types like lists and trees, and then pattern match against them. That's so nice compared to the way you'd do it in Java or C++.
Isn't it funny how, eventually, you can usually rely on good concepts to drift down from theoretically strong languages into the practical tools?
Andrei Alexandrescu, known in the C++ world for the miracles he performs with templates in his library code (a subject about which he literally wrote the book), produced an article on what he termed "discriminated unions" for the C/C++ Users Journal a few months back. It made quite an interesting read.
You can actually do quite a lot of the good stuff with C++, but somehow it's always a bit like Microsoft trying to force OO concepts into Visual Basic.Net: the general idea is there, but it never has quite the power or elegance of the original that you'd find in a language that was actually good at it.
Oh, for a language with the flexibility and strengths of C++, but also the sum types, pattern matching, closures and first order functions of ML and the text processing tools from Perl...:-)
Oh, I expect we don't disagree very much at all.:-)
I thought your original point was probably that it was important to keep the required part of the library small. (I've worked in instrument control and embedded markets myself, so I'm all too aware of the limitations there, and their size relative to the desktop PC apps market.) From your second comment, I can see that I got the right idea about your point of view.
Keeping the optional libraries separate from the core is exactly what I would want to see, hence the suggestion of a limited "kernel library" to provide bare essentials and a framework for more, while delegating more extensive functionality to some sort of centralised repository where you can find it if you need it. This approach has worked spectacularly well for a couple of things (Perl and (La)TeX being the first two that came to mind) and strikes me as a much better way forward than the monolithic beast that is Java's standard library.
I take it you've never suffered writing and debugging a complex XSLT set-up on a deadline, then?;-)
Mark-up languages should be used for mark-up. Programming languages should be used for programming. Many people have suggested swapping these over; many more have tried and found it doesn't work.
The language MUST have these things built in: associate arrays, regular expressions, iterators, introspection, "here" documents, both static and dynamicly sized arrays.
Your description (and your example) look as though you like Perl, but find it mildly lacking in a few areas. Am I close?
I think the problem today is that everything seems to be moving on much faster than it actually is.
Quite a few years ago, I learned to program in C and x86 assembler. They were useful at the time, and I learned a lot about structured programming and such while using them.
Several years later, I learned C++, and encountered OO for the first time.
At university, I discovered things like Java and ML. ML was new and interesting, but at the time Java was just underpowered C++ with a heavyweight standard library, and to a large extent it still is. That was when I realised that many "advances" that come along "at breakneck speed" aren't really any different to what you've already got.
For several years at the start of my professional career, I relied on little more than standard C++ and a few very common libraries (MFC, mainly, and some in-house things). I didn't need any more.
After a while, I got the feeling I was stagnating, and since I wanted to do a few things that weren't convenient with the C++, I went out and learned some more.
In the past couple of years, I've learned to generate HTML with XML/XLT, I've learned to write scripts in Perl, I've learned about server side scripting and CGI, I've learned to use MySQL, and recently I've put it all together and written a pretty solid bulletin board web site for a club I help run. And this was just with a few hours now and then out of curiosity; the day job writing back-end C++ without much whizz still pays the rent.
I guess my point is that three years ago, CGI, MySQL, Perl, XML and all the rest were just buzzwords to me. Everywhere you looked on the Internet, there were millions of pages of tutorials, mostly very bad ones, and people telling you it was the next great thing, radically different to all that's gone before, etc. You know what? I learned the basics of each of these things inside of a day, once I actually sat down, did some real homework to track down a decent tutorial and got on with it. None of this stuff is hard. Just find useful info -- which often still comes on paper, or in the form of docs from the tool provider for high calibre things like Perl, MySQL or Apache, and not from random glitzy web sites and magazines -- and do some reading.
I reckon if you have a general knowledge of programming in procedural, OO and functional styles, a bit of experience with database design and SQL, a bit of web savvy and familiarity with mark-up, and some general knowledge of modern computers, you can learn any of the buzzword technologies in a week, maybe even a day. They're really not very clever at all; the reason they're buzzwords is that stupid people talk them up to make them sound clever.
Keep the faith; if you've got solid basics -- as any old-timer in this industry probably does -- you're never far behind the lead edge if you choose to catch up. The only people who claim everything is advancing at lightspeed all the time are marketroids selling new buzzwords, and impressionable kids too new to the business to know any better. The rest of us can well afford to relax, keep an eye on new developments now and then, and simply learn whatever tools we need to do what we want to do, if and when we need them.
A language with sound underlying models, with simple implementation, which helps me do what I want rather than telling me what I want to do, and which has no dependence on today's buzzwords.
This post has hit the mark exactly. You can't create a good solution until you understand the problem, and different problems require different solutions.
I agree entirely with you (and Brooks) that syntax is just a means to an end. What's important is the underlying models behind that syntax. Today's models -- be they procedural, OO, functional or whatever -- lend themselves pretty well to textual representation. You could perhaps advance things a little with graphical representations, but I suspect the place for that sort of thing is in better development tools, rather than the definition of the language/environment itself.
The interesting question about graphical or new development environments is whether they'll make it practical to use more advanced underlying models that don't lend themselves readily to a textual representation. I've come across examples of this sort of thing at various points in my programming travels -- the concepts of interfaces, polymorphism of various sorts, modularity and access control come to mind as things that are inadequately represented by most of today's textual languages -- but never anything substantial enough to justify a shift to a radically different representation.
I think I understand where you're coming from, and I agree with the principle, although I don't entirely agree with exactly what you've said.
I think the issue of how libraries are handled is crucial to the success of a modern programming language, as numerous success stories and famous failures can testify. Here are a few random thoughts; how do they match up with yours?
Firstly, I agree that it is best to keep a small "kernel" standard library. This library should be very well designed, with as much thought put into it as the language itself. In particular, it must be readily extensible by other libraries without being overcomplicated. If you like, it should provide a framework for doing common programming tasks, without filling in too many specific cases.
However, I don't think it's either easy or desirable to separate libraries completely from the language itself (as in syntax, grammar, etc). Your own comment about C++ is wrong, for example: you cannot ignore the standard library completely, because certain language operations (such as a failed dynamic_cast on a reference type) result in behaviour that needs library support (throwing an exception of a type defined by the standard library).
Now, you could get around that by creating new standard types for such cases, but do they really belong in the formal grammar of the language, alongside normal exception behaviour but distinct from it? The point is, from a programmer's perspective, it doesn't matter whether that exception type is in the library or the language. It should function identically, offer the same interface, exhibit the same behaviour, either way. It shouldn't matter whether my string type is part of the language or part of the library; it should just work.
The same goes, to a lesser degree, for other libraries. Once I've decided to use a library (or part of it), that extra functionality should just be there. I shouldn't have to care where it came from, and the only time I should have to know it's in a library is when I'm identifying the functionality I want to use. The syntax, style and function should be just like any other feature of the pure language and its standard library.
As a final point, while I believe the standard and portable library should be compact and highly flexible, it's obvious that having a widely recognised and comprehensive library of commonly used functionality is advantageous. Look at the success of Java, for example; although many of its standard libraries suck compared to alternatives for other languages, or even replacements available for Java, that doesn't matter to many Java programmers, because they're good enough. OTOH, this results in suboptimal code due to laziness and/or lack of knowledge of alternatives on the part of many Java developers.
The solution to this, IMHO, is to follow the path set by Perl (CPAN), TeX (CTAN), etc. The sponsors of the language -- commercial or community -- should provide a well-known and recognised central repository, into which contributers can add their own offerings. Better yet, adopt a genuine community review process, such as the C++ Boost community has, to force higher standards within the libraries in the repository.
So, in my ideal little world, a language would have a structure such that libraries and language were indistinguishable except where identification is concerned (basically just a matter of how to specify which libraries are desired, and naming conventions to prevent clashes between them). The language should come with a standard library that provides really common features (basic math functions and string handling, for example) in flexible frameworks on which other libraries can build. The bulk of library functionality shouldn't be standard -- that's too invasive and too limiting -- but ideally should be collected in a central repository of peer-reviewed offerings, with simple, standard and widely known conventions for using those libraries in programs. This way, no-one uses substandard code by default, but you still have the comprehensive functionality base there when you want it.
Copyrights in the database are quite separate from copyrights in the content of the database.
Exactly my point; whatever rights Google may have relating to the former Deja database, are independent of my rights over my own work.
However Courts have to take a wide view of the implied license granted by people who post information on Usenet (and indeed the internet) or else they would be making a wide variety of internet use unlawful.
I don't see how that necessarily follows...
Implied licenses tend to be simple: I've never heard of a court recognising an implied license as complicated/sophisticated as you suggest.
I've never heard of a court either recognising or disputing practices such as Internet archiving yet, either.:-)
But seriously, while there's an argument in favour of simplicity, I don't see how "We want it to be simple!" could or should translate into "By posting on Usenet I give up most/all useful rights relating to copyright of this material". Even if you decide that archiving is reasonable because I posted the material freely in the first place -- which you might do on public interest grounds, given certain caveats about people being able to prohibit this for their posts in a sensible way -- I don't see how I've granted any implicit rights for commercial use of my post. Then again, maybe you can argue that any non-free ISP providing Usenet access is making commercial use of my posts. Then again again, I'd argue that Usenet itself is essentially non-commercial, and the ISP is charging for the connection to Usenet.
You could have a fair and reasonable debate about what the implied permissions granted by posting to Usenet should be, in the best interests of both the public interest and the rights of the original poster, but this seems to be avoided at present, until someone feels aggrieved enough to take up the challenge. Unfortunately, in the meantime, people like me are having our material used by others for commercial gain, and while that is somewhat offensive, it's not worth our while to do anything about it.
I realise that what you say is currently the case, but I'm not sure it's a good idea to limit investigations as a result. After all, if you apply for a patent and it's turned down, chances are the confidentiality wasn't protecting much anyway.
A better system would be one where the amount of time granted for exclusive ownership of the idea is based on how much developement goes on in that area.
I'm not sure it's quite as simple as that -- probably the effort required to implement the invention would also be relevant, for example -- but I think the idea of granting varying degrees of exclusivity has a lot of merit.
What if, as in certain country around the world, you simply had no patents?
I question, quite sincerely, how many of those countries develop significant numbers of new inventions compared to countries that have parents. My (limited) experience is that most of the new tools, technologies and similar developments in such countries are copied from essentially the same things in other patent-offering countries, where the original research to develop them was done.
US Patent laws are unbelievably biased in favor of patent-owners, and give them a monopoly to charge above what the market would otherwise afford.
That, however, is a problem with the implementation of patents in the US, and not with the principle of patents per se.
As far as I'm aware, no other country in the world suffers anything like the same problems with patents at the US does. Having worked in industries where patents are relevant and genuine R&D does result in genuine new developments, I think the system works very well and does exactly what it's supposed to, as long as the patents granted are sensible and the provision for enforcing them is reasonable to both sides.
It seems that most of the genuine objections I've seen to USPTO-granted patents fall into fairly precise categories:
the patent really is obvious to anyone knowledgeable in the field, or
the patent blatantly represents widely known prior art, or
the patent is written in waffly terms, such that
no-one else could reproduce the implementation it's supposed to describe, so it benefits no-one but the claiming party, and
it can be used as a commercial weapon, by interpreting it favourably when enforcing it against competitive rivals.
In each of these cases, the problem is the same: granting the patent is a one-sided benefit, good for the claiming party but never offering anything in return to the rest of the field.
Now, there is always going to be the risk, with any patent, of hard-to-find but genuine prior art coming to light after the patent has been granted. No-one knows everything in their field, even an expert, so you can never make this problem disappear completely. Logically, therefore, it must be incumbent on the party claiming the patent to do their homework, and accept that the patent will be struck down at some later stage if they don't do it well enough. It must also be practical for anyone with a legitimate claim to overturn a granted patent on this basis: not just big corps against smaller outfits, but also the other way around.
However, unavoidable problems aside, at least getting in specialist help in the manner suggested before granting a new patent would ensure that the gross errors that occur frequently at present would be prevented, which is a big step forward relative to status quo, IMHO.
Essentially, I believe people should have a right to take action against anyone who has used their posts in a way other than they might reasonably have expected when they posted them to Usenet. They have not consented to them being used in any other way.
This is clearly a grey area. Typically posts propagate within a few days, and then remain on servers for 2-4 weeks before they expire. Someone keeping them on a server a bit longer is fine, because there's no explicit standard that says everything expires after max 4 weeks AFAIK.
Someone who's kept them for years, and now offers them in a searchable archive, however, is (IMHO) operating well outside the expectations of normal Usenet practice. Someone who sells a database full of such posts for profit is likewise doing something quite different to what the original posters might have reasonably expected.
Several telemarketing companies have a rule that says their people can't hang up first. It became quite a common policy a while ago, for sensible-sounding reasons. However, if you're an irritated householder who's being harrassed for the sixth time today, it leads to an interesting situation if you tell them you're just going to get your card and will be right back, and then put the phone down (without hanging up) and walk away. }:-)
Slashdot Mirror
Yeah, sure. That's why there are more P2P trades in Britney Spears than all your local indie bands put together.
Really, who are you trying to kid with this sort of argument?
And, in ten years time when nearly all the music is cheap crap and it's impossible to find any of the good stuff unless you already know the band anyway, they will wonder what went wrong.
But you have diminished the value of what they do have. The distributor can make all the copies they like, and you can argue that by copying illegally no-one has taken that away from them, but if they can't sell a single copy because everyone has an illegal version already, their material is worthless.
This is the aspect that many people conveniently choose to overlook when arguing that copyright infringement should not be called theft. No, it doesn't take away anything physical that cannot be replaced, but it does take away the value, and thus the financial compensation that was owed to the legal distributor of the material. In this respect, it is directly analogous to theft, and reasonable to equate the two for many purposes.
By the way, the answer to your implied question about intent to buy is simple. We live in a capitalist society, which uses money as a medium to represent both giving and getting our fair share of things. If you do useful work, you gain money, which you can choose to spend on things you want in return. Illegal copying is taking something without paying the money, which is breaking your side of the bargain, and thus a bad thing. If you don't want the stuff enough to pay for it, you don't take the stuff; that's how it works. People who take something without paying an agreed price are called thieves, hence again the analogy between copyright infringement and theft.
How is wide scale distribution of commercially valuable copyrighted material "fair use"? Please don't tell me you think making an arbitrary number of copies for people you've never met and don't even know is "personal use" or any such crap.
No, but the radio station has to pay lots for the rights to play the music on air, typically funded by adverts in between tracks.
So are you going to encourage people to respect copyright by boycotting P2P as well, or are you just making the RIAA's point for them that there's a whole class of bottom-feeders who just rip stuff illegally over P2P and never do buy even the stuff they think is good legitimately afterwards. Way to go, bullet in the foot for the pro-P2P argument.
Ultimately, while being easy to write does confer a small advantage, being easy to read is much more significant. As the oft-quoted motto reminds us, code is only written once, whereas it's likely to be read many times. A vanishingly small amount of a developer's time is spent typing. Most is spent in design, testing, documenting and such rather than programming, and even of what I'd call programming, only a tiny fraction of the time is spent pressing keys on a keyboard.
You're right, of course. But there's very little that's so new and different that an experienced programmer couldn't pick up the basics quickly, enough to decide if the tool was more useful to them than what they already knew. If it is, then they can invest more time in really getting to know it.
Again, I agree with you, but I don't see why this is a problem. Companies rarely need to keep up with the bleading edge, for the reasons I've given: there's little out there that's so new and improved as to justify investing in learning that rather than improving your abilities with the tools you already use.
I was about to write that it's an evolutionary process rather than a revolutionary one, when I realised that actually, a lot of these new developments really do just go around in circles. I wonder how many more times we have to reinvent LISP, ML, Eiffel or C before we realise that for all their idiosyncracies, languages like these have the goods, and all the C#s and Visual Basics and Pythons in the world are really just popular but ultimately insignificant steps along the way to reaching them?
Isn't it funny how, eventually, you can usually rely on good concepts to drift down from theoretically strong languages into the practical tools?
Andrei Alexandrescu, known in the C++ world for the miracles he performs with templates in his library code (a subject about which he literally wrote the book), produced an article on what he termed "discriminated unions" for the C/C++ Users Journal a few months back. It made quite an interesting read.
You can actually do quite a lot of the good stuff with C++, but somehow it's always a bit like Microsoft trying to force OO concepts into Visual Basic.Net: the general idea is there, but it never has quite the power or elegance of the original that you'd find in a language that was actually good at it.
Oh, for a language with the flexibility and strengths of C++, but also the sum types, pattern matching, closures and first order functions of ML and the text processing tools from Perl... :-)
Oh, I expect we don't disagree very much at all. :-)
I thought your original point was probably that it was important to keep the required part of the library small. (I've worked in instrument control and embedded markets myself, so I'm all too aware of the limitations there, and their size relative to the desktop PC apps market.) From your second comment, I can see that I got the right idea about your point of view.
Keeping the optional libraries separate from the core is exactly what I would want to see, hence the suggestion of a limited "kernel library" to provide bare essentials and a framework for more, while delegating more extensive functionality to some sort of centralised repository where you can find it if you need it. This approach has worked spectacularly well for a couple of things (Perl and (La)TeX being the first two that came to mind) and strikes me as a much better way forward than the monolithic beast that is Java's standard library.
A powerful library, a clear syntax, flexible underlying models and a wide user base?
I take it you've never suffered writing and debugging a complex XSLT set-up on a deadline, then? ;-)
Mark-up languages should be used for mark-up. Programming languages should be used for programming. Many people have suggested swapping these over; many more have tried and found it doesn't work.
Your description (and your example) look as though you like Perl, but find it mildly lacking in a few areas. Am I close?
!!like_hell_it_is
j/k
I think the problem today is that everything seems to be moving on much faster than it actually is.
Quite a few years ago, I learned to program in C and x86 assembler. They were useful at the time, and I learned a lot about structured programming and such while using them.
Several years later, I learned C++, and encountered OO for the first time.
At university, I discovered things like Java and ML. ML was new and interesting, but at the time Java was just underpowered C++ with a heavyweight standard library, and to a large extent it still is. That was when I realised that many "advances" that come along "at breakneck speed" aren't really any different to what you've already got.
For several years at the start of my professional career, I relied on little more than standard C++ and a few very common libraries (MFC, mainly, and some in-house things). I didn't need any more.
After a while, I got the feeling I was stagnating, and since I wanted to do a few things that weren't convenient with the C++, I went out and learned some more.
In the past couple of years, I've learned to generate HTML with XML/XLT, I've learned to write scripts in Perl, I've learned about server side scripting and CGI, I've learned to use MySQL, and recently I've put it all together and written a pretty solid bulletin board web site for a club I help run. And this was just with a few hours now and then out of curiosity; the day job writing back-end C++ without much whizz still pays the rent.
I guess my point is that three years ago, CGI, MySQL, Perl, XML and all the rest were just buzzwords to me. Everywhere you looked on the Internet, there were millions of pages of tutorials, mostly very bad ones, and people telling you it was the next great thing, radically different to all that's gone before, etc. You know what? I learned the basics of each of these things inside of a day, once I actually sat down, did some real homework to track down a decent tutorial and got on with it. None of this stuff is hard. Just find useful info -- which often still comes on paper, or in the form of docs from the tool provider for high calibre things like Perl, MySQL or Apache, and not from random glitzy web sites and magazines -- and do some reading.
I reckon if you have a general knowledge of programming in procedural, OO and functional styles, a bit of experience with database design and SQL, a bit of web savvy and familiarity with mark-up, and some general knowledge of modern computers, you can learn any of the buzzword technologies in a week, maybe even a day. They're really not very clever at all; the reason they're buzzwords is that stupid people talk them up to make them sound clever.
Keep the faith; if you've got solid basics -- as any old-timer in this industry probably does -- you're never far behind the lead edge if you choose to catch up. The only people who claim everything is advancing at lightspeed all the time are marketroids selling new buzzwords, and impressionable kids too new to the business to know any better. The rest of us can well afford to relax, keep an eye on new developments now and then, and simply learn whatever tools we need to do what we want to do, if and when we need them.
A language with sound underlying models, with simple implementation, which helps me do what I want rather than telling me what I want to do, and which has no dependence on today's buzzwords.
I think I'd hate your language. :-)
Damn, where are my mod points when I need them?
This post has hit the mark exactly. You can't create a good solution until you understand the problem, and different problems require different solutions.
I agree entirely with you (and Brooks) that syntax is just a means to an end. What's important is the underlying models behind that syntax. Today's models -- be they procedural, OO, functional or whatever -- lend themselves pretty well to textual representation. You could perhaps advance things a little with graphical representations, but I suspect the place for that sort of thing is in better development tools, rather than the definition of the language/environment itself.
The interesting question about graphical or new development environments is whether they'll make it practical to use more advanced underlying models that don't lend themselves readily to a textual representation. I've come across examples of this sort of thing at various points in my programming travels -- the concepts of interfaces, polymorphism of various sorts, modularity and access control come to mind as things that are inadequately represented by most of today's textual languages -- but never anything substantial enough to justify a shift to a radically different representation.
I think I understand where you're coming from, and I agree with the principle, although I don't entirely agree with exactly what you've said.
I think the issue of how libraries are handled is crucial to the success of a modern programming language, as numerous success stories and famous failures can testify. Here are a few random thoughts; how do they match up with yours?
Firstly, I agree that it is best to keep a small "kernel" standard library. This library should be very well designed, with as much thought put into it as the language itself. In particular, it must be readily extensible by other libraries without being overcomplicated. If you like, it should provide a framework for doing common programming tasks, without filling in too many specific cases.
However, I don't think it's either easy or desirable to separate libraries completely from the language itself (as in syntax, grammar, etc). Your own comment about C++ is wrong, for example: you cannot ignore the standard library completely, because certain language operations (such as a failed dynamic_cast on a reference type) result in behaviour that needs library support (throwing an exception of a type defined by the standard library).
Now, you could get around that by creating new standard types for such cases, but do they really belong in the formal grammar of the language, alongside normal exception behaviour but distinct from it? The point is, from a programmer's perspective, it doesn't matter whether that exception type is in the library or the language. It should function identically, offer the same interface, exhibit the same behaviour, either way. It shouldn't matter whether my string type is part of the language or part of the library; it should just work.
The same goes, to a lesser degree, for other libraries. Once I've decided to use a library (or part of it), that extra functionality should just be there. I shouldn't have to care where it came from, and the only time I should have to know it's in a library is when I'm identifying the functionality I want to use. The syntax, style and function should be just like any other feature of the pure language and its standard library.
As a final point, while I believe the standard and portable library should be compact and highly flexible, it's obvious that having a widely recognised and comprehensive library of commonly used functionality is advantageous. Look at the success of Java, for example; although many of its standard libraries suck compared to alternatives for other languages, or even replacements available for Java, that doesn't matter to many Java programmers, because they're good enough. OTOH, this results in suboptimal code due to laziness and/or lack of knowledge of alternatives on the part of many Java developers.
The solution to this, IMHO, is to follow the path set by Perl (CPAN), TeX (CTAN), etc. The sponsors of the language -- commercial or community -- should provide a well-known and recognised central repository, into which contributers can add their own offerings. Better yet, adopt a genuine community review process, such as the C++ Boost community has, to force higher standards within the libraries in the repository.
So, in my ideal little world, a language would have a structure such that libraries and language were indistinguishable except where identification is concerned (basically just a matter of how to specify which libraries are desired, and naming conventions to prevent clashes between them). The language should come with a standard library that provides really common features (basic math functions and string handling, for example) in flexible frameworks on which other libraries can build. The bulk of library functionality shouldn't be standard -- that's too invasive and too limiting -- but ideally should be collected in a central repository of peer-reviewed offerings, with simple, standard and widely known conventions for using those libraries in programs. This way, no-one uses substandard code by default, but you still have the comprehensive functionality base there when you want it.
Real people don't buy a computer, they buy the parts and build it themselves. That way, you can ignore the floppy issue completely...
Of course, real people also feel no pain when vendor X claims the instability is due to vendor B's component and vice versa. ;-)
Exactly my point; whatever rights Google may have relating to the former Deja database, are independent of my rights over my own work.
I don't see how that necessarily follows...
I've never heard of a court either recognising or disputing practices such as Internet archiving yet, either. :-)
But seriously, while there's an argument in favour of simplicity, I don't see how "We want it to be simple!" could or should translate into "By posting on Usenet I give up most/all useful rights relating to copyright of this material". Even if you decide that archiving is reasonable because I posted the material freely in the first place -- which you might do on public interest grounds, given certain caveats about people being able to prohibit this for their posts in a sensible way -- I don't see how I've granted any implicit rights for commercial use of my post. Then again, maybe you can argue that any non-free ISP providing Usenet access is making commercial use of my posts. Then again again, I'd argue that Usenet itself is essentially non-commercial, and the ISP is charging for the connection to Usenet.
You could have a fair and reasonable debate about what the implied permissions granted by posting to Usenet should be, in the best interests of both the public interest and the rights of the original poster, but this seems to be avoided at present, until someone feels aggrieved enough to take up the challenge. Unfortunately, in the meantime, people like me are having our material used by others for commercial gain, and while that is somewhat offensive, it's not worth our while to do anything about it.
I realise that what you say is currently the case, but I'm not sure it's a good idea to limit investigations as a result. After all, if you apply for a patent and it's turned down, chances are the confidentiality wasn't protecting much anyway.
I'm not sure it's quite as simple as that -- probably the effort required to implement the invention would also be relevant, for example -- but I think the idea of granting varying degrees of exclusivity has a lot of merit.
I question, quite sincerely, how many of those countries develop significant numbers of new inventions compared to countries that have parents. My (limited) experience is that most of the new tools, technologies and similar developments in such countries are copied from essentially the same things in other patent-offering countries, where the original research to develop them was done.
That, however, is a problem with the implementation of patents in the US, and not with the principle of patents per se.
As far as I'm aware, no other country in the world suffers anything like the same problems with patents at the US does. Having worked in industries where patents are relevant and genuine R&D does result in genuine new developments, I think the system works very well and does exactly what it's supposed to, as long as the patents granted are sensible and the provision for enforcing them is reasonable to both sides.
It seems that most of the genuine objections I've seen to USPTO-granted patents fall into fairly precise categories:
In each of these cases, the problem is the same: granting the patent is a one-sided benefit, good for the claiming party but never offering anything in return to the rest of the field.
Now, there is always going to be the risk, with any patent, of hard-to-find but genuine prior art coming to light after the patent has been granted. No-one knows everything in their field, even an expert, so you can never make this problem disappear completely. Logically, therefore, it must be incumbent on the party claiming the patent to do their homework, and accept that the patent will be struck down at some later stage if they don't do it well enough. It must also be practical for anyone with a legitimate claim to overturn a granted patent on this basis: not just big corps against smaller outfits, but also the other way around.
However, unavoidable problems aside, at least getting in specialist help in the manner suggested before granting a new patent would ensure that the gross errors that occur frequently at present would be prevented, which is a big step forward relative to status quo, IMHO.
Essentially, I believe people should have a right to take action against anyone who has used their posts in a way other than they might reasonably have expected when they posted them to Usenet. They have not consented to them being used in any other way.
This is clearly a grey area. Typically posts propagate within a few days, and then remain on servers for 2-4 weeks before they expire. Someone keeping them on a server a bit longer is fine, because there's no explicit standard that says everything expires after max 4 weeks AFAIK.
Someone who's kept them for years, and now offers them in a searchable archive, however, is (IMHO) operating well outside the expectations of normal Usenet practice. Someone who sells a database full of such posts for profit is likewise doing something quite different to what the original posters might have reasonably expected.
Several telemarketing companies have a rule that says their people can't hang up first. It became quite a common policy a while ago, for sensible-sounding reasons. However, if you're an irritated householder who's being harrassed for the sixth time today, it leads to an interesting situation if you tell them you're just going to get your card and will be right back, and then put the phone down (without hanging up) and walk away. }:-)