I also want to commend Microsoft for continuing to support VB and not succumbing to the whims of sneering hipster programmers who consider it beneath contempt (see the second comment on that article for a good example, with a classy response from MS). VB is a thing that a lot of people rely on, and some even like, and doesn't deserve to be kicked to the curb.
I wrote my first non-toy lines of code in VB6, with a (pirate) copy of the IDE that I had to ask for as a request to a dude that sold cds in a public park.
At that time, I only had a C/C++ compiler that I didn't know how to use (because I had no internet and no standard library / STL docs). The MSDN library that was preloaded in the cd was an eye opener, and the visual components made it easy to experiment.
I would probably work in a restaurant today, if it wasn't for that cd.
I worked in a start-up straight out of college where I had done C/C++. We decided to try out this Visual Basic to see if we could get things done more quickly. VB 3.0. I was blown away by how quickly you could do things even though the language made it hard to organise any kind of structure when things got bigger. We did a lot of work in it and I assumed something like it was the future of programming.
Then the start up went bust and I was back to C++ before any newer version of VB came out. They really got reusable components right. I've never had an experience since where there is such a huge jump in productivity with a new technology.
Delphi came after VB3. VB3 had "custom controls" called VBX (Visual Basic Extensions), which were the reusable components. It was the precursor to OCX and ActiveX controls.
Yes - I migrated from VB -> Delphi - one of the big advantages at the time was you could compile a small executable that didn't require you to distribute several additional disks of vb runtime DLLs with your software.
I taught myself to code late in life on VB.net - amazing how easy and powerful to get going. I've done a decent amount in C# since then. When I think about C# syntax vs VB.net syntax, and consider it's all .NET under the hood, makes me wonder whether developers like feeling as though they are writing something more complex in C# than they are. Anyway, i'm indebted to Microsoft and will be a fan for life as a result.
Fresh out of college (2004), I worked at a company that was a VB.NET shop and one of the tasks I started with was porting a bunch of ASP (not .Net) pages to ASP.NET using VB.NET.
I absolutely loved the language, coming from a Java/C++ education in college.
Then, my next job, it was a mix of VB.NET, PHP, and C# (custom software shop). I did all three and decided that C# was where I wanted to be. I simply found that VB.NET was too "wordy" with all of the "If/End If" and "Get/End Get" and "List(of Foo)". I just found it easier to follow with if(eq){}, Get{}, and List<Foo>.
I personally just found the C# syntax more straightforward than VB.NET, C# was new and VB seemed to have a bit of baggage. I never had much in the way of problems, even as a beginner, translating from VB.NET to C# examples though.
I also have a small pile of vb6 code that I must support. And while it usually behaves OK there are some instances where putting it on a Windows 7 machine to run will cause some headaches.
I got my first serious code written in VB6. It is the first IDE that I bought with my own hard earned money as a kid and it was great. I still dream of a day when there is a language/framework that makes development that easy again.
I also find it interesting now how much of the professional IDE features that Visual Studio Community Edition opens up for free to students and non-profits and open source enthusiasts.
It's easy to look back with nostalgia at our own paths (mine was QBASIC, [saved up for] VB3, with dalliances into things like DJGPP, then a lot of HTML, PHP, and very early era JS), but let's not overlook that we live in an interesting era with interesting new paths (Small Basic, Squeak, Python, modern JS, etc).
I loved Python when I learned it back in college. That was around Python 2.3/2.4. I said back then (while doing mostly C++) that Python should be the base language for CS101 at the University level. It was much easier to work with as opposed to the nuances of C++ compilers at the time.
My biggest dream is the ability to have a cross platform Mobile App/Web App ecosystem. Something that you can use from any device with a virtually equal experience. Not so easy at the moment, especially for things that need to be charged for... app store fees are way to big in my opinion. /rant
It's such a shame you had to pirate that CD. I feel happy for young/aspiring programmers today. Open source has made programming so much more accessible.
Similar story for me as well. First major application I did was with VBA built into Office. Was bored in study hall in high school and would spend my time building solitaire from scratch in it since the actual game had been blocked on the school computers.
That led me into considering Computer Science over Civil Engineering in college and have been programming ever since :)
Same here. I was a "data researcher" (read: data capturer), at a fortune 500 company. They had an office in Cape Town, South Africa. Taught myself VBA, and then VB.Net to automate some of my work. It is a few years later and I have landed myself a job as a full time C# dev.
I had a boss who started one of his companies in his attic and while he wasn't a 'real' software developer, he was still able to bring his initial ideas to fruition to get a working product because of how approachable VB is, especially for those without much experience programming. It definitely has its purpose and I am glad Microsoft understands that. The hate over VB and BASIC languages in general seems like a matter of elitism among software developers to me and oddly enough, I see this attitude from inexperienced developers more often than experienced ones.
The hate on VB(6) is specific, and it's caused by the language making the "programmer" slip into bad practices, like mixing the application and presentation layers, or the infamous "On Error Resume Next".
Design-wise, this is well justified hate - I stress "design-wise".
In the bigger picture, the ease of the framework attracted plenty of unqualified masses, therefore there is surely lots of people with a painful past of VB6 applications maintenance.
Of course I don't want to detract from VB6, as at the same time, it made very simple (or as simple as possible) for almost anybody to create applications - I'm not aware of any other language/framework which accomplished this.
I have written small kid's experimentations in QBasic, and it was fun at the age of 13, but then when I had to use VBA at the age of 28 after considerable amount of experience in C# (among others), it was painful. Is this because of elitism? No, it is because VBA has some terrible properties, which are not true for VB.Net. VB.Net is mostly OK, I just don't use it.
I'm also glad they keep that product alive, because in addition to the many positive aspects meantioned in the comments it makes sure that the CLR evolution takes into consideration the aspects needed for a more broad variety of languages.
It's not that odd to me that inexperienced developers just don't "get it" yet about stuff like this. Maybe because I used to be (more) inexperienced and have opinions like this.
BTW, as trolls go, the one who commented on the blog turned out to be comparatively sweet: After my response they came back to say they were really sorry, and asked that I delete their comment. Which I did, so you won't see it anymore.
Whoa, hi Mads! I hope we see you more around here, there's usually an HN post corresponding to big C#/.NET announcements and it would be great to have your input.
It's not VB as a language, it's VB as an ecosystem, including the developers. It's the same with php and javascript. When you have a class of developers happy to just slap things together and unable to learn other languages frameworks you end up with a lot of awful code. If I were to take a VB.net job it's not the language I'm worried about, it's the mess of spaghetti code I know I'll have to deal with.
The thing is... VB, PHP, and JS have all enabled an incredible amount of creations that never would've happened without them. It's honestly hard to imagine where we'd be without these ecosystems, and the casual slapping things together that these enable.
True, but I've also seen millions of dollars flushed down the toilet on failed projects. The culture around these languages have been the primary reason for many of these failures. I've seen millions more wasted on workarounds and attempts to fix the spaghetti code they contain.
So while the world has some cool stuff that it might not otherwise I'm not sure the world is better off for it.
I think they should quit with VB support not because there is anything wrong with it, but because it is, now, identical to C#. It is just C# with words replaced. This is nonsense.
I would donate many beers if they halted all VB work and put those guys and gals on F#!
It never was and never will be identical to C#. They share a lot but there are hundreds if not thousands of subtle differences between the two. It's just easier for people to 'think' that VB is just C# with a search and replace because... that's a lot shorter to say. If you were to look at the compilers themselves or try to write a perfect automatic conversion tool you'll quickly see that far from identical.
For example, VB Select Case and C# switch work nothing like each other.
Yes, they have a pretty dissimilar philosophy. XML Literals, different event handling/wiring, no need for event delegates, inline date declarations, explicit integer division operator, the Module concept, the My namespace, etc.
> If you were to look at the compilers themselves or try to write a perfect automatic conversion tool you'll quickly see that far from identical.
There's so much truth in this.
Telerik has a online conversion tool[1] you can us, which can batch convert entire code-bases. But a 1-to-1 straight conversion cannot be done with 100% accuracy, and the tool will tell you everywhere it struggles to figure out the right C# equivalent for the corresponding VB.Net code.
I've used this tool in the past to "eliminate" the last remnants of VB-code in our organization. And when you do a job like that, on that scale, you definitely notice the differences.
A quick list of things you can expect to cause troubles (from memory and may not be 100% accurate):
- The difference in VB global/C# static semantics.
- The (default & overuse) of late-binding in a typical VB codebase. (While that wasn't an option for me back then, this can now be overcome by using "dynamic" everywhere, but that's hardly idiomatic C#)
- VB Modules can cause issues.
- For a full conversion, you'll typically have to rewrite all code using the functions and operands only found in the Microsoft.VisualBasic namespace. Not all these have straight up C#/BCL replacements.
Etc etc.
For being superficially so similar, a conversion job is actually much more work than you would typically imagine.
And until VS2013 the IDE was nothing like either. I think with VS2015 both have mostly converged but I must say it is a bit of a regression for the VB IDE.
Read the source for the compiler and find all the differences. There are constantly minor semantic changes, like numeric conversions, double parsing, scope of generated temps in for loops, delegate conversions, Nothing, etc.
I just started typing this list off the top of my head and every time I typed something out I could think of one more thing. And these are just the ones I remember, so they're probably the ones that were annoying to work around in the compiler.
Legacy VB != VB.net. VB.net is just C# with the words replaced (although there are a few unique logic structures). Legacy VB code has to be ported to VB.net.
You should parse my statement as (legacy (VB code)) and not ((legacy VB) code).
At this point anything written in VB of any flavor is legacy. But it still needs to be supported. And as long as that is true, Microsoft has reason to support it.
In an ideal world, this would probably happen quite often, but on a large and complex code base, it also means throwing away the specific knowledge that might only exist in the heads of people who have already left the company, as well as throwing away the countless hours of debugging to get it working (even if "working" might mean "barely working").
From a management point of view, it means throwing away a large amount of money and then spending more money to replace the old code base, accompanied by the usual risk of whooshing deadlines and all that.
To a programmer it might be easy to see that a rewrite will save the company money in the long run, that can be difficult to sell.
Existence of VB.NET doesn't bother me at all. I develop exclusively in C#.NET but there is a lot of VB.NET language features I wish were available in C#.NET.
It's not about sneering a VB. I don't see the use of it in 2017. I started using VB6 in 1999 - 2000. I was a pretty good C and C++ programmer, I could do a little MFC, I was pretty good at writing COM and DCOM dlls in C++, etc. but I saw a real advantage of VB to getting used friendly GUI apps done and the IDE was pretty good. I would often wrap c++ code in ATL wrappers to create COM objects to use in VB.
But what's the real purpose of VB today? No matter how you look at it, either C# is just as easy as VB.net or VB.Net is just as complicated as C#. It seems just wordier and redundant.
Nowadays, do you use any language which is not C like?
Regarding VB, the language is used by many people whose main occupation is not software development, and even for those doing software there are many who find C# or similar looking languages aren't a panacea (I do, and have around 15 years of C# experience).
In some cases VB is also less redundant than C#, it has better type inference for example.
I'm sure plenty of pascal/delphi developers are also fine without C#.
You should understand that other languages than C/C++/C# make different syntax choices, and it is not hurting C# in anyways that such language exist and prosper.
Note that I had a lot of prejudice against VB but I came back from that perspective, and in the meantime, I feel additions to C# language push it in territory where the syntax is getting really noisy / clumsy (I've picked up F# so I use that it as a metric).
I'm just waiting for a robust VB to C# converter or at least a way to start moving code across gradually. For now, I'm locked into VB because of a huge code base that's all one giant assembly. It'd be great if you could put C# classes in a VB program (not as dlls), then we might see some VB programmers just stop using it for new features.
The sneering may be driven by those who are stuck in VB6. My company is still in the middle of replacing a huge VB6 code base with a C# web based system, and doing anything in VB6 with the VB6 IDE is a nightmare in comparison.
VB6 used to be awesome though; sure it's really long in the tooth now and doesn't fit into modern workflows but there was a time it was great for banging out apps. I did a lot work in VB6 and I even used it to teach my daughter programming many years ago.
But VB.NET never really seemed to have a point. Why develop a backwards-incompatible language with all the warts of VB? If it was originally much more closely compatible with VB6, you probably still wouldn't be stuck with VB6 code in 2017. And if it didn't try to be so but not quite VB6-like, it would make for better beginners and financial systems language.
There is a case for case insensitive languages (pardon the pun!). You just don't get to write a lot of useless bugs because you mistyped the casing of a particular variable. I see that all the time in C# live demos.
I've been doing VB6 conversion stuff for most of my career, so I definitely feel this.
I think the sneering is more driven by the sorts of people that think that programming shouldn't be easy/accessible to the untrained masses. There seems to be a lot of coding elitism/machismo/masochism out there.
Do you think VB.Net is in any way more accessible than C#? Or that any of those is less accessible than VB6?
The untrained masses have a way into getting hooked on tools that are harder but offer no benefit compared to many other stuff available around. It is very easy to hate those tools.
«Do you think VB.Net is in any way more accessible than C#?»
Having been a teacher's assistant on courses the answer is very clearly and emphatically: Yes.
It's easy to discount the accessibility of a syntax when you are already at the top of the learning curve, but the Algol family will always be tougher to teach/learn than the BASIC family. Punctuation is harder than you think. (Aside: partly why I think JavaScript is actually the easiest to teach in the Algol-inspired family for the benefit of having optional semicolons alone.)
«Or that any of those is less accessible than VB6?»
That's not an anecdote I have first hand experience with. I think there are a lot of cranky VB6 developers that sneer that VB.NET is worse and so much harder than VB6, but my gut tells me that that may be more the relative learning curve/gap in moving from VB6 to VB14. I don't think it is anywhere near as representative of the accessibility of learning VB14 as a first language. (I also think the more important question is the accessibility of moving from Office VBA to VB14, as it still seems for a lot of disciplines Office VBA is the most important first step towards programming.)
«The untrained masses have a way into getting hooked on tools that are harder but offer no benefit compared to many other stuff available around.»
I'm not sure what you are getting at here. I don't think VB.NET is any "harder" than C# and while VB.NET might not offer "more benefit" than C# (assuming you discount syntax/accessibility entirely as a benefit), it certainly is no worse than C# as a tool for a person to use.
> I'm not sure what you are getting at here. I don't think VB.NET is any "harder" than C# and while VB.NET
It was not clear by the comment, but I was not talking about VB.Net. This one is no worse than C# or Java, and I also don't see many people stuck on it.
That phrase applies much more to VB6 (even more in the day), and some others like PHP, or, going out of the generic domain MathLab (that used to suck, a lot, but doesn't anymore), and VBA.
> my gut tells me that that may be more the relative learning curve/gap in moving from VB6 to VB14.
As I remember it, there were lots of angry VB6 developers when Microsoft discontinued the "old" VB and told them to migrate to VB.Net. I vaguely remember there was some kind of online petition (although it was a long time ago, my memory might be playing tricks on me).
We ported a massive classic ASP site to VB.Net in 2003 and then several years later ported it to C#. My experience was that some devs did better with VB.Net (coming from classic ASP) than they would have jumping to C#.
It wasn't quite "open the site in the new IDE and fix all the squiggly underlined bits" but that was a substantial part of the mechanical effort.
Starting from nothing? Skip VB.Net and start with C# (assuming you're set on the CLR). Starting from VB6 and a novice programmer? VB.Net has advantages over C#, IMO.
It is certainly accessible to business people who's only early steps with programmming have been in VBA.
It is by the way an act of cruelty from Microsoft to only provide office users with a 20 year old language that hasn't been updated since the end of the 90s... What happened to VSTA??
Second this. Most people new to VB.NET these days are transitioning from VBA and would find C# far more difficult. Engineers in my office don't write much production code and therefore get to pick what they want to solve problems. Python is very popular and the .NET people are split in 1/2 between C# and VB.NET. The C# code is usually better as the people that choose it are more advanced programmers, but the VB.NET crew still crank out time saving tools and like it.
>"It is by the way an act of cruelty from Microsoft to only provide office users with a 20 year old language that hasn't been updated since the end of the 90s"
Office has support for multiple languages, not just VBA. The three that spring to mind are JavaScript, M and DAX.
The big difference with VBA and javascript / third party solution is that I can send a xlsm spreadsheet to a colleague or another company and he will be able to run it just as well as me, I don't need to spend the next 5 years doing the support of how to reinstall the addin that is required to make it run.
Yes, that's why I said "if you don't mind using 3rd party solutions". If 3rd party solutions aren't suitable in your workplace (some workplaces would only need the extra features in internal-only documents, meaning the add-in installation could be managed by a single IT department rather than by individual users) then the Microsoft solution that's being planned is more relevant.
I've learned both C++ and C#, and I ended up writing my home automation system in VB because it just came more naturally to me, and I can write code that does what I want faster with it.
The side perk that I can relatively easily convert to C# later if I have to is there. But yeah, as much as I've worked in C style languages before, I find VB much more comfortable.
Seriously, sneering at VB6 in 2017 is elitism? Using it today comes with countless drawbacks, but is actually not any easier than using C#.
I used VB6 for all my Windows applications when my alternative was to use C++ + MFC or Win32 which was significantly more difficult. There was an actual advantage. Today, there is no advantage whatsoever.
Sorry, no, my intended tone was that sneering at VB14 (VB.NET 2015 edition) today was elitism. VB14 is a good language on equal footing with its peers, but there seems to be a lot of antagonism to it simply because it still tries to be new programmer friendly-ish.
(I agree that VB6 is a relic of the past that is no longer a viable programming platform.)
Previous company had a couple large programs, all in VB6. Back in the Windows 98 days, one of the accountants literally bought a copy of "Teach yourself Visual Basic in 21 Days", and wrote the first version of one of these programs. He had no formal computer science training or other programming experience.
Well, other people in accounting borrowed the book and built more and more features into this program, and created a couple other similar programs.
At no time did they consider 'maybe we should bring some real programmers into this' or re-write any of the code, and now they're stuck on this code and they have 4 'very bad' programmers working on it. It's a huge buggy mess with every bad programming practice you can think of.
Given (MOS 6502) Microsoft BASIC was the company's first product, BASIC has been such a deep part of the Microsoft DNA, I couldn't imagine Microsoft discontinuing VB. I'm not sure a BASIC-less Microsoft would still be Microsoft. It almost seems easier for me to imagine a Microsoft without Windows than one without VB or some successor to VB.
I've had to pick up a couple of VB.Net projects. They've both been poorly written, badly implemented and years if not decades behind the time.
There's a reason for the sneering. One of those I've virtually completely rewritten in C# and the code base is now like 30% of the TLOC. Not because of the language, but because of the type of programmer who started a new project in VB.Net in the last 5 years.
For all intents and purposes the languages are virtually interchangeable, though C# is generally more succinct and somehow "better" to me. I don't even really think about it when switching between the two.
UK projects, for reference, where .Net has always penetrated further than Java.
I also still get an inordinate amount of calls because my linked in profile list VB.net asking to 'upgrade' a project from VB.Net to C#. Then again, the salesforce offers I get too... Ugh, much worse than VB.Net.
Seconded. Though I don't really understand what is their message on VB in plain english. They will continue supporting it but won't be adding new features like they do in C#? Am I right to read it this way?
I'm translating a giant pile of Excel w/VB macros into Python at the moment and am not exactly having fun. The ugliness isn't really VB syntax as much as the interactions with and organization into the underlying sheet.
But I can't argue with the fact that it did do it's job for a long time. And I've learned to not underestimate the value of something that is known to work.
Its not for backwards compatibility, is for beginner friendliness of a eco-system. If one had a stroke and lost all knowledge on comp-science- what would you be more likely to drop for overwhelming complexity and missing instant results? C# or VB?
For a language that has both "And" and "AndAlso" as keywords; I don't think VB.NET should be considered the paragon of beginners languages.
It might have "Basic" in it's name but the complexity of smashing old-school VB syntax and semantics with .NET syntax and semantics has not made for a very beginner friendly language. It's more complex than C# (excluding some of the newest C# features). It's just painted over with a more English syntax to appear beginner friendly.
How is it far more complex than C#? Both have been designed at about the same time and VB.net has broken backward compatibility precisely to get rid of legacy design decisions. But both have evolved since. And yes you can use a generic and non generic version of a class. Yes you have old style async and new async/await versions of methods. Yes you have explicit typing vs type inference with two ways to do the same thing. And yes you can use lync as an expression or as chained functions. How is that different from C#? Both have evolved pretty much side by side and have as much legacy.
The one thing in my opinion that has been preserved from VB6 and is dangerous as ambiguous semantically is the following:
Dim x as Integer
Means declare a variable x and instantiate it to zero
For i = 1 to 10
Dim x as integer
x += 1
Next
The second line means declare x as integer but only instantiate it to zero the first iteration, the second iteration the instruction will be ignored.
Basically you answered your own question. VB.NET has all the same features as C#, evolved over the same time, but VB.NET has a bunch of additional "crap" held over from a language and environment that it isn't compatible with anymore. That's how it's more complex.
You didn't even consider in your example that you declare variables with the keyword "Dim". Do you even know why? It's meaning has almost been lost to history and makes little sense for what it's used for now.
In VB6/VBA, the Dim New syntax actually had different semantics; it would create the instance on first access instead of when the Dim statement was executed. It also had the fun side-effect that setting the variable to Nothing would destroy the instance but anytime you accessed that variable it would just create a new one. Irrelevant now, I guess, but still a nice bit of trivia.
Right, but it was introduced to C# over 8 years ago so it's a bit of a moot point, wouldn't you say?
`Dim`, a poorly worded keyword by today's standards, is a perfect example of the kind of leftover crap that C# doesn't have today that VB still does have.
I must admit that many VB.NET keywords more closely represent their respective concepts than C# does, but having far more C# experience, those VB.NET keywords initially strike me as seeming like baby-talk.
I think VB6 and VB.NET are totally different beasts. VB6 is maybe a good language for beginners but VB.NET is just a weird language in my view. C# is a much more natural fit for the .NET runtime.
So the big change there is to VB, right -- instead of being a language co-equal to C#, they're refocusing it to be beginner-focused, and are explicitly saying it won't have the same capabilities as C#.
I think that makes a lot of sense -- it was always weird to have two near-identical languages to choose from -- but at the same time, I wonder if VB.NET isn't already too complex to be an accessible language for beginner-programmers in the way that PHP or VB6 were.
I learned on VB.Net maybe ~15 years ago now, and back then all the english like 'end sub' and 'end if' really really helped me understand the code. Honestly languages that used brackets looked like voodoo to me at the time. Of course later when I understood that brackets were faster to write and conveyed the structure just the same, I converted and became a sneering hipster.
languages that used brackets looked like voodoo to me at the time
Hah, exact same here. I started with VB5/6 and it was so much easier to build a graphical Windows app than using scary C++ MFC. In VB6 you could just drag your "Winsock1" over to your "Form1" and start writing networking code quite easily.
Honestly though, to add some sneering hipsterism, Visual Studio is light-years better these days if you're just trying to crank out a basic app. So it does confuse me why anyone would choose VB.NET now over C#.
I don't think anyone has ever typed End If in visual studio. The VB IDE always had very proactive statement completion, that the C# IDE only recently matched. All you end up typing is "for i=1 to 10", press enter, not worrying about the casing and the IDE does the rest. To me the quality of the IDE makes 50% of the quality of a language and the VB.net IDE was superb.
I may be a VB.NET stalwart, but I have evolved to ensure my code is clean and properly declared, and I wish that all my VB.NET colleagues had done the same, then maybe it still wouldn't be seen as C# ugly step-sibling.
Why don't I switch to C# ?
1) I don't code professionally these days, only as a hobby.
2) I can't see the point of having to put semi-colons at the end of lines, when you immediately follow them with CRLF anyway.
3) Curly brackets are too easy to miss in the middle of code for these old eyes.
Right now, there's almost no app that's written in C# that can't also be written in VB.NET.
I think I had gotten stung previously with VB6s loose typing (everything as a generic object unless declared otherwise), so when I switched to VB.NET I made a point of declaring everything (and still do).
yeah it took me a while to get rid of bad VB6 habits too. Hungarian notation, specifying byval in front of every arguments in a function, not relying on type inference, etc.
Yeah - feels too late to turn that ship around. If you instead focused on making a VB6-like language that just had enough features to interact cleanly with most .NET APIs... you'd end up in a very different place today than where VB.NET has been taken by its attempt to have every C# feature implemented with just a different, more wordy syntax. Especially as you could lean on a lot of the DLR functionality to provide VB-like 'variant' types.
They need to replace VB with JS. JS is by far a better dev experience and there are more learning resources for new programmers (not to mention that there are way more JS devs than VB devs). It would also give them an excuse to push their JS engine more (I'm no fan of MS, but their new JS engine is a great piece of tech).
Good on Microsoft for writing about their strategy in such a clear, concise way. More of this style of writing, please, Microsoft! C# is, indeed, a real treat. I've been in love with it since 2001 and that shows no signs of changing any time soon.
It's nice to see their strong continuing support for F#. I'm no longer in the .NET ecosystem but when I was learning F# and using it day to day was some of the most enjoyable paid programming I've done
I wouldn't call it strong continuing support. F#'s been a second class citizen both in resources given and marketing support. Community effort is great, but as long as MS pushes C# as the flagship language instead of giving it the equal-or-lesser footing it deserves, F# can't truly pull ahead.
It's good to see C# catching up with the past decades of language research. Maybe it's MS's DNA - they're still heavily pushing C++.
Tooling is the only real reason to ever use C# over F# - C# just doesn't do much (anything?) better. That, and legacy/enterprisey dev.
Heck, C# 7's tuple support is exactly what F# used to do, but then capitulated to MS's idea of making System.Tuple, a reference (heap allocated) type. Now in C# 7 since they finally got around to being a bit serious, they implement a new value-type tuple.
I guess we should be happy for any F# support we get. And indeed, tooling for functional languages is poor in general, so F# certainly leads...
You're seeing us strike a balance here. As I point out in the post, there are millions of C# developers, and tens of thousands of F# developers.
However, we think F# has awesome growth potential, and is great for .NET in general. So while we can't defend spending the same resources on it as we do on C#, we want to do what it takes to nurture it and keep it healthy and growing.
Being on the inside at Microsoft over the past years, it's been great to see more and more of the organization think of F# as part of the family.
Agree with other comments, back then MS invested a lot in C# while there was then way more VB users, now it should invest a lot on F# while there are way more C# users.
C# isn't going to dwindle because F# expands, if F# expands C# wins because F# has ability to appeal to developers on non .net platforms, where C# isn't seen as appealing, and F# has ability to bring outstanding projects and idioms to .net eco-system.
Take the returns on investment made with C# all those years and invest a fair share in F#.
The main reasons F# is not picking up have been stated, and I face this situation at my work where my use of F# is put on hold because Microsoft is not investing in it much and my colleagues have the feeling C# is "good enough" which is very short sighted perspective.
While I'm already one of the few that use F# full time, I think this is a rather self-fulfilling statement. Looking back in time, Microsoft has continually cubbyholed the language, almost to the point of counter-marketing its general purpose feature set.
Simply giving it a fair share per-developer after so many years of mismanaged commercial handling seems to fall short. You say yourself, F# has awesome growth potential and I'm sure you'd agree that the growth potential has been there for years now. Is this time around going to be different?
In my opinion Microsoft should focus more on base tools for F#, such as Roslyn, integration with dotnet core, etc.
Integration with Visual Studio is nice, but if the language is to be adopted in hacker circles, without major Microsoft investment, it needs to provide very solid and flexible tools on top of which the community can build awesome things.
Example of small things Microsoft can help with: as far as I can see Nuclide doesn't work with dotnet core (only Mono). Throwing 1-2 devs that way would pay good dividends, in my opinion.
> Example of small things Microsoft can help with: as far as I can see Nuclide doesn't work with dotnet core (only Mono). Throwing 1-2 devs that way would pay good dividends, in my opinion.
I don't know anything about Nuclide, but if they want to work with dotnet core, they should look into working with omnisharp-roslyn[0]. VS Code[1] and Atom[2] both have extensions that work with it.
> In my opinion Microsoft should focus more on base tools for F#, such as Roslyn, integration with dotnet core, etc.
I think there's already work underway for F# support for dotnet core[6].
As far as F# support for editors go, have a look at ionide[4]. They only have extensions for VS Code and Atom at the moment.
> Integration with Visual Studio is nice, but if the language is to be adopted in hacker circles, without major Microsoft investment, it needs to provide very solid and flexible tools on top of which the community can build awesome things.
Have you seen omnisharp[5]? If so, what's missing from that?
Think how many developers you could add by adding Higher Kinded Types to F#. You could poach a ton from Scala/Haskell land. Alas, many of us can't leave until that happens. :)
It really needs to be added at the dotnet level. I'd love to have it in C# as well. LINQ expressions should work on arrays, ienumerables, lists, iobservables, subjects, nullables, etc, basically anything monadplus, and return back what you passed in. It's silly to have to write the same expression for each of those cases, or to convert everything to ienumerable/iobservable and back by hand. I'm surprised they didn't take the opportunity to do that in dotnetcore. It's mainstream enough now that I'm curious why they didn't; whether the perceived need was low or whether there are other problems it would have introduced.
But that's a catch-22 isn't it? There's few users in large part from not just tooling but messaging. MS has pitched F# as a specialised language for scientists and financial work.
But I do appreciate the work MS does - F# is a leader in FP tooling. And C# is getting easier to deal with :).
You have a business to keep running, I respect that. But if you truely want to bring innovation to the regular developer, bump up your F# efforts.
It needs a significant effort to educate developers to develop in a truly functional way. You are on track to implement many FP constructs and patterns into C#, so I'm sure the F# efforts would not be wasted at all.
I think they do, and this is why they giving it any resources at all while admitting they only see it used by tens of thousands, compared to millions using c#
At the end of the day, MS is a big corp, decisions needs to be justified and supported by both quantitative and qualitative measures
Also on the bright side, in programming, more developers doesn't really mean it will evolve faster, actually with a smaller team f# may evolve faster, it this wasn't true no language other than c# or java would have stood a chance
I agree with the other comments as well, that treating F# as a second-class citizen is a self-fulfilling prophecy.
As someone who was telling myself, "One day, I should learn F#", this thread makes me pause.
Throw all your weight behind it, make it a first-class citizen, and Microsoft may be the first to make functional programming mainstream. That would be exciting.
I'd like to see more of a focus on extension methods rather than the pipe operator in tutorials and such, and tupled args rather than curried args. Also make the OO aspects more visible. It's not so much a language thing as a presentation thing. I think these are the things that confuse mainstream developers, and it's silly to present them all up front when teaching the language. Intellisense and C# compatibility works way better if you go this route too.
In four years full-time F# use, I still find standard LOB apps work better with an OO SOA structure at the high level. I've tried various methods of designing FP-style architectures for those apps but nothing has ever ended up nice and clean as a standard interface-based SOA (in F#) and a standard OO DI utility. At the low-level, F# is awesome for immutable records, ADTs, combinators, etc., in a way that C# would be hard to replicate just because the syntax would be so foreign.
So I think there's an opportunity for the F# market to explode as C# devs start to realize the utility of such things at the bottom level (and also for making interesting combinator-based libraries like suave). But in order to get there, I think the stepping stone has to be a change of emphasis in the F# world, to show off F# as a "better C#", starting with standard SOA-style OO-style frameworks, emphasizing a similar style (tupled explicitly-typed fn params, ext methods rather than pipe, C# naming conventions), and then just bumping the lower-level implementations of things and the domain model to ML style.
Going head-first functional-first I think leaves F# useful to just a handful of developers, where everyone else just wants their objects and DI frameworks back.
What exactly do you mean by "OO SOA structure at the high level"? Do you mean essentially a function from a document to a result? If so, then what exactly is object-oriented about it? I'm no expert on industry lingo, but "Service Oriented Architecture" sounds to me much more functional than object-oriented.
That you feel the need for DI frameworks is a great shame and more F#'s failing than functional programming per se. If F# had inherited the module system from OCaml, then there would be much less need to use objects. In OCaml, DI comes for free with module functors, no framework necessary. As it stands, I agree that you are somewhat forced to use objects as a module system, as F# has no other. That is what MS should fix.
I mean `class Database implements IPersist`, `class Redis implements ICache`, `class MyLogger implements ILogger`, etc.
So classes/interfaces to each service your app uses. I just use very basic autofac, declaring which implementations to use in code. (Really nothing I couldn't wire up by hand; autofac is just a tad less cumbersome).
I've heard about OCaml's module system and am intrigued by it but never used it.
When I was doing .Net full-time I really wanted to get into F#. But...
- I wanted to use it for websites. Sorry, not really supported in MVC.
- I thought it'd be great for doing .Net stuff in SQL-Server and SSIS, like you can with VB and C#. But it's not supported there either.
They always positioned it as "use F# for the extra hard stuff and C# for everything else," but in the end C# isn't terrible for hard stuff, and if that's what you use all day then for you, C# is probably better.
Not even just about web projects. Even standard GUI apps have no ready templates at least in VS 2015. Just Console apps. Even if guides online show how you can easily hack together both GUI apps as well as e.g ASP .NET Web API's!
I'd like to see some love there. These simple things introduces needless uncertainty about the language.
I feel like this was addressed a bit in the linked blog post: the support is getting better and it's now "in the family" as opposed to a primarily community and research-supported "toy".
I'm looking for the nearing releases where F# starts to share much more of the same Roslyn platform that C# and VB have been using for a while now. That should be some very interesting tooling to have at F#'s disposal.
C# is always going to be the flagship for the same reason that C/C++/Java/et al are still some of the most common programming languages in the world. That doesn't mean that we can't expect good things from F#, though.
It's worth mentioning that another reason C# is popular is because of the strong commitment to backwards compatibility. I can write something in C# and be fairly confident that it will still work a decade from now. That kind of reliability makes me willing to invest significant capital into C# development.
So we had this security app that needed to know what version of Windows it was running on. And the Windows detection worked flawlessly... until Microsoft came out with a new version. Our program detected the new Windows as the previously-most-recent version, even though we were calling the standard Microsoft-approved which-version-are-you function.
Turns out Microsoft detected that our specific app was asking, and lied to it, because telling it the truth broke the previous version of our app (because the previous version didn't know about the new version of Windows). It was annoying, and yet still incredibly impressive that Microsoft knew who we were and was going out of their way to try not to break us.
I've heard of nvidia doing similar things lately, patching their driver because of a bug in a game. I'm really not a fan of this approach, it's coupling on a global scale and adding a lot of complexity.
I remember hearing epic stories from ex-MS coworkers about the internals of CreateFile/Read/etc. All sorts of convolutions to keep back compat with things from the win31 and earlier days. Painful to work on as a developer but great for customers.
I can sing the praises of Microsoft's backwards compatibility twice! The first is the little graphics library that is abused by µTorrent since the 9x days, and HTML Applications that lets me run Javascript with full system access. That team is the unsung heroes of computing while (IMO) I'm breaking stuff all the time.
How much cruft is in the language because of backwards compatibility?
Java couldn't do generics right, for example, because they didn't want to break compatibility. C# seems to be adding a lot of improvements, but would it be better if they could break compatibility?
If that is to be done, there needs to be some legacy settings for the compiler. I'll happily, trade inconvience for the ability to completely abolish null from my code. I already use a Maybe pattern to avoid returning null, but I cannot avoid checking for null because it's so ingrained in the standard lib.
Microsoft took the hit and revamped the runtime when generics landed. I'm sure they would take another hit if such a critical feature presented itself and there wasn't a good way to retrofit it.
The only two warts that strike me off-hand are covariant arrays and System.Nullable being value-type only.
Overall Microsoft has done a great job of building on earlier decisions. Including functions as first-class types (System.Delegate) in V1 is probably the biggest and was a deliberate break with Java's approach. It has enabled a ton of features: lambdas, LINQ, Expression, etc. The fact that LINQ can be turned into an AST with Expression<T> means you can also construct code dynamically at a much higher level than IL.Emit() while delegates mean you can get the JIT to provide the equivalent of a function pointer to the native code.
The reason is that C# had a chance to learn from the experience of others and is still a relatively new language.
There is a little bit of cruft here and there. For example, ,NET had good threading support from the start, but the idioms that are used nowadays for concurrent and parallel programming have evolved, and while the old APIs are still there, developers now use APIs that are more up to date.
It's kind of a tradeoff, right? How many years worth of work are you willing to rewrite, just to get rid of a little cruft? Choose your language wisely and you'll have no problems.
You are assuming that the changes would take years. Doesn't it really depend on the changes? Some could be automated? Perhaps a switch/flag could be set within the language itself. If C# became safer, for example, how would you weigh the tradeoffs?
> That would be huge, and worth any amount of hit.
I'm open to the idea that non-nullable references (by default) could 'be worth any hit', but I'd like to see the evidence. Have you tested converting a large codebase to non-nullable, and seen a reduction in errors as a result?
I have. Obviously it's not possible to do this completely in C#, but my team has moved over to using Option, Try, and Either types for values that might be null or throw exceptions. We've noticed a reduction in what we all knew was the single most common bug: null reference exception. It also reduces cyclomatic complexity [1], which is a fairly well understood measure of complexity and therefore bugs.
Anecdotally I've noticed a reduction in these kinds of issues when using languages that use non-nullable references by default (F#. Haskell, etc.). I find I am much more confident as a programmer when nullable references aren't the default. Actually a few days ago we had our first null reference error in F#, and it was because the record type passed to an F# function was instantiated in C#.
If you think about it, the idea that a statically typed system lies to you about the contract that a value will honour is always going to be a source of bugs. It takes static languages back into the realm of dynamic languages.
- F# is poor for relational databases. (Also, I try several ORM-ish/type providers but only "work" for sql server, and in windows).
- F# is poor for web projects and
- F# is poor for mobile development.
I'm sticking with F# because I'm that much against C-based syntax, not because I logically noted that C# is the only language that truly matters in .NET and I waste more time I wish to trying to solve everything with F#. Also, I'm a solo developer.
BTW, I use python, F#, swift, obj-c, delphi and have used Visual FoxPro and others languages that are smaller and expected to have limited support. Among all of this, F# is the one that cause more trouble (because tooling and ecosystem).
But is just a joy when things work. And the massive reduction in code pay for it. It only need some love to polish around the edges.
I'm aware of all that options, and have tested them. In fact, I have tried to use xamarin+f# for mobile for a year.
Now is a better (even have F# templates!) but is clearly a second class citizen.
--
Is not the case of Core that F# integration is black magic, or this has changed in last release? All apis work now for F#? For web I try like 6 months ago and only suave was more or less usable (however, is hard to find how solve some stuff. NOTHING (in the open source options I test) is close to Flask/django in this case, and asp.net was sub-par when I test it.)
--
I also agree that F# need more push from MS. My complaints, like much others, are about things that just need more polish and tooling - and if it get more competitive in performance with C#, better -. So I think is good to see this .NET strategy and think F# have a good future, to the point that F# is the only reason I come back to .NET.
Is only, I wish not just a good future. I want a AMAZING future!
Consider contributing to a type provider for the database engine of your choice, I use SQL Server and F# is a better choice than C# in this regard anyday because of the type provider library that was created by community.
Seeing as this is a comment thread all about VB, an anecdote:
A few weeks ago, I decided to convert the 300 or data CDs and DVDs to ISOs - there's no point keeping large stacks of discs around these days - especially now that most OSs allow you to natively mount ISOs as virtual drives.
I wanted a quick and easy one-click ISO creator (for Windows), so hunted online for one, and couldn't find a good free one, so turned to Visual Studio to knock up my own utility (as I tend to do often).
Not wanting to waste too much time on this (after all it's a one-time ripping project) I found some C# and VB.NET partial code examples of how to stream the data byte by byte off the disc, and into an ISO file.
Try as I might, I just could not get the code to work. Again not wanting to waste too much time, I remembered I'd also seen some VB6 code snippets during my searches.
I fired up a VM that has VB6 installed (as I never use VB6 anymore), and threw in the snippets, and 10 minutes later I had a rough cut of the utility ripping it's first disc to an ISO.
People are very quick to decry older technologies, but if they still work, and take less time to use, then where's the harm?
Screenshot of the util (that happily converted over 300 random data discs over the space of a few days, without error):
I agree with you. If I remember correctly there is also a x86 debugger written in VB. And I claim that those who write C++ by using all the "boost" they can in fact just use too much energy to write VB-style in C++ (or Python style, or Java style). And once they achieve that, having a separate allocation for everything, reference counting etc. even the performance converges, once the allocation patterns are similar.
All that being said, for the task you needed, have you seen ImgBurn? It's a native application, written in Delphi. There's a button "create the image file from disc."
I have ImgBurn installed, and use it a lot, but i needed the 'play a sound when done' and 'eject when done' features - as they really help with bulk rips if you are doing something else at the same time.
I also know from experience, that the simpler the UI, the faster repetitive bulk tasks become - years ago I wrote something similar for Audio CDs when I was ripping my (at the time) 500+ music CD collection.
> but i needed the 'play a sound when done' and 'eject when done'
I believed both are present in ImgBurn, see Settings/Read/Page 2 "batch mode: eject tray before next read" and Settings/Sounds "Play sound after read"?
Wouldn't you in ImgBurn just have to put the next disc once the previous is finished, it would even detect when you close the tray and continue automatically with the automatic name, you wouldn't have to click anywhere in the GUI?
Totally agree. If someone paid me to write something, I'd do it C#. I'd moan and grumble about it, but still I wouldn't use VB.NET as the Article says - millions of people use c#, and only a hundreds of thousands use VB.NET.
I can code adequately in many languages, I just seem to be more comfortable in any dialect of Basic.
It's unlikely, but it would be great if Microsoft would take ownership of the .Net port of Clojure. If there are two official object-oriented languages in the .Net stable; C# and VB.NET, why not two official functional as well; F# and Clojure?
Given Arcadia, the Clojure bridge to Unity, and Microsoft's interest in Unity via its Unity Tools, there might be some synergy there.
C# and vb.Net are not so much two languages as they are two grammars for the same language. Their ASTs are practically equivalent, bar some minor vb idiosyncrasies, holdouts from the VB6 days. I would be surprised if there were any organizational overhead to speak of for MS in maintaining the two.
Clojure and F# are fundamentally, semantically different.
(not arguing for or against, just giving some background)
I would be surprised if there were any organizational overhead to speak of for MS in maintaining the two.
I sure wouldn't, because I worked on the VB.NET compiler team back in 2008-2009, and "organizational overhead" was pretty much the whole game. The VB and C# compilers were completely separate codebases, managed by parallel but non-overlapping teams of engineers. We never touched the C# compiler's codebase, and the C# people never touched VB. (I did once read through a piece of the C# compiler source code, to see how they'd implemented a feature I was supposed to be reimplementing for VB, so I could be sure to use the same semantics: but that was it.)
We had lots of meetings, though. Oh, god, so many meetings. So much time burned keeping all those parallel projects in sync. Whatever commonality the languages have occurs through endless soul-crushing hours of almost-pointless meetings sorting out how these two separate pieces of software are both going to be modified to do pretty much the same thing, with almost exactly the same syntax. Every new feature had to be designed twice over, implemented twice over, tested twice over, and documented twice over. They may look like twin languages, but the illusion is maintained via massive, ongoing investment of sheer brute force man-hours.
Maybe things have changed since I was there, but it's really difficult to imagine how that could happen. The VB compiler was effectively legacy code, a horrible creaky mess of ancient patched-together bullshit, and nobody wanted to touch it any more than necessary for fear of breaking something. Refactoring was totally out of the question. I cannot imagine an organization as sclerotic as devdiv managing to rally the effort it would take to rewrite it - safely! - such that the VB and C# codebases could be combined far enough that they would no longer need to have a separate VB compiler team.
Muscle memory is why microsoft opted for curly brackets for C#, to make it familiar to java and c developers. Muscle memory is raw productivity. It does matter.
Particularly for a population where a large part (including me) are not professional developers and do not have the time to learn new languages. The time you spend outside of your job learning new languages, is the time we spend doing some programming outside of our job.
> It's unlikely, but it would be great if Microsoft would take ownership of the .Net port of Clojure.
Yes please. Maybe not join the direct CLR port, but rather a "clojure like" language implemented in fsharp, with repl/interactive development, a bit more syntax, immutable data, amenable to dotnet native, and fix clojure warts like bloated core namespace, startup issues, etc..
this would be great, with more and more people learning about functional programming techniques, C# with a functional leaning is really nothing compared to F# with support for OO. It's like the premium language from MS but feels not so loved.
I met a programmer from an antique land
Who said: Two vast and trunkless legs of code
Stand in Redmond. Near them, on the sand,
Half sunk, a shattered language lies, whose IDE,
And DLLs, and ActiveX controls,
Tell that its sculptor well those passions read
Which drive market share, stamped on these lifeless things,
The server that mocked them and the client that fed:
And on the retail box these words appear:
'My name is VISUAL BASIC, king of kings:
Look on my works, ye Mighty, and despair!'
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare
The lone and level sands stretch far away.
.Net language strategy is to have no long term strategy. They just react to the market, and don't care that much about anything else. VB6 was a great eco-system, had most developers in the late 1990s yet they managed to completely fuck it up. dotNet and it's VB.Net was a bad joke until 2003, and after years of announcing and hot air it was incompatible, and the Wizard to convert was a Lite version from a third party vendor. Many stayed VB6 and changed to the web, or also also looked at Java alternative C#. But the RAD development is a day of the past. Nowadays building a UI app is certainly more effort than in VB6 days. Anyway, nowadays web apps and Android and iOS are in, WinPhone is dead and desktop apps are out.
> dotNet and it's VB.Net was a bad joke until 2003
Considering that VB.NET was released in 2001 (or 2002, Wikipedia disagrees with itself on this point), it was a "bad joke" for 2 out of the 16 years of its existence so far? That doesn't sound that bad to me.
Unfortunately, PowerShell lacks support for asynchronous programming. This has been a huge deal for me when trying to interface with newer .NET I/O-related assemblies, some of which only expose their methods as async.
PowerShell is the recommended shell language. But I don't think it is considered a first-class .net language because Visual Studio does not have built-in support for it.
You can almost do this in C# now [1]. It's ad-hoc polymorphism rather than full on type-classes, but it does facilitate generic programming in a way that I've not seen used in anger before.
For example, here's a definition of a super generic function that takes a functor of string and maps it to a functor of int.
public static FB ParseInts<Functor, FA, FB>(FA input)
where Functor : struct, Functor<FA, FB, string, int> =>
default(Functor).Map(input, Int32.Parse);
The secret to it working is the constraint that constrains Functor generic argument to be a struct and a Functor<FA, FB, string, int>. The struct bit means I can call default(Functor) and get a valid reference back (because structs can't be null).
I can then call it with a List:
var list = List("100", "50", "25");
Lst<int> res1 = ParseInts<FLst<string, int>, Lst<string>, Lst<int>>(list);
FLst and FOption are essentially the 'class instances'. Functor is the 'type class', it's just a C# interface [2]:
public interface Functor<FA, FB, A, B>
{
FB Map(FA ma, Func<A, B> f);
}
The key thing is that 'this' won't be used, so the first argument is the value to be mapped.
FLst looks like this [3]:
public struct FLst<A, B> : Functor<Lst<A>, Lst<B>, A, B>
{
public Lst<B> Map(Lst<A> ma, Func<A, B> f) =>
ma.Map(f);
}
And FOption like so [4]:
public struct FOption<A, B> :
Functor<Option<A>, Option<B>, A, B>,
BiFunctor<Option<A>, Option<B>, Unit, A, B>
{
public Option<B> BiMap(Option<A> ma, Func<Unit, B> fa, Func<A, B> fb) =>
ma.IsNone
? fa == null
? Option<B>.None
: fa(unit)
: fb == null
? Option<B>.None
: fb(ma.Value);
public Option<B> Map(Option<A> ma, Func<A, B> f) =>
ma.IsSome && f != null
? Optional(f(ma.Value))
: None;
}
As you can probably tell, the amount of clutter from specifying generic type-parameters that the compiler could (relatively) easily work out on its own, is pretty annoying. Which limits it's usefulness somewhat. But if you want to write truly generic code, it's doable (with some caveats of course. you'll notice that the Functor type isn't quite as strict say the definition in Haskell).
I'm currently updating my language-ext project to add type-classes [5] and class-instances [6], in the hope that the C# team will take pity on me and make this technique a language feature (it's been seriously turning my head inside out trying to make it work with higher-order types like monads).
This is already being investigated by some Roslyn team members [7]. I figured this feature was unlikely to move seriously in the near term without some indication of real world need.
VB for me was the gateway to the modern .NET programming. Back in school, I've started with VB6 and moved to VB afterwards. The transition was somehow seamless and made me understand the .NET ecosystem better. When I was learning C# I had to first write my code in VB and then try to port it to C#. That was just my way of learning things. It happen to be useful since now I'm fluent in both when I need them.
I have been trying to read planning docs, github issues etc and I still can't find if my one pet feature is planned or requested for C#: proper exhaustive pattern matching for records/tuples.
Tuples, records, etc are all find and dandy, but what I want is propoer safety when adding a variant, otherwise they don't really help me reason about my code.
What I would like to see is a dedicated REPL application (likely based on the scripting dialect of C#) with IntelliSense and support for NuGet packages (if you want to have those features in LinqPad, you have to pay).
Kind of similar to Xamarin Workbooks, but better, and without all the "it's for documentation and inspecting applications" cruft.
Not a dedicated REPL app, but there's an 'interactive window' for c# in VS 2015, it has IntelliSense (but no NuGet support, which might be added in the future.)
https://github.com/dotnet/interactive-window
I would recommend Microsoft to name their environments and languages such that you can meaningfully search for them in Google. I could be wrong, but I can't imagine searching for ".net" or "f#" gives any useful results.
Microsoft has been trying to kill Visual Basic since 2005. It's like a zombie. Credit to Microsoft for keeping customers and users of the language happy.
>"Microsoft has been trying to kill Visual Basic since 2005"
Where do you get that idea from?
Perhaps it's because of confusion over the name Visual Basic. Microsoft have deprecated VB, but not VB.NET. The name 'Visual Basic' has been applied to both, but they're not the same language. Microsoft's support for VB.NET is stronger than F#, and second only to C#.
VB actually GREW in popularity in the last two years. By the way, VB is supported until 2024. That should be enough time to switch to VB.NET, right? :)
> VB actually GREW in popularity in the last two years.
Or people have been using the term "VB" to to refer to VB.NET as old-style VB falls out of the general consciousness, distorting Tiobe's web search engine based methodology for generating ratings.
There will be runtimes for VB until 2024, but that's far from calling it "supported". The last language release was 19 years ago, in '98, and the IDE stopped being supported in 2008, 9 years ago.
AFAIK supported means that they'll bundle VBRUN600.DLL (and other relevant files) with new Windows versions and make sure those work fine.
After that you'll have to do that yourself and rely on normal Win32 backwards compatibility. It doesn't mean it'll stop working (e.g. you can run 32bit VB4 on 64bit Windows 10 just fine).
Microsoft has always been a polyglot corporation. Just because not all of their code is/will ever be managed code/.NET doesn't mean that Microsoft would abandon all of the good work that has gone into the .NET platform, its languages, managed code, the CLR platform...
.NET is still the "third pillar" of modern application development on Windows devices in the UWP and .NET is also more cross-platform than ever with big investments into Xamarin tooling (now a first party part of the Visual Studio team/Developer Division) and the open source, cross-platform .NET Core runtime.
Your missing out. C# is a really great and productive language. And with the advent of .Net Core it's cross platform and open source. What's not to love?
Tooling outside of Windows is really bad. I'm not completely discounting VS Code, they have been doing great work and might improve big time, but currently it's not an option.
MonoDevelop seems quite nice. I have only used it for F# but just the fact that its F# interactive has intellisense and syntax highlighting gives me good vibes.
I have tried both. VS Code lacks too many features still that are necessary for dealing with C# comfortably, while Rider is still immature (and isn't free).
What features are you missing? I've been using VS Code for 4 months now on a daily basis and can't say I'm missing anything outside of some Nuget package management tools, but I'm not sure if that's available to me and I just don't know how/where yet.
Were you using .Net Core, or .Net 4.X? The latter is all the C# I have to work with (mostly ASP.NET stuff), and that was pretty poorly supported last time I tried it; requiring me to roll a lot of files manually and so on (e.g. no "create new X page" style contextual options, no way to build project from editor and so on).
I'm writing an asp.net core app, my host os is macOS.
I initially setup my project with yeoman which created the footprint for me, but after that I've been manually creating files. You're right that it would be nice if it would create the file footprint for me but its only a couple of lines to add the namespace and class so it doesn't bother me too much, especially if you're used to text editors in general (I've used both a range of text editors with scripting languages and vs.net full in the past).
You can build via cmd+shift+b on mac, I assume swap the cmd for ctrl on PC, run is F5. These require properly configured launch.json and tasks.json files. cmd+shift+p brings up the command palette which lists everything you can do and their shortcuts.
The main things that make it viable for me (and differentiate it from a standard text editor) are intellisense, find references, rename symbol (method name, variable etc) and step through debugging. Without those id probably be leaning towards full VS on Windows or more likely for my particular situation Java being that I need to deploy initially to Ubuntu.
I do like the way Project Rider is going but I've found it a little buggy when debugging, so keeping half an eye on it as it progresses for now.
