Tuesday, September 04, 2012

Second Thoughts on C# and .Net

I got quite optimistic about nSuneido - a .Net implementation of Suneido. The C# language is decent, the Dynamic Language Runtime (DLR) looked promising, and Mono and MonoDevelop were better than I expected. I went quite a bit farther with my experimenting than I had with D.

But ... I started to run into some frustrations. First, the MSDN .Net documentation sucks. That wasn't a big deal when I was just writing simple code. But when I needed to use the framework, it wasn't so good. Granted, I was trying to work with memory mapped files, which is often tricky. And some of the problems may have been due to working in Mono, rather than on Windows. I ended up having to look at the Mono source code to figure out how to get things working.

Looking at the source code made me realize that Mono probably isn't quite as production capable as I would like. Don't get me wrong, they've done a great job, but unfortunately they'll always be a second class citizen playing catch up with limited resources.

Don't get me wrong, I realize there are going to be frustrations with any platform. The grass always looks greener than it actually is. You initially tend to focus on the problems that something will solve, not realizing what you might lose, or the new problems it will introduce.

Finally, I started to wonder if I really wanted to support multiple implementations. I realize that I actually chose quite well when I picked Java. I don't think there's any question that the JVM is the most stable, portable, and performant platform.

So why was I looking for an alternative to Java? There are two main things:

- Suneido's current user interface is Windows API based

- The Java language is ok, but it's ... old. We can do better.

(There are other issues, like the lack of fixnum's and value types, but you can't have everything.)

But it may be possible to solve both of these, and stay with the JVM platform and all its goodness.

- Java Native Access (JNA) can provide access to the Windows API

- Other languages are available on the JVM (more all the time). I could use Xtend, or Scala, or maybe Kotlin. And using another JVM language could be done incrementally.

I'm a strong believer in not starting software projects over from scratch. And I don't believe that's what I've done with jSuneido. Porting or writing an alternative implementation are not the same as starting from scratch. What I've found, especially lately, is that rewriting existing code, even multiple times, is very beneficial. You find bugs, discover better approaches, and gradually work towards a clean design. The jSuneido implementation is much better than cSuneido. And from rewriting code in Xtend, and D, and C# I continue to find better approaches.

I don't want to give up the benefits of rewriting, but I also don't really want to write and maintain multiple implementations. Perhaps sticking to the JVM and experimenting with alternate languages is the best compromise.


Larry Reid said...

Here's my totally off-the-wall suggestion: Emulate the Windows GUI API in a browser. That way you get portability and the ability to run over the Web. 45 seconds of Googling didn't find anyone who's done it, but I wonder if there isn't something out there to do it? And API that matches Windows and turns it into something that a browser can render.

Andrew McKinlay said...

That certainly makes sense, but I think it would be tough. The Windows API is very low level. I think a better level to emulate would be our widgets. We only use a limited number, and it's a higher level. Of course, the other drawback is browser incompatibilities, but you could get around that by embedding something like WebKit or Chromium.