Welcome… and some notes and priorities

[David Pollak]

Folks,

Welcome to the Visi.io open source mailing list.  To the 20ish folks who have headed the call of Visi.io in the last 24 hours… THANK YOU!

A little bit of a sidetrack…

One of the amazing things about Smalltalk is the elegance and beauty of the Smalltalk language and the amazing integration between the language, the IDE, the environment, and the GUI applications.  They feel as one.  It's my opinion that a huge part of Smalltalk's integration is that the developers had to use the tools they built with.  In this way, I'd like to get Visi.io to be an environment that we can use to enhance the environment as quickly as possible (this is a many-month "quickly") so that we're eating our own dog food.

With that being said, I think that GHC will continue to play a large part in the development of Visi.io.  Currently, the language parses to a typed lambda calculus-ish thingy.  On platforms that support it (Mac OS X, but not iPad), I'd like to figure out how to seamlessly migrate the code into input to some form of input into GHC such that Visi.io leverages the years of optimizations and amazing set of back-ends that GHC offers.

Here's a semi-ordered (no, wait, it appears to be more random) list of stuff:

• The code only compiles using OS X 10.6 with Xcode 3.2.5 with GHC-iphone built against GHC 6.12  That's a pretty fragile setup.  There's reportedly an LLVM backend for GHC 7.4.x which the GHC-iphone folks are cycling into GHC-iphone.  That should allow a unified set of cabal files, GHC versions, etc. so that we can develop and build using OS X 10.7 rather than the very fragile stuff that's currently implemented.
• I'd like to split the codebase up so that the core Visi language stuff can be integrated into the iPad app, into an OS X development tool and whatever other front ends people choose (some folks have contacted me about a web front-end to Visi which is nifty but not something I'm going to participate in until I turn my focus into Lift integration with Visi which will happen, but not in the next 12 months.)  This means some serious cabal stuff and build management.  I'd love to get a Cabal maven to help out with the build process.
• The type inferencer and type checker code is a mess.  I broke some of the type checker when I was trying to implement type parameters (which don't work either).  I need to work on this.  More generally, I tried to build a type inferencer from scratch.  I'm not sure that was the wisest idea, but it made me feel like a macho guy when I started on the project. ;-)
• Long term, I'd like to add type algebra to the type system so that the type system can support transformations like (Maybe Int, Maybe String) -> Maybe (Int, String)
• There will be two modes: coder and library author.  Coder mode will not allow for any type declarations and the error messages in coder mode must be super duper helpful (an order of magnitude better than the already awesome GHC 7 type error messages).  Library author mode will expose types explicitly, but a library author must sacrifice a chicken to get into that mode.  Put another way, coder mode should look and feel like Ruby or Python code, where library author mode should feel more like Haskell or Scala or Ruby meta-programming.
• Syntactically, I'd like to keep things very, very clean. I'd also like to support function documentation and tests right at the function definition location and I've been noodling with a default enforcement of requiring tests (xCheck style) and documentation for all public functions to force "good coding practice."
• The language syntax should be very friendly to partial compilation such that the IDE can do all kinds of analysis at development time, but not get stuck on minor syntax problems.
• I'm noodling on how to manage the dependency/data flow/type graph dynamically so that the cost of re-analysis for minor code changes is super quick so that Visi has the feel of a dynamic language.  Anyone with insights or research papers… please share.
• Visi will not be object oriented.  However, Haskell-style type classes offer some nice ways of unifying different data types. Built in pattern matching (including being able to pass patterns as parameters like Scala's Partial Functions) is a must.  But, so is syntactically simple field access).  The key place that OO plays nicely is in the whole dynamic message dispatch that ObjC/Smalltalk allows for.  Creating a lower/zero boilerplate mechanism to create per-data-instance behaviors so that GUI programming is Smalltalkish is a key goal.
• Like Clojure, Visi is based on immutable data structures and mutability is stored in Refs, but Ref boundaries can be compiler enforced rather than enforced via exceptions.  BTW… I think Clojure's Refs are the single most important advance in state management that I've ever seen.
• Developing Visi-based apps should be seamless like Smalltalk… this means sweet debugging and whole environment inspection.  However, as the code change velocity decreases, the code gets compiled into increasingly performant forms.  This means that changes to code are instantly reflected in the environment while the developer is working, but there's Haskell-level performance for normally running code.
• I need to go through the code and write Haddock documentation.  This is my highest priority.  More broadly, I am going to devote no more than 50% of my Visi-time coding.  At least 50% of my Visi-time will be spent documenting, writing, and communicating.  A key mistake I made in Lift-land was not setting a tone of communication.  While Lift code is awesome, the documentation around Lift, especially for newbies, is lacking.
• My Haskell code sucks… much the way my early Scala code sucks… I'm working through the idioms and have not yet found my groove.  I'm all for patches that teach a better style.

So, readying the above, one might say, "Dude… you're a lot of promises and not really far down the road… why should I waste any time on this?"  The answer is most likely that you should not.  Visi.io is a vision and some code.  The vision will get crisper and the code will get bigger and better.  But it will take time.  If you're looking for a solution today, tomorrow or next quarter, we're not there yet.  If you're looking for a place to have a conversation, grow, explore practical programing language theory, and influence the way people interact with computers, then please stick around.

Thanks,

David

PS -- As a process matter, Visi.io is going to be pure GitHub, wiki, tickets, pull requests and all.

[Sander Mak]

Cool to see your dedication to documentation! Have you looked at literate programming for Haskell? Seems like that could help with your 50/50 rule while staying close to the sourcecode: http://www.haskell.org/haskellwiki/Literate_programming

[David Pollak]

On Fri, Nov 18, 2011 at 12:52 PM, Sander Mak <sand...@gmail.com> wrote:

Cool to see your dedication to documentation! Have you looked at literate programming for Haskell? Seems like that could help with your 50/50 rule while staying close to the sourcecode: http://www.haskell.org/haskellwiki/Literate_programming

Thanks!

--

Visi.Pro, Cloud Computing for the Rest of Us http://visi.pro

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im