I'm seeing my career basically go head first into .NET despite my attempts at going all in on Python, Visual Basic 6 was my first language followed by C#, and in college, the moment I learned about preprocessor directives in C I did what probably everyone who likes BASIC and learns C has done, define BEING and END as { and } respectively... to the horror of C developers everywhere.
I think .NET is a fantastic platform, and I'm still surprised there's not more attempts at building languages on top of it, especially when you consider how IronPython was built to "prove" .NET was a terrible platform, but the Jython developer fell in love with .NET as a result of his attempt, heck, Microsoft hired the developer! At least thats how I've heard the story told on random HN comments over the years. :)
I havent had the pleasure of building a full interpreter yet, so props on doing the work.
Edit:
A few weeks ago I tried VB .NET and theres something nice about it, it feels like when I write some pieces of code, I can verbalize what it is, instead of some obscure character someone gave a meaning to, but building out VB .NET projects means translating C# to VB .NET the entire time, since most .NET things today are all in C# and it can be more effort than just writing in C#. There is something really nice and almost elegant about BASIC.
My only complaint with Microsoft was that VB6 made native binaries, I wish they had done VB7 with threading support before .NET became a thing.
I REALLY hope they open source Visual Basic 6 with the MIT License, would love to see what might happen if people fork it and make improvements to it...
.NET was going to be next generation COM, based on J++, but then things went somewhere else, Cool became C#, J# was introduced as transition for J++, and the rest as we know it.
WinRT was an attempt from WinDev to get back to their COM über alles, and replace .NET with their vision.
People didn't experiment that much with .NET due to it being Windows only, and mono not being quite the same thing.
So ironically, the Java Virtual Machine has experienced more guest languages, while the plethora of languages that targeted Common Language Runtime has diminished since 2001, and nowadays even Microsoft behaves as if it was C# Language Runtime, given some of the latest decisions on .NET features not exposed to VB, F# and C++/CLI.
> even Microsoft behaves as if it was C# Language Runtime, given some of the latest decisions on .NET features not exposed to VB, F# and C++/CLI.
While the track record is not squeaky clean in this area, it is pretty much not true anymore and was already in a decent state for quite some time. Also, very late into .NET 8 development cycle there was a breaking change regarding ref readonly parameters, which was introduced without proper consideration of F# and caused a lot of trouble for F# team. I think after that the issue can be assumed to be fully addressed because there were changes made to ensure that F# and CIL level compatibility are considered much more comprehensively even in areas where it wasn't considered relevant in the past. It is less of a language problem and more of a popularity problem - Java just has so much more developers, so sibling languages even relatively niche ones will easily have the amount of developers and jobs necessary to clear the viability threshold.
Personally, I do not think that all, especially low-level, aspects of the platform need to be uniformly available everywhere - something like ClojureCLR certainly doesn't need to concern itself with convenient syntax for byrefs.
At the end of the day most features C# exposes that aren't syntactic sugar exist at CIL level meaning that anything can target them as they eventually become a part of ECMA spec.
It would be great to see more guest languages as .NET is a target that can offer higher level LLVM bitcode like experience with way better performance assurances than OpenJDK or GraalVM Truffle, and because guest languages implemented today are way less likely to use un-analyzable reflection or reflection emit, it means zero effort is required to turn your CIL output into a native executable.
> I think .NET is a fantastic platform, and I'm still surprised there's not more attempts at building languages on top of it, especially when you consider how IronPython was built to "prove" .NET was a terrible platform, but the Jython developer fell in love with .NET as a result of his attempt, heck, Microsoft hired the developer! At least thats how I've heard the story told on random HN comments over the years.
It is often joked that .NET doesn't feel like it needs that many languages because C# can be so very good, and the JVM has so many languages because Java is, uh, well Java.
IronPython was indeed pretty great and some of the tools it inspired are still in .NET (and in C#). The thing that mostly "killed" IronPython was the same thing that disrupted most of the Python ecosystem: Python 3. Maintaining a second interpreter for a language requires a lot of work to keep up with the primary interpreter, and Python definitely had one of those fun hurdles that caused a lot of updates. Around that point is also when F# arrived and while F# was intended to be an IronPython killer, either, it fills a similar gap sometimes. (Certainly for me F# replaced a lot of what I was using IronPython for at the time, and even today.)
Many of the other alternative languages I've used in .NET were eventually replaced simply because C# continued to improve, including it's abilities to run in a REPL and to be a miniature scripting language for quick scripting needs. The joke I started with comes from a place of some truth, too.
Also, PowerShell I use a lot, and it is weird to not think of it as a common .NET language in the wild, but it definitely is technically exactly that.
VB7 would have been nice. They were missing a couple of key features that prevented it from being true OOP language.
As far as open sourcing it... I think one of the people who worked on VB6 (can't remember the name) mentioned on a podcast that it's impossible to open source it because it uses all sorts of proprietary libraries from 3rd parties. The effort to track down the rights holders 20 years later would be a real challenge and not even a guarantee that they would go along with it.
That's a shame, I would be alright with a stripped down version of it that has only the Microsoft specific as open source. I'm mostly curious given an open source release of it, how much would the wider open source community work on it. We saw that Go despite its core maintainers not porting it to Windows, got ported to Windows by the community.
That's also a BASIC built in .NET. It's focus is on "pedagogy" (teaching programming a step at a time in a revealing pattern sort of way), and offers a lot of fun silly things like a Turtle module and other basic GUI tools.
This is great. It makes me think there's something about the simplicity of a line-based interface for both editing and running code that we could still learn from in today's tooling. The interface to BASIC programming had to be simple because the only way you could do anything was by typing at the next line. But due to that very limitation, there was less friction from context switching. I think that's something that hasn't been fully recaptured even by advanced current REPLs.
I'm seeing my career basically go head first into .NET despite my attempts at going all in on Python, Visual Basic 6 was my first language followed by C#, and in college, the moment I learned about preprocessor directives in C I did what probably everyone who likes BASIC and learns C has done, define BEING and END as { and } respectively... to the horror of C developers everywhere.
I think .NET is a fantastic platform, and I'm still surprised there's not more attempts at building languages on top of it, especially when you consider how IronPython was built to "prove" .NET was a terrible platform, but the Jython developer fell in love with .NET as a result of his attempt, heck, Microsoft hired the developer! At least thats how I've heard the story told on random HN comments over the years. :)
I havent had the pleasure of building a full interpreter yet, so props on doing the work.
Edit:
A few weeks ago I tried VB .NET and theres something nice about it, it feels like when I write some pieces of code, I can verbalize what it is, instead of some obscure character someone gave a meaning to, but building out VB .NET projects means translating C# to VB .NET the entire time, since most .NET things today are all in C# and it can be more effort than just writing in C#. There is something really nice and almost elegant about BASIC.
My only complaint with Microsoft was that VB6 made native binaries, I wish they had done VB7 with threading support before .NET became a thing.
I REALLY hope they open source Visual Basic 6 with the MIT License, would love to see what might happen if people fork it and make improvements to it...
.NET was going to be next generation COM, based on J++, but then things went somewhere else, Cool became C#, J# was introduced as transition for J++, and the rest as we know it.
WinRT was an attempt from WinDev to get back to their COM über alles, and replace .NET with their vision.
https://arstechnica.com/features/2012/10/windows-8-and-winrt...
People didn't experiment that much with .NET due to it being Windows only, and mono not being quite the same thing.
So ironically, the Java Virtual Machine has experienced more guest languages, while the plethora of languages that targeted Common Language Runtime has diminished since 2001, and nowadays even Microsoft behaves as if it was C# Language Runtime, given some of the latest decisions on .NET features not exposed to VB, F# and C++/CLI.
> even Microsoft behaves as if it was C# Language Runtime, given some of the latest decisions on .NET features not exposed to VB, F# and C++/CLI.
While the track record is not squeaky clean in this area, it is pretty much not true anymore and was already in a decent state for quite some time. Also, very late into .NET 8 development cycle there was a breaking change regarding ref readonly parameters, which was introduced without proper consideration of F# and caused a lot of trouble for F# team. I think after that the issue can be assumed to be fully addressed because there were changes made to ensure that F# and CIL level compatibility are considered much more comprehensively even in areas where it wasn't considered relevant in the past. It is less of a language problem and more of a popularity problem - Java just has so much more developers, so sibling languages even relatively niche ones will easily have the amount of developers and jobs necessary to clear the viability threshold.
Personally, I do not think that all, especially low-level, aspects of the platform need to be uniformly available everywhere - something like ClojureCLR certainly doesn't need to concern itself with convenient syntax for byrefs.
At the end of the day most features C# exposes that aren't syntactic sugar exist at CIL level meaning that anything can target them as they eventually become a part of ECMA spec.
It would be great to see more guest languages as .NET is a target that can offer higher level LLVM bitcode like experience with way better performance assurances than OpenJDK or GraalVM Truffle, and because guest languages implemented today are way less likely to use un-analyzable reflection or reflection emit, it means zero effort is required to turn your CIL output into a native executable.
> define BEING and END as { and } respectively
I know this is a typo, but I love the idea of using "BEING" and "END" as delimiters. Maybe "BIRTH" and "DEATH".
> Maybe "BIRTH" and "DEATH"
Constructors and destructors
Haha I didn't even notice, glad everyone understood :)
> I think .NET is a fantastic platform, and I'm still surprised there's not more attempts at building languages on top of it, especially when you consider how IronPython was built to "prove" .NET was a terrible platform, but the Jython developer fell in love with .NET as a result of his attempt, heck, Microsoft hired the developer! At least thats how I've heard the story told on random HN comments over the years.
It is often joked that .NET doesn't feel like it needs that many languages because C# can be so very good, and the JVM has so many languages because Java is, uh, well Java.
IronPython was indeed pretty great and some of the tools it inspired are still in .NET (and in C#). The thing that mostly "killed" IronPython was the same thing that disrupted most of the Python ecosystem: Python 3. Maintaining a second interpreter for a language requires a lot of work to keep up with the primary interpreter, and Python definitely had one of those fun hurdles that caused a lot of updates. Around that point is also when F# arrived and while F# was intended to be an IronPython killer, either, it fills a similar gap sometimes. (Certainly for me F# replaced a lot of what I was using IronPython for at the time, and even today.)
Many of the other alternative languages I've used in .NET were eventually replaced simply because C# continued to improve, including it's abilities to run in a REPL and to be a miniature scripting language for quick scripting needs. The joke I started with comes from a place of some truth, too.
Also, PowerShell I use a lot, and it is weird to not think of it as a common .NET language in the wild, but it definitely is technically exactly that.
VB7 would have been nice. They were missing a couple of key features that prevented it from being true OOP language.
As far as open sourcing it... I think one of the people who worked on VB6 (can't remember the name) mentioned on a podcast that it's impossible to open source it because it uses all sorts of proprietary libraries from 3rd parties. The effort to track down the rights holders 20 years later would be a real challenge and not even a guarantee that they would go along with it.
That's a shame, I would be alright with a stripped down version of it that has only the Microsoft specific as open source. I'm mostly curious given an open source release of it, how much would the wider open source community work on it. We saw that Go despite its core maintainers not porting it to Windows, got ported to Windows by the community.
There have been some interesting projects, like PHP on .NET [0] They have a version of Wordpress compiled into a NuGet package for Asp.Net Core [1]
[0] https://www.peachpie.io [1] https://www.nuget.org/packages/PeachPied.WordPress.AspNetCor...
One rather charming attempt is:
https://github.com/VBAndCs/sVB-Small-Visual-Basic
Something fun to compare your efforts against is Small Basic: https://smallbasic-publicwebsite.azurewebsites.net/ (https://github.com/sb) [0]
That's also a BASIC built in .NET. It's focus is on "pedagogy" (teaching programming a step at a time in a revealing pattern sort of way), and offers a lot of fun silly things like a Turtle module and other basic GUI tools.
[0] Apparently not to be confused with SmallBASIC, a C/C++-based somewhat math-focused one: https://github.com/smallbasic/SmallBASIC
This is great. It makes me think there's something about the simplicity of a line-based interface for both editing and running code that we could still learn from in today's tooling. The interface to BASIC programming had to be simple because the only way you could do anything was by typing at the next line. But due to that very limitation, there was less friction from context switching. I think that's something that hasn't been fully recaptured even by advanced current REPLs.