The .NET Language Strategy(blogs.msdn.microsoft.com)
blogs.msdn.microsoft.com
The .NET Language Strategy
https://blogs.msdn.microsoft.com/dotnet/2017/02/01/the-net-language-strategy/
274 comments
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'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.
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.
I'm all for maintaining backwards compatibility but I've coded in both and VB is just an inferior language. Sorry :)
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.
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:
That to me is unintuitive.
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
For i = 1 to 10
Dim x as integer
x += 1
Next
That to me is unintuitive.
> How is it far more complex than C#?
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.
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.
How is "Dim" worse than "var"???
In fact even before type inference I always thought that Dim was a better idea. It was kind of absurd to be forced to write your type twice.
In fact even before type inference I always thought that Dim was a better idea. It was kind of absurd to be forced to write your type twice.
Dim D as New Dictionary(Of String, String)
Dictionary<string, string> D = new Dictionary<string, string>();> How is "Dim" worse than "var"???
Var means variable.
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.
Var means variable.
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.
You don't write your type twice in C# either. So, the second example would be:
var d = new Dictionary<string, string>();
As I said, var was introduced with type inference. Before type inference you had to declare it twice, which you never had to do in VB, even in VB6.
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.
`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.
Try defining an instance member with var in C#
I laughed as I read your comment (not the way you intended).
"Try VB.Net, the perfect language choice for stroke victims."
"Try VB.Net, the perfect language choice for stroke victims."
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.
[deleted]
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.
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.
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.
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.
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.
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.
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.
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).
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).
Yes, it's in VS User Voice page [0] and surprisingly there's people commenting even tho it was decline.
[0] https://visualstudio.uservoice.com/forums/121579-visual-stud...
[0] https://visualstudio.uservoice.com/forums/121579-visual-stud...
> I also think the more important question is the accessibility of moving from Office VBA to VB14
VBA 6 is exactly the same language as VB 6, with the same IDE. VBA 7 (the current version) adds some new types to support 64-bit mode.
(I'm currently maintaining a bunch of VBA code in a third-party application that uses it for scripting.)
VBA 6 is exactly the same language as VB 6, with the same IDE. VBA 7 (the current version) adds some new types to support 64-bit mode.
(I'm currently maintaining a bunch of VBA code in a third-party application that uses it for scripting.)
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 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.
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.
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.
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??
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.
Office has support for multiple languages, not just VBA. The three that spring to mind are JavaScript, M and DAX.
You can't really write UDF in javascript, it's nothing like the VBA integration. (and on a personal note, I still prefer VBA over javascript)
UDFs aren't the only reason VBA is used, though if that's what you're interested in it looks like Microsoft are planning something new in this area:
http://stackoverflow.com/a/40727011
Also, if you don't mind using 3rd party solutions, you've got other options:
http://fcell.io/
http://xlloop.sourceforge.net/
http://stackoverflow.com/a/40727011
Also, if you don't mind using 3rd party solutions, you've got other options:
http://fcell.io/
http://xlloop.sourceforge.net/
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.
Also a somewhat limited version of SQL.
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.
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.)
(I agree that VB6 is a relic of the past that is no longer a viable programming platform.)
Yeah, I'm sure everyone hates VB6. That's why the last stable release was 19 years ago and the IDE stopped being supported 9 years ago.
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.
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.
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.
Even without Visual Basic .Net, MS would still have Visual Basic in MS Office and that will be around probably until the end of time
Not just that, it was BillG who wrote the code for that. Not going deeper in MSDNA than that.
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.
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 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>.
Simply one's own taste, I suppose.
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>.
Simply one's own taste, I suppose.
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.
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 :)
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.
Hey man, me too! Almost same story, pirate CD. Though it was VB3 for me. Used to make AOL chat bots and mass mailers.
What did you build back then?
What did you build back then?
Isn't it great to note that we're now in an atmosphere where you can just... download Visual Studio... no piracy required?
I spent months getting my MSDN license personally assigned so I could get a copy at home for playing around in. So bitter...
(it's awesome)
(it's awesome)
I collected those for a while. What was your handle or group affiliation?
I have to still maintain some things running on VB6 code. It has it's whims, but there are worse things to work with as well.
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 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 think Small Basic is interesting for that. [1]
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).
[1] http://smallbasic.com/
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).
[1] http://smallbasic.com/
You might want to look at PyCharm (Has free community edition, $99 year for pro) and Python. My eight year old writes Python!
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
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
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.
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.
I started with similar tools: Borland Delphi and the Object Pascal language.
I'm not really sure of the timeline, but I think Delphi pioneered the "reusable components" paradigm and VB was Microsoft's entry into the market.
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.
It's not just hipsters ;)
All joking aside, VB.NET has solved a lot of problems for companies.
All joking aside, VB.NET has solved a lot of problems for companies.
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.
#TrollsArePeopleToo :-)
#TrollsArePeopleToo :-)
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.
Hey, thanks! If they let me out of my cave again, I'll make a point of visiting more often!
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#!
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.
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.
[1] http://converter.telerik.com/
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.
[1] http://converter.telerik.com/
Isn't Microsfot.VisualBasic just as much part of C# as it is VB or any other .Net language?
The rest of your points all sound like bad practice anyway so hopefully people are already avoiding them.
The rest of your points all sound like bad practice anyway so hopefully people are already avoiding them.
> The rest of your points all sound like bad practice anyway so hopefully people are already avoiding them.
Welcome to the real world. I can tell you're new here :)
Welcome to the real world. I can tell you're new here :)
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.
Hundreds or thousands of differences? Do you have a citation for that?
He is the program manager for VB...
While I was/am a bit incredulous at the number I was hoping for some sort of list or summary. Just sounds like a lot.
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.
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.
Even so... with numbers like that we need proof!
As long as paying customers have legacy VB code, Microsoft has a very good reason to continue supporting VB.
Companies generally spend a lot more money maintaining legacy code than they do creating new code.
Companies generally spend a lot more money maintaining legacy code than they do creating new code.
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.
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.
Or throw it to the trash and rewrite 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.
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.
Never having touched VB.Net, that makes me kind of curios: Would you care to name a few of those features?
better type inference for anonymous functions, better type inference for instance members.
Another big feature is code layout being more compact and consistent than in C# codebases.
Another big feature is code layout being more compact and consistent than in C# codebases.
Thanks!
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 read it as "we will be adding features that make sense for VB (which might also make sense for C#), rather than keeping it in sync with C#".
Allowing it to evolve on it's own, rather than being C#'s ugly little brother.
Allowing it to evolve on it's own, rather than being C#'s ugly little brother.
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.
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.
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.
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.
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'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.
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.
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.
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).
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.
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...
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.
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.
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?
I hope so.
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?
I hope so.
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.
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?
[0] https://github.com/OmniSharp/omnisharp-roslyn
[1] https://github.com/OmniSharp/omnisharp-vscode
[2] https://github.com/OmniSharp/omnisharp-atom
[3] https://github.com/Microsoft/language-server-protocol
[4] http://ionide.io/
[5] http://www.omnisharp.net/
[6] https://github.com/dotnet/netcorecli-fsc
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?
[0] https://github.com/OmniSharp/omnisharp-roslyn
[1] https://github.com/OmniSharp/omnisharp-vscode
[2] https://github.com/OmniSharp/omnisharp-atom
[3] https://github.com/Microsoft/language-server-protocol
[4] http://ionide.io/
[5] http://www.omnisharp.net/
[6] https://github.com/dotnet/netcorecli-fsc
About F# and .NET Core, you can read more info (usage/bugs/workaround) in the wiki https://github.com/dotnet/netcorecli-fsc/wiki/
The only ide who support f# and .net core is VSCode (with Ionide extension who add f# support)
see
- https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... for LTS of .net core 1.0 (project.json)
- https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... for msbuild based (latest bits)
The only ide who support f# and .net core is VSCode (with Ionide extension who add f# support)
see
- https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... for LTS of .net core 1.0 (project.json)
- https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... for msbuild based (latest bits)
I meant Ionide. Ionide works with/on Mono.
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.
My reply here [1] may be of interest :)
[1] https://news.ycombinator.com/item?id=13547181
[1] https://news.ycombinator.com/item?id=13547181
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 :).
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.
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.
Preface: I really love what you guys are doing but...
I really don't think you guys appreciate how many Scala/Clojure/Haskell devs would love to work in F# but can't because of the tooling.
Also equating the type of work being done with C# to the type of work being done F# by just comparing developer numbers is incredibly naive.
I really don't think you guys appreciate how many Scala/Clojure/Haskell devs would love to work in F# but can't because of the tooling.
Also equating the type of work being done with C# to the type of work being done F# by just comparing developer numbers is incredibly naive.
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
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.
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.
just make folders work properly on F# solutions and I'll send beer/wine, whatever you want.
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.
If you want "OO aspects", you can use C#. F# should focus on being a functional language. Features like currying exist for a reason.
F# is multi paradigm though. It's just that, especially when looking locally at code, functional style is just way better.
C# is also multi-paradigm, or certainly well on its way, as it gets more and more functional features. F# needs to be functional-first.
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.
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.
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.
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.
Striking a balance? It's the Innovator's Dilemma!
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.
- 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.
About web:
- use Suave (https://suave.io/), best from f#, works on .netcore too
- use Aspnet Core Mvc (just `dotnet new -l fsharp -t web` in dotnetcore), or just aspnet core
- use Suave (https://suave.io/), best from f#, works on .netcore too
- use Aspnet Core Mvc (just `dotnet new -l fsharp -t web` in dotnetcore), or just aspnet core
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'd like to see some love there. These simple things introduces needless uncertainty about the language.
There are a few F# WPF templates. Here is one: https://marketplace.visualstudio.com/items?itemName=DanielMo...
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.
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.
F# has shipped with VS for the better part of a decade now though, yet tooling doesn't reflect that.
Hopefully this will improve. It's just frustrating seeing C# slowly adopt stuff that was known to be good decades ago...
Hopefully this will improve. It's just frustrating seeing C# slowly adopt stuff that was known to be good decades ago...
I am interested in F# for enterprisey web development. Is there a good resource/guide for using F# for ASP.NET MVC?
Again about F#:
- 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.
- 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 am curious whether you think F# is poor as a language for web/mobile development, or is it the F# tooling for such development that is lacking?
well, some options for mobile
- xamarin works with f# and support it: https://developer.xamarin.com/guides/cross-platform/fsharp/f...
- use react native (with fable to transpile f# -> js): https://github.com/fable-compiler/fable-react_native-demo
for web you can use:
- suave (http://suave.io)
- aspnet core (or aspnet core mvc)
both works with .NET, .NET Core and Mono
- xamarin works with f# and support it: https://developer.xamarin.com/guides/cross-platform/fsharp/f...
- use react native (with fable to transpile f# -> js): https://github.com/fable-compiler/fable-react_native-demo
for web you can use:
- suave (http://suave.io)
- aspnet core (or aspnet core mvc)
both works with .NET, .NET Core and Mono
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!
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!
Tooling. And that some stuff (ie: c# centric classes) not interop as nicely (for example, expando objects, if I remember well...).
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):
http://www.jaruzel.com/files/dvd-to-iso.jpg
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):
http://www.jaruzel.com/files/dvd-to-iso.jpg
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."
http://imgburn.com/index.php?act=screenshots
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."
http://imgburn.com/index.php?act=screenshots
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.
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?
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?
I wouldn't describe myself as a VB fan but I don't hate it either.
I would say however that there is harm in picking technologies that less developers know (or will be willing to learn).
For your use of VB6 clearly it doesn't matter but I'm not sure I'd recommend anyone started a commercial project with VB...
I would say however that there is harm in picking technologies that less developers know (or will be willing to learn).
For your use of VB6 clearly it doesn't matter but I'm not sure I'd recommend anyone started a commercial project with VB...
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.
I can code adequately in many languages, I just seem to be more comfortable in any dialect of Basic.
You can get cdparanoia for Windows these days. (And I think even dd; which would be enough if your CDs don't have scratches.)
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.
To be fair a lot of the VB6 ecosystem was showing its age in terms of text encoding support etc. It is the Python2.7 of Visual Basic.
As a former VB6 programmer I'd say VB6 is the PHP of Visual Basic!
> 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.
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.
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 guess C++/CLI doesn't count as a .NET language? Shame it gets so little attention, it's a fantastic interop language.
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.
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.
It didn't make C# 7. Will hopefully be in C# 8:
https://www.infoq.com/news/2016/05/csharp7-pattern-matching-...
The best thing Microsoft could do for .NET is give LinqPad away with every copy of Windows.
I'm hesitant to suggest they buy it out though.
I'm hesitant to suggest they buy it out though.
Not sure LinqPad is the right way to go.
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.
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.
It seems perfectly fine: https://www.google.co.uk/#q=f%23
Pardon my confusion, but I thought that some time back Microsoft abandoned the effort to write all their stuff in managed code under .NET ..
That seems like a lot of confusion.
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.
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.
Starting with Windows 8, they improved the story of AOT compilation to native code.
With Windows 10, the native backend introduced on Windows 8.x was replaced by Visual C++'s backend, known as C2.
With C2, Microsoft is trying to make a kind of internal LLVM-like stack for their compilers, with clang, .NET and Visual C++.
With Windows 10, the native backend introduced on Windows 8.x was replaced by Visual C++'s backend, known as C2.
With C2, Microsoft is trying to make a kind of internal LLVM-like stack for their compilers, with clang, .NET and Visual C++.
Source? C# and VB have been constantly updated, with a new release practically every VS release.
Many of the built-in Windows 10 apps are written in C#.
[deleted]
I read this as "we don't really care about VB anymore, but we're contractually obliged to say that we do".
More love for F# please.
It is coming!
We love F# and it continues to be both an inspiration to other languages at Microsoft, as well as API developers.
We love F# and it continues to be both an inspiration to other languages at Microsoft, as well as API developers.
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.
[deleted]
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.
Honestly I wish decent transpilers existed in life so I need never use another language.
> We will enable and encourage strong community participation in F# by continuing
> to build the necessary infrastructure and tooling to complement community
> contributions. We will make F# the best-tooled functional language on the
> market, by improving the language and tooling experience, removing road blocks
> for contributions, and addressing pain points to narrow the experience gap with
> C# and VB. As new language features appear in C#, we will ensure that they also
> interoperate well with F#. F# will continue to target platforms that are
> important to its community.
Hey, I didn't write anything between the lines! :-)
Don't worry: We're not "handing F# over to the community"! It always had a strong community participation, and continues to. It's a fabulous collaboration. This post is not an attempt to signal a change to our strategy for F#, and if anything should be read as a commitment to F#.
We're currently integrating F# more deeply with Roslyn, which should lead to an awesome bump in tooling quality.
Don't worry: We're not "handing F# over to the community"! It always had a strong community participation, and continues to. It's a fabulous collaboration. This post is not an attempt to signal a change to our strategy for F#, and if anything should be read as a commitment to F#.
We're currently integrating F# more deeply with Roslyn, which should lead to an awesome bump in tooling quality.
Thank you and I apologize.
That's the exact opposite of what it means. Additionally F# already is the best-tooled functional language on the market as far as I can tell, so I look forward to whatever is coming to make it even better.
If that were true, why is their primary commitment to "encourage the community" and "build a forum" (my paraphrasing)? It triggers my doublespeak detector. If they were developing the language they'd have put "language development" at the top of the list.
Call me skeptical. Microsoft are no stranger to killing off their products.
Call me skeptical. Microsoft are no stranger to killing off their products.
Because F# was Microsoft's first open source language to even allow community involvement in its design processes and accept PRs directly from the community (C#, VB, and Typescript have all subsequently followed in F#'s trailblazed path here), there is a strong sense of not wanting to dictate the language direction and instead build the language as a community effort. It's been such a point of pride in the F# community that so much of F#'s development has been out in the open and a community effort, that are good reasons Microsoft would want to make sure its language was inclusive of that and respectful to that history.
Because that is what they have been doing with C# and VB for the last couple of years? The compilers are open source and anyone can write a language feature request on GitHub [1].
[1] https://github.com/dotnet/roslyn
[1] https://github.com/dotnet/roslyn
F# has always been a research/community project, that's why the tooling isn't up to scratch with c# and VB.
This signals F# is becoming more of a core language with better tool integration, but is keeping its community driven roots.
This signals F# is becoming more of a core language with better tool integration, but is keeping its community driven roots.
I really hope you are right. The tooling around F# is the only reason it doesn't explode in popularity.
If Microsoft starts to treat it as a first class citizen with respect to their .NET Core direction, then the future is very bright.
If Microsoft starts to treat it as a first class citizen with respect to their .NET Core direction, then the future is very bright.
I hope so as well. I love F# but using it in a corporate environment is hard due to its second tier status.
Is PowerShell not considered a first-class .NET language?
I thought it was on deck to take over default Windows shell/scripting status from hellish Batch
I thought it was on deck to take over default Windows shell/scripting status from hellish Batch
I wish we just had c# in a script form instead of powershell
Try fsharp with interactive, with paket it is also very easy to depend on complex graph of nuget dependencies.
You can, just need to have VS 2015 installed and use .csx files.
There is this: http://scriptcs.net/
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.
At that point I abandoned powershell and just compiled a .NET exe
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.
Yes, it does. You can even choose it during installation on VS 2015 and VS 17.
Still, there is the ISE as well, although not that feature rich.
Still, there is the ISE as well, although not that feature rich.
[deleted]
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 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.
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).
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#.
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#.
You've just killed me saying that was 15 years ago :(
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.
tsk! :)
>> For I as Int32 = 1 to 10
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.
>> For I as Int32 = 1 to 10
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 agree with your points except for
For i as Int32 = 1 to 10
Dim i = 10
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.
>Strategy for Visual Basic
Not >Killing it with fire
Very disappointing.
Not >Killing it with fire
Very disappointing.
Why are you disappointed? VB is not exactly javascript, meaning it's easy to avoid writing it if you try. And for that matter, what exactly is your complaint about VB?
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#.
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#.
I know the article was about VB.NET (successor) but I was referring to the predecessor.
http://www.tiobe.com/tiobe-index/
https://web.archive.org/web/20141110003154/http://www.tiobe....
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? :)
http://www.tiobe.com/tiobe-index/
https://web.archive.org/web/20141110003154/http://www.tiobe....
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.
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.
> VB is supported until 2024
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.
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).
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).
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.
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.
Yup, that's always been Microsoft's strength.
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 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?
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?
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 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.
Actually they had it "almost" done before 1.0, but they didn't want to delay the release any longer.
https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-gener...
https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-gener...
Luckily, very little.
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.
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.
Probably the big one is non-nullable types [1], aka 'The Billion Dollar Mistake', which would break everything.
[1] https://gist.github.com/olmobrutall/31d2abafe0b21b017d56
[1] https://gist.github.com/olmobrutall/31d2abafe0b21b017d56
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.
Cobra language solved this and compiles to C#, they can introduce non nil references, but yes they can't scrap the BCL which is nil ridden.
Seems to go against null propagation operator though :)
Seems to go against null propagation operator though :)
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?
I can't think of any change in C# that I would make that would really be worth the effort.
Non-nullable references (by default), as mentioned above. That would be huge, and worth any amount of hit.
> That would be huge, and worth any amount of hit.
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.
[1] https://en.wikipedia.org/wiki/Cyclomatic_complexity
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.
[1] https://en.wikipedia.org/wiki/Cyclomatic_complexity
testUser69(1)
F# is the best #
2017 type classes, 2018 Higher minded types ;)
Both going in at the same time would be better
Both going in at the same time would be better
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.
I can then call it with a List:
FLst and FOption are essentially the 'class instances'. Functor is the 'type class', it's just a C# interface [2]:
FLst looks like this [3]:
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.
[1] https://github.com/louthy/language-ext/blob/type-classes/Lan...
[2] https://github.com/louthy/language-ext/blob/type-classes/Lan...
[3] https://github.com/louthy/language-ext/blob/type-classes/Lan...
[4] https://github.com/louthy/language-ext/blob/type-classes/Lan...
[5] https://github.com/louthy/language-ext/tree/type-classes/Lan...
[6] https://github.com/louthy/language-ext/tree/type-classes/Lan...
[7] https://github.com/MattWindsor91/roslyn/blob/master/concepts...
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);
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);
Option<int> res2 = ParseInts<FOption<string, int>, Option<string>, Option<int>>(opt);
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);
}
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);
}
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;
}
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.
[1] https://github.com/louthy/language-ext/blob/type-classes/Lan...
[2] https://github.com/louthy/language-ext/blob/type-classes/Lan...
[3] https://github.com/louthy/language-ext/blob/type-classes/Lan...
[4] https://github.com/louthy/language-ext/blob/type-classes/Lan...
[5] https://github.com/louthy/language-ext/tree/type-classes/Lan...
[6] https://github.com/louthy/language-ext/tree/type-classes/Lan...
[7] https://github.com/MattWindsor91/roslyn/blob/master/concepts...
I hope Microsoft continues to support VB.NET. I don't know what I'd do without XML literals.
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.
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)
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.
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.
You seem to completely discount muscle memory.
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.
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..
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..