|
LOL
You're gonna hate me, but none of my generated code ever has Finalize() methods unless it's only C# and not the codedom.
but lately all my generation code has used the codedom, just so I can support VB
to be honest i don't even know VB syntax.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: You're gonna hate me, but none of my generated code ever has Finalize() methods
Why would I hate you for that? 
I've never written a finalizer in my life... Or thinking back on it, once, maybe.
honey the codewitch wrote: to be honest i don't even know VB syntax.
To tell you an uglier truth, I do 
|
|
|
|
|
I know VB6 and VBScript pretty well as a matter of necessity in the bad old days of microsoft land when every idiot fine programmer out there was using it to write bad software. It was usually my job to try and fix it, which really meant gleaning the functional requirements from undocumented source code and then rewriting.
Since .NET i've seen little of it, and I've had no use for VB.NET.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Sander Rossel wrote: To tell you an uglier truth, I do
And what's the problem with that?
Are you becoming a snob as well?
|
|
|
|
|
Jörgen Andersson wrote: And what's the problem with that?
You wouldn't be asking me this is you saw the VB code I had to work with 
I used to love VB.NET, even after I started doing C#.
But after years of doing C# I now have to use it again and it's just lagging behind in pretty much everything.
The fact that Option Strict is off by default (causing much of my current problems) makes it bad by default.
Sub and Function As Object (or worse, just Function without an As clause because that's optional without Option Strict) feels weird.
The default indentation in Visual Studio sucks.
If something AndAlso
somethingElse Then
DoSomething()
ThisIsAlsoAFunction
End If Keywords like End Function, AndAlso and OrElse are unnecessarily long.
Don't even get me started on lambda's! collection.Where(Function(x) x.Something) vs. collection.Where(x => x.Something)!
Meanwhile, shortcuts like inline ref variables don't make it to VB.
Because it's not case sensitive myVar and MyVar are the same, meaning I sometimes need to think just a bit harder to name my variables.
Static classes don't exist, you need a Module, but that's slightly different (in that functions become public without the need of using the class name) making a Private Class with Private Sub New() the closest to a static class.
And please don't use the default VB namespace Modules that are imported by default!
If I'm honest, I've never seen good VB code that I didn't write myself, while I've seen some good C# code.
Microsoft is quickly dropping support for new platforms and VB.
It's only just been added to .NET Core with version 3, together with WinForms support.
Try finding (good) code samples for VB online.
Even newer Visual Studio functionality, like code cleanup, is not available for VB.
All in all, I have no reason whatsoever (or even a choice) to use VB in any modern software development.
Let me end with a small positive note for the language I started in.
One thing VB does right (in WinForms development) is Sub MyButton_Click(sender As Object, e As EventArgs) Handles MyButton.Click, which I find more clear than the C# way of adding a handler in the designer.
|
|
|
|
|
Sander Rossel wrote: The fact that Option Strict is off by default
Major f***up, agreed.
Sander Rossel wrote: The default indentation in Visual Studio sucks.
So, do you prefer Allman, K&R or Whitesmith?
Sander Rossel wrote: Keywords like End Function, AndAlso and OrElse are unnecessarily long.
Those aren't even very long.
Sander Rossel wrote: Because it's not case sensitive myVar and MyVar are the same
Here I have to really disagree with you, having two variables like myVar and MyVar isn't just against MS naming convention, it's also honestly quite stupid. I've seen more than one bug coming from this.
Sander Rossel wrote: If I'm honest, I've never seen good VB code that I didn't write myself
There are two ways I can take that, and in either case I believe I have to take offence.
Sander Rossel wrote: Microsoft is quickly dropping support for new platforms and VB.
Try finding (good) code samples for VB online.
Agreed, this is also the reason that I've been using mostly C# for quite a few years
Most of the rest you bring up is just general whining.
You're becoming an old git. How does it feel to be so young and already being older than me?
Soon enough you're going to change your name to OriginalRosemary, f*** no, OriginalRossel, no, still wrong. SROP, yeah, that's it!
|
|
|
|
|
Jörgen Andersson wrote: So, do you prefer Allman, K&R or Whitesmith?
I didn't even know this existed! 
It seems all but Allman are pretty messed up 
Jörgen Andersson wrote: having two variables like myVar and MyVar isn't just against MS naming convention, it's also honestly quite stupid
Property MyProp with backing field myProp, MS uses it too 
The _myProp style was disbanded by MS in VS2010 I think, at least in C#.
It's really not that weird.
In C# I never need backing fields because all my properties are auto-properties.
Of course, in VB, support for auto-properties is limited so I still need them from time to time 
Jörgen Andersson wrote: There are two ways I can take that, and in either case I believe I have to take offence.
I guess you should take it as "Sander hasn't seen my code"
Jörgen Andersson wrote: Most of the rest you bring up is just general whining.
I can live with the verbosity, but when you ask me what's wrong with VB I'm going all out 
The incomplete tooling compared to C# is something I blame on MS.
Jörgen Andersson wrote: You're becoming an old git. How does it feel to be so young and already being older than me?
You young folk get off my back, you hear! 
Jörgen Andersson wrote: SROP, yeah, that's it!
That made me laugh, but... Not in a million years
|
|
|
|
|
Sander Rossel wrote: It seems all but Allman are pretty messed up
And there you parted with OG.  He's diehard Whitesmith.
Sander Rossel wrote: Property MyProp with backing field myProp, MS uses it too
And they use m_MyProp and _MyProp as well. I didn't say they live according to their own rules.
Sander Rossel wrote: The _myProp style was disbanded by MS in VS2010 I think, at least in C#.
I think it was still around 2013, those rules change every few years anyway.
Current rules states no prefixes and no underscores at all, but they also state that fields should be Pascal cased, and that naming should avoid confusion. And at least the last part makes proper sense no matter what. Especially since the same name with different case also tends to confuse intellisense.
Sander Rossel wrote: in VB, support for auto-properties is limited
Is it? Works fine for me since long.
And another comment on your previous post: You shouldn't blame the tool for the tools using it.
If VB goes out of fashion they will just start using a different language.
It seems at the moment that C# isn't it, but rather Javascript and Python. Or whatever is taught in the schools at the moment.
|
|
|
|
|
Jörgen Andersson wrote: And there you parted with OG. He's diehard Whitesmith.
I don't want to hang around such psychopaths anyway
Seriously though, you'd have to change all the Visual Studio defaults and anyone working with your code after that will curse you for doing so
Jörgen Andersson wrote: but they also state that fields should be Pascal cased
Fields Pascal? Where did you find that? I always camelCase them and never seen different.
Intellisense works fine for same name variables that are differently cased, at least in C#
I don't think I do it a lot though, but I wanted to do it in VB because of the auto-property issue I mentioned.
I also use it when, for example, I have a property MyResult and then in a method I calculate myResult in a local variable.
Jörgen Andersson wrote: Is it? Works fine for me since long.
Try to set Public ReadOnly Property MyProperty As String (there's that verboseness again).
I figured it out, you have to set the invisible field _MyProperty 
Jörgen Andersson wrote: You shouldn't blame the tool for the tools using it.
I'm not sure what you mean, but I never blamed tools.
I blame VB programmers for writing abysmal code
|
|
|
|
|
Sander Rossel wrote: and anyone working with your code after that will curse you for doing so
I wouldn't curse you, only turn passive aggressive and think you're stupid.
Sander Rossel wrote: Fields Pascal? Where did you find that?
Names of Type Members | Microsoft Docs[^]
Note though something I didn't notice yesterday: design-guidelines wrote: The field-naming guidelines apply to static public and protected fields. Internal and private fields are not covered by guidelines
But guess how the private invisible backing variable to the autoimplemented property looks like. Also in C#. 
So even if they removed that guideline some years ago, the compiler still does it.
|
|
|
|
|
Sander Rossel wrote: One thing VB does right (in WinForms development) is Sub MyButton_Click(sender As Object, e As EventArgs) Handles MyButton.Click, which I find more clear than the C# way of adding a handler in the designer.
Just don't look at the generated code.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
That's the point.
If I want to remove a handler in VB I just remove the handler and be done with it.
In C# I have to visit two places and if I remove just the addhandler I'm left with some handler that's never triggered!
|
|
|
|
|
no typedef!
dt = new KeyValuePair<KeyValuePair<CharFA<TAccept>, CharFA<TAccept>>, RegexExpression>(
new KeyValuePair<CharFA<TAccept>, CharFA<TAccept>>(
dt.Key.Key,
dt.Key.Value),
tt[dt.Key]);
I want to make the C# language team have to declare things like this all day long.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
using KV = KeyValuePair<CharFA<TAccept>, CharFA<TAccept>>;
|
|
|
|
|
Doesn't work. Using requires hard types. It can't use the type parameter TAccept
FOr it to be able to do that it would have to work like C++ where typedef kinda runs like a preprocessor macro (as do source templates)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Mmm... Like Harold said, compiles for me!
using System;
using ListI = System.Collections.Generic.List<int>;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
var f = new ListI();
f.Add(1);
Console.WriteLine(f.Count);
}
}
}
|
|
|
|
|
That only works because int is a hard type.
You can't use using with type parameters.
You cannot do using ListT = IList<TAccept>;
You can in C++ because template stuff basically works like source macros internally, which means they don't have to "resolve" type parameters, they can just preprocess/replace them in whatever context they're used in. C# does not treat generics like source macros so it cannot do a C++ style templated typedef
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Mmmm.. you mean typedef can't be generics, didn't you?
ha well... true that...
On a side note, one that is only vaguely relevant. When generics got out I went all out on generics... and my code became an increasingly complicated and unusable bag of noodles...
Then I realised generics are better when used in moderation!
Works for me, at least!
|
|
|
|
|
Unfortunately, when doing functional style programming heavy use of generics is pretty much unavoidable.
C++ does so much better at this kind of thing. I wish C# would add "template" to the language and allow you to do source style templates like C++ as well as generics (which are binary)
Source level templates are simply far more flexible. You can do things like that typedef, you can do things like get the compiler to make complicated calculations like generating parse tables at compile time (see the Spirit C++ parser framework for an example), and you can do partial template specializations and just all kinds of things you'll never be able to do at the binary level.
It's unfortunate. I love C++ for this stuff. I wish other languages had it.
Ironically, Java/J2EE comes close with their templates, since they are source level but they are so poorly architected that they're a bad joke.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
You can use an interface for TAccept to represent a wide variety of types, am I right? Albeit it is more restrictive that a completely wild symbolic type ...
|
|
|
|
|
No, because the whole point of TAccept is it can be a value type like int, or a reference type like string.
It has to be a basic type so it can be serialized to code via System.CodeDom.CodePrimitiveExpression or via an InstanceDescriptor in the worst case. I don't want to have to force the user to declare a type for TAccept. It should be able to accept intrinsic types at face value.
Worse, one of the main points of generics is accessing value types without boxing/unboxing. If I access a value type by interface, I take the boxing hit anyway, and there's almost no reason to use a generic at all versus using System.Object at that point. Boxing in a lexing routine needs to be avoided because it's a tight, performance critical operation. It's one of the few areas where bit twiddling to get some extra speed is worth it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
OK, I see what you mean. The C++ generic codes are sources for the C++ template concrete code generator whilc C# generic codes are concrete ones in themselves, therefore it could be harder to achieve what you are looking for ...
|
|
|
|
|
That's precisely it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
public class MyKvp<TAccept> : KeyValuePair<CharFA<TAccept>, CharFA<TAccept>
{
public MyKvp(TAccept key, TAccept value) : base(key, value)
{ }
}
public class WhateverTheHellThisIs<TAccept> : KeyValuePair<MyKvp<TAccept>>, RegexExpression>
{
public WhateverTheHellThisIs(MyKvp<TAccept> kvp) : base(kvp)
{ }
}
var thing = new WhateverTheHellThisIs<TAccept>(new MyKvp<TAccept>(dt.Key.Key, dt.Key.Value));That should solve of the verboseness and greatly improve readability.
Although I think I did that slightly wrong, but you get the idea
|
|
|
|
|
Yeah, that's not practical. I use too many different combos of generics. I'd have zillions of one off types, and that actually makes things less maintainable and less intelligible. At least with the templates they are using well known types, and a limited number of them.
welcome to functional programming w/ generics - something C# is *almost* good at.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
