It's been 30 years since Ken and Larry and I started Axon. Back then, I was a 22 year old computer geek. Now, I'm an older (you can do the math) computer geek. I've spent more than half my life at it. Ours was not an overnight success story. More a matter of being too stubborn to give up and go work for someone else.
Some things haven't changed. What I wanted to do back then was write code. What do I like to do now? Write code. The trick was to figure out how to make a living writing the code I wanted to write, not just get a job writing code for someone else. In the end, I've been pretty successful at that. I've ended up writing some code that maybe wouldn't have been my first choice, but that's been the minority. And that's been more than offset by actually having customers and users, and a programming team, not just coding in a vacuum.
It's nice that Axon is now successful. I've been extremely fortunate. Although, to be honest, we spent so many years struggling that I feel vaguely uncomfortable not to be struggling. I see all our staff with their steady pay cheques and all the money flowing in and out of the company, and it seems a little alien. Even my mother never quite grasped our success. Long after it was a silly question, she would continue to ask me "Did you pay yourself this month?", and then slip me a twenty for coffee money. My father never lived to see our success. He would have been amazed.
I can see why entrepreneurs move on to start new companies rather than stay with a successful one. It's different. But I'm not really an entrepreneur, my interest was never the business side. So I guess I'll just keep on coding.
Thursday, September 13, 2012
Wednesday, September 12, 2012
Memory Usage of Suneido Versions
I've been assuming that the Java version of Suneido (jSuneido) used a lot more memory than the C++ version (cSuneido). But I think what gave me that idea was that I've been running the 64 bit version of Java. Running jSuneido on the 32 bit version of Java doesn't use a lot more memory than cSuneido.
.png)
This was after running our complete application test suite.
Of course, you will still want to use 64 bit Java if you are running a server for a big database and lots of users. In this case you should have lots of memory, so the extra usage is not important.
But for standalone development, it's nice to know you can run with not much more memory than cSuneido.
This was after running our complete application test suite.
Of course, you will still want to use 64 bit Java if you are running a server for a big database and lots of users. In this case you should have lots of memory, so the extra usage is not important.
But for standalone development, it's nice to know you can run with not much more memory than cSuneido.
Tuesday, September 11, 2012
Using MethodHandle's in jSuneido
This is a continuation to my last post, Moving jSuneido to Java 7.
Previously, the implementation of a built-in method looked like:
The new version, using method handles (behind the scenes) looks like:
At first, I wasn't sure how to handle the parameter information since I no longer had a class to put it in. Then I thought of using annotations, which I think works very nicely.
To use an annotation, it was easiest to specify the parameter information as a single string description rather than separate arguments. This means a little more work to parse it and split it up, but it makes the description cleaner. Of course, I could have done this before as well.
As before, during startup the methods are picked up by reflection. The difference is that now an instance of a generic class is created, containing a MethodHandle pointing to the static method. I still need the methods and instances to handle adjusting call arguments i.e. filling in default argument values, handling named arguments, and collecting or spreading arguments. (Suneido has a more flexible argument / parameter scheme than Java.)
Once I start using invokedynamic the argument adjustment will probably be done by composing method handles. I could do some of that now if I wanted, but it fits better with invokedynamic.
One advantage of this approach is that the methods can now be static and don't need to take an implicit "this" argument (which I didn't use) in addition to my own explicit "self" argument. Before, they had to be instance methods so I could call them virtually.
Meanwhile, I've been playing with invokedynamic and figuring our how best to use it. I'll post more on this as I progress.
Previously, the implementation of a built-in method looked like:
The new version, using method handles (behind the scenes) looks like:
At first, I wasn't sure how to handle the parameter information since I no longer had a class to put it in. Then I thought of using annotations, which I think works very nicely.
To use an annotation, it was easiest to specify the parameter information as a single string description rather than separate arguments. This means a little more work to parse it and split it up, but it makes the description cleaner. Of course, I could have done this before as well.
As before, during startup the methods are picked up by reflection. The difference is that now an instance of a generic class is created, containing a MethodHandle pointing to the static method. I still need the methods and instances to handle adjusting call arguments i.e. filling in default argument values, handling named arguments, and collecting or spreading arguments. (Suneido has a more flexible argument / parameter scheme than Java.)
Once I start using invokedynamic the argument adjustment will probably be done by composing method handles. I could do some of that now if I wanted, but it fits better with invokedynamic.
One advantage of this approach is that the methods can now be static and don't need to take an implicit "this" argument (which I didn't use) in addition to my own explicit "self" argument. Before, they had to be instance methods so I could call them virtually.
Meanwhile, I've been playing with invokedynamic and figuring our how best to use it. I'll post more on this as I progress.
Sunday, September 09, 2012
Moving jSuneido to Java 7
I'm finally getting around to using Java 7 features in jSuneido. I've been hearing about this stuff for so long, but it hasn't seemed practical to use it till lately. At first, Java 7 wasn't available. Then it was available, but there were some issues. Then Eclipse didn't support it. Now that these issues are resolved, and end-of-life for Java 6 has been announced, it seems like I can finally go ahead.
The main thing I've been waiting for is JSR 292 - Supporting Dynamically Typed Languages on the Java Platform.
For some reason I have a hard time wrapping my head around invoke dynamic + bootstrap + method handles. The ideas seem simple enough, but actually figuring out how to use them properly is tough. Part of the problem is that there's not much documentation available. That's not surprising, considering that the audience is primarily language developers and therefore small. There's the JSR292 Cookbook, which helps, but it's just code, with no explanation. There is a corresponding slide deck from last year's JVM Summit which is still mostly code, but at least highlights the critical pieces.
I decided to take the smallest first step I could - just use java.lang.invoke.MethodHandle to avoid making a class for each built-in method. Even that gave me a few problems because I wasn't sure how much of my infrastructure for default and named arguments I could/should replace. (I ended up keeping most of it for now.)
I got that working, but then I could no longer get ProGuard to run. (Note: I use it to produce a final jar with only what I need, I don't obfuscate.) It failed with:
Warning: suneido.language.Builtin$Method: can't find referenced method 'java.lang.Object invoke(java.lang.Object,java.lang.Object[])' in class java.lang.invoke.MethodHandle
I searched on the web, but couldn't find anything helpful.
I tried every combination of ProGuard options without any luck.
I eventually looked at the source for MethodHandle (which I somehow had available in Eclipse). The invoke method is native, so I tried the various options which ProGuard recommends for keeping native methods, again with no success.
I think the problem is that MethodHandle.invoke is "signature polymorphic", meaning it doesn't have a fixed signature. I'm guessing that is confusing ProGuard. (Although the signature is (Object... args) so it should accept anything anyway.) Hopefully they'll fix it at some point when more people try to use it.
In the meantime, I more or less gave up and just added:
The main thing I've been waiting for is JSR 292 - Supporting Dynamically Typed Languages on the Java Platform.
For some reason I have a hard time wrapping my head around invoke dynamic + bootstrap + method handles. The ideas seem simple enough, but actually figuring out how to use them properly is tough. Part of the problem is that there's not much documentation available. That's not surprising, considering that the audience is primarily language developers and therefore small. There's the JSR292 Cookbook, which helps, but it's just code, with no explanation. There is a corresponding slide deck from last year's JVM Summit which is still mostly code, but at least highlights the critical pieces.
I decided to take the smallest first step I could - just use java.lang.invoke.MethodHandle to avoid making a class for each built-in method. Even that gave me a few problems because I wasn't sure how much of my infrastructure for default and named arguments I could/should replace. (I ended up keeping most of it for now.)
I got that working, but then I could no longer get ProGuard to run. (Note: I use it to produce a final jar with only what I need, I don't obfuscate.) It failed with:
Warning: suneido.language.Builtin$Method: can't find referenced method 'java.lang.Object invoke(java.lang.Object,java.lang.Object[])' in class java.lang.invoke.MethodHandle
I searched on the web, but couldn't find anything helpful.
I tried every combination of ProGuard options without any luck.
I eventually looked at the source for MethodHandle (which I somehow had available in Eclipse). The invoke method is native, so I tried the various options which ProGuard recommends for keeping native methods, again with no success.
I think the problem is that MethodHandle.invoke is "signature polymorphic", meaning it doesn't have a fixed signature. I'm guessing that is confusing ProGuard. (Although the signature is (Object... args) so it should accept anything anyway.) Hopefully they'll fix it at some point when more people try to use it.
In the meantime, I more or less gave up and just added:
-dontwarn java.lang.invoke.MethodHandle
to my ProGuard configuration. That "fixes" the warnings and the resulting jar appears to work fine.
Just using MethodHandle for built-in methods doesn't really accomplish much, but it's a start. The real benefit will come from using invokedynamic, but that has a lot more moving parts to figure out.
Just using MethodHandle for built-in methods doesn't really accomplish much, but it's a start. The real benefit will come from using invokedynamic, but that has a lot more moving parts to figure out.
Thursday, September 06, 2012
Eclipse + MercurialEclipse Problem
Since I updated to Eclipse Juno 4.2 I've had problems a few times where Eclipse won't start - you just get a pop up saying an error has occurred and to look in the log. Often this seems to follow killing (Force Quit on Mac OS X) Eclipse after it freezes (locks up).
You can see from the log that the problem seems to be related to the MercurialEclipse plugin. I'm not sure if the original freezing is also caused by MercurialEclipse, but I wouldn't be surprised.
Side note: Mac OS X doesn't make it easy to access files starting with a dot, in a directory whose name starts with a dot. You can't really do it with the Finder (AFAIK). You can't even do it with an editor since the standard open file dialog also hides them. I usually just open a terminal window and cat /Users/andrew/workspace/.metadata/.log (On the positive side, you can copy the path from the error pop up and paste it into the terminal window.)
The solution I've come up with is:
You can see from the log that the problem seems to be related to the MercurialEclipse plugin. I'm not sure if the original freezing is also caused by MercurialEclipse, but I wouldn't be surprised.
Side note: Mac OS X doesn't make it easy to access files starting with a dot, in a directory whose name starts with a dot. You can't really do it with the Finder (AFAIK). You can't even do it with an editor since the standard open file dialog also hides them. I usually just open a terminal window and cat /Users/andrew/workspace/.metadata/.log (On the positive side, you can copy the path from the error pop up and paste it into the terminal window.)
The solution I've come up with is:
- go into your Eclipse/plugins directory
- rename com.vectrace.MercurialEclipse_<version>.jar to ...jarX (i.e. add X on the end)
- start Eclipse (it should work now, but you won't have Mercurial)
- quit from Eclipse
- rename the file back (remove the X from the end)
Wednesday, September 05, 2012
Kotlin - a JVM language
I like Scala for its power, but the complexity (especially the type system) scares me. I like Xtend for its simplicity, but it's somewhat limited. Kotlin seems to be aiming for a sweet spot somewhere in between the two - more powerful than Xtend, but not as scary as Scala.
Here are a few of the things I like (in no particular order)
- optional semicolons
- var and val
- modest type inference
- extension methods (like D and C# but more powerful)
(I like this better than Scala's implicit conversions) - traits (interfaces with method implementations)
- function literals aka lambdas or closures
- IDE support from the start
- improved handling of null references
- no checked exceptions
- standalone functions (everything doesn't have to be in a class)
- operator overloading
- infix function calls
- default and named arguments
- no "new" keyword
- when expressions
- static imports
- a goal of fast compilation
- good Java integration
There are a few more attractive features like inlining and runtime generics that are coming.
Of course, because it runs on the JVM and has good Java integration, I could mix Kotlin with Java in jSuneido. And I'd still have access to libraries like java.util.concurrent and Guava and ASM.
Another intriguing feature is that Kotlin can compile to JavaScript. I'm not sure why they're working on this, since their stated motivation for Kotlin is to have a better alternative to Java to write their IDE and other tools. Regardless, it's a neat idea. I've even had the crazy idea of implementing Suneido in JavaScript, but I'm not sure what the advantage would be, other than running in the browser. And I prefer statically typed languages for systems programming. I guess if I converted jSuneido to Kotlin, then in theory it could run in the browser (except for all the Java libraries I use).
I installed Jetbrains IntelliJ IDEA Community Edition (free) and added the Kotlin plugin. I've never really used IntilliJ but it wasn't hard to get started. Hello world was easy and so was implementing one of the classes I've been using for language evaluation. The Kotlin version of this class was the most clear and concise of the languages I've played with lately. (Without being so concise that it becomes cryptic.) I didn't have any installation problems or weird errors. Although this is beta software, it seems quite good.
I have mixed feelings about Kotlin arising from a commercial company. On the one hand it can mean there are some real resources behind it. And if Jetbrains really does use it for their own applications, then they will have a strong motivation to improve and polish it. (And hopefully less tendency to go down the rabbit hole of complexity.) On the other hand, a company can decide to drop projects for various business reasons. Thankfully, much of Kotlin is open source, so it has a life outside of just Jetbrains.
In a way I'm glad I didn't look into Kotlin when it was first announced (July 2011). Even now, it's still in beta and somewhat in flux. But it seems far enough along to play with and consider using at some point.
Hi, my name is Andrew, I'm a programming language addict ...
Hi, my name is Andrew, I'm a programming language addict ...
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.
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.
Saturday, September 01, 2012
No DRM Computer eBooks Update
- O'Reilly
- Pragmatic Programmers
- Manning
- Apress
- Informit (Addison-Wesley, Que, Sams)
I've run into a few older books that are available on Kindle from Amazon, but aren't available as ebooks from the above sources. I can see older books maybe not being available digitally, but if there's a Kindle version obviously that's not the case.
They all want you to sign up for their email lists. I prefer to keep my email free of that kind of stuff. Some of them have RSS feeds which I don't mind.
One of the advantages of getting the emails or following the feeds is to get discount offers. Another option for this is to do a web search for something like "oreilly coupons". This will usually turn up valid discount codes. I'm not sure if the companies like that, but they're the ones offering the discounts, so I figure it's ok.
It's too bad that Amazon doesn't sell DRM-free books. It's not ideal to have to go to multiple suppliers, and set up accounts on each, and deal with their differences. Some take PayPal, some don't. O'Reilly automatically sends my books to my Dropbox, the others don't. Maybe someday Amazon will see the light. Until then, they're losing my business.
Several of the sources offer access to "pre-release" versions. At first it seemed attractive to get access sooner, but I ended up preferring to wait to read the final version.
I've been looking forward to Tor (science fiction) going DRM-free, but the date has slipped from "July" to "summer", and now it's September. There's already been pressure by other publishers against Tor authors. [Update: I see on Amazon that at least some Tor books say: "At the publisher's request, this title is being sold without Digital Rights Management software (DRM) applied." I'm not sure why the Tor web-site still says "Coming in Summer 2012", maybe that's just referring to Tor's online store.]
Just to be clear, I prefer to buy my ebooks without DRM because it gives me more flexibility in where and how I can read them. I do not do it because I want to "pirate" them.
Labels:
books
Subscribe to:
Posts (Atom)