You seem to be about the only responder in this thread who actually understands how files work.
It's pretty sad that people don't understand the pseudo-atomicity of the POSIXish way of handling file names (as opposed to files).
(You could also have mentioned the distinction between file handles and inodes (and lazy unlinking) to explain the "program can write to a deleted file without causing harm" bit, but whatever.)
... therefore Godditit, right? Aka. the "argument from ignorance".
So religion is just as good as your exploding rock theory.
Mischaracterizations aside, one of these ideas is supported by multiple lines of evidence (the cosmic microwave background radiation, observable expansion of the universe, etc.) the other is supported by a 2000-year (give or take) idea.
Straw men, hurling insults, moving the goal posts, etc. etc.
You still didn't answer my point: Why should I (as a programmer) be bothered by things that the computer can do for me? (And if your accusation that we are all 'idiots' is to be taken seriously, the computer would do it better.)
C++ has advantages. Not just ones that matter in this day and age where programmer time is more expensive than computer time. The disadvantages far outweigh its advantages.
Instead you have to make do with this statement. "In case that an object is destructed while still associated with an open file, the destructor automatically calls the member function close()."
What if "exceptions" is set and the file cannot be closed? Will the close() call throw in that case?
If so, the program just terminated() because it couldn't close a handle. But hey, at least it's not entered "undefined behavior" territory, eh?
Oh noes! You actually have to be smart to be a C++ programmer. Oh the horror!!! THE HORROR!!!!!!!!
Um, no. You have to be a robot to be a C++ programmer. Writing C++ is absurdly cumbersome and error-prone (what's the standard up to now, 1500 pages?) for some theoretical "efficiency" gain.
The smart way would be to choose a language which helps you get the job done with the minimum amount of fuss. If that entails extreme efficiency, then maybe you'll want to use C++ (or more likely C), but there are very few places these days where has any place.
Language X and Y both being Turing Complete doesn't mean shit when it comes to practical use and the level of abstraction you can achieve. For example, I'm about 10-100x more productive in Haskell than I am in Java simply because I'm working at a much higher level of abstraction.
Btw, most of the time it doesn't actually take an "expert" to identify where optimisations are needed. A profiler will do that in an automated, objective and easy way.
Picking an efficient algorithm at the start usually makes a big difference to overall performance and doesn't cost much in developer time.
You'd need to supply some evidence for this rather than just asserting it. In your example of sorting algorithms, it doesn't hold true: Quick sort is a lot more complicated to implement than, say, bubble sort. If you're picking between different sorting algorithms from a library, then it's certainly a different matter. In that case there really is a (demonstrably!) zero cost.
Unless you've benchmarked and determined that the choice of sorting algorithm is actually a problem, you should absolutely do the simplest thing that could possibly work. You have no grounds for doing anything else.
Theism doesn't provide any kind of basis for morality -- look in any holy book and you'll see that plain as day. Assuming you agree(*) with that proposition, how do can you explain the fact that humans are apparently better at deciding moral truth than $GOD?
(*) Otherwise, you'll essentially be endorsing slavery, mutilation of girls/boys/etc. etc. (Your holy book may contain small differences, but they're basically the same misogynist, homophobic bullshit.)
I agree with a lot of what you said, so take my silence on any issue as agreement.
I see what you did there. You're just trying to not represent any positive arguments made for Git, while being free to supply whatever counterarguments you think you have in favour of Bazaar. If you're going to do that, you're just being disingenuous -- which is to say: "not constructive".
Oh, and "Linus thinks it's a good idea" is not a good argument. (Hopefully) we're arguing on technical merit.
It think the AC answered most of your other points.
Unfortunately, misogyny is rampant in all "geek" fields (as it is in the rest of society). Just see the "Perform Like A Porn Star" talk at Ruby Con 2009, or even "ElevatorGate" in 2011.
(Btw, here in $European_Country, the percentage is still something like 10% female/90% male.)
You apply sound engineering practice
on
The Rise of Git
·
· Score: 1
and avoid breaking APIs willy-nilly. Instead you: provide the new API and deprecated the old in version n and remove the old API in version n+1 (or +2, or whatever).
If you have such a huge system (12 modules each of which is apparently too big for git), it's a very worrying sign that you're breaking the inter-module API often -- it probably means the modules aren't actually modular.
(Just for clarification: I've used both Bazaar and Git extensively.)
"Externalized" branches are still a bad idea. I've admin'ed a Bazaar installation and the fact that every group had its own convention for laying out branches in the file system was a complete pain in ass. (Some had multiple levels of directories, others only one, etc. etc.). It's bad from a scripting perspective and from a consistency perspective. It does not add any functionality that you actually need, but it does add a lot of incidental complexity.
There's also the fact that disconnected development requires you to predict in advance what branches you're going to need. Having all the branches in the same repo (i.e. it costs nothing to sync all of them) is a huge advantage here.
Re. revision numbers: Revision numbers are a fundamentally flawed model in a distributed world. In a distributed system there can be no consistent numbering unless you can and do enforce a global total order... which neither Bazaar nor Git do. The only sane thing to do is to use a "content" hash. The fact that Bazaar just lies to you and pretends that there is a global total order is not a plus. In practice, it led to unnecessary confusion because you always have to refer to branch and revision number, but people being what they are, they often forget that. The fact that a content hash identifies a given revision globally and uniquely means that you even don't have to care where you get the repository data from as long as the hashes match.
IME Bazaar is also a lot buggier than Git, presumably because of an internal model which is a lot more complicated than Git's. It's got a huge test suite, but we regularly ran it various obscure errors. It's also (still!) a lot slower than Git.
You're projecting a straw man who holds the fallacious belief that "it's natural therefore it's good".
Btw, the "atheists have no morals" objection has also been answered a multitude of times. Morals, cooperation and empathy are innate in us, "bred" into us by evolution.
You know I could switch your view point around to a creationist agenda and say most of the same words... like evolutionist are holding back science.
Well, ok, you could, but you'd be wrong. Evolutionary theory is the basis of all of biology. None of it makes sense outside an evolutionary context.
(notice that I call neither of them science as they are belief systems.... sure you can argue that evolution has basis in science however the odds IMO are stacked against it and there are very large gaps in the theory where you just have to believe things are one way or the other.... so I personally can't count it as scientific fact)
So, let's see... evolution is backed by mountains of evidence. Creationism is backed by... a book written roughly 1700 years ago. Guess it's fifty-fifty then, huh?
Here's another hint: One of these is scientific, the other isn't: A) Evolutionary theory, B) Creationism. Guess which is which.
it's a type error. (Whether or not that type error should be caught at compile time or run-time is debatable. This is about weak vs. strong typing, not dynamic vs. static type checking.)
Weak typing is a horrible, horrible idea with almost no redeeming value whatsoever.
(I still hook my my LCD monitor with VGA so I can keep my KVM switch)
Having the option of switching my outweigh it, but the only thing that'll happen by hooking up an LCD with a D-SUB (VGA) cable is that you'll get a blurry picture. (This was an issue even at 1024x768.)
Seriously, try a DVI cable and you'll never want to go back.
The point is that there is no way to pass anything other than a SanitizedSQLString to the "raw" database layer. The only way to produce a SanitizedSQLString is via a strictly defined set of "safe constructors".
The DB access library defines the "safe constructors", not you, nor should there be any way to "convert" a String to a SanitizedSQLString without going through one of the "safe constructors" (which properly escapes or throws exceptions on "invalid" input).
A proper module system with real abstraction boundaries can enfore that restriction trivially. In languages with poor module support, say Java, judicious application of "final" (or your language's equivalent) would probably be enough for "practical" safety -- i.e. ensuring that you never accidentally circumvent the "safe constructors".
Slashdot Mirror
What happens if, say, a close() fails during the destructor call?
You seem to be about the only responder in this thread who actually understands how files work.
It's pretty sad that people don't understand the pseudo-atomicity of the POSIXish way of handling file names (as opposed to files).
(You could also have mentioned the distinction between file handles and inodes (and lazy unlinking) to explain the "program can write to a deleted file without causing harm" bit, but whatever.)
Mischaracterizations aside, one of these ideas is supported by multiple lines of evidence (the cosmic microwave background radiation, observable expansion of the universe, etc.) the other is supported by a 2000-year (give or take) idea.
And... "anti-Creationists"? Seriously?
Straw men, hurling insults, moving the goal posts, etc. etc.
You still didn't answer my point: Why should I (as a programmer) be bothered by things that the computer can do for me? (And if your accusation that we are all 'idiots' is to be taken seriously, the computer would do it better.)
C++ has advantages. Not just ones that matter in this day and age where programmer time is more expensive than computer time. The disadvantages far outweigh its advantages.
What if "exceptions" is set and the file cannot be closed? Will the close() call throw in that case?
If so, the program just terminated() because it couldn't close a handle. But hey, at least it's not entered "undefined behavior" territory, eh?
What's your point?
Um, no. You have to be a robot to be a C++ programmer. Writing C++ is absurdly cumbersome and error-prone (what's the standard up to now, 1500 pages?) for some theoretical "efficiency" gain.
The smart way would be to choose a language which helps you get the job done with the minimum amount of fuss. If that entails extreme efficiency, then maybe you'll want to use C++ (or more likely C), but there are very few places these days where has any place.
Are you familiar with the phrase Turing Tarpit?
Language X and Y both being Turing Complete doesn't mean shit when it comes to practical use and the level of abstraction you can achieve. For example, I'm about 10-100x more productive in Haskell than I am in Java simply because I'm working at a much higher level of abstraction.
That's the understatement of the year. X11 is a dead end and it's time to face up to that fact.
(Just ask Keith Packard.)
Fullscreen has never worked satisfactorily for me, personally. There would always be some weirdness which made it practically useless.
You fail it.
Btw, most of the time it doesn't actually take an "expert" to identify where optimisations are needed. A profiler will do that in an automated, objective and easy way.
You'd need to supply some evidence for this rather than just asserting it. In your example of sorting algorithms, it doesn't hold true: Quick sort is a lot more complicated to implement than, say, bubble sort. If you're picking between different sorting algorithms from a library, then it's certainly a different matter. In that case there really is a (demonstrably!) zero cost.
Unless you've benchmarked and determined that the choice of sorting algorithm is actually a problem, you should absolutely do the simplest thing that could possibly work. You have no grounds for doing anything else.
I went to that site and it said
Your browser fingerprint appears to be unique among the 1,684,880 tested so far.
HAHA! ... Wait, what?
No, seriously, fuck you.
Theism doesn't provide any kind of basis for morality -- look in any holy book and you'll see that plain as day. Assuming you agree(*) with that proposition, how do can you explain the fact that humans are apparently better at deciding moral truth than $GOD?
(*) Otherwise, you'll essentially be endorsing slavery, mutilation of girls/boys/etc. etc. (Your holy book may contain small differences, but they're basically the same misogynist, homophobic bullshit.)
I see what you did there. You're just trying to not represent any positive arguments made for Git, while being free to supply whatever counterarguments you think you have in favour of Bazaar. If you're going to do that, you're just being disingenuous -- which is to say: "not constructive".
Oh, and "Linus thinks it's a good idea" is not a good argument. (Hopefully) we're arguing on technical merit.
It think the AC answered most of your other points.
Unfortunately, misogyny is rampant in all "geek" fields (as it is in the rest of society). Just see the "Perform Like A Porn Star" talk at Ruby Con 2009, or even "ElevatorGate" in 2011.
(Btw, here in $European_Country, the percentage is still something like 10% female/90% male.)
and avoid breaking APIs willy-nilly. Instead you: provide the new API and deprecated the old in version n and remove the old API in version n+1 (or +2, or whatever).
If you have such a huge system (12 modules each of which is apparently too big for git), it's a very worrying sign that you're breaking the inter-module API often -- it probably means the modules aren't actually modular.
(Just for clarification: I've used both Bazaar and Git extensively.)
"Externalized" branches are still a bad idea. I've admin'ed a Bazaar installation and the fact that every group had its own convention for laying out branches in the file system was a complete pain in ass. (Some had multiple levels of directories, others only one, etc. etc.). It's bad from a scripting perspective and from a consistency perspective. It does not add any functionality that you actually need, but it does add a lot of incidental complexity.
There's also the fact that disconnected development requires you to predict in advance what branches you're going to need. Having all the branches in the same repo (i.e. it costs nothing to sync all of them) is a huge advantage here.
Re. revision numbers: Revision numbers are a fundamentally flawed model in a distributed world. In a distributed system there can be no consistent numbering unless you can and do enforce a global total order... which neither Bazaar nor Git do. The only sane thing to do is to use a "content" hash. The fact that Bazaar just lies to you and pretends that there is a global total order is not a plus. In practice, it led to unnecessary confusion because you always have to refer to branch and revision number, but people being what they are, they often forget that. The fact that a content hash identifies a given revision globally and uniquely means that you even don't have to care where you get the repository data from as long as the hashes match.
IME Bazaar is also a lot buggier than Git, presumably because of an internal model which is a lot more complicated than Git's. It's got a huge test suite, but we regularly ran it various obscure errors. It's also (still!) a lot slower than Git.
You're projecting a straw man who holds the fallacious belief that "it's natural therefore it's good".
Btw, the "atheists have no morals" objection has also been answered a multitude of times. Morals, cooperation and empathy are innate in us, "bred" into us by evolution.
Well, ok, you could, but you'd be wrong. Evolutionary theory is the basis of all of biology. None of it makes sense outside an evolutionary context.
So, let's see... evolution is backed by mountains of evidence. Creationism is backed by... a book written roughly 1700 years ago.
Guess it's fifty-fifty then, huh?
Here's another hint: One of these is scientific, the other isn't: A) Evolutionary theory, B) Creationism. Guess which is which.
I'd suggest using the name McLovin. It always fools them.
it's a type error. (Whether or not that type error should be caught at compile time or run-time is debatable. This is about weak vs. strong typing, not dynamic vs. static type checking.)
Weak typing is a horrible, horrible idea with almost no redeeming value whatsoever.
Having the option of switching my outweigh it, but the only thing that'll happen by hooking up an LCD with a D-SUB (VGA) cable is that you'll get a blurry picture. (This was an issue even at 1024x768.)
Seriously, try a DVI cable and you'll never want to go back.
The point is that there is no way to pass anything other than a SanitizedSQLString to the "raw" database layer. The only way to produce a SanitizedSQLString is via a strictly defined set of "safe constructors".
The DB access library defines the "safe constructors", not you, nor should there be any way to "convert" a String to a SanitizedSQLString without going through one of the "safe constructors" (which properly escapes or throws exceptions on "invalid" input).
A proper module system with real abstraction boundaries can enfore that restriction trivially. In languages with poor module support, say Java, judicious application of "final" (or your language's equivalent) would probably be enough for "practical" safety -- i.e. ensuring that you never accidentally circumvent the "safe constructors".
There is no such thing as "intellectual property" -- it's an entirely fictitious concept. Boo-fuckin'-hoo, dude.