Microsoft Emacs.Net

A recent post at meta-doublasp hints at something Microsoft may have in the works: Emacs.Net. For many UNIX and Linux folks, emacs is probably old hat. Otherwise, here’s a quick overview.

Emacs is a popular UNIX text editor, often used to write software, configure systems and edit just about anything. Emacs is mainly used by technical folks, and is pretty easy to configure, extend and tweak if you are inclined. I haven’t used emacs much in the past decade, but it is a handy, light-weight editor also scoring high on the geek cred scale. As far as UNIX file editors go, emacs dates back to 1976 and has been developed in a fashion that retained it usefulness as it has been extended. To contrast with some other tools, emacs has endured the test of time and appears to keep on going. For more on Emacs, please check out the wiki.

Which brings us back to Microsoft’s premier development editor: Visual Studio (VS). I’ve been using Microsoft’s VS for the past decade and overall, each version has gotten bigger and at times more unwieldy, buggier and less usable. That is a shame because Microsoft has been cramming tons of work into adding features. I think on paper, VS ships a great spec: All kinds features, functions and capabilities. But over time, this editor has grown, and for some users, questionable usability and productivity.

One long running joke: Visual Studio was designed by and for executives. The meaning may be: At MS, Executives drive product direction. At other companies, Executives specify technology stacks, including development toolsets/Visual Studio.  What I’d find sad, is if MS executives don’t really know what they’re shipping (Visual Studio), and the other-company executives don’t really know what they’re buying.

A related item: Microsoft .NET. Years ago, when the internet was starting to take off and Executives were asking “how can I cash-in on this internet craze?” Microsoft was starting to sweat how they were going to complete with Netscape and remain competitive in this new internet based world. The MS Windows team was worried about future prospects (i.e. who needs windows is everything is done in-browser), as was the MS Office team (i.e. complete with web apps?), the MS Developer division (i.e. native applications?).

This brings us to .NET, which Microsoft hoped would provide competition to Java (another interpreted and web-centric language) .NET could theoretically help the office team if they wanted to market web-based office applications. And .NET could help the developer division remain competitive by developing a Cool.New.Thing! A bunch of languages (J#, VB.NET, etc) using the same run time (CLR) which run on different platforms (Cool! CRL is its own abstraction mechanism and runtime). Basically, a bunch of different people were jazzed about what .NET could do.

In the spirit of Dogfooding, Microsoft Developer division created a massive all-in-one developer tool to end all developer tools. I suspect many people thought this was a grand idea. Now that this has been completed, I do have to say this tool is a 100 ton whale that cannot get out of its own way. (That’s just my opinion, coming from VS6).  .NET possibly has become something of a challenge for Microsoft. Overall, it’s very functional and provides all kinds of cool capabilities. But…

.NET brings some challenges: auto handling of garbage collection (like java) is really pretty good, but perhaps as good as custom developed allocation and deallocation written in C++ (granted native alloc/free leads to who host of problems) Also .NET imposes a performance hit as CLR is a complete runtime, running on top of the Windows runtime. But, my biggest issue with .NET: its not being used as much as good old fashioned C++. And that’s a travesty. Specifically, MS spent many millions of dollar designing, developing and marketing a product (.NET) that people don’t want. And MS has been spending years pushing C++ developer, teams and products away from C++.  Don’t get me wrong, there are a bunch of people that write applications for .NET, but when you look at industry statistics: there currently are more people, teams and companies writing applications is good old fashioned C++, than in .NET. Since it took some years for Microsoft to realize this, they are now quickly trying to re-invest in their native C++ toolset. So now, Microsoft is saying something like: Hey C++ is a great language! You can use .NET or C++. Really, we love both!

This brings us back to Microsoft’s rumored Emacs.Net. Since .NET has some issues, and Visual Studio is written in .NET, and many C++ developers have gotten fed up with .NET… it’s time for a new tool: Emacs.NET. You may say: huh? It does seem a bit odd, but if I had to guess, I’d think this tool will have interop with .NET but overall, a (hopefully) clean slate design.. with expressed purpose of: continuing to leverage Microsoft’s technologies, while reconnecting with the core developer base (i.e. emacs endures, so lets make an emacs).  This results in a new light-weight tool to be levered against Windows Server core, Powershell and by general technical folks.

These are just my best guesses because I really don’t know. And neither will Microsoft until all is said and done. Developing software is one massive, yet continual, feedback loop. You don’t really know where you’re going, or how it will pan-out, until the product ships.


About dataland

Like many others, I'd like to improve the world but I'm currently caught up in day-to-day work. In the meantime, I'm a software developer who is very much focused on the end user.
This entry was posted in Microsoft, Software Development, Technology and tagged , , , . Bookmark the permalink.

5 Responses to Microsoft Emacs.Net

  1. Dmitri says:

    Well this sure is bizarre. The only real problem with VS is the fact that it gets really slow. And I don’t think it’s written using .NET – look at the extensibility API – it’s all COM. If it was .NET, we wouldn’t have all this casting foinf on. Anyway… the main problem with VS is the fact that things get really slow, especially if you get power-hungry add-ins such as ReSharper into the mix.

    Still, Emacs… how totally weird.

  2. Chuckle says:

    This reads like a spoof article by someone who’s deliberately trying to sound clueless for comic effect.

  3. Pingback: Emacs.NET - The Guessing Game « Tales from a Trading Desk

  4. Joe says:

    There really is no logic to what you are saying. If MS were turning away from C++ then why are they releasing new OS functionality in managed APIs only? MILCORE/WPF still doesn’t have a public C++ API.

    This sounds more like wishful thinking than anything else.

    I think I tried to bite off too much in this post. There are several things I’m trying to say here, which include the following. Microsoft’s FUD in large part created a new set of languages: .NET (this is OK). But, in marketing .NET, Microsoft (for all practical purposes) put their existing native VC++ customer base on hold (I don’t consider that OK). Since Microsoft is really massive, it’s taken quite a while to realize much of their developer base is still in native C++. Closely related (IMHO) to the moving away from their VC++ customer base, was the massive increase in bloat within Visual Studio. Again, in my opinion VS has not really gotten much new exciting C++/MFC functionality since VS 6. IMHO: most new functionality in VS 2002, 2003, and 2005 was geared around .NET. My pitiful attempt at snipping humor was that Emacs.NET may be (ironically) embraced by the VC++ developers since VS has gotten so slow and bloated. I also hope that Emacs.NET stays lean and mean (like what Mini-Microsoft might advocate)
    — Dataland

  5. Pingback: free wwe video

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s