-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Independent VB development team? #492
Comments
P.S. I want to make clear that I'm not trying to disrespect, discourage or blame the current Microsoft developers working on VB.Net. I don't think Microsoft's quietly shoving VB.Net to the side is their fault. I'm sure it's a decision being made higher up the corporate ladder. |
My biggest concern was the closing of VB Prototype "Checked expressions"
I don't want to see a fragmented VB language and comments like that and this topic will lead to that. |
I don't want to see a fragmented VB language either... But if Microsoft is not going to keep it current with new technologies, then what choice do we have? As I see it, the only other options are to A: learn another language, or B: accept being relegated to merely supporting what will become "legacy" applications. I don't find either of those acceptable when we have a third option... the one I outlined above. Ideally MS would wake up and realize they can't afford to keep losing developers and all of the businesses those developers provide software for. Unfortunately, big profits cloud their thinking... |
I actually don't mind see VB being fractured to pieces. |
Why not modular model ? when we import (maybe call it plugin) dll, it add new language feature from community. Plugin Recursion.dll
Function Factorial(Input As Int32) As Int32
Dim Output = 2
Recur Until Input < 3
Output *= Input
Input -= 1
End Recur
Return Output
End Function Harmony project maybe a good example to do this. |
I agree 100% - that is why I contacted others that can do it; with already 5 other langugaes with a shared compiler, the only work they have is to add the language syntax and the specific VB things. |
Is there another choice? So my hopes are gone. Microsoft won't help us. |
No one want to do mobile apps with VB.net |
I do, why not? |
As I see your profile, you are doing only C#, so it's just YOU don't want to do mobile (or whatever) with VB. |
We develop mobile apps with VB.Net, too. |
My company develops mobile and desktop apps in vb.net
…On Wed, Feb 5, 2020 at 9:29 AM StefanDirnberger ***@***.***> wrote:
We develop mobile apps with VB.Net, too.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#492?email_source=notifications&email_token=ACDXH6KL5PSU6NUE7V6ATM3RBLLMBA5CNFSM4KQDGGU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK32ZMQ#issuecomment-582462642>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACDXH6MJUR5XUPPQMX4HGFLRBLLMBANCNFSM4KQDGGUQ>
.
|
From my experience the Roslyn developers can be downright hostile, to potential contributors, who have little experience with the codebase. Documentation is lacking, especially "internal" tools, for example the "syntax.xml" and "BoundNodes.xml" has little explanation. Often having to use trial-error to make any changes or progress. The tools that is to build the syntax and bound nodes for the languages, doesn't produces, contextually meaning diagnostic error messages. Instead it produces errors when you compile the resultant outputs. I have and do, implement prototypes of feature, would use and like. Yet don't yet have the skill or knowledge to convert them into a viable feature, That could be added to a "official" version of the language. Tried to follow their procedure of submit proposals, and it feels like shouting into a dark empty office. The computer power lights are on, but nobodies in. It is not an environment the cultivates the small number of programmers interested in compilers. Encouraging them and helping them to learn. Eventually it becomes "whatever", disinteresting and murders to passion that they had for both languages VB.net and C#. |
Isn't it interesting that a number of the more popular "new" languages have a VB style syntax? Specifically, NO CURLY BRACES! Python, Nim, Julia, and others. Isn't it also interesting that Microsoft is spending a LOT of effort to support and promote Python which is very similar to VB.Net, while at the same time trying to sideline VB.Net which is far superior to Python... Why? If they would support and promote VB.Net with .Net Core which will enable VB.net to be used cross platform, I believe VB.Net would become more popular than Python. |
I am afraid they just did the math.
and:
So the less VB can do, the more users will switch to C#. Tiobe index this month: This will make C# the third language instead of the fifth. |
And if you read this: https://devblogs.microsoft.com/vbteam/digging-deeper-into-the-visual-basic-language-strategy/ VB is Winforms and WPF. And that's it. For everything else, you need C#. |
Why should anyone switch from VB to C#? Up until recently there wasn't anything you could accomplish in C# that you couldn't do in VB. Yes, I realize you could play with toy pointers (not REAL pointers like C or C++), but you don't need pointers to accomplish the task... which is why they're not in VB in the first place. Not only could you do anything you needed in VB, but once compiled there wasn't any difference anyway. Why use ugly syntax if you don't have to? |
Those are the words of Mad (nice name in this context btw), not mine. |
VB has always been more than a compiler. Microsoft is going a good job making sure the IDE (codefixes) continues to have parity between VB and C#. A lot of work is going on getting WinForms to work for VB which is a lot more complex then C# because the IDE and WinForms and VB are all tangled together. I don't need many new features in VB except to make sure it can consume all Core libraries. I would like to see unchecked math built in and a few other things but I'm OK with the language being behind C#, VB should not be a "pioneer" here. |
BTW it look 18 months from the time I proposed adding "Comments after Line Continuation" until it was in VB 16. Microsoft added another feature at the same time (one I have no idea why it was added and I have seen no document about). I am working with someone to improve VB formatting which I started mid-2019 and some day it will get integrated. Because there is little documentation on the formatter I can't make progress myself and that will be the problem just splitting the language. If you want a feature following the painful process does work. |
Personally, I want the option of developing cross platform and mobile apps in VB.Net. I find it interesting that at the same time that VB.Net has been climbing in popularity over the past few years we began hearing more howling and hating from the C# crowd. Did someone see the writing on the wall and realize that if they didn't do something VB.Net would become the #1 preferred .Net language? |
MS pushed VB into 'discourage phase'. Reason for this is not language itself, but tools. Making VB tools for each platform (Xamarin, ASP NET, Azure, Blazor, etc) require heavy investment, new teams and more complex structure of these tools, to handle two different languages. Keeping in mind that tools for C# now require all possible resources, and these tools are far from mature / polished, it is highly unlikely that MS will split these resources for two languages. Current policy for VB is to enable it in platforms only where tooling requirement is minimal. if some Independent VB development team will take risk and create (paid) VS extensions with tools, then MS could eventually transfer some newest features from C# to VB, IMO. |
MS had 39.2 Billion in Net Income last year (2019). They certainly have the money to add VB.Net to the new platforms. If they need to add new developers for those tools, they certainly have the resources to hire them. It's not a matter of lack of "resources". It's simply a matter of will, and honoring your commitments. |
In my experience, I can't find a vb dev anywhere near me in Texas but
there's a ton of applicants from India.
We ended up opening an office in Gift city and now I'm making videos on how
to use LINQ and lambdas and such.
…On Wed, Feb 5, 2020, 8:01 PM WolvenRA ***@***.***> wrote:
MS had 39.2 Billion in Net Income last year (2019). They certainly have
the money to add VB.Net to the new platforms. If they need to add new
developers for those tools, they certainly have the resources to hire them.
It's not a matter of lack of "resources". It's simply a matter of will, and
honoring your commitments.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#492?email_source=notifications&email_token=ACDXH6KAVMHTZNMURPYX6HTRBNVRHA5CNFSM4KQDGGU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK5U6BQ#issuecomment-582700806>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACDXH6LGVDPMHMQNT3YQAULRBNVRHANCNFSM4KQDGGUQ>
.
|
@Hamenopi Interesting, I have posted resumes looking for VB.Net jobs and all I get are C# sometimes when I look at other .Net jobs they want VB experience. The .Net confuses the search engines. |
@Hamenopi What kind of application are you building? |
What pieces are missing? I think having a cross-platform, .NET Core-based toolchain leveraging open parts like VS Code would be a great first step, much like OmniSharp pushed forward the development of .NET Core. |
I'm not sure what all of the pieces missing from VS Code are... I'd have to find the article that I read explaining which pieces were missing. Basically it said you could Edit, Run and Debug your code but things like creating an install file and a number of others weren't there. I did read another article saying that pieces are being added and it's getting closer all the time. Although I don't think the added pieces were for VB.Net in particular. I do agree with Paul1956, it would be MUCH nicer if MS would just add the functionality we're looking for. They can hire the developers and play nicer with the open source developers to do the work. |
You mean the same article where I read: "bridge existing applications into mobile and [...]new services optimized for the cloud from the ground up [...] align very strongly with F#[...]" And yes, they communicated it, but they publicly denied allegations (or minimised to avoid concern) while privately regretting that choice. |
Business do not work this way. Every department have his budget, goals, agendas, and their primary task (management level) is make profits, maintain / expand marketshare and fully exploit every opportunity that currently exist or will exist in foreseable future. Seems that current model (expanding C# with tools / maintain VB with current tools) is best from organisational / financial POV. Making perfect world is not target for business |
What's the non-nullable default for |
@WolvenRA Just use a property instead of a field that sets the default? |
@tverweij You mean the property should set the default?
That's all well and good until some other member within the class calls the field directly instead of the property. And I don't think there's any way to prevent that kind of access. Having nullable reference type handling would allow a compiler warning.
|
Semi Auto Properties? |
Local properties and Non Nullable References are implemented right now. But not In Microsoft VB. |
@Happypig375 Semi Auto Properties? @tverweij Local properties? |
Properties defined in the method body. Just like local functions (That Microsoft VB doesn't have either, but C# does). |
which is a better solution to
|
@tverweij I don't think C# has local properties, only local methods. |
@Happypig375 : That is what I meant to say. |
When the object is created, unless overridden, all fields and properties would be set to whatever the base type default value is. 0 for Integers, Floats, Decimals, etc. An empty string for String, a blank for Char. So for SqlConnection the Connection String value would be a blank string, the Connection Timeout would be 0, etc.. Gettting a Null Reference Exception because we try to access an object that hasn't been Created yet makes sense (actually the error should be "'Object' doesn't exist"). But other than that, I shouldn't ever have to worry about some value being Null. Unless I SPECIFICALLY defined something as Nullable... which I would never do. |
@WolvenRA Ahh yes, a |
Or a table with color 0x00000000 (transparent) and 0 legs. |
What about fields whose type is not a value type? The default value for these is generally
Isn't it generally more appropriate to store the date of birth in the object and have age calculated from the date of birth? Assuming |
@WolvenRA post is the one that makes more sense in this whole thread. And yes a person with no name and 0 age is a perfectly acceptable object in a neonatal ICU, or as far as the programmer instantiate a person without initialising its properties. That's a mistake of the programmer and as such shall remain. For all other objects without a default value, Nothing is a perfectly acceptable value. |
@Padanian Consider the following code:
Where was the programmer's mistake? Was the mistake in originally assigning Now, if there's some way to separate between the two (either explicitly declaring the null-allowed, or explicitly declaring the null-disallowed), the compiler can warn either on the inappropriate assignment ("You're trying to assign Just as the compiler prevents the mistake of trying to add two instances of |
Objects needs to be declared, instantiated and then initialised. |
@Padanian The error message comes from the CLR;
Except that somewhere in the intervening code you changed the Variables can vary; that's why they're called variables. My point is, with null reference type handling, the compiler can identify and warn about such potential problems, making it easier to fix them. |
I would argue that IF the programmer assigned Nothing then, yes, it's their responsibility to check for that (and having the compiler give a Warning is fine). But if the programmer did this: Dim ToSeeHere As New Object Then ANY and ALL properties, fields, etc. SHOULD be set to either some predetermined value OR to the base default value for that property\field type... NOT NOTHING! If they did this: Dim ToSeeHere As Object Then it's up to them to instantiate it before they try to use it (and again having the compiler give a Warning is fine). And @Happypig375
Whether it's valid or not is irrelevant. That's the programmers responsibility. BUT, it SHOULDN'T be Null\Nothing, (unless the programmer SPECIFICALLY set it to Null\Nothing). Other than an un-instantiated object, NOTHING should be Nothing or Null... :) (Again, unless the programmer SPECIFICALLY set it to that.) I forget who the guy was that originally came up with the idea of Null (originally as a string terminator I believe), but I read an article where HE said it was the biggest mistake in the history of computer science. I agree with him. Nulls are just *&^%$ stupid. |
Class A
Public O As Object ' Uninitialised, so Nothing
End Class
Class B
Public A As A ' Uninitialised, so Nothing
End Class
Dim A1 As A ' Nothing
Dim A2 As New A ' Now A2.A.O is initialised? |
And this: Public Class C
Public A As Console ' Yes, System.Console
End Class
Dim c As New C ' What is the value of c.A? |
In fact correctly returns
I think the whole discussion here is about good programming practice. |
The ideal of "good programming practice" would say that you obviously shouldn't attempt to add two instances of
the compiler complains that there is no such operation defined for the
and would only fall at runtime. This is what null reference type handling brings to the table: a way to indicate that a variable can be |
@zspitz |
Which is why nullable reference types is opt-in: you can choose not to use this feature entirely. |
@Padanian Were you in the forbidden? Or in the minority? 😊 But I don't quite understand what you're trying to say. Nobody is proposing that |
Alright, we made our point clear. No need to further discuss the matter. Thanks for your patience. |
Obviously neither Object O nor Console A are initialized or instantiated... but I'm not sure what the point is. Furthermore I'm not clear how the "Nullable Reference Types" (a HORRIBLE name for something that's actually supposed to enable NON Nullable types) feature being added to C# would change anything in your two scenarios. As I understand it (and could definitely be wrong) so the compiler will give you a warning about EVERY possible access of something that COULD be Null\Nothing. Dim A as Decimal = 10 C = A / B Would we want the compiler to give us warning EVERYTIME we do a division about POSSIBLY dividing by zero? As I understand it (and again could definitely be wrong), the feature being added to C# is to enable types that CAN'T be null\nothing so you don't have to bother adding code for null\nothing checks. While that makes sense, it seems you're still going to have lots of un-instantiated objects that will still need the checks soooo... ? |
@WolvenRA I think @Happypig375 's point is that there is no default value to which reference types can be initialized. Even after you've initialized your immediate variable with an an instance of an object, the individual properties also have the same problem -- if those properties are of reference types, they also need to be initialized. IOW, the following:
is impossible.
Because the compiler warns on a class with uninitialized fields. In the
Actually, it only warns about the first access of a given variable within the current scope; once you fix that warning, the next warning lights up. And the compiler detects many cases (there may be others) where even though the CLR type can contain
Perhaps. However, I would suggest division by zero is a little different, because
Only for those places where your design mandates the possibility of Also (as I noted above) there is a warning on classes with fields which aren't supposed to contain |
I'm beginning to wonder if maybe the VB community needs to create an independent VB development team. The team would need to consist of sub teams that work on the various components of the entire development tool chain. If I'm not mistaken, (although I could be), it seems like pretty much the entire tool chain for .Net and .Net Core is supposedly Open Source... but I don't know about the Visual Studio IDE. VS Code is open source but it doesn't contain a number of the components needed to create the entire solution\package.
In any case, why couldn't we make a Fork of the entire development tool chain and control our own destiny? Including incorporating VB into the new .Net Core web development pieces (MVC, Web API, Razor, WebForms, etc.) as well as other portions of .Net Core. In short, Actually Fulfilling the promise Microsoft gave us at the beginning of .Net to keep VB essentially equal to C# through their "Co-Evolution" strategy.
The reason I think we might need to do this is because Microsoft is clearly bailing out of their commitment to VB. While I think this is complete cowardice and blatant treachery on Microsoft's part, we have to face the facts. Just as they shafted the original VB developers, they are now heading down the same path with the VB.Net developers. And just as it cost them thousands of loyal VB developers, I have no doubt it's going to cost them thousands more loyal VB.Net developers. But apparently Microsoft doesn't need the VB.Net developers or the millions of business clients using applications written in VB.Net... (Python anyone?)
I think one of the reasons we don't see as much participation in this Github VBLang community is because most VB.Net developers are business application developers... not system developers. i.e. we don't write Compilers, OS's, Runtimes, Drivers, etc... Consequently most of us (myself included) don't have the background or experience to be able to actively participate in the development of Roslyn, the Framework, the CIL, the Runtime, the VB Compiler etc.. Nor the time. We counted on Microsoft for that. Hard to imagine why we feel stabbed in the back...
Apparently we will have to step up and do it ourselves. While I'm sure I could learn how to help write all these development chain tools, I quite frankly don't have the time or desire. BUT! Since I'm sick and tired of being dependent on an unreliable Microsoft, I would be willing to pay a reasonable annual fee to an INDEPENDENT, DEDICATED, COMPETENT, VB Development team to do it for me.
So, How many others would be willing to support such a team?
Question for Kathleen or one of the other top MS people... How many developers does MS actually have working on the various .Net components specifically for VB?
The text was updated successfully, but these errors were encountered: