This is the archived version of Roland Weigelt's weblog that ran from 2003 to 2023 at weblogs.asp.net

Contents tagged with Future

  • WebAssembly – A new Hope

    6 Comments

    Recently, WebAssembly was announced, a new standard that defines a binary format and execution model for the Web. With Google, Mozilla, Microsoft and others voicing their support, my first thought was: Wow, so there is actually hope to get rid of JavaScript someday!

    In this blog post I’ll explain why I think WebAssembly is such a big step in the right direction, even if it’s something that won’t have an immediate impact.

    What’s the problem with JavaScript, anyway?

    JavaScript is a programming language that has quirks (see Seven JavaScript Quirks I Wish I’d Known About or JavaScript garden), lacks important features (e.g. proper arithmetic data types) and isn’t type safe (by design).

    All this doesn’t matter for JavaScript’s original purpose – writing a few lines of script code. In fact, the dynamic nature of JavaScript, i.e. being able to add object properties or change data types on the fly, enables some pretty elegant solutions.

    But writing large amounts of JavaScript in a team of average developers comes with a risk that is higher than in other languages. Bugs that the compiler for a typed language would catch immediately can remain unnoticed for a long time. Renaming identifiers (via find-and-replace in a text editor) or refactoring code can be downright dangerous. Anders Hejlsberg puts it this way: “[…] you can write large programs in JavaScript. You just can’t maintain them.”.

    So why are people using JavaScript?

    • JavaScript in the browser (used in conjunction with other web technologies) enables highly responsive, cross-platform, zero-deployment applications…
    • …without any additional client installation (most would consider their favorite non-IE-browser as part of the “basic operating system setup” before any work can be done on a new computer) …
    • … and is good enough for developing almost any kind of application – at least given enough time, budget and/or determination.

    The problem: this “good enough” is an enormous hurdle for any alternative technology. At this point in time, it’s totally unrealistic that a completely new technology will magically appear and win the uphill battle to be available on all platforms, with the same reach as JavaScript-enabled web browsers.

    Fact is, JavaScript (plus other web tech) won. Some people are perfectly fine with this, others (me included) are a bit skeptical what this means for the future of software development –  to put it mildly.

    Is JavaScript the QWERTY of programming languages?

    I started programming in 1983 and since then I’ve witnessed incredible progress. From writing Z80 code that fit into a few kilobytes of RAM to simply using a component without caring, or even knowing, what language it was written in. And then, at some point, writing lots of code using a scripting language (using a document markup language to create application UIs, but that’s another story) became state-of-the-art. I thought we’d be much further in 2015.

    Ok, if replacing the JavaScript ecosystem with something completely new isn’t a realistic option, what can be done to improve the current situation for software developers?

    Option #1: Make JavaScript better

    JavaScript can be improved if all major players agree on the how, when and what. This can happen (see ECMAScript 2015), but sometimes it doesn’t (see ECMAScript 4). Improving a standard takes time, and it’s definitely not a playground for “let’s try this crazy idea and see how it works out when all browser have it”. Plus, some language characteristics simply cannot be changed without breaking a lot of existing code.

    Of course, this “you want to turn X into Y, but you cannot change X and don’t want to start from scratch” is nothing new in the world of programming languages. It’s a recurring pattern that if people have an idea for a programming language [feature] and are not in the position to write a full-blown compiler/interpreter and the matching runtime environment, they choose the route of more or less advanced a preprocessor.

    Which is exactly what happened with JavaScript, too.

    Option #2: Compile-to-JavaScript

    There are quite a few source-to-source compilers (see List of languages that compile to JS). These “transpilers” let you write programs in one language and translate the source code to another – JavaScript.

    In the early days, debugging was kind of painful, because you had to debug the resulting JavaScript. Now that browsers support source maps, the debugging story is straightforward: You step through the original source code, and the debugger keeps track of where program execution is in the JavaScript code behind the scenes.

    Note that source maps are not magic; they can tell the JavaScript debugger the original filename, line and column. If you want on-the-fly inspection of variables, the source language shouldn’t be too far away from JavaScript and its concepts (see the article “Beyond Source Maps” for more on source maps).

    TypeScript is a language that is close to JavaScript by design, extending it e.g. by offering optional typing. The TypeScript compiler translates the source code to idiomatic JavaScript code, i.e. code that a JavaScript developer following certain patterns would write by hand. TypeScript improves the developer experience, but cannot overcome inherent limits of JavaScript. The performance is determined by how fast the JavaScript engine executes JavaScript, obviously, and you still don’t get better (native) arithmetic data types.

    asm.js is “a strict subset of JavaScript that can be used as a low-level, efficient target language for compilers” (quote from the spec). So this is not a language intended to be written by human developers. Instead, a compiler like emscripten compiles a source language to “JavaScript-as-assembly” code. The code still runs in any browser, but for good performance you need an engine that either knows about asm.js or at least can achieve good performance from the JavaScript code that tries to avoid type conversions and garbage collections.

    There are a couple of things to keep in mind regarding asm.js:

    • Currently it is intended for statically-typed languages like C/C++ that use manual memory management. For other languages, you either have to translate the source to e.g. C first, or even translate the whole interpreter/runtime environment.
    • Browser vendors have to adapt their JavaScript engines for significant performance gains.
    • The resulting JavaScript code can be pretty large, so parsing the code on the client becomes a bottleneck (sending the code over the write can be an issue in certain scenarios, too).
    • Debugging is a problem, because the information stored in source maps is not sufficient.

    Finally, what’s WebAssembly about?

    WebAssembly can be thought of as an evolution of asm.js, to have “something” that can execute low-level code which can be optimized and precompiled. The central idea is transport the code in a binary format instead of (mis-)using JavaScript. This results in smaller file sizes and removes the parsing of source code on the client (good for mobile or IoT).

    This “something” will be part of JavaScript engines some day. Part of the high-level goals is to have a polyfill at least for the first step, the minimum viable product, which enables the MVP to run on existing browsers, but I’m not sure how important this will be in practice.

    It is important to note that at first, WebAssembly won’t be a general purpose compilation target for languages other than C/C++. The idea is to work incrementally, gain experience and collect feedback. The long-term vision does contain support for garbage-collected languages, though. Looking at the long list of To-dos it becomes clear that a lot of work is waiting to be done (including better source maps).

    Does WebAssembly have a chance?

    Judging from the collaboration of the big players alone, I’d say yes. Also important: Both the vision and the incremental approach to get there sound reasonable, clearly trying to avoid XHTML 2‘s “death by overambitious design”. WebAssembly is not about throwing away or replacing JavaScript engines. WebAssembly will be added to the engines, which helps interop and means that low-level infrastructure can be reused.

    Again, things will take time, and the first versions will not be suitable for all scenarios. In the long run (we’re talking years, not months), though, WebAssembly is very promising. If you have a general purpose engine/virtual machine in every browser, developers are free to use whatever language they want because the language matters only at compile time, not at runtime.

    And this is the point where we’ll be able to get rid of JavaScript.

  • A C# Feature I’d Really Like to See in a Future Version

    6 Comments

    In C#, if you declare a variable somewhere inside curly braces, that variable cannot be accessed from the outside. Examples are (private) member variables inside a class, (local) variables inside functions or statement blocks in general.

    What I really would like to see in a future version of C# are variables that can only be accessed within a property declaration. Then it would be possible to write something like this:

    class MyClass
{
    public string MyProperty
    {
        string _myProperty; // only accessible from within MyProperty

        get
        {
            DoSomething();
            return _myProperty;
        }
        set
        {
            _myProperty=value;
            DoSomethingElse();
        }
    }
}

    Looks like other people had the same idea, the feature is already suggested on UserVoice. The original author of the suggestion had a different reason for the suggestion (citing documentation requirements); the benefit that I and another commenter see is the additional encapsulation. By declaring the variable the way it is shown above, you could express the intent that the backing field isn’t intended to be accessed directly, helping other people reading the code (or yourself in a couple of weeks…).

    If you agree that the feature would be a valuable addition to the C# language, it would be nice if you could vote for it on UserVoice.

  • Welcome 2012

    No Comments

    Things that happened in 2011

    • MIX11 was a good conference, but not as great as MIX11. I blogged about
    • The BUILD conference (here’s my short recap) at first did a good job at exciting me about the things to come. But then too many “oh, wait a minute, so you’re saying …” moments hit me.
       
    • On both conferences Microsoft didn’t do much to prevent Silverlight from being labeled as “dead”. It’s a sad fact that we’re living in a world where reality is reduced to 140 characters or less. It’s just “good vs. evil”, “win vs. fail”, “the past vs. the future”.
      There was one sentence near the end of the “Standards-based web, plug-ins and Silverlight” blog post in April that did say the right thing: “HTML5 is a solution for many scenarios, but developers should make the appropriate choice based on application needs”. But the mismanaged communication by Microsoft, obviously caused by political in-fighting, puts this pragmatic “use the right tool for the right scenario” approach at risk. Why was Silverlight RC5 announced one week before BUILD? Why wasn’t the 10 year support guarantee communicated at BUILD (even if without a specific date)? 
      Other companies would have entered the stage with a loud and clear voice, telling everybody “Look at us, we’re the greatest development company in the world, we offer X and Y and Z.” – without showing the infamously silly architecture diagram.
       
    • On a more positive note: The dotnet Cologne 2011, the conference organized by the .NET user group Köln and my own group Bonn-to-Code.Net became the largest .NET community conference in Germany with almost 330 attendees.

    Things that I have learned/observed/noticed in 2011

    • I learned that I’m not the only one to have the growing feeling of “less participation, more consumption” in the (local) .NET community.
      A discussion at the .NET Open Space 2011 in Karlsruhe brought up the word “consumity”. In Bonn, despite the success of the dotnet Cologne conferences, the core audience has remained virtually unchanged over the years; the majority is “cherry picking” specific topics and finding speakers from within the group is tough.
       
    • I (again) couldn’t decide on a new smartphone to replace my vintage XDA Neo. After comparing Android, Windows Phone and iOS, I was ready to buy an iPhone (for its available software), but the 4S kept the design of the iPhone 4 which (in my humble opinion) is cool to look at, but doesn’t feel good in my hand. So one more year of being the only guy without a “real” smartphone. On the other hand my track record of waiting for a certain point in time to buy a piece of technology hasn’t been too bad.
       
    • I finally made the jump from Paint Shop Pro to Photoshop. Being a PSP user since 4.x, the transition – especially un-learning certain key strokes – wasn’t easy and there are still situations where I’d be faster in PSP. But of course I also gained a lot from the transition. And learning something different and trying to soak up a different philosophy from time to time isn’t a bad thing, either.

    Things I’m looking forward to in 2012

    • The dotnet Cologne 2012 on May 4th. We’ll be able to keep many sponsors from last year, but we’re also looking for new sponsors. Just drop me a line via the “Contact” link and we’ll send you our information on sponsorship opportunities. 
       
    • A new version of Visual Studio, which I suspect/hope to be more of a “Visual Studio 2010 R2” than something completely new.
       
    • Using async/await in C# in an RTM, i.e. non-CTP environment.
    • Continuing my personal path from being a software developer with an interest in GUIs to becoming a UI/UX expert.

  • Welcome 2011

    No Comments

    Things that happened in 2010

    • MIX10 was absolutely fantastic. Read my report of MIX10 to see why.
       
    • The dotnet Cologne 2010, the community conference organized by the .NET user group Köln and my own group Bonn-to-Code.Net became an even bigger success than I dared to dream of.
       
    • There was a huge discrepancy between the efforts by Microsoft to support .NET user groups to organize public live streaming events of the PDC keynote (the dotnet Cologne team joined forces with netug  Niederrhein to organize the PDCologne) and the actual content of the keynote. The reaction of the audience at our event was “meh” and even worse I seriously doubt we’ll ever get that number of people to such an event (which on top of that suffered from technical difficulties beyond our control).
       
    • What definitely would have deserved the public live streaming event treatment was the Silverlight Firestarter (aka “Silverlight Damage Control”) event. And maybe we would have thought about organizing something if it weren’t for the “burned earth” left by the PDC keynote. Anyway, the stuff shown at the firestarter keynote was the topic of conversations among colleagues days later (“did you see that? oh yeah, that was seriously cool”).

    Things that I have learned/observed/noticed in 2010

    • In the long run, there’s a huge difference between “It works pretty well” and “it just works and I never have to think about it”. I had to get rid of my USB graphics adapter powering the third monitor (read about it in this blog post). Various small issues (desktop icons sometimes moving their positions after a reboot for no apparent reasons, at least one game I couldn’t get run at all, all three monitors sometimes simply refusing to wake up after standby) finally made me buy a PCIe 1x graphics adapter. If you’re interested: The combination of a NVIDIA GTX 460 and a GT 220 is running in “don’t make me think” mode for a couple of months now.
       
    • PowerPoint 2010 is a seriously cool piece of software. Not only the new hardware-accelerated effects, but also features like built-in background removal and picture processing (which in many cases are simply “good enough” and save a lot of time) or the smart guides.
       
    • Outlook 2010 crashes on me a lot. I haven’t been successful in reproducing these crashes, they just happen when every couple of days on different occasions (only thing in common: I clicked something in the main window – yeah, very helpful observation)
       
    • Visual Studio 2010 reminds me of Visual Studio 2005 before SP1, which is actually not a good thing to say about a piece of software. I think it’s telling that Microsoft’s message regarding the beta of SP1 has been different from earlier service pack betas (promising an upgrade path for a beta to the RTM sounds to me like “please, please use it NOW!”).
       
    • I have a love/hate relationship with ReSharper. I don’t want to develop without it, but at the same time I can’t fail to notice that ReSharper is taking a heavy toll in terms of performance and sometimes stability.

    Things I’m looking forward to in 2011

    • Obviously, the dotnet Cologne 2011. We already have been able to score some big name sponsors (Microsoft, Intel), but we’re still looking for more sponsors. And be assured that we’ll make sure that our partners get the most out of their contribution, regardless of how big or small.
       
    • MIX11, period. 
       
    • Silverlight 5 is going to be great. The only thing I’m a bit nervous about is that I still haven’t read anything official on whether C# next version’s async/await will be in it. Leaving that out would be really stupid considering the end-of-2011 release of SL5 (moving the next release way into the future).

  • Welcome 2010

    1 Comment

    Things that have happened

    • I’m no longer responsible for maintaining GhostDoc, SubMain has taken over the development and this has freed up a considerable amount of time. Some of this time went into playing more computer games, a larger portion went into seriously digging into WPF.
       
    • The dotnet Cologne 2009, a community conference organized by the neighboring .NET user group Cologne and Bonn-to-Code.Net (which I founded exactly 4 years ago) became a huge success. In fact, almost too much of a success - we had to close registration a full month before the conference and the rooms sometimes were pretty crowded. There are plans for a dotnet Cologne 2010, but it’s too early to go into details.

    Things I have learned

    • The concept of “open space” / “unconference” can actually work. I attended the .NET Open Space 2009 in Leipzig and what I experienced blew away my initial skepticism. One thing to keep in mind is that this approach is not really a replacement for a conference in classic style – in my opinion the two styles supplement each other.
       
    • The more I learn about Silverlight and WPF, the more I start to see how much I don’t know yet. While the actual amount of concepts to learn is finite, knowing how to combine these to achieve a specific goal is something completely different.
       
    • Not much of a big surprise, just an observation: The lambda expressions introduced in C# 3.0 slowly but surely start to influence the way I think about/plan my code and (small scale) architecture.

    Things I’m looking forward to

    • Visual Studio 2010 when/if it’s released in good quality (please MS, take your time to get this release right, I still remember VS2005 before the SP!). I’m especially looking forward to the extensions for the editor that are now possible; when I saw the first samples, I was immediately reminded of one of my old blog posts back from 2003. Looks like we’re finally getting there!
       
    • Silverlight 4 and WPF 4: The basic concepts of WPF and Silverlight are promising, but at the same time there are still many quirks and missing pieces. It’s nice to see Microsoft is pushing hard to close the gaps, at the same time I still see a long way to go (enough work for version 5, 6 and 7). Performance is improving from version to version, but still can be a source of frustration. And I’m definitely looking forward to the day when Silverlight is a bit more specific about errors than just telling me AG_E_SOMETHING – but I guess I’ll have to wait for something after version 4 for that.

  • The Future of GhostDoc

    4 Comments

    Today is the day that I'm finally able to speak about why things have been pretty quiet lately regarding the future of GhostDoc.

    I'm happy to announce GhostDoc has been acquired by SubMain, developer of tools like CodeIt.Right. The agreement covers the usage of GhostDoc's documentation generation technology in their products, as well as the availability of GhostDoc as a standalone product. SubMain will continue to maintain and distribute a non-crippled version of GhostDoc free of charge, and will make sure that it will work with future versions of Visual Studio like the upcoming VS2010. The first step is a new version 2.5 of GhostDoc that has been released just moments ago.

    For more information please take a look at a Q&A with Serge Baranovsky from SubMain and me that covers past, present and future of GhostDoc.

    As I already mentioned in the Q&A, from my experiences of working with the guys at SubMain (both on the legal and the technical stuff), I can say that GhostDoc is in good hands. The developers now have my issue tracking database where I collected and annotated all the feature requests of the recent years, but I also would like to ask every GhostDoc user to please let them know if you have ideas how to improve this tool.

    I'd like to use this opportunity to say a big Thank You to all GhostDoc users out their for their (overwhelmingly positive) feedback over the recent years. Thank You!
     

    Update: Important note for existing GhostDoc users
    There are uninstall issues with the old GhostDoc version 2.1.3 (and versions before) that under specific circumstances may lead to losing your Visual Studio settings on Vista machines. I'm already working on a solution to the problem (with help from one of the SubMain developers), in the meantime please back up your settings as described in this step-by-step guide before uninstalling the old GhostDoc version. During uninstallation, if a Visual Studio instance pops up and asks you to choose a developer profile, choose one and continue. This will lead to the loss of the settings, which then can be restored by importing the backup you just made before. Note that you have to choose a profile; cancelling the dialog will lead to a corrupted state of the uninstallation.

    The new GhostDoc from SubMain is using different install/uninstall/VS integration technology that has been proven in their other products and does not have such problems.

    Update 2: Please read this blog post on upgrading to GhostDoc 2.5 and later.

  • WPF/E CTP - Nice, but...

    1 Comment

    I just downloaded the WPF/E CTP bits (a good starting point for all things WPF/E is the new Dev Center). If you are a C# dev who has waited for the CTP as eagerly as I did, be prepared for a slight disappointment: right now you can only use Javascript, but no managed code – yet. Fortunately a blog post by Scott Guthrie gives a hint of things to come: “…We'll also be providing "WPF/E" integration with .NET managed code next year ”.

    Regarding the roadmap, the WPF/E FAQ says “Microsoft plans to deliver a customer-deployable release in the first half of 2007”, with Joe Stegman mentioning upcoming CPTs in this blog post: “Our next milestone is scheduled for February 2007 and the feature set for this is in development and mostly fixed. The milestone after that will be driven largely by customer feedback”.

  • Looking back, looking forward...

    1 Comment

    2005 was an amazing year…

    • GhostDoc became really popular (the VS2005 version alone had over 6000 downloads since the release in early November).
    • The PDC was a great experience, and visiting Microsoft before that was a lot of fun.
    • Being part of the “Show Off” session was nice; unfortunately it was pretty late, so people started leaving the movie theater before my video was even shown.

    My plans for 2006 (to be more exact, those related to .NET)

    • GhostDoc: After doing a bit of work after Christmas, it became clear that GhostDoc 2.0 will be a “large” release. Internally I’ll do some heavy refactoring on certain, isolated parts, throwing out some historical junk and moving to “C# 2.0 style” code.
    • Things I want to learn: From my current point of view, WPF is the thing I want to dive into.
    • Things I want to do: I’m in the process of founding a local .NET user group for the Bonn area, called “Bonn to Code” (yup, pun intended – all credit for that name goes to my colleague Jens Schaller).

     

  • PDC 05: WPF (aka "Avalon") - Wow, I am impressed...

    4 Comments

    Data binding everywhere (every control, every property bindable), data templates (that can also be changed on the fly, depending on e.g. the value of a certain property) – I just saw virtually all my GUI problems of the last years solved. Okay, there will be new problems, but this is such a huge step forward… impressive.

  • Raising C# events doesn't feel right (and seems to have problems too)

    7 Comments

    [This blog post was inspired by reading “Events, Delegate and Multithreading” by Brad Abrams.]

    I'm pretty sure the language designers thought about the whole thing way longer than I did, but from the very beginning raising events simply didn't "feel right". I’m not talking about the pattern of using “On…” methods — while that was something I (with an extensive Javascript background) had to get used to, it was a typical case of “what? whose idea was that? hmm, that’s not so dumb after all… hey, good idea!”.

    No, it’s the way of actually raising the event inside the “On…” method. In the blog post mention above Eric Gunnerson is quoted “We have talked about adding an Invoke() keyword to the language to make this easier, but after a fair bit of discussion, we decided that we couldn't do the right thing all the time, so we elected not to do anything”. Well, but that’s exactly what I’m missing: a keyword. While I don’t miss much from VB6 (ok, maybe the command window), I really miss the good ol’ RaiseEvent.

    When you look at source code, keywords are something that catch your eye. While you are bombarded with lots and lots of words (names of classes, variables, methods, etc. ), keywords like “delegate”, “event”, “throw”, “override” (man, I’m thankful for that one!) stand out — not only because of the coloring inside the editor, but also because of the different syntax compared to lines and lines of “variable = Method(parameter)”.

    For example throwing an exception: 

    throw new FooException("bar");

    It says “throw” and you can virtually see some referees throwing a yellow flag.

    If I declare a delegate “FooHandler” and an event "Foo"

    public delegate void FooHandler(object sender, FooArgs e);
    public event     FooHandler Foo;

    then one can argue the overall approach (is it too complicated yes/no?), but nevertheless it’s quite clear what the code is trying to tell me: This is a delegate, and this is an event, and there seems to be some connection between those two (because FooHandler appears in both).

    But then comes the big letdown: the code for raising the event. Until recently I would have used

    protected virtual void OnFoo(FooArgs e)
    {
     if (Foo != null)
     Foo(this, e);
    }

    Now I’ve read the recommendation to use

    protected virtual void OnFoo(FooArgs e)
    {
     FooHandler handler = Foo;
     if (handler != null)
     handler(this, e);
    }

    Sorry, but this doesn’t survive my personal test for “is the important stuff easily discoverable”: Step back from the monitor, squint your eyes until things look kind of blurry, and then collect all information you can get from what you see with a quick look. For fun, try it with the code example. While “throw new blah blah” and “public event blah blah blah” give you a rough idea of what’s happening, you have to look again to find out what “protected virtual blah handler handler blah handler null blah this” is all about. To avoid misunderstandings: This is not about understanding a programming language without learning it. What I’m talking about is browsing code really fast, looking at each line only fractions of a second, and not actually thinking about the code, but just matching some basic patterns inside your brain — stuff we’re all doing automatically when scrolling up and down while editing text.

    Ok, this post is longer than it should be, so let’s cut this whole thing short and get to the point:

    Comparing raising an event with the way how to throw an exception, and keeping in mind that the official wording (according to the Design Guidelines for Class Library Developers) is that exceptions are "thrown" and events are "raised", I would personally prefer:

    protected virtual void OnFoo(FooArgs e)
    {
     raise Foo(this, e);
    }

    What should the “raise” keyword do internally? Let me play the role of the unfair customer here: I don’t care, just make it work. I want to raise an event and that should work without the danger of a race condition or whatever.