The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
"I say this not because I have any prejudice against VB.NET, but, because I think Microsoft truly created a mutant monster when they adapted VB6 to VB.NET, and the awkward and obscure syntax, and constructs, they added to the language to force it to fit into an object-oriented programming universe, is a spaghetti-verse of syntax that makes learning/using it much more difficult than, for example, C#."
You are so far off the mark there your comment is laughable. VB.Net is a completely different beast to VB6 or VBA. Geez, its been ten years since VB.Net was released, when will people forget VB6 and move on from their noob like prejudices! VB.Net is OO from the ground up. It has more in common with C# than VB6!
I am a self taught VB developer. I learned basic programming concepts in high school in the 70's and learned Fortran in college in the early 80's. I recommend this series of video tutorials if you are interested:
I dislike the Visual part of Visual Studio, because it hides too much complexy that a novice programmer need to know to fully appreciate the Visual benefits, having said that, VB is a simple language that is as close as possible to speaking to the computer and telling it what to do, other language of that kind is Pascal (The Delphi variants are my favorites), so you may want to take a look at it if you have time.
I recommend you to start with simple console apps, then start building simple Winforms apps from scratch (without the visual editor), and then go ahead using all the tools that Visual Studio offers you. Also, writing pseudocode in a piede of paper may help you to organize your ideas and get the logic you need to program efficiently.
I feel the pain! I was in the same position in 2001 when switching to VS C#. I use google to find examples and help (forget about MS help system). For example: a search on google for ListCollectionView will show a good list with examples from all corners of the world. If MS shows up first, I check it out but scroll down through the members list to the examples. Mentally, in 2001, I said to myself "this stuff looks like Greek to me but a year from now I'll understand it." It worked. Now it's all about design, coding is more about the never ending challenge to keep things "clean" and "tidy". I also purchased at least $1,000 in books over the first two years. If you want a really good beginners book on WPF and MVC try "Teach Yourself WPF in 24 Hours" by Eisenberg and Bennage. It will point you in the right direction and get those "little grey cells" electrified! Buy older books from Amazon "used" for a fraction of retail. Good luck and Cheers!
Keep at it. I personally prefer C#. There's only one thing I really dislike about vb.net and that's no built in intellisense. (It has no problem using it, but no way I found to create it and the documentation expressly says it isn't supported, so I doubt I missed the nook where it works. Anyone who would call you a n00b for using vb.net is a n00b in programming. Be sure you understand the underlying OO concepts that built C++ to begin with.
OK, I'm no expert at all in version control and maybe 'I just don't get it', (whatever it is), but for love nor money I can't understand how something that's so hard to use gained so much traction so quickly when alternative systems that also have the distributed advantage, are also OS, have better UI options etc. etc. are freely available and are also actively developed etc.
Maybe Git just doesn't fit the way my head works but I've seen so many similar comments and there are so many sites offering basic guidance on how to do the most simple things that I'm certainly not alone!
If you need to explain in that level of detail how to use one of the most basic concepts then something can't be right.
Really, the learning curve is just steep at the entry level. Once you are in the club, it gets easier.
for love nor money I can't understand how something that's so hard to use gained so much traction so quickly when alternative systems that also have the distributed advantage, are also OS, have better UI options etc. etc. are freely available and are also actively developed etc.
I have become familiar with about 5 VCS products, and really every one of them has advantages and disadvantages that are somewhat unique. The best one I used was a company-proprietary one which has many features none of the commercial ones have. Git got traction right away because it was designed and written by a popular developer who had a lot of clout in the unix/linux kernel.
I'm also not a fan of a UI on a VCS. I prefer doing source authorship in an IDE but source control in a command window.
Really, the learning curve is just steep at the entry level. Once you are in the club, it gets easier.
I've always imagined that would be true but unfortunately I don't use any of them enough to get that familiar, so I am biased to something that's easy to use for the basics (Hg) and has a UI (TortoiseHg) so I don't have to remember command line instructions and switches I haven't used in several days / weeks.
Advantages / Disadvantages - Absolutely, but if your needs are very simple you don't notice the advantages when something you need is a disadvantage (learning curve like the Eiger).
So maybe I should change the title ...And that's the problem with Git for Basic Users / Noobs / Beginners. Perhaps we're not their target audience.
I prefer doing source authorship in an IDE but source control in a command window.
Nothing wrong with that, but considering the many things that you can do with a VCS but rarely ever use, I'd rather not have to learn every single command that there is, or else have to dig the manual for half an hour just to find out the exact syntax, then go and try in the sandbox to make sure I'm not messing up my working copy.
Also, even pro-GIT-users admit that the commands themselves are unintuitive and suffer from inconsistencies. If I absolutely have to use the command line, I'd rather have one that makes sense.
Git is THE most non-intuitive, syntactically klunky (command line, really???) version control systems I have ever had to use. It is confusing, non-intuitive, and frustrating. On numerous occasions I have sat down with the intention of getting productive work done, only to have wasted 2 hours trying to figure out how to get the latest remote commits downloaded onto my local repository, finally giving up, deleting the entire folder, and re-cloning the entire repository.
After my Git rant of a few weeks ago, one poster kindly suggested SmartGit/Hg[^] which I downloaded, tried out, and found to be a life saver, and promptly purchased.
So yes, that interactive tutorial is absolutely necessary. I still don't fully understand the nuances of branches, commits, stages, stashes, and all the other complexities and bizarre command line syntax nuances that Git forces you to learn -- life was NEVER this complicated with SVN, CVS, or any other version control system I've ever used, going all the way back to RCS in the days of DOS. Happily, SmartGit takes a lot of the pain of Git out of the process.
Furthermore, while I understand that people rave about distributed source control, I still do NOT see the point. If you want to share your work with others, you still have to commit to the remote server. I've never in my life needed the complexities of local commits and branches.
In my ever so humble opinion, Git solves problems that exist only because Git creates the problem to begin with! Stashes are a great example. I've never in my life needed to use a stash, but stashes exist to solve a problem created by distributed source control, so we have a complex solution because of a "feature." Makes little sense to me. "Cherry picking?" In SVN, that was as easy as right-clicking on a file, reviewing the commits, and picking the version I wanted to extract. Git seems to make simple concepts into demons of complexity.
And one final note -- Git's merge, when I had to use it to merge two branches that had evolved over several months, broke a lot of code. In fact, on several occasions, it did some very stupid and inexplicable things, requiring hours of hand comparing to figure out what the merged code should look like (there were probably 50 of these WTF merges to deal with.)
And for the Git lovers out there, apologies for being harsh and possibly speaking with my head up my arse. Git, until I was pointed to SmartGit, was constantly getting in the way of my working productively, and therefore it takes a lot of heat. Now that I'm using SmartGit, I now have a series of simple steps that I perform to commit my stuff and to check it out on my other computer. Why it should be any more complicated than that is beyond me. Yes, some people say that Git really shines when working with large teams, but I have my doubts. Mercurial is supposed to be far superior.
Git is THE most non-intuitive, syntactically klunky (command line, really???)
I'm one of those people who likes to use git on the command line - I can specify exactly what I want to do very quickly, especially since I use it within Powershell. But then I'm one of those Powershell command-line nerds, so maybe it doesn't count...
When it comes to browsing source and viewing diffs, a UI wins hands down though - but I use a combination of a merge utility and the online viewing capabilities that most git hosts have to achieve that. If you want a UI that does everything then yes, SmartGit wins for sure. I just find it to be quicker and simpler to use the command line for most git operations.
Marc Clifton wrote:
In my ever so humble opinion, Git solves problems that exist only because Git creates the problem to begin with! Stashes are a great example. I've never in my life needed to use a stash, but stashes exist to solve a problem created by distributed source control, so we have a complex solution because of a "feature."
I like distributed source control and the fact that I can check in my code from anywhere, internet connection or not (I have numerous times checked in code for my own purposes while in the middle of a flight), and only push when I get my code to a point where it's ready to do so. Stashes are pretty useful when you need them but often not necessary (and you don't have to stash just because the command-line text suggests it as a possible resolution).
Marc Clifton wrote:
Git's merge, when I had to use it to merge two branches that had evolved over several months, broke a lot of code. In fact, on several occasions, it did some very stupid and inexplicable things, requiring hours of hand comparing to figure out what the merged code should look like (there were probably 50 of these WTF merges to deal with.)
I have seen that on occasion - there are a few bugs here and there in the merge engine that have made me seriously ticked off on the not-so-frequent occasions they have popped up.
Marc Clifton wrote:
Yes, some people say that Git really shines when working with large teams, but I have my doubts. Mercurial is supposed to be far superior.
We used to use Mercurial where I work (team of 5 devs working on the same code) and we found it too limited. But then what works for one person may not work for another - you may find the simplicity refreshing, and it may not bother you that it lacks features if you never use those features anyway.
So it's not just beginner's like me who find Git to be shrouded in an impenetrable fog of confusion, as someone said above I'm sure that Linus' support drove the early adoption but for why so many other folk have trudged through the pain of that fog to arrive in a place that is neither worse nor better, just different, I don't know. There must be something other than weight of users that makes Git popular enough to overcome that learning curve, it must be giving folk something they really really need, else Hg would seem to batter Git at every turn and MySpace users would become Facebook users. I doubt I'll ever get through said fog to find out, Hg it is then., smile the contented smile.
There must be something other than weight of users that makes Git popular enough to overcome that learning curve,
The only thing I think that is the cause for its popularity is the geek factor, and it hits several geekoid buttons -- it's:
1. newish and shinyish (anything to make life more interesting for a while) 2. arcane. Geeks love arcane complexity. It's something to yammer on about over cubicle walls, like Design Patterns was in the 1990's. 3. *nix love it because it doesn't need a UI
Me, I use the following aging curmudgeon rules:
1. do I have a problem that it solves? NO 2. do I think it can make my life easier even though it has an initially higher level of arcane complexity? NO 3. does the documentation make sense if I read it while playing online poker and surfing Code Project? NO 4. does the documentation make sense if I focus 100% of attention on the docs? NO 5. is it command line? YES - ok, back to the 1980's. I will NOT waste my time on something that does not START with a UI.
That said, I'm using it because my client is using it and my client is doing cool things and I, well, I'm also a geek!!!! (but I will never use it on any of my personal projects.)
I never understood people's obsession with the command line. I think that under virtually every circumstance, a well organized and well designed UI is always easier to pick up and more productive to use. Certainly more work to develop as well.
Whenever I have any significant amount of work that needs committing, it is way nicer to see the list of changes in a UI so I can explicitly see unversioned files, right click and quickly add an ignore pattern if I need to, see if I accidentally changed a file I shouldn't have, double click an entry to pull up a diff easily, etc.
I'm a bit of an intuitive design nazi so IMO the command line should be reserved for 1% functionality that is rarely needed.
Agreed on all your points. If scripts are useful then your program should certainly be scriptable. As for the rest, yeah, I made the point that it's a lot harder to code something with a GUI front end, especially if its going to be GOOD
I can understand v0.9beta being CL-only, but after that a respectable tool with any amount of complexity it should have a nice intuitive GUI driving it.
I personally like to split my tool projects into a core assembly that has all the functionality, and then reference that from a CL exe and a GUI exe so that none of the UI bloat gets loaded if you are just scripting it.
If you do not get it then you do not need it. However, people are likely to do what they should not. Some other people see that as a business opportunity, not a nuisance. This is why there are so many "sites offering basic guidance". Is is OK and even advisable to visit that sites for 2 reasons. First, if your circumstances change and you need something like GIT, you will know where to get it. Second, GIT is based on a set of ideas that may be used differently elsewhere and ideas are digested subconsciously as soon as you see them. Unfortunately, many sites offer recipe based advice which is virtually useless.
Last Visit: 31-Dec-99 19:00 Last Update: 28-Mar-17 11:24