This is a comparison of Fan against the list of the Next Big Language as produced by Steve Yegge. The needs to be taken with a pinch of salt as he favours dynamic typing, nevertheless it is a useful data point.
Rule #1: C-like syntax
Yes, Fan uses curly braces
Rule #2: Dynamic typing with optional static types
No. But thats not Fan's goal.
Rule #3: Perform about as well as Java
Yes.
Rule #4: Tools
Still not strong for Fan (Eclipse is the data point for better or worse), but Fan is still new.
Object-literal syntax for arrays and hashes
Yes
Array slicing and other intelligent collection operators
Range operator on lists
Perl 5 compatible regular expression literals
Not really.
Destructuring bind (e.g. x, y = returnTwoValues())
No. We've discussed tuples and found them unconvincing.
Function literals and first-class, non-broken closures
Yes (although its unclear what non-broken means)
Standard OOP with classes, instances, interfaces, polymorphism, etc.
Yes, although there are mixins instead of interfaces
Visibility quantifiers (public/private/protected)
Yes.
Iterators and generators
No. Not really discussed.
List comprehensions
No. Discussed and deferred to DSLs.
Namespaces and packages
Pods are hopefully a better solution.
Cross-platform GUI
Yes.
Operator overloading
Yes
Keyword and rest parameters
???
First-class parser and AST support
I'd say Fan has this, although I'm not certain
Static typing and duck typing
Yes.
Type expressions and statically checkable semantics
Yes.
Solid string and collection libraries
Fairly. Fan's collection story is still weak outside List/Map.
Strings and streams act like collections
Strings do, Streams don't IIRC
Rule 6: Multi-Platform
Yes.
So, looking down this summary, Fan does pretty well. There isn't anything I'd highlight that makes me say Fan is seriously deficient in any of these criteria.
heliumMon 26 Jan 2009
Keyword parameters would solve what you call immutable setters. Each immutable object would get a compiler generated methodcalled with that takes all it's public fields as parameter and has the current value as default value for that parameter.
So you could write
p1 := Point(4, 5)
p2 := p1.with(x = 9)
or whatever
f00biebletchMon 26 Jan 2009
Given Yegge's love of javascript, the feature set for JS 1.7 seems relevant to this post. It has python-esque "array comprehensions", and generators+iterators to boot. The destructuring assignment is quite nice as well. I guess I'm still pulling for list comps in Fan since "everyone else is doing it".
And JS 1.8 cleans up closures with optional braces and optional "return". They have clearly wrestled with the same things that are being discussed here, and also worthwhile to look at what they have decided.
JohnDGMon 26 Jan 2009
I was pretty excited to see ECMAScript 4. To have such a language available in every browser would have been an amazing thing. Too bad it got scratched.
Still, looks like 1.7 is going to get a few of those features.
brianMon 26 Jan 2009
Perform about as well as Java
As much as Yegge loves JavaScript, it is hard to imagine any of the scripting languages like JS, Groovy, Ruby, Python, etc ever reaching the level of Java performance. Not that performance matters a huge deal for many applications, but it means that most core libraries in those scripting languages have to get written in some other language for performance reasons.
jodastephen Sun 25 Jan 2009
This is a comparison of Fan against the list of the
Next Big Languageas produced by Steve Yegge. The needs to be taken with a pinch of salt as he favours dynamic typing, nevertheless it is a useful data point.Yes, Fan uses curly braces
No. But thats not Fan's goal.
Yes.
Still not strong for Fan (Eclipse is the data point for better or worse), but Fan is still new.
Yes
Range operator on lists
Not really.
No. We've discussed tuples and found them unconvincing.
Yes (although its unclear what
non-brokenmeans)Yes, although there are mixins instead of interfaces
Yes.
No. Not really discussed.
No. Discussed and deferred to DSLs.
Pods are hopefully a better solution.
Yes.
Yes
???
I'd say Fan has this, although I'm not certain
Yes.
Yes.
Fairly. Fan's collection story is still weak outside List/Map.
Strings do, Streams don't IIRC
Yes.
So, looking down this summary, Fan does pretty well. There isn't anything I'd highlight that makes me say Fan is seriously deficient in any of these criteria.
helium Mon 26 Jan 2009
Keyword parameters would solve what you call
immutable setters. Each immutable object would get a compiler generated methodcalledwiththat takes all it's public fields as parameter and has the current value as default value for that parameter.So you could write
or whatever
f00biebletch Mon 26 Jan 2009
Given Yegge's love of javascript, the feature set for JS 1.7 seems relevant to this post. It has python-esque "array comprehensions", and generators+iterators to boot. The destructuring assignment is quite nice as well. I guess I'm still pulling for list comps in Fan since "everyone else is doing it".
And JS 1.8 cleans up closures with optional braces and optional "return". They have clearly wrestled with the same things that are being discussed here, and also worthwhile to look at what they have decided.
JohnDG Mon 26 Jan 2009
I was pretty excited to see ECMAScript 4. To have such a language available in every browser would have been an amazing thing. Too bad it got scratched.
Still, looks like 1.7 is going to get a few of those features.
brian Mon 26 Jan 2009
As much as Yegge loves JavaScript, it is hard to imagine any of the scripting languages like JS, Groovy, Ruby, Python, etc ever reaching the level of Java performance. Not that performance matters a huge deal for many applications, but it means that most core libraries in those scripting languages have to get written in some other language for performance reasons.