Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Microsoft Programming IT Technology

Four Microsoft Programming Languages Compared 112

prostoalex writes "Prashant Sridharan, senior product manager for Microsoft's Visual Studio product, compares four Microsoft languages for .NET development. C++ (.NET version), C#, J# and VB.NET are explored with features of each language outlined. There are no usual "pro and con" lists, so the ever-popular "default public access" made into the "features of VB."
This discussion has been archived. No new comments can be posted.

Four Microsoft Programming Languages Compared

Comments Filter:
  • Diversity (Score:5, Insightful)

    by rmull ( 26174 ) on Monday August 18, 2003 @10:29PM (#6729529) Homepage
    A "rich palette of languages"? Let's see, three statically typed object-oriented languages and one dynamically typed object-oriented half language. I seem to remember there being MORE to programming than objects.

    But that's just me.
    • Nice, much better FP than my last time. As for objects, what else is there at that level of the paradigm. If code is not part of one, it should be part of another, no? Strictly on the same level, of course? Of course, I Ain't Much Of A Programmer.
      • by saden1 ( 581102 )
        The whole world is an object and it belongs to me! Me and me alone.

        This code proves it!

        Saden1 s = new Saden1();
        World myWorld = World();
        s.setWorld(myWorld);
    • Re:Diversity (Score:4, Insightful)

      by Anonymous Coward on Monday August 18, 2003 @10:37PM (#6729590)
      I seem to remember there being MORE to programming than objects.

      Sure there is...in academia.

      In the corporate world, people use languages with a track record of being able to meet the balance between performance and the ability to meet deadlines. Enter the M$ product line.
      • Re:Diversity (Score:4, Insightful)

        by Anonymous Brave Guy ( 457657 ) on Wednesday August 20, 2003 @07:03AM (#6742618)
        Sure there is [more to programming than objects]...in academia.

        But academics and R&D departments are where the new ideas come from. We already have several OO languages, each of which changes everything and yet somehow stays the same. None of these is really a radical departure from status quo, none of them is going to make a dramatic improvement to productivity.

        What we need today are genuine new ideas finding their way into the industry, so that the ones that work in practice can establish themselves and the ones that only work in theory can be set aside. We don't need C#JavaInteropVB++.NET.

        In the corporate world, people use languages with a track record of being able to meet the balance between performance and the ability to meet deadlines.

        VB.NET has no track record. It's nothing like old VB, as any VB6 developer suffering the pain of moving can tell you.

        C# has no track record, except for its uncanny resemblance to Java.

        C++ with managed extensions has no track record, aside from the C++ part.

        Visual J#? After the "track record" of Visual J++, I'd be amazed if anyone serious goes near it.

        If you want to talk about track records in a commercial setting, let's talk about C, C++, Perl, Java and VB6. The new Microsoft languages and the .NET architecture beneath them aren't even on the scale.

    • Re:Diversity (Score:4, Informative)

      by Chester K ( 145560 ) on Monday August 18, 2003 @11:01PM (#6729735) Homepage
      I seem to remember there being MORE to programming than objects.

      The .NET Framework excels at interoperability, and the key to that is their OOP system; so obviously that's what they're going to point out as the killer feature. In my opinion, you're wasting your time with .NET if you're not going to take advantage of the platform to its fullest; but there's nothing stopping you from putting your procedural code into a thin object wrapper; and Microsoft Research has put together a few reference implementations of some functional languages -- but those are "fringe" languages, so they don't get top billing.
      • Re:Diversity (Score:5, Insightful)

        by farnsworth ( 558449 ) on Tuesday August 19, 2003 @12:47AM (#6730207)
        "Informative"? oh, please. All .net is is an i18n'ed compiler with an extensive class library. Don't get me wrong, I used it for some time writing a tcp server app, and it's pretty cool and all, but it doesn't matter what language you use, it takes serious training to use the platform to any degree of real usefulness outside of the simplest, example-style apps.

        The .NET Framework excels at interoperability

        ... with itself only*. Have you ever tried to get nmake and make to coexist? It's a nightmare. Generate .net wrappers to export standard c++ code to a c# app? 'Easy' doesn't come to mind.

        My gut feeling is that .net should be applauded for what it is: a comprehesnive (finally!) win32 class library with compilers that work "pretty much the same" for each supported language. This was, no doubt, no trivial accomplishment, but "interoperability" is a far, far cry from what .net really provides.

        * - True enough, there is good support for wsdl, and web services in general, but this should be not be rocket science for any platform.

        • Re:Diversity (Score:5, Insightful)

          by zero_offset ( 200586 ) on Tuesday August 19, 2003 @07:35AM (#6731613) Homepage
          You have an interesting definition of interoperability. The correct way to export standard C++ code to a C# app would be to expose the C++ code through an existing mechanism -- not munge together .NET-specific wrappers of some kind. Hell, make them a DLL and Visual Studio will do all the hard work for you. Expose them through CORBA and buy one of the off-the-shelf .NET CORBA interop packages. Expose them through COM and Visual Studio will do most of the hard work for you on both ends of the project.

          I'm starting to notice the only non-trolls who complain about .NET being hard to use are the die-hard C++ guys who refuse to simply use the tools that are being given to them. I am reminded of the situation about 15 years ago when I used to scoff that nobody could do any serious programming without resorting to assembly, but these days most of the C++ guys I work with don't know the first thing about assembly...

          • You are telling only half of the story here. All of your 'solutions' are correct depending on the type of data. If you are passing the data via the stack, yes, you are correct.
            Now, if you are passing large data sets, then, you are most likely passing by reference. Now, your solutions break down. Interop does not handle refernce passing at all. You then have to do all of the dirty work. I had to do just that because I was using a web service to provide a COM server to the world.
    • Re:Diversity (Score:5, Informative)

      by bigsteve@dstc ( 140392 ) on Tuesday August 19, 2003 @02:56AM (#6730645)
      That is a bit unfair. While the author only deals with languages shipped by Microsoft, a number of others have been ported to the .Net platform. See here [jasonbock.net] for a list.
      • If by "ported" you mean "a thin layer over .NET semantics", yeah, a lot of languages have that.

        If by "ported" you mean "language X's objects are completely visible to .NET, and efficiently so", then the numbers will drop off quite a bit.

        See this thread [google.com] from comp.lang.lisp on why Franz Inc (the longest-surviving Common Lisp vendor) looked into porting their stuff to .NET, and declined.
    • Re:Diversity (Score:3, Interesting)

      by smallpaul ( 65919 )
      Which of these languages do you think is dynamically typed? VB has become more and more statically typed with every generation and Microsoft's answer to any problem with it (especially the problem of porting VB code to VB.NET) is "add type declarations".
    • MicroSoft now gives you 4 flavors of crap to choose from instead of just one.

      'Nuff Said !
    • Well, there's always F# [microsoft.com] which was not mentioned in this 'review'. This is the red-headed functional stepchild of the .NET family.

      -m
      • Sadly, it looks like F# was a research project: a proof-of-concept port of ML (OCaml) to .Net. Alas, functional programming is still waiting for its Larry Wall.

    • Nop.
  • by fm6 ( 162816 ) on Monday August 18, 2003 @10:41PM (#6729616) Homepage Journal
    This "comparison" is just your basic dog and pony show. Its purpose isn't to help you compare languages. They just want to fill your head with the "there's a .net language for everybody" party line.

    Which is pretty normal for any technology company. So Microsoft bashing is, for once, inappropriate. What's stupid is that anybody would think that Slashdotters would be interested in it. Even if we were all rabid .net fans, this kind of thing would have no interest for us.

    • I'm a slashdotter, and I find the article quite interesting. As a programmer, it helps to keep abreast of *all* options out there, politics/personal opinions aside. Yes, you're right, the article is there to expound the benefits of .NET, but is that a bad thing? No, it's a valid platform for the development and deployment of software, and that's news to slashdot developers.

      In fact, I'm somewhat disappointed at the severe *lack* of articles such as this one for the developers section. Developers section
    • .NET languages (Score:5, Interesting)

      by Latent Heat ( 558884 ) on Tuesday August 19, 2003 @09:27AM (#6732527)
      Let us assume for the moment that the requirement is to program for Windows -- there are pros and cons that we don't need to get into because they have been hashed over, so lets move on here.

      Visual Basic is Microsoft's flagship project for Windows application software development while Visual C++ has been a poor stepchild. Windows has two major features that are hard to do cleanly without some kind of support hard wired into the computer language. One is the one-size fits all WndProc() interface to the Windows API with its zillion messages. The other is the different-shoe-for-every-foot of the zillions of interfaces that make up COM along with the support for QueryInterface to interrogate objects for supported interfaces at run time.

      VB has message dispatch and COM support built in as language extensions to Basic. C++ is not supposed to need language extensions because of macros, classes and templates, and Microsoft uses a mishmosh of macros, classes, and templates to support message dispatch (the infamous message map macros) and COM with QueryInterface(). We can have flame wars about languages all we want, but I think that Windows support in VB is pretty transparent because they adapted the language while the Windows support in VC++ is pretty clunky because they have stuck to C++ without extensions, and there may be a cleaner way to use C++ to support message dispatch and QueryInterface(), but Microsoft has not figured it out but come up with a hodge podge (actually several hodge podges: MFC, ATL, and perhaps something else).

      Also, VB is truly visual with the Form Designer while I could never figure out how VC++ is visual -- you need to create Windows forms as dialog resources that you have to wizard your way into code somehow. In the Microsoft world, VB is the solution they offer for the cook who wants to develop a recipe program, for the race car team that wants to develop and engine analyser program, for the accountant who wants to develop a financial program. VC++ is the solution they offer for the hard-core programmer who wants to squeeze out efficiency that you can never get in VB, but is willing and able to put in the extra time required for a program that perhaps will have a large shrink-wrap market. VC++ is not meant for the rapid development of the application-specific one-of program.

      While Visual Basic is Microsoft's favored child for application software development, its syntax is not modern (i.e. C-like: I am a Pascal person myself, but I admit that C-style syntax has won out), its object model is restricted (lacks class inheritance), and it is slow. A VB program is actually pretty responsive to loading (a dig at Java) and to menu clicks, but it can bog down big time if you have heavy numeric stuff.

      To understand where .NET came from, you need to look at Visual J++, a product they developed by hiring Anders "Delphi" Hejlsberg away from Borland. Visual J++ had a C-style syntax (it was Java), but in terms of drag-and-drop form layout, WndProc() handling, and COM/QueryInterface() support, it was everything Visual Basic was and Visual C++ wasn't. It wasn't up to VC++ execution speed, but it was much faster than VB, and it was one of the fasted-executing Java's out there.

      J++ was also a marketing failure and the focus of the infamous SUN/Microsoft Java lawsuit. It wasn't proper Java, so it didn't get any Java people to cross over, and it wasn't of interest to the great unwashed masses of VB programmers either. The lawsuit and associated bad publicity about J++ didn't help either.

      Microsoft is not one to give up, and .NET is really J++ Version 2.0. Part of .NET and C# is Microsoft taking their football and going home over the Java lawsuit, part is trying a second time with J++. If you have tried Visual C# .NET, you really need to install a copy of Visual J++ 6.0, play with it, and experience the powerful sense of deja vu.

      Lets face it, the .NET langu

    • J# (Score:2, Insightful)

      by beggarstune ( 636814 )
      Class library support. Independently developed class libraries designed to provide the functionality of most Java Development Kit (JDK) level 1.1.4 class libraries and many of the classes in the JDK 1.2 java.util package specified in College Board's Advanced Placement curriculum for Computer Science.

      JDK 1.1.4 is at least 5 years old. How do they expect anybody to port their Java app to Microsoft J# if their Java is 3 versions behind? A lot has happened to Java inbetween their supposrted version and the
  • by ArmorFiend ( 151674 ) on Monday August 18, 2003 @10:46PM (#6729645) Homepage Journal
    I can just see some highschool newb coming across this article and choosing which language to learn based on it. Poor soul, so locked in for the rest of his life...

    Probably the guy that does that shouldn't use their follow up article in choosing a nice place to live:

    Compare and contrast Soviet Gulags!
    1. Western Siberia!
    2. Cuba!
    3. Wherever in China!
    4. Eastern Siberia!

  • "languages"? (Score:5, Insightful)

    by SHEENmaster ( 581283 ) <travis&utk,edu> on Monday August 18, 2003 @11:00PM (#6729729) Homepage Journal
    Non-portable C++,Psuedo Java with all the crap of and the portabiltiy of neither(C#), Wannabe Java(J#), and Beginner's Anal Soviet Interogation Code (VB.NET).

    Thank goodness I'm in Linux with gcc, gcj, and Java. All of which are free, and all of which are portable. I don't have to pay Microsoft, I can keep my code compatible, and I can compile to hundreds of platforms. When was the last time Visual anything supported compiling to the TI-89, Mac OS X, and Solaris platforms from a single codebase on a single computer?
    • The .Net framework and development tools are also free, and can be downloaded [microsoft.com]. And efforts are being made for making .Net portable. Examples include Microsoft's own Rotor [microsoft.com] (Windows, FreeBSD and Mac OSX), Mono [go-mono.com] (Linux) and DotGNU [gnu.org] (Linux).
      • Yeah, the "OMIGOD MICROS0FT SI TEH DEVAL!!" rabidness is getting out of hand. .NET is a nice architecture, certainly a damn sight better than the god forsaken cruddy mix of C/C++/COM/DCOM/ActiveX/Fnord/WTF technologies they had before. Even gnome and GNU (GNU OF ALL ORGANIZATIONS!) is adopting the .NET (well, CLR) runtime. Good riddence to C/C++ hodgepodge.
      • The .Net framework and development tools are also free, and can be downloaded. And efforts are being made for making .Net portable. Examples include Microsoft's own Rotor (Windows, FreeBSD and Mac OSX), Mono (Linux) and DotGNU (Linux).

        Language is nothing. The dependabilty and completeness of the libraries is really what's important.

        These projects may one day produces a sturdy C# compiler or CIL interpreter. But how complete will their libraries be?

        The Microsoft FCL library is huge. Before we can s

        • That FCL implemenation will also have to behave very closely to the Microsoft's library for compatibility. I don't think Mono, or DotGNU is going to be able to pull that off and I suspect MS realizes this as well.

          I suspect MS is relying on this. While the appearance of work to make .NET cross platform is important to MS's marketing, a real working Linux .NET implementation would be MS's worst nightmare.

        • The Windows.Forms bit will be tricky to handle even with the help of Wine, since there are a lot of assumptions in there very specific to Windows.

          I suspect what is more likely is that developers will make the guts of their software in some kind of library using the more general parts of the class library and language features and then bolt on a different UI for different systems. This has the advantage that the UI will better follow the "local" UI style, plus it means that the functionality of the program

  • Four? (Score:5, Funny)

    by AJWM ( 19027 ) on Monday August 18, 2003 @11:13PM (#6729798) Homepage
    I count two: an odd C++/Java-ish hybrid (spoken with three different accents) and something almost but not completely unlike BASIC.
  • by trouser ( 149900 ) on Tuesday August 19, 2003 @12:14AM (#6730064) Journal
    C# is really good compared to ahhh.....J# which is really good compared to being eaten by a crocodile which is really good compared to Micro$haft C++
  • by abulafia ( 7826 ) on Tuesday August 19, 2003 @12:23AM (#6730098)
    Christ, VB as a productivity language? J++ as a migration language? c# and a real development language may make some sense sometimes, if you're trapped. Sure, I guess VB works out, if you have to. There are languages that actually make string parsing sensible, but I'm not one to tell people what to use.

    But damn, they don't care at all about the most important languages they compete with, sh and perl. All the admin languages they've tried really quite blow. I fix problems every day with sh, and as far as I can tell, That Creepy Virus Vector is the response. That's not competition, that's pathetic. And I build applications in perl (and sometimes other languages) that pull people away from MS. I'm done ranting, back to coding for me (mostly perl, sometimes Java when I have to, C when it is useful, and various pgplsql/plsql/etc. DB languages when it makes sense.)

    • All the admin languages they've tried really quite blow.

      That's what happens when you design the system around a GUI rather than a command line. It's a lot easier to put a GUI on top of a command line base than the other way around.

      On the other hand, Apple's scripting language for MacOS wasn't bad. Guess it's just a Microsoft thing.
      • On the other hand, Apple's scripting language for MacOS wasn't bad. Guess it's just a Microsoft thing.

        Hell, now you can control the GUI itself [apple.com] with applescript! *note* I do not use AS so I can not comment on how well it works, I'll keep my perl thanks ;-)
      • Er, surely Windows *is* (historically) a GUI on top of a command line base?

        As for Applescript, I've only glanced at it, but what I saw looked hideously like a dialect of COBOL. (Yes, I'm prejudiced.)
        • What Windows was 8+ years ago is irrelevant; the NT series was always GUI-based and even the Win9x series pretty much so (quick, how do you edit the registry without a GUI?).

          Applescript may be verbose, but the point is that it gives you access to everything, as any decent systems scripting language should. The closest thing Windows has to an equivalent scripting language would be Dismal, er, Visual Basic.
    • I'm learning java at the moment (nightmare darling). Somebody pays me money to program in VBA (absolutely horrible, like fingernails down a blackboard), Sometimes I need to write shell scripts, but when I need to do something quickly, and easily, if it needs to be do something to my shell, I use backticks and perl. Perl is just the best. Terse, as elegant as you want, and not too many keypresses required (particularly for emacs users). Perl is the dog's bollocks.
      • I'm with you. I can't stand Java. If I were a sadist, Java is the language I'd make my submissives code in. Nice and restrictive, with horrific little tricks like the Date object.

        OTOH, I really like Perl's permissive notion of objects. We've built a niftly little framework and our own database libs that self configure against a database and let us crank out ungodly amounts of functionality quickly.

        But of course, didn't you know that every time you use emacs, God kills a kitten?... Vim is the path to en

  • by Futurepower(R) ( 558542 ) on Tuesday August 19, 2003 @01:20AM (#6730305) Homepage
    To me the most significant feature of .NET is that the languages are more easily de-compiled.
  • by Viol8 ( 599362 )
    Why isn't there MASM for .NET?? Oh , hold on....

    Seriously though , it would be interesting if MS (or Sun for Java) released an assembler for the
    intermediate language used in these VMs.
    • Comment removed based on user account deletion
      • Somehow I get the feeling that an interpreter for assembler rather defeats the whole point of writing
        in assembler in the first place :)
        • Knuth seemed to believe in writing in an interpreted "machine language" (which also had an assembler). He seemed to think his algorithms were more clear if they were expressed in atomistic operations.
    • Re:MASM? ILASM.... (Score:3, Informative)

      by thing12 ( 45050 )
      Seriously though , it would be interesting if MS (or Sun for Java) released an assembler for the intermediate language used in these VMs.

      ILAsm comes with the .net framework along with csc (C#), vbc (VB.Net), jsc (J#). That's what you're asking for, right?

      C:\WINNT\Microsoft.NET\Framework\v1.1.4322>ilasm

      Microsoft (R) .NET Framework IL Assembler. Version 1.1.4322.573
      Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.

      Usage: ilasm [Options] <sourcefile> [Options]

      blah blah...

      • Ah ok , didn't know about that. So why don't they ever advertise it?
        • they did indirectly through some of the msdn magazine articles as part of tutorials on the emit api and the overview of the VS.NET 2003
          too lazy to find them for you. checkout msdn [microsoft.com]
        • When .NET was in Beta test, before Visual Studio 2002 was realeased, this was how everyone used it - you used the command line tools & your favorite make utility. Theres tons of tutorials and FAQs and what have you on MSDN and all the .NET sites. It's not in the marketing literature because they're pushing VS .NET and it's RAD features - CIOs don't care about command line assemblers.
    • There's a Java assembler out there, called Jazmin. I might be wrong on the spelling of it though. I worked with it a bit in my compilers class. We wrote a Java compiler that outputted code for Jazmin to assemble into .class files.

      Coding Java in assembly isn't very interesting. Calling functions is a bitch, and since it's just a simple stack machine, you aren't going to get any better performance than you would by using a compiler unless your compiler really blows.
  • by Anonymous Coward
    with the number of .NET articles posted on /., this one is totally useless. It's so superficial as to be worthless. The only people the article would be useful for is some idiot IT manager with no clue.

    On another side, anyone happen to know if .NET 1.1 supports CPU affinity, ie, set a process to a specific CPU? I've been searching and googling for answers and haven't found any. SQL 64 apparently has the option, but that is SQL Server. I'm hoping someone knowledgable knows the answer to this, since all indi

    • hrm, not absolutely sure, but look at cpu gardening in asp.net (as opposed to cpu farming). That may have some features that do what you want.
  • .NET Borg Monkeys (Score:5, Insightful)

    by tedgyz ( 515156 ) on Tuesday August 19, 2003 @08:22AM (#6731975) Homepage
    I had to sit through 3 days of meetings listening to a .NET borg monkey feed his PHB the .NET mantra. Every problem we discussed could be solved by .NET.

    It got really bad when we were debating whether to go with a Web interface or a traditional windows interface. Monkey-boy says, "No problem. The windows forms can be cut and pasted to ASP forms. It will _only_ take us 3 months to convert the GUI." ONLY 3 months! I told my boss later that I could write the GUI from SCRATCH in JSP in 3 months! My blood pressure is rising just typing this. It took all my energy to stop myself from strangling the guy.

    This isn't an article. It's a marketing page.
  • by Anonymous Coward on Tuesday August 19, 2003 @10:37AM (#6733454)
    C++ - awful language, but at least it has high performance .. no wait this is the .NET version!

    J# - like Java, only different!

    VB.NET - Aw, isn't it cute! It's Microsoft My First Language! With real working arrays and everything!

    C# - Like Java, only different!

    My recommendation? Use C#, it's at least standardized and when you use it on Mono it will be the same. Of course the Mono runtime will have to be removed for the inevitable patent lawsuit, but the C# compiler will still be there for you!

    Thanks microsoft, for your rich palette of non-standard languages!
    • Re:quick summary (Score:1, Insightful)

      by Anonymous Coward
      WTF is everyones problem with VB.Net. It's fantastically easy to use and it offers the same access to the framework and API's that C# and all of the other >Net Languages do. Do you feel threatened that it is easy to read and understand and that formerly arcane functions that could only be harnessed with C++ are easily available to lowly VB developers? You people are pathetic. Use the tools that work. C# works. C++.Net works. VB.Net works, and works quickly.
  • i've read some parts of the article written by a Microsoft employee hosted on the Microsoft website.

    My point of view?
    This is MS trying to "sell" their products again

    "look it can do this, it can do that"
    "fast" ?

    i don't know if we can trust their objectivity.
    At least, i don't.
  • Now, let's do the comparison to what I think of as real programming languages such as ANSI C, C++, Java, and Perl and see how much M$'s languages SUCK.
  • by aled ( 228417 ) on Tuesday August 19, 2003 @03:36PM (#6737093)
    Funny, I can see just one semantic, in four syntaxis flavors.
    Something must be wrong with my eyes.
  • Haha. Microsoft Programming languages - get it?

    Boy, I tell you, the Slashdot editors have quite a sense of humor.
  • There are no usual "pro and con" lists...

    Cons? In a Microsoft product? NEVER!

  • I want to see a more organized asm language. But rather than call it asm.net or something silly like that, let's just break the words down.
    It's ORGanized ASM, so we can call it ORGASM.
    I bet we get a LOT of college students who want to try it out. ;)
  • Thought I'd post this because quite a few people I've talked to recently aren't aware of the "Mixed DLL Loading Problem" that affects anyone mixing native and .NET code in the same DLL (ie. linking objects compiled with and without -clr). This MSDN article [microsoft.com] describes a problem where:

    "...due to the way the loader works in version 1.0 and 1.1 of the common language runtime, deadlock situations are always possible with mixed DLLs..."

    The problem exists in versions 1.0 and 1.1 of the .NET runtime (1.1 being t

  • Summary
    Programming languages may be used to build a variety of solutions.


    That's amazing! Glad he told us!

"Conversion, fastidious Goddess, loves blood better than brick, and feasts most subtly on the human will." -- Virginia Woolf, "Mrs. Dalloway"

Working...