There was already some investigation going on on using the Eclipse JDT API as the basis for a source to source translator which proved to be a wise choice in the long run.
Eventually sharpen was born and after a lot of love we finally reached a point where the translated c# code would look really good.
People would get really interested every time sharpen was mentioned but for several reasons it wasn't publicly available.
Until now. Hooray!
I'm really looking forward to what people will build on top of that.
But is it programming dominantly math? Or is it mainly human communication?
Maybe we swung too far to the the latter. I speculate that the current rise of functional programming can also be attributed to its liberating effect - one is no longer expected to attribute proper intent to entities before a program can be seen to make sense.
As a constant reminder of that I'm tempted to use a different font for my programming.
]]>With many many kudos to Avishay Lavie, Cédric Vivier, Daniel Grunwald and Marcus Griep!
What? - http://boo.codehaus.org/
Download - http://boo.codehaus.org/Download
Official irc channel - irc://irc.codehaus.org/boo
Have fun!
]]>
What a great experience.
A chance to interact live with a dear friend. Free Software, Hacking, Women, Futurama, McDonalds, love spreading, Militant Atheism, Monty Python, Douglas Adams and the French Way.
Had lots of interesting exchange of ideas with Massi, ranging from "extensible parsing through composeable PEGs with optimal performance" to Carlos Castañeda, Jesus Christ, meta-physics, religion and Pink Floyd. The Cryptonomicon really got me.
Got to put a face on Joachim and see how really cool Unity is.
Jeroen IKVM Frijters is a funny guy!
On Thursday I got to talk about db4o which led me to meet a few db4o users hanging around the conference.
Pedro Santos had an interesting question, how to monitor and control the usage of computational resources in a managed client/server application? In other words, how a sysadmin can make sure a specific client won't DOS the application?
For .NET servers running on Windows there are performance counters, what about Mono servers running on Linux?
I've also got to spread the gospel about boo for which I got a hugely positive response.
Thomas "Gaia" Hansen seemed to really get it and so we had lots of interesting discussions on how to take over the world boo style.
Jackson wants to hack on better nullable type support for boo!
Mark wants an extensible language where NullReferenceExceptions are impossible.
Miguel reassured me once again mcs won't be rewritten on top of the boo compiler infrastructure :)
The presentation material is here.
Looking forward to the next one. ]]>
I wish him the best of luck on his new crusade.
]]>"Assuming that you have no access to tooling, and you don't have the resources to built NHibernate-sque framework, how would you approach building a Domain Driven application on the naked CLR?"
The most interesting part of the question for me is "and you don't have the resources to built NHibernate" because it immediately goes to the seemingly basic assumption most people have these days that "Persistence => SQL".
While it might be certainly true that a relational backend is a given for most enterprisey scenarios it is certainly not true that all persistent applications have to go through the pain.
Once upon a time a team with 4 people (2 developers, 2 web designers) built the web content management system for the 3rd largest TV station in Brazil on top of System.Runtime.Serialization using the Object Prevalence architecture.
Yeah, skin naked CLR.
If your specific application can't afford keeping all its objects in memory all the time and you don't mind putting a little clothes on, there's db4o.
4 years later here I am finally implementing the idea in order to take boo's dynamic dispatching performance to the next level.
Before the optimization:
$ build/booi performance/duckoperators.boo int*int: 1.101584 list*int: 29.0217312 dynamicDispatch: 51.9484224 staticDispatch 1.4921456
Each line reports how long it takes to execute the described operation with dynamic dispatching 5_000_000 times (except the last line which executes the same operation as the line before it but with static dispatching).
The first line tells us that it takes 1.10 seconds for boo to multiply two integer objects using dynamic dispatching.
The second line says boo takes 29.02 seconds to multiply a List instance by an integer using dynamic dispatching (dynamic dispatch over static methods).
The third line which is the most interesting one for our purposes here says that boo takes roughly 52 seconds to dynamically dispatch 5_000_000 instance method calls.
We can see a huge overhead over static dispatching.
After the optimization:
$ build/booi performance/duckoperators.boo int*int: 1.101584 list*int: 27.755072 dynamicDispatch: 4.055832 staticDispatch 1.4821312
Niiiiiice.
So this first stab got it from 52 seconds down to 4 seconds. Not bad at all. A few changes and we'll have the same benefits for dynamic dispatching over static methods.
I hope this will have a huge impact on environments that rely heavily on dynamic dispatching such as Brail.
Unfortunately though this optimization is only available when building for the .NET 2.0 profile.
Soon in a source code repository near you.
]]>I've also been pair programming a lot. Another pleasure:
"Some jobs are too big to handle alone, or simply more fun when done with friends. Either case leads us into the fruitful and challenging field of collaboration. Artists working together play out yet another aspect of the power of limits. There is another personality and style to pull with and push against. Each collaborator brings to the work a different set of strengths and resistances. We provide both irritation and inspiration for each other - the grist for each other's pearl making.
We need to remind ourselves here of what is obviously true but not often enough said: that different personality styles have different creative styles. There is no one idea of creativity that can describe it all. Therefore, in collaborating with others we round up, as in any relationship, an enlarged self, a more versatile creativity."
I could quote the whole chapter but hey, do yourself a favor and get the book.
]]>