Nor is all code written in static languages elegant, clear, disciplined, or correct. You can't give a bad programmer enough tools to prevent him from making mistakes if you want to allow him the possibility to do anything interesting.
I'd far rather rely on a compiler than a developer to find bugs, any day.
In my experience, the bugs that compilers can't find are much more important. I'd rather use a more expressive, higher-level language that gives me the flexibility to do my work more productively and quickly and rely on disciplined coding to prove that I've accomplished what I intended to accomplish.
Any existing language running on Parrot right now can use the SDL bindings, if the language has syntactic support for loading the appropriate library and calling class and instance methods.
As well, Tim Bunce's plans for DBI 2, Perl's almost ubiquitous database module family, includes porting it to Parrot to make it available to any language running on Parrot.
Everything compiles down to Parrot bytecode, so if your language has the syntax for interoperability, you'll have it.
You're being lazy. Alternately, you're not being lazy enough.
I find that it's helpful to sketch out some idea of how the parts will fit together so I know where to start and when to stop, but I prefer to let the design emerge from writing the tests. It's really helpful to let the tests show you what it's like to use the API you're creating. If it's awful and awkward, there's a sign that you need to simplify it.
I also like to check for refactorings after each successful test-fail-code-pass cycle. It seems like more work in the short term, but the refactorings are usually much smaller than if I waited. It also makes my tests much less brittle to code changes.
I don't see any disagreement in the documentation; the only place the word "PERL" appears (apart from headings, define flags, and environment variables -- all of which which always appear capitalized) is in the section I quoted.
I suppose the same would go for Tcl, but man tcl doesn't find anything on my box.
I see your link to Java.net (running on mod_perl, by the way). Perhaps you like J2EE? The original goal of Java (err, Oak) was to program embedded devices. What does that have to do with anything?
I've come to the conclusion that people who say things like "____ doesn't scale" are merely engaging in vigorous and pedantic platform self-congratulation.
Darnit, I was just thinking that. Thanks for pushing yet another task on my overburdened stack. Of course, if you're interested, I could certainly show you how....
For what it's worth, when I started reading the article, I wasn't sure what to expect. I trust John's judgment though, and halfway through, his arguments had convinced me.
There were a couple of spots where I asked him to make revisions (since I thought his personal experiences might be exceptional), but we're both satisfied with the final product.
I don't particularly like that feature of Safari either, but if you're insinuating that I published this article because of an editorial bias toward Microsoft, you're wrong.
Read the article. Think about it. Then speculate as to why I published it.
Hm, I can't think of any of those features now, unless it was how Ruby handles adding methods to an instance. I like Ruby, but it has pieces I don't like.
On the other hand, I do remember objecting to the Rubyometer on occasion when the invocant has failed to pay homage to the source of Ruby's inspiration. Maybe that's what you had in mind.
Without design specifications and a complete, well written documentation, the only way people could check a program is by reading the whole code and understanding the whole thing.
Yeah, many proprietary software projects have a lot of outstanding bugs too.
it's more realistic to believe they're just forgetful and lazy.
I dare anyone to weed through hundreds and hundreds of duplicate submissions in the bin every day for a week and remember what did and didn't make it. It's more difficult than you'd think.
Weird things could happen, but I'll personally attest that Sun's working seriously on this. I'm not a Sun employee or contractor (but also not under NDA), so take what you will from my certainty.
Maybe technically true; I don't recall whether Rasmus called PHP/FI PHP. Still, the original project that eventually became modern PHP was a set of Perl scripts. See History of PHP and Related Projects for more information.
All things being equal, a strict structure produces fewer errors.
That may be true, but all things are not equal.
I don't have the impression you're talking about a language with an actual working static type system, such as Haskell or ML. The amount of bookkeeping the type systems of Pascal, C, Java, and C++ force on the programmer is significant. If you're concerned about programmer productivity, efficacy, and correctness, I think you have to consider the strengths and weaknesses of the abstractions the language provides.
A language that forces you to think about the storage size and layout of every variable is certainly strict, but is that really the kind of strictness that prevents errors?
Slashdot Mirror
Nor is all code written in static languages elegant, clear, disciplined, or correct. You can't give a bad programmer enough tools to prevent him from making mistakes if you want to allow him the possibility to do anything interesting.
In my experience, the bugs that compilers can't find are much more important. I'd rather use a more expressive, higher-level language that gives me the flexibility to do my work more productively and quickly and rely on disciplined coding to prove that I've accomplished what I intended to accomplish.
It's not just possible, it's a goal.
Any existing language running on Parrot right now can use the SDL bindings, if the language has syntactic support for loading the appropriate library and calling class and instance methods.
As well, Tim Bunce's plans for DBI 2, Perl's almost ubiquitous database module family, includes porting it to Parrot to make it available to any language running on Parrot.
Everything compiles down to Parrot bytecode, so if your language has the syntax for interoperability, you'll have it.
Apparently, they stay in place: Perl 6 and Parrot Essentials, 2E. (Disclaimer: I did tech review on the book.)
You're being lazy. Alternately, you're not being lazy enough.
I find that it's helpful to sketch out some idea of how the parts will fit together so I know where to start and when to stop, but I prefer to let the design emerge from writing the tests. It's really helpful to let the tests show you what it's like to use the API you're creating. If it's awful and awkward, there's a sign that you need to simplify it.
I also like to check for refactorings after each successful test-fail-code-pass cycle. It seems like more work in the short term, but the refactorings are usually much smaller than if I waited. It also makes my tests much less brittle to code changes.
Hey, there are people familiar with the writings of Joseph Campbell who find him simplistic and hasty to overgeneralize.
I don't see any disagreement in the documentation; the only place the word "PERL" appears (apart from headings, define flags, and environment variables -- all of which which always appear capitalized) is in the section I quoted.
I suppose the same would go for Tcl, but man tcl doesn't find anything on my box.
Read perldoc perlfaq1, specifically What's the difference between "perl" and "Perl"?
Subject line says it most, anyway.
I see your link to Java.net (running on mod_perl, by the way). Perhaps you like J2EE? The original goal of Java (err, Oak) was to program embedded devices. What does that have to do with anything?
I've come to the conclusion that people who say things like "____ doesn't scale" are merely engaging in vigorous and pedantic platform self-congratulation.
Yes, that's a euphemism.
Slash uses Template Toolkit. It's a nice system, but the Slash templates haven't changed much visually in years.
Darnit, I was just thinking that. Thanks for pushing yet another task on my overburdened stack. Of course, if you're interested, I could certainly show you how....
(By the way, it's Perl, not PERL.)
For what it's worth, when I started reading the article, I wasn't sure what to expect. I trust John's judgment though, and halfway through, his arguments had convinced me.
There were a couple of spots where I asked him to make revisions (since I thought his personal experiences might be exceptional), but we're both satisfied with the final product.
I don't particularly like that feature of Safari either, but if you're insinuating that I published this article because of an editorial bias toward Microsoft, you're wrong.
Read the article. Think about it. Then speculate as to why I published it.
I did (or will, when he sends in his invoice). Can I have the million dollars now?
Hm, I can't think of any of those features now, unless it was how Ruby handles adding methods to an instance. I like Ruby, but it has pieces I don't like.
On the other hand, I do remember objecting to the Rubyometer on occasion when the invocant has failed to pay homage to the source of Ruby's inspiration. Maybe that's what you had in mind.
Are you avoiding the JIT problem by outlawing it, requiring proof of correctness for all JIT operations, redefining it, or something else?
Yeah, many proprietary software projects have a lot of outstanding bugs too.
I dare anyone to weed through hundreds and hundreds of duplicate submissions in the bin every day for a week and remember what did and didn't make it. It's more difficult than you'd think.
Weird things could happen, but I'll personally attest that Sun's working seriously on this. I'm not a Sun employee or contractor (but also not under NDA), so take what you will from my certainty.
If you had led with a dictionary definition of the word "essay", you would have had an essay and a speech in one!
It's not plagiarism when the submitter copies an introduction he wrote.
Self respect.
Maybe technically true; I don't recall whether Rasmus called PHP/FI PHP. Still, the original project that eventually became modern PHP was a set of Perl scripts. See History of PHP and Related Projects for more information.
That may be true, but all things are not equal.
I don't have the impression you're talking about a language with an actual working static type system, such as Haskell or ML. The amount of bookkeeping the type systems of Pascal, C, Java, and C++ force on the programmer is significant. If you're concerned about programmer productivity, efficacy, and correctness, I think you have to consider the strengths and weaknesses of the abstractions the language provides.
A language that forces you to think about the storage size and layout of every variable is certainly strict, but is that really the kind of strictness that prevents errors?
Ever programmed in C?