Sunday, November 17, 2002

My good friend John Burkhardt has some good push-back on Joel's latest well-done essay: The Law of Leaky Abstractions.  "While I agree with a lot of it, I'm not sure I buy the idea that because an abstraction might have a performance penalty in some cases, its a leaky abstraction.  And there certainly are some that seem well cemented by now.  For example, how much .asm have you written in the past 5 years?   And I don't know anyone who can hand code floating point Pentium assembler better than the compiler.  We tried to be sure, but couldn't do any better.. And I hear VS C++ is about to get even better." 11:20:19 AM

	Friday, November 15, 2002

My work lately led me quite naturally to the seminal book, Generative Programming: Methods, Tools, and Applications. I read most of the book yesterday in one sitting (yikes!) and although I found much of it tough going, I want to share one key insight I got. I have always had a lot of trouble understanding the Smalltalk argument as put forth on places like Wiki when I used to be there and indeed the real  advantage of late binding languages. I always viewed the safety of static type checking as a given. Well, in Chapter 6 on Generic Programming, in the area of Overloading and Parametric versus Subtype Polymorphism, is the example that lays it bare before my eyes and makes me see it. Consider writing a function for squaring a number. In pseudo-code, it looks like: sqr(x) return x * x In a dynamically typed language, such as Smalltalk, this pseudo-code code can be typed in almost "as- is": sqr: x ^x * x However, if we want to implement it in a statically typed language; we have to declare the type of x and the return type, for example in C++: int sqr(int x) { return x * x; } This only works for int types; it is more "special" than the pseudo-code or Smalltak, which understands the message "*", or for any type including the operation "*." In C++, you could have a whole series of squaring functions for different types, but you would eventually come to the solution: a function template: template <class T> T sqr(T x) { return x * x;}   Of course, the compiler will automatically generate a concrete function for each parameter type. The interesting thing to note that the sqr() template will work, not only for number types, but for any type providing the operation "*", just as the Smalltalk implementation of sqr().  However, there a difference between these implementations and here's my revelation: The sqr() template is statically type-checked and no run-time errors of the type "operation * are not found" are possible, whereas the Smalltalk version is dynamically type-checked and a runtime error is possible (no suprise there; thats been my main objection to dynamic languages in general). But, on the other hand, the Smalltalk version if more flexible of x is not fixed at compile-time and objects of different types can be passed to sqr:. Wow, thats pretty more powerful and certainly leads to the rapid Refactoring that they have always talked about. This example is also a good one of just taking the proble semantics and "just typing it in."   9:28:31 AM

	Thursday, November 14, 2002

John Giudice has started a weblog.  John is another Product Manager here at Groove.  He is in charge of the Groove Developer Kit and its various tools and utilities.  John says: Over the coming days I will try and share ideas on what is involved with creating collaborative applications and making them succesful [Matt Pope's Radio Weblog] Cool! I worked with John a lot on the Toolkit. One of the very cool things that I always loved about John is he is one of the very few Product Managers I have ever seen anywhere that gets as dirty in the code as he does. He codes at home too. Cool! 6:32:44 PM

new look. A fresh new look for Groove's homepage [Jeroen Bekkers' Groove Weblog] And a new message-) 1:33:07 PM

Writing Secure Code This book provided a few new insights, but nothing earth-shattering.  It's a good read for newer programmers, but [good] seasoned programmers will have already run into a lot of the described issues and learned from their mistakes. [Paresh Suthar's Radio Weblog] I agree that its quite basic. However, judging from the amount of buffer overruns that are seen in everyday C/C++ code, and the fact that Buffer Overrun checks had to be put into Everett C++, I don't at all agree that many programmers are writing C/C++ write code that doesn't have these problems (or even aware). Heck, to some extent Java and C#/.NET exist for large reasons because of the failure of C/C++ programmers to write good safe code. 9:30:16 AM

	Wednesday, November 13, 2002

Microsoft launches corporate IM. Just days after AOL announced its corporate instant messenger solution, Microsoft has announced it will jump in the market and release its own corporate IM system sometime in the first quarter of 2003.... [Lockergnome's Bits and Bytes] 1:52:46 PM

Microsoft's and collaboration. Forbes : CEO Network Chat with Microsoft VP Jim Allchin yves: Will .NET servers bring collaborative work functionalities going forward? What`s MS postion with regard Groove Networks? JALLCHIN: Basic file serving is moving to project/team serving. STS 2.0, which is part of Windows server, will be a huge step forward for collab. In terms of RTC, we are building an RTC Service which will also run on Windows .NET Server. We are in production (with beta code) at one large customer now. Then there is how Office will evolve to encompass more of this RTC functionality. Groove is a great app. The way to think about it is that we will build a rich RTC platform (meaning APIs!) that others like Groove/Office/others can build on. [Jeroen Bekkers' Groove Weblog] 10:06:57 AM

	Monday, November 11, 2002

I have just been given a go-ahead (Visual C++.NET only so I won't talk about the rest) since a lot of this has gone public already. The Everett Visual C++.NET features, I feel, are the biggest changes to VC++ since 5.0 and have made me extremely happy. The features break into 4 main areas: ANSI/ISO Compliance Forms Designer for Managed C++ Security Features Optimizer Improvements particuarly in floating point The ANSI/ISO compliance is particularly exciting as Visual C++ finally does Partial Template Specialization, Partial Ordering, Member Template Definitions, and pretty much everything in the standard. Public statements have said 98% compliant. I have not been able to throw any Standard C++ at it that it couldn't compile and handle correctly yet. Very heavy users of advanced Standard C++ features, particuarly templates like Loki, Boost and Blitz now compile 100%! Also, in the unmanaged arena, there have been significant additions for security, paticuarly in the area of buffer overruns. The new /GS flag, when code is recompiled with 71, will catch many buffer overruns. There are also Safe Exceptions which I won't go into here. Also, in the unmanaged area, there have been some outstanding improvements made in the optimizer, particuarly for floating point. The /G7 flag builds code optimized for the P4 and there are major gains. Also the new /arch:[SSE:SSE2] flags let you generate code for the Streaming SIMD and Streaming SIMD Extensions 2 instructions. Last, but certainly not least, there is now a Form Designer for Managed C++! You will be able to do everything you do with the C# or VB designer. You can visually design forms and work with Managed C++. This obviously opens powerful opportunities to do certain things like Direct/X without Interop penalities and much more. Its very exciting! 3:45:10 PM

The warmth and depth of this community never ceases to amaze me. I was just talking to Tomas down in Columbia, who has posted a very thoughtful reply to my essay), and Ingo at .NET One, (at the same time!) who are both encouraging me to go out on the circuit and speak on COM Interop. Since they asked, and Radio seems to have lost the pointers, here is the Is COM Interop Fundamentlaly Flawed (Parts 1 and 2) story which Radio has once again lost the links to, from last August. There is actually more detail in my slides on my web site. I will be updating this after talking to Don about it and with new insights but for now, Paresh, who worked heavily with me on this area during that period, has an excellent article on what we found in Connection Points in particular and how to write wrappers to fix some of the mess. 10:59:26 AM

	Sunday, November 10, 2002

I want to step away from coding, talking about .NET altogether, and talk about abstraction, domain engineering, generic programming, and design paradigms for a bit. In 1999, I read a book by Jim Coplien, “Multi-Paradigm Design for C++”, which forever changed the way I looked at design paradigms. Lately, while reading Andrei Alexandrescu’s “Modern C++ Design: Generic Programming and Design Patterns Applied”, combined with doing a lot of “Modern C++”, I had several awakenings those shook up things for me even more.             For years now, it seems to me, we have had many design “gurus” repeating a mantra “Object Oriented Design good, all other techniques  bad”, to the extent that for many developers and designers, that is the only paradigm that they use and even know. Abstraction is one of the key tools for managing the ever-increasing complexity of modern software. As Coplien says, “The common answer to what is abstraction usually has something to do with objects, thereby reflecting the large body of literature and tools that have emerged over the past decade to support object-oriented techniques.” Even more so, frameworks, languages and abstractions like .NET’s BCL and most of Java is only OO based (yes, I had been thinking about this for 2 weeks now, before Microsoft’s vapor announcement of future generic programming features in .NET). Java is touted, rightly or wrongly, as completely OO such that everything must be in a class. NET’s BCL is mostly only OO. Both of these, for the most part, wrap your abstraction and your way of thinking in object-oriented ways. Yes, there are exceptions (no pun intended!), but for the most part, most of the world thinks in objects. Well, that’s goodness, right? After all, it models the real world and builds abstractions much better, right? Well, yes and no. There’s no denying the vast benefits of OO but the key message in these books, and particularly Coplien’s book, is that Object Oriented Design is just one subset of the solution domain and not always appropriate for the problem at hand.  {READ MORE...} 3:03:16 AM

	Tuesday, November 05, 2002

Groove case study. Groove and Glaxo case study : Surmounting Corporate Boundaries The ability to share information so quickly produced an "immediate benefit" and noticeable productivity boost from teams using Groove. [Jeroen Bekkers' Groove Weblog] 8:19:16 AM