I have noticed a lot of Fan vs Scala lately. In some ways I guess that is to be expected since both languages are statically typed alternatives on the JVM (unlike the dynamic languages such as Groovy, JRuby, Jython, and Clojure). But just remember that we are all on the same team trying to advance the state of JVM languages - we share the common goal of convincing Java programmers that there are alternatives to the Java language itself.
I think Scala is a really great language and I'm always on the lookout of good stuff to steal from it. But I do believe there are some key philosophical differences which I haven't really seen talked about. Note I haven't used Scala to write any production code, so I am not an expert by any means - but I do try to keep up with it.
Both Fan and Scala are trying to take software scalability to the next level, but I think we are taking different paths to get there. Scala's focus is clearly on a sophisticated type system which can catch as many errors as possible at compile time. It is also focused on mixing functional style with OO style (more so than Fan which only uses functional programming primarily as an enabler of better APIs).
Fan uses a static type system also - but as just one tool in the toolbox. Rather much of Fan's effort has been focused on overall architecture - more of a "cathedral" approach to providing a unified solution for all the different pieces required to build, test, and deploy software (yes I know IDE solutions are lacking, but I think this will take care of itself with time). This philosophy on the entire platform and the end-to-end programming experience versus just the language is reflected in Fan's features and even this site itself.
Its been long overdue, but we have finally posted 1.0.68!
There have been many breaking changes to the
dom APIs. This is in preparation for the development of a brand new UI toolkit called
domkit which we hope to open source later this year. Domkit replaces FWT as our toolkit for developing HTML5 user interfaces in Fantom. See topic 2466 for more details, and please review change log for list of changes.
I posted a new build and updated the online documentation - we had built up a huge amount of changes since the last clean build. No really big new features, but tons of small enhancements and fixes. Here are a couple of the highlights:
The dom pod API has received many enhancements, and will most likely be the center of a lot more development through 2015 as we continue to make Fantom a first class platform to target web applications.
The official Fantom hg repo is now hosted on BitBucket:
We looked at doing this a few years ago, but felt it wasn't quite ready. Since then its turned into a very nice platform. And more importantly, dramatically simplifies how we can accept and review patches. So hopefully this lowers the bar for contributions.
We are no longer pushing to
hg.fantom.org - and will be bringing that server down over the next week or two. So make sure you update your local repo to use BitBucket.
Its been almost a year since we actually posted a build with all the latest changes. So I figured it was about time to to get a clean zip with all the tweaks, fixes, and enhancements we've added over the last 10 months.
Google code doesn't allow file downloads anymore, so I posted this build on BitBucket.
Couple notable new APIS...
I've been in Santa Clara this week for the JVM Summit. It has been a really fantastic experience. The group of attendees was all insanely smart and deeply into language, compiler, and VM design. The nice thing about the JVM Summit was that it was small enough that you got a chance to meet everyone. So it was quite cool to finally meet many of the people who previously I've only known through their blog persona.
I have tons of notes and comments in no particular order...
All the talks were video taped, and supposedly will be available - but who knows when that will happen. I gave a short presentation Wed on Fan, specifically on how we tackle portability between the JVM and CLR. You can download the PDF slides here.
I posted a new build and updated the online docs.
This is mostly just a bug fix release with lots of fixes and minor enhancements.
Build 1.0.65 (20 May 2013)
How many times have you sat around trying to think of a good name for a class or concept in your software? Good names are concise and unique across the system. But lets face it, coming up with names really sucks. So over the years I've been collecting a list of words to spark my imagine (often leading me to thesaurus.com for further refinement). I've been scribbling this list on a tattered sheet of paper. But now I am going to start maintaining the list on this page and share it with everybody! The names in no particular order:
Kit Bag Cache Association Product Vector Dock PlugPoint Client Group Blade Transcript Server Mediator Page Share Builder Attach Bar Stamp Director Register Descriptor Parcel Manipulator State Selector Resolver Prototype Strategy Concern Find Clone Tactic Pod Discover Adapter Policy Capsule Learn Wrapper Cell Catalyst Routine Target Sage Sealed Pigeonhole Iterator Archetype Coalesce Baton Cursor Canonical Classifier Dialect Traversal Assembly Sieve Reaction Observer Backplane Tub Liaison Dependent Plug Depot Vat Publish Receptacle Tribe Promise Subscribe Bank Attribute Future Interest Document Facet Mint Aspect Deed Annotation Shard Any Part Meta Rendition Terminal Artifact Record Sketch Term Host Info Syllabus Variant Actor Manager Reduction Materialization Pathway Session Synopsis Relationship Responder Connection Verse Role Authority Exchange Stanza Relation Feature Memento Compass Preview Alias Token Blueprint Res (Latin obj) Bundle Solver Diagram Track Tracker Constraint Read/Write Sector Proxy Originator Encode/Decode Vessel Surrogate Caretaker Marshal/Unmarshal Behavior Shadow Housekeeping Inflate/Deflate Stimulus Subject Cluster Cue Request Ambassador Guardian Query Response Extent Orphan Morph Timeline Handler Zombie Digest Tag Command Struct Hive Operation Action Realm Media Narrative Transaction Domain Agent Bridge Interpreter Zone Dimension Abstraction Context Generalization Axis Implementor Expression Specialization Monad Composite Widget Envoy Pose Component Field Broker Interior/Exterior Leaf Property Portal Manufacturer Tuple Template Door Factory Decorator Visitor Gate Kind View Element Cyber Species Facade Entity Resource Mold Subsystem Node Organ Rule Flyweight Catalog Slice Event Colloborators Fragment Extension Trigger Aggregate Block <x>let Collection Segment Moniker
I have posted the latest build for download and updated the online docs.
The biggest feature in this build is what we have open sourced the webfwt. This is an awesome new pod that includes tons of FWT widgets designed for use in a browser making use of DOM and CSS.
Other than webfwt, this is mostly just a maintenance build with six months worth of fixes, tweaks, and minor enhancements.
I think when a new language like Kotlin is announced, every one's first thought is how is this different than X. In our case how is it different from Fantom?
I continue to be amazed by the proliferation of JVM languages. Part of me thinks this is a great thing. But at the same time, there seems to be a ton of work going into creating new things that don't seem have to meaningful differentiation. That said, I believe there is probably some very big philosophical differences between Fantom and Kotlin. I would say Kotlin is more akin to Groovy++, Gosu, or Java 1.8 with closures.
A language is as much what you leave out as what you put in. But syntax sugar tricks don't define a language because you can always add stuff like that without changing the basic semantics of the language. What really characterizes a language is the basic approach to fundamental issues like the type system, OO vs function paradigm, immutability, concurrency, standard library, modularity, composability, etc.
So here are some of my thoughts about what I think are major differences between Fantom and Kotlin: