Comment Feed for Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet (Charles on Channel 9)

Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

Chris Stevens — Thu, 22 Oct 2009 14:43:40 GMT

I'm quite interested to see how this will progress. As many other developers may have experienced, I find I have to know both VB and C# to get things done (as well as C, C++, Java, shell scripting, etc.).

Co-evolving the languages, I think, would be quite beneficial - at least to me. This would reduce, if not eliminate, my consistant need to write a library in C# because VB doesn't expose the functionality I need - and, once in a great while, the other way around - then drop the library in my project.

I'm also anxious to learn some F# in the beta version of Visual Studio 2010 I'm testing. I'm intruiged by Luca's comments about F#.

Finally, as the video addresses, it will be interesting to see if this co-evolution will result in a new language eventually.

Re: Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

Charles — Thu, 08 Oct 2009 23:04:54 GMT

ASP.NET is a server platform .NET technology... C# is a programming language that you can use to compose ASP.NET applications (like VB.NET, etc).

Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

haseeb alam — Thu, 08 Oct 2009 22:45:11 GMT

i have a question for Luca which is in regards to his discussion about C# and vb.net co-evolving.

Q) ASP.Net seems to be the only option if you want to develop a web site in dot net. Are there any plans to provide us with the option of using C# to do the same thing?

haseeb alam faridabad HR IN

Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

Ron Garrett — Thu, 24 Sep 2009 03:47:24 GMT

Lisa et al.

I was surprised when MS introduced VBA rather than expand VB to include good Office support. That would have been MUCH better. Now MS can hardly dump VBA type of support for Office. VB of sorts has its biggest alliance there. It may be the cause of VB having been poorly supported in the move to .NET. VBA programmers may like the .NET environment more than I do. I HATE IT!! Its fine for development of applications that spend most of their time awaiting user input - "Northwind" sorts of applications. In that sort of application the user uses up the time wasted in unwrapping APIs and excessive type checking, by simply pondering the next move. But applications that work harder and longer between user inputs will suffer seriously. Pointers alone can greatly speed progress through large corporate or technical data structures. I'm not talking about $20 payroll and employee records. Large applications doing a lot of work would surely be advised to avoid .NET like the plague.

Now that the .NET cancer is incurable I hope that VBA will be brought into VB (not the other way round). But there does need to be simple ways AROUND the .NET foggy marshland - a treacly morass it is. The talk of safe and unsafe code is foolish. Managed code has a safe (or do I mean unsafe) place to safely use pointers free of GC pilfering - where it places large (80Mb) objects or much-used objects (GLOBAL or STATIC) and I can see no reason why VB should not use this space for pointer arithmetic. The only problen that really needs attention is the provision of good, clean, direct, unencumbered access to addresses of data blocks (arrays, lists, collections, images, bitmaps) to READ AND WRITE! And unencumbered access to the APIs. It seems quite ironic (or do I mean ridiculous) that coding skills improved as one started to use Windows APIs directly in VB only to find that the deveopment of the language is measured by the degree to which we can no longer easily and directly get at them. Object-oriented programming is powerful - Class-oriented programming is often slow and tedious, never quite giving you what you really need.

.NET tries to help the (novice?) programmer from making type and catastophic mistakes. Perhaps it succeds. But in doing so it also seriously impedes the (competent! and confident!) programmer from making significant coding progress.

Since you invented the .NET quagmire you are the best to write a new best-seller entitled "Paths To Get Around In VB.NET" but with the "In" heavily crossed out!

Otherwise, regards,

Ron

Re: Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

MaidenDotNet — Sun, 16 Aug 2009 18:25:36 GMT

I don't think LINQ to SQL is going to go away in near future. Please see the following:

http://reddevnews.com/blogs/data-driver/2009/08/linq-to-sql-lives-on.aspx

I think both languages should have identical features and agree with direction Microsoft is taking. I really do think that the syntax of all languages should move away from C or C++ syntax and think the way code is formatted is ridiculous. There should be an easy, visual way to see Threads, Memory, Branching, Logic, Types, Delegates, Pointers, Reference Types, Value Types, Logic, Flow, Nullable, Generic, Data, XML, JSON, Service, Characters, Strings, Classes, Interfaces, Objects, Events, Configuration, Attributes, Inheritance, Lambda's, etc.

In other words, typing /n is so stupid and just another ritual that is tolerated. Syntax or constructs which are not intuitive and demand memorization instead of knowledge is either C or C++ religion, and just one more obstacle in the way of solving the actual problem because it is useless and gets in the way of seeing more concisely what is actually going on. The word alludes me right now yet I think it has been referred to as ritual/routine or something like that. I am not for abstracting away all of the language either because then you cannot really see what is taking place. The perfect language in my opinion would be self modeling, self documenting, have immediate recognizable function, concise, visual, and require zero memorization (Intellisense Nirvana). In order to achieve this, I think it would be necessary to create new universal symbols for certain programming items kind of analgous to the road signs that have Deer Crossing.

I know, I'm a dreamer.

Re: Re: Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

maguirpd — Thu, 13 Aug 2009 22:30:25 GMT

there isn't a question i stupidly added this comment here then realised my mistake but could not undo my posted comment.

my mistake was assuming that ASP.Net was a VB only thing like ASP was but i see with the dot net version this is no longer the case.

macca.

Re: Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

Charles — Tue, 11 Aug 2009 00:12:05 GMT

Well, ASP.NET is a .NET server technology that is independent of .NET programming languages... What's the question?
C

Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

maguirpd — Mon, 10 Aug 2009 21:02:28 GMT

i have a question for Luca which is in regards to his discussion about C# and vb.net co-evolving.

Q) ASP.Net seems to be the only option if you want to develop a web site in dot net. Are there any plans to provide us with the option of using C# to do the same thing?

macca.

Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

stikves — Sat, 18 Jul 2009 21:58:20 GMT

Please do not make C# into VB. C# is an elegant language, which appeals to another set of people (specifically those coming from C++/Java backgrounds).

Things like Xml literals or exception filtering would really clog up an otherwise nice language. I personally find features like LINQ and functional programming more appealing than dynamic programming (which I can do in IronPython anyways).

Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

Mulb — Tue, 09 Jun 2009 15:05:42 GMT

Will VB.Net get proper pointers? I sure hope so. After, all the other types are in the framework. It's a realy pain as a Vb Dev to have to learn two langauages to get stuff done. Why the restrictions?

Mulb

Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

Waleed El-Badry — Tue, 02 Jun 2009 10:21:39 GMT

It is a good news to hear so. Since both are twins in the visual studio families. I can't say that I dore braces of C# (native VB coder as you may have noticed ;) . However, C# did great job in terms of refactoring which I hope our VB team coul make use of it and not relying on DevExpress in this regard.

Nice job guys. I love you all (but not as much as Lisa [H] . Cheers

Re: Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

Philaman01 — Sat, 23 May 2009 22:54:17 GMT

There are countless backoffice apps written in VBA/Macros. MS Office versions from 97-2007 are so ubiquitous in today's world that a VBA code "sea change" is IMHO unattainable. Additionally, considering MS Office is a multi-billion dollar cash cow for the company, I strongly doubt they would do something radical as eliminating VBA completely any time soon, if ever.

Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

Philaman01 — Sat, 23 May 2009 22:43:18 GMT

Reading between the lines of this interview, it sounds to me like VB.NET and C# will eventually meet into one language. Visual Basic .NET was created as an entrance ramp for Visual Basic 6 programmers to get on the Object Oriented/.NET super highway. Just like Microsoft closed the road on VB 6, they will do the same for VB.NET and bring everyone into one camp within the next 4-10 years.

Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

loloolllool — Fri, 22 May 2009 20:56:47 GMT

Where is XML Literals for C#? :S

Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

Johanson — Thu, 21 May 2009 19:32:57 GMT

If it were evolutionary multiple teams would be created, the top two would be bred with each other, and the rest shot. You are really talking about directed design and the decision to unify the design process across both language properties.

Now, if you want to start building in support for parallel GA execution, that would be exciting. :-)

Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

RoryBecker2 — Wed, 20 May 2009 11:02:41 GMT

I still reckon you need to provide multi-language projects.... Multi-language solutions just don't cut it.

Re: Re: Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

Daniel Earwicker — Wed, 20 May 2009 09:40:42 GMT

Thanks for that answer. I'd certainly hope that there is no intention to drop everything from VB.NET into C#. Several people have mentioned XML literals as something "cool" to bring into C#. XML may have been cool when that feature was added to VB.NET, but JSON has taken over since then, and who knows what will be next? The C# approach is already much better: anonymous types give us free-structured object literals, which can easily be flipped into any stream format by a library function (e.g. JsonResult in MVC), so C# already has this problem solved.

Re: Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

mads.torgersen — Tue, 19 May 2009 21:35:38 GMT

It doesn't necessarily mean that. Exception filtering is one of those features that there is comparatively low interest in, and so adding it to C# "just because" VB has it may not be the best investment.

Think of co-evolution not as a mechanical thing but as a framework for decision making. Whenever we add a new feature, all else equal we do it in both languages; if it is valuable enough to add to one, it is most likely also valuable in the other. But literally adding to C# every feature that VB already has, and vice versa, is hardly a good approach, so we have to find a balance. I'd say that exception filtering is right around that balance point, so I can't say for sure one way or the other.

Thanks,

Mads Torgersen, C# Language PM

Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

Daniel Earwicker — Tue, 19 May 2009 13:21:12 GMT

So does this mean that C# will be getting the equivalent of VB.NET's "When" keyword that can appear after a Catch, to control exception filtering?

To briefly recap the issue, in C# today we can only filter exceptions by their exact type, or by their location in the type hierarchy (catching a base type). Unfortunately that isn't very useful because exceptions are not generally organized into useful type hierarchies. Deriving from ApplicationException to indicate "non-fatal" is now discouraged, for example, so in fact it should be expected that custom exception classes will all derive from Exception. Meanwhile, due to the lack of flexible exception filtering, the Exception Handling block of the Enterprise Library suggests catching the universal Exception base class, which directly contradicts the advice of the CLR program manager. The CLR team also suggest using VB.NET (or hand-written IL) to get access to "Catch/When" functionality from languages that don't have it such as C#.

Re: Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

Lisa Feigenbaum — Sun, 17 May 2009 17:21:59 GMT

Hi Jeffery,

The features you mention are certainly important ones for VB.NET development. In VB 2010, there will be the ability to stub out new functions. We're calling this feature "Generate From Usage". Here are a couple resources with more info:

http://blogs.msdn.com/vbteam/archive/2008/12/13/walkthrough-tdd-support-with-the-generate-from-usage-feature-in-vs-2010-lisa-feigenbaum.aspx

http://blogs.msdn.com/vbteam/archive/2008/12/02/code-focused-development-in-visual-studio-2010-lisa-feigenbaum.aspx

Unfortunately, the ability to refactor chunks of code to their own function (a.k.a. "Extract Method") is not yet available in the VB product. However we've been partnering with DevExpress over the past few years to fill this hole, and they ship a FREE add-in that includes this feature and a whole lot more. The latest release for the DevExpress add-in was this past week, and includes over 60 refactorings. More info below:

Download DevExpress CodeRush Xpress: http://www.devexpress.com/crx

Watch a video of this tool in action: http://tv.devexpress.com/CodeRushXpressVBIntro.movie

Cheers,
Lisa

Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

Jeffery Geer — Sat, 16 May 2009 22:50:09 GMT

Luca,

I've been working in C# and VB.net for a while and what I miss the most in VB.net is the ability to refactor code. I hope it isn't too long before Visual Studio supports refactoring chunks of code to their own function, or stubbing out new functions in VB.net.

-J

Re: Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

Lisa Feigenbaum — Sat, 16 May 2009 06:52:17 GMT

Hi Daniel,

Thanks for your post. It would be interesting to know what surveys you've been seeing. There certainly are a lot of languages in the Basic family: Basic, PowerBasic, ThinBasic, FreeBasic, SmallBasic, VBA, VBScript, VB6, VB.NET - the list goes on! When mining the data that Luca referred to, we made sure to just include the numbers of developers using VB.NET (and then we compared those numbers to C#). The survey that we use contains a large sample space that is representative of developers around the world. I would argue that a survey on a blog does not have the same kind of sample space. Finally our survey asks what language you are using now, whereas the question on the blog survey is different.

Good to hear from you,
Lisa

Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

nektar — Thu, 14 May 2009 18:33:23 GMT

I know that you are trying to get rid of VB 6 and that for me is very good. But I have two problems which I don't see you addressing fast or even addressing at all.

(1) Office development, especially in MSAccess, is still VBA-based, which is even worse than VB 6. You have to immediately: (A) Define a new direction for VBA macros, they are too old. (B) Create a modern macro interactive (did I say interactive) shell for Office. (C) Decide on what to base such an Office interactive shell: Powershell, VB, Python, what. (D) Decide on what to do with Access: have a .NET language embeded into it or what, but move away from VBA. (E) Decide on how people would best write Office extensions, COMM and it 10-year old Office interfaces does not cut it in this modern age, neither does COM Interop Assemblies or whatever else you offer. (F) Find a way for hobbyists and students to create Office extensions, now you have to buy VS 2008, expensive. (G) Generally make Office programming fun again. (H) If Firefox has an extensions site why can't Office, where can I get the best extensions for Word, you tell me that no fun extensions can be created for a modern processor or say for WMP.

(2) I liked the immediate window for Visual Basic 6. It used to be a dynamic language. Now nobody things of VB as a dynamic language. Why can't I use VB like I use Python and even better? Why isn't there an interactive shell for VB? Why doesn't the VS debugger have any macro-like interactive shell support: imagine being able to type VB interactive commands to check your arrays and variables whilst the debugger is running or at break time. VB could really have been a Python for the .NET but you did not move forward with this idea. Now, however, we are stuck with it, both in Office and in VS macros. If you really want to make VB like C# then please replace the macro editors in VS and in Office with Ironpython then and do it fast and not after 5 years. Office and VS debugger etc need a modern macro interactive interface and they need it now! Imagine the productivity I would have just by say at a specific break-point being able to write say a Python command that would go through 2 instances of an array in two functions of a running program and compare corresponding values, returning which ones do not match. Would not this improve my VS and for another example my Office productivity tremendously?

Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

Jason Dean — Thu, 14 May 2009 16:51:21 GMT

Great video, Nice to hear about the parallel development. One question, will there be a VB.NET XNA?

Re: Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

www.mrmubi.com — Thu, 14 May 2009 15:22:37 GMT

I had been programming in VB then VB.Net then C# and thinking the same thing. Now finally we got it. Luca weldone.