Microsoft declares its modeling love with a new language, 'D'

Microsoft declares its modeling love with a new language, 'D'

Summary: A handful of Microsoft's top developers are working to create a new programming language, code-named "D," which will be at the heart of the Microsoft's push toward more intuitive software modeling.


A handful of Microsoft's top developers are working to create a new programming language, code-named "D," which will be at the heart of the Microsoft's push toward more intuitive software modeling.

D is a key component of Microsoft's Oslo software-oriented architecture (SOA) technology and strategy. Microsoft outlined in vague terms its plans and goals for Oslo in late fall 2007, hinting that the company had a new modeling language in the works, but offering no details on what it was or when the final version would be delivered.

D will be a declarative language aimed at non-developers, and will be based on eXtensible Application Markup Language (XAML), sources, who asked not to be named, said.

Sources close to Microsoft confirmed the existence of D, which they described as a forthcoming "textual modeling language." In addition to D, sources said, Microsoft also is readying a comlementary editing tool, code-namd "Intellipad," that will allow developers to create content for the Oslo repository under development by Microsoft. (Intellipad is the "Emacs.Net" text editor for which Microsoft has seeking developers over the past couple of months.)

What, exactly is a "declarative" programming language? According to that old standby, Wikipedia, a program is "declarative," if it describes what something is like, as opposed to how to build it. To some, a declarative program needs to be written in a purely functional programming language. HTML Web pages are examples of declarative programs.

At last week's Lang.Net 2008 conference -- a meeting of programming gurus from Microsoft and other vendors held on the Redmond campus -- Microsoft's Chief Modeling Officer Don Box provided some more clues about where Microsoft is going on the tool and platform front with Oslo. Box said Microsoft wasn't interested in creating some grandiose 1980s' style computer-aided-software-engineering (CASE) tool; it was thinking more along the lines of providing a class designer. The goal, according to Box: "putting more and more of your application into data and putting less in code."

The Windows Communications Framework (WCF) team, of which Box has been a part since WCF was codenamed "Indigo," is just one of a number of divisions at Microsoft interested in "moving the line" between data and code more towards data

With Oslo, Microsoft is endeavoring to "deliver a world class and mainstream modeling platform that helps the roles of IT collaborate and enables better integration between IT and the business," according to the company's Web site. Next-generation versions of a number of Microsoft products -- BizTalk Server V6, System Center V5, Visual Studio V10, BizTalk Services V1 and .NET Framework V4 -- for which there are no ship targets available from Microsoft, are all part of the Oslo vision.

If I were a betting woman, I'd say we'll likely see a technology preview of D by the time the Microsoft Professional Developers Conference (PDC) hits in late October. I'm doubtful Microsoft will say more about D, but I've got a query into the company about it.

Topics: Enterprise Software, Microsoft


Mary Jo has covered the tech industry for 30 years for a variety of publications and Web sites, and is a frequent guest on radio, TV and podcasts, speaking about all things Microsoft-related. She is the author of Microsoft 2.0: How Microsoft plans to stay relevant in the post-Gates era (John Wiley & Sons, 2008).

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Just what the world needs...

    ...yet another programming language. As soon as you say it's aimed
    at non-developers, "real" developers will avoid it like the plague. And
    without "real" developer support, it's dead in the water.

    Just look at javascript - a great little language that has expressive
    power that is far beyond that in other much larger languages. But
    because it was aimed at non-programmers, it's considered a "toy"
    that's not fit for real developers.

    Tell that to Google, or Yahoo, or even Microsoft.
    Fred Fredrickson
    • Bias of 'real' developers

      In my experience, real developers don't ever see the forest for the trees. Almost without fail, I've had the virtues of C, C++, and Java quoted to me as though it was the pinnacle of computing achievement.

      Yet when there are bugs, or failures.... it's always because a virtual machine had a flaw, or there was a buffer overflow, or a pointer error.

      Maybe it's time to borrow ideas from 'non developer' languages.
      • or maybe

        Or maybe its time to start using a managed language, professional IDE, and the .NET Framework to solve all the problems you mentioned above and many more! VB.NET or C# offer much better options than yesterday's languages.
        • Bugs

          No matter what "human" developers create to make development easier, there will always be bugs. Avoding bugs caused by bad development practices isn't a good reason to go to a higher level language, you must hire competent developers to begin with (no matter the language you use)

          Having a runtime, framework, or interpreted language int the front end development is easier but there can and will be bugs under it all.

          The advantage of using lower level languages is the developer is closer to the problem when it happens, so it's much easier to find.

          Nothing is more frustrating than to try and figure out why your app is crashing to only debug it to the goo that shims in the runtime, without sources and symbols for the runtime you are pretty much SOL unless you understand assembly really well. (and if you are only hiring high level programmers, assembly knowledge these days is pretty doubtful)
          • More productivity

            Of course there will always be bugs in software regardless of the development platform or operating environment you are targetting. The real advantage of a managed environment is that you don't have to worry about memory management, garbage collection, and writing low level functionality from the ground up. You are going to be much more likely to find stability in Microsoft's .NET classes than writing the same functionality yourself in a lower level language. Productivity is where the .NET framework really makes is biggest impact, and since productivity drives profits, it really is the best choice available at the moment.

            I've been developing .NET applications for 5+ years now and would never even consider going back to an unmanaged environment.
          • .NET

            offers me no productivity as no platform that is in my organization runs Windows.

            C# and .NET are for developing instances of MS class libraries which are useless without the Windows API to support them.

            Luckily I have never had to experience your result of programming over 5 years in .NET.

            I am glad, however that MS is developing a new tool for script kiddies to wreak havoc on the Windows hegemony.
          • Doesn't run Windows?

            Your organization doesn't run Windows? Are they a bunch of zealots or just really don't have a clue?
          • (NT)

          • Doesn't need or run Windows

            Exactly. What clue would you suggest?

            I used to use Windows, then I got a clue. I could do everything I needed without Windows and its expense and up keep.

            Sorry, but the computing world does not revolve around Windows, except for a few like you maybe.

            Get a clue...
          • The Mono Project

            sounds like a great idea sponsored by Microsoft to push .NET client, and eventually server, side capabilities into the other OSes.

            Thanks but no thanks. The mere fact that it exists does not create a compelling case for its use, does it?
          • "sounds like a great idea sponsored by Microsoft..."

            Yeah, except that it's not.
            Did you actually VISIT the web site linked?
            No, you didn't.
            If you had, you'd know that Mono was started by Ximian,
            and is now sponsored by Novell. Microsoft has no
          • Topical

            I wasn't even addressing the advantages of a managed envionment vs unmanaged when it comes to productivity

            I agree, .Net makes things much easier and speeds up development time, however my comment was about debugging in general.

            Higher level langs make debugging more difficult, they do however make development easier.

            BTW: You can have memory leaks in managed code.
          • Worse yet

            you can run out of memory due to a sluggish garbage collector. If you run .Net apps in a Citrix environment, the typical settings for the garbage collector will cause memory problems. Even setting objects to null works sporadically. I like it better when I can control when objects are released from memory rather than relying on a managed environment to do it for me.
        • There is no unique language

          Choice on language is made based on capabilities compared to requirements.

          You will not choos the same language for a standalone client side software, for server side infrastructure, for grid targeted computation or for AI.

          As hardware capability grows and as the software market matures, needs broaden which in turn leads to oportunity for more different languages.

          Interpreted languages is one possible answer for one, or a few categories of software.
        • Yep. .NET means no bugs.

          At least that is what some will try to convince you. Having done a few programs using
          it, I can say it did not make anything any easier or help produce any less bugs than a
          non-managed environment.
          • You lack sufficient experience

            A few programs? That isn't exactly an impressive amount of experience when you are trying to make such definitive statements as .NET doesn't make things easier for developers or reduce debugging requirements. Just by the very nature of the beast .NET makes things more straightforward because it manages memory for you, thus you inherently encounter far fewer memory leaks (the most common unresolved problem in software developed in unmanaged C++ today), and since preexisting components and already available and have been debugged, it only makes logical sense that this simplifies things when compared to building every component from scratch.

            Things have gotten to the point now where any project of significant size in C++ requires a sizable team of professional developers, which many start-up companies cannot easily afford. I have created applications in .NET with a small team (two developers and two graphic artists) in around 21,000 lines of source code. The same project would have taken a team three times the size, cost hundreds, maybe a million dollars, and required three to four times as many lines of source code had it been developed in unmanaged C++. And guess what? We probably ended up with at least as good, if not better, results than the C++ team could have.

            You won't learn .NET overnight because it is radically different from unmanaged win32 programming, so if that is how you evaluated .NET, you really cheated yourself.
          • You oversimply

            and attribute to memory management the benefits of available libraries.

            When you talk about all these festures rpesent in .NET and you would have to rebuild from scratch in C++, you attribute the merits of the libraries to the language. You can find libraries of components for C++ also ( you can even use .NET if you wish ).

            As for managed source code reducing memory leaks, from my experience in other languages using memory managemelnt features, the constructs hide the details from you but do not change the underlying truth : if you make no effor to clean things behind you, the system will not do it for you, and you can have mempory leaks also on managed code if you do not put into place practice that insure the memory management infrastruction can do its job properly.
          • Not really.

            If I don't see gains on the FIRST program, the API is:

            1) Too poorly laid out.

            2) Too complex.

            3) Still has too many design defects.

            And I simply write it off. I have had to use .NET 3 times now and I am under-
            whelmed. I found .NET to be a bit lacking even compared to the capabilities
            offered by NeXT/Sun with OpenStep. It is a huge step forward from MFC but most
            things are.

            The truth is, memory management is not all that hard if you set up a few simple
            rules. NULL pointers, life time, memory leaks and other memory issues have rarely
            taken up more than a few % of my development/debug time and if that is the only
            true gain .NET offers, it is very small indeed.
      • Not Invented Here

        [i]Maybe it's time to borrow ideas from 'non developer' languages.[/i]

        What, like BASIC or Smalltalk?
        Yagotta B. Kidding
        • Smalltalk was pioneer of today's OOP languages

          Smalltalk, developed in 1971 at Xerox PARC, introduced objects, message passing, reflection, just-in-time compilation, windowing environment. One of Smalltalks developers, Alan Kay, went on the Apple and brought many of Smalltalk's ideas with him. In fact, in 1979, Steve Jobs toured Xerox, saw Xerox's Smalltalk-based windows Plato system, and was inspired to create the Macintosh predecessor, the Lisa. People always accuse Microsoft of copying, but Apple borrowed many early ideas, too.