Project Mercury: Another version of VB

[tverweij]

As I follow this GitHub board for a few years now, and did not see any improvements to VB or any feature request implemented, I talked to another company that builds programming languages about making a custom VB / VB.Net implementation that can compile all current code and extend it with (almost) anything that C# has (including unsafe) and most of the request done here (including mixing C# and VB.Net code in one project).

Edit:
This won't be a free implementation - think of a yearly fee of about USD 500,-
And this topic is to see if a second implementation of VB is feasible.

Development will be done in Visual Studio or in their own IDE on Windows and Mac OS
Supported targets will be:

• .Net (including Mono)
• .Net Core
• Android using the Android SDK
• IOS using Cocoa
• Web Assembly
• Native Windows
• Native Linux

If this was accomplished, who would be willing to try this implementation?

[Padanian]

I would it give it a try. I'm currently evaluating Xojo, AKA Realbasic.

[pricerc]

I might be game.

Since the Roslyn VB compiler is Open Source, I would have thought that forking it to a better supported alternative would be quite feasible, although that alternative would (presumably) need to also be open-source.

[WolvenRA]

I believe we (the VB community) are going to HAVE to do something ourselves. It's becoming quite apparent that we're not going to get much help from Microsoft to keep VB on parity with C# or incorporate VB into a lot of the .Net Core going forward. I'm going to post another Issue with some thoughts on this.

[tverweij]

The implementation has started.
I won't give any updates here - just follow my twitter (see my profile) to get the progress updates.

[rrvenki]

Before putting a lot of effort I suggest you (@tverweij) to see the specifications and plans for .NET 5.0. One known plan is merging of Standard, Core, and Main .NET frameworks. Even if half of @AnthonyDGreen PoCs in VB are incorporated in VB of .NET 5.0, it would be great (if not JSON literals).

[tverweij]

@rrvenki: Where is that information regarding to VB?
For C# - yes, you are right.
For VB - no information is available as far as I know, and almost all other promises they did regarding to VB were broken.

[tverweij]

@rrvenki: and the effort is a lot smaller than you think; we already have out own IDE (Windows and Mac), support for VS and multiple programming-language implementations (including a 100% C# implementation) - that interact together within the same project and are all capable of doing all targets. Adding all C# functionality (and more) to VB won't therefore be that difficult either.

[tverweij]

@rrvenki: The most work is implementing the VB syntax and the specific VB things (like ByRef bahavior). As soon as that is done, it will be editable and compilable.

[tverweij]

To be more specific, all our languages have (just a pick):

• nullable reference (we already had those before C# had) Nullable References #355
• local properties and methods
• unsafe and pointers [Proposal] Add Support For Pointers #46
• reference returns
• ranges [Proposal] Add support for ranges #418
• lazy properties
• extension properties [Proposal] Extension Property? #73
• exit a specific for loop Proposal: More control on exiting and continuing nested loops. #420, Exit For j Statement to Break Out of Nested For and For Each Loops #186
• Discardables

And a complete aspect implementation wit AOP - see: https://en.wikipedia.org/wiki/Aspect-oriented_programming

[salelele]

I am game! We need an alternative and we need a choice otherwise soon enough, we shall be faced with the choice to rewrite thousands of lines of VB Code in C# or some other language.

[ocdtrekkie]

@tverweij Commenting on a bunch of issues to spam everyone's notifications about your new not open source not free alternative that has these features is... a pretty spamming advertising choice. Please refrain?

[tverweij]

Just trying to provoke any (re)action from Microsoft to match it and start taking VB seriously again.
Because there is no such reaction at all from Microsoft; nothing is ever implemented, only a few things declined.
Yes, I am working on the non open source, non free project Mercury, but I rather have 2 distinct living and evolving versions of VB out there. The second one is needed - otherwise VB will die. I hope some competition will awake them.

[VBAndCs]

please take a look at #498 to gather all the efforts.

[tverweij]

I support all projects that will give VB a future, but at this moment I am completely fixed on Mercury, as this project has almost reached the point that it can compile all VB code, followed by internal testing and a beta program.

Mercury is not Roslyn based, so it won't interfere with your efforts.
I wish you the best with that project.

[VBAndCs]

@tverweij
Can't you add the extensibility feature to mercury? You are in a raw stage and I think this can be easy now, and will make your product attractive, as everyone can add his favorite syntax.

[tverweij]

@VBAndCs
Yes and no.
Mercury is added to an existing toolchain - see remobjects.com. So not really in a raw state; everything is already ready and proven for years; we only have to implent the language parser.

So adding that would affect all languages and things like that would break compatibility between different installs of those languages. So we are not adding that.

But this toolchain supports Aspect Oriented Programming (see wikipedia: https://en.wikipedia.org/wiki/Aspect-oriented_programming and https://docs.elementscompiler.com/Concepts/Aspects/Cirrus)

I for myself use some aspects in another RemObjects language (Oxygene Pascal) that replaces all .Substring calls to another implementation, does logging, and generates code in general.

[tverweij]

An update:
The syntax is now for about 80% implemented and we are able to target all kind of console apss - MacOs/Cocoa, Linux Native, Windows Native, .Net Console and .Net Core Console - and yesterday we had Web Assembly operational.
We are now focussing on Winforms for .Net and .Net Core.
Next will be ASP.Net and ASP.Net Core.

[Padanian]

Can't wait to put my dirty hands on it.

[VBAndCs]

Can you implement this in mercury?
#501

[tverweij]

Already done.

[VBAndCs]

Well done :D
I hope you also fix the problems in XML literals, such as dotnet/roslyn#34816 and #422

[tverweij]

XML literals are the last on our list :-(

[VBAndCs]

@tverweij
You can use this idea if you like:
https://developercommunity.visualstudio.com/idea/956194/embedded-unit-tests.html

[tverweij]

I build an aspect for that some time ago for our Pascal language Oxygene.
This will work on Mercury too - so when the time comes, I will publish that for general use.

[tverweij]

It works like this:

<TestMethod>
Public Sub MyTest
 …
End Sub

This will enable our own testing software and the test methods are removed from the Release builds.

[VBAndCs]

In my idea, no need to attributes. Tests reside in a .tset.vb files, and methods are linked by name convention. The test clases and method are auto generated for every class and method added in the project. This will make testing fun.

[tverweij]

That is not an attribute - it is an aspect.
And with those you can extend the language, as I did with this testing solution.
It's not part of Mercury (and won't be), but it will work on it.

[Padanian]

testclasses and testmethods are also used in Microsoft.VisualStudio.TestTools.UnitTesting.
Other unit testing frameworks already exist, like NUnit and more.
No need to reinvent the wheel by adding unnecessary files to projects

[tverweij]

No files, just methods.
And no obligation to use it.

[VBAndCs]

@Padanian
I am aware of existing tests, but they are separated in different projects in the same solution where you have to navigate back and forth between them. I get this idea from the 150.000 tests in the Roslyn source code. It is an agony to find the original method that the test is designed for in that maze of projects. I also hate to switch away from the project after adding a new feature to write a test for it. Automatic tests seems nice but it is in the enterprise edition only. Things will be easier and linked if the tests are reorganized closer to the code it tests, and as I descried, tests will not compiled with the project. I feel that tests should have been written that way in first place.

[tverweij]

From @AnthonyDGreen https://anthonydgreen.net/2019/02/12/exhausting-list-of-differences-between-vb-net-c/

Pet peeve: I really dislike that + is even allowed for string concatenation in VB. It’s there for legacy purposes, + always concatenated strings but its current behavior is more like a bug than anything. Why? Because:

“10” - "1” = 9.0,
“5” * “5” = 25.0,
“1” << “3” = 8, and
“1” + 1 = 2.0, but
“1” + “1” = “11”

Every other arithmetic operator converts the strings to numbers. + being inconsistent is a design bug.

Do you want us to implement this bug or just don't allow the + operator on strings?

[VBAndCs]

Add an Option Legacy which is Off by default. This will allow you to add all the breaking changes you want, which will benefit the new apps, while old code can turn on the Option Legacy at project level or at individual files so that existing apps can move safely and easily to your platform.

[tverweij]

No.
It's implemented or not - we are NOT going to make anything more complex than it has to be.

And we WILL get breaking changes; as we are extending the language - add new keywords.
When someone used them as identifiers, you have to change that (or escape between brackets) before you can run your code.

[WolvenRA]

From what I read somewhere using + for string concatenation is slower than using &. While it would be a breaking change (and a PITA), it's not that hard to scan and replace... I know cuz I've done it myself on a 750,000 lines of code solution. It's takes a little time and is mind numbing, but... :) I would recommend NOT implementing it. Cleaning up our code is a good thing. Painful though it might be.

[tverweij]

That is what I was thinking - I think we'll skip all string math for the first version, and see if it is needed in the future. If so, we'll implement it then.

[VBAndCs]

@tverweij
It is not about string math. It is about implicit conversion, which is a smart feature of VB that leads to some confusion in some situations (quickly solved after a debug) but it makes us code less. I miss implicit conversion in C# and feel it is a stupid language that I need to lower my intelligence to talk to. So, you must have "1" + "1" as you have to had "1" + 1, but decide what the first will yield. This is also related to objects and late binding. You can't take such decision quickly without conceding the side effects.

[tverweij]

Implicit conversion should only be widening, not narrowing. Because widening can not fail, while narrowing can. Fast coding is ok, but fast building bugs is not.

But the code behaviour tests will be excuted soon, as old VB code should behave the same in mercury (unless we decided that we break some constructs, in which case it won't compile).

[zspitz]

Is Mercury going to implement a language server? It could then be usable from many different editors. Or is there at least some way to expose the information needed to construct a language server?

[tverweij]

@zspitz: I don't know - I will ask.

@WolvenRA: "From what I read somewhere using + for string concatenation is slower than using &."
That is correct; & is just String.Concatenate, while + is trying to implicit convert to see if it has to do string math.

[tverweij]

@WolvenRA: But in Mercury, we dropped string math, so + will be exactly the same as &.

[tverweij]

@zspitz : No, but we have 3 supported IDE's; Visual Studio, Water - our own IDE on Windows and Fire - our own IDE on Mac.
There are currently no plans to implement this.

[VBAndCs]

I once proposed to allow this alternative of Lambda in VB:
Fn(a) => a + 1
which is equivalent to:
Function(a) a + 1
The 'Fn' is an old VB keyword. The => makes it visually obvious that there is a reurn value following.
I wish current lambda at least be:
Function(a) = a + 1
But in this case, this is a 5 chars shorter and closer to C#:
Fn(a) => a + 1
Or if you prefer to save more 1 char:
Fn(a) = a + 1

[conioh]

I would seriously caution everyone from falling for RemObjects' misleading propaganda.

While they and their fanboys here promise to support VB.NET's syntax [1] they will probably not support VB.NET's semantics. That is, code that used to do something will do _something else.

That's exactly what they say about their implementation of Swift:

You have the full Swift language syntax – with some extensions, even – and full access to the native platform APIs, be it the Java or Android libraries, the extensive .NET Framework Class Library, or more.

But the semantics are different [2]:

Moreover, when I tried, their native target weren't even half-baked. When I tried it they didn't even generate PDBs. You couldn't even specify DllMain for DLLs and a bunch of other problems. Some of those issues were fixed, but anything you get from there would be a second-class citizen on the platform it's supposed to implement (be it .NET or Win32 or macOS and probably the rest others too) and even the IDE and toolchain are second-grade.

The idea is nice. The reality isn't as much. They have too small of a a team to actually make good on their promises to the point that sometimes they don't even try. That brings us back to "we support the full syntax but interpret it to mean something else completely".

If you still want to invest heavily into that, go ahead.

[1] "... full Visual Basic™-compatible Mercury language syntax will be available" https://www.elementscompiler.com/elements/mercury/

[2] https://docs.elementscompiler.com/Silver/DifferencesAndLimitations/

[salelele]

@conioh
If you have an investment of thousands of lines of code in VB.NET/VB 6 then you will understand why Mecury has fans.

If the so called. Net team did not ignore the VB community for so long and attempt to downscale VB, Mecury would not be.

People want to program with Microsoft VB; but alternatives to VB are appearing because Microsoft .net team is squeezing VB.Net programmers out...

In this forum and in reaction to Project Mecury, people were being advised to investigate Xojo and other such products because .net team would not advance VB.NET since they are not "dog fooding" it or whatever.

If I have to rewrite thousands of lines of code across a diverse applications portfolio, then instead of rewriting to C# or Xojo, I would rather try something that is closer to what I have already been using: that is the promise of Mecury.

I do not expect it to be 100% compatible, but even if it gave 80% to 90% compatibility, it will be worth its salt.

[conioh]

@salelele you're going way off topic here. Microsoft's behaviour and the amount of VB6 code you have and what not are irrelevant. This "issue" isn't really an issue for the vblang repo but rather an advertisement for a supposed alternative. This advertisement is misleading at best.

Since people seem to be interested in the advertised alternative based on the false and misleading information provided I shared additional information on the alternative and its developers. Now the interested parties can make a better decision. If they still want to go for it, they're more than welcome.

But since you told a long and unrelated story I'll comment on some of the things you said.

If you have an investment of thousands of lines of code in VB.NET/VB 6 then you will understand why Mecury has fans.

If the so called. Net team did not ignore the VB community for so long and attempt to downscale VB, Mecury would not be.

People want to program with Microsoft VB; but alternatives to VB are appearing because Microsoft .net team is squeezing VB.Net programmers out...

If you have VB6 code you should have obviously migrated to another language/platform than VB.NET. You should have used C# or even some non-Microsoft product. It was clear from the start to anyone who's even worked in to software development industry and got any clue about Microsoft that VB.NET isn't a priority for Microsoft and it's only purpose is to lure VB6 developers into the .NET ecosystem.

Commenters were mad at Microsoft for their announcement in a recent blog post about VB.NET saying they basically lied in their previous announcement less than half a year ago. And that's true. Microsoft lied. But you fell for it despite all the warnings. So you're definitely at fault here too. You know how the common idiom goes? "Fool me once - she on you; fool me a gazillion times - ..."

Migration from VB6 to VB.NET wasn't easy or problem-free and now you find yourself in need to make a similar migration once again. When RemObjects go out of business or decides to stop supporting "Mercury" or decides to drop one of their target platforms don't act all surprised.

It's not like they have a team of about 3 developers and they're basically writing language front-end for LLVM but all the back-end side depends purely on LLVM good will. What? You think they wrote a WebAssembly back-end? You think they managed to understand what the hell is going on in the PDB format and generate PDB files? It's all LLVM.

If being screwed over by Microsoft convinces you that you should put all your eggs in basket held by a low-two-digit employee company that's your business. Have fun.

In this forum and in reaction to Project Mecury, people were being advised to investigate Xojo and other such products because .net team would not advance VB.NET since they are not "dog fooding" it or whatever.

If I have to rewrite thousands of lines of code across a diverse applications portfolio, then instead of rewriting to C# or Xojo, I would rather try something that is closer to what I have already been using: that is the promise of Mecury.

You should have done that a decade ago. You're only delaying the inevitable. You're going to work on the migration and by the time you get everything perfect you'll have to move on to the next "something that is closer". Or not. Maybe in the last two years they made everything perfect, Mercury will be 99.9% compatible with VB.NET and RmObject will live on and support it for decades to come. Maybe. Do whatever you like.

I'm just giving you a fair warning that:

1. Despite saying the offer "full" compatibility of syntax, the offer incompatible semantics.
2. They're an extremely small company that after 15 years still isn't that big and its products aren't that popular.
3. They're critically dependent on LLVM and if LLVM drops target it would be practically impossible for RemObjects to do it themselves.

Now do what you want. You don't have to convince me. Just don't forget to imagine me hearing "I told you so" when you find out you've been fooled gazillion and one times.

[tverweij]

@conioh : I don't know who you are, never saw you here before. No name on your profile. No email. No website. Your repositories are not VB. So I am not even going to react on this kind of trolling.

For everyone else:
We try to reach 100% compatibility, with the same specific VB semantics and behaviour.
Yes there will be breaking changes - not everything is portable to the multi-target stack.
Nobody has to convert to Mercury - you can stay at VB if you like (or whatever you want).
When it is released you can try 30 days for free - including support during that time.
So nobody will be fooled into anything - you can try your selfs without costs.

[conioh]

For everyone else:
We try to reach 100% compatibility, with the same specific VB semantics and behaviour.
Yes there will be breaking changes - not everything is portable to the multi-target stack.
Nobody has to convert to Mercury - you can stay at VB if you like (or whatever you want).
When it is released you can try 30 days for free - including support during that time.
So nobody will be fooled into anything - you can try your selfs without costs.

Good to know that you're not simply a fanboy but rather an employee. Somehow I didn't notice it earlier. I'm sure that it's not because you tried to conceal this affiliation by writing "I talked to another company that builds programming languages about making a custom VB / VB.Net implementation" without that it's "we" as you now say.

@conioh : I don't know who you are, never saw you here before. No name on your profile. No email. No website. Your repositories are not VB. So I am not even going to react on this kind of trolling.

Since you are unable to speak civilly this comment is being reported both to the repo owner and to GitHub.

[tverweij]

Good to know that you're not simply a fanboy but rather an employee

No, I am not an employee, but the owner happens to be a friend of mine,
I convinced him to start this project, and yes, I am helping - to safe my own VB future.

Since you are unable to speak civilly this comment is being reported both to the repo owner and to GitHub.

You are really concerned about this endeavour aren't you?

[Padanian]

Yes, he is, and I will report him for threatening and harassing.

[tverweij]

My last reaction on this subject.

Yes, RemObject is a relatively small company, but I have to name one of their products, namely Oxygene - former name : Delphi Prism. And as @AnthonyDGreen stated in his observations about VB:

"The difference between where we are now and a mostly HAPPY sustainable VB.NET community is…
3-5 developers."

So, there is no need for a big, multi-trillion company to support the language. The needed ingredients are knowledge, experience and the will to succeed. And they are all available.

[jaredpar]

This repostiory is meant for discussion about the VB.NET language. This instead a product advertisement. As such inappropriate for this forum. Locking the thread.