C++ has a lot of tools and just because you don't have a need for them or have no idea how to correctly use them, it does not make them useless, pointless or otherwise.
You know what? You make a great point. I'm not being sarcastic, that's absolutely correct.
That being said, I think there is something to be said about the fact that tools shouldn't easily make people make mistakes. C++ is an old language (I consider it old because it's made to be compatible with C). Lots of languages have come around which improve on the language's features. There are always tradeoffs, but people are always trying to make it better. I think a lot of people's gripe with C/C++ that you see in these commentaries are valid, because the "power" that comes with C++ is actually possible in ways that are less likely to have people make mistakes when using it.
If the great minds could come together and write a new language which is meant to be a competitor to C++ (i.e. not Java, Python, etc.), they would make a MUCH better language than C++. Check out D, it is exactly that (although I admit I've never used D professionally, so I'm not trying to say D is the trump card here).
I guess my point is that, when you hear gripes about C++, it's not just because some developers aren't as awesome as the experts so they make mistakes... that's gonna happen no matter what language one uses. I believe that C++ is a language in which it is too easy to make mistakes, in the sense that another language would give a developer just as much power, but where that same developer of the same skill level would not make as many mistakes.
You forgot to mention the preprocessor. People may love it, but it is a solution to 1960's technical limitations that is totally unnecessary today. D completely removed the preprocessor and none of the power, instead using "static" templates and functions and constants, etc.
Oh, and header files. WTF? Header files? Why the fuck do I need to write it twice (or more)?
Much like the old roman empire was ultimately destroyed from the germanic peoples within, Modern Rome (USA) is being rotted inside-out by the bankers.
There's so much wrong with this analogy. Those two concepts are so so freaking far apart. But thank you for allowing me to elucidate with my knowledge of the ancient Roman empire, as this simple post may be one of the only 3 times such knowledge will ever be useful for any practical reason in my entire life.
The ancient Roman empire slowly degenerated for so many reasons that Edward Gibbons had to use thousands of very detailed pages to write about the subject. Other authors have written even more thousands of pages. One of the most controversial reasons was the adoption of Christianity over the old state religions, but I digress. Yes, many Germanic peoples were involved in the Western Empire and had power later and one tribe sacked Rome, but this wasn't really a problem from within, it was a problem from the outside that slowly moved in on old Roman borders. It did not actually come from the inside of the Empire; the Empire's effective borders shrank. When parts of the Empire broke off as time went on, the peoples rebelling weren't just Germans, there were many many ethnicities. Many Roman Germans considered themselves Roman before German, like I'd call myself American before "European-American". External invading German tribes did help such people have the conditions to rebel, but there were only a few of them over the hundreds of years that were successful... and even then, we'd call those external and not internal, right?:)
The western Roman empire of 350-500 AD is in no way shape or form comparable to the USA in 2011. The western Roman empire was weak and decentralized and didn't hold much power (imperium) over its supposed empire. It was not a single entity which had what can be described as the strongest military in the world of its time. It did not have the greatest economy. It was not superior to anyone in technology or learning, and in many ways was far inferior to lands east of it. People often get the Roman republic and empire of ~50 B.C to ~200 A.D. confused with the western Roman empire which fell in ~400-500.
Finally, even if there was one cause of the fall of the old "Roman empire" (you mean Western Roman empire) and it was from "Germanic peoples within", this is in no way comparable to bankers in the USA. To make the comparison, the bankers would have to be destroying the means and methods of the government to tax its people, and prevent another government or peoples from destroying or taxing the same people which the government claimed sovereignty over (i.e. ransacking tribes of Candians or self-declared independent states like the Confederacy).
Ugh, I've seen your signature from time to time on slashdot, and it bugs me because it's incorrect. "You may solo them" and "I prefer them in a group" are complete sentences on their own. I think you were going for the second option below (with the semicolon).
Wrong: You may solo them, I prefer them in a group. Correct: You may solo them; I prefer them in a group. Correct: You may solo them, but I prefer them in a group. Correct: You may solo them. I prefer them in a group.
I feel better now that I've got that out.:) If your objective was to piss off stupid grammar nazis like me, then by all means don't mind me.
Nobody seriously thinks that taxing the rich twice as much as we do will solve the problem (yes, you'll hear some random stupid voice say it, but that doesn't mean the "liberals" or the "democrats" as a whole are saying it). The entire democratic portion of the senate is trying to balance a way between three ways: cutting defense, cutting entitlements, and raising revenues. Not everyone agrees on how.
The frustration from the left is twofold: the right is does not want to cut from defense very much (i.e. unpaid wars) and they want to cut from entitlements too much. They also refuse to update the approximately 15,000 page tax code, because destroying a page from that might mean some.001% of entities may pay more taxes once that page is destroyed. The right also says that the left wants to "raise taxes on Americans" or "small businesses" and has an "obsession with taxes" which is simply a dishonest misconstruction to regular people who simply don't know what the truth of what the left really wants: the left does not want to raise taxes on almost all Americans and almost all small businesses, but regular Americans who listen to the right now think that they do.
The frustration from the right tends to be that the left wants to spend too much. That isn't correct, or at least it's a misrepresentation of what the left really wants: the left wants to spend on different things than the right. The left wants to spend less on wars and more on entitlements. It can be misconstrued to say the left wants to raise taxes when the left doesn't want to use borrowing to pay for wars, they want the wars to be paid for.
Sorry, but math trumps your class envy.
Your math is pointless, because nobody thinks that we should double income taxes on everyone. Saying that increasing taxes is "class envy" is a sleezy argument from the right. It is not class envy to think that raising taxes on the rich is a good idea at this point in time for some particular reason. It is not class envy to think that the ~15K page tax code should be updated. You want it to be class envy so that you demonize anyone saying this, but it isn't and ruins any hope of an objective debate (as opposed to emotional).
The real scenario looks more like this: it is likely that someone making 80K/year in 2011 will be paying 33% in taxes while someone making 300K/year will be paying 25% in taxes (or less, considering the rich can afford to pay someone to use the 15K page tax code for finding ways of paying less). The democrats want the scale to always be incremental in terms of income (i.e. poor, 1%, less poor 5%, etc...) and so they want the riches paying a higher percentage than the less rich. This is not class envy, this is a rational and objective argument.
And as a side note, if there is a perspective to say that tax breaks should be given for job creators, then tax breaks shouldn't be given based on income, they should be given based on job creation.
Problem solving is the cornerstone of Comp. Sci. and that requires creative thinking and coming up with different ways to do something. Just learning what stuff is, like integers or linked lists, isn't enough. OOP is definitely something that requires creative thinking to be able to properly design a program. Being creative and learning goes hand in hand in Comp. Sci., just don't mistake it with the "creative writing" sort of creative because that's different.
80-90% of Comp. Sci. college material does not require creative thinking, the same as with math. There is generally a "right way" to solve most problems. And remember, I'm specifically referring to learning CS and not something else like web design: linked lists, graph traversal, Big-O/computational mathematics, language theory, algorithms and other data structures, computer/processor architecture, etc. Don't mistake what I'm getting at. Yes, creativity is great (actually I would prefer to say "critical thinking" is great). But as someone who has experience in teaching material to various students, most of whom weren't CS majors, using pseudo-code and dynamically typed languages caused problems with students that were solved once we started using a statically typed language.
If you'd like to start using dynamically typed languages, go for it. I'm not saying they suck. What I'm saying is that I believe, and I have experience to back it up such an opinion, that dynamically typed languages are worse than statically typed languages for teaching CS concepts, especially to beginners.
I take it from your examples that you are a web developer.
So what?
Well, because you thought that people might as well teach Pascal as Java, as your experience as a web developer thought they were equally as relevant. Java is used a lot more than you're admitting, even though it is dying in certain areas (such as a language that would be used in many websites and web applications).
I think you are being a bit too defensive. Being creative to solve a problem is great, but being creative has nothing to do with learning the basics. I don't believe that creativity matters when learning how to implement a linked list, writing a binary search, OOP concepts, and other CS topics, any more than I think that creativity has to do with learning how to factor polynomials. Creativity is absolutely a great attribute in any field, including software development, but I was referring to learning. If it matters, I was a TA in CS classes which used many languages, including pseudo-code, LISP, SmallTalk, and Java.
I would have taken your examples more seriously if you hadn't said Java has no real world relevance and is a dead language. I take it from your examples that you are a web developer. Java is the absolute top language today. It is used in enterprise applications, server applications, and Android mobile applications, to name a few examples. It certainly won't be that way forever, and I have no idea how long it will be this way, but it is the most used language today. Google it. (here's the first hit from my google search: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html ) And as far as runtime environments go, that is a problem that all teaching environment languages suffer from. Even JavaScript can function differently on different browsers.
P.S. I don't think Java is the best language, the end-all language, etc. And yes, this is all opinion in the way of how to best teach programming and computer science concepts, but it is not an opinion when stating that Java is or isn't a dead language; factually it isn't.
switch from using Java as a teaching language to something like Python
I think it helps very much to have a statically typed language instead of a dynamically typed language used in teaching (regardless of Python vs. Java). Much better feedback for the student in figuring out why things work and don't work, enforcing designs, and lots more than I won't bother to enumerate.
For everything that Java does, there is a better alternative under a more functional language.
Re:Git could use revision numbers
on
The Rise of Git
·
· Score: 1
The guarantee of uniqueness would come from the master repository; see the OP. And it's not necessarily unique, it's just a label that says 15th commit since branch2 or something similar, as in "branch2.15".
However, I should also point out that the only guaranteed unique identifier would still be the SHA. The reason being is that, Git gives one the ability to "rewrite history", which is what happens whenever you have to do a "force" push. In this case, the revision numbers would change.
So once again, I think that they would be convenient as labels for people, but they would not be replacements for SHAs, and they would not be the same as SVN revision numbers. Just a better way of describing the history.
Elsewhere I mentioned that this requires a central/master repository. Revision numbers aren't replacements for SHAs, they are simply labels. Such as "10th commit since branch1". The revision number is only assigned on the master repository, so local repositories with commits that haven't been pushed to the master server don't even have such a revision number. Also, it is fully expected that the revision numbers would change if rebasing or cherry picking occurred which erased history on the master server, but this is what you get when you erase history (i.e. force push). Force pushing already erases history so it is expected it would renumber revision numbers.
Well then, I think this is an example of something Git doesn't do well and that's something it wasn't designed for. I suppose you'd have to write a custom script to copy to and from the git repository to the target location.
Re:Git could use revision numbers... Not!
on
The Rise of Git
·
· Score: 1
As I stated in the OP, this would ONLY work with a centralized repository setup, not a distributed one. The Linux kernel wouldn't make much sense with revision numbers. What I was thinking was that you could assign a repository to be flagged as the master, since in my experience I have worked exclusively with repositories that actually have a "master" repository.
And as I rebase and cherry pick all the time, I figure it would really hurt revision numbers, but other DVCSes seem to have tackled this problem. I don't know how, and I haven't thought it through enough. Personally, I think it would be fine for me to say "10th revision since this tag" and since the commit history could change, the revision numbers could change because it could become the "15th revision since this tag". The SHA would remain the same as the revision changed. And remember: this is only a people problem I'm trying to solve (communication, inherit description of the commit without looking up the SHA, etc.) Also, other posters have helpfully pointed out to me git describe, which I think I'll take a look at and start using.
Re:With Git, you can have better revision numbers
on
The Rise of Git
·
· Score: 1
Interestingly enough, this is pretty much what we've setup.:) The build system tags commits.
One thing that another user has pointed out to me about Bazaar is that Git's branches aren't inherently objects, just commits. When creating a branch in Bazaar the branch itself has a name/label. When groking the git graph, unless a developer properly tagged those branches, it is slightly more cumbersome to follow what and more importantly why the graph looks the way it does.
Re:Git could use revision numbers
on
The Rise of Git
·
· Score: 1
Nothing... but I would like to flag the "master" repository to automatically do it for me. I think tagging everything is overkill. But in any case, our build system is setup to tag builds so we do have some semblance of this.
Re:Git could use revision numbers
on
The Rise of Git
·
· Score: 1
Perhaps with a small number of commits like your 13 example, this would work fine. But what about r32185? Are you going to sit there and count them all by hand?
Actually, other modern VCSs with revisions would use branch/tags to create the revision numbers. So it would be "mybranch.500", which means it's a revision in "mybranch", or "release1.5-200", meaning the 200th commit after release1.5. This also helps when using the blame tool to find out why a certain line was changed, as you could see that this line was changed for "somefeature" inherently (although admittedly that's a minor caveat).
In a project the scale of the linux kernel, a commit might be copied around a large number of repositories before finally being blessed by Linus or one of his lieutenants and included in the next release. In all of those moves, the commit id will not change. But the branch it has been included in, and perhaps even the order it was merged will change.
As I stated in the original post, this idea would only work with a "centralized" or "master" repository. And it would only be a convenience label; the SHAs would still exist as normal. The Linux kernel repository is not centralized.
I gave examples elsewhere. One example is communication with other people, as in when speaking or e-mails. Another example is when using the Blame... tool, you can see that this line was changed with "mybranch-3" instead of having to look up "ec09302930293".
For example, with a SHA hash I can be sure that a branch/commit/tag/file/repository that I have is the same that you have
Revision numbers only work with a master/centralized repository, and not with decentralized repositories as Git was designed for. However, I've never once dealt with a Git repository that didn't have a "master" or centralized repository. And if you could assign such a repository as the master one (which you can't do in Git now), the master repository could assign revision numbers.
when you clone a git repo, you get everything checked out anyway, so you're not saving any space at all. This isn't like SVN's sparse directory feature where you can checkout partial repositories, with git you (practically) have to check it all out to use all its useful features.
No. With Git you have the entire database in a compressed form, and only one copy of the file system checked out. With SVN, if you get the entire database, you have ALL file structures checked out, i.e. you have every tag and every branch present on your local hard drive. Yes, I understand that most people wouldn't check everything out with a large SVN repository.
Also, just go to any open source repository that has a mirror Git and SVN repository and check them both out (as I have done for various reasons). The SVN repository always takes up more space. For example, try libgdx... the SVN repository took up 33% more space on my hard drive.
If you're ever trying to use relative paths between branches (and trunk is effectively a branch), then you're in a world of stupid.
As I stated elsewhere, I also thought it was stupid. But the company did it because that's how all SVN is setup... use trunk/branch/tags directories.
No, but "I've tried to learn it and it so far has confused the hell out of me" is grounds for an argument that something is hard to learn.
I agree 100%. Many of my professional team members have fucked up with Git. That being said... I suspect the problems my teammates have had is because distributed VCS is in general harder to grasp than centralized ones, and so I think my teammates would have fucked up with the other DVCSs too. I don't have any professional experience with Mercurial or Bazaar, so I can't compare that aspect or back up my guess.
Except with a major difference: Bazaar gives you the ability to have both checkouts share the same database, so it doesn't take up twice the amount of space. Git doesn't let you do this -- you'll have to create two full copies of the repository. (Ironically, this accusation is often made towards Bazaar by people who haven't heard of shared repositories.)
This sounds like an advantage that Bazaar has. Personally, though, I feel like if you only want to checkout parts of a repository, then the repository is too big. Modules deserve to have their own trunk/branches themselves. Once again, just opinion - and my point is completely moot if you're dealing with someone else's repository that's too big.
It seems like things weren't set up very well.
It wasn't. I hated it. I argued against it, and failed. I think it's terrible that a person would have to manually copy stuff after checking out a particular tag/branch. But with Git (or other VCSs), one could have checked out any tags/branches and the directory path wouldn't have changed. That's the main point I was getting at... separate directories changes pathnames.
Aren't you assuming that both of the parents have tags? Wouldn't the user need to manually tag the commits to get that effect?
Yes. A stable release simply has to have a tag... if it doesn't, this is beyond a discussion of comparison of VCSs, because you wouldn't make a stable release without a tag or some sort of label. As far as the branch goes, also yes... if it is a non-trivial branch, then it should have a tag or a branch label (usually in the form of "origin/branchname"). In my professional experience, all non-trivial branches either had tags or the "origin/branch" branch was still in the previous commit line before the merge.
.... my main source of frustration is not that people tend to prefer Git over Bazaar, it's that a) they dismiss the other DVCSes out of hand without actually learning about them, and b) the usual reasons claimed for why Git is better are true of all DVCSes.
Totally hear ya. I think that Git is a stepping stone to the next better thing in 5 years. It has drawbacks which could be solved (and apparently some of which has already been solved with Bazaar and Mercurial... but I'm not going to agree yet that Bazaar is the "correct" way either, yet:) And yeah, people tend to think what they already use is better, even if it's not the case. Tons of psych studies about this topic.
So, I want to check in (and push) the source file changes, but not the solution and project file changes. And i don't simply want to ignore the solution and project files, i just don't want to *push* them. I still want them versioned locally. This sort of thing sucks.
I do understand your example... but I still maintain that you're just doing it wrong. You don't need to commit them at the same time. Just commit them separately. In another VCS, you would check them in separately if you wanted to do what you're talking about.
There's no getting around the fact that you need one command to check in or commit one set of files, and another command to do the same to the second set of files, in any VCS.
You also can't just get one file from a git repository like you can from svn.
This may be true... but I've never encountered such an example in my life. The only times I've gotten a single file was by browsing online repositories, and certainly never in a case where I actually wanted to check a file back in. But in any case, that's certainly an example of what SVN can do that Git can't.
Re:Git could use revision numbers
on
The Rise of Git
·
· Score: 1
In one word: communication.
Revision numbers make communication easier. There is no difference between "15.1" and "e209309fff0902930293302920" as far as a unique ID to a software program goes, but there is a difference as far as communication to people goes. A revision number called "mybranch.13" inherently tells me that it is the 13th commit of mybranch, and is also easy to communicate to another person. Going further, it helps with Blame... lookups which says "this line was changed because of "thisnewfeature.13" and hence "thisnewfeature", instead of having to make awkward lookups of "e203920390293039".
Not every commit is tagged... and it shouldn't be, because that is what commit messages are for.
There is absolutely no software problem that is solved by revision numbers, only people problems.
Re:Git could use revision numbers
on
The Rise of Git
·
· Score: 1
I think your points misses my point: I do like Git, but revision numbers make communication easier. There is no difference between "15.1" and "e209309fff0902930293302920" as far as a unique ID to a software program goes, but there is a difference as far as communication to people goes. A revision number called "mybranch.13" inherently tells me that it is the 13th commit of mybranch, and is also easy to communicate to another person.
Mercurial's most touted advantage is that it's easier to learn, but this is a joke. If you develop, you interact with the version control system all day. A tiny advantage in learning it faster is nothing compared to not being able what you want to do afterwards, or having to redo something because the version control works against you instead of with you.
I work at a company that has used Git professionally. My team isn't dumb people, but they have fucked up with Git dozens of times. What I quoted is an okay argument at a personal level. However, there is something to be said as an organization that having an easy-to-use tools is better.
I am not making the argument that either Mercurial or Git is better; I am making the argument that tools which are easier to use will lead to less fuck-ups in an organization.
Re:PostgreSQL CVS-git conversion
on
The Rise of Git
·
· Score: 1
Interesting.
I would argue to the old-school developers that there is absolutely, positively, 100% no reason to ever use CVS in 2011. There is absolutely no advantage that CVS has over modern VCS's.
(2) You can't check out just a subtree of a Git repository. This actually has cost me quite a lot of time when I had to take a repository that I later figure out was too big and split it up.
I HATED this shit with SVN, I wanted to check out the entire repository but it was just too big, so I could only check out parts of it. Now, with Git, I've changed to where I love the fact that I have everything on my local storage.
What I think is that the reason repositories were so big in the first place was because CVS/SVN encouraged it. With Git, if a repository is too big and you want to split it up, then the repository shouldn't have been so big in the first place! If bet that if there were never a previous incarnation of VCS before Git, then people wouldn't throw their entire company's portfolio into one big friggin' repository. For example, if you have modules that work together, and it makes sense for these various modules to be released in separate versions (i.e. 1.5 of feature1 and 1.6 of feature2), then you should have separate repositories in Git. And that's even if the build system requires both repositories... OK then, have it get both repositories!
(3) I will occasionally get the repository into a configuration where I don't really understand how to get it back to something I know. Usually playing with it for a bit will fix it. (4) It's easy to forget to push.
I don't think this is a Git vs other VCS problem... it's just a general problem. If you never dealt with any other VCS then you wouldn't have mentioned these points. With forgetting to push, I think it's better to forget to push than to accidentally push something you didn't want to, IMO.
Slashdot Mirror
C++ has a lot of tools and just because you don't have a need for them or have no idea how to correctly use them, it does not make them useless, pointless or otherwise.
You know what? You make a great point. I'm not being sarcastic, that's absolutely correct.
That being said, I think there is something to be said about the fact that tools shouldn't easily make people make mistakes. C++ is an old language (I consider it old because it's made to be compatible with C). Lots of languages have come around which improve on the language's features. There are always tradeoffs, but people are always trying to make it better. I think a lot of people's gripe with C/C++ that you see in these commentaries are valid, because the "power" that comes with C++ is actually possible in ways that are less likely to have people make mistakes when using it.
If the great minds could come together and write a new language which is meant to be a competitor to C++ (i.e. not Java, Python, etc.), they would make a MUCH better language than C++. Check out D, it is exactly that (although I admit I've never used D professionally, so I'm not trying to say D is the trump card here).
I guess my point is that, when you hear gripes about C++, it's not just because some developers aren't as awesome as the experts so they make mistakes... that's gonna happen no matter what language one uses. I believe that C++ is a language in which it is too easy to make mistakes, in the sense that another language would give a developer just as much power, but where that same developer of the same skill level would not make as many mistakes.
You forgot to mention the preprocessor. People may love it, but it is a solution to 1960's technical limitations that is totally unnecessary today. D completely removed the preprocessor and none of the power, instead using "static" templates and functions and constants, etc.
Oh, and header files. WTF? Header files? Why the fuck do I need to write it twice (or more)?
Much like the old roman empire was ultimately destroyed from the germanic peoples within, Modern Rome (USA) is being rotted inside-out by the bankers.
There's so much wrong with this analogy. Those two concepts are so so freaking far apart. But thank you for allowing me to elucidate with my knowledge of the ancient Roman empire, as this simple post may be one of the only 3 times such knowledge will ever be useful for any practical reason in my entire life.
The ancient Roman empire slowly degenerated for so many reasons that Edward Gibbons had to use thousands of very detailed pages to write about the subject. Other authors have written even more thousands of pages. One of the most controversial reasons was the adoption of Christianity over the old state religions, but I digress. Yes, many Germanic peoples were involved in the Western Empire and had power later and one tribe sacked Rome, but this wasn't really a problem from within, it was a problem from the outside that slowly moved in on old Roman borders. It did not actually come from the inside of the Empire; the Empire's effective borders shrank. When parts of the Empire broke off as time went on, the peoples rebelling weren't just Germans, there were many many ethnicities. Many Roman Germans considered themselves Roman before German, like I'd call myself American before "European-American". External invading German tribes did help such people have the conditions to rebel, but there were only a few of them over the hundreds of years that were successful... and even then, we'd call those external and not internal, right? :)
The western Roman empire of 350-500 AD is in no way shape or form comparable to the USA in 2011. The western Roman empire was weak and decentralized and didn't hold much power (imperium) over its supposed empire. It was not a single entity which had what can be described as the strongest military in the world of its time. It did not have the greatest economy. It was not superior to anyone in technology or learning, and in many ways was far inferior to lands east of it. People often get the Roman republic and empire of ~50 B.C to ~200 A.D. confused with the western Roman empire which fell in ~400-500.
Finally, even if there was one cause of the fall of the old "Roman empire" (you mean Western Roman empire) and it was from "Germanic peoples within", this is in no way comparable to bankers in the USA. To make the comparison, the bankers would have to be destroying the means and methods of the government to tax its people, and prevent another government or peoples from destroying or taxing the same people which the government claimed sovereignty over (i.e. ransacking tribes of Candians or self-declared independent states like the Confederacy).
Ugh, I've seen your signature from time to time on slashdot, and it bugs me because it's incorrect. "You may solo them" and "I prefer them in a group" are complete sentences on their own. I think you were going for the second option below (with the semicolon).
Wrong: You may solo them, I prefer them in a group.
Correct: You may solo them; I prefer them in a group.
Correct: You may solo them, but I prefer them in a group.
Correct: You may solo them. I prefer them in a group.
I feel better now that I've got that out. :) If your objective was to piss off stupid grammar nazis like me, then by all means don't mind me.
Nobody seriously thinks that taxing the rich twice as much as we do will solve the problem (yes, you'll hear some random stupid voice say it, but that doesn't mean the "liberals" or the "democrats" as a whole are saying it). The entire democratic portion of the senate is trying to balance a way between three ways: cutting defense, cutting entitlements, and raising revenues. Not everyone agrees on how.
The frustration from the left is twofold: the right is does not want to cut from defense very much (i.e. unpaid wars) and they want to cut from entitlements too much. They also refuse to update the approximately 15,000 page tax code, because destroying a page from that might mean some .001% of entities may pay more taxes once that page is destroyed. The right also says that the left wants to "raise taxes on Americans" or "small businesses" and has an "obsession with taxes" which is simply a dishonest misconstruction to regular people who simply don't know what the truth of what the left really wants: the left does not want to raise taxes on almost all Americans and almost all small businesses, but regular Americans who listen to the right now think that they do.
The frustration from the right tends to be that the left wants to spend too much. That isn't correct, or at least it's a misrepresentation of what the left really wants: the left wants to spend on different things than the right. The left wants to spend less on wars and more on entitlements. It can be misconstrued to say the left wants to raise taxes when the left doesn't want to use borrowing to pay for wars, they want the wars to be paid for.
Sorry, but math trumps your class envy.
Your math is pointless, because nobody thinks that we should double income taxes on everyone. Saying that increasing taxes is "class envy" is a sleezy argument from the right. It is not class envy to think that raising taxes on the rich is a good idea at this point in time for some particular reason. It is not class envy to think that the ~15K page tax code should be updated. You want it to be class envy so that you demonize anyone saying this, but it isn't and ruins any hope of an objective debate (as opposed to emotional).
The real scenario looks more like this: it is likely that someone making 80K/year in 2011 will be paying 33% in taxes while someone making 300K/year will be paying 25% in taxes (or less, considering the rich can afford to pay someone to use the 15K page tax code for finding ways of paying less). The democrats want the scale to always be incremental in terms of income (i.e. poor, 1%, less poor 5%, etc...) and so they want the riches paying a higher percentage than the less rich. This is not class envy, this is a rational and objective argument.
And as a side note, if there is a perspective to say that tax breaks should be given for job creators, then tax breaks shouldn't be given based on income, they should be given based on job creation.
Problem solving is the cornerstone of Comp. Sci. and that requires creative thinking and coming up with different ways to do something. Just learning what stuff is, like integers or linked lists, isn't enough. OOP is definitely something that requires creative thinking to be able to properly design a program. Being creative and learning goes hand in hand in Comp. Sci., just don't mistake it with the "creative writing" sort of creative because that's different.
80-90% of Comp. Sci. college material does not require creative thinking, the same as with math. There is generally a "right way" to solve most problems. And remember, I'm specifically referring to learning CS and not something else like web design: linked lists, graph traversal, Big-O/computational mathematics, language theory, algorithms and other data structures, computer/processor architecture, etc. Don't mistake what I'm getting at. Yes, creativity is great (actually I would prefer to say "critical thinking" is great). But as someone who has experience in teaching material to various students, most of whom weren't CS majors, using pseudo-code and dynamically typed languages caused problems with students that were solved once we started using a statically typed language.
If you'd like to start using dynamically typed languages, go for it. I'm not saying they suck. What I'm saying is that I believe, and I have experience to back it up such an opinion, that dynamically typed languages are worse than statically typed languages for teaching CS concepts, especially to beginners.
I take it from your examples that you are a web developer.
So what?
Well, because you thought that people might as well teach Pascal as Java, as your experience as a web developer thought they were equally as relevant. Java is used a lot more than you're admitting, even though it is dying in certain areas (such as a language that would be used in many websites and web applications).
I think you are being a bit too defensive. Being creative to solve a problem is great, but being creative has nothing to do with learning the basics. I don't believe that creativity matters when learning how to implement a linked list, writing a binary search, OOP concepts, and other CS topics, any more than I think that creativity has to do with learning how to factor polynomials. Creativity is absolutely a great attribute in any field, including software development, but I was referring to learning. If it matters, I was a TA in CS classes which used many languages, including pseudo-code, LISP, SmallTalk, and Java.
I would have taken your examples more seriously if you hadn't said Java has no real world relevance and is a dead language. I take it from your examples that you are a web developer. Java is the absolute top language today. It is used in enterprise applications, server applications, and Android mobile applications, to name a few examples. It certainly won't be that way forever, and I have no idea how long it will be this way, but it is the most used language today. Google it. (here's the first hit from my google search: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html ) And as far as runtime environments go, that is a problem that all teaching environment languages suffer from. Even JavaScript can function differently on different browsers.
P.S. I don't think Java is the best language, the end-all language, etc. And yes, this is all opinion in the way of how to best teach programming and computer science concepts, but it is not an opinion when stating that Java is or isn't a dead language; factually it isn't.
switch from using Java as a teaching language to something like Python
I think it helps very much to have a statically typed language instead of a dynamically typed language used in teaching (regardless of Python vs. Java). Much better feedback for the student in figuring out why things work and don't work, enforcing designs, and lots more than I won't bother to enumerate.
For everything that Java does, there is a better alternative under a more functional language.
Care to back that up?
This page has all the details: http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html
The guarantee of uniqueness would come from the master repository; see the OP. And it's not necessarily unique, it's just a label that says 15th commit since branch2 or something similar, as in "branch2.15".
However, I should also point out that the only guaranteed unique identifier would still be the SHA. The reason being is that, Git gives one the ability to "rewrite history", which is what happens whenever you have to do a "force" push. In this case, the revision numbers would change.
So once again, I think that they would be convenient as labels for people, but they would not be replacements for SHAs, and they would not be the same as SVN revision numbers. Just a better way of describing the history.
Elsewhere I mentioned that this requires a central/master repository. Revision numbers aren't replacements for SHAs, they are simply labels. Such as "10th commit since branch1". The revision number is only assigned on the master repository, so local repositories with commits that haven't been pushed to the master server don't even have such a revision number. Also, it is fully expected that the revision numbers would change if rebasing or cherry picking occurred which erased history on the master server, but this is what you get when you erase history (i.e. force push). Force pushing already erases history so it is expected it would renumber revision numbers.
Well then, I think this is an example of something Git doesn't do well and that's something it wasn't designed for. I suppose you'd have to write a custom script to copy to and from the git repository to the target location.
As I stated in the OP, this would ONLY work with a centralized repository setup, not a distributed one. The Linux kernel wouldn't make much sense with revision numbers. What I was thinking was that you could assign a repository to be flagged as the master, since in my experience I have worked exclusively with repositories that actually have a "master" repository.
And as I rebase and cherry pick all the time, I figure it would really hurt revision numbers, but other DVCSes seem to have tackled this problem. I don't know how, and I haven't thought it through enough. Personally, I think it would be fine for me to say "10th revision since this tag" and since the commit history could change, the revision numbers could change because it could become the "15th revision since this tag". The SHA would remain the same as the revision changed. And remember: this is only a people problem I'm trying to solve (communication, inherit description of the commit without looking up the SHA, etc.) Also, other posters have helpfully pointed out to me git describe, which I think I'll take a look at and start using.
Interestingly enough, this is pretty much what we've setup. :) The build system tags commits.
One thing that another user has pointed out to me about Bazaar is that Git's branches aren't inherently objects, just commits. When creating a branch in Bazaar the branch itself has a name/label. When groking the git graph, unless a developer properly tagged those branches, it is slightly more cumbersome to follow what and more importantly why the graph looks the way it does.
Nothing... but I would like to flag the "master" repository to automatically do it for me. I think tagging everything is overkill. But in any case, our build system is setup to tag builds so we do have some semblance of this.
Perhaps with a small number of commits like your 13 example, this would work fine. But what about r32185? Are you going to sit there and count them all by hand?
Actually, other modern VCSs with revisions would use branch/tags to create the revision numbers. So it would be "mybranch.500", which means it's a revision in "mybranch", or "release1.5-200", meaning the 200th commit after release1.5. This also helps when using the blame tool to find out why a certain line was changed, as you could see that this line was changed for "somefeature" inherently (although admittedly that's a minor caveat).
In a project the scale of the linux kernel, a commit might be copied around a large number of repositories before finally being blessed by Linus or one of his lieutenants and included in the next release. In all of those moves, the commit id will not change. But the branch it has been included in, and perhaps even the order it was merged will change.
As I stated in the original post, this idea would only work with a "centralized" or "master" repository. And it would only be a convenience label; the SHAs would still exist as normal. The Linux kernel repository is not centralized.
I gave examples elsewhere. One example is communication with other people, as in when speaking or e-mails. Another example is when using the Blame... tool, you can see that this line was changed with "mybranch-3" instead of having to look up "ec09302930293".
For example, with a SHA hash I can be sure that a branch/commit/tag/file/repository that I have is the same that you have
Revision numbers only work with a master/centralized repository, and not with decentralized repositories as Git was designed for. However, I've never once dealt with a Git repository that didn't have a "master" or centralized repository. And if you could assign such a repository as the master one (which you can't do in Git now), the master repository could assign revision numbers.
when you clone a git repo, you get everything checked out anyway, so you're not saving any space at all. This isn't like SVN's sparse directory feature where you can checkout partial repositories, with git you (practically) have to check it all out to use all its useful features.
No. With Git you have the entire database in a compressed form, and only one copy of the file system checked out. With SVN, if you get the entire database, you have ALL file structures checked out, i.e. you have every tag and every branch present on your local hard drive. Yes, I understand that most people wouldn't check everything out with a large SVN repository.
Also, just go to any open source repository that has a mirror Git and SVN repository and check them both out (as I have done for various reasons). The SVN repository always takes up more space. For example, try libgdx... the SVN repository took up 33% more space on my hard drive.
If you're ever trying to use relative paths between branches (and trunk is effectively a branch), then you're in a world of stupid.
As I stated elsewhere, I also thought it was stupid. But the company did it because that's how all SVN is setup... use trunk/branch/tags directories.
No, but "I've tried to learn it and it so far has confused the hell out of me" is grounds for an argument that something is hard to learn.
I agree 100%. Many of my professional team members have fucked up with Git. That being said... I suspect the problems my teammates have had is because distributed VCS is in general harder to grasp than centralized ones, and so I think my teammates would have fucked up with the other DVCSs too. I don't have any professional experience with Mercurial or Bazaar, so I can't compare that aspect or back up my guess.
Except with a major difference: Bazaar gives you the ability to have both checkouts share the same database, so it doesn't take up twice the amount of space. Git doesn't let you do this -- you'll have to create two full copies of the repository. (Ironically, this accusation is often made towards Bazaar by people who haven't heard of shared repositories.)
This sounds like an advantage that Bazaar has. Personally, though, I feel like if you only want to checkout parts of a repository, then the repository is too big. Modules deserve to have their own trunk/branches themselves. Once again, just opinion - and my point is completely moot if you're dealing with someone else's repository that's too big.
It seems like things weren't set up very well.
It wasn't. I hated it. I argued against it, and failed. I think it's terrible that a person would have to manually copy stuff after checking out a particular tag/branch. But with Git (or other VCSs), one could have checked out any tags/branches and the directory path wouldn't have changed. That's the main point I was getting at... separate directories changes pathnames.
Aren't you assuming that both of the parents have tags? Wouldn't the user need to manually tag the commits to get that effect?
Yes. A stable release simply has to have a tag... if it doesn't, this is beyond a discussion of comparison of VCSs, because you wouldn't make a stable release without a tag or some sort of label. As far as the branch goes, also yes... if it is a non-trivial branch, then it should have a tag or a branch label (usually in the form of "origin/branchname"). In my professional experience, all non-trivial branches either had tags or the "origin/branch" branch was still in the previous commit line before the merge.
.... my main source of frustration is not that people tend to prefer Git over Bazaar, it's that a) they dismiss the other DVCSes out of hand without actually learning about them, and b) the usual reasons claimed for why Git is better are true of all DVCSes.
Totally hear ya. I think that Git is a stepping stone to the next better thing in 5 years. It has drawbacks which could be solved (and apparently some of which has already been solved with Bazaar and Mercurial... but I'm not going to agree yet that Bazaar is the "correct" way either, yet :) And yeah, people tend to think what they already use is better, even if it's not the case. Tons of psych studies about this topic.
So, I want to check in (and push) the source file changes, but not the solution and project file changes. And i don't simply want to ignore the solution and project files, i just don't want to *push* them. I still want them versioned locally. This sort of thing sucks.
I do understand your example... but I still maintain that you're just doing it wrong. You don't need to commit them at the same time. Just commit them separately. In another VCS, you would check them in separately if you wanted to do what you're talking about.
There's no getting around the fact that you need one command to check in or commit one set of files, and another command to do the same to the second set of files, in any VCS.
You also can't just get one file from a git repository like you can from svn.
This may be true... but I've never encountered such an example in my life. The only times I've gotten a single file was by browsing online repositories, and certainly never in a case where I actually wanted to check a file back in. But in any case, that's certainly an example of what SVN can do that Git can't.
In one word: communication.
Revision numbers make communication easier. There is no difference between "15.1" and "e209309fff0902930293302920" as far as a unique ID to a software program goes, but there is a difference as far as communication to people goes. A revision number called "mybranch.13" inherently tells me that it is the 13th commit of mybranch, and is also easy to communicate to another person. Going further, it helps with Blame... lookups which says "this line was changed because of "thisnewfeature.13" and hence "thisnewfeature", instead of having to make awkward lookups of "e203920390293039".
Not every commit is tagged... and it shouldn't be, because that is what commit messages are for.
There is absolutely no software problem that is solved by revision numbers, only people problems.
I think your points misses my point: I do like Git, but revision numbers make communication easier. There is no difference between "15.1" and "e209309fff0902930293302920" as far as a unique ID to a software program goes, but there is a difference as far as communication to people goes. A revision number called "mybranch.13" inherently tells me that it is the 13th commit of mybranch, and is also easy to communicate to another person.
Mercurial's most touted advantage is that it's easier to learn, but this is a joke. If you develop, you interact with the version control system all day. A tiny advantage in learning it faster is nothing compared to not being able what you want to do afterwards, or having to redo something because the version control works against you instead of with you.
I work at a company that has used Git professionally. My team isn't dumb people, but they have fucked up with Git dozens of times. What I quoted is an okay argument at a personal level. However, there is something to be said as an organization that having an easy-to-use tools is better.
I am not making the argument that either Mercurial or Git is better; I am making the argument that tools which are easier to use will lead to less fuck-ups in an organization.
Interesting.
I would argue to the old-school developers that there is absolutely, positively, 100% no reason to ever use CVS in 2011. There is absolutely no advantage that CVS has over modern VCS's.
(2) You can't check out just a subtree of a Git repository. This actually has cost me quite a lot of time when I had to take a repository that I later figure out was too big and split it up.
I HATED this shit with SVN, I wanted to check out the entire repository but it was just too big, so I could only check out parts of it. Now, with Git, I've changed to where I love the fact that I have everything on my local storage.
What I think is that the reason repositories were so big in the first place was because CVS/SVN encouraged it. With Git, if a repository is too big and you want to split it up, then the repository shouldn't have been so big in the first place! If bet that if there were never a previous incarnation of VCS before Git, then people wouldn't throw their entire company's portfolio into one big friggin' repository. For example, if you have modules that work together, and it makes sense for these various modules to be released in separate versions (i.e. 1.5 of feature1 and 1.6 of feature2), then you should have separate repositories in Git. And that's even if the build system requires both repositories... OK then, have it get both repositories!
(3) I will occasionally get the repository into a configuration where I don't really understand how to get it back to something I know. Usually playing with it for a bit will fix it. (4) It's easy to forget to push.
I don't think this is a Git vs other VCS problem... it's just a general problem. If you never dealt with any other VCS then you wouldn't have mentioned these points. With forgetting to push, I think it's better to forget to push than to accidentally push something you didn't want to, IMO.