My post from last week generated some interesting discussions and reactions, but one in particularly grabbed my attention.
Both Stephen Haberman and Tom Davies made the following observation:
As far as Fantom is concerned, I doubt the successor of Java will lack user defined generics. Thats like going back to Java 1.4.
This got me to think. If I were to pick a different language than Java, would I be willing to give up user defined generics? Here is my answer:
Thats a fair point.
Personally, I wouldnt mind trading user defined generics if I get in return type inference, closures, traits, properties, actors, .net support and Javascript generation.
And user defined generics are on Fantoms road map, but I wouldnt expect them for at least one or two years.
Switching to a new language always comes with compromises, no matter how superior you think that new language is. Even if it beats your current language on every point, you should expect to lose some productivity because of lacks in other areas, such as tools, support, documentation, community, compiler bugs, etc…
Fantom is no exception, and actually, due to the very design goals and Andy and Brian set for themselves when they created it, Fantom made some tough compromises in order to keep the language manageable. And user defined generics are one of the casualties.
Note that Fantom supports implicit casting, which contributes to cutting down the verbosity of the code when you are dealing with raw user types, but obviously, this doesn’t buy you any safety compared to user defined generics.
By the way, as the name implies, “user defined generics” means that Fantom does support some limited form of genericity: only List, Map and Func are generic. Therefore, your collections remain typed but you no longer have the option to create your own class Node<T>.
Is it a big deal?
I would miss them, because I do use them. A quick look at the TestNG code base shows about twenty generic classes out of nine hundred. That’s less than 2%, and TestNG is a framework that exposes a substantial API. But there is no question that these classes increase the robustness of the API and of the client code that uses it.
However, I feel that I would use the other features that I would gain from Fantom a lot more, especially properties and closures. I wouldn’t be surprised to find out that I could use at least one of these features in all the nine hundred classes. That’s a lot of benefit right there.
How about you? If you had to drop one feature from the following list:
- User defined generics
- Type inference
- Closures
- Traits
- Properties
- Actors
- .net support
- Javascript generation.
Which one would you do without?
#1 by Jeremy Norris on March 1, 2011 - 3:28 pm
I would drop .net support and Javascript generation since these seem orthogonal to language design and could be added later. Actors could also be dropped if I was moving to a language that could implement them in a “native” way in a library (eg: Scala).
I would have a hard time giving up Scala’s “scalable language construct” philosophy. I find this “feature” extremely compelling.
In your opinion, what do you “give up” when you choose Scala?
#2 by Casper on March 1, 2011 - 10:27 pm
User defined generics, due to the 80/20 rule and KISS.
#3 by Wouter Lievens on March 1, 2011 - 11:42 pm
I would build a language/compiler-environment that would make it easy to plug all this in as features. Why is nobody doing that?
#4 by Paul on March 2, 2011 - 1:52 am
.NET first, it’s useless to me specifically (so selfish reasons there) and then Javascript generation. As Jeremy says, that’s not essential to the language itself.
#5 by Adam Fitzpatrick on March 2, 2011 - 4:15 am
Focusing on features of the language itself (ignoring the .NET and Javascript support, for the reasons already mentioned, and Actors, which are, or ought to be, largely a library thing), out of your list of language features I would choose properties. They’re neat syntactic sugar, but that’s way easier to give up than any of the other features.
But if it had occurred to you to include inheritance on the list, I would’ve chosen that without a second thought.
It might seem like having generic list and map types is enough at first. But what if you want a queue or a stack? Shouldn’t they be just as type-safe and self-documenting as List?
I don’t really understand why you assert that implicit casts are a good thing. As it says right at the start of Fantom’s type system documentation, the type system is primarily about contracts. Implicit casts undermine that by silently neglecting to enforce the contract. In particular, the type system documentation says that “A coercion from a nullable type to a non-nullable is implicitly allowed, but is checked at runtime”. What is the point of supporting non-nullable types if the compiler silently accepts possibly null values? Or if you want to be free to sling objects around without these potentially unnecessary constraints being enforced, why implement a static type system at all?
Honestly, if Fantom appeals to you, look to Go instead. It’s similar except where it’s superior.
—-
Wouter Lievens: that sounds like Lisp. Not everybody’s cup of tea, but it works exactly as you describe, so people really are doing that.
#6 by Stephen Haberman on March 2, 2011 - 1:25 pm
Your list of features is pretty much already in order-of-importance for me.
Also, I missed that fantom has user defined generics on the roadmap–that’s good to hear. I thought I’d read (maybe awhile ago) that the authors were rather dogmatically opposed to them beyond the built-in Map/List types.
Only because I take every opportunity to mention them, I pine for boo macros, such as defining you own “class” keyword:
https://github.com/bamboo/boo/blob/master/tests/testcases/macros/custom-class-macro-with-method-override.boo
#7 by Cedric on March 2, 2011 - 1:32 pm
Stephen:
Not only are user defined generics on Fantom’s road map but they might actually come earlier than I predicted:
http://twitter.com/#!/briansfrank/status/42743095456051200
#8 by Eelco Hillenius on April 15, 2011 - 9:40 pm
Absolutely dotNet generation first. Still in doubt about JS generation.