|
ZevSpitz wrote: I'm curious to know why you feel that way about VB.NET
Because the name starts with "VB".
ZevSpitz wrote: which can express virtually everything that C# can; and like other .NET languages can make use of (almost all of) the types in the .NET Framework.
The words "virtually" and "almost" should be indicators for you...
ZevSpitz wrote: There are obviously various small differences (VB.NET allows inferring the delegate type, allows assigning a numeric string to a number, etc.)
"Inferring" and being typeless do not make VB a better idea. Unless you're a commie... or liberal...
".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
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Some facts: 
1. I am not a liberal or commie - in fact I think Atilla the Hun and Genghis Kahn were lily-livered pinko-liberal pooftahs.
2. I have written lots and lots of VB.NET - and got paid for it. 
3, I have a 50 foot yacht in the marina. Sadly, the marine police have removed my small armoury therefrom until such time as I leave.
Your move! 
|
|
|
|
|
Another VB fact:
I am retired on a tropical island in the Caribbean after 25 years of VB /VB.Net programming 
Who's next?
|
|
|
|
|
I'm not retired because I'm busy replacing VB-based crap-ware with C#.
".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
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
So I got the money using VB and you got the crap and problems using C#.
Who did better?
|
|
|
|
|
I still do some projects - just for fun.
So If you want, I can enlighten your burden and take the project from you.
That is - if it pays enough of course.
|
|
|
|
|
A fact you missed:
0) Real programmers know enumerated lists start with 0.
".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
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
And 3 facts you missed:
0. Real programmers don't care what language they use; because they are able to solve the problem in any language.
1. Smart programmers solve the problem in the way it is the least work and pays the most.
2. Really good programmers won't be used on projects where they have to fix the crap of someone else (that's where juniors are for).
|
|
|
|
|
Reminds me of a 16 bit mini I knew in the 1980s: Fortran arrays are 1 based. This machine had a 48 bit float format, three 16-bit words. The CPU had a special instruction for calculating the memory address of an element in a float array: MIX3 would add one to the accumulator and multiply it by 3. The instruction had no other use than for Fortran float array address calculations.
|
|
|
|
|
John Simmons / outlaw programmer wrote: Because the name starts with "VB".
Because you don't like the name? It seems to me your dislike is far to strong to be justified by this.
John Simmons / outlaw programmer wrote: The words "virtually" and "almost" should be indicators for you...
I was referring specifically to pattern matching and types that make use of Span<T>, which are both relatively new features in C# and .NET in general. Unsafe code is also something that C# has which VB.NET doesn't.
IMO, pattern matching is as much a game-changer as LINQ, in writing expressive code, and it is quite unfortunate that it is not yet in VB.NET.
But I think the others are relatively edge cases. Your average business developer, targeting a Web stack or desktop application, doesn't need the higher performance of Span<T>, or unsafe programming -- not in C# and not in VB.NET.
Are you aware of other differences in day-to-day usage? Please feel free to correct me.
John Simmons / outlaw programmer wrote: "Inferring" and being typeless do not make VB a better idea.
I think that inferring the type in general is a good idea (using `var` in C# or `auto` in C++), because the code becomes more declarative -- focused on the intent of the code, and less focused on the mechanism the code will use. It's true that when every byte matters, it may be important to specify the type as byte, but again, I think these are relatively edge cases.
But I didn't say I think these are good things; only that these are things that work in VB.NET and will not work when transferring this knowledge over to C#.
(In fact, inferring delegate types from lambda expressions might involve a serious performance hit. If I have a database with a million records, and I use an ORM to extract the records which match a certain condition:
Dim qry As IQueryable(Of Person)
Dim filter = Function(x As Person) x.LastName.StartsWith("A")
Dim results = qry.Where(filter)
this code will use the Enumerable.Where extension method (which takes a delegate instance and not an expression), retrieve all the records in the database, and filter them in memory in the application code, all without any error. C# will not allow this, and force you to explicitly type filter as Expression<Func<Person, bool>>.
The automatic conversion that VB.NET does from a numeric string to an integer is also a bad idea, because the conversion might sometimes work in odd ways, and can be exceedingly hard to debug.)
John Simmons / outlaw programmer wrote: typeless
Note that VB.NET is not typeless, it just treats the type Object like C#'s dynamic.
modified 12-Nov-18 11:31am.
|
|
|
|
|
ZevSpitz wrote: I'm curious to know why you feel that way about VB.NET
ZevSpitz wrote: VB.NET allows ... assigning a numeric string to a number
I think you've just answered your own question there! 
(Option Strict and Option Explicit should always be On. IMO, there shouldn't even be an option to turn them off.)
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Yes, they should always be on.
But C# still has the GoTo statement.
But that doesn't mean you have to use it
|
|
|
|
|
I even make use of it! In switch statements where two or more alternatives have the same (final) handling, it can be really useful, and far safer than the silent fallthrough of classical C (which is not allowed in C#).
It lacks a builtin ComeFrom, though; I had to implement that myself. It really is a must when you do more than the elementary exception handling.If you leave the stack dump to the standard library exception handling, you won't be able to pick up the output and process it in a reasonable way.
Of course you can't make a ComeFrom without support from the runtime libary. Given the StackTrace / StackFrame classes, it is trivial.
|
|
|
|
|
And so you see - everything has it use
|
|
|
|
|
Richard Deeming wrote: IMO, there shouldn't even be an option to turn them off.)
All of this is presuming that VB should be allowed to exist in the first place.
".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
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Then stop financing its makers - oh wait, they build C# too ....
Oh wait again - its even the same compiler and toolset ....
|
|
|
|
|
I did stop funding them. The last thing I bought from Microsoft was a MSDN subscription a number of years ago. That got me Windows 7 and VS2013. Recently, I migrated almost completely away from Microsoft at home. I still have a VM running Win7 so I can write Windows code with VS2017 community), but that's it.
".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
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Then there is only one thing left to do: find a job where you don't have to work with Microsoft either. If I see your rant, it would be really better for your heart.
|
|
|
|
|
VB pile of crap? Really? Funny how we see things. When I look at all the {{{{{}}}}} and ;;;;;;;;; in other languages, I feel sorry for all that syntax crap they have been born with. A lot of people like that sh*t though, so it must be some sweet crap..
Functionality wise, VB and C# for example visite the same barbershop to get their new identical look, ready to be swallowed up by the machine. So if you are not talking about syntax, then C# is in this case a pile of crap too. I doubt that.
|
|
|
|
|
When converting stringly typed data from a flat file into strongly typed data for database storage, nothing beats the built in conversion functions found in VB. In addition, VB.net's verboseness means I can look at the header of a function and know exactly what events and what objects those events tie to. In C# this wire-up is frequently hidden in another source file. Having keyword based blocking vs. {} for block controls also helps when working out the logical structure of code. Is that } going to the "if" or the "while" statement 30 lines up? In VB you'll see an End If or Loop so you don't have to guess when looking at the code on paper. Granted, VS's indent lines make this less of an issue now but prior to those indent lines it was an issue.
Where C#'s syntax is better is in the implementation of Lambda (anonymous) functions and LINQ syntax. VB.Net's syntax is just awkward here. I also prefer C#'s <> for type declarations for Dictionaries and Lists as it highlights the actual typing without making the New parameters confusing.
|
|
|
|
|
After using VB.Net for around 8 years, I have been using C#.Net exclusively for the past 5. There are two things I very much still miss about VB.Net - the first of which are those oh-so-hated-by-everyone-else verbose blocking keywords. ESPECIALLY when working at the end of a function or class...
[ Next / End If / End Select / End With / End Function ] is instantly easier to understand which blocks you are leaving, than [ }}}}} ] - even when on separate lines.
The second is the [ My. ] class - so much exposure to the underlying environment, user profile, settings, and resources... all in one API.
At the end of the day, I use C# just to keep fluent in what is arguably the more-widely-used language of the two, but I very much miss the good ol' days.
|
|
|
|
|
It takes manure to make things grow. Have you ever worked in VB? If not How can you criticize something you don't use? 
tired of the VB bashers …..
|
|
|
|
|
In point of fact, I've worked in every evil incarnation of it, but more importantly, I've worked with better languages, so I know from where I speak.
Even if I hadn't, I'm old, so I'm entitled to criticize anything I want.
Oh, and you can use your cute little disappointment emoji till the cows come home. I don't give two sh|ts about it. (I can say that because I'm old, too.)
".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
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
You are not the only "Old Guy". I am 70 in a few months. I have been working in Basic (GW-Basic) since 1978. I have made a very good living with it, and have happy clients running their businesses all over the Southeast and Central U.S. with my programs.
Being "Old" does not entitle you to anything, except the knowledge you will die soon. The emoji was for you, because you sound like a fan-boy millennial in your post.
BTW, I am converting my programs to C#, and have found it is more verbose,and does not handle Dates worth a cr@p. I'm doing that so when I finally drop dead at the keyboard, my clients will be able to find one of the younger guys around that know C# to support them. I notice you failed to mention any of the so-called "better" languages you work in. I'd be interested to know what language/framework du-jour you currently like.
Get over it, it's all just syntax, in the final analysis. The tool you use is not important, only the product you create
Oy! Haters gonna hate.
|
|
|
|
|
why do you think it's crap? is this from personal experience or is from from what others say it is?
from my personal experience (and i do have quite a few languages that i use from day to day) it's on par but not equal to C#, VB.net does somethings better than C# and vice versa. and at the end of the day they both compile down to the same IL.
i could say javascript is crap because it's an interpenetrated language and other reasons, but it does serve a purpose and does it well, so i wont.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
