Ola Bini is a Swedish developer working for ThoughtWorks. His daily job includes working on JRuby, starting up a Swedish ThoughtWorks office and mucking around with Java and Ruby. In his spare time he spends most time on his language Ioke, working on one of several other open source projects or reading science fiction. Ola has presented at numerous conferences, such as JavaOne, Javapolis, JAOO, RailsConf, TheServerSide Java Symposium and more. He is the author of APress book Practical JRuby on Rails Ola is a DZone MVB and is not an employee of DZone and has posted 45 posts at DZone. You can read more from them at their website. View Full User Profile

Some Results From the Ioke experiment

07.03.2010
| 3396 views |
  • submit to reddit

It’s been a bit over 18 months since I first released Ioke in the wild. During this time I’ve always been specific about Ioke first and foremost being a language experiment. I changed many things to see what would work and what would not. I thought I’d take stock and take a look at a few of these decisions and how I feel about them now. Ioke never got a huge user base, of course, so most of these impressions are based on my continued working on the language, and also experiences trying to explain features of the language.

This does not mean in any way that the Ioke experiment is over. I will continue working on Ioke and see what else interesting will come out of it.

White space separation for method calls

I adapted Io’s, Self’s and Smalltalk’s syntax for Ioke. This meant I could use periods to end expressions instead (taking the role of semicolons in most other languages). Personally I like this a lot. Readability really improves substantially by using white space for method calls. The only thing that makes it a bit tricky is the interaction regular expression syntax. I ended up adding an initial character to regular expressions to make them easily distinguishable. I thought I would dislike that more than I do. So white space is definitely a win.

Keyword syntax in method calls

Having methods take keyword arguments and positional arguments baked in to the language was also a big win. It’s really a huge difference between this approach and something like Ruby - having it first class means it is easy to do things like collecting all keyword arguments, provide default values and so on. It also makes introspection and documentation much better. Finally, the duality if dictionary creation with keywords and regular method invocation ended up being very pleasing. Another clear win. Languages should have keyword arguments.

Nontraditional naming

I wanted to see what would happen if I stayed away from the traditional names in the object oriented languages of today. So I didn’t use Object, String, prototype, slot, clone or property. The most obvious place for this is in the core concepts of the language. The place where user code starts is called Origin. I’m don’t miss Object as such, but I’m not sure Origin is the clearest way of talking about this object. My current thoughts are going in the direction of something like “Vanilla” (from Flavors), or “Something”.  Another problematic renaming was to talk about the act of creating a new object as “mimicking”, and call the parents of an object “mimics”. It ended up being very confusing, both from a verb/noun standpoint, but also just from simply being to opaque. So that’s a definite failure. I’m still comfortable with “cell” instead of “slot” or “property”. I’m also happy with “Ground”, “Base” and “DefaultBehavior”. All of these communicate clearly what they should. I’m also happy about the renaming of “String” to “Text”. I don’t use the type name much in Ioke code, but when I do “Text” feels much better.

Numerical tower, and no real numbers

I’ve always liked numerical towers in programming languages, and it feels good to have it in Ioke. Ratios are also necessary as first class concepts. I also decided to not have real numbers, only the equivalent of BigDecimals. That was probably a good decision for Ioke, and I still feel real numbers are problematic. I don’t think removing them from the language is the right solution though.

Condition system instead of exceptions

The decision to adapt and include a condition system based on Common Lisp was definitely a success. I like the programming model and it makes code much more flexible and expressive. Clear win.

No global scope

This is also a clear win. It’s a tricky one in many languages do. You have to unify things to a high level to make it possible to get away from global state. But I think the benefits way outweigh the cost of this.

Specialized forms of code

Ioke have quite a few variations in runnable code. The main distinction is between things that are lexically scoped and things that are object scoped. Methods, Macros and Syntax are object scoped, while Blocks and Lecros are lexically scoped. This seemed like a good idea at the time, but if I were to do it again, I would try to unify several of those - at the cost of making the evaluation rules slightly more complicated. Especially having methods that aren’t lexical closures still surprises me regularily. I wonder if I was influenced by the way Ruby works when designing these parts.

Prototype OO

I’ve always maintained that properly implemented propotype based object orientation is both conceptually simpler and more powerful than class based object orientation. I still believe this to be true, and I still think prototype based is better than class based. However, there are some places where the model breaks down. There are some situations where it just makes sense to have a class that describes objects. Take numbers for example. In a prototype based scheme, what is the parent of the number 2? Is the parent the number 1? Not really. In Ioke I added a singleton object Number that is the parent of all numbers. But that still becomes weird since you could write code like “Number + 9″, and expect that to work. I’m not sure how to solve this problem. Of course, prototypes can represent classes without problem, but my problem is mostly what makes sense intuitively.

Ruby-like load/require system

For a language with a global scope and/or total mutability, it works quite well to just have things represented as scripts that will modify a shared environment when loaded. However, there are things that become cumbersome - parameterization of modules/files become very ad hoc, and there is a real risk of conflicting names. If I were to redo this part I would probably opt for something slightly less convenient but more powerful, that allow you to work with software modules in a better way. Exporting parts and keeping other parts private, parameterize modules, bind modules under different names, and so on.

 

From http://olabini.com/blog/2010/07/some-results-from-the-ioke-experiment/

Published at DZone with permission of Ola Bini, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Thomas Kern replied on Thu, 2012/09/06 - 11:01am

Did you consider having full language support for *both* prototypes and classes? That way you could choose whatever fitted the problem at hand. Ruby is oh so very close to having that, missing basically some syntax sugar and the ability to do self.new from within eigenclasses.

http://www.java-tips.org 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.