In August 2005, Andy and I started kicking around the idea of Fan. The basic problem that we felt confronted with was that anytime you start up a new software project you have to make this hard decision: to build with Java or build with .NET. If you are in the business of building software components, then it is an even tougher decision: you have to pick one half of the market.
Another trend not unnoticed was the drumbeat of alternative languages like Python or Ruby and how productive a developer could be with a more dynamic environment. Having built two dynamic meta-programming frameworks in my past, I know how painful using Java can be for such tasks. An avid Java developer for nine years now, I have been disappointed by Java's lack of progress. When progress did come with 1.5 it was only to play catch up with C# (competition is good). I think adding generics to the Java language pushed me over the edge - they hurt my brain they are so complicated and solve a problem that I never felt I had. I would have been much happier with a simple ?= Eiffel like cast-assignment operator just to remove the ugly casts from my code.
My personal itch is to create a programming environment that is more productive and more elegant. I find great inspiration in languages like Ruby and Boo, and to a lesser degree Python. But the fundamental problem that these other languages don't solve is to let me create software for what I consider the two development platforms of the near future: the Java VM and the .NET CLR. In the 90s developers had to pick their operating system: Windows or Unix (and a couple brave souls OS/2 or MacOS). Then Java and .NET came along and moved the question to a new level of abstraction. These platforms provide a hardened virtual machine with garbage collection and basic OS integration (like threading and IO). Plus both platforms support an enormous amount of existing software libraries for just about any problem in any domain. But just like Java negated the OS question, now something needs to negate the VM platform question. This is how Fan was born.
From the get go the main problem Fan attempts to solve is to let you create software that runs on both the Java VM and the .NET CLR. Along the way we would like to create a very elegant language that moves the abstraction bar up a few notches so that you can do more with less code. The JVM and CLR are alike in more ways than they are different. They are both are based on a strongly-typed object oriented type system. Like it or not that imposes a lot of tradeoffs on our new language design. Running well on both platforms imposes further tradeoffs. But the more subtle design tradeoffs require understanding the priorities of various angles of Fan on the JVM and CLR - which led to these rules:
Golden Rule: make it easy and fun to write pure Fan code against the standard Fan libraries which can run seamlessly across the JVM and CLR. The standard Fan libraries should be complete enough to solve most problems productively and elegantly.
Silver Rule: make it easy and fun to write Fan code against platform specific libraries so that Fan can used as a replacement for Java or C#. This is also an important goal for writing the portable Fan libraries themselves.
Bronze Rule: make it easy and natural for platform specific languages (Java and C#/VB) to call into libraries written in Fan. This is important and should feel as "natural" as possible, but not at the expense of the Golden or Silver rules.
brian Mon 5 Dec 2005
In August 2005, Andy and I started kicking around the idea of Fan. The basic problem that we felt confronted with was that anytime you start up a new software project you have to make this hard decision: to build with Java or build with .NET. If you are in the business of building software components, then it is an even tougher decision: you have to pick one half of the market.
Another trend not unnoticed was the drumbeat of alternative languages like Python or Ruby and how productive a developer could be with a more dynamic environment. Having built two dynamic meta-programming frameworks in my past, I know how painful using Java can be for such tasks. An avid Java developer for nine years now, I have been disappointed by Java's lack of progress. When progress did come with 1.5 it was only to play catch up with C# (competition is good). I think adding generics to the Java language pushed me over the edge - they hurt my brain they are so complicated and solve a problem that I never felt I had. I would have been much happier with a simple ?= Eiffel like cast-assignment operator just to remove the ugly casts from my code.
My personal itch is to create a programming environment that is more productive and more elegant. I find great inspiration in languages like Ruby and Boo, and to a lesser degree Python. But the fundamental problem that these other languages don't solve is to let me create software for what I consider the two development platforms of the near future: the Java VM and the .NET CLR. In the 90s developers had to pick their operating system: Windows or Unix (and a couple brave souls OS/2 or MacOS). Then Java and .NET came along and moved the question to a new level of abstraction. These platforms provide a hardened virtual machine with garbage collection and basic OS integration (like threading and IO). Plus both platforms support an enormous amount of existing software libraries for just about any problem in any domain. But just like Java negated the OS question, now something needs to negate the VM platform question. This is how Fan was born.
From the get go the main problem Fan attempts to solve is to let you create software that runs on both the Java VM and the .NET CLR. Along the way we would like to create a very elegant language that moves the abstraction bar up a few notches so that you can do more with less code. The JVM and CLR are alike in more ways than they are different. They are both are based on a strongly-typed object oriented type system. Like it or not that imposes a lot of tradeoffs on our new language design. Running well on both platforms imposes further tradeoffs. But the more subtle design tradeoffs require understanding the priorities of various angles of Fan on the JVM and CLR - which led to these rules:
Golden Rule: make it easy and fun to write pure Fan code against the standard Fan libraries which can run seamlessly across the JVM and CLR. The standard Fan libraries should be complete enough to solve most problems productively and elegantly.
Silver Rule: make it easy and fun to write Fan code against platform specific libraries so that Fan can used as a replacement for Java or C#. This is also an important goal for writing the portable Fan libraries themselves.
Bronze Rule: make it easy and natural for platform specific languages (Java and C#/VB) to call into libraries written in Fan. This is important and should feel as "natural" as possible, but not at the expense of the Golden or Silver rules.
Or to summarize: