Kilsmo's log

I have just bought an Acer Aspire S7 with 256 GB SSD and an Intel Core i7 CPU. 13" screen, 1920*1080, Windows 8 preinstalled and it has a touch screen.

I am going to write about my experience with Windows 8 as I go along, and the first thing that I am going to explore is using the touch screen.

The reason to but a laptop with a touch screen for me was to be able to test on the same machine as I do the app development. But from my first experience I can say, having a touch screen on a laptop is great! I use touch a lot. I can put the laptop in my lap, use the touch screen without holding it with my hands as when I use a tablet, and always have the keyboard available for typing and use of modifier keys.

I can't tell you if it is an ergonomic problems to use touch on a laptop, but I think you will use it as much as it makes you feel comfortable, you will not touch all the time. And, just for your information, using a tablet gave me serious neck and back problems, so don't believe that a tablet is a more ergonomic device than a laptop with a touch screen without actually trying it out.

I am very happy I spent the extra money to get a laptop with a touch screen.

Dart is a rather boring language, and I think it is meant to be boring. Languages are allowed to be boring, just look at Java, it was a big success, but has written boredom all over it. Dart is a language that tries to stay close to the static Java-like-languages, and add some stuff that makes it feel lighter. Robust, boring, and with a touch of scripting language.

For a person like me, that mostly have been doing C++ development, it is a good thing that the language is boring, since it is more similar to what I have been doing. Of course, there are interesting things with the language, like optional type system and isolates. If you compare it to JavaScript (I think we should, since Google is trying to integrate it to the browser) it is less dynamic, but more robust. That code can import other code is great for structure, and I also think that the main function brings structure, instead of just adding code in the body of the script to do initialization. (however, main removes the nice things from most scripting languages)

A warning, it is hard to learn Dart, you can use try.dartlang.org, and you also need to read the language specification. (I have not done that yet, so I don't have a full understanding of the language)

If it was just a language choice, it existed two languages in the world, Dart and JavaScript, and both worked equally well in the browser, which one would I pick? Because of my background, I would probably go for Dart. If Dart were a little better at being dynamic, it would be an easier choice.

What is the chance that we can add another successful language to the browser? I will list a few things that must come true.

Size of the binary: how much bigger will the binary be if we add another language? This is something that a few years ago were very important for running on mobile devices. But, if you are going to be able to run a web browser well, you need a lot of heap storage. No new smartphone has less than 256 MB I think, so this argument is probably not valid anymore. However, if we start talking about adding n languages, it will of course be a problem.

Burden on browser vendors: creating a good JavaScript engine is a lot of work, creating an engine for Dart will double that effort. Of course, everyone can use the same Dart engine if they want to. Google's dart implementation will be written to integrate well with Chrome, and its API will work best with Chrome.

Standardization: I like JavaScript because it is standardized, and therefore can have multiple compatible implementations. Dart needs to be standardized too.

Work everywhere: JavaScript is available everywhere, how is Dart supposed to get there? First, all browser vendors must like it, and find a way to motivate themselves to add it. Google will add it to Chrome since they are creating the language. They would probably also try to write some of their biggest web applications in Dart. Mozilla would like it if the design process is open, and if more applications will be written for the web as a result. Opera would add it if the others add it. Google can easily do all the integration for Apple, that is a good way to convince someone. Microsoft, I don't know what it would take. They try to be compatible with what is already out there, and they might want to push for another solution if we are going to allow any other language to the web.

So, what do I think? I dislike the effort of trying to add a lot of functionality to JavaScript, morphing it to a different language, I thought the EcmaScript 4 suggestion was horrible, and was very happy that it didn't happen. JavaScript is a compatible language, and it should stay compatible. At the same time, more and more code is written for the web, and we should have better tools for building what we want to build. I find CoffeeScript to be a very nice addition, but as long as you can't debug in a good way, it will not be a great solution. We have to think about the future, and we should not settle for something that is not good enough, or else the walled gardens will win. I want applications that run on all platforms, on all devices. Dart is at least one possible way to get there. And, it widens the discussion how we should solve the web as a platform.

One thing that scared me with Dart, before I saw the actual information about the language yesterday, was its type system. It was supposed to have both typed and untyped variables. This sounded like complexity, and I don't like complexity in languages.

Now I know that the type system is very different from what I anticipated. Yes it has both untyped and typed variables. But they did something that I have never seen in a language that I have studied before, the types were for debugging and documentation, not a rigid type system that will keep you in the type jail.

When you run your code in production, the VM does not care about the types. When you debug it, the tools will check if the types are honored. Suddenly, you have a language who's variables are completely dynamic, but that helps you write more robust code anyway.

So, what are the advantages of using variable type declaration?

1. Documentation, easier to document an API, since the types are given in the declaration.
2. Type checking during compilation and/or run-time.
3. Faster code.

In Dart, you get the documentation, you also get most of the type checking. However, the faster code part is not there, since all static type declarations is gone when you run the code in production. I think that is a good thing, I think that a VM that supports type checking might be slower when it also allows untyped variables, so it is better to treat all variables as untyped. But, of course static type checking during compilation will usually have a speed advantage to untyped variables.

I have not completely dived into Dart yet. It feels like a pragmatic, but not very exciting language. The type system is interesting, and I think I like it.

So, Amazon has created a new browser Silk for its soon to released tablet Amazon Kindle Fire. Silk is something similar to Opera Mini or Skyfire, but it is really hard to understand from the available information how it actually works. I can't figure out if it is more like Opera Mini, or more like Skyfire in its design.

You can do "cloud browsing" in a number of ways. You can just do a proxy to the Internet, and do all the requests via a server, with a quick link to the browser. This doesn't reduce the size of the content downloaded, but you can have one connection to the server open, and can shuffle the data quicker than individual requests. Then you can do one step further, compress the content, like Opera Turbo. You may reduce the image quality, but you use a normal web rendering engine on the client, so everything will work the same way as you are used to. Then you can do what Opera Mini does, invent a new format for rendering on the client, so you don't need a real web rendering engine on the client, but something simpler and much more compact data. The last variant is to send bitmaps representing the content on the screen, and as soon as the content changes/you scroll, the browser will get new bitmaps. It is like a glorified VNC server, that is only used for the browser.

All these types of "cloud browsing" solutions have their pros and cons. It depends on the device and the network which one you want to use. And only the first two solutions can provide SSL all the way, so you might lose more customers if you go for the last two options due to security concerns.

One thing that makes me believe that Silk is using Opera Mini-like technology is that they say that they send compressed images to the client. But, watching the video, I am not really sure.

A VNC-like solution is much simpler than a solution based on markup in its design. Its drawback is usually bandwidth usage. But, for a WiFi-only device for the US market, I don't think that extremely low bandwidth usage is as important to the user. (and Amazon will be shuffling much more data into their "cloud" than out from it, so cost shouldn't be that big of a deal either for each solution) And, they create a new "cloud browser", is it really possible that they have gone through all the problems that is related to a solution not based on bitmaps, if it is not necessary for their target audience?

I personally use Opera Mobile on my Android device, since I think it is fast enough and I have unlimited data on my 3G subscription.

Then, there is a remark in the blog post, that sounds like something unique from the Silk browser: "Each time you load a web page, Silk makes a dynamic decision about which of these subsystems will run locally and which will execute remotely."

What does that mean? I don't know. But having a really flexible solution will create a lot of complexity. Should JavaScript run locally on some pages, and not on others? And if JavaScript runs locally, the rest will have to run locally to. To me, it does not make sense. We will have to wait and see.

The days are not actual days, but the time it takes me to read 100 pages in the book, and have time to read and comment about them. My goal is still to read 100 pages a day, but after 3 days I had only read 200 pages, so we'll see how that goes, it is not that important to reach the goal, what is important is to finish the book.

What I noticed when reading this time, was that C# is really a better C++, or at least aims to be. (depending on your own preferences) You can actually see the differences from Java (at least early Java that I am used to), that C# tries to add more of the functionality from C++ but in a different and cleaner way, where Java tried to be a simpler language than C++. What I really liked was the use of use and ref keywords for references. You have to declare out or ref to the argument, when you call a function that has a parameter list with an out or ref parameter. In C++, you add an &, and then the argument becomes a reference, without you even know that it might be changed in the function that you call. (that is, if you only look at the current function, not the function that gets called, you will not see that it is passed by reference)

This is just one example of C# providing C++ functionality in a cleaner way. I am still a little bit sceptic about using C#, I want to move away from C++, and if I end up in a language too similar, what will I learn? And, I have started to believe in dynamic languages, so why a structured language? C# tries to be the perfect structured language. And, the structured language needs a lot of features I think. It can't really just be as elegant as a dynamic language, the whole idea inherited from structured languages demands that you add features, since otherwise you will feel limited, as all of you know that used the first version of Java. If you don't have generics, you will spend all your time casting, so you need that feature. In a dynamic language, you don't need generics, you just call the functions that you want, and it will fail if it doesn't exist. So, with C# I will get a feeling of how good a structured language can be, and compare it to the best dynamic language, to see who actually wins. :-)

In general, what makes a dynamic language better than a structured language, and vice versa? A dynamic language can be much simpler, fewer constructs, and at the same time deliver the same power as a structured language. Code from a dynamic language will use fewer lines of code. Code testing is better in a dynamic language, since you will be able to truly write the tests first, you can call functions that does not exist, and say that the test fails. (instead of having to write a stub for that function) Documentation is better in a structured language, you get a lot of help from type checking and access modifiers. Tools usually work better with structured languages, even if I am not sure that it will always be like that, or if it is not that we have figured out yet how to write great tools for dynamic languages. Because of the above, structured languages work better with external libraries.

Which leads to a good reason for me to learn C#. Working with external libraries. I am not used to that at all. I haven't even used STL in C++. The problem is to grasp a big set of external functionality, and to make use of them. It will be very useful for a coder that thinks that it is more fun to write a hash table implementation, than to use one.

So, I got my DVD+R DL disk that I needed for installing Windows 8. I like to take risks, so I wiped my Windows 7 computer, to replace it with Windows 8. It didn't work.I spent at least 90 minutes to make sure that it didn't work, installing both with and without developer tools.

Finally, I decided to try to install Windows 8 on the second drive, a 2 TB drive with stone age technology, instead of the 120 GB SSD that I have been using for Windows 7. Then, it suddenly worked. Of course, I had installed the version without developer tools when it started working, so another install with the developer tools and I was done.

I have also written my first 'application'. (actually, what I did was writing "Hello world" in the HTML body, but it is still an application, that is, it started when I used Visual Studio to tell it to start. Now I am at least there when I can start coding.

So, what about Windows 8? Well, I will not spend that much time on that, I will jump to coding immediately. After all, it is probably just a year or so until the applications have to be ready. :-)

Today the Build conference will start. Since I am in Europe, I have some time to finish this blog post, before we know what the Build conference will present.

I am not going to guess what they will talk about. I am just going to share what I currently think of Microsoft, and that also includes what probably will happen at Build. I am going to watch the live stream of the keynote, since I think this event is one of the most important events ever in the industry.

If you listen to the debate, it sounds like Microsoft is a has-been. I see a new and strong Microsoft, a Microsoft that is easier to like. The starting point of Microsoft's new life is Windows 7. It is not that I am one of those who think that Vista was worse than XP, I preferred Vista over XP. The reason that Windows 7 is so important is that the good developers won. Only promise to deliver what you can deliver, only show what is almost complete, and that you can deliver. Deliver on time. A company that does not even control their own development process, will not be able to deliver good stuff, or shape the future. With Windows 7, Microsoft fixed that.

With a fixed development process, Microsoft was able to start doing real innovation again. You can't do innovation, if you are not sure if there will be a version of Windows to add your innovation to. We don't know that much about Windows 8 yet, but what we can see, it sure looks innovative.

A company that can deliver, and can innovate, does not have to be scared. Microsoft can now shape their own future. A company that is scared, will fight to keep their position, instead of using their skills to stay ahead of the competition. When you try to keep your position, you will do whatever you can to slow the competition down, since the competition is better than you at innovation.

Lock-in is not a viable long-term strategy. It can work well for a few years, but since technology moves on, the innovation dept for a company that tries to use lock-in as a strategy will eventually be too big. Microsoft knows that, and the new Microsoft has innovation as its strategy, not lock-in. A lot of companies (including Opera Software where I used to work) have tried to stop Microsoft from using the lock-in strategy. It has had some effect, but the biggest reason for Microsoft's change in strategy is there because Microsoft needed it, and that they were finally able to change when their development process and innovation started working.

But isn't Microsoft still evil? Well, probably, but it is hard to tell. When it comes to standards, they are accused of not implementing the new standards fast enough, and for building test cases where IE passes. The IE team has improved so much that I am happy with their development speed. As for test cases, I think that they are doing the right thing. Of course you should build test cases, and make sure that your product passes all of them before you release them. You need to prove that your tests work first. Of course, there has been some marketing coupled with the release of the test cases, but the reason for releasing the test cases have been to improve the web, no doubt about that. I think it is sad that some people can't see the difference between the work the team is doing to improve the web, and what the marketing department is doing. By releasing the test cases, Microsoft helps other browser makers to find their bugs. (and in a few cases that I know of, find bugs in their test cases, and actually help Microsoft back by fixing the bugs in the test cases, that finds bugs in IE)

Then we have the big and ugly patent fight between the biggest companies. Or may I say the marketing fight? Because especially the fight between Microsoft and Google seems to be marketing. Both cries wolf. Good thing that both companies have a lot of money to spend on both patents and marketing. Microsoft has the history of being evil, Google has the potential of being evil.

Microsoft is the only company of the big ones that has focus on the developer. This is Microsoft's strength. They get developers. They get how important it is to have partners. Microsoft is not arrogant, but they are able to listen to the developers, and deliver something that works for them. Of course, in the last years, they have tried to invent their own stuff, but Microsoft is changing. And now, with Windows 8, the only thing we know about developing for the platform, is that you are going to be able to build applications with web technology. This is from a company that tried to make sure that the web stagnated, since they were afraid that the web platform could compete with their platform. Today, Microsoft has realized that their platform is not limited to the client, and they are delivering the complete stack, with hosting in Windows Azure, and the focus is the developer's needs.

Developers, developers, developers. Do you want to go Apple, and develop in Objective C, a language that I can for no reason call a good language. Or do you want to go Google, and use their clunky Eclipse based tools for Android development? I am not fond of C#, I am really tired of the statically typed languages, and all the code that you usually need to write in them just for the simplest thing. But you still have the best development tools that the market has to offer. And now, with Windows Azure maturing, you get all you need to develop and deploy applications from one big company.

Developers is the true, legal, and moral lock-in. Build stuff that the developers like, and they will build great applications on your platform. Don't just get them there because the platform is the biggest, that does not work for Windows Phone, because of its market share, and apply the developer love everywhere. I think this is exactly where Microsoft is heading.

I am trying to adjust to living in the Microsoft world and finding a way to like it. To be able to use web technology in Windows 8 is important to me, it helps me being a believer. I have for a long time worried about two things, the hardware, and the special versions of Windows that you get when you buy a laptop. I hope this will be solved, and Intel's UltraBook concept is something that is very interesting. Today, I would buy a MacBook Air if I just looked at the hardware, but soon I think I will have a choice.

I am really looking forward to the keynote that is only 160 minutes into the future.

Opera Unite might be one of the most odd extensions of the browser. Add a web server to the browser, and have a more powerful application platform. I never really understood (when I was an Opera employee) why Unite was a great solution. However, I agreed with its goals, give the data back to the user, and make it easy to write and use applications. Actually, I felt very strongly for its goals, and fulfilling its goals is something that I have been thinking about since before the first internal prototype of Unite existed.

There are alternative solutions, like Pogoplug, but I don't really see that as the answer to the goals.

And a solution that I sketched on a few years ago, closer to Pogoplug, but with applications on the server written in JavaScript, had a lot of problems too. As soon as you have a local server, even the simplest to administer, you get network problems and problems that the average user needs to install it. (privacy and power should be for everyone, why should you create a solution for the people who already know how to install a server?)

Finally, this week, I saw the light. (actually, I saw a light, and it is probably a solution that has problems just like all the other solutions, but all the pieces fit very well together, so well that I can't stop thinking that this might be the problem-free solution) One of the ingredients is hosted private clouds, as an alternative to people being able to have a private cloud that they host themselves. How hard do you want it to be to keep your data private, vs how private do you want your data to be.

I am going to experiment with this for a while (it is much more to it than just hosted private clouds, but the details are not that interesting until I have a proof of concept), and see how it works. One interesting thing is that I started to think about this problem again since I wanted to create another product, and it needed some of the things that a private cloud or hosted private cloud can provide. Distractions, you never know if the distraction is more important than the product.

Cake is CoffeeScript's build tool. It is not much to be said about it, yoi write a Cakefile, that is using CoffeeScript code, and run it with the cake command.

You define tasks by calling the task function, and cake will take care of the rest. I have created a small Cakefile, to build the two files in my previous unit testing example. Of course you can approve this a lot, but right now I just want to show you how to get started using cake. Write cake build, and the 2 coffee files will be translated to JavaScript files.

{exec} = require 'child_process'

task 'build', 'build everything', ->
  for x in ['./taste.coffee', './tests.coffee']
    exec "coffee -c #{x}"

Name, description, function, that's it. And, with the blessing of NodeJS, you can call binaries like coffee.

I have been trying to learn some CoffeeScript, and just bought and started to read CoffeeScript, Accelerated JavaScript Development. I am so impressed with CoffeeScript! It enables you to write compact beautiful code. What I am wondering is if the constraints to try to be close to JavaScript under the hood helped the design process of the language. Usually, when designing a new language, you can do whatever you want, too many choices to try out. Or maybe is it just a result of the genius Jeremy Ashkenas. Better than JavaScript, better than Python, better than Ruby.

So, the question is still, will you be more productive in CoffeeScript than you would be in JavaScript. You win a nicer language with clear and compact syntax, you lose the possibility to debug in the source language, and need to debug in another language. (JavaScript) Work is being done supporting source level CoffeeScript debugging, but we are not there yet, so what about productivity today?

This is a really hard comparison to make, I am absolutely certain that given a CoffeScript source code debugger, developing in CoffeeScript would be more productivity, but what is the actual cost of not having a source code debugger?

The CoffeeScript compiler will catch all errors in your syntax, but it will not catch runtime errors. Make sure that you are using tests. (a combination of unit tests and acceptance tests) Make sure that you know JavaScript. Every time you happen to run into a runtime error, you will lose some time in comparison to getting the same error in JavaScript.

I could of course guess what will be more productive. (my guess is that the productivity in CoffeeScript would be higher) But guessing isn't an answer. Measuring is. So, what to measure?

* Compare the number of runtime errors during the development of an application
* Compare the average time it takes to fix a runtime error
* Compare the time it takes to write the code (excluding the time it takes to fix runtime errors)
* Use the same acceptance tests for both implementations

Let's see if I can set up such an experiment.