I don't think it's a good thing, but I know why it's there and I think it's a difficult-to-avoid syntactic trap. All languages have them; consider the ambiguous pronoun antecedent problem in English.
There are certainly ways around it too. On the compiler side, it's possible for the parser or tree transformer to detect an ambiguous expression of this sort and emit a warning or error message. On the programmer side, add parentheses to ambiguous expressions.
I consider separating a function parameter list from the function name akin to splitting a word in English, so I don't worry too much about this problem in general. I've also encountered it only twice in years and years of programming Perl 5. Maybe it makes me an awful person to believe that no designed language can completely eliminate ambiguous constructs. I can only imagine how tedious such a language would be.
It would have been SO EASY to define a flag or a pragma noting that all of the declarations in a file were implicitly of "my" variables, but this never happened.
How do you identify declarations without some sort of declaration identifier? Is it a typo or is it a new declaration? Other dynamic languages without a use strict 'vars'; equivalent suffer this problem.
But I am telling you this: if we don't fix Perl, we will die.
(Emphasis mine.) I look forward to your contributions of time, money, code, documentation, ideas, evangelism, testing, support, and praise.
Java, and C# (especially C#), however are truely on the cutting edge...
The cutting edge of what, the best technologies the '70s had to offer?
It's not clear that you understand CPS, continuations, coroutines, properties, language-supported roles, optional type inferencing and strictness, junctions, hyperoperators, rules, grammars, or closure-based control structures. I don't expect to see Java add any of those features in the next ten years. The CLR might add a few in the next five years.
Have you ever programmed in a language outside of the Algol family tree?
Multi-dispatch, junctions, roles, rules and grammars, a much improved VM, asynchronous IO, working threads, an event system, continuations and coroutines, optional typing and type inferencing, an immensely improved FFI, interoperability with other languages including Perl 5, an improved object system, hyperoperators, unification of blocks and closures, properties, object-like built-ins, improved reflection and introspection, improved consistency, improved clarity, and improved distribution possibilities.
So they don't test anything? They just modify production code directly?
No, the part you quoted talks about the Rails development cycle. Rather than making a change, recompiling, and redeploying to see the change, you can just make the change. The typical Rails development process I've seen is to make a change, use the built-in web server to preview the app locally, then deploy it to a live server when everything's correct.
Nothing in Rails forces or encourages you to modify running production systems, but nothing in Rails forces you to test your code either -- just like nothing in J2EE, ASP.Net, PHP, or even plain HTML forces you to test or to deploy to a testing server first. Of course, Rails does make it easy to test your code.
I meant that Pugs was a frivolous project when it started and when Autrijus decided to experiment with his development process, not that it's a toy now. I don't believe it's a toy; I have a fair bit of Perl 5, Perl 6, and Haskell code in Pugs.
I meant that Pugs started as a frivolous project in the same sense that the Linux kernel started as a frivolous project and as much as any learning experience refactorable into useful, non-frivolous code is frivolous.
I'm not sure when Autrijus realized what he had, but I'm sure he didn't intend to write a full-fledged Perl 6 implementation with pluggable backends targeting Perl 5, Parrot, the JVM, and JavaScript, at least not at first.
Sometimes I wish that Slashdot would grow a spine and stand up for what it believes in.
Slashdot is a website. It doesn't believe anything.
Metonymy partially aside, it's irresponsible to believe that the opinions of some commentors are the same as all commentors, the site editors, and all Slashdot readers. If you make the mistake of basing your self-worth on having lots and lots of people agree with you (or worse, on being able to find apparent hypocrisy of overgeneralized groups of people that don't agree with you), you're in for a lot of disappointment.
If you want to boycott EA, do it. I do. If someone asks, I'll explain why. It's not worth it to me to throw a fit and try to find conspiracies in everyone who doesn't, though.
Bottled water distributors sell water. That's their product. Restaurants often give free water with meals. The meals are their products -- not the water. Are they in competition? In the case of Debian, soup kitchens give away water and even soup. Are they in competition with restaurants and bottled water distributors?
...if the DOJ, according to you, is infallable...
My point was merely that your argument is fallacious. Unless this is rhetorical flourish on your part, you've read far too much into that.
I don't think you understand either PHP or Perl 6. Compare the count of core operators, for example, and consider that despite a few stabs at CLI use and GUI programming, PHP is not a general purpose programming language in any sense that Perl is.
Re:Screensavers, music, and Unicode?
on
State of the Onion 9
·
· Score: 5, Funny
Well I guess that explains then what he's been doing instead of fricking finishing Perl 6!!!
The sinister Perl 6 cabal briefly debated unlocking Larry from the chains holding him to his desk for 23 and a half hours every day until the first stable release so he could respond, but this comment has given us a much needed sense of perspective: some random jackass on the Internet has nothing better to do than complain. It's back to the salt mines for Mr. Wall!
Re:Python is nice but consider LUA for game script
on
Game Scripting With Python
·
· Score: 2, Informative
You know, tools such as StackGuard, ProPolice, Valgrind, Splint...
What if your way to do it didn't fit with the vision of whoever chose the one or two ways to do it?
If you're working on a multi-person project that's a mixture of many different styles and techniques, then the problem is with the development process, not the language. Until someone invents a language where there's one true formatting style, one true symbol naming style, one obviously right name for every symbol, one single API for every necessary library, and so on, you're going to have to trust other people to write maintainable code where the language doesn't help you. If that language ever comes about, you ought to hope that the choices the language designer made match the problems you have to solve -- if not, you may have some ugly, ugly workarounds. Hopefully the language supports those with sufficient encapsulation to keep the ugliness confined appropriately.
The belief that the Son is of the Father (ie, that Jesus is divine, more than a man) didn't come about until several hundred years after the Church had formed.
You're right that certain beliefs and lines of thinking have changed and grown over time -- especially in Roman Catholicism with regard to Augustine's Aristotelianism, but the implication that the roots of Christianity weren't present in written form by at least the end of the first century doesn't fit the historical record.
How odd that your second paragraph claims that "exposure" is the predictor of vulnerability but your third paragraph says that the vulnerable Linux application is "badly written".
Might there be some correlation between the quality of an application and its vulnerability? If so, is it possible that a popular application of high quality might have fewer exploits than a less popular application of lower quality?
Everyone else in my neighborhood can tie their doors closed with bits of twine and clothesline at night and pretend that breakins happen because nine out of ten people on the street all use knots instead of locks to keep burglars out, but I'll stick with my deadbolt and not succumb to the fantasy that popularity is the primary indicator of vulnerability.
Even famous designers of other languages get that wrong. I've heard Larry Wall claim that the creator of Perl first thought about naming it after his wife, then chose "Pearl" before dropping the "a". Talk about confused!
count($arr) is better than $#arr because it's bleeding obvious what count($arr) does.
Not to me. count($arr) should always return 1, unless you meant count( @arr ) and want to break the consistency of list flattening everywhere else in the language. Of course, in Perl 6 you can say @arr.elements to get the number of elements in the array (though "elements" is a long method name, so there may be an alternate at some point if there's a good, clear, shorter synonym) or evaluate the array in numification context with +@arr.
And if you didn't know what $#arr does, there's no way to index that sort of thing in manual.
Sure it is! See perlvar, one of the oldest documentation pages. (If you never even knew of that page, it's well worth your time to browse the perltoc manpage.)
Slashdot Mirror
I don't think it's a good thing, but I know why it's there and I think it's a difficult-to-avoid syntactic trap. All languages have them; consider the ambiguous pronoun antecedent problem in English.
There are certainly ways around it too. On the compiler side, it's possible for the parser or tree transformer to detect an ambiguous expression of this sort and emit a warning or error message. On the programmer side, add parentheses to ambiguous expressions.
I consider separating a function parameter list from the function name akin to splitting a word in English, so I don't worry too much about this problem in general. I've also encountered it only twice in years and years of programming Perl 5. Maybe it makes me an awful person to believe that no designed language can completely eliminate ambiguous constructs. I can only imagine how tedious such a language would be.
Perhaps the reader should bother to learn the language (or at least consult the error messages) before complaining that it's too difficult to read.
I can't read Asian pictograms or any Sanskrit-derived languages, but somehow a couple of billion people in the world manage to get by with them.
How do you identify declarations without some sort of declaration identifier? Is it a typo or is it a new declaration? Other dynamic languages without a use strict 'vars'; equivalent suffer this problem.
(Emphasis mine.) I look forward to your contributions of time, money, code, documentation, ideas, evangelism, testing, support, and praise.
So does almost every phonetically written l an g u age, though it turns out that humans are still better at pattern matching than are computers.
The cutting edge of what, the best technologies the '70s had to offer?
It's not clear that you understand CPS, continuations, coroutines, properties, language-supported roles, optional type inferencing and strictness, junctions, hyperoperators, rules, grammars, or closure-based control structures. I don't expect to see Java add any of those features in the next ten years. The CLR might add a few in the next five years.
Have you ever programmed in a language outside of the Algol family tree?
Perhaps CPAN::Mini could help you.
Multi-dispatch, junctions, roles, rules and grammars, a much improved VM, asynchronous IO, working threads, an event system, continuations and coroutines, optional typing and type inferencing, an immensely improved FFI, interoperability with other languages including Perl 5, an improved object system, hyperoperators, unification of blocks and closures, properties, object-like built-ins, improved reflection and introspection, improved consistency, improved clarity, and improved distribution possibilities.
No, the part you quoted talks about the Rails development cycle. Rather than making a change, recompiling, and redeploying to see the change, you can just make the change. The typical Rails development process I've seen is to make a change, use the built-in web server to preview the app locally, then deploy it to a live server when everything's correct.
Nothing in Rails forces or encourages you to modify running production systems, but nothing in Rails forces you to test your code either -- just like nothing in J2EE, ASP.Net, PHP, or even plain HTML forces you to test or to deploy to a testing server first. Of course, Rails does make it easy to test your code.
You may be taking the wrong lesson from that exchange.
I meant that Pugs was a frivolous project when it started and when Autrijus decided to experiment with his development process, not that it's a toy now. I don't believe it's a toy; I have a fair bit of Perl 5, Perl 6, and Haskell code in Pugs.
I meant that Pugs started as a frivolous project in the same sense that the Linux kernel started as a frivolous project and as much as any learning experience refactorable into useful, non-frivolous code is frivolous.
I'm not sure when Autrijus realized what he had, but I'm sure he didn't intend to write a full-fledged Perl 6 implementation with pluggable backends targeting Perl 5, Parrot, the JVM, and JavaScript, at least not at first.
Slashdot is a website. It doesn't believe anything.
Metonymy partially aside, it's irresponsible to believe that the opinions of some commentors are the same as all commentors, the site editors, and all Slashdot readers. If you make the mistake of basing your self-worth on having lots and lots of people agree with you (or worse, on being able to find apparent hypocrisy of overgeneralized groups of people that don't agree with you), you're in for a lot of disappointment.
If you want to boycott EA, do it. I do. If someone asks, I'll explain why. It's not worth it to me to throw a fit and try to find conspiracies in everyone who doesn't, though.
Bottled water distributors sell water. That's their product. Restaurants often give free water with meals. The meals are their products -- not the water. Are they in competition? In the case of Debian, soup kitchens give away water and even soup. Are they in competition with restaurants and bottled water distributors?
My point was merely that your argument is fallacious. Unless this is rhetorical flourish on your part, you've read far too much into that.
I think you misunderstand the nature of the product an OSS company sells. I doubt the DOJ will make the same mistake.
I don't think you understand either PHP or Perl 6. Compare the count of core operators, for example, and consider that despite a few stabs at CLI use and GUI programming, PHP is not a general purpose programming language in any sense that Perl is.
The sinister Perl 6 cabal briefly debated unlocking Larry from the chains holding him to his desk for 23 and a half hours every day until the first stable release so he could respond, but this comment has given us a much needed sense of perspective: some random jackass on the Internet has nothing better to do than complain. It's back to the salt mines for Mr. Wall!
You know, tools such as StackGuard, ProPolice, Valgrind, Splint...
What if your way to do it didn't fit with the vision of whoever chose the one or two ways to do it?
If you're working on a multi-person project that's a mixture of many different styles and techniques, then the problem is with the development process, not the language. Until someone invents a language where there's one true formatting style, one true symbol naming style, one obviously right name for every symbol, one single API for every necessary library, and so on, you're going to have to trust other people to write maintainable code where the language doesn't help you. If that language ever comes about, you ought to hope that the choices the language designer made match the problems you have to solve -- if not, you may have some ugly, ugly workarounds. Hopefully the language supports those with sufficient encapsulation to keep the ugliness confined appropriately.
If not for TIMTOWDI, you wouldn't be able to do so.
Untrue. See, for example, the writings of the Ante-Nicene Fathers.
You're right that certain beliefs and lines of thinking have changed and grown over time -- especially in Roman Catholicism with regard to Augustine's Aristotelianism, but the implication that the roots of Christianity weren't present in written form by at least the end of the first century doesn't fit the historical record.
(I am an armchair historian.)
How odd that your second paragraph claims that "exposure" is the predictor of vulnerability but your third paragraph says that the vulnerable Linux application is "badly written".
Might there be some correlation between the quality of an application and its vulnerability? If so, is it possible that a popular application of high quality might have fewer exploits than a less popular application of lower quality?
Everyone else in my neighborhood can tie their doors closed with bits of twine and clothesline at night and pretend that breakins happen because nine out of ten people on the street all use knots instead of locks to keep burglars out, but I'll stick with my deadbolt and not succumb to the fantasy that popularity is the primary indicator of vulnerability.
There's no charge for Foo camp. O'Reilly hosts it, rents showers, and pays for food, wireless, and electricity.
Well a less subtle sense of humor anyway...
Even famous designers of other languages get that wrong. I've heard Larry Wall claim that the creator of Perl first thought about naming it after his wife, then chose "Pearl" before dropping the "a". Talk about confused!
Not to me. count($arr) should always return 1, unless you meant count( @arr ) and want to break the consistency of list flattening everywhere else in the language. Of course, in Perl 6 you can say @arr.elements to get the number of elements in the array (though "elements" is a long method name, so there may be an alternate at some point if there's a good, clear, shorter synonym) or evaluate the array in numification context with +@arr.
Sure it is! See perlvar, one of the oldest documentation pages. (If you never even knew of that page, it's well worth your time to browse the perltoc manpage.)