Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

C# and CLI Fast-tracked to ISO 83

Posted by Hemos from the get-yer-ISO-on dept.
jdfox writes "It wasn't that long ago that ECMA approved standardisation of Microsoft C# and the associated Common Language Infrastructure. Now they have used the "fast-track" agreement between ECMA and ISO to move ISO ratification forward quickly, according to this article on CNET. We should see ISO C# by January.
Maybe this will finally persuade Sun to take their leash off of Java."
This discussion has been archived. No new comments can be posted.

C# and CLI Fast-tracked to ISO More

C# and CLI Fast-tracked to ISO

Comments Filter:

  • And we care because... (Score:5, Insightful)

    by glenstar ( 569572 ) on Friday October 11, 2002 @11:20AM (#4432242)
    I don't think it really matters whether there is a C# ISO standard or not. People are either going to use it or they are not. Did corporations flock to using Java^H^H^H^HECMAScript) just because it became "standardized"?

    The whole thing is moot.

    • Well, since it is standardized in ushc a way Microsoft can advertise it as an open language and not vendor specific like Java is, some Twilight Zone vibes there...
      • Some of us will remeber when Sun was working on ECMA standardization for Java. They withdrew it when MSFT started maneuvering to create portability problems by manipulating the standard though their ECMA participation, and Sun saw they couldn't prevent it.

        Of course, MSFT isn't worried about C# being unportable...

    • Re:And we care because... (Score:4, Insightful)

      by pizza_milkshake ( 580452 ) on Friday October 11, 2002 @11:51AM (#4432448)
      Did corporations flock to using Java^H^H^H^HECMAScript) just because it became "standardized"?

      As far as I know, one of the major complaints about Java is the fact that it isn't standardized by an outside party like ECMA or ISO, but by Sun itself, meaning developers have as much say in the Java standard as they do over MS's VB. (please let me know if i'm wrong about this).

      personally, I've taken a look at C# and like it. of course MS claims it's more related to C++ thna Java, but C# has more in common with Java than anthing else.

      I assume the reasoning behind the standardization is to compete with Java... MS hasn't really had its own enterprise-level language before this (the candidates would be VB, which IMHO sucks and forces you to stick with Windoze and C++ which doesn't mean you have to use VC++). personally I'm much more likely to use it if its standardized, because I know MS can't easily pull off an "upgrade" or change the EULA and break/change the language for their benefit.

      of course, by the time C# is ISO standardized (assuming it will be) the MONO project [go-mono.org] should be well enough along to use C# seriously... of course since the languages are so similiar why not just use Java in the first place?

      lots of questions, not many answers.

      • of course since the languages are so similiar why not just use Java in the first place?

        That's somewhat true from a pure language standpoint, but I think you'll find developing for the two environments to be *vastly* different in terms of all the little details that matter and can make life pleasant or a living hell. Whether you're making your life pleasant or hellish is a function of how much you have to swim against the current in your current organization to use one tool set or the other.

        Surprise, surprise, this isn't a technical issue. Within the context of a corporate operational environment, it's a cultural issue.

        I think Microsoft is correct in stating that language choice is no longer the most relevant problem in software development anymore (if it ever really was).
      • of course since the languages are so similiar why not just use Java in the first place?
        Yeah, it's not really all about language choice at this point.

        You'd chose .NET over J2EE for:

        Superb development environment for much greater productivity. Perfectly integrated database, XML, source control, web page, middle tier, etc. etc. development

        Well thought-out framework with all sorts of good stuff already done for you

        ASP.NET WebForms--really a fantastic way to program web pages

        Multiple languages in one project

        Performance on the Windows platform

        • You choose J2EE because you actually have a choice of:

          In short, you choose J2EE in order to have a choice of what software you want to use within your business and how much you are willing to pay for it, what hardware (Intel, Sun, IBM) and operating systems (Linux, Windows, Solaris, AIX, OS/400) requirements you have, and what requirements you have on the performance (single Intel box to 64 CPU Sun box to IBM mainframe) and scalability of your application.

          You make J2EE match your requirements rather than force yourself to match .NET requirements.

      • Re:And we care because... (Score:1, Insightful)

        by Anonymous Coward

        As far as I know, one of the major complaints about Java is the fact that it isn't standardized by an outside party like ECMA or ISO, but by Sun itself, meaning developers have as much say in the Java standard as they do over MS's VB. (please let me know if i'm wrong about this).

        Yes, you are wrong.

        Java is standardized and evolved by the sun community process. Nearly every company having a market in enterprice Java is participating.

        A lot of individual members are participating as well.

        E.g. the new java compiler for jsr014, very likely the standard compiler distributed with Java 1.5, is written by Martin Odersky and his team.

        A lot of standards around J2EE are heavy influenced by third parties. E.G. Appache Tomcat is now the official reference implementation of the Servlet API of J2EE.

        JDO, the new way of persistance in Java is heavyly influenced by the major Database companies and the leading oo database companies like POET.

        Best Regards,
        angel'o'sphere

        Sorry, I moderated this thread and thats why I post anonymous.

      • No, one of the major complaints about Java is that it continues to get more bloated. There are a few vocal OSS advocates who can't bear to have freely available software being though of as "free", because as everyone knows its more important to know how to make beer than to have some given to you.

        Unfortunately, IMHO, Sun hasn't kept a tight enough leash on Java. It started with an excellent vision, but then let the "community" get in on the act and push for every more standards, without really considering the benefit.

        Its very much like the SourceForge effect. Start a project, put some ideas on a web page, and wait for someone to do the work. The JCP has provided a lot of solutions by providing APIs to develop against, but there is no implementation.

        Worse, the APIs are often poor and bloated as a result of a lack of proper domain understanding, and provision for any conceivable implementation.

        Java and its developers would be better served by providing additional libraries where they are warranted - not standards - and leaving the market (or OSS) to fill in the gaps with components. It has done wonders in the Microsoft world.

        Some cases in point: Apache's log4j and regexp packages are widely considered the de facto standards, and have been around since well before JDK 1.4 was in development. They are also considered technically superior to the functionality which has appeared in 1.4 as a result of the JCP.

        In fact the JSR for regular expressions is reads like a child's christmas list, as it is part of the NIO request, and includes a desire for printf-style formatting.

        Sun did an excellent job with the design of Java. Its a pity there are a bunch of wannabees who are too shortsighted to see the value of leaving the control of the language's development in the hands of technical experts, and providing or acquiring what they specifically need in their own back yard as components.

      • As far as I know, one of the major complaints about Java is the fact that it isn't standardized by an outside party like ECMA or ISO, but by Sun itself, meaning developers have as much say in the Java standard as they do over MS's VB. (please let me know if i'm wrong about this).

        You're wrong about this. For all of its flaws, the Java Community Process [jcp.org] allows anyone from a large corporation to a single unaffiliated individual to help chart the course of Java evolution. This is a far cry from MS's focus-group oriented evolution of the VB platform.

  • ISO's 7 layer OSI really beat non-std TCP/IP (Score:5, Funny)

    by mekkab ( 133181 ) on Friday October 11, 2002 @11:37AM (#4432341) Homepage Journal
    I gotta say I think its great for my career that I support a 7 layer OSI kernel stack. I mean, it was the first ISO network standard! And that really means something in todays "just get it done" business climate. I'm sure there are plenty of opportunities out there for me!

    De Juris standards don't mean squat. I'll take De facto every day.

  • What good is it (Score:1, Insightful)

    by Anonymous Coward
    C# will not get me a job as a systems developer. C++ will. C will. Java maybe. C# more than likely not. C# will only benefit those doing Windows app development. Of course, I may be wrong and if I am, please enlighten me because I'd like to learn the language but don't want to waste my time on something that isn't marketable.

    • Re:What good is it (Score:4, Insightful)

      by uradu ( 10768 ) on Friday October 11, 2002 @12:24PM (#4432775)
      > C# will not get me a job as a systems developer [...]
      > don't want to waste my time on something that isn't marketable.

      Ok, so you're saying that systems development jobs are more plentiful than general desktop app development? Which universe are you living in? This is regardless as to the merits of C#.

      • Ok, so you're saying that systems development jobs are more plentiful than general desktop app development? Which universe are you living in?

        Sounds like The Real World to me. Relatively few companies actually write general purpose desktop applications, but almost every business in the world of any decent size employs in-house developers writing custom code that never sees general market exposure. I can get a job anywhere doing this kind of work. Well, that is, when the market turns around :-\

        Or maybe we have a different understanding of the semantics of "system" or "systems developer". To me system does not just (or even most often) mean operating system.

        • > To me system does not just [...] mean operating system.

          I'm sorry but that's the traditional meaning of the term. If you list "systems programming" on your resume, most people would expect you to be able to write device drivers and such.

    • Re:What good is it (Score:2, Interesting)

      by perljon ( 530156 )
      In my experience, if you catch a Mircrsoft technology in the height of it's marketing buzz, you will get paid big to implment it. For example, Active Directory or in my personal experience ADSI (which is just a common library for Active Directory)

      • Re:What good is it (Score:2, Interesting)

        by Anonymous Coward
        Absolutely correct. The trick (if money is your main concern...as mine is) is to find out what'll be hot for the next 1-3 years and learn it. In 1.5 years you should be reassessing for the next cycle. Best way for a developer to make cash is to follow the hype trends. I'd love to be a system programmer but I'm a web and app programmer because that is the space where it is easiest to find jobs. I've been a C++/VB COM, DCOM, and COM+/PHP/ASP/Java/C# developer at different times in my career...but then I'm a greedy bastard. Oh and I've only been working in the "real world" for about 7 years if that gives you any idea how many times I've bounced aroudn from technology to technology to stay as marketable as possible.

    • Re:What good is it (Score:3, Interesting)

      by j3110 ( 193209 )
      Monster.com begs to differ:
      Java: 961
      C++: 827
      C#: 118
      C: 885 (also returns C++/C# matches... some want both, few want just C)

      Java + C++: 381

      I'll give you two guesses of why someone needs to know both Java and C++. (Hint, they aren't moving from Java to C++.)

      C# has went from 0->118 in a few months. I think it's surpassed C already. You should have said
      Java absolutely. C++ absolutely. C# soon enough. C not in another few months.

      The programming community is moving to an object oriented philosophy, mostly because XP is common place and XP pretty much requires OOP.

      Given monster.com isn't the all knowing oracle, but I think it does show a trend. In the end, there will be two options for high level languages: Java and .Net. If for no other reason than portability and OO.
      • I'll give you two guesses of why someone needs to know both Java and C++. (Hint, they aren't moving from Java to C++.)
        1. They need to be able to write the high performance, low-level stuff in C++.
        2. There aren't enough good C++ programmers around in the job market, and they'd rather take a good programmer who knows Java and train him than a bad programmer who knows some C++ and will be a liability.
        C# has went from 0->118 in a few months. I think it's surpassed C already. You should have said Java absolutely. C++ absolutely. C# soon enough. C not in another few months.

        Um... How many decent programmers do you think there are in the world? Quite a few, that's for sure, and many of them program in C, C++ or Java. Under the present circumstances, many of those are sitting in stable jobs, and their employers are keeping a stable staff, so there's not much going on in that market.

        The only places the industry is really moving now are bad/unlucky people who've been hurt by the recession, and buzzwordites who follow wherever the hype takes them. Given this climate, it's not surprising that buzzwordy languages have lots of job offers, but that certainly doesn't make them mainstream, and is no guarantee that things will stay that way in the long term.

        The programming community is moving to an object oriented philosophy, mostly because XP is common place and XP pretty much requires OOP.

        XP is commonplace? I've never seen a professional development company that uses it on a widespread basis. Some of the better guys have looked at it, and plenty of places have been implementing parts of what XP recommends since long before the hype. But it's hardly what I'd call mainstream, however much those who evangelise on its behalf might like to disagree.

        As for OOP, if anything, I think the market is starting to realise that it isn't a panacea. Everyone and his brother has tried it, a lot have liked it more than what's gone before, but I'm waiting for some of the more recent developments in programming theory to hit the mainstream now, not for the next big OO revolution.

        • In what circumstance do the speed differences in C++ and Java justify not having the broad compatibility and stable free API's of java?

          Embedded: J2ME is compiled directly to bytecode, there is no difference between C++ and Java. Java still allows a user to write a program, using a subset of the API's of Java, and run it on virtually all consumer, and most other platforms.

          Applications: Processors are -> 3Ghz, RAM is cheaper than pizza and bear. Development costs will dictate the path. It's hard to argue with the hardware abstraction and the availability of free classes that go with Java. 9/10 programming in C++, my bugs and problems where with the subtle API differences between different systems. XP broke a good chunk of my program, and for no good reason. Wouldn't have happened if I were using Java.

          The only place where C will remain prevailant for now is low-level systems programming. It's not likely anyone is going to write a kernel in Java (although with gcj and the like, it is possible).

          You're arguement would have one believe that good programmers choose Java, but the jobs are mostly for C++/C. I don't buy that. Programmers choose the languages that are profitable and make sence to them. Companies choose languages with least TCO. If a project is easiest to implement in Java, that's what a company will choose. Java is usually easiest, but only because there are so many good API's, and it's a strongly typed object oriented language making it easy for developers to understand each other's code. (no a->b[35].chocolate_pudding(-1)?null:0 BS)

          You're arguement about C/C++ developers having stable jobs is exactly backwards from what you think. The number of jobs for C/C++ developers are not dependant on how many C/C++ developers are out of a job. It's based on the growth of market. If companies that specialize in C/C++ projects where growing, then there would be more job openings. The Java market is growing faster than any other. C++ is just behind it. C, on the other hand, is a niche market for system level program. How many kernels are needed? It doesn't grow very much at all. It's the new assembler. It's the great platform portable assembler! .Net has went from a rate of 0 job openings per unit of time, to >100 in 1/3 a year. If it grows linearly, it will be with java in 3 years. Thats pretty good, but I don't think it'll see those numbers until it is truely cross platform.

          The entire XP ideology is based on OOP(small talk originally). Most of it doesn't make sence elsewhere. Refactoring is the #1 concept of XP adopted by most people. That concept was designed specifically for OOP. Refactoring was common place before XP. Now it has a name, and a method to make it easy using OOP.
          • In what circumstance do the speed differences in C++ and Java justify not having the broad compatibility and stable free API's of java?

            In any circumstance where you want:

            1) A responsive user interface.
            2) High speed code execution.
            3) Parameterized classes.
            4) Stable APIs.

            I was laid off a year ago from a company that was an all-java shop. For years I had written software exclusively in Java. I believe the reason we couldn't get customers for our product was because our product was 100% Java and was SLOW. After leaving the company and going back to C/C++, it was quite a hit on the head to see just how much faster C/C++ was in comparison. Pure logic and method invocation easily felt like an order of magnitude faster.

            I'd go back to Java if I had the chance, but all that "write once run anywhere" speak is just crap. I can't tell you how many hours I spent at a Solaris box trying to make code that worked perfectly under NT/2K to work under Solaris.
            • but all that "write once run anywhere" speak is just crap. I can't tell you how many hours I spent at a Solaris box trying to make code that worked perfectly under NT/2K to work under Solaris.

              Hmm.. WORA seems to work just fine for me. I know shit about Solaris (or any OS really) but my Java programs seem to work quite reliably on all systems that have solid JVM implementations on them.

              Of course, WORA is easily broken by a newbie programmer so it does require a competent team of Java developers to be able to achieve it.

              • Of course, WORA is easily broken by a newbie programmer

                Well we don't call them newbies, we call them "Junior Engineers". But yes my job was come along behind them and fix anything that was causing problems moving over to Solaris.

                so it does require a competent team of Java developers to be able to achieve it.

                A competent team of developers can write C++ code that is portable between Windows and Solaris with forks for the UI. What good is Java if it still requires a team of senior engineers to avoid all the landmines? As many have said before, that isn't write once run anywhere, it's write once test everywhere. All of our software had to be thoroughly tested on both Windows and Solaris. I'm not clear that Java saved us anything in time spent in development, but cost us a lot in performance.
                • A competent team of developers can write C++ code that is portable between Windows and Solaris with forks for the UI.

                  Of course they can. Or with any other language. With Java it is a lot less work though.

                  What good is Java if it still requires a team of senior engineers to avoid all the landmines?

                  Java, or any other programming language, will not do away with the fact that programmers in general need to know what the hell they are doing. If you thought you can go with Java and do not need experienced people to use it effectively, then you have made choices based on wrong assumptions.

                  As many have said before, that isn't write once run anywhere, it's write once test everywhere.

                  Again, just shows that you did not know what you were doing. Everyone doing serious Java development does extensive testing on the platforms they expect to use the most. Java does not promise to do away with testing. If you thought it will, then you made your choices based on bad assumptions.

                  WORA has worked great for me. People are using software written by me on platforms I never even anticipated while writing it. However, I do not think I can get quality Java software without an experienced programmers or by dropping solid testing procedures. It is quite stupid for anyone to think they could.

                  • Of course they can. Or with any other language. With Java it is a lot less work though.

                    Is it? The only benefit to Java over C++ here is Swing. And Swing is painfully slow (I once had the discomfort of using a swing-based Java app running on solaris over exceed... the memory still makes me cringe)

                    If you thought you can go with Java and do not need experienced people to use it effectively, then you have made choices based on wrong assumptions.

                    Okay, this is one important point with Java... You need just as much talent with Java as with C++, so Java sees no savings in hiring costs.

                    Everyone doing serious Java development does extensive testing on the platforms they expect to use the most

                    Yes, this is because each JVM has its own peculiarities and bugs. So you can't "write once". You "write once" then refactor for each platform you run on. So Java doesn't save that much time there.

                    Every project I've seen (whether I worked on it or not) that has used Java for its "run anywhere" promise has paid the gains in time of not having to port to another platform with trying to improve their business logic so that the software isn't so slow it offends users, and working around JVM bugs of different platforms (or dealing with UIs that suddenly look hideous when using Sun's braindead selection of fonts on Solaris).
          • In what circumstance do the speed differences in C++ and Java justify not having the broad compatibility and stable free API's of java?

            Anywhere you need high performance code more than you need the assistance with portability. That means almost any serious maths and any serious database work, for a start, never mind real-time stuff, instrument control, etc.

            Applications: Processors are -> 3Ghz, RAM is cheaper than pizza and bear. Development costs will dictate the path.

            I doubt it. Management's idea of what it thinks is best will probably dictate the path, and unless you're blessed with technically competent managers, this will usually slow you down significantly in getting your job done. Alas, such is life.

            Further, if you think that modern desktop PCs have adequate processing power and memory for serious crunching, either numbers or databases, I'm afraid you're a little short of the mark. I'm going into work tomorrow, profiler at the ready, to hand-optimise some algorithms that just aren't running fast enough to be acceptable in our product. They do some relatively straightforward maths, but still take several seconds on the top-of-the-range Dell box on my desk with realistic data sets.

            This is already code that's had its basic data structures and algorithms optimised by some very clever people for a decade or so, which means it really is the raw processing power that's lacking. I don't even want to contemplate the performance hit that would be entailed in shifting this sort of thing to a system running a language with the sort of overheads imposed by Java.

            It's hard to argue with the hardware abstraction and the availability of free classes that go with Java.

            No, it's really not. Many of the free classes available for Java are... erm... not very good. Today's Java standard library is an example of poor design that would make even those responsible for MFC proud, a perfect illustration of too many sous-chefs spoiling the broth.

            9/10 programming in C++, my bugs and problems where with the subtle API differences between different systems. XP broke a good chunk of my program, and for no good reason. Wouldn't have happened if I were using Java.

            Interesting you say that. I've programmed a bit of Java in my time as well, and I'd say the complete opposite. I currently work on a C++ project that compiles on something like 15 different platforms, without any major problems porting it. (The UI and such are simply abstracted out into platform-specific libraries, none of which is really more than a few functions in one file to call the relevant UI toolkit.)

            In contrast, I've rarely seen a truly successful use of Java as a cross-platform programming environment. It certainly has its good points, but I don't think that's one of them. And I'm sorry, but I don't for an instant believe that your XP problems would have been easier if you'd been using Java; the most popular JVM for Windows couldn't even handle a mouse properly with Swing programs for several years, which isn't exactly confidence-inspiring.

            You're arguement would have one believe that good programmers choose Java, but the jobs are mostly for C++/C. I don't buy that.

            Not at all. My argument is that a lot of serious programming is done in C++, and that needs good people. There aren't enough good C++ people moving in the market right now, so they look to good people who know Java and would be willing to make the jump.

            Companies choose languages with least TCO. If a project is easiest to implement in Java, that's what a company will choose. Java is usually easiest, but only because there are so many good API's, and it's a strongly typed object oriented language making it easy for developers to understand each other's code.

            Sorry, but you really gave yourself away there. Every single sentence above is so clearly, demonstrably, provably wrong, that it's not even worth refuting them (though I can provide copious arguments to support this claim if you really, really want).

            (I'll gloss over the next bit, which seems to say that because one popular Internet job site lists a whole 100 jobs for .Net programmers, that means .Net is taking off. Get back to me when it's 100,000 jobs, or maybe 1,000,000. This particular job site is hardly representative of the industry anywhere near where I work, speaking as someone who actually moved jobs recently.)

            The entire XP ideology is based on OOP(small talk originally). Most of it doesn't make sence elsewhere. Refactoring is the #1 concept of XP adopted by most people. That concept was designed specifically for OOP. Refactoring was common place before XP. Now it has a name, and a method to make it easy using OOP.

            Sorry, but that, too, is Just Plain Wrong(TM). There is very little about XP that is OO-specific. Major concepts, such as pair programming, the importance of unit tests, constant refactoring, developing in small increments and so on have all been around since long before anyone hyped them up and called them XP, and all apply to any other non-OO programming methodology you care to name. I'm pretty sure we used to talk about refactoring (in the sense of reorganising your code to reduce redundancy and improve the design) long before I ever heard of XP, or probably even OOP, too.

            • If you think DBMS systems need processor time, you are badly mistaken. You could write a DBMS in VB and it would be sufficiently fast on old hardware that the harddisk would be the limiting factor.

              For mathmatical algorithms, most people bypass even C and go straight to assembler (though they usually keep an unoptimized version for portability).

              Any management decision is going to be made on economical principals, or else your business isn't going to stand up to competition. Usually, and unfortunately, management isn't always well informed. As you would see someone like me telling management what moves to make, I see management taking your advice and see similarities with cobol.

              Modern computers are fast enough to do 99% of all tasks easily in the slowest of environments. You won't be able to name more than 1% of tasks that require more processing power. If Java was 50% the speed of C++, then by moores law, only software designed for the last year's hardware would not be possible to do in Java. In C++, design and development of software that was that processor intensive would take about a year. Especially considering that you have to worry about buffers and leaks.

              A lot of serious work is still done in C++ and C. I don't dispute that. You wouldn't have disputed that a lot of serious work was being done in COBOL about 5-10 years ago. Java is more efficient because the DLL hell is worried about by one single team of developers. That is the TCO savings. We already have a partial Java port of our software, and I just tested it 2 days ago under XP. It works great so far. Works fine on Linux as well.

              I can't believe you would compare the Java API with MFC. MFC isn't even really object oriented. The types of the data are very similar to assembler directives for declaring memory (DWORD, etc). The Java API is hierarchial, fully OO, and very easy to understand. There is an object for a button, not an ID. I hated every minute of using VC++ and the MFC. Borland's class library was a lot more sane, but interoperability with other Win32 API's that didn't have the BCL to wrap it was a nightmare that I only solved with embedded assembler. C++ is not pretty when dealing with the Win32 API. Then with C++, if you want some sane way to do something, you have to rely on some proprietary third party library. So far, we haven't needed a single third party library in the rewrite of our current software in Java.

              The most popular JVM for windows?? If you mean MS's VM, I'm not even going to argue with you. It's a POS. Anyone programming for that is going to thing Java is a POS. Anyone claiming that it is faster than 1.4.1 from SUN, hasn't really compared the two.

              The wave may not have reached where you work yet, and it may never considering that you might be in the 1% where C++ makes sence. If performance is that important at where you work, then you aren't working in a normal job. You may be working on a kernel, photoshop, or 3d studio, but the average person is building a dynamic storefront online, games, DBMS, etc that are more IO bound than CPU bound. In each of those cases, you will have a larger problem delivering data through the network, rendering graphics on the GPU, and accessing the disk respectively.

              I admited that refactoring came before XP hype. refactoring is one of the greatest forces for OOP though. It is much easier to refactor code and keep an object performing it's usual task than it is to do the same with a set of dlls. dlls compartmentalize sets of functions into something almost recognizable as an object. Else, a bunch of free floating functions would be impossible to maintain or to refactor.
              • If you think DBMS systems need processor time, you are badly mistaken. You could write a DBMS in VB and it would be sufficiently fast on old hardware that the harddisk would be the limiting factor.

                For many databases, sure; I certainly wasn't intending to suggest that all database work is processor-bound the way heavy maths and such is. It obviously depends on the nature of your queries, though. Serious database servers use all those megs of memory as one big cache for a reason, after all, and they can potentially make much more effective use of it with a language like C or C++ that can reach lower.

                Rather than simply sling our personal beliefs, though, let's look at some real examples. At the last count, something like 75% of the most-visited web sites -- nearly all of which are basically database front-ends -- had their back-end software written in C++. (Sorry, I forget the source; probably a quick Google will turn up a copy of the article somewhere.)

                For mathmatical algorithms, most people bypass even C and go straight to assembler (though they usually keep an unoptimized version for portability).

                That's really not true. Most well-regarded mathematical libraries in the world are currently written in C or C++. (This is my current line of work, not idle speculation.) With modern processors and architectures, it's often the case that a compiler will generate better output code than raw assembler written by an average programmer, because it will take account of pipelining and caching, systematically allocate the use of registers, etc. I know of at least one big company that writes most of its consultancy stuff in C++, but keeps its core engine in C, basically because the C compiler does a better job of optimising the output code than the equivalent C++ compiler.

                Assembler can be useful, but you really need to know what you're doing to better a modern compiler on a modern processor architecture, and obviously you also sacrifice portability for that code. That's usually too expensive a price, in practice.

                If Java was 50% the speed of C++, then by moores law, only software designed for the last year's hardware would not be possible to do in Java. In C++, design and development of software that was that processor intensive would take about a year. Especially considering that you have to worry about buffers and leaks.

                I'm afraid your bias is really showing again. Modern Java is certainly of a comparable speed to C++ in everyday code, assuming a decent JVM, JIT compilation, etc. But when it sucks, it really sucks. The things Java forces upon you for safety -- garbage collection, array bounds checking, yada yada -- can make literally orders of magnitude difference to execution speed. It's just a matter of how much these things get in the way. Normally, it's not enough to worry about, but in some applications, it hurts all the time.

                I'm afraid I can't resist rebutting your bash on C++, either. How can you arbitrarily say that development of processor-intensive software would take about a year? More to the point, why do you think C++ still suffers from buffer overruns and leaks? I haven't had either in years (and I have the results from running Purify and such to back me up on this). Any competent C++ programmer uses the tools available to avoid this, reducing the claims to an old wives' tail thrown about by C++ bashers who don't know their subject.

                I can't believe you would compare the Java API with MFC. MFC isn't even really object oriented. [...] The Java API is hierarchial, fully OO, and very easy to understand.

                Granted, that was slightly harsh, but not that harsh. MFC is certainly deserving of criticism, but while Java's APIs may be more "OO", they aren't much better designed in many places. Just look at the number of redundant or deprecated classes lying around. Just look at the effort it takes to read in and parse a string. And why do I need two GUI APIs that are similar but different anyway?

                There are some languages and libraries out there that do certain things well. Perl does regular expressions and string parsing well. VB does Windows database front-ends well. FORTRAN is legendary for its high-performance maths, and still more than holds its own for the practising scientist who's not a software engineer. C++ combines low-level flexibility and high-level code well. Which part of the Java API would you cite as being exemplary, or even particularly good, in its handling of a particular field? What proportion of it would you say is pure bloat?

                The most popular JVM for windows?? If you mean MS's VM, I'm not even going to argue with you. It's a POS. Anyone programming for that is going to thing Java is a POS.

                Sorry, I should perhaps have said "most widely used", rather than "most popular" to make myself clear. I agree that it's very bad. But the point is, it's what most people running everyday desktops (and not a few businesses who write Java apps but don't know better) are using. I've downloaded any number of "portable" Java tools from the net, and these days, I've given up, because they all fall over somewhere or other on Windows boxes. I just don't have the time or inclination to update to the next incarnation of Sun's JVM every few weeks on all the boxes I use.

                Clearly this is not a problem for businesses who are setting up all their own systems, and can choose to use Sun's JVM for their back-end stuff, which, incidentally, seems to be where all the serious action in the Java world is these days. It makes a mockery of the "write once, run anywhere" claims, though. As the critics have always pointed out, you need a good JVM first, and there ain't a whole lot of them around.

                The wave may not have reached where you work yet, and it may never considering that you might be in the 1% where C++ makes sence.

                I accept entirely that my current job is not the average in the industry. However, I think it's a little unfair to claim that Java is suitable for 99% of the work out there. There are a lot of "business apps" (aka databases) out there, sure, but there are a hell of a lot of non-database applications, too:

                • scientific/number-crunching (I feel you underestimate the number of such applications there are)
                • operating system code, not just the OSes themselves, but device drivers -- thousands of them for dozens of OSes
                • embedded control code for just about every piece of consumer hardware in the world, for a start
                • instrument control code used to drive most of the machinery in industry
                • games, not just for graphics/sound, but for the AI and the sheer scale of modern games environments as well
                • networking applications, which by their nature run close to the metal.

                This list obviously isn't comprehensive, but it does illustrate a few of the big non-database development areas. A cursory look down any job ads page, or one of the few surveys into areas of work within the industry if you can find them, will demonstrate that these areas make up just a little more than 1% of software development that goes on!

                I totally accept that Java is improving in some of these areas, particularly things like embedded control software. It's still the new kid on the block, though, and it has a long way to go before it's playing with the big boys yet. However, with these fields being as vast as they are, there just ain't enough good C and C++ programmers to go around. A lot of people over the past few years have come out of uni straight into Java programming jobs, that being the most popular principal language on CS/SE courses over recent years. It makes sense to tap that market for good people -- not a few of whom will have taken such courses -- and thus you get the ads for "Java or C++ programmers".

                Well, that's my theory, anyhow. :-)

          • Embedded: J2ME is compiled directly to bytecode, there is no difference between C++ and Java.

            All Java code is "compiled directly to bytecode." And if you meant that it's compiled to machine language, that doesn't seem to be true based on what I've read about J2ME, the CVM, and the KVM.

            • I think that's only true on platforms that opted to not have it so. Most devices out there run Java natively. (where most devices is quantity of different models, not including the popularity of some out there) A lot of the newer phones have a java implementation in the hardware directly. They don't run a VM. The handhelds mostly are run from a VM-ish thing. Not that Java can't be compiled for a set of cheap hardware already on the market. You can do completely Java embedded programming that runs natively on hardware that isn't expensive. There are smart cards that run Java natively. It would be incredible stupid of me to have said that all embedded devices can run java natively. I just assumed that the reader would interpret that as that the hardware does exist, is popular, and is competively priced with non-Java hardware.

              That arguement aside, I could probably write an entire OS in Java and compile it down to x86 code. SUN should really consider the merits of writting a JVM in Java. They can then distribute a tool to translate Java code to native instructions. They already do this with their jit, they now only need to do it with a stand alone tool. It's all OK though, because Gnu is doing similar things for them, and there are already commercial products that will convert any SWT project into native binaries that need no JVM.

              I'm sorry for any confusion or misleading statements. Keep in mind, though, that java is a language as well as a platform. GCJ will compile Java 1.1 compliant code into a linux elf binary. No real difference than C++ there, and it will have the same performance, close anyhow, to C++. If you are interested in using Java for an embedded application consider both alternatives (GCJ and Java hardware) for one that fits your needs better. It is viable.

  • A good thing (Score:5, Insightful)

    by kawika ( 87069 ) on Friday October 11, 2002 @01:23PM (#4433354)
    A standard will at least give the Mono folks something to point to if Microsoft decides to move the goalposts with later changes to C# or the CLR. We need an open-source implementation of this because Microsoft has the right idea.

    The C# versus Java debate is a red herring that's most interesting to language bigots. There's a more important difference between the philosophies. Sun wants the world to write all its code in Pure Java, abandoning the non-Sun environments they currently have. This is a great idea for full software programmer employment, we can spend all our time rewriting the world's code in Java. Not.

    Microsoft wants to let people to migrate the stuff they have slaved over for the past 25 or so years into a shiny new Common Language Runtime environment. Yes, there is a new C# language, but the front end can be other languages as well. With minimal changes, a business can take the core of a Cobol program that has proven itself over the past 10 years, recompile it with a Cobol compiler that generates CLR [netcobol.com], and drop it down into a new distributed environment. They can write the web interface to that Cobol core in any language they want, including C#, VB, Javascript, Fortran, or even Java (J++) if that's what their current programming staff is trained to use.

    For a moment, ignore the language bigotry and disregard whether Microsoft might implement this in some way that will hurt their competitors. Which approach seems to be the most logical to you? Rewrite all the world's code or reuse what you can?

    • Don't try running any of the C or C++ or even VB code people have slaved over for the past 25 years in the CLR. It just won't work without extensive re-writing. The difference between the Java VM and the CLR in this respect is almost entirely marketing, not reality. The CLR does not magically let you run code written for other languages in its environment--the code has to be written 1) with portability in mind in a language with limitations that match the CLR's own, or 2) changed extensively to match the expectations of a CLR-compatible compiler. My problem with .Net is not with its technology--which is superior to Java technology in some ways--it's just that .Net is late to the game without bringing a compelling reason to switch. The marketing reasons (multi-language support) are largely dishonest.

      • Wrong (Score:2, Interesting)

        by jdevons ( 233314 )
        M$ has a tech that they call It Just Works (IJW) that, suprisingly, does!

        We converted 2+ million lines of c/c++ code to CLR in a matter of days.

        Now, making some of those c++ classes interact with other .NET languages is a pain, but it DOES NOT require rewriting.
      • If you're talking about UI or systems programming code I would agree, but the majority of "business logic" code should move over pretty painlessly. The point for these folks is that they want to deploy existing apps on the web (sometimes integrating multiple apps in the process) and they don't feel like retraining their staff in Java and rewriting every line of code in Java. I didn't make up that Cobol example.

      • Re:A good thing (Score:2, Interesting)

        by Tsali ( 594389 )
        VB

        You have to be kidding.

        VB.Net apps have little resemblence to their old ones. Most VB6 apps that would have required migration have stayed as COM because it would have been too costly to migrate. It is not even the same language in my opinion. It's like English - someone from Massachusetts has a hard time understanding someone from Kentucky. Sure, it's the same language, but they are both wacked out.

        It would be nice if VB were ISO'd, but you'll never see that, and that's a shame... although it's a crappy language to some, it is (was?) relatively easy to pick up and run with. C# comes close, as does Java, but Basic is one of the first things people use, thanks to Office and all their other stuff.

        Microsoft..... why do I have to be your bitch?

    • With minimal changes, a business can take the core of a Cobol program that has proven itself over the past 10 years, recompile it with a Cobol compiler that generates CLR, and drop it down into a new distributed environment.

      ...or they can expend zero effort (dollars) and leave it running just fine right where it is.

      They can write the web interface to that Cobol core in any language they want, including C#, VB, Javascript, Fortran, or even Java (J++) if that's what their current programming staff is trained to use.

      ...just like they already can now (excluding C#), with Cobol programmers comfortable in their green screens and Web developers happy in their browsers.

      Actually, C# and the CLR are really intriguing and seem to have some interesting new features, but Java is here NOW and enjoys wide industry support with multitudes of cross-vendor tools and compatibility. At my workplace, we have been stepping into the J2EE waters and have been having huge success at webifying legacy COBOL/mainframe applications and integrating them with newer distributed systems. In particular, we've been using WebSphere Studio Application Developer (WSAD) to develop and deploy to WebSphere running directly on the mainframe. We could just as easily be running WebSphere on a non-mainframe server or even be running applications on another J2EE server entirely. Just for fun, we deployed our app to Weblogic on a Sun server and it ran just fine. We have one old mainframe coder who spends about 30 minutes per legacy application running IBM's Enterprise Access Builder to generate Java interfaces to the programs, and then throws the Java over the wall to us. He knows absolutely zero about Java and distributed systems. We had a future need for bar coding, 10 minutes browsing on the web gave us a demo download of a generic barcode generator running as a servlet alongside all our other code, and boom, every page that needed a barcode was just a snip of HTML away.

      We love this approach because 1) it allows a wide choice of hardware from small to scaling way past the biggest PC servers 2) it allows a wide choice of software (servers, dev tools, third-party add-ons. etc.) 3) employees can use their existing skills at different stages of the development with a good interface/workflow between stages 4) it appears to be reaching a stable, mature technology phase and most importantly 5) it allows us to leave our legacy applications unchanged in place where they are, integrating them into new systems while giving us time and breathing room to make careful decisions on what core business logic makes the most sense to migrate and which functions should stay right where they are. And we are doing this today, right now, with stable tech that just works.

      It will be a while before C# and the CLR can present the same ability and maturity.

    • 'The C# versus Java debate is a red herring

      your right. Java failed to become the de-facto language which is what it was intened to be. But its stuck around and become a really useful tool (which is what a language should be)

      .. the next 'war' is gonna be .NET versus Linux
    • With minimal changes, a business can take the core of a Cobol program that has proven itself over the past 10 years Cobol without a mainframe behind is not really used. And I don't think that moving from MVS for instance toward a windows.net cluster is a "minimal change". And who wants to interface with Cobol in any language they like ? It's not the Cobol philosophy.
    • With minimal changes, a business can take the core of a Cobol program that has proven itself over the past 10 years

      I think you're being overly optimistic here. Ask any VB developer how minimal the changes to move to .NET platform are. *smirk*

      Pay more close attention to reality, and less attention to Microsoft marketing machine, please.

    • Which approach seems to be the most logical to you? Rewrite all the world's code or reuse what you can?

      And get stuck in the Microsoft Windows, IIS, Exchange, SQL Server, VSS hell?

      I'll take any approach over that one in a heart beat.

  • I am sure there are many developers who have skills ranging from C,C++ to Java C# including all scripts and tools associated with it.And these developers have ability to quickly learn new technology b'cos of their experience and get expert to some extent.I consider one myself.

    But where are Jobs man..? Companies are cutting their IT budgets as much as Bush is planning to spend it on war.Companies are installing new security systems which filters out software developers.:-).So guys what do you think ? Does it matter if Microsoft C# is going to ISO or Java released new EJB specification ?

    • Re:C#, Java, Microsoft,IBM whatever.Give me a job. (Score:1, Funny)

      by Anonymous Coward
      You could join the Army.
    • C# is hot and getting hotter. The skill sets are in short supply. If you are developing business apps I would suggest that it is a good choice to invest time in. If you get real experience in it and .NET now you're bankable for years to come.
      • If you get real experience in [C#] and .NET now you're bankable for years to come.

        I wouldn't bet my career on it. Going with Microsoft's latest and greatest isn't always a sure thing, as anyone who went into Visual J++ found out a few years back, and anyone with lots of VB6 background is discovering right now. Microsoft has already dropped several major parts of .NET faced with, essentially, a complete lack of interest in them (which was widely predicted by anyone who watched the industry months earlier). What makes you think there will be any serious advances in C#/.NET's CLR in the future if they don't take off either?

        If I could take a language like C++ or Java, which has a wide range of applications and is widely adopted across the industry, or a language like C# that's much hyped but currently little used, I'd go for the safe bet if I knew I needed a rent cheque next month.

  • This move is clearly designed to help C# and .NET get into classrooms. Currently C++ is used by many schools because the faculty wanted to teach something that had been "standardized". They don't want to teach a language that's going to be obsolete in a year. This is particularly true at two year schools, where there isn't time to teach multiple languages, and the students are intending to go straight into the job market.

    Of course, then these same schools go ahead and use Visual C++, so standards go right out the window. But the buzzword remains powerful in their purchasing decisions. For this very reason, Java is only being hesitantly adopted.

    If Microsoft can get C# standardized, they won't have to use the standard. They just need it for marketing.
    • From the College Board AP Computer Science 2003 Course Description:

      The AP Computer Science Examinations will require knowledge of the programming language Java beginning with the 2003-04 academic year and the 2004 examinations. The exams will continue to cover the fundamentals of computer science taught in first-year college courses. However, those sections of the examination that require the reading or writing of actual programs will use Java rather than C++.

      So maybe standardization doesn't matter for getting the language into the classroom? Next year every AP computer science student will be learning Java.

      Adam
      • Well, standardization is a huge factor, at least where I am, but there are other factors too. Certainly they look at what the AP course is using, and that's why Java is hesitantly being brought into the curriculum.

        However, the Java course will be CSC 228, while the intro(115) will continue using C++. Why they're incorporating Java as a second-year course because maybe 2% of their students are coming in having taken the AP course is beyond me.

  • What would ISO-C# help as long as the main vendor doesn't support multiple targets?

    99% of the C# code will use some part of the Windows classes space, and will be inheritely importable.

    So that leaves some academical playing with the rest. I'm also afraid that will be Mono's place.

    This is no competition of Java (and I'm no Java lover btw, just a realist), which is already entrenched in a lot of companies.

    Not standards, but decent vendor support is what
    C# needs to make it credible for non M$-shop managerial eyes.
  • This is the most brilliant marketing scheme I've ever seen.

    Standardize your own technology, try to get people to buy into the standard, and then ... ... embrace and extend it.

    Microsoft should try and patent the process by which it re-proprietizes it's proprietary products.

Slashdot Top Deals

If you want to put yourself on the map, publish your own map.

Close