|
The major bullet point in comparative languages is the ability to choose the correct language for the task at hand. Are you scripting on the web? Javascript. Are you writing image processing routines? C++ with some assembly. Writing Cross platform applications? Java (ok, up for debate) Writing data-driven business applications? C#. Natural Language processing? Lisp (funny, I know)
The point is, that for all tasks there are languages that are appropriate to the task, some better than others. Yes, 99% of the functionality of C# exists in VB.NET but we also, have to consider, in the business application domain, maintenance. Of course, it is funny, that whenever I response to a debate about VB or syntax, or style or basically any holy war I usually get some sort of ad hominem reply.
The reason I hate VB.NET, above all others, is that I have programmed in it and VB6, VB5 and VB4. I am by no means a master of all languages but very few VB.NET supporters program both (c# and VB.NET). [Hey, look, there I go with an ad hominem remark; I'm such a hypocrite]
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: if not foo is nothing and foo.Id < 10 then
end if
If you wrote it like this it would work:
if not foo is nothing andalso foo.Id < 10 then
end if
... VB.NET is not responsible for your lack of knowledge of its syntax.
|
|
|
|
|
Your lack of reading earlier replies is directly responsible for you making this post. It has been a decade (more? less?) and I am still put off by the decision to use andalso instead of and as the short circuit operator.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: Fourth, no one should have to wonder why this doesn't work:
if not foo is nothing and foo.Id < 10 then
end if Of course it doesn't work, it doesn't do anything between "then" and "end if"!
I do remember swearing mightily at the language when I was learning it, it was blowing up because I was overindexing an array and had checked the index values before the "and field[id] >5".
It's good to know the design considerations of earlier VB products went into such an idiodic practice. I really swore at it when I found out 8/3 was 3. What morons would design such dumb math? I felt a bit better when I found out 8\3 was 2 like it should be. Before that I was multiplying it by 3 and if the result was > 8 I'd subtract 1. All the while thinking this is such a stupid language.
|
|
|
|
|
I don't mind VB as long as I'm not writing/maintaining code with it.
Your example isn't an instance of "stigma in action". Your colleague is a retard which means its a clearer case of "cerebral inaction". Making everything public doesn't mean nothing will break, it just means that the programmer has nothing resembling a clue what object-oriented programming is all about, and he actually SHOULD be using VB6...
If I were you, I would subject EVERYTHING that idiot writes to the most stringent of code reviews.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Grow a skin, a thick one, you are always going to come across idiots who have a fanaticism for one product/religion/language/country, it is part of human nature!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I always found it funny as hell that the people who laughed at (the old) VB because it wasn't "type safe" are the same people who say absolutely nothing about the total lack of type safety in Java.
|
|
|
|
|
Huh?? You maybe mean JavaScript??
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Yeah, I did. I had an image of JS embedded in a web page in my head, but typed the wrong thing. My fingers can't keep up with what I'm thinking...
|
|
|
|
|
You can write un-type safe code in C / C++ / C# / Java etc - just use casting.
|
|
|
|
|
I don't consider type casting to be type unsafe operations.
There are certain rules that are enforced for type casting as well
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Oh, I thought he was talking about Java's hacked-on and very type-unsafe generics mechanism.
For example, try this:
private void test() {
List<String> list = new ArrayList<String>();
addStuff(list);
for(String item : list)
logger.info(item);
}
private void addStuff(List list){
list.add(new Object());
}
This will give you a compiler warning in addStuff, but that doesn't help you if the non-typed collection method is in another library. The code won't fail in addStuff, though; it will result in a List<String> that contains non-strings!
|
|
|
|
|
I agree with you. (But, then again, I use VB.NET)
|
|
|
|
|
One of the biggest problems with VB.net is that it attracts all the VB6 idiots, so a large amount of the VB code out there is written by idiots. After all, if you're not trying to pick a language that your monkeys could do, you'll pick C# over VB.net because the language is more concise and more full featured (e.g. writing lambdas or delegates in VB is painful).
|
|
|
|
|
Proposal - a series of "tests" (described below) to see who writes better code in both VB and C#. Beyond being given the requirements of the test application, no other information is to be provided regarding programming style, content, or anything else. It should be up to the participating programmers to write code as they see fit to satisfy the design requirements. Requirements should include mock-ups of screen shots. It might be a good idea to establish tangible quality indicators that each judge must use as a minimum in their decision making process.
Test #1:
0) Ask two programmers to write a moderately simple application in VB.Net. One should be an experienced C# programmer with experience in VB.Net, and the other an experienced VB.Net programmer with no exposure to C#.
1) Evaluate the two projects side-by-side without knowing which programmer wrote which version.
2) Identify each of the projects' respective author.
Test #2:
0) Ask two programmers to write a moderately simple application in C#. One should be an experienced VB.Net programmer with experience in C#, and the other an experienced C# programmer with no exposure to vb.net.
1) Evaluate the two projects side-by-side without knowing which programmer wrote which version.
2) Identify each of the projects' respective author.
The idea would be to more scientifically determine who writes the better code. Since "better code" is a subjective term, create a panel of three judges to serve as the evaluation team. They cannot discuss the projects amongst themselves,, and each places secret ballots, with a simple majority indicating the group decision.
To further eliminate chances of a lopsided decision, run both tests three to seven times.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Looks like a very reasonable research project. It would be great to have my theory proved.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
The biggest problem with VB is that it has too many design flaws.
I noticed that people who started programming with VB have difficulties to understand why others discredit VB.
C# has some design flaws too (says Anders Hejlsberg), but it is probably one of the nicest programing language ever designed.
|
|
|
|
|
I don't necessarily have something against VB. I love the language, but there's a few flaws... First of all, backwards compatibility with VB1 to VB6. You could argue this is really only Option Strict, which is off by default. You can turn it on and you're forced to write better code. Be that as it may, many VB programmers don't know about Option Strict. It allows for code such as the following:
Dim i As Integer = TextBox1.Text + TextBox2.Text It takes a more experienced programmer to see we've got a problem here.
However, I was told this kind of 'auto-casting' and 'type inference' was the default in VB6 and many programmers loved it. Casting and Parsing is a pain to them.
Unfortunately many VB.NET programmers still come from the pre-.NET VB era and still think having to think about your types is to much trouble.
Furthermore, a VB.NET Form ignores all rules of encapsulation. I've seen VB.NET code that instantiates a Form as follows:
Form1.Text = "Isn't Text Public, not Shared!?"
Form1.Show What the...? I've spent quite some time looking for a variable called 'Form1', but it simply didn't exist! Text and Show can be called as if they were Shared. Backwards compatibility with VB1... Of course C# came after VB1 and I guess Microsoft learned from their mistakes with VB to make C# a 'better' language.
In short, VB can do everything C# can and more (but also less, for example VB has no 'unsafe' code blocks). It's more the pre-VB.NET mentality that makes a lot of VB programmers frowned upon and I must sadly confess it's not completely unjustified.
However, I've seen C# programmers who made a mess out of things too. You can write bad code in any language and VB is no exception.
When you're dealing with a skilled VB programmer who knows what he's doing all the above does not apply and I'd have to say VB is just as good as C#. I prefer VB syntax, but that's personal
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
|
|
|
|
|
Keep in mind that I am an ex-VB programmer. The stigma is illogical, however, one thing that gets me is that it allows you to get things done without ever challenging your knowledge (I was guilty of this, I only learnt OOP when I moved to C#). The problem with VB isn't the top-end it's the bottom-end.
It's not that VB programmers are worse than any other programmer, it's that that some are (wait for it) because the language facilitates it (prior to VB.Net, basically required it). Take two **bad** programmers, one C# and one VB - get them to write a decently-sized program: the VB guys will polish it off long before the C# guy. Now ask them to change it quite drastically and watch the VB guy sweat. (On the other side of the coin, there is no difference between a good VB developer's program and a good C# developer's program).
You can be truly efficient in any language but you can only be absolutely horrible in a couple. For people that worry about the quality of the code sticking to devs who use C# is the safer bet: there is just less risk - the bottom-end is more competent (although still pretty horrible, to be honest).
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chinese Proverb]
Jonathan C Dickinson (C# Software Engineer)
|
|
|
|
|
Personally, without checking the other comments first to bias my opinion on, VB.NET isn't THAT bad, but I still don't like it.
VB.NET was my first programming experience. It was the first language I learned about 6-7 years ago, and I did my fair share of initial learning how and why things were as they were in it.
Eventually, both from peer pressure and pure interest I started to experiment with C#, and fairly quickly I started really liking it. It just felt more logical to use curly brackets to mark down your code instead of new lines and verbose words, but I also remember back then (could've been me, it was my first programming experience after all) that when I ran into problems with VB.NET and tried rewriting the project in C#, it worked better in C#, without the flaky behavior.
Now before all of you are going to yell "But MS IL! That's impossible as it gets compiled to the same bytecode anyway!" there's still 2 different compilers here, one for C# and one for VB.NET, and perhaps the syntax gets translated differently? Anyway I'm talking about 6-7 years ago here, back then .NET 2.0 was the new kid on the block and perhaps MS has fixed things since then.
But personally, even though VB.NET was my first language, I really prefer C# between the .NET languages.
And I also tell everyone who's doing VB.NET to at least try to get acquainted with C#. Why? Well, C#'s syntax is much less arcane than VB's, and can prepare you for maybe trying C or C++ some day. After all, framework languages are cool and all, but in some businesses, those low level languages really are where the party's at. So if you really want to do .NET, why not do the most widely used, least arcane one?
|
|
|
|
|
Maybe its worth asking him if he has a file with all of the global functions "everything needs to use" lol, I started with VB6 and occasionally play around in .NET, there not poor languages, they have event-driven and best of OOP and alot of people wanting to quickly prototype things often write them in VB(.NET or 6). While I do syntactically prefer C-style programming (not low level just curly braces, strong typing, familiar type names), but recently I have begun playing in VB.NET again as I have been writing some BASIC code for my rPi and wanting to quickly get to grips with windows8
|
|
|
|
|
I think the problem with VB has always been its accessibility. It's so easy to use compared to, say, C++ or even C# that the price of admission is really low. This has meant a lot of non-programmers have used it to write poor, unstructured code - mainly due to a method of designing whilst coding. I've come across this kind of thing many, many times in the VBA arena particularly.
On the other hand, its ease of use for a disciplined programmer means you can get 'stuff' done in it quickly. You can prototype an outline of an application easily.
The tool itself is fine, it's just another way of describing your solution to a problem to the machine. Its ease of use is one of its greatest assets but is also a large contributor to it getting a reputation for buggy, spaghetti code.
Personally, because my first 'real' language (after Sinclair Basic) was C I find C# easier and more expressive (of the .Net languages). But c#, vb both end up as the same MSIL code going into the .net virtual machine. The differences between VB and what the critics call "proper" languages are teeny tiny.
|
|
|
|
|
Just about to celebrate 16 years with my present company - hired from another company to fix a problem and whipped up the application (ship tracking) in VB5 in a month or so. 16 years later and a few million in revenue from the product and supported 15 staff for that period I am now re-writing it in VB.Net for the next 16 years.
People can have whatever attitude they like - I have electronics background but learnt VB from a book and it has kept my family and I fed and clothed, along with all my staff.
|
|
|
|
|
Two points:
First, VB is a verbose language, no doubt about it, but that actually works in its favor for people who don't program all the time. Making fun of VB is like an army guy making fun of my 30-06 bolt action rifle. Well, dude, I'm not shooting people. I don't need the same tool. In fact, I appreciate the simplicity of it because I don't use it everyday.
Second, language without framework is meaningless. We'd all program in Scheme/Lisp if there was a framework out there worth a dang. The stigma is typically against .NET rather than some funky open source flavor of the month. And from what I've seen, the tools which are provided free for the frameworks like Spring, Struts, are uneven and spread out all over the place. Again, if that's what you do, and you work with a team, you can track those things down and create a tricked out mousetrap.
At the end of the day, the success of VB.NET is really me, because I've been able to set up intranet applications, desktop utilities, and design calculators which are actually useful despite being an engineer by trade. Sure, I had C, QBasic, Java, and Unix shell programming in college, but in order to do anything useful, you have to spend the time learning what you need and building up your tool chest. With .NET, your tool chest is pretty much dumped in your lap, and supported by a consistent and well funded development community.
Without that, I probably wouldn't be as effective, because I'd be bogged down trying to figure out Eclipse, Ant, Maven, and Tomcat. And then once I had a handle on that, I'd have to decide my implementation for a web app: J2EE, Spring, MyFaces? Should I swap in an ORM like Hibernate? Well that means JBoss... wait, what's JBoss? You get the picture.
|
|
|
|
|
Part of the problem is it's name: basic. BASIC goes back ... well, a long time and was pretty basic. I don't want to go into detail on it, but the BASIC from the 70s and 80s was terrible. Another part of the problem is there have been many basic programmers - who should not have been programmers - who wrote a ton of awful code [I was there, I had to deal with it] because they could; it was basic. They lent a bad name to the language. It's history, Dude - give it time. Maybe by 2030 the c# guys will forget
|
|
|
|
|