It's easier to design well an API and library if you're using it and can improve it as you go along. Even more than that, though, it's much easier to design a nice framework if you refactor it out of two or three applications that use it. Otherwise, you run the risk of designing things you'll never need, making the easy things complex, and turning hard things into impossible things.
I'm surprised that no one's made any decent generic game engines.
I'm not. I think before you can write a generic game engine, you must have at least one game running. See Programs suck; frameworks rule! for more on this.
C. S. Lewis was actually an Anglican. J. R. R. Tolkein was the Roman Catholic.
(Pullman's first two books in that trilogy are good, but the third one falls apart halfway through. I found his resolution of the huge conflict the previuos two books set up with years of backstory deeply unsatisfying.)
I don't understand the patent comment. Per my understanding of patents, there are two possibilities.
If the companies that distribute the software don't hold the patents, they're legally liable for infringing the patents regardless of the openness of the source code.
If the companies that distribute the software do hold the patents, the existence of the patent still means that they can bring suit against other people for infringing the patent regardless of the openness of the source code. Also, to obtain a patent, you have to disclose the process anyway, so it's not as if these techniques were secrets.
I think it's a false dilemma that you can either use Perl flexibly or write maintainable code. Surely a flexible language allows you to choose a coding approach that fits your team!
Regardless, I fail to see how agreeing on minutiae such as brace placement and indentation will make Perl inflexible. I don't understand on how agreeing to write short subroutines, use a consistent and descriptive naming scheme, and build a comprehensive test suite is unperlish.
In short, I think if your team can agree on a coding style, you can solve the maintainability program.
If you can't agree on a coding style, it doesn't matter which language you choose.
Actually, that happened at OSCON 2003. After Larry's talk, Guido van Rossum talked about the state of Python, Shane Caraveo talked about the state of PHP, Monty Widenius and David Axmark talked about the state of MySQL, Ted T'so talked about the state of the Linux kernel, and Greg Stein talked about the state of the Apache Foundation (not specifically Apache httpd).
I don't see the freedom in the GPL it dictates too much how GPL code HAS to be used.
This one time I was all like downloading this program you know and I untarred it blip blipety blip and there was this LICENSE file and I'm all checking it out and GPL this and GPL that and I'm like whatever dude 'cuz it's all YOU HAVE TO SPIN AROUND IN YOUR CHAIR THREE TIMES AND HOWL AT THE MOON and I'm like not even you don't tell me what to do Mr Program and I so deleted it but it came back and crash0r3d my box0r and it was like A. Major. Bummer.
You *can* do a XML parser in Perl, it just won't be as fast as in C, because ultimately Perl is interpreted.
Yes and no. If Perl 5 had an optimizing JIT and could turn string tokenizing operations into machine code, I think it'd still be slower than a corresponding C application because of the overhead of working with strings in Perl versus an array of characters in C.
Perl'd be a lot closer to C in that case, but C has a big win where it can increment a pointer and switch on the new value with very little overhead.
search.cpan.org, perhaps? Otherwise, you might like perldoc -f function for documentation on a function or perldoc -q searchterms to look up a question in the FAQ.
I can understand your quibble with learning what certain symbols mean in a specific context, but what part of learning a new codebase isn't learning the language of the solution? Class names, method names, function names, variable names, and metaphors -- they're all part of that new language.
Yes, the risks are high that any software, proprietary or open, infringes upon someone's patent.
No, I don't believe SCO's copyright suits would count as patent audits. That's completely different territory. For one thing, you don't have to create a derivative work or even know about the prior work to infringe upon a patent.
That's a good question. My guess, not being an attorney but having talked to a few, is that patent law is so different that the court wouldn't make that distinction. I don't know, though.
Perhaps there's a difference between civil law, contract law, and criminal law that comes into play here.
I smell a rat, and I bet it has something to do with the insurance money.
Smell harder. If you don't know and someone brings suit against you, you're liable for damages. If you do know and someone brings suit against you, you're liable for triple damages plus the attorney fees of the other side.
Sure, the system's completely messed up, but if your attorney doesn't tell you to minimize your risk by remaining ignorant, find a better attorney.
One problem with the U. S. Patent system is that looking for patent violations in your source code makes you liable for charges of willful infringement. I'd be surprised if any companies actually did this.
Did you read the article? Your post is full of inaccuracies.
Defending against a patent lawsuit is expensive and time-consuming. Sure, the courts throw out around half of all contested patents, but that means they uphold around half of all contested patents.
Unwitting infringement does not mean that the patent is bogus, it means that you can show reasonably well that you did not know that you reinvented something someone else had patented.
Where did you come up with the idea that patent damages include royalties?
Where did you come up with the idea that because you can't sue everyone associated with Linux you can't sue anyone? That's completely false.
I think you're confusing the notion of having a valid case versus actually bringing a case. You don't have to have a good chance of winning to file a suit. You just have to be stupid, arrogant, or really unfriendly.
Why isn't there a standard Database Independant Interface library yet?
For PHP? I suspect it's because the language has built-in MySQL access functions from the start, at least in the most common configuration. It's so easy to start using MySQL with PHP that there's really no reason an alternate access mechanism could gain any significant traction.
This is one of several cases in PHP where attempting to simplify the language for novices has made some tasks much more difficult. It's a pity that namespaces didn't make it into PHP 5.
Your argument was that Mac OS X has a larger market share than Linux because Mac OS X is more usable. If your premise doesn't hold, why should anyone believe your conclusion?
Perhaps the usability of Linux is better than you claim or the relative usability advantages of Mac OS X aren't valuable enough to justify the price.
Slashdot Mirror
It's easier to design well an API and library if you're using it and can improve it as you go along. Even more than that, though, it's much easier to design a nice framework if you refactor it out of two or three applications that use it. Otherwise, you run the risk of designing things you'll never need, making the easy things complex, and turning hard things into impossible things.
I'm not. I think before you can write a generic game engine, you must have at least one game running. See Programs suck; frameworks rule! for more on this.
C. S. Lewis was actually an Anglican. J. R. R. Tolkein was the Roman Catholic.
(Pullman's first two books in that trilogy are good, but the third one falls apart halfway through. I found his resolution of the huge conflict the previuos two books set up with years of backstory deeply unsatisfying.)
The editors usually schedule stories in advance for Slash to publish later.
Someone scooped you. It happens.
Sure, it's confusing to people who know what they're doing, but it's more elegant!
I don't understand the patent comment. Per my understanding of patents, there are two possibilities.
If the companies that distribute the software don't hold the patents, they're legally liable for infringing the patents regardless of the openness of the source code.
If the companies that distribute the software do hold the patents, the existence of the patent still means that they can bring suit against other people for infringing the patent regardless of the openness of the source code. Also, to obtain a patent, you have to disclose the process anyway, so it's not as if these techniques were secrets.
I think it's a false dilemma that you can either use Perl flexibly or write maintainable code. Surely a flexible language allows you to choose a coding approach that fits your team!
Regardless, I fail to see how agreeing on minutiae such as brace placement and indentation will make Perl inflexible. I don't understand on how agreeing to write short subroutines, use a consistent and descriptive naming scheme, and build a comprehensive test suite is unperlish.
In short, I think if your team can agree on a coding style, you can solve the maintainability program.
If you can't agree on a coding style, it doesn't matter which language you choose.
Actually, that happened at OSCON 2003. After Larry's talk, Guido van Rossum talked about the state of Python, Shane Caraveo talked about the state of PHP, Monty Widenius and David Axmark talked about the state of MySQL, Ted T'so talked about the state of the Linux kernel, and Greg Stein talked about the state of the Apache Foundation (not specifically Apache httpd).
Long night.
This one time I was all like downloading this program you know and I untarred it blip blipety blip and there was this LICENSE file and I'm all checking it out and GPL this and GPL that and I'm like whatever dude 'cuz it's all YOU HAVE TO SPIN AROUND IN YOUR CHAIR THREE TIMES AND HOWL AT THE MOON and I'm like not even you don't tell me what to do Mr Program and I so deleted it but it came back and crash0r3d my box0r and it was like A. Major. Bummer.
What possible legal claim could a license exert over the copyright holder?
Yes and no. If Perl 5 had an optimizing JIT and could turn string tokenizing operations into machine code, I think it'd still be slower than a corresponding C application because of the overhead of working with strings in Perl versus an array of characters in C.
Perl'd be a lot closer to C in that case, but C has a big win where it can increment a pointer and switch on the new value with very little overhead.
search.cpan.org, perhaps? Otherwise, you might like perldoc -f function for documentation on a function or perldoc -q searchterms to look up a question in the FAQ.
Until you want to put an object in a collection, that is -- even in Java 1.5.
I can understand your quibble with learning what certain symbols mean in a specific context, but what part of learning a new codebase isn't learning the language of the solution? Class names, method names, function names, variable names, and metaphors -- they're all part of that new language.
Yes, the risks are high that any software, proprietary or open, infringes upon someone's patent.
No, I don't believe SCO's copyright suits would count as patent audits. That's completely different territory. For one thing, you don't have to create a derivative work or even know about the prior work to infringe upon a patent.
That's a good question. My guess, not being an attorney but having talked to a few, is that patent law is so different that the court wouldn't make that distinction. I don't know, though.
Perhaps there's a difference between civil law, contract law, and criminal law that comes into play here.
That would be stupid AND arrogant AND unfriendly. SCO's clearly an aberration.
Smell harder. If you don't know and someone brings suit against you, you're liable for damages. If you do know and someone brings suit against you, you're liable for triple damages plus the attorney fees of the other side.
Sure, the system's completely messed up, but if your attorney doesn't tell you to minimize your risk by remaining ignorant, find a better attorney.
One problem with the U. S. Patent system is that looking for patent violations in your source code makes you liable for charges of willful infringement. I'd be surprised if any companies actually did this.
Did you read the article? Your post is full of inaccuracies.
Defending against a patent lawsuit is expensive and time-consuming. Sure, the courts throw out around half of all contested patents, but that means they uphold around half of all contested patents.
Unwitting infringement does not mean that the patent is bogus, it means that you can show reasonably well that you did not know that you reinvented something someone else had patented.
Where did you come up with the idea that patent damages include royalties?
Where did you come up with the idea that because you can't sue everyone associated with Linux you can't sue anyone? That's completely false.
I think you're confusing the notion of having a valid case versus actually bringing a case. You don't have to have a good chance of winning to file a suit. You just have to be stupid, arrogant, or really unfriendly.
Strange, then, that RMS has released more source code than I have and probably more than you have.
For PHP? I suspect it's because the language has built-in MySQL access functions from the start, at least in the most common configuration. It's so easy to start using MySQL with PHP that there's really no reason an alternate access mechanism could gain any significant traction.
This is one of several cases in PHP where attempting to simplify the language for novices has made some tasks much more difficult. It's a pity that namespaces didn't make it into PHP 5.
Your argument was that Mac OS X has a larger market share than Linux because Mac OS X is more usable. If your premise doesn't hold, why should anyone believe your conclusion?
Perhaps the usability of Linux is better than you claim or the relative usability advantages of Mac OS X aren't valuable enough to justify the price.
Care to revise that in light of IDC's claim that Linux overtook Mac OS X in desktop market share in 2003?