As an avid OCaml hacker I wonder whether you have any plans to make your runtime port available as open source software (OCaml being GPL and all)?
jaked
· 2 years ago
Thanks for asking. The port is still under development, but we will definitely be releasing the source before shipping it on phones.
andrey
· 2 years ago
Man, this is so awesome! I wish we did something like that @Vindigo. Writing all those apps would've been so much easier...
Serge
· 2 years ago
In my experience, it is true that OCaml boosts productivity thanks to its type system. However I still have mixed feelings about it when it comes to readability and the stability of the language itself (just consider the recent CamlP4 incompatible changes).
C and C++ bindings are added to OCaml by the day. While many hail this as healthy for the language, I view it as a failure: it destroys code portability because now you depend on the underlying platform, it is no testament to OCaml's versatility and it voids its safety.
By analogy, would you rather use a JNI JDBC implementation and get into all kinds of threading problems, memory corruption and the like rather than use a pure Java JDBC driver?
Not to curb your enthusiasm though! OCaml fills a nice niche between the lax C and C++ legacy and the strictness of Ada (btw Ada is eminently more readable). It runtime is currently non-preemptive; not a problem in your case since you can develop a runtime that plays well with active objects.
I applaud this strategy that I am sure will help boost portability in the messy, unreliable, under-documented world of mobile software development (about which I could rant on and on but that's another issue)
I will be reading this blog in the future and hope you will report about this experience!
Matthew Stecker
· 2 years ago
So, I've been ruminating about this for a few days now. It's a fascinating choice.
I get that by "owning" the runtime, you essentially gain machine level control of the device while still getting to program in a more abstract language. It's a conceptually similar choice to that of building your own phone-side browser rather than relying on the built-in browser.
That said, why not port a Java runtime of your choosing? At least then, you'd still have a shot at deploying on "closed" environments that might only give you access at the J2ME level. Perhaps you've decided that these smaller and/or more "closed" devices aren't in your immediate roadmap.
I've seen some ugly caml code in the telecom world in the last year. I almost feel that languages are readability agnostic (perl and ada excluded). Vindigo had some amazingly readable server code - not because Java necessariy lent itself to that - but becuase the team placed a high value on reading code.
Unfortunately, it will be hard to draw conclusions from the effectiveness of your initial work, if only becuase you guys are good enough to make any framework run well. It reminds me of a recent track day - driving my fancy new Porsche - when I had my posterior handed to me (passed like I was sitting still) by a seasoned instructor driving a Mini. The point being that the skill of the driver (or in this case the programmer) plays such a huge part in the overall delivery, that it's hard to independently judge the effectiveness of the tool. If you're planning on bringing in lots of newer/younger programmers, that will be more interesting.
All Comments
I wish we did something like that @Vindigo.
Writing all those apps would've been so much easier...
However I still have mixed feelings about it when it comes to readability and the stability of the language itself (just consider the recent CamlP4 incompatible changes).
C and C++ bindings are added to OCaml by the day. While many hail this as healthy for the language, I view it as a failure: it destroys code portability because now you depend on the underlying platform, it is no testament to OCaml's versatility and it voids its safety.
By analogy, would you rather use a JNI JDBC implementation and get into all kinds of threading problems, memory corruption and the like rather than use a pure Java JDBC driver?
Not to curb your enthusiasm though! OCaml fills a nice niche between the lax C and C++ legacy and the strictness of Ada (btw Ada is eminently more readable).
It runtime is currently non-preemptive; not a problem in your case since you can develop a runtime that plays well with active objects.
I applaud this strategy that I am sure will help boost portability in the messy, unreliable, under-documented world of mobile software development (about which I could rant on and on but that's another issue)
I will be reading this blog in the future and hope you will report about this experience!
I get that by "owning" the runtime, you essentially gain machine level control of the device while still getting to program in a more abstract language. It's a conceptually similar choice to that of building your own phone-side browser rather than relying on the built-in browser.
That said, why not port a Java runtime of your choosing? At least then, you'd still have a shot at deploying on "closed" environments that might only give you access at the J2ME level. Perhaps you've decided that these smaller and/or more "closed" devices aren't in your immediate roadmap.
I've seen some ugly caml code in the telecom world in the last year. I almost feel that languages are readability agnostic (perl and ada excluded). Vindigo had some amazingly readable server code - not because Java necessariy lent itself to that - but becuase the team placed a high value on reading code.
Unfortunately, it will be hard to draw conclusions from the effectiveness of your initial work, if only becuase you guys are good enough to make any framework run well. It reminds me of a recent track day - driving my fancy new Porsche - when I had my posterior handed to me (passed like I was sitting still) by a seasoned instructor driving a Mini. The point being that the skill of the driver (or in this case the programmer) plays such a huge part in the overall delivery, that it's hard to independently judge the effectiveness of the tool. If you're planning on bringing in lots of newer/younger programmers, that will be more interesting.
Matthew