Criticize all you want. My points are very simple.
One, every feature in Perl (or any other F/OSS project) is there because someone put it there. If you want a feature, make it happen somehow. If you don't, you're probably not going to get it. Complaining that it should have been there years ago almost never works.
Two, people who've actually contributed to a project tend to know a lot more about the project and its development than people who haven't.
Criticize all you want. Just don't think that the people who actually do the work confuse your opinions for anything useful or informed.
The problem is with the other.o files you mention; they use GPLd kernel headers, which contain macros and constants and actual code. If you build those files, look at them with ldd or another tool--they do indeed link against GPLd code and, in some cases, actually include it.
There's no linkage in the source code; the.c files contain no GPLd code. It's only the act of compiling those files for the Linux kernel that makes the resulting binary a derivative work of the kernel.
If that binary is not a derivative work of the kernel, then distribution can follow NVidia's guidelines. I don't see how it is anything other than a derivative work though.
That's the packager's choice, but I can't see how the shim--though distributed as source code by NVidia--falls under the GPL, when compiled and linked against GPLd kernel headers. NVidia's distribution method is a very clever ploy to get around the GPL, but if evey they can't distribute a binary blob linked against the kernel apart from following the GPL, how could anyone else?
NVidia can't give permission to distribute compiled versions of the shim between the binary blob and the Linux kernel, as that code--when compiled--becomes a derivative work of the Linux kernel and the GPL (or standard copyright) applies.
Continuations is simply a modern term for GOTOs...
Maybe if you manage all of the memory management manually and implement your own frame storage and reclamation strategy.... (I like Sam Ruby's Continuations for Curmudgeons.)
Java was born to be an OO language.
Love those primitive types! (Smalltalk seemed to do okay without them.)
I think Perl's decision to undefine decades-old comforts like the ternary operator (?:) and bit shifting () is a huge mistake.
There are billions of potential programmers in the world and maybe a few million existing programmers. Optimizing for the benefit of the first group seems like the right choice to me.
It seems like so much has been changed, just for the sake of change.
It hasn't. Everything that has changed is to make the default easier or more sensible, to exploit similarities in similar features, or to enable more powerful features.
Your example of needing to know local and dialectical idioms is misleading...
Perhaps I was a bit unclear. I didn't mean only the idioms of the language, but also the idioms of the problem domain. I'd make a terrible programmer for insurance or payroll software because I've never worked in either industry.
That's something no language can completely solve, and yet another thing that depends on the discipline and standards of the entire team who created and maintains the software.
I don't mean to say that the only acceptable form of contribution is a patch. A bug report, a test, a question for the FAQ, a helpful answer on a mailing list or forum, a piece of documentation, an article, a tutorial, a book, or anything else constructive is absolutely fine.
Complaining in a completely unrelated forum without any apparent understanding of the issues or willingness to be a part of the community (by contributing anything) is completely useless. I don't see why the people who do contribute have any obligation to listen to such opinions, much less care.
I'm perfectly willing to dismiss uninformed, ignorant opinions from people who demonstrate clear refusal to be part of the community. They can still use the software I help create and document anyway.
How frequent is it? I could come up with a whole article full of criticisms of Perl 5's design and implementation (What is Perl 6 is a start). I wouldn't have seen everything Larry has seen, for example, but he's a lot better at designing languages than I am.
My experience is that a lot of project have wishlists with big and small items. Granted, the big items tend not to be radical rethinkings (as in the case of Perl 6), but I'm not sure it's as insular as you might think.
I'm willing to continueto earn the right to have people care about my opinions by producing code, patches, documentation, bug reports, test cases, articles, presentations, tutorials, and books.
The Perl development community has welcomed patches for nearly 19 years now. I believe you forgot to preface your humble opinion with "In my humble opinion as a non-contributor and someone who has used the work of hundreds of contributors (who know much better than me and thus may very well be in very good positions to disagree with my humble opinion) for many years for free...."
(Being one of those hundreds of contributors, I laugh when you say "simple" and dare you to prove it.)
Fine, but by that definition everything in the design a programming language is arbitrary, so that's a fairly useless description. I thought you meant the capricious or random definition, which (while incorrect in this case) actually means something in context.
... there's a fundamental disconnect between "arrays" and "iterators" that is just barely enough to keep you from using one as the other routinely, which is what you need for extensive library support.
You're right about that. It's probably too late to fix that in Perl 5, though that does give me an idea.
... but [the equivalent in any language of] 10,000 lines of Perl is a mess unless you're a very disciplined programmer.
Assuming, as a rule of thumb, that a line of Perl is equivalent to ten lines of C, would you expect an undisciplined programmer to maintain 100,000 lines of C code with ease? Me neither.
The "there's more than one way to do it" is hell on maintenance programmers, because they have to know everything in the language to read code.
No, they only have to know the idioms used in the code to read that code.
Suppose you take a job as the Mandarin-to-English translator for a large set of documents. It helps if everyone wrote at a sixth-grade reading level. It helps if every writer used the same local dialect. It helps if you can read Mandarin. If none of those are true, you and your employer have a severe problem.
...with Roles, which as I understand it act like a combination of interfaces and mixins...
That's not really it. Mixins and interfaces are cut-down, minimal, crippled implementations of roles. A role-based system offers both mixins and interfaces trivially, but mixins or interfaces offer poor emulations of roles. Does that make more sense?
Slashdot Mirror
In the case of music, the copyright holder and distributor explicitly provide listening stations and radio singles for you to try before you buy.
That's not the case when downloading cracked versions of a game.
Psst! It's Columbus Day (or Canadian Thanksgiving), not Incoherent Analogy Day. Sorry.
Really? For some reason, that reminds me of original Trek.
Let me fix this for you:
There; that helps me get through the day in all sorts of situations!
Perhaps all of the GMail developers transferred off of the team?
Maybe. I consider practice at least as important, however.
Criticize all you want. My points are very simple.
One, every feature in Perl (or any other F/OSS project) is there because someone put it there. If you want a feature, make it happen somehow. If you don't, you're probably not going to get it. Complaining that it should have been there years ago almost never works.
Two, people who've actually contributed to a project tend to know a lot more about the project and its development than people who haven't.
Criticize all you want. Just don't think that the people who actually do the work confuse your opinions for anything useful or informed.
The problem is with the other .o files you mention; they use GPLd kernel headers, which contain macros and constants and actual code. If you build those files, look at them with ldd or another tool--they do indeed link against GPLd code and, in some cases, actually include it.
There's no linkage in the source code; the .c files contain no GPLd code. It's only the act of compiling those files for the Linux kernel that makes the resulting binary a derivative work of the kernel.
If that binary is not a derivative work of the kernel, then distribution can follow NVidia's guidelines. I don't see how it is anything other than a derivative work though.
That's the packager's choice, but I can't see how the shim--though distributed as source code by NVidia--falls under the GPL, when compiled and linked against GPLd kernel headers. NVidia's distribution method is a very clever ploy to get around the GPL, but if evey they can't distribute a binary blob linked against the kernel apart from following the GPL, how could anyone else?
NVidia can't give permission to distribute compiled versions of the shim between the binary blob and the Linux kernel, as that code--when compiled--becomes a derivative work of the Linux kernel and the GPL (or standard copyright) applies.
Maybe if you manage all of the memory management manually and implement your own frame storage and reclamation strategy.... (I like Sam Ruby's Continuations for Curmudgeons.)
Love those primitive types! (Smalltalk seemed to do okay without them.)
There are billions of potential programmers in the world and maybe a few million existing programmers. Optimizing for the benefit of the first group seems like the right choice to me.
It hasn't. Everything that has changed is to make the default easier or more sensible, to exploit similarities in similar features, or to enable more powerful features.
Perhaps I was a bit unclear. I didn't mean only the idioms of the language, but also the idioms of the problem domain. I'd make a terrible programmer for insurance or payroll software because I've never worked in either industry.
That's something no language can completely solve, and yet another thing that depends on the discipline and standards of the entire team who created and maintains the software.
I don't mean to say that the only acceptable form of contribution is a patch. A bug report, a test, a question for the FAQ, a helpful answer on a mailing list or forum, a piece of documentation, an article, a tutorial, a book, or anything else constructive is absolutely fine.
Complaining in a completely unrelated forum without any apparent understanding of the issues or willingness to be a part of the community (by contributing anything) is completely useless. I don't see why the people who do contribute have any obligation to listen to such opinions, much less care.
I'm perfectly willing to dismiss uninformed, ignorant opinions from people who demonstrate clear refusal to be part of the community. They can still use the software I help create and document anyway.
How frequent is it? I could come up with a whole article full of criticisms of Perl 5's design and implementation (What is Perl 6 is a start). I wouldn't have seen everything Larry has seen, for example, but he's a lot better at designing languages than I am.
My experience is that a lot of project have wishlists with big and small items. Granted, the big items tend not to be radical rethinkings (as in the case of Perl 6), but I'm not sure it's as insular as you might think.
Indeed I have, and it was as wrong for me to do so as it is for you. Where's your patch?
I'm willing to continueto earn the right to have people care about my opinions by producing code, patches, documentation, bug reports, test cases, articles, presentations, tutorials, and books.
Pick one of those. Show us all how easy it is.
The Perl development community has welcomed patches for nearly 19 years now. I believe you forgot to preface your humble opinion with "In my humble opinion as a non-contributor and someone who has used the work of hundreds of contributors (who know much better than me and thus may very well be in very good positions to disagree with my humble opinion) for many years for free...."
(Being one of those hundreds of contributors, I laugh when you say "simple" and dare you to prove it.)
Fine, but by that definition everything in the design a programming language is arbitrary, so that's a fairly useless description. I thought you meant the capricious or random definition, which (while incorrect in this case) actually means something in context.
You're right about that. It's probably too late to fix that in Perl 5, though that does give me an idea.
Good thing it's not arbitrary then.
I think you have a typo. Let me fix it for you:
Assuming, as a rule of thumb, that a line of Perl is equivalent to ten lines of C, would you expect an undisciplined programmer to maintain 100,000 lines of C code with ease? Me neither.
No, they only have to know the idioms used in the code to read that code.
Suppose you take a job as the Mandarin-to-English translator for a large set of documents. It helps if everyone wrote at a sixth-grade reading level. It helps if every writer used the same local dialect. It helps if you can read Mandarin. If none of those are true, you and your employer have a severe problem.
I don't see why programming is any different.
Indeed you can. You don't get the iterator as the return value from a read operation on the iterator, but who would expect that you do?
See the book Higher Order Perl for far more examples.
That's not really it. Mixins and interfaces are cut-down, minimal, crippled implementations of roles. A role-based system offers both mixins and interfaces trivially, but mixins or interfaces offer poor emulations of roles. Does that make more sense?