Me neither. The post to which I responsed made an absolutely inane suggestion revealing a deep non-understanding of what trademark is and I corrected it.
O'Reilly seems to think they now have the rights to Web 2.0
O'Reilly and CMP seem to think that they have registered for a service mark on the phrase "Web 2.0 Conference". That's very different and has very different implications.
Like it or not, something must be done soon if Parrot is to be taken seriously.
I checked in code to Parrot yesterday. I checked in code to Parrot today today. Did you?
I talked to a student who proposed a Summer of Code project today. Did you?
If "something must be done", someone must do something (unless by "something" you mean "yammer yammer endless armchair quarterback anywhere but with other developers, where it might actually matter").
Read the whole chapter, not just the title. Brooks argued that no single technique offered an order-of-magnitude improvement. The last part of the chapter describes several techniques which, when combined, may improve productivity.
The important question is instead "Does Ruby on Rails take advantage of multiple techniques to bring about an improvement in productivity?"
I doubt Intron is claiming this is a Perl feature.
Of course it's a Perl feature. If you evaluate that string numerically, you get just what it says: 0. If you evaluate that string for truth, you get just what it says: true.
Perl is an operator-oriented language. People who fail to understand this find themselves continually surprised.
The first is more important to me, as it relates to readability of code by people who don't know the language.
Why does that matter?
Seriously. Who cares if people who don't know the language can't read and understand it immediately? Do you expect them to maintain large, important projects written in the langauge without learning it? (If so, why?)
It's more than a little funny that, thanks to Mono, the newest version of C# will run on my laptop (Linux/PPC) sooner than the new version of Java will.
Global warming went back in time and convinced the founders of New Orleans to build on a coastal swamp below sea level and not to reinforce their levees?
I always thought the whole point of pair programming was to bring newbies up to speed with stuff...
That's a benefit when it occurs, yes, but the real point of pair programming is to get two people working together on a single task to stay disciplined, to implement all of the necessary features, to produce the best possible code, and to spread the knowledge of the entire system throughout the team. It supports many of the other XP practices.
Perl, at least of 5.8.8 and 5.9.3, uses both the GPL v1 (or any later version) and the Artistic License v1. You can choose which one applies if you modify and/or redistribute it. See the README file in the core distribution.
I've patched Perl a few times myself; it's not speculation.
Perl stores scalars in a structure called an SV. There are different subtypes of SV to hold various combinations of integers, floating point numbers, and strings. When you use a scalar in one of those contexts, Perl checks a flag to see if the SV has a valid value for the particular context. If so, it uses the cached value. If not, it converts from the current, most accurate value that it has to the value most appropriate for the context, caches the converted value, and sets a flag to note that it now also has the converted value available.
It's not the case that Perl stores everything as strings internally, nor is it the case that it always converts to and from the contextually appropriate representation. Yes, there is bookkeeping there, and in some cases that's slower than the corresponding C or assembly code, but I don't think the link you quoted gives the whole story. (In my opinion, this is also not the single biggest reason why Perl can be slower than C code -- there's scope overhead, reference counting, and opcode dispatch.)
You're right about the OpenGL support in SDL_perl. The problem is that there are three variants of the code in three repositories at the moment and no one has really had the time to merge them.
Part of the problem is that many of us have learned through repeated experience that many people with grand ideas and designs often produce very little usable code, if any.
Me neither. The post to which I responsed made an absolutely inane suggestion revealing a deep non-understanding of what trademark is and I corrected it.
O'Reilly and CMP seem to think that they have registered for a service mark on the phrase "Web 2.0 Conference". That's very different and has very different implications.
Unfortunately, that's not how trademarks work.
Perhaps you should do some research on trademarks before you start feeling disappointed.
I checked in code to Parrot yesterday. I checked in code to Parrot today today. Did you?
I talked to a student who proposed a Summer of Code project today. Did you?
If "something must be done", someone must do something (unless by "something" you mean "yammer yammer endless armchair quarterback anywhere but with other developers, where it might actually matter").
Do something, if you're someone. I dare you.
Read the whole chapter, not just the title. Brooks argued that no single technique offered an order-of-magnitude improvement. The last part of the chapter describes several techniques which, when combined, may improve productivity.
The important question is instead "Does Ruby on Rails take advantage of multiple techniques to bring about an improvement in productivity?"
Of course it's a Perl feature. If you evaluate that string numerically, you get just what it says: 0. If you evaluate that string for truth, you get just what it says: true.
Perl is an operator-oriented language. People who fail to understand this find themselves continually surprised.
Why does that matter?
Seriously. Who cares if people who don't know the language can't read and understand it immediately? Do you expect them to maintain large, important projects written in the langauge without learning it? (If so, why?)
Brilliant! If only we had thought of that!
A Japanese RPG is a spreadsheet with cutscenes?
It's more than a little funny that, thanks to Mono, the newest version of C# will run on my laptop (Linux/PPC) sooner than the new version of Java will.
When are they going to get to the firework factory?!
Global warming went back in time and convinced the founders of New Orleans to build on a coastal swamp below sea level and not to reinforce their levees?
No wonder people are afraid. That's powerful!
Of course, because we all know that the true mark of maintainability is when a programming neophyte can maintain a serious, important program.
I'm pretty sure you haven't asked EVERY good programmer whether he or she works best alone, if only because I know at least a few who claim otherwise.
That's a benefit when it occurs, yes, but the real point of pair programming is to get two people working together on a single task to stay disciplined, to implement all of the necessary features, to produce the best possible code, and to spread the knowledge of the entire system throughout the team. It supports many of the other XP practices.
You'd do the content site an even better service by not downloading the content, too.
It still passes all of its tests, even after Audrey and Leo hacked on it all day to connect it to Pugs.
Add cutscenes and combat to a spreadsheet. (That should be easier with the Cell processor.)
Perl, at least of 5.8.8 and 5.9.3, uses both the GPL v1 (or any later version) and the Artistic License v1. You can choose which one applies if you modify and/or redistribute it. See the README file in the core distribution.
I've patched Perl a few times myself; it's not speculation.
Perl stores scalars in a structure called an SV. There are different subtypes of SV to hold various combinations of integers, floating point numbers, and strings. When you use a scalar in one of those contexts, Perl checks a flag to see if the SV has a valid value for the particular context. If so, it uses the cached value. If not, it converts from the current, most accurate value that it has to the value most appropriate for the context, caches the converted value, and sets a flag to note that it now also has the converted value available.
It's not the case that Perl stores everything as strings internally, nor is it the case that it always converts to and from the contextually appropriate representation. Yes, there is bookkeeping there, and in some cases that's slower than the corresponding C or assembly code, but I don't think the link you quoted gives the whole story. (In my opinion, this is also not the single biggest reason why Perl can be slower than C code -- there's scope overhead, reference counting, and opcode dispatch.)
What now? Perl adjusts its speed according to your perception of its internals?
It might, if it were true. It's not.
The most recent and up-to-date OpenGL code is in the sdlperl1 repository. I'd love help getting that merged into the repository on sdl.perl.org.
You're right about the OpenGL support in SDL_perl. The problem is that there are three variants of the code in three repositories at the moment and no one has really had the time to merge them.
Part of the problem is that many of us have learned through repeated experience that many people with grand ideas and designs often produce very little usable code, if any.