Entries:
Comments:
Discussions:

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

Discussions

William Kempf wkempf
  • Google gets the better of Microsoft

    Chinmay007 wrote:
    
    I'm 100% correct but spreading FUD at the same time. It's sad when the truth causes fear, uncertainty, and doubt.


    Politicians are great at this (you are not).  Take part of the "truth" out of context, and you'll be technically 100% correct, but you'll be lying through your teeth none-the-less.  Going back to context, you know perfectly well what I was saying you were doing to spread FUD.  You are purposely giving the impression that there's no way OOXML will be accepted as a standard (you probably even believe this to be likely, but you know it's not a certainty), but the only "truth" in what you said is that it won't be accepted AS IT IS NOW.  That's obvious, since the voting is over.  But that doesn't mean it's simply locked out for ever.  With the requested modifications and clarification it well may be accepted later on.  You have no idea if that will happen or not, you're just spreading FUD because you don't want it to happen.

    Of course, you know that, so all I'm doing is feeding the troll.  Sorry, won't happen again.

  • Google gets the better of Microsoft

    Chinmay007 wrote:
    
    Fact of the matter is, OOXML is NOT an ISO standard, and OOXML in it's current form WILL NEVER be an ISO standard

    OpenDocument is.

    So while you might whine that you can't implement a spreadsheet without leaving ISO, you can't implement pretty much anything in Microsoft's format without leaving ISO.


    Nice to know you can predict the future.  Oh, wait, you said "in it's current form".  So you are 100% correct, but are making a pointless statement in order to spread FUD.  Let's leave politics out of this, please.

  • C# over JVM, or Java over CLR/CLI

    punkouter wrote:
    

    Yes, I know, but J# have lots of enhancements (Microsoft Enhancements) that is not in the Java Spec. The idea that I'm asking here is to compile the Java language itself (Java 5) to CLR/CLI. Given that both of them are targeting VM and have similar facilities it might be possible to do this. If it can be done, then maybe you can write C# applications with Java libraries. Isn't that cool? (or am i being fetish?)



    There are already a very large number of Java libraries ported to .NET by using J#, so I don't understand why you dismissed that response.  There's few extensions in J#, and extensions don't change the fact that the rest of Java still exists.

    That said, most Java libraries ported this way are suboptimal solutions.  The APIs feel "foreign" because of Java's lack of .NET features such as delegates and properties.

  • And now... LINQ for Ruby

    TimP wrote:
    

    I'm not quite sure what you're trying to get at. C# and .NET weren't made in a clean room; they borrowed stuff from Java and other languages/frameworks, too.



    I think you're misinterpreting this as an attack on other languages.  I actually really like Ruby, and the last thing I'd be doing is attacking it.  I'm not putting any other languages down, I'm giving the C# designers credit where credit is due, for an exciting new technology.

    When LINQ was first discussed by Microsoft, many, MANY, developers questioned (or worse) the idea.  So it's worth noting that now we have several languages with LINQ like technologies.

    1.  JavaScript
    2.  Java
    3.  Ruby
    4.  .NET

    I expect other implementations to follow.  So, even though LINQ isn't officialy released yet, I'd say it's already an overwhelming success.

  • And now... LINQ for Ruby

    Seems Microsoft has certainly started something Wink.

    http://errtheblog.com/post/11998

  • LINQ for Java - This time for real

    It's called Quaere (no idea what the name means), and it looks to be extremely similar in design to LINQ.  However, it doesn't have the built in language syntactic sugar.  What I find funny, is a response to this blog post suggests there's a "similar" library here: http://josql.sourceforge.net/.  Yeah, that's similar all right.  It parses strings, so doesn't have any of the type safety or intellisense support.  So, once again, there are way too many developers out there who don't "get" LINQ.

  • Should Microsoft develop 'full cross-​platform support' or not?

    evildictaitor wrote:
    
    wkempf wrote:
    
    OK, now that I've shown how badly you've done at trying to make me out to be an idiot, care to either drop this entirely, or get your facts straight and stop trying to attack the technical aspects of what I said (which wasn't the point of what I said, and you've proven yourself not competent to argue any way) and address the actual topic?


    Since you have decided to move this conversation to a personal attack rather than keeping this conversation as a reasoned discussion, I won't dignify your post with a response, save to say that it is clear you have not read the link you posted on ECMA 335 - CIL, which lists no parts of the .NET framework except those used by the underlying CIL model itself (collectively, the Runtime, System.XML and System dlls). ECMA 334 which lists the C# model is also suitably void of .NET framework components, and as such, your response of suggesting that CIL/C# were incomplete because of a lack of ported GUI functionality is simply wrong, and I suggest we leave it at that.


    Sorry, bad day, and I took your post as a personal attack and responded in kind.  With a more level head I can see that you didn't mean it that way, though I still take offense at the assumption I didn't know several of the things you claimed I was ignorant of, when they were mentioned in my initial posts.

    In any event, I have read the standard.  It does include the BCL.  You're twisting things here by dismissing the BCL as only the System.XML and System dlls.  That's a HUGE set of classes, and is pretty much everything except the things I've suggested should be part of the BCL.  And you can't dismiss my claims by saying I'm "simply wrong".  That's not a reasoned argument, and I've already explained why this *perception* exists, and that isn't "simply wrong".

  • Should Microsoft develop 'full cross-​platform support' or not?

    n4cer wrote:
    I have  nothing against a GUI or other functionality being added to the standard, however I've seen multiple people suggest since the CLI was released that the CLI wasn't truly cross-platform or that it wasn't a real or full standard simply because MS didn't include technologies they built atop the standard. My argument is that this should not be expected because it has not usually been done before. Treating the CLI differently is to use a double-standard. But for Java and Tkl (neither ISO standards to my knowledge), language standards don't generally include GUI libraries. It may expand the requirements for a conforming implementation, libraries are usually an area of vendor competition, and in the case of the MS components usually discussed, are platform components (WinFX) or  other solutions that drive platform adoption (ASP.NET). I include ASP.NET because portions of the *x crowd normally mention it along with pretty much everything else. A standard's great, but there also needs to be room for the vendor to go beyond it and differentiate.


    1.  We're in agreement about it being a standard, from a technical stand point.  You (and others) miscontrued what I meant (because I worded it very poorly) in this regard.
    2.  The reality is that people don't believe it's a standard in anything but name, for lots of political reasons, including the perception that Microsoft is "holding back" what they believe to be crucial parts of the .NET platform.
    3.  No, Java is not standardized.  That was another point I made.  Microsoft did the right thing here, I just want to see them go "the full way" with the effort.  And again, this isn't a technical issue, it's a political/marketing issue.
    4.  I agree with giving the vendor room to compete, but a language can't ignore a standard library either.  Currently the standard includes a BCL that encompasses most of the functionality included by more traditional languages.  But, politically, like it or not, the bar has been raised with regards to what people expect from a language's "standard" library these days.

    Now, from a personal stand point, I don't agree with the political aspects of dismissing C# as a standard.  In this regard, I agree with the Mono folks.  The current standard provides a very nice, cross platform, language.  There's lots you can do with it, and it has advantages over other choices.  However, I still believe, and not only to placate those playing politics here, that many of the APIs available from Microsoft should be standardized, including WPF, WF, WCF, et. al.  I see doing so as a win for everyone.

  • Should Microsoft develop 'full cross-​platform support' or not?

    evildictaitor wrote:
    
    wkempf wrote:
    
    The current problem with the standard is that it's not complete (missing necessary components, such as a GUI library, that Microsoft includes in their proprietary version but didn't include in the standard).


    You are confusing issues here. C# is the text that you type into Visual Studio, but could be written in notepad. This is formalized in the ECMA standard. CIL is the format that the program is stored in once you have compiled. This is fixed except for changes between CIL1.0 and CIL2.0. The .NET libraries are every function you use that you didn't write or buy.

    C#, CIL and the mechanism of turning C#->CIL->Machine code is all fixed and can be used on any operating system. The .NET libraries arn't.

    From what I understand of your comment you are suggesting that C# is incomplete without System.Windows.Forms, but System.Windows.Forms is part of the .NET library, and is nothing to do with the completeness of C# or CIL - you can program in C# and compile to CIL (or, indeed compile to Java Bytecode or x86 pure etc.) without the .NET framework.


    You need to step down from the soap box, because you're simply wrong.  The standard (http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-335.pdf) includes the BCL (see Partition 4).  I've spoken loosely, and thus used some terms incorrectly, but I'm hardly ignorant of the technical aspects here.

    evildictaitor wrote:


    wkempf wrote:

    What I am calling for is community participation NOW.  If Microsoft isn't going to provide implementations on all platforms, this is ESSENTIAL in order to ensure the standard actually can be implemented on all platforms in an efficient manner.  This doesn't mean willy nilly community contributions, like in many OpenSource projects.  I'm envisioning something more along the lines of other ISO standards, such as C++, where vendors of various implementations and other interested parties participate in a standards committee.  With out this, it's a little hard to consider .NET a full "cross platform standard".


    Microsoft employs and contracted a substantial number of computer language researchers when they were writing the specifications for C#. The specifications for CIL were (sadly, in my opinion) almost lifted from the x86 architecture but made register-independant. This means that CIL will be trivial to compile under x86,x64,PPC,ARM architectures etc, and can be relatively operating system independant.

    The .NET framework is more difficult to push onto other operating systems (although other architectures, thus platform independancy is easier) and basically involves rewriting significant sections of the .NET library but keeping the interface. This is what Mono is currently doing.


    Again, part of the standard includes the BCL.

    evildictaitor wrote:


    wkempf wrote:

    Oh jeez.  No one asked C# to become more like Java, least of all myself.  I can go on for days about the problems with Java, most of which have never existed in C#.  All I was doing was making a comparison between the processes used by the two.  Java chose to remain proprietary, but provided implementations on practically all platforms.  Microsoft standardized, but only provided a (supported) implementation for Windows.  I think that Microsoft's approach is better, but it will only work if an effort is made to truly make it a "full standard" by taking the steps I outlined.  Otherwise, despite technically being a standard, it will forever be viewed as a proprietary language/platform available basically only on Windows.  IOW, you have to fix the perception before the technical reality will be accepted.


    No. Microsoft's C#/CIL is operating system independant and has been for over a year. The .NET framework isn't. You have been able to write applications for Linux and Mac in C# for quite some time now under the Mono Project. The only team currently involved in providing .NET functionality under other operating systems is Novell, which is supported by Microsoft in it's endeavour.


    1.  It's been much more than a year.
    2.  The BCL *IS* platform independant.
    3.  I'm fully aware of Mono, and from the sounds of this post, probably more so than you.
    4.  As I already stated, Mono isn't the only implementation.  There's also Rotor and DotGnu.
    5.  Microsoft is supporting Moonlight (and eventually the Mono's CoreCLR), not Mono in general (meaning not in "providing .NET functionality").

    OK, now that I've shown how badly you've done at trying to make me out to be an idiot, care to either drop this entirely, or get your facts straight and stop trying to attack the technical aspects of what I said (which wasn't the point of what I said, and you've proven yourself not competent to argue any way) and address the actual topic?

  • Should Microsoft develop 'full cross-​platform support' or not?

    n4cer wrote:
    
    wkempf wrote:
      I'm envisioning something more along the lines of other ISO standards, such as C++, where vendors of various implementations and other interested parties participate in a standards committee.  With out this, it's a little hard to consider .NET a full "cross platform standard".


    C#/CLI has this. Any interested party can contribute to ECMA/ISO and drive the standard forward. C#/CLI is just like C++ and its standard libraries. There's an important difference between the CLI and CLR/.NET that is often missed when the terms are interchanged while talking about the standard. CLR/.NET is Microsoft's implementation of the standard plus value-added libraries. It's Microsoft's choice whether to license these libraries for use on other platforms, but the CLI is a full cross-platform standard in any case.


    I'm obviously not explaining myself well.  This is a perceptions problem, not a technical one.  The fact that there is a standard, and that people can contribute to it, isn't the point.  The point is that this hasn't been encouraged, and so the perception is that this hand waving only.

    n4cer wrote:


    wkempf wrote:
      Oh jeez.  No one asked C# to become more like Java, least of all myself.  I can go on for days about the problems with Java, most of which have never existed in C#.  All I was doing was making a comparison between the processes used by the two.  Java chose to remain proprietary, but provided implementations on practically all platforms.  Microsoft standardized, but only provided a (supported) implementation for Windows.  I think that Microsoft's approach is better, but it will only work if an effort is made to truly make it a "full standard" by taking the steps I outlined.  Otherwise, despite technically being a standard, it will forever be viewed as a proprietary language/platform available basically only on Windows.  IOW, you have to fix the perception before the technical reality will be accepted.


    If a standard GUI or other library is desired, a request should be submitted for consideration to the standards bodies, but the lack thereof does not make CLI less than a "full standard" anymore than it does C++. WinForms, WPF, WCF, et al., are analogous to Win32. Just because it's written in the same laguage defined by the standard doesn't mean it should be part of the standard. There are cross-platform libraries in both cases that fill the gap where platform-independent code is needed. If such functionality is to be included in the standard, it can be requested and voted on, and doesn't have to come from MS. As far as I'm aware, C#/CLI is the norm rather than the exception when it comes to what's included in a language standard.


    It gives the perception that it's less than a "full standard" (there's reasons I'm using quotes here).  C++ doesn't suffer here, because it's a "traditional" compiled language.  Java changed the perception of what's to be expected when the language runs on a VM (and yes, I do understand the subtle differences between the JVM and the CLI... oh, and I was sloppy using CLR instead of CLI).

    There is no way to construe WPF, WCF, et. al. to being analogous to Win32.  WinForms, yes, the others, no.  There's nothing about these libraries that make them platform specific, much less related to Win32.  I really don't give a rats rear what library is submitted or who submits it, only that one be included and Microsoft includes it in their implementation.  However, since we're talking specifically about what Microsoft can do to alter the perception here, I stated that THEY could include a GUI library, and that I thought WPF would be a great candidate.

    <frustrated rant>
    I realize I'm not doing a good job of communicating here, but the fact that I make simple statements about their being a standard should cause all of you attacking me on that front to take pause and consider what the rest of what I said means.  Jumping to the conclusion that I think there's no standard is insane, since I stated there was one.
    </frustrated rant>