Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] XP and .NET popularity

Expand Messages
  • Ron Jeffries
    ... I haven t chatted with any XP luminaries since OOPSLA. However, I, too, am doing .NET. Here are some of my reasons: .NET is a very interesting technology.
    Message 1 of 219 , Dec 31, 2002
    • 0 Attachment
      On Tuesday, December 31, 2002, at 1:10:29 AM, David Vydra <groups-xp@...> wrote:

      > I've been noticing lately that many XP luminaries are doing work
      > with .NET.

      > Is it due to:
      > a. .NET is a superior technology
      > b. .NET market is growing fast and we like to eat well
      > c. We want to take revenge on Java for J2EE :)
      > d. .NET apps are significantly simpler to create and deploy than
      > equivalent java apps
      > e. Other____________

      I haven't chatted with any XP luminaries since OOPSLA. However, I, too, am doing
      .NET. Here are some of my reasons:

      .NET is a very interesting technology. I like the multi-language support in
      particular.

      .NET seems to be slightly cleaner in some ways. I like C# better than Java.

      I don't do Java, so can be closer to the front of the .NET wave than I could
      with Java.

      I wanted to write about how to learn, so I had to start with something I
      didn't know.

      Scott McNealy is a whiner and really ticks me off.

      If I run into any XP luminaries (aren't they those little candle in paper bag
      things?) that are doing .NET, I'll ask them about it. Which ones did you think
      were .NETting?

      Ron Jeffries
      www.XProgramming.com
      Only the hand that erases can write the true thing. -- Meister Eckhart
    • Daniel Sheppard
      ... If the language isn t doing type-checking on you, you wouldn t have had to refactor that test to make it compile. You would have run your tests and see
      Message 219 of 219 , Jan 5, 2003
      • 0 Attachment
        > > Well, you had a test that did "new Car(owner)" and asserted
        > that this object
        > > returned what you expected from toString() before you
        > refactored. So you break
        > > your unit test.
        >
        > Yes, that test is in the unit tests for Car. When refactoring
        > Car, I of
        > course changed that one to take an OwnerList, rather than an
        > owner. The
        > problem is with someone who *calls* that method. I'm supposing that I
        > forgot about refactoring DmvImporter as well.

        If the language isn't doing type-checking on you, you wouldn't have had to refactor that test to make it compile.

        You would have run your tests and see that it fails, and your first thought at that point should not be "how do I change the test to make it work?" but "how do I change the code to make it work?". This would have led you to change your toString() method operates correctly regardless of it being an owner or an ownerlist. If you don't have control of all the calling code, or you can't trust yourself to change it all, this is the only solution you should be entertaining.

        Daniel Sheppard

        daniels at pronto.com.au
        #####################################################################################
        This email has been scanned by MailMarshal, an email content filter.
        #####################################################################################
      Your message has been successfully submitted and would be delivered to recipients shortly.