Tech Off Thread

27 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

I have the solution (vb.net vs c#)

Back to Forum: Tech Off
  • User profile image
    RoryBecker

    Alright I might not have the solution, but but I'm interested to know what people think of this compromise.

    First of all, I am not about to advocate the use of one language over another.  That argument has had far too much time dedicated to it already and things are not ‘getting’ stupid, they already are.

    The current problem is not that c# is better than vb.net or vb.net is better than c# but that the 2 are better at one thing than they are at another.

    I would like to think less in terms of vb.net or c# but more in terms of dotnet

    Let’s introduce a new file type ‘.net’

    So now we can have MyCodeFile.cs, MyCodefile.vb and also MyCodeFile.net

    This new .net file type would function as a language independent file. Default language specified at the top and away you go.

    <code DefaultLang=”vb.net”>

                Public Class CoolClass

                            Public Su New

                                        ‘ VB.Net Code here

    Call c_sharpfunction()

                            End Sub

     

                            <region lang=”c#” >

                                        void c_sharpfunction()

    {

                            // some c# code here

                                        }

    </region>

     

                            <region lang=”IL”>

                                        /* I’m a real hard-* and brave with it. So I’m going to code a proc in IL. Except as the author of this post, I have no Idea how J*/

    </region>

    End Class

    </code>

    With this in mind...

    I’m sure it is quite common for programmers to be coding along happily in vb.Net, all very happy with their case insensitivity etc. Then they realise that their VB.net class would be much more useful if it overloaded the + operator. (or any similar facility/. Some c# programmers might like to have optional parameters for some methods. I dunno)

    Unfortunately at the current time this is not allowed in available in vb.

    Never mind, open up a quick c# region and code the overloaded operator in c#

    Then back to vb.

    Sure they might receive an error trying to use the overloaded operator until this file had been compiled. (Either manually or automatically)

    But the code is kept together and all facilities of all dotnet languages are made available.

    The way things are I have to create a new c# project and migrate my class entirely into this new project translating it as I go in order to get the functionality I want. This is would be quite a task for some of my classes and introduces project dependency issues that can really confuse.

    Granted we are about to receive partial classes which are good in their own right but I still need to create a new project and this will still be a major pain as well as forcing my class to be spread all over the place.

    Different projects should IMHO be used to separate logical parts of a solution not different languages.

    (ie Datamanagers / Business Logic  / UI   rather than  vb/c#)

    I have no blog, so I am submitting these thoughts to Channel9 in the hopes someone will tell me if it is sensible or not.

    hopefully with good reasons Smiley 

    Thanks for taking the time to read this.

     Rory Becker


    ok....I'm done.... Let Fly with the comments.....

    please be gentle Smiley

  • User profile image
    Manip

    I like the idea, but I think the XML formatting in the file is moronic.

    @VB

    @C#

    Maybe?

  • User profile image
    GooberDLX

    The actual idea sounds interesting.. but almost reimplementing IL at a higher level, which to me, sounds confusing.. There is nothing wrong with having multiple source files and compiling to components in each of the different languages...

    Thats the whole idea of .Net .. Why reimplement the wheel?

    Its almost bringing the idea from HTML over, where you define a language script type within the code..

    Do you see multiple websites using 2 or 3 different client side scripting in one page? Not really..

    And that brings another point, if this feature would be useful for more than a handful of projects, then great! bring it on.. but I dont know the validity of adding such, parsing multiple langauges into AST switching back and forth between languages and contexts, would be mind boggling!

    IMHO

    Jake

  • User profile image
    RoryBecker

    >>I think the XML formatting in the file is moronic.

    Any chance you could elaborate a bit?

    After all the xml used in the example, while probably not perfect, does get across all of the important information.


    >>@VB
    >>
    >>@C#



    I am not familiar with your syntax. Does it draw from any established standard/language?

    The xml has the added benifit that many people are becoming more and more familiar with it as the days go by.

    (Appologies if I have missed spotting that your syntax is in fact incredably well known and popular Smiley )

    Anyways, I'm personally not bothered too much what syntax is used to acheive the goal.


    Rory Becker

  • User profile image
    DrFooMod2

    Preprocessor directives such as

    #code c#
    ...
    #endcode

    would be most appropriate.

  • User profile image
    mufoxe

    I don't think that this style of coding will do wonders for the readability of the code. It was tough enough reading HTML embedded with ASP, PHP, or whatever.

    Keep the stuff separated in projects thank you very much Smiley

  • User profile image
    RoryBecker

    GooberDLX wrote:
    There is nothing wrong with having multiple source files and compiling to components in each of the different languages...


    Well, without meaning to sound aggressive, it's my contention that there is.

    The problem is that currently we have to make a choice at the start of a project as to which language we want to use for it's duration.

    If I decide to use vb for my project but then decide that I need some functionality that is easier to implement in c# I currently need to create a whole new project.

    Why should a given Project be dedicated to only one language.

    Sure we can call out to other projects but this has issues of it's own.

    The new project takes a lot more time to create against a couple of lines of source

    A new Project means yet another Dll which can lead again to the way of the Dll version hell (oh yes it does)

    Surely this suggestion is no more tricky than the idea of partial classes. Only the code is of differing types and in the same place?

    We are told by Microsoft that it doesn't matter which language we pick since it all compiles down to IL and therefore all languages sit on a level playing field.

    Yet both VB.net and C# are starting to evolve in slightly differing directions.

    I believe that this is a good thing. However this should not make me choose which I wish to use.

    A good developer uses the best tool for the job.

    But you don't restrict a graphics designer, forcing him (or her) to choose between using color or different sized brushes. You give them a tool that can use both.

    GooberDLX wrote:

    If this feature would be useful for more than a handful of projects, then great!
    but I dont know the validity of adding such


    I have seen that argument before for many things.

    To para-phrase:-
       "That sounds like a lot of work to me."

    but is it really that much worse that the partial types idea. The only real difference in in the location of the code.

    If I only want 2 - 3 functions is it really worth coding an entirely new project. Now that is a real waste of time. Equally if the existing class has 20-30 methods then recodeing the class in the other language is clearly madness as I would surely come across a similar need eventually leading me in another direction.

    This feature might well require work in order to get running but that's the VS.net/Compiler/framework team(s) job.

    Spend Microsoft's time saving the average programmer time and making their job easier.

    GooberDLX wrote:

    Do you see multiple websites using 2 or 3 different client side scripting in one page? Not really..


    Well no we don't but if web sites could be coded in 2 languages them more 'solid code' could be borrowed from existing sites.

    This would prevent such code being poorly translated, which often introduces more bugs.

    Rory

  • User profile image
    RoryBecker

    mufoxe wrote:
    I don't think that this style of coding will do wonders for the readability of the code. It was tough enough reading HTML embedded with ASP, PHP, or whatever.

    Keep the stuff separated in projects thank you very much Smiley


    ok I'll agree that reading mixed html/asp/javascript has never been a picnic to read.

    I personally don't like the way many developers insist on mixing serverside html with inline code.

    (I prefer the code behind model)

    However what I am describing sees 2 or more languages which do at least all reference the framework rather than one refering to the framework and another refering to the DOM of a document that hasn't even been created yet.

    Our editors are much more intelligent these days anyway.

    we could choose to let the editor show us the code in any number of ways

    1.> Like languages reside together.
    2.> Unlike languages appear on differing tabs.
    3.> Language regions could be collapsible to hide what we don't want to see.

    Of course even if something is hidden Intellisence can always find it for us.

    There are many new ways to deal with the readability issue.

    Rory


  • User profile image
    RoryBecker

    DrFooMod2 wrote:
    Preprocessor directives such as

    #code c#
    ...
    #endcode

    would be most appropriate.


    Yeah that sounds good. I like that.

    Nice and simple with out being scary to those who don't like xml.

    Rory

  • User profile image
    Manip

    DrFooMod2 wrote:
    Preprocessor directives such as

    #code c#
    ...
    #endcode

    would be most appropriate.


    I also like that Smiley

    Shouldn't it be 'end code' ?

  • User profile image
    pierlove

    Although in theory this all sounds nice, I think that implementation of this at the compiler level would be a formidable task.  The implications are far reaching and cause me concern.

    1. Merging Languages into a single source (resource) would obfuscate code causing confusion. The would cause for programmers who are not disciplined in a particular language to be forced into understanding foreign syntax. While like me most programmers using .net can fluently speak both tongues, not everyone is a Sr. Software Architect.

    2. Merging Languages into a single source would using any syntax at all would add additional overhead at runtime, the nature of JIT/CLR itself would most likely be compromised by such a move, a better solution would be develop a 3rd even higher language that is a construct of many languages. This new dialect would be a superset of the lesser languages for use only as needed by experts of that discipline.

    3. Presentation would also be compromised by such a move. As previously mentioned the client-side parsers are language specific, and implementation would most likely require retrofitting the designers to support these language-state-transitions.  Again reference Item 2 on this list as a better solution.

    IMHO,

    Jamie

  • User profile image
    GooberDLX

    Prodev wrote:
    Although in theory this all sounds nice, I think that implementation of this at the compiler level would be a formidable task.  The implications are far reaching and cause me concern.

    1. Merging Languages into a single source (resource) would obfuscate code causing confusion. The would cause for programmers who are not disciplined in a particular language to be forced into understanding foreign syntax. While like me most programmers using .net can fluently speak both tongues, not everyone is a Sr. Software Architect.

    2. Merging Languages into a single source would using any syntax at all would add additional overhead at runtime, the nature of JIT/CLR itself would most likely be compromised by such a move, a better solution would be develop a 3rd even higher language that is a construct of many languages. This new dialect would be a superset of the lesser languages for use only as needed by experts of that discipline.

    3. Presentation would also be compromised by such a move. As previously mentioned the client-side parsers are language specific, and implementation would most likely require retrofitting the designers to support these language-state-transitions.  Again reference Item 2 on this list as a better solution.

    IMHO,

    Jamie


    Beautiful! Couldnt have said it any better..

    RoryBecker wrote:

    But you don't restrict a graphics designer, forcing him (or her) to choose between using color or different sized brushes. You give them a tool that can use both.


    True, but you cant force an image to encode in JPEG for half the file and PNG the other half... What about software specs and requirements? If someone hands you a spec that gives you the freedom to write in two languages for one product in one module or class, how does that reflect on the spec? "Gee I dont care how it gets done, just get it done"


    RoryBecker wrote:
    If I only want 2 - 3 functions is it really worth coding an entirely new project. Now that is a real waste of time.


    Yeah but so is switching implementation to another language just to code 2 to 3 functions..

    RoryBecker wrote:

    Equally if the existing class has 20-30 methods then recodeing the class in the other language is clearly madness as I would surely come across a similar need eventually leading me in another direction.


    Microsoft .Net allows us to not have to worry about this. Why would you recode a class to another language if it was that big in the first place and you were worried about it? If you are a VB developer and are refactoring a piece of code.. that was written in C#, you aren't the right person for the job! Simple..


  • User profile image
    pwiest

    This is a very cool idea, and it definately would have some benefits. However I think there is one critical problem that makes this something we won't see for a while (if at all): feature parity between languages.

    Lets assume you use a region to have a c# operator overload. This will work great for the c# code. However, since vb has no concept of Operator overloading (at least for now, Whidbey!), what will it do? Adding two classes doesn't make sense to vb, and it will fail to compile.

    Cool idea though, I could have definately used something like this in my managed code adventures Smiley

  • User profile image
    Bryn Waibel

    Personally, I'd rather see the IDE and compilers support multiple language projects. That coupled with the support for partial classes coming in C# 2.0 would solve this problem quite elegantly IMHO.

    -Bryn

  • User profile image
    chollander

    As you've mentioned, I have certainly had the experience of working through a project coded in one language, and desired a feature from a different .NET language.

    There are existing techniques, however, that can help you work around this, without mixing different languages in a single file. First of all, I have found that different languages (and, more precisely, the developer tools available when your using those languages) truly are better at doing different things... so the first thing i do is decide what language I am going to need for each logical component in my architecture.  Lets say i'm on a team producing some ridiculously complex application;  for example, lets say that we're writing a neural-network based face-recognition app.  I might write the "engine" for the recognition engine using c#, because i find it very easy to model complex object relationships using c# syntax.  For the UI, which has to use a dozen or so of the underlying engine components, I might choose VB.NET, because I like the way that VB works with .NET events, and because of filtered exceptions, and because of the "with" keyword.  In really general terms, VB.NET is a great consumer, and C# is a great producer.  Now; I might find out that certain aspects of the neural network recognition engine are particularly slow;  not a problem, I can just create a new managed C++ project, inherit from my existing C# classes, and extend whichever slow methods I might have.  

    In my opinion, one of the best things about the "divergences" between vb.net, c#, and C++ is that they force you to logically divide code that really should be seperate ANYWAY.  having the ability to put all of that code in a single file will not, at the end of the day, make your code easier to write, or make your application faster, or make your design easier to manage... so why bother?  in other words, if your using VB for your UI layer, why in the world would you be trying to implement operator overloading?  your UI shouldn't need operator overloading.... your business components might, though, but your biz components can benefit from being written in C# anyway.  now, why is your biz component trying to directly access some esoteric piece of hardware?  thats not what biz components are supposed to do... if you need to do that, use managed C++.   

  • User profile image
    RoryBecker

    pwiest wrote:
    However I think there is one critical problem.....

    Lets assume you use a region to have a c# operator overload. This will work great for the c# code. However, since vb has no concept of Operator overloading (at least for now, Whidbey!), what will it do? Adding two classes doesn't make sense to vb, and it will fail to compile.


    I quote from 'Applied Microsoft .Net Framework Programming - Jeffery Richter' http://www.amazon.com/exec/obidos/tg/detail/-/0735614229/qid=1083917528/sr=8-2/ref=sr_8_xs_ap_i2_xgl14/103-8747487-9414201?v=glance&s=books&n=507846

    A great book by the way

    Page 193:-

       'Visual Basic doesn't Offer special syntax that allows a type to definean overload for the + operator. In addition, Visual Basic doesn't know how to translate code using a + symbol to call the op_addition method. However, Visual Basic (Like all Languages) does support the ability to call a type's methods. So in visual Basic you can call an op_addition method that was generatedby a Type built with the C# Compiler'

    chollander wrote:

    In my opinion, one of the best things about the "divergences" between vb.net, c#, and C++ is that they force you to logically divide code that really should be seperate ANYWAY.  having the ability to put all of that code in a single file will not, at the end of the day, make your code easier to write, or make your application faster, or make your design easier to manage... so why bother? 


    Well here we have inherited a Solution which has been entirely written in vb.net and we don't get the option to descide which project should be written in which language. however we too recognise that c# is better at some things than vb and vice versa.

    If I had unlimited time and resources I probably would rewrite a sizable chunk of our code in c# but as it is I do not have the resources needed to do that.

    Bryn Waibel wrote:
    Personally, I'd rather see the IDE and compilers support multiple language projects. That coupled with the support for partial classes coming in C# 2.0 would solve this problem quite elegantly IMHO.

    -Bryn


    MultiLanguage Projects rather than MultiLanguage Files

    I'm Stunned Smiley

    Storming Idea Byrn

    As far as i'm concerned that gives me almost everything I'm after.

    I would just want to be able to right click a partial type and then be given a list of other parts to which I could then jump.

    Would this be as hard to implement as my Idea?

    Is it too late to get 'this' feature into Whidbey?

    This does not clutter a given file so readabiliy is maintained.

    It allows me to code a class in both C# and VB and anything else that might be allowed(J#, delphi.net etc)

    True there would need to be some unification of project level options etc but i'm sure that at worst these could be placed on differing tabs in the project options dialog?

    I would really like to get everyone's take on the difficulty of implementing this.

    GooberDLX, ProDev... What do you think of this alteration. Would this feature be any easier to code.


    Thanks for everyone's continued input

    Rory

  • User profile image
    GooberDLX

    RoryBecker wrote:

    MultiLanguage Projects rather than MultiLanguage Files.

    ...

    GooberDLX, ProDev... What do you think of this alteration. Would this feature be any easier to code.


    I think it would be interesting.. more so than MultiLanguage files! This breaks down the project into even smaller subsets, which (now that I think about it) could help teams that are working on a single project.

    There's still the problem of code readability from the developers side. Situation: Rory (VB.Net expert) and Me (C# expert) know nothing of the other language but are working on the same project. This kind of thing would allow us the freedom of developing together, but then if I want to see how he developed something, it would be a mess, or.. what happens when Rory quits or leaves the team, then I'm stuck with VB.Net code in which I dont know anything about, yet its wrong or has to be added to... Hire another VB.Net Developer to replace him? Smiley 

    I think its a step.. Could it be easily done? just compile each different source to IL then merge the IL into one DLL after the fact!

    Jake

  • User profile image
    pierlove

    Language Independent Projects Would Be Useful If Automation was strong and one could toggle constructs between languages. Meaning the net change to the result code itself was nominal.

    Meaning that what's important here is the IL, and that some type of comparison/ round trip engineering could be done to compare and process conflicts and isolate issues with a piece of code using alternate (.Net) languages.

    I stick with my position state above:
    http://channel9.msdn.com/ShowPost.aspx?PostID=6430#6430

    Jamie 

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.