|
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.
|
|
|
|
|
Matt McGuire wrote: why do you think it's crap?
Because of the first two letters in its name. I thought I' made that clear.
Matt McGuire wrote: i could say javascript is crap
And I don't personally know a single person that would argue with you on that point.
Matt McGuire wrote: but it does serve a purpose
Only because we let it serve a purpose.
Y'all really need to stop arguing the point. It's crap, and I absolutely won't change my mind.
".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
|
|
|
|
|
I used to be like you years ago, but after a couple decades of coding, i have learned to be more flexible in what i use to get the job done.
John Simmons / outlaw programmer wrote: Because of the first two letters in its name. I thought I' made that clear.
by the sound of it, you haven't used it, or at least not enough to see some of the benefits that VB.net offers that differentiates it from C#.
C# and VB.net are both good languages, and they both have their strengths and weaknesses. I use them both, and ADA, javascript, c, c++, D, Rust,HTML and a few others i dabble in; they all have their own uses.
if you want to bash on VB6 go for it, that should have died over 10 years ago. but VB.net is not VB6
|
|
|
|
|
Matt McGuire wrote: by the sound of it, you haven't used it, or at least not enough to see some of the benefits that VB.net offers that differentiates it from C#.
Once again, and for the last time, I *HAVE* used VB.Net, and it is still crap, just like it's predecessor, VB6.
Matt McGuire wrote: if you want to bash on VB6 go for it,
I suppose I could equate that with "divine dispensation", but I didn't need it to start with.
VB apologists make me laugh out-f*ckin-loud...
".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
|
|
|
|
|
Look I'm not here to convince you otherwise, you have your standpoint and i will respect that, even if i don't agree with it.
My only request is to not bash on others for their personal preferences. if there was constructive criticism over a language feature, I have no issue with, but to say something is just "crap" is not helpful and will lead to angering others for no purpose what so ever.
|
|
|
|
|
VB is used in-house, making the software carrying the company forward.
C-ish languages used by experts, for boxed software, and for contractor work, carrying their company forward.
|
|
|
|
|
I would debate that, this stems from the old long debate of VB6 vs. C++.
I use to develop industrial control systems that controlled directly to the IO with VB.Net and had several hundred installations. the difference between c# and vb.net is not a lot. both are good languages, and both had good features, both have their own benefits, what it actually comes down to is do you prefer "{}" or "if, end if"; it still compiles down to the same IL.
|
|
|
|
|
13 is the age when one should be moving from VB to a programming language. No later than puberty.
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
