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
  • 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.

  • Windows and Office will be written in native code forever

    I'm sure you're all aware of the complexities involved in writing and shipping native code. It in general is much harder than managed code, principally because computer memory must be managed by the developer, but the language itself is very difficult as well.

    Microsoft Windows and Microsoft Office are released every 3 -5 years, and this is no guarantee that business or users will upgrade their previous version (as Vista and Office 2007 prove). It now is more of a case where "I'll use my current machine" until that is "on-its-last-legs", then buy a new one with a new OS or Office license. This inherently means that the rapid development that managed code offers, is not necessarily an advantage for these products. If you could ship a new OS every 2 years would you?

    There have been exciting things like Midori or the Singularity project recently, but they failed to recognise the fact that business and users aren't and won't upgrade willy-nilly, so the turnaround for application development is neither here-nor-there. The other overwhelming aspect is cost. It takes many more developers to develop native code applications (much more), but if you have something like office, you can reduce the staff - look, I know its still a huge engineering project- and release the product every 4 or 5 years.

    This is in complete contrast to line of business application and website development, where you want to complete the product at the soonest available opportunity. Having the .NET framework seems a worthwhile trade off for the rapid and bug freer software you get.

    Would you say that this is a fair assessment, or is my reasoning misjudged?

  • C# 4.0 and VB10. WOW

    W3bbo said:
    littleguru said:
    I'm refering to modular DTDs, which work well when they're properly implemented; I'm not refering to XML schemas.

    This isn't a technical issue, it's theoretical. The W3C did it with XHTML (see "XHTML Basic") and CSS (now split up into different modules rather than a single monolithic spec).
    I think this simplicity thing is more a dream, than a reality. Yes you can look favourably at less complex languages, but as a given, they do less complex things.

    The Utopia of a pure and simple language has been achieved by Haskell. The brainiest of the brainiest love the language, and are raucous about its purity. I somehow don't see distributed applications like Azure being built with C or Haskell.

    MSIL, .NET, C# and VB must increase in abstraction, in order to facilitate the raised complexities they need to solve. Language guys like Anders all sit in on the Base Class Library, and know what types of problem are trying to be solved with Microsoft's vision, so that must be a factor in the evolution of the language.

    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.

    All code, be it C++ (now with lambdas) or .NET must have the notion of contracts associated with locks to deal with concurrency. I just don't think you can say the halcyon C days were better than now. There are harder problems to solve now.

  • C# 4.0 and VB10. WOW

    martofsky said:
    Minh said:
    I'm trying to remain muted instead of getting excited like I did about previous features.  I'm sure that to get these features, you'll need the DLR which will ship as part of .NET 4 which will include Oslo and all the other cruft that MS has added to .NET that I don't need, necessitating a 400MB (or worse) runtime...

    Thanks, but no thanks.
    I really wish the Client Profile was a true "client profile", and stayed as such. All the Server stuff would then be installed in Windows Server 2008 Version 2.0, in effect creaqting a two-tier .NET framework.

    Surely you don't want Oslo/M and WCF, WF, Azure and all that stuff installed on Client Machines when it will never be used? Space is not an issue nowadays, but developers are still very pedantic about not having anything they don't need installed on a machine.

    We need Windows 7 with .NET 4.0 Client Profile (that is never upgraded via Windows Update), and .NET 4.0 Developer Profile, as they are the only people that'd ever use it fully.

  • Long Zheng's UI task force is back

    I little while ago Long started a UI task force. It's main aim, was to highlight the graphical inconsistencies between dialogues in Vista and ostensible relics from 10 to 15 years ago still rife in the operating system.

    From what I've thus seen, there have been welcome improvements to utilities I still use daily, like notepad and calculator. What of the dialogues with Win 2000, XP and Vista icons all in one? Has there been an improvement here, or will the OSX lovers still be laughing and the jumbled-up mish-mash of icons, text and dialogues?

    While we are at it, PDC has left me felling like a kid in a candy store/sweet chop, and told I cannot eat any sweets because they are bad for my teeth. When will we get to try out the 7 beta?

  • Is WinForms dead already?

    Sabot asked me this question a while ago. I return to is because it is an excellent question. What drives development in your organisation, business need or technology?

    As I've written before, my present client couldn't care less what the program is written in. As long at it solves their business need, and I can bring it in under budget. WPF is way too expensive at present , and until the toolkit can match http://silverlight.net/samples/sl2/silverlightcontrols/run/default.html and http://timheuer.com/blog/archive/2008/10/28/silverlight-toolkit-released-with-charting-databinding.aspx, coupled with the speed of the Windows forms design time environment, then it is not a one size fits all framework.

    It's one thing talking about WPF being the future UI for the Windows platform, but exactly how much of Windows 7 is WPF?

    Far more important to me is the business logic and services, that I can choose to bind to Silverlight or WPF or ASP.NET at a later date. It's just a question of Architect-ing your applications smartly.

    Microsoft have promised to maintain updates to Windows forms, but there are quite a few controls with bugs that have not been fixed since VS 2005, and it will be 5 years when VS 2010 is released. I think they do need to revisit some of these controls,and tidy them up a bit. They also need to open up Windows 7 API's via managed wrappers to promote the platform (a big mistake in Vista)

    I also think the best WPF UI designers will come from a winforms background, because getting a UI right is actually quite hard, and you end up with the Yahoo messenger problem where it looks good, but the usability is poor.

  • Is WinForms dead already?

    I have written my thoughts on this here and here. No this is not self promotion, but I've written about it at length, and am not about to regurgitate stuff.