I am technically stupid (which I'm not), I don't see TFV! All I see are pics. Shit article.
You might have some blocking extension which disables seing the video. I also didn't notice that there's a video until I read it in a comment. Temporary allowing the site to access youtube fixed the problem.
They could even make more money with the traditional model, if the price were right. I've once seen in a shop a CD with the sound track of a movie. I liked the music. I probably would have bought the CD. But not at a price that is considerably higher than the price for the complete movie on DVD!
The Java programmers were told the JVM handles the memory for them. So why should they learn to handle it themselves? After all, if they have to think about their memory, they lose a major reason to look down upon the C and C++ programmers!
Simple solution: Use IE6 for the internal apps, and another browser for the Internet. As added bonus, if you manage to technically enforce that policy (e.g through proxies which detect the used browser), you are safe from XSS attacks against your internal apps coming from the internet.
It's not that it's "wrong", it just says a lot about the "programmer", and would make me want to ask furthermore questions before hiring. I'd rather a developer knew how their cut'n'pasted code was working, and how to fix it if it's buggy.
Oh, that's easy. The cut and pasted code works well, at least in the two unrealistic cases he tested. Otherwise he wouldn't have used it. And if it is buggy, just find some better code to cut and paste from.
[OK, all the text added at the end didn't help to please the lameness filter; maybe it considers only a certain number of lines. Well, let's add junk to the beginning instead. That's of course even less nice to the reader, but if the alternative is to not get this post posted at all...]
Beautiful is better than ugly.
I think nobody argues that -- assuming all else being equal, of course (beautiful but incomprehensible is certainly worse than ugly but understandable).
Explicit is better than implicit.
Sometimes, but often not. That's why e.g. the vast majority of programming languages uses the same operator for adding integers and for adding floats. Now for division, it does make sense to distinguish both. Also note that all(!) abstraction is about making some things implicit. This is even true for such simple things like a loop, where the explicit form would use an if controlling a goto. And isn't one of the much advertised advantages of languages like python over languages like C that memory management is implicit?
Simple is better than complex.
Only as long as you don't oversimplify.
Complex is better than complicated.
I'm not sure what exactly is meant here.
Flat is better than nested.
BASIC rules!
Sparse is better than dense.
Wrong. You can be too dense, and you can be too sparse. Both are equally bad.
Readability counts.
Of course. Nobody ever seriously argued that, I think.
Special cases aren't special enough to break the rules.
Depends on what is meant by that. If you need to break the rules for special cases, the rules are not general enough. However, when the language evolves, it may be the better solution to add a special case, than to replace the rules by better ones, breaking all the code depending on the old rules. Of course the worst decision would be to not support something useful purely on the reason that the current rules don't allow it.
Although practicality beats purity.
Again, depends.
Errors should never pass silently. Unless explicitly silenced.
In an ideal world, yes. In the real world, one has also to take into account how expensive it is to detect the error.
In the face of ambiguity, refuse the temptation to guess.
Guessing is bad. However, simple and clear rules for ambiguity resolution can be an advantage. Especially if the ambiguity exist only formally (i.e. to a human it's "obvious" what should happen).
There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch.
Disagree. This means forcing a certain style on the programmer. It should be the used style which makes the decision obvious, not the language (of course, there are very simple things where this rule obviously should hold; e.g. the obvious way to add x and y is to write x+y).
Now is better than never.
Depends. If someone wanted to kill me, I'd rather chose never than now.:-)
Although never is often better than *right* now.
No argument here.
If the implementation is hard to explain, it's a bad idea.
Not necessarily. If the hard to explain implementation is the only way to acomplish the task, it's a good idea to use it. Also: Explain to whom? I can imagine an implementation of a quantum computer simulator would be hard to explain to the average programmer, but relatively easy to explain to a quantum ph
The PHP interpreter tends to get bored with executing the code, and then browses the repositories. The less comments there are in the commit messages, the less time the PHP interpreter spends reading them, and the more time it can use to actually interpret the code.:-)
I would have expected the JavaScript programmers to have their code most likely to be read by the end-user. After all, unlike most other source code, sending the JavaScript source to the end user is mandatory.
C++ seems to be the opposite in how it draws moths to the flame of weird language features (Overload the + operator into actually subtracting, that type of thing).
Yes, you can overload the + operator to subtract on your own type. Just as you can define the function "add" to subtract in about every language I know (except classic BASIC, which didn't have named functions at all). If you find a "+" that subtracts, it's not a language problem, it's a programmer problem.
1) Germany is no human, therefore an ad hominem attack on it isn't possible. All you could do is an ad rem publicam attack. 2) Yeah, she never used the computer anyway. 3) They aren't. Most hardware comes in closed boxes! 4) But Windows 95 is bad. There's not even a 64 bit version! 5) Won't do it. I'm not a terrorist, you know? 6) Netcraft confirms it. 7) Yeah, they don't even have a Cowboy Neal option these days! 8) Your periods are inconsistent!
They ran over to Sauron.
One trademark to rule them all
and in the darkness bind them.
I am technically stupid (which I'm not), I don't see TFV! All I see are pics. Shit article.
You might have some blocking extension which disables seing the video.
I also didn't notice that there's a video until I read it in a comment. Temporary allowing the site to access youtube fixed the problem.
You can also get the video directly at http://www.youtube.com/watch?v=AaWFivMjJG0
Or maybe many tiny text files with a common format, like in Windows 3.11?
They could even make more money with the traditional model, if the price were right.
I've once seen in a shop a CD with the sound track of a movie. I liked the music. I probably would have bought the CD. But not at a price that is considerably higher than the price for the complete movie on DVD!
In the past they at least restricted "virus" to something that actually spreads.
Then put the externalities in the price (through taxes).
Exactly. This is like trying to reduce the noise in the entry lane of an airport by demanding that people turn down the volume of their TV.
Will they forbid those, too?
The Java programmers were told the JVM handles the memory for them. So why should they learn to handle it themselves? After all, if they have to think about their memory, they lose a major reason to look down upon the C and C++ programmers!
Code comments comment the code. Commit messages comment code changes. They are not exactly the same thing, but the differences are mostly technical.
Just integrate Bochs into your browser. :-)
Simple solution: Use IE6 for the internal apps, and another browser for the Internet. As added bonus, if you manage to technically enforce that policy (e.g through proxies which detect the used browser), you are safe from XSS attacks against your internal apps coming from the internet.
Possibly the U.S. government is angry about that, too. They just can't say it aloud.
No. They couldn't get the graphics drivers for the eye.
So PHP users only swear low-pitched? ;-)
It's not that it's "wrong", it just says a lot about the "programmer", and would make me want to ask furthermore questions before hiring. I'd rather a developer knew how their cut'n'pasted code was working, and how to fix it if it's buggy.
Oh, that's easy. The cut and pasted code works well, at least in the two unrealistic cases he tested. Otherwise he wouldn't have used it. And if it is buggy, just find some better code to cut and paste from.
SCNR :-)
[OK, all the text added at the end didn't help to please the lameness filter; maybe it considers only a certain number of lines. Well, let's add junk to the beginning instead. That's of course even less nice to the reader, but if the alternative is to not get this post posted at all ...]
I think nobody argues that -- assuming all else being equal, of course (beautiful but incomprehensible is certainly worse than ugly but understandable).
Sometimes, but often not. That's why e.g. the vast majority of programming languages uses the same operator for adding integers and for adding floats. Now for division, it does make sense to distinguish both. Also note that all(!) abstraction is about making some things implicit. This is even true for such simple things like a loop, where the explicit form would use an if controlling a goto.
And isn't one of the much advertised advantages of languages like python over languages like C that memory management is implicit?
Only as long as you don't oversimplify.
I'm not sure what exactly is meant here.
BASIC rules!
Wrong. You can be too dense, and you can be too sparse. Both are equally bad.
Of course. Nobody ever seriously argued that, I think.
Depends on what is meant by that. If you need to break the rules for special cases, the rules are not general enough. However, when the language evolves, it may be the better solution to add a special case, than to replace the rules by better ones, breaking all the code depending on the old rules. Of course the worst decision would be to not support something useful purely on the reason that the current rules don't allow it.
Again, depends.
In an ideal world, yes. In the real world, one has also to take into account how expensive it is to detect the error.
Guessing is bad. However, simple and clear rules for ambiguity resolution can be an advantage. Especially if the ambiguity exist only formally (i.e. to a human it's "obvious" what should happen).
Disagree. This means forcing a certain style on the programmer. It should be the used style which makes the decision obvious, not the language (of course, there are very simple things where this rule obviously should hold; e.g. the obvious way to add x and y is to write x+y).
Depends. If someone wanted to kill me, I'd rather chose never than now. :-)
No argument here.
Not necessarily. If the hard to explain implementation is the only way to acomplish the task, it's a good idea to use it.
Also: Explain to whom? I can imagine an implementation of a quantum computer simulator would be hard to explain to the average programmer, but relatively easy to explain to a quantum ph
Agreed. I've found that a letter followed by a three-digit number works much better. :-)
The PHP interpreter tends to get bored with executing the code, and then browses the repositories. The less comments there are in the commit messages, the less time the PHP interpreter spends reading them, and the more time it can use to actually interpret the code. :-)
Commit messages are comments, too.
I would have expected the JavaScript programmers to have their code most likely to be read by the end-user. After all, unlike most other source code, sending the JavaScript source to the end user is mandatory.
Or maybe in Python and PHP the code is already such a profanity that the programmers don't consider it necessary to add more of it in the comments ...
Yes, you can overload the + operator to subtract on your own type. Just as you can define the function "add" to subtract in about every language I know (except classic BASIC, which didn't have named functions at all). If you find a "+" that subtracts, it's not a language problem, it's a programmer problem.
C++ Templates will turn the most pious programmer into a curse-slinging, chain-smoking alcoholic.
Only those who don't understand them.
Learn a functional programming language, and you'll understand much more about C++ template programming.
1) Germany is no human, therefore an ad hominem attack on it isn't possible. All you could do is an ad rem publicam attack.
2) Yeah, she never used the computer anyway.
3) They aren't. Most hardware comes in closed boxes!
4) But Windows 95 is bad. There's not even a 64 bit version!
5) Won't do it. I'm not a terrorist, you know?
6) Netcraft confirms it.
7) Yeah, they don't even have a Cowboy Neal option these days!
8) Your periods are inconsistent!