Forgot your password?
typodupeerror
Programming IT Technology

How C# Was Made 391

Posted by timothy
from the magic-dust dept.
prostoalex writes "Bruce Eckel (from the Thinking in C++/Java/Patterns/Enterprise Java fame) and Bill Venners have interviewed programming legend Anders Hejlsberg. After 13 years in Borland and joining Microsoft in 1996, Hejlsberg now leads the development of C# language and talks about the development process, reasons some things exist in C# and some not, as well as future directions."
This discussion has been archived. No new comments can be posted.

How C# Was Made

Comments Filter:
  • "Co-opt Java" (Score:2, Informative)

    by tealover (187148)
    I believe that was the mandate given Hejlsberg by Gates.

    • Re:"Co-opt Java" (Score:5, Insightful)

      by tjmsquared (702422) on Saturday February 07, 2004 @05:00PM (#8213838)
      I don't know why Java developers always feel the need to point out that C# took a lot of ideas from Java. I don't see C++ developers always pointing out that Java's mandate was to "co-opt" C++. Of course C# took a lot of ideas from Java (I don't think Microsoft has ever denied this), because Java got a lot of things right. C# also made a lot of improvements (event handling is MUCH improved in C# for example) and is a great language to program in. I think it would be even better if there were a .NET runtime for an OS other than Windows, but the good people on the Mono project are working on that already.
      • Re:"Co-opt Java" (Score:5, Insightful)

        by tealover (187148) on Saturday February 07, 2004 @05:07PM (#8213880)
        In a sense, Java was designed to co-opt C++. But co-optinging C++ was not made as a business decision to lock in Sun customers, it was made as part of Sun's vision of "The Net is the Computer" (or whatever they called it).

        Sun embraced the internet years before Microsoft and looked out into the future and realized that desktop computing and huge, standalone applications were going to be increasingly replaced by device computing and small, internet downloadable applications would be prevalant.

        To that end, they tried to design a language that was simple, that had built-in libraries to handle basic internet protocols and to a large extent, their vision was spot-on and Java was hugely successful.

        Without Microsoft spending years trying to undercut them it's very conceivable that Java would be the lingua-franca of the internet right now.
        • Re:"Co-opt Java" (Score:5, Insightful)

          by yomegaman (516565) on Saturday February 07, 2004 @05:12PM (#8213913)
          What are you talking about? Nobody uses java for "internet downloadable applications", or even intranet downloadable ones. Their vision of thin-client computing was shown to be a pipe dream, to everyone except you anyway.
          • Re:"Co-opt Java" (Score:2, Informative)

            by tealover (187148)
            I use them on my cell-phone daily. It appears you're still thinking in terms of desktop applications. You better start thinking in the now before you become obsolete.
          • uh, Java WebStart? If 'nobody' includes the US Government, then ok, you're right.
          • Re:"Co-opt Java" (Score:3, Interesting)

            by blincoln (592401)
            Nobody uses java for "internet downloadable applications", or even intranet downloadable ones.

            Retek [retek.com] does, and it's one of - if not *the* - most popular set of apps for the backend of the retail industry in the US.
        • by Anonymous Coward on Saturday February 07, 2004 @05:19PM (#8213965)
          But co-optinging C++ was not made as a business decision to lock in Sun customers, it was made as part of Sun's vision of "The Net is the Computer" (or whatever they called it).

          For fucks sake, man! Wake up and smell the marketing bullshit. The most innovative impressive thing about Java was that it was successfully marketed as basically the second coming (more tangibly as the solution to 10 different huge problems), all while just being another platform. Get it? They created their own platform without hardware leverage, OS leverage, app leverage, etc. It's bootstrapping by marketing.

        • Re:"Co-opt Java" (Score:4, Insightful)

          by __past__ (542467) on Saturday February 07, 2004 @06:04PM (#8214251)
          Without Microsoft spending years trying to undercut them it's very conceivable that Java would be the lingua-franca of the internet right now.
          Then thank god for microsoft. I am rather confident with an open-standards-based, multilingual internet as it is, even if it could have been better.
      • Re:"Co-opt Java" (Score:3, Insightful)

        by 1010011010 (53039)

        That C# takes ideas from java is irrelevant. .Net and C# exist for exactly one reason: Bill Gates wanted to stop Java. Bill likes to have control. He couldn't tolerate Java, because it didn't allow him to have control.

        Maybe you like C#, maybe you don't. maybe it's useful for your project, maybe it's not. Those are side issues -- its role as a tool is secondary.

        DotNet performs the task for which it was designed very well. That task is, of course, to contain programming talent and effort within the Windows
        • Re:"Co-opt Java" (Score:4, Insightful)

          by malakai (136531) * on Saturday February 07, 2004 @05:47PM (#8214138) Journal
          Those are side issues -- its role as a tool is secondary

          Your comment is a fascinating insight into a fanatical mind. You may not yet be as bad as the guy that lives on the corner of my block, with the foil under his NY Yankees basball cap, but the distinction is small.

          You've esentially said C# and .Net may be a great language and framework, may make a developers life easier, may generate better application for our clients (internal and external)... but you don't like Bill Gates and therefore any and all points are moot.

          Wonderfull logic.

          Your prison/Gates metaphor-pun is wonderfully melodramatic as well.

          Thanks for play,
          • Hehe! A little touchy, aren't you? I said nothing about liking or not liking Bill Gates. I also said nothing about your clients (internal and external).

            I just stated out the true raison d'etre of DotNet. it's role as a tool *is* secondary -- to Microsoft.

            I notice that you did not contradict me.

            MSFT created DotNet and C# to displace Java, maintain some measure of control over application development, and reinforce their OS monopoly. Please provide proof to the contrary -- you seem to feel strongly about
          • Re:"Co-opt Java" (Score:3, Insightful)

            by Brandybuck (704397)
            Your comment is a fascinating insight into a fanatical mind.

            Fanatical no. Cynicism spawned actions of Microsoft? Maybe.

            Despite whatever wonderful attributes C# and .NET have, they do not override the fact that the language and framework are under the control of Microsoft. All the people bitching at Sun's control of Java seem to just look the other way when .NET is mentioned. Who gives a rip that they've submitted it to some standards committee? Do you think Microsoft can't "embrace and extend" .NET? Do y
        • Re:"Co-opt Java" (Score:2, Insightful)

          by 91degrees (207121)
          Yeah, but Java existed because Sun wanted to have control, and was simply an attempted coup to sieze control from Microsoft. The Apple Mac existed because Apple wanted to control desktop computing.

          Most companies want to dominate the market. The difference is that for the vast majority of them, market domination is a ludicrous concept.
        • What about Apple and "Objective-C"? Isn't that a similar (but failed) attempt at a proprietary language?
      • I quote: "the cheddar breed jealousy 'specially if that man fucked up, get your ass stuck up."
      • Re:"Co-opt Java" (Score:5, Insightful)

        by kyz (225372) on Saturday February 07, 2004 @05:21PM (#8213982) Homepage
        Java was designed to co-opt Smalltalk, or at least Sun brand it and bring it up to date.

        Think about it... Smalltalk's main points were the single root object heirarchy, the bytecode compilation, and the large runtime library including full GUI. Did C++ have this? No. It was more "object oriented concepts ported to C" - lean and mean, machine dependant and no standard GUI. The C++ generics and the STL weren't standard when Java arrived.
        • Java is obviously a result of many older languages - it's syntax (and hughe parts of the semantics) are derived mostly from C++, the VM/JIT idea is largely a Smalltalk ripoff, garbage collection has been around for at least 40 years before Sun adopted it, some things it owes to earlier Sun research languages like Self (too few, IMHO), you name it.

          On the other hand, these are only means to an end. And, as stated in the early Oak/Java papers, this end was creating a language for mediocre programmers, i.e. a

      • Re:"Co-opt Java" (Score:5, Insightful)

        by matchlight (609707) * on Saturday February 07, 2004 @05:28PM (#8214009)
        But people DO say that Java was co-opted C++, including you and now .. me. Languages naturally progress from those that already exists like every other technology. Why reinvent the wheel and find out that squares don't work... over and over.

        Java is taking ideas from C# as well, just take a look at 1.5 with enums, yes I know they existed before C# but I think their existence in C# prompted the move.

        I just find it funny that pro-MS people often don't like to hear that C# could even possibly be an evolutionary step off of Java. And unlike older languages, Java itself is still evolving. The .NET runtime concept that works so much better than Java on a Windows machine is something that could exist for Java some day. C# might actually have a legitimately supported OS other that Windows, and although the Mono project is great, it ain't by MS.
        I've used both and the both work and they'll both change... for a while ... then another will come along.

        I wounldn't try to find religion in a programming language, they come and go too quickly.
        • Re:"Co-opt Java" (Score:3, Insightful)

          by 0WaitState (231806)
          just take a look at 1.5 with enums, yes I know they existed before C# but I think their existence in C# prompted the move.

          Uh, no. Enums' existence in ansi C and C++ prompted the move, given the large number of developers who work in both C/C++ and java, who know from real-world experience that enums improve maintainability and reliability of code.
      • event handling is MUCH improved in C# for example


        I dont agree. All C# does is take the widely understood OOP concept named the observer pattern and formalize it in language syntax (Delegates).

        I personally feel that simple syntax is something that makes Java great. Keep the syntax simple and recommend good OOP to do things like event listening.
    • Re:"Co-opt Java" (Score:5, Insightful)

      by prockcore (543967) on Saturday February 07, 2004 @05:07PM (#8213881)
      Fine with me. A java-like language that doesn't gobble ram like no tomorrow? Sounds good.

      As a bonus, Gtk# has the best API I've ever used in a gui toolkit.
  • by Anonymous Coward on Saturday February 07, 2004 @04:36PM (#8213676)
    There a great interview [sys-con.com] with The father of C# here too,
  • by enkafan (604078) on Saturday February 07, 2004 @04:37PM (#8213688)
    There is a pretty good interview [microsoft.com] on the .NET show on MSDN with Anders too. It runs about one hour, so get a comfy chair.
  • by atlasheavy (169115) on Saturday February 07, 2004 @04:39PM (#8213697) Homepage
    Joel Spolsky published a great article [joelonsoftware.com] a while back on .Net, his company's strategy for the platform, and why Anders so damn cool. Also, just in case you're curious as to how his last name is pronounced, it's pronounced hells-burg.
  • ...right here [artima.com] to save you a click thru the MSDN page.
  • by moronga (323123) on Saturday February 07, 2004 @04:53PM (#8213794)
    They hit the black key to the right of C.
  • by gurustu (542259) <gurustu@SLACKWAREatt.net minus distro> on Saturday February 07, 2004 @05:06PM (#8213876)
    It's very easy for Java devs (and I'm one) to sneer at C# as just another MS ploy to lure people away from quality, but I think that there's no question that C# has some language features that should be migrated into Java.

    It's well known that the C# designers paid a lot of attention to Java, but more importantly, it's also quite clear that they also spent a lot of time paying attention to the experience of developing in Java.

    So while I might not entirely agree with the uncaught exceptions or the way methods aren't virtual by default, I do think it would be a good idea for Sun to take the lesson from MS, and take what is best about C# and move it into Java.

    • by JohnnyCannuk (19863) on Saturday February 07, 2004 @05:19PM (#8213966)
      ...uhmm

      Go here [sun.com] and when you done, go here [sun.com] and get it.

      When you are done playing, come back and see if your post makes sense.
      • by gurustu (542259) <gurustu@SLACKWAREatt.net minus distro> on Saturday February 07, 2004 @05:35PM (#8214047)
        I've been following the 1.5 release pretty closely for a while now, and it has some excellent additions. I'm especially pleased with the generics, the enumerated constants, the ability to define a method as accepting an undefined number of parameters, and the improved monitoring. The amount of code I'll be able to remove from my codebase will be large.

        However, that doesn't invalidate what I said initially. 1.5 isn't a response to C# (well, maybe the enumerated types are), but seems to be kind of orthogonal to C#. It is a distinct improvement to the language, but that isn't the same thing as "embrace and extend". Those improvements don't give Java evangelists the ability to say "The C# language has no good feature that Java doesn't."

        I'm also making an argument about intellectual honesty. Java (like any other piece of software) will never flower into its full potential unless the people who believe in it are willing to acknowledge the strengths of its competitors, and then adopt those strengths where it can.

        It isn't a sign of weakness to do that, but a sign of strength.

    • Of all the features that C# has the only I would like to see in Java is explicit override. Fortunately there is a proposal for incorporating that with the metadata support in 1.5. The other features I want off of my projects.

  • It seems to me that big companies like Sun and Microsoft like pseudo-compiled languages like Java and those in .NET like C# for two reasons:

    1) Pseudo-compiled languages are easily decompiled. If a small competitor writes an especially useful program, it is easy to see the logic by just decompiling the source code. In business programming, the business systems logic can be EXTREMELY complicated. It's easier to copy it from a competitor who has proven success. See these links for information about decompilation. Of course, the best methods of decompilation are not made public:

    .NET Decompilers [program-tr...mation.org]

    Java Decompilers [program-tr...mation.org]

    A friend wrote this:

    "I regularly use decompilers for Java classes. The last library I decompiled is TupleSpace from IBM, a library for network communication (useful if doing clustering). The result was of a shocking clarity. :) Thank you IBM.

    "That was especially easy because the code had few local variables (in the bytecode, local variables have an identifier that is a number) and no obfuscation."

    2) Pseudo-compiled languages are slower. That raises the cost of hardware. Sun makes most of its money from selling hardware. Slower software requires more expensive hardware. Microsoft makes most of its money selling operating systems. The customers most important to Microsoft are not you and I. Microsoft's important customers are the systems builders like Dell and HP. Systems builders want slow software so they can sell more hardware. Microsoft wants slow software so people buy more systems and therefore more operating systems licenses.
    • In many cases, pseudo-compiled languages, or languages that use a VM are a better choice. No worrying about memory management, buffer overflows, etc.

      There will always be a place for C and C++ in places where you *NEED* low-level control over things like memory management, or where performance is very critical. But for most applications, this is simply not the case. You want a language that can do all you need it to do, and you don't want to worry about the rest of the details. Java and C#/.Net are the nex
      • You can get garbage collection and array bounds checking in fully compiled languages (such as D [digitalmars.com]), too.

        And you'd better still worry about such things to a certain extent, or else you'll be throwing exceptions on legitimate usage cases when your fixed-size buffer turned out to be too small, running out of memory because you didn't bother nuking references to old objects, etc.

    • Well, pseudo-compiled languages is hardly a "big company" thing. Look at Python for instance. It's all over the place (in the open source world).

    • > it is easy to see the logic by just
      > decompiling the source code.

      You mean bytecode, probably.

      > the business systems logic can be
      > EXTREMELY complicated

      If it's that complicated, having a bunch of decompiled source code is not going to be that useful. You're better off programming it yourself so you understand it and can change it when you need to.

      > Pseudo-compiled languages are slower.

      But not _much_ slower. A $3K dual CPU Linux server can serve up a lot of Tomcat hits. Need more?
      • Need more? Buy a load-balancer and a few more servers. Not a big deal.

        You just bought a bunch of hardware; you just proved his point.

        But thats not necessaraly a bad thing. Its a trade off. Hardware is cheap. Throwing hardware at the problem is very often the cheapest solution.

        • > You just bought a bunch of hardware;
          > you just proved his point.

          Not really; his point was that I'd buy a $60K E6500, my point was that I'd buy a couple of $3K pizza boxes.

          > Throwing hardware at the problem is very
          > often the cheapest solution

          Yup, and if you can cut your development time down by using Java vs C, everyone's happy.
      • But not _much_ slower.

        Says the person with the dual CPU server. From the first day of Java, the proselytizers kept telling me to get faster hardware and wait for the next version. I now have hardware 30 times faster, and four major versions later, and Java STILL crawls on my system. Even purely interpreted languages like Python and Ruby are faster!
    • That's the biggest FUD I have seem so far. Your talking about "pseudocompiled" makes me think you don't know how either language really works.
      OTOH I agree that both are relative simple to decompile.
      The speed will depend of your particular use, but in some cases programs in Java are faster than C programs.
    • by prockcore (543967) on Saturday February 07, 2004 @06:11PM (#8214284)
      1) Pseudo-compiled languages are easily decompiled.

      Um, compiled languages are easily decompiled as well.
      http://hte.sf.net is a badass hexeditor/disassembler.

      Case in point, I walked through the assembly of iTunes to figure out the AES key that iTunes uses for iTMS. And iTunes was written in C++.
    • It seems to me that big companies like Sun and Microsoft like pseudo-compiled languages like Java

      I guess you've not heard of gcj, TowerJ or the other traditional ahead-of-time compilers for Java, eh?

      Java is not necessarily a VM based language - that's not to say that VMs aren't useful in lots of situations. Obfuscators also often work well. Of course, if you're doing server-side code, decompilation isn't an issue at all...

      Nice straw man though... ;-)

  • Having used TP and DelpiI was kind of disappointed to see Anders join Microsoft a few years back. But now behold .... Delphi 8 adopts quite nicely to .net and is actually giving Borland a new lease on life and delivering where Kylix couldn't.

    Having used both java and delphi I allways missed some sort of generics. I found Anders thoughts [artima.com] to be quite interesting. Question: is it possible to change the java generics-implementation in such a way that it would loose the limitations mentioned (and changing the
  • Checked Exceptions (Score:5, Informative)

    by po8 (187055) on Saturday February 07, 2004 @05:16PM (#8213951)

    Actually, Java supports both checked and unchecked throwables: the latter with the class Error. My programming style is to make throws that I don't expect to be "routinely" caught throw Errors rather than Exceptions. An Error can still be caught, but since you don't expect it, you needn't declare it.

    The checked exceptions are still useful for the case where it would probably be a bug not to handle the exception, e.g. "search found no element" or "file not found". The reason for the two kinds of throwables is exactly this: you don't want to declare that every method doing division throws DivideByZero. Unfortunately, the Java library designers don't seem to have gotten it, and so there's a bunch of things like IOException that IMHO should have been Errors.

    • by AndyS (655)
      I think you probably want RuntimeException rather than Error - error is meant to be things like 'OutOfMemory' or 'LinkingError'

      NullPointerException is a runtime exception for example, and so is ClassCastException.

      If you want to squash IOExceptions then just wrap them in RuntimeExceptions - ie

      try {
      blah;
      } catch(IOException ioe) { throw new RuntimeException(ioe); }

      - but I'd wager that there might well be some remedial action you can take other than this.

      There are cases that go the other way - for examp
    • by Anonymous Coward on Saturday February 07, 2004 @05:56PM (#8214194)
      Java supports both checked and unchecked throwables: the latter with the class Error.

      Unchecked exceptions should be derived from the RuntimeException class. Generally subclasses of Error are not meant to be caught ("An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch" - from the Javadoc for Error).

      you don't want to declare that every method doing division throws DivideByZero

      That doesn't throw an exception/error at all, it returns NaN [sun.com].

      there's a bunch of things like IOException that IMHO should have been Errors

      IOException is something that needs to be checked. It can occur because of low disk space, broken network connections (including NFS mounts), bad character coding, etc. Even FileNotFoundException is a subclass of it.
      • Ive always considered the Exception/RuntimeException/Error thing to be a little poor in the design.

        I dont really see the need for two different unchecked throwables, and certainly not because of loose contracts like "you shouldnt try to catch errors but if you like you can try to catch RuntimeException". I'll catch whatever I like thank you very much.

        I also dont like C#'s ham-fisted approch of having no checked exceptions at all.

        Personally I would have gone with Throwable as an abstract base class with C
  • why trust your development to a language designed to lock you in to Windows? C#, for all its niceities is just a way of getting you to buy more Windows 2003 Server licenses.
    • by prockcore (543967) on Saturday February 07, 2004 @07:05PM (#8214641)
      why trust your development to a language designed to lock you in to Windows? C#, for all its niceities is just a way of getting you to buy more Windows 2003 Server licenses.

      C# is just a language, it doesn't lock you into Windows at all. Mono supports the entire C# language.

      It's the classes you choose to use that lock you onto a specific platform.

      You can't blame C# if people want to use classes that aren't available on other platforms.

      Its like saying that C++ sucks because DirectX doesn't work on Linux.
      • I'm not a c# programmer but...

        Is there a STL-type library under c#, and is there a port under mono? If not, it would make c# under other os's kindof pointless, if a few base classes werent implemented.

        just curious..
  • They lie! (Score:5, Funny)

    by dexterpexter (733748) on Saturday February 07, 2004 @05:52PM (#8214168) Journal
    Gonna burn some karma on this...

    Gandalf: This is C#. Forged by the Dark Lord and his engineers in the fires of Mount Redmond. Taken by him from the hand of evil himself. All who use it are bound to him. Gates needs only this ring to cover all the lands of a second darkness... He is seeking it, seeking it; all his thought is bent on it.

    Frodo: Alright, we put it away. We keep it hidden. We never speak of it again... No one knows its here, do they? Do they, Gandalf?

    Gandalf: Unfortunately, yes. The power of Gates is far reaching. The innocent would use C# from a desire to do good, but through them, it would wield a power too great and terrible to imagine.

    You get the idea... ;) And yes, I am just teasing.
  • by ajagci (737734) on Saturday February 07, 2004 @06:10PM (#8214281)
    I think on many issues, Hejlsberg is missing the point and the reasons he gives aren't necessarily the actual reasons why particular design tradeoffs are good ones.

    But it really doesn't matter. The changes that C# made relative to Java are obvious and proven (e.g., value classes, removal of statically checked exception declarations, declared unsafe code sections). Many of them had made Sun's bug parade. All of them had been in other languages before either Java or C#. In fact, C# is, in many ways, close to Modula-3.

    There seems to be another reason for some of the design decisions: patents. Sun has patents on several aspects of the JVM and Java, and if Microsoft wanted to be free of potential future claims by Sun, they had to avoid those in their own competing virtual machine.

    Keep in mind that Hejlsberg is also a salesperson for the language anyway. That means that he may not be telling you the real reasons behind design decisions, but the reasons that sell the language well.

    In any case, however it came into existence, C# is a somewhat better language than Java, and we should be happy about that: whether you are planning on using C# or not, it raises the bar for what is considered standard in industry. Without C#, Sun probably wouldn't even have made the largely cosmetic changes they made to Java in 1.5, and maybe the continued existence of C# will force them to fix other misfeatures of Java and the JVM in future versions. And C# (but not .NET) may turn out to be the free and open language that Java should have been; time will tell.
  • worst C# drawback (Score:3, Insightful)

    by iezhy (623955) on Saturday February 07, 2004 @06:27PM (#8214383) Homepage
    most serious C# drawback is that it doesn't have (and probbably will never have) so rich and wide open source community like Java does (Apache group, Object Web group and many many many more...).

    Each tiny crappy component, each crappy lib for C# out there on the net is sold, and sometimes for outrageous prices (a month ago seached for a plugin to generate properties from variables - something like getter/setter generator macros, so common in most Java IDEs - found it for 100$ per seat! OMG!). there is no idea of sharing, neither the source nor experience, and this IMHO will be the main cause of C# setback.

    And oh, most computer literate people pronouce '#' as 'hash', not 'sharp' :-))
    • Re:worst C# drawback (Score:4, Informative)

      by enkafan (604078) on Saturday February 07, 2004 @10:39PM (#8215831)
      Here's your macro: http://weblogs.asp.net/jan/archive/2003/04/29/6168 .aspx [asp.net]
      There are plenty of people working on tons of free libraries out there. The gotdotnet workspaces are pretty good place to search for things, but your best best is to follow the weblogs on asp.net.
    • Re:worst C# drawback (Score:4, Informative)

      by Bazouel (105242) on Saturday February 07, 2004 @11:55PM (#8216172)
      Ever bothered to look at http://www.codeproject.com ??

      How about you write your own getter/setter macro and publish it there ? That is how a community is built, slowly but surely.
    • wrong analysis (Score:3, Insightful)

      by ajagci (737734)
      most serious C# drawback is that it doesn't have (and probbably will never have) so rich and wide open source community like Java does (Apache group, Object Web group and many many many more...)

      It is true that there is more open source server-side web stuff for Java than there is for C#. But, against that, you have to hold that C# actually has a full-featured, high-performance, compatible open source implementation. Also, you can get a full-featured, open-source, widely-used GUI toolkit for C#, namely G
  • by teetam (584150) on Saturday February 07, 2004 @06:37PM (#8214444) Homepage
    Why do people spend so much effort fighting over which tool/language is better? The whole question is secondary to me.

    The truth is - existing software quality sucks. There are a few exceptions, but there are too many poor quality products being shipped everyday sometimes costing millions of dollars. The fault is seldom with the tools or the language of choice.

    There are so many parts of the whole software development process that needs to be improved. With the right process, people and management it is possible to make great software regardless of the language.

    When automobile engineers argue, do they argue about the quality of their cars, their features and design or do they childishly bicker about which wrench is better?

    • It's a good point, but the language can make a difference. C has a lot of potential for error that a higher level language just doesn't have; the most obvious example being strings. In C, to concatenate 2 strings, you might type

      char *s1 = "The quick";
      char *s2 = "Brown fox";
      s1 = strcat(s1,s2);

      Which could crash, or foul up data (or possibly do nothing) because you're writing over the end of a pointer. A high level language will have strings as a built in type. Concatinating them will simply create a new

    • There are so many parts of the whole software development process that needs to be improved. With the right process, people and management it is possible to make great software regardless of the language.

      There is no such thing as the right process, there is no such thing as the right people, and there certainly is no such thing as the right management, because none of these things can be designed. On the other hand, tools can be designed and implemented to perform optimally, and it is not all that hard

    • "There are so many parts of the whole software development process that needs to be improved."

      Completely true.

      In a time when tools are myriad, code can be found for free, and the Internet archives and Google searches lessons and tutorials for us, software developement is crazy. And its funny and ironic that the most essential part to software developement, the developement (it's process: the drafting, coherent, problem-solving design, habitual testing and review, documentation, etc.) is seen as expendab
  • One thing I've never seen explained in any of the designer interviews on C# or Java is why they both have the redundant 'new' keyword.

    Neither language allows you to create objects on the stack, so using new to denote 'on the heap' is completely redundant.

    Also, why can't language designers take hints from the *productive* languages as well as the *popular* ones.
    I'm not saying that good programming is a speed typing contest, but modern, popular languages require far too many key presses to get stuff done.

    C
    • Personally, I like the 'new' keyword. It makes it very clear where an object is being instantiated, and not just assigned through a function (that's what var = Type(args) looks like to me).

      Also, C# allows the core types to be allocated on the stack. Here is a line I pulled from my code:
      byte* buffer = stackalloc byte[256];

      stackalloc can only be used inside an unsafe context.

    • In your example, I know with complete certainty that I am creating a new "Type" and assigning it to the variable "varName". This is not the case if it used the syntax of Python. How do you know I am not calling a method called "Type"?

      Scott
      • Re:Its not redundant (Score:4, Informative)

        by hobuddy (253368) on Saturday February 07, 2004 @08:28PM (#8215151)

        In your example, I know with complete certainty that I am creating a new "Type" and assigning it to the variable "varName". This is not the case if it used the syntax of Python. How do you know I am not calling a method called "Type"?

        You don't know, and you shouldn't.

        Suppose at first you do, in fact, instantiate a new object via the 'Type()' call. Later, during the optimization phase, you discover that in most cases you can return a reference to a pre-existing, pooled object. In Python, you can make that change without breaking client code; not so when object creation is explicitly annotated.

        As to whether Type is a method, function, or class constructor, it doesn't matter as long as the returned objects implement the required interface.

    • Actually, it's worse than you think...

      int i = new int(1);

      No heap allocation has occurred, we've just allocated an int32 on the stack and dumped the output of the int32 constructor into it. That new keyword is really just an indicator that tells us we're calling a constructor.

      And how about this:

      int[] ints = {1, 2, 3, 4, 5};

      That just allocated a new heap object, and there's no new keyword in sight...

      (Before anyone argues that that's just like string s = "hello", it isn't... string literals are constants
  • by Kupek (75469) on Saturday February 07, 2004 @07:03PM (#8214626)
    C++ is the opposite. In C++, you can do anything you damn well please on a variable of a type parameter type. But then once you instantiate it, it may not work, and you'll get some cryptic error messages. For example, if you have a type parameter T, and variables x and y of type T, and you say x + y, well you had better have an operator+ defined for + of two Ts, or you'll get some cryptic error message. So in a sense, C++ templates are actually untyped, or loosely typed. Whereas C# generics are strongly typed.

    I disagree with that assessment. Both C# and C++ generics/templates are strongly typed. It's just that the enforcement happens in different places.

    In C++, if you try to stick a class into a templated class when that class doesn't have a particular member function defined, the compiler will yell at you, just like Hejlsberg said. But for some reason, this doesn't count as type checking? Yes, template error messages can be strange (and very long) if you're not familiar with them. But that's just a lesson in "know your tools."

    To me, "strongly typed" is strict type enforcement at compile time. C++ templates certainly do this.

    Constraints, however, are something that I think are a generally good idea. Stroustrup's reasoning for not including them in C++ was that "Requiring the user to provide such information decreases the flexibility of the parameterization facility without easing the implementation or increasing the safety of the facility." (The Design and Evolution of C++, Stroustrup, 343).

    He does, however, show an interesting way to get around this using inheritance:

    template <class T>
    class Comparable {
    T& operator=(const T&);
    int operator==(const T&, const T&);
    int operator<=(const T&, constT&);
    int operator<(const T&, const T&);
    };

    template <class T : Comparable>
    class vector { // . . .
    };

    (The D&E of C++, Stroustrup, 344)

    This technique is similar to how C# does constraints, class List where T: IComparable. One is supported and enforced by the language, the other is a natural consequence of the languages facilities. In general, I think that constraints are probably a good thing. Having an error message like "Can not instantiate class Y<T> because T does not implement z()" is probably best, and when looking at a class' declaration, it would be nice to see up front what assumptions the templated class makes.
    • AIUI, the major reason many of the big names in C++ don't like language-supported constraints on type parameters is that just having "derives from this base class" isn't a sufficiently general condition for good support of generic programming.

      C++ enforces any necessary interfaces at compile-time, by checking whether the instantiation of a function template can be interpreted properly with the functions available. Requiring every class that supports == to derive from EqualityComparable is just a cumbersome

  • by 21mhz (443080) on Saturday February 07, 2004 @08:03PM (#8214975) Journal
    I must say he doesn't seem to grok exceptions very well.
    Anders Hejlsberg: The scalability issue is somewhat related to the versionability issue. In the small, checked exceptions are very enticing. With a little example, you can show that you've actually checked that you caught the FileNotFoundException, and isn't that great? Well, that's fine when you're just calling one API. The trouble begins when you start building big systems where you're talking to four or five different subsystems. Each subsystem throws four to ten exceptions. Now, each time you walk up the ladder of aggregation, you have this exponential hierarchy below you of exceptions you have to deal with. You end up having to declare 40 exceptions that you might throw. And once you aggregate that with another subsystem you've got 80 exceptions in your throws clause. It just balloons out of control.

    Well, if you're a Java programmer worth your salt, you DON'T propagate every exception class the underlying modules might want to throw. You make your code catch exceptions rising from below and either handle them or massage them into the exception set your module exports. This is much better for the upper-level users because they want to deal only with situations raised by, and meaningful for, the APIs at hand, and they don't have to care about what would brew beneath.
    If you don't want to lose exception stack information, as of J2SE 1.4, you can chain an original exception to your higher-level exception, so that everything would be rolled down nicely in a trace printout.

Thus spake the master programmer: "After three days without programming, life becomes meaningless." -- Geoffrey James, "The Tao of Programming"

Working...