The .NET Language Strategy
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
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.
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 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 got my first serious code written in VB6. It is the first IDE that I bought with my own hard earned money as a kid and it was great. I still dream of a day when there is a language/framework that makes development that easy again.
I also find it interesting now how much of the professional IDE features that Visual Studio Community Edition opens up for free to students and non-profits and open source enthusiasts.
It's easy to look back with nostalgia at our own paths (mine was QBASIC, [saved up for] VB3, with dalliances into things like DJGPP, then a lot of HTML, PHP, and very early era JS), but let's not overlook that we live in an interesting era with interesting new paths (Small Basic, Squeak, Python, modern JS, etc).
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
That led me into considering Computer Science over Civil Engineering in college and have been programming ever since :)
What did you build back then?
(it's awesome)
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'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.
#TrollsArePeopleToo :-)
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 would donate many beers if they halted all VB work and put those guys and gals on F#!
For example, VB Select Case and C# switch work nothing like each other.
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.
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 :)
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.
Companies generally spend a lot more money maintaining legacy code than they do creating new 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.
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.
Another big feature is code layout being more compact and consistent than in C# codebases.
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.
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).
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.
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.
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.
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.
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.
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).
[0] https://visualstudio.uservoice.com/forums/121579-visual-stud...
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.)
It wasn't quite "open the site in the new IDE and fix all the squiggly underlined bits" but that was a substantial part of the mechanical effort.
Starting from nothing? Skip VB.Net and start with C# (assuming you're set on the CLR). Starting from VB6 and a novice programmer? VB.Net has advantages over C#, IMO.
It is 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??
Office has support for multiple languages, not just VBA. The three that spring to mind are JavaScript, M and DAX.
http://stackoverflow.com/a/40727011
Also, if you don't mind using 3rd party solutions, you've got other options:
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.
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 agree that VB6 is a relic of the past that is no longer a viable programming platform.)
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.
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.
Allowing it to evolve on it's own, rather than being C#'s ugly little brother.
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.
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.
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.
Basically you answered your own question. VB.NET has all the same features as C#, evolved over the same time, but VB.NET has a bunch of additional "crap" held over from a language and environment that it isn't compatible with anymore. That's how it's more complex.
You didn't even consider in your example that you declare variables with the keyword "Dim". Do you even know why? It's meaning has almost been lost to history and makes little sense for what it's used for now.
In 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>();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 d = new Dictionary<string, string>();
`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 VB.Net, the perfect language choice for stroke victims."
All joking aside, VB.NET has solved a lot of problems for companies.
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.
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#.
>> 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
Dim i = 10
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...
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.
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.
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.
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.
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
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)
But I do appreciate the work MS does - F# is a leader in FP tooling. And C# is getting easier to deal with :).
It needs a significant effort to educate developers to develop in a truly functional way. You are on track to implement many FP constructs and patterns into C#, so I'm sure the F# efforts would not be wasted at all.
I 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.
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
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.
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.
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.
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.
- 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'd like to see some love there. These simple things introduces needless uncertainty about the language.
- 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
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.
Hopefully this will improve. It's just frustrating seeing C# slowly adopt stuff that was known to be good decades ago...
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 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.
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?
[1] https://gist.github.com/olmobrutall/31d2abafe0b21b017d56
Seems to go against null propagation operator though :)
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.
https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-gener...
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.
> That would be huge, and worth any amount of hit.
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.
Well yes, I'm sure you have, but were those replaced by other bugs, leaving the bug count the same?
- 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.
- 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
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!
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):
All that being said, for the task you needed, have you seen ImgBurn? It's a native application, written in Delphi. There's a button "create the image file from disc."
I 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 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 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 can code adequately in many languages, I just seem to be more comfortable in any dialect of Basic.
Given Arcadia, the Clojure bridge to Unity, and Microsoft's interest in Unity via its Unity Tools, there might be some synergy there.
Clojure and F# are fundamentally, semantically different.
(not arguing for or against, just giving some background)
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.
And in Roslyn, C# and VB share some code, but a lot of the code is still separate even in the rewritten compilers.
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.
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..
We love F# and it continues to be both an inspiration to other languages at Microsoft, as well as API developers.
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.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.
I thought it was on deck to take over default Windows shell/scripting status from hellish Batch
Still, there is the ISE as well, although not that feature rich.
Both going in at the same time would be better
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...
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.
I'm hesitant to suggest they buy it out though.
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.
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#.
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? :)
Or people have been using the term "VB" to to refer to VB.NET as old-style VB falls out of the general consciousness, distorting Tiobe's web search engine based methodology for generating ratings.
There will be runtimes for VB until 2024, but that's far from calling it "supported". The last language release was 19 years ago, in '98, and the IDE stopped being supported in 2008, 9 years ago.
After that you'll have to do that yourself and rely on normal Win32 backwards compatibility. It doesn't mean it'll stop working (e.g. you can run 32bit VB4 on 64bit Windows 10 just fine).
Microsoft has always been a polyglot corporation. Just because not all of their code is/will ever be managed code/.NET doesn't mean that Microsoft would abandon all of the good work that has gone into the .NET platform, its languages, managed code, the CLR platform...
.NET is still the "third pillar" of modern application development on Windows devices in the UWP and .NET is also more cross-platform than ever with big investments into Xamarin tooling (now a first party part of the Visual Studio team/Developer Division) and the open source, cross-platform .NET Core runtime.
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++.
Not >Killing it with fire
Very disappointing.
> 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.
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.
Call me skeptical. Microsoft are no stranger to killing off their products.
This signals F# is becoming more of a core language with better tool integration, but is keeping its community driven roots.
If Microsoft starts to treat it as a first class citizen with respect to their .NET Core direction, then the future is very bright.