Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements


Vesuvius vesuvius Count Orlock
  • Office 2007 adoption numbers, anyone?

    jjesse said:
    No hard numbers from me, but I used to have to save my docs in .doc, .xls, etc format to ship them to clients.  Now it doesn't matter.  I just send them in Office 2007 format and people accept them.

    Not the best of barometers as the Office 2007 compatibility pack was released for Office 2003 that allows them [clients] to view the newer formats , I know of a few places this is used.

    Office generates about the same revenue as Windows (would you believe it or not), and I don't see people intentionally bashing Office 2007 like Vista . I think most enterprises will retain their old Office 2003 machines, but on new machines you can have XP, but definitely take Office 2007. There is a tonne of business value there, unlike Vista.

  • Advice to job seeker in Edinburgh is needed...

    Could not resist it.

  • Silverlight 2: Bad Core Library Design?

    This really should not come as a surprise (if true)

    Silverlight is anaemic. Even using the client profile for example [27 MB], you don't have access to the windows forms System.Design namespace. Cut down frameworks have cut down features, and the Silverlight team must have resolved to reach a certain functionality threshold to create some types of applications - not all.

    I agree with you that OO is being limited, but it is targeted at a browser, and this is V 1.0 of a proper runtime you can program against. I forsee the next version incorporating the features developers moan about  the most.

     It's a judgement call when choosing what to put in and leave out, and only feedback will resolve the issue.

  • Windows and Office will be written in native code forever

    wkempf said:
    Ion Todirel said:
    Are you listening to a word I've said?  I never claimed JIT wasn't unique to VMs (NOT the CLR).  But how does a JIT make you more productive?  What does runtime performance have to do with developer productivity (not to mention, you can't make a claim that JITed programs automatically perform better than compiled programs).  Intermediate code isn't going to help in any way when it comes to GC, but even if it did, how would that increase developer productivity?

    The "specifics" is precisely what your doing in this post.  This thread started out with flawed comparisons of native vs. managed languages.  You want to compare two languages (with out specifying those languages, btw) instead of discussing the non-specific managed vs. native.  Is C# more productive than C++?  Well, without getting into specific usage scenarios, yes, I believe everyone would have to agree that C# is more productive.  But that's not relevant to the post that started this thread.
    It is however important to note
    Would you say that this is a fair assessment, or is my reasoning misjudged?
    This post has transmogrified into misinterpretations and some factual stuff. Not all your reasoning has been correct either, nor have have you gone to any great lengths to define parameters for debating X versus Y, then getting into any specifics. It is relatively easy to respond to each post and say you're not sufficiently specific.

    Eric Gunnerson was a PM on the C# team, and has some illuminating views on the subject. My mistake at times, is tacitly assuming that people understand my point of an argument, and don't interject any factual stuff.

    Programming is like that I guess - most times - where people are passionate about certain subject areas, but find it difficult to communicate their stance in a comprehensible way. My proof of the productivity benefits are reflected in my bank balance (not great, but much better), and the sheer amount of stuff I've been able to develop. No need to try and explain that, when the fruits of my C# Vs C++ toils are abundantly ostensible.

    Maybe I was just a Sh** C++ developer Big Smile

  • Windows and Office will be written in native code forever

    staceyw said:
    wkempf said:
    I have to agree with wkempf here.  vesuvius, I really don't understand what your trying to say here.
    By your definition they may be General Purpose, but I define general purpose insofar as, if I need to hire a developer here in Yorkshire, how easy is it for me to do so? It is very difficult as it is to get very experienced .NET developers at present, and looking at D, for example, a first stable version was made available in January 2007. I somehow don't see a high abundance of programmers with D skills, as by my definition, it is niche and not something I could happily choose to use to create the aforementioned projects I've done in C#.

    Eiffel is used in Academia and some domain specific areas, as alluded to above. I don't think I can use Eiffel to create n-tier, distributed applications like C#/VB can in .NET. I know it has influenced C#, and Spec# is the latest .NET incarnation with the design by contracts mantra, but it is still domain specific even though it was object oriented way back when. I have seen the Betrand Meyer video, with the Sleeping Barber Algorithm via MS research and Eric Meijer.

    I think the key issue here is that you have admitted to using these in research, and there is a wide array of people brainier than I am that design compliers, embedded systems and the like. I mean no offence, but sometime people don't live in the real-world, solving day to day, you would say "run-of-the-mill" business problems. It is when you deal with these problems, you see the difficulty of implementing technologies like D, Eiffel and even F#. That  the language semantics and implementations are superior, is beyond doubt - I agree entirely with you here. I like to write something that can be maintained easily. I don't see myself as being a code junkie eternally, so at some stage I must move on. The applications I've written must continue to be maintained and developed and C++ and C# developers will always be more abundant, than the domain specific languages you have mentioned at present. Things may change.

  • Bad programmers, anybody?

    leeappdalecom said:
    Maddus Mattus said:
    So nobody checked his work for 2 months put the app into production and let him leave?

    Actually this reminds me of;

    There is an interesting theory in software development that the quality of your software is limited to that of the second worst programmer on the team. Why the second worst and not the worst programmer?

    The theory goes something like this. Everybody in the team knows who the worst programmer is. They usually stand out like a sore thumb and so everyone is carefully watching his work. But because his work is so closely monitored it is also corrected before it impacts the code base. Sure, you end up losing time but you can mitigate the problem because you are aware of it.

    Now think about your own team and you will no problems deciding who the worst is. But who is the next worst? Who is the one that nobody is watching but is still checking in poor quality code? Their code spreads like a web throughout the project and so ultimately they limit the quality of the whole teams work. While you are carefully monitoring Mr. Dunce you are blissfully unaware of the time bombs being planted by his prodigy.

    So take a look around your office and decide who is wearing the dunce’s hat and then decide who the runner up is. If you come to conclusion that there is no weakest player in your outfit then I have bad news. In poker they have a saying “If you don’t know who the patsy is…” and I hope I don’t need to finish the quote for you.

    Original post.

  • Bad programmers, anybody?

    Maddus Mattus said:
    vesuvius said:
    what's wrong with goto?

    I really dont understand,..
    This guy SpectateSwamp (I'm chuckling just writing his name) produced the most unique threads I have seen hitherto here at Channel 9. He was a bit of a troll, and had a product called desktop search, which coupled with your example is an atrocious piece of coding.

    Those that remember him will laugh because he was dedicated to informing us windows search has inferior to the code he had produced.

  • Bad programmers, anybody?


  • Windows and Office will be written in native code forever

    wkempf said:
    I can't agree with several things in your premis.  First, managed languages aren't inherantly easier than unmanaged languages.  You'll have to talk specifics to make a claim like that (for instance, I won't argue that C# is easier than C++, but it's not really any easier than D or Eiffel).  Not all unmanaged languages require you to do memory management.  Heck, even in C/C++ there's garbage collectors you can use, and in C++ they actually plan on adding GC to the language spec.

    Linux ships new OSes every quarter, basically, and that's with most of the code written in C/C++.  Different model, yes, but the point is that the time frame of releases isn't all that relevant.  I work on commercial applications written mostly in C/C++ that ship new versions quarterly.  Not all users are "wait until I can't wait any longer" types.  In fact, I'd say the majority still aren't in this camp, though I'm guessing as much as you are.

    Midori and Singularity haven't proven anything, other than you can use managed code in interesting places.  Users aren't switching for many reasons, but none of them have anything to do with users not wanting to "upgrade".  It's more along the lines of costs vs. benefits analysis (the user's current investment in applications that won't run on Singularity, for instance, prevent them from doing more than checking it out).  Also note that these are research projects and not commercial offerings.  With out marketing, MOST users don't even know they have the option to switch, and haven't made the cost/benefit analysis.
    OK, my premise is this.

    I have a just grabbed a copy of Practical Visual C++ 6 from my bookshelf. Were I to use this to create the commercial applications I've written, I still would not have finished the first one. I am a qualified native C++ developer by the way, but self taught managed C#.  I find .NET much much easier, and not having to deal with pointers, stack overflows and buffer overruns for me at least, makes C# "a walk in the park", compared with native C++. The IDE is much cleaner, re-factoring and a standardised framework, makes it lovely to work with. I have the utmost respect for native developers and think they can be hoity-toity towards managed developers, because native coding is harder. Why to you think managed code has taken off the way it has - because it's just as hard as unmanaged?

    D and Eiffel would be easier to deal with if they had a rich IDE like VS and the resources put into it that the base class library has. Another flaw in your argument, is comparing domain specific languages with general purpose programming languages like C++ and C#. Designing programs by contract well in general is done by people with some experience of programming, Spec# being the latest offering from Microsoft. A quick look at D has things like tuples (funtional programming) and Eiffel has a lot of features that leave academics salivating. This is all well and good, but not as productive as a general purporse programming language like C#.NET.

    Everything about .NET is based around productivity. I know of no single ISV developers, that have completed n-tier, multi user applications, with a sproc data access layer, utilising web services. It is possible to do this with native C++, Eiffel or D, but it takes longer, and there is a wider scope for bugs. The trade off is performance, and having a bulky runtime beneath.

    For a business with 500 users, a quarterly upgrade as you suggest with Linux is expensive and impracticable, unless there is an overwhelming reason to do as such. Microsoft have just spent $300 million on marketing Vista, can you imagine them launching a new campaign every 13 weeks? You find that reasoning agreeable?

  • C# 4.0 and VB10. WOW

    evildictaitor said:
    vesuvius said:
    ** The brainiest of the brainiest love the language, and are raucous about its purity. 
    That's not a good reason for anything. Lots of clever people like COBOL. Doesn't mean it's any good.

    ** I somehow don't see distributed applications like Azure being built with C or Haskell.
    Why not?

    ** I guess the trade off is whether you can introduce 5 functional constructs in C# to handle concurrency for example, or say no, it must remain pure and simple , learn and use F# instead.
    Do you mean syntax constructs? You are no doubt aware that most of what can be done by adding syntax can be done by adding library features too, right?

    ** All code .. [including .NET] must have the notion of contracts associated with locks to deal with concurrency. 
    Locks don't solve concurrency. They are a way of avoiding it. Putting a lock in your code is essentailly saying "this bit of code must not be concurrent". True concurrency is achieved by writing programs that avoid locks wherever possible.
    The reason Haskell and C would be more difficult in Azure is that WCF is mostly .NET code and XML, and intrinsically builds upon .NET 2.0.. This is a rapidly developing area, and C or Haskell are not as likely to be changed and developed as WCF because that is the tool for the services.

    Obviously C will be present on the Win 2008 server and in the kernel and server side code, but for the flexibility that XML and .NET code give, I would head straight to WCF and not Haskell.

    With regard to adding the library features, as opposed to the syntax constructs, I'm not a language developer, but my head tells me to include functional programming in C#, my heart says learn F# and use a F# .dll to deal with any concurrency issues or mathematical programming. Money unfortunately determines a lot of decisions, and it is economically judicious to use functional constructs in C#, as opposed to learning a completely new language like F#. It's a Catch-22 situation really, where users will complain that C# is not flexible enough if these features are left out, or people will complain that purity and simplicity is lost if they are included.

    The use the right tools for the job argument is an opaque one now. Linq for example results in all your query code strewn over various libraries, and Linq projects are not the tidiest to work on, but some people love their object upon object. Stored procedures are super clean code wise, and your data access code resides on a server. People prefer both approaches, and I guess that's why you have a common language runtime that ends up as MSIL.