Re:This doesn't mean they want to "control" Python
on
Guido Goes Google
·
· Score: 1
Yeah, I clearly meant that to be a funny. I haven't looked at perl in a while now, but the last time I looked it was missing at least a couple of the features. And really, I think that the naming convention feature means not over-using (or allowing) the use of single characters to represent complex operations which leads to cryptic code. I've seen a lot of very cryptic code in older perl versions, maybe it has gotten better.
So all in all, perl really does violate at least a couple of items on my list, and doesn't have a big name promoter, which basically puts it in the same category as every other language: not quite there.
If you can afford 6 games, you can afford HD. It won't be big screen, but it'll be HD. Of course, if you wait one more year, it's likely you'll find HD + bigscreen very affordable.
That's an unfortunately bad benchmark. I've not been able to find any more realistic benchmark showing more than a 4x difference between intel-c and java.
He does at least the following wrong:
His benchmark reads from the console rather than doing file IO, and so puts console IO overhead into the benchmark. No one cares about console overhead in real performance.
His benchmark includes jvm startup time. You shouldn't count that against any of the programs in question, because this is a small one time cost (in the event you must run your program many many times, you can work around this by one-time loading the vm, and keeping it around).
His java implementation constructs a Counter object for every word, that's a grossly unnecessary implementation overhead compared to the C implementation.
He runs the java version under -client: anyone with really performance critical code is going to run in -server, and for that you'll need a larger benchmark to be fair.
All in all, a terrible inter-language benchmark.
Re:This doesn't mean they want to "control" Python
on
Guido Goes Google
·
· Score: 1, Insightful
I think this may be an issue with size of codebase: you claim you'd look at pmd, but wouldn't it be easier just to check by hand. To which i'd say: not in 40,000 source files, no it wouldn't. When I first ran PMD against our 40,000 source files I turned up four bad semi-colons, three of which were real bugs (one had no side effect). Likewise, if you're looking at a comparatively small amount of python, i'm not too surprised if you haven't run into this very often. Working on a large team, with a large codebase, you want tools to do as much work as possible, and python is not as friendly to that notion as it should be.
Re:This doesn't mean they want to "control" Python
on
Guido Goes Google
·
· Score: 2, Funny
I don't know if I can provide any sort of statistic. I've seen this error crop up in python more than a few times, and it is both annoying and potentially difficult to debug. I very much guarantee you it can reach a runtime error (unindent the last line of any if block). When it does crop up, you better hope you have a unit test that catches it, or that the behavior is sufficiently broken to be obvious.
Re:This doesn't mean they want to "control" Python
on
Guido Goes Google
·
· Score: 2, Interesting
It would be fantastic to see a language from google that: 1) is open source so the people who avoided java for that reason can participate 2) is brace constrained, so the people who hate python for whitespace can participate 3) has a full frontend for gcc, so the optimization freaks can participate 4) has a vm, so the web folks can love it 5) has an interpreter, so the python/ruby people can enjoy it 6) has multiple inheritance or explicit delegates, so the people who can't live without that aren't stuck in c++ 7) builds on all the great features we've been seeing in language design lately 8) has the functional programming features needed to draw in the ML/LISP crowd 9) comes with a nice well rounded library with a good naming convention 10) has the backing of a big name computer player (hence google)
Your tools should have caught that. Empty statement is even a warning in the standard javac now I believe, but even if it's not, you should definitely be using a code-cleaner like pmd (or various others).
That was where I started from all the way back in the great-great grandparent original post: preferring ruby.
My concern is that 'rarely' isn't very happy, and that this particular issue is potentially unfun to debug, particularly in situations where the intent is less obvious (and sure, unit tests might save you, if you were sure to capture every consequence of the if conditional, which in my experience is beyond the depth even fairly hardcore unit testers reach). I have never seen the corresponding brace error come up in java (which would be correct number of braces, but with a brace on the wrong line). The corresponding brace error which tends to actually occur is unmatched brace which never reaches runtime because you can't compile it.
If typing rate is a constraint on your productivity, that's a serious problem with methodology.
Note that running an auto-indenter on java is harmless, and not so on python.
Again, my experience suggests that making an indentation mistake is easier than making a brace mistake. Maybe your experience differs. But given my experience, I have to reach the conclusion that indentation based depth is a programming risk. If you're lucky enough to work with the sorts of people who will never make that mistake, that's great, but I'd rather work with a language and toolset that works hard to protect me from less talented peers.
Note that 'wrap'ing a big scientific program isn't exactly the same as writing a big scientific programming. I'm not saying python is unusable, just that it doesn't scale well (eg can't replace java).
I have, and of course you hope they will, but that requires that your unit tests cover every aspect of every conditional. That's the ideal, but the number of places actually successfully testing to that depth is miniscule.
Java may allow it, but who in their right mind doesn't flag a warning for unbraced if? This is trivial to do in all of the major IDEs, and everyone I know of does this, among numerous other code sanitizing requirements.
But with python, it's literally impossible to compile time check for this error.
I've worked with python long enough to actually see these mistakes happen. You only get an indentation error if your indentation is illegal, but not if your indentation is wrong but legal. An off by one brace error is a compile error in java, an off by one indentation is a run time bug in python. I've never seen a brace error reach runtime in java, but i've seen an indenting error in runtime python.
My experience tells me I don't want to have to debug poorly written python, and that i'll have no difficulty debugging poorly written java/ruby.
Whitespace errors can occur far more easily than block delimiting errors. Consider the case of un-indenting one line too soon. That produces an if condition error in python. Consider failing to close a block in java: that produces a compile time error.
Run time errors are much much badder than compile time errors.
Given that i've worked at only one place where I didn't have to work with people who would make this kind of error, I'd much rather stick with a language that will let me avoid having to debug this kind of mistake.
Pythons syntax relies on whitespace rather than closure for depth management. It's foreign to a sufficient number of programmers to represent a real bug risk, particularly as you try to grow toward building large programs.
Some people from Sun discussed it (at JavaOne) being in progress for java 6-7. That is, it will likely have a compiler in the java 6 timeframe, and will become a fully supported language in the java 7 timeframe. I don't have a link for you because Sun isn't publicly committed to this yet, so it could not happen, but given their interests that seems unlikely.
No one I've met doing serious development is building on python, it's just too error prone. Ruby (and on rails) are definitely gaining serious adherents though. Particularly with ruby likely to become a first class JVM language, Ruby's future looks pretty bright. Ruby may well replace java as the syntax of choice for developing big web apps.
It's a false assumption that they can't go back and change all existing devices: the plans are already in the works to require that future devices have an internet connection and be flash upgradeable to handle this potential risk. If the content owners succeed then such an upgrade will become mandatory (your device will stop functioning if you don't allow it to update regularly). Look at how the DirecTV people do this for a model of what will be coming (just imagine them being able to do it on a daily upgrade cycle rather than the semi monthly cycle DirecTV is stuck with).
Slashdot Mirror
Yeah, I clearly meant that to be a funny. I haven't looked at perl in a while now, but the last time I looked it was missing at least a couple of the features. And really, I think that the naming convention feature means not over-using (or allowing) the use of single characters to represent complex operations which leads to cryptic code. I've seen a lot of very cryptic code in older perl versions, maybe it has gotten better.
So all in all, perl really does violate at least a couple of items on my list, and doesn't have a big name promoter, which basically puts it in the same category as every other language: not quite there.
If you can afford 6 games, you can afford HD. It won't be big screen, but it'll be HD. Of course, if you wait one more year, it's likely you'll find HD + bigscreen very affordable.
Another followup:
your original link is to a benchmark in the 'old' category.
Have a look at the current benchmarks:
http://shootout.alioth.debian.org/
Wherein mostly java is generally no worse than 4x slower than the fastest implementation in any language.
That's an unfortunately bad benchmark. I've not been able to find any more realistic benchmark showing more than a 4x difference between intel-c and java.
He does at least the following wrong:
His benchmark reads from the console rather than doing file IO, and so puts console IO overhead into the benchmark. No one cares about console overhead in real performance.
His benchmark includes jvm startup time. You shouldn't count that against any of the programs in question, because this is a small one time cost (in the event you must run your program many many times, you can work around this by one-time loading the vm, and keeping it around).
His java implementation constructs a Counter object for every word, that's a grossly unnecessary implementation overhead compared to the C implementation.
He runs the java version under -client: anyone with really performance critical code is going to run in -server, and for that you'll need a larger benchmark to be fair.
All in all, a terrible inter-language benchmark.
Perhaps I omitted having a sane syntax. ;-)
I think this may be an issue with size of codebase: you claim you'd look at pmd, but wouldn't it be easier just to check by hand. To which i'd say: not in 40,000 source files, no it wouldn't. When I first ran PMD against our 40,000 source files I turned up four bad semi-colons, three of which were real bugs (one had no side effect). Likewise, if you're looking at a comparatively small amount of python, i'm not too surprised if you haven't run into this very often. Working on a large team, with a large codebase, you want tools to do as much work as possible, and python is not as friendly to that notion as it should be.
Give yourself time, you'll recover.
I don't know if I can provide any sort of statistic. I've seen this error crop up in python more than a few times, and it is both annoying and potentially difficult to debug. I very much guarantee you it can reach a runtime error (unindent the last line of any if block). When it does crop up, you better hope you have a unit test that catches it, or that the behavior is sufficiently broken to be obvious.
Can I buy stock in your cookie factory?
It would be fantastic to see a language from google that:
1) is open source so the people who avoided java for that reason can participate
2) is brace constrained, so the people who hate python for whitespace can participate
3) has a full frontend for gcc, so the optimization freaks can participate
4) has a vm, so the web folks can love it
5) has an interpreter, so the python/ruby people can enjoy it
6) has multiple inheritance or explicit delegates, so the people who can't live without that aren't stuck in c++
7) builds on all the great features we've been seeing in language design lately
8) has the functional programming features needed to draw in the ML/LISP crowd
9) comes with a nice well rounded library with a good naming convention
10) has the backing of a big name computer player (hence google)
Is it too much to ask?
Please, google?
See the various white space dependency issue posts.
Your tools should have caught that. Empty statement is even a warning in the standard javac now I believe, but even if it's not, you should definitely be using a code-cleaner like pmd (or various others).
/ pmd
http://java-source.net/open-source/code-analyzers
That was where I started from all the way back in the great-great grandparent original post: preferring ruby.
My concern is that 'rarely' isn't very happy, and that this particular issue is potentially unfun to debug, particularly in situations where the intent is less obvious (and sure, unit tests might save you, if you were sure to capture every consequence of the if conditional, which in my experience is beyond the depth even fairly hardcore unit testers reach). I have never seen the corresponding brace error come up in java (which would be correct number of braces, but with a brace on the wrong line). The corresponding brace error which tends to actually occur is unmatched brace which never reaches runtime because you can't compile it.
If typing rate is a constraint on your productivity, that's a serious problem with methodology.
Note that running an auto-indenter on java is harmless, and not so on python.
Again, my experience suggests that making an indentation mistake is easier than making a brace mistake. Maybe your experience differs. But given my experience, I have to reach the conclusion that indentation based depth is a programming risk. If you're lucky enough to work with the sorts of people who will never make that mistake, that's great, but I'd rather work with a language and toolset that works hard to protect me from less talented peers.
Note that 'wrap'ing a big scientific program isn't exactly the same as writing a big scientific programming. I'm not saying python is unusable, just that it doesn't scale well (eg can't replace java).
I have, and of course you hope they will, but that requires that your unit tests cover every aspect of every conditional. That's the ideal, but the number of places actually successfully testing to that depth is miniscule.
Java may allow it, but who in their right mind doesn't flag a warning for unbraced if? This is trivial to do in all of the major IDEs, and everyone I know of does this, among numerous other code sanitizing requirements.
But with python, it's literally impossible to compile time check for this error.
I've worked with python long enough to actually see these mistakes happen. You only get an indentation error if your indentation is illegal, but not if your indentation is wrong but legal. An off by one brace error is a compile error in java, an off by one indentation is a run time bug in python. I've never seen a brace error reach runtime in java, but i've seen an indenting error in runtime python.
My experience tells me I don't want to have to debug poorly written python, and that i'll have no difficulty debugging poorly written java/ruby.
Whitespace errors can occur far more easily than block delimiting errors. Consider the case of un-indenting one line too soon. That produces an if condition error in python. Consider failing to close a block in java: that produces a compile time error.
Run time errors are much much badder than compile time errors.
Given that i've worked at only one place where I didn't have to work with people who would make this kind of error, I'd much rather stick with a language that will let me avoid having to debug this kind of mistake.
Pythons syntax relies on whitespace rather than closure for depth management. It's foreign to a sufficient number of programmers to represent a real bug risk, particularly as you try to grow toward building large programs.
Some people from Sun discussed it (at JavaOne) being in progress for java 6-7. That is, it will likely have a compiler in the java 6 timeframe, and will become a fully supported language in the java 7 timeframe. I don't have a link for you because Sun isn't publicly committed to this yet, so it could not happen, but given their interests that seems unlikely.
No one I've met doing serious development is building on python, it's just too error prone. Ruby (and on rails) are definitely gaining serious adherents though. Particularly with ruby likely to become a first class JVM language, Ruby's future looks pretty bright. Ruby may well replace java as the syntax of choice for developing big web apps.
It's a false assumption that they can't go back and change all existing devices: the plans are already in the works to require that future devices have an internet connection and be flash upgradeable to handle this potential risk. If the content owners succeed then such an upgrade will become mandatory (your device will stop functioning if you don't allow it to update regularly). Look at how the DirecTV people do this for a model of what will be coming (just imagine them being able to do it on a daily upgrade cycle rather than the semi monthly cycle DirecTV is stuck with).
That only applies in the US. This has to be attached to WTO membership of course.
I've read it 3 times now, and I don't see what would make anyone believe that selling unsecured hardware would remain legal in any WTO country.