Visi

Latest and greatest from the Visi.io project

  • Visi.io Project Home
  • Visi.io Group
    • 0
      8 Jan 2012

      Visi the Language vs. Visi.Pro the platform

      • Edit
      • Delete
      • Tags
      • Autopost

      I want to draw a distinction between the Visi language and the Visi.Pro platform.

      The Visi language is an open source, MPL 1.1 licensed, collection of software and other intellectual property (documentation, etc.)  While I, David Pollak, am the only one currently working on Visi, I welcome contributions from others.  I am focusing my efforts on making Visi work well on iOS, Mac OS X, and in non-GUI mode on Linux.  I am doing this because I intend to build a tablet/cloud business with Visi.Pro (which I'll get to in a minute).  I have spoken with folks from ThoughtWorks who think Visi would make a great web development platform.  I agree and if these folks want to contribute to Visi or fork Visi and do a web platform based on it, very, very cool.  If folks want to do an Android version or a Windows version or any other version of Visi, I wholeheartedly support the efforts.  Why?  Because the value of a computer language is based on the network of users that know how to program in it.  I want to make Visi as ubiquitous as Excel.  I want every B-school student to think in Visi.  I want to see a sea of former PHP developers coding in Visi.  I aim to make Visi bigger than Java, bigger than PHP, bigger than any computer language, ever (yeah, I'm not being modest here.)

      Visi.Pro is a commercial venture based on the Visi language.  It is the thing that will ultimately help fund Visi development but also give folks a way to use Visi applications on this iOS and OS X machines, but to have a seamless cloud component to their applications.  One of the attributes of the Visi language is that it supports a migratory locus of computing.  You can move the computation around to suit the current data locus and other factors (thanks Ian Clark for the idea.)  Visi.Pro is a focused venture based on enabling a particular class of users who use a particular class of devices to do beautiful and amazing things.  I will gladly discuss my choice of platform with potential investors and potential large-scale customers and with Apple, whose blessing Visi.Pro will need to succeed on iOS.

      As we discuss Visi, you all will know that I have commercial motivations for my contributions to Visi.  But my contributions will hopefully not be the sole and exclusive contributions to Visi.  If you have a hankering for making Visi run on your platform of choice, be it open or not, please join the discussion, please contribute code, please make Visi more than I can ever make it by myself.
      • views
      • Tweet
    • 0
      5 Jan 2012

      Program lifecycle phases

      • Edit
      • Delete
      • Tags
      • Autopost
      We developer types have a couple of pre-set modes or notions about code life-cycles.

      If you come from the "dynamic" language school, the cycle looks something like:
      1. Sometimes use a REPL. Type lines of code into something and get answers.  You know, irb.
      2. Change the code and re-run it/reload the web page.  Does it work?  Cycle back to 1.  Cycle time: 30 seconds.
      3. Run some tests.  Okay, they pass.  Or maybe you ignore this phase.
      4. Commit the code to a repository.
      5. Maybe a Continuous Integration system does its thing.
      6. Publish the code to your user-base.
      If you come from C/C++/Java-land, life looks something like:
      1. Edit a bunch of files.
      2. Compile the code.
      3. Maybe run automated tests, maybe do some manual exploration of the code giving you the right answer. Cycle back to 1 a bunch of times.  Cycle time: 5 to 60 minutes.  Yuck.
      4. Commit the code to a repository
      5. Maybe do some Continuous Integration
      6. Publish the code to your user-base.
      If you come from Scala, Haskell, OCaml, life might look like:
      1. Mess around in the REPL or running code like scripts.  Cycle time 30-90 seconds.
      2. Build the code to be a module or a package or a JAR.
      3. Compile the module, package, or JAR, including running some tests.
      4. Integrate module, package, or JAR into larger application and see how well the app runs both with automated tests and with hand-use.  Cycle back to 1.  Cycle time, 1-5 hours.  Note that lots of work gets done at 1, so the cycle time is somewhat deceptive vs. other environments.
      5. Commit code to repository.
      6. Publish the code to your user-base.
      If you come from an Excel background, like might look like:
      1. Take a spreadsheet template that someone else built.
      2. Put in some data.
      3. Tweak some formulas. Cycle back to 2.  Cycle time, 10 seconds.
      4. Get done for the day and save the spreadsheet, hopefully not over-writing the prior version.
      5. Email the spreadsheet to co-workers.  Who will cycle back to #1.

      Depending on the descriptiveness of the type system, the act of compiling is also the act of running some tests.  Depending on the purity of the language/limit of side effects, more or fewer tests will be required.  Depending on the Cyclomatic Complexity that the language syntactically and semantically encourages, the number of tests will be more or fewer.

      And then there are the cultural norms.  One of the greatest contributions that Java made to good coding is the inclusion of JavaDoc as a core part of the Java platform.  JavaDocs were simple to write, simple to use, and the early cultural norms of Java coders included writing at least some minimal JavaDocs with the code.  It helped a lot that Java arrived along with HTML so that there was a common, low cost way to publish the docs.  But, none-the-less, JavaDocs made a hugely positive difference in terms of teams being able to document code.

      In thinking about Visi, I want to capture the quick cycle times of Excel, yet support Visi code in source repositories (structured, versioned sharing), good habits (writing tests and documentation), and safe publishing habits.

      I am currently debating making tests and documentation of public parts of Visi programs mandatory by default (although could be over-ridden by a flag).  This means that before you can share a Visi program (commit it to a repository), you must write documentation and tests.  The docs would be much like JavaDocs and the tests would be co-resident with the functions being tests... kind of design by contract style.  Although, given that Visi is a pure, statically typed, lazy language, a HaskellCheck style of tests will likely be the correct semantics rather than the Eiffel contracts that measure input and output values.

      So, what do you think?  Should Visi require tests and documentation by default?  How can we create the right atmosphere and cultural norms around Visi that make it super simple and super easy to start, super simple, super easy to cycle on models/programs, and also make sure there are the right norms so we wind up with a solid test mentality like the Ruby/Rails culture and a solid documentation mentality like the Java culture?
      • views
      • Tweet
    • 0
      5 Jan 2012

      What is Visi?

      • Edit
      • Delete
      • Tags
      • Autopost
      Visi is a new language... a "what if Haskell and Excel" had a love-child kind of language.  Visi is pure, lazy, just like Excel, yet Visi is statically typed, like Haskell.  Visi's syntax is beautiful, in a Haskell/Python sort of way, yet inviting to spreadsheet users.  Visi is targeted as a HyperCard-like language for the iPad and the cloud, but with a firm grounding in computer science that has evolved since the mid-80s.  Visi is built in Haskell and takes advantage of the GHC platform.  David Pollak, the inventor of the real-time spreadsheet, founded the Visi project which can be found at http://visi.io
      • views
      • Tweet
    • 0
      16 Dec 2011

      Wow... Visi works

      • Edit
      • Delete
      • Tags
      • Autopost
      Well, it's been a month since I announced the whole Visi thing.  When I announces, I had a barely functional type checker and inferencer and a barely functional expression evaluator.

      That's all changed in the last month.  As I've gotten my Haskell Foo on and gone with an existing implementation of Hindley-Milner type checking rather than trying to write my own from first principals, I've made a ton of progress with the Visi language.

      For example, Visi can implement Factorial:

      fact n = if n == 0 then 1 else n * fact n - 1
      res = fact 10 //  testResults [("res", DoubleValue 3628800)] . checkResults)

      The above code is taken right out of the Visi test suite.  Parsing, type checking, and computation works

      Visi supports inner functions.  Rather than having an explicit "let" in the Visi syntax, you can define a local function 'fact' is referenced inside the 'f' function.  The local 'fact' function is passed, partially applied, to the 'app' function and correctly applied:

      fact n = n & \"hello\" {-  propper scoping this fact is not the inner fact -}
      f n = {- Test partially applied functions -}
        fact n = if n == 0 then 1 else n * fact(n - 1)
        app n fact
      app v f = f v
      res = f 8 // testResults [("res", DoubleValue 40320.0)] . checkResults)

      Local functions close over scope.  For example, 'f' returns a local function that takes two parameters and references the 'b' variable and computes the product of the three variables.  The 'q' function applies 'f' to 8 and 'z' applies 'f' to 10.  WIth these functions, we can apply or partially apply the functions:

      f b = {- test that the function closes over local scope -}
        timesb n m = n * b * m
        timesb
      app v f = f v
      q = f 8
      z = f 10
      res = (app 9 (app 8 q)) - ((z 8 9) + (z 1 1)) // testResults [("res", DoubleValue (-154))] . checkResults)

      Note, too, the clean syntax.  No line-end characters.  No "let" keyword (although variable shadowing is possible and not yet flagged as an error).

      So, check out the tests to get a better sense of both the Visi language and the test harness that I'm using for Test Driven Development.
      • views
      • Tweet
    • 2
      12 Dec 2011

      Mmm... sweet tasty state monads

      • Edit
      • Delete
      • Tags
      • Autopost
      One of the really challenging things about Haskell is the lack of state... or more specifically, the lack of global state.

      In Scala there are a ton of places you can put state (stuff that's mutated across method invocations.)  You can use globals, thread-local variables (something that Lift makes heavy use of), and instance variables.  Here are some examples:

      Global:

      object MyState {
        private var cnt = 0

        def inc = synchronized {cnt += 1}
        def dec = synchronized {cnt -= 1}
        def getCnt = synchronized {cnt}
      }

      Instance variables are pretty much the same, except you have to pass the instance around:

      class MyState {
        private var cnt = 0

        def inc = synchronized {cnt += 1}
        def dec = synchronized {cnt -= 1}
        def getCnt = synchronized {cnt}
      }

      In Haskell, there's no mutability, so if you have a reference to a chunk of data, the data will never change.  In order to change the state, you must create a new instance, but any holder of the old reference see the old data.  In general, this is a GoodThing™ because you don't have to worry about state changing out from under you, but it makes accumulating state pretty difficult.  For example, if we want to count the number of hellos and goodbyes and accumulate the names of the people who said Hello or Goodbye, it's easy to do:

      val state = new MyState

      val greeters = List(("David", "Hello"), ("Archer", "Woof"), ("Annette", "Bye")).flatMap {
        case (name, "Hello") => state.inc ; List(name)
        case (name, "Bye") => state.dec ; List(name)
        case _ => Nil
      }

      At the end of the above execution, we have a list of people who have made greetings and the side effect of updating the state object with the net Hello/Bye count.

      In Haskell, without the State monad, we'd have to accumulate both the count and the names and then fold across them:

      list = [("David", "Hello"), ("Archer", "Woof"), ("Annette", "Bye")]

      gTest (name, "Hello") = (1, [name])
      gTest (name, "Bye") = (-1, [name])
      gTest _ = (0, [])

      acc = map gTest list

      sumIt (i1, n1) (i2, n2) = (i1 + i2, n1 ++ n2)

      summed = foldr1 sumIt acc

      As the state that we carry around becomes more complex, it.  Further, having to fold our result in sumIt is counterintuitive.  We've already done the calculation, why do we have to fold the pairs into the final result?

      There's a simpler way to carry state around in Haskell.  Here's an example:

      -- the stateful test
      sTest v = 
      do 
      i <- get -- get the current state
      case v of
      -- update the state and then return the value
      (name, "Hello") -> put (i + 1) >> return [name]
      (name, "Bye") -> put (i - 1) >> return [name]
      _ -> return []

      sAcc = (mapM sTest list)

      sSummed = mapFst concat $ runState sAcc 0

      In the above code, we're separating the state from the core name calculation.  The get function get the state into the variable i.  Depending on the greeting, we increment, decrement or ignore the state.

      Now, the thing that confused me for years about the State monad was where "get" was getting from and where "put" was putting it.  Well, it's like this, the State Monad is actually some accumulated functions that are "played" by the runState function.  sAcc function returns a bunch of functions.  The runState function takes that function and a seed value (in this case, 0), and plays the function to get the resulting information and the resulting state.

      The State Monad makes stuff like parsing and keeping state while parsing (e.g., the current count of AST elements we've encountered) is very powerful and makes Haskell code that is in effect imperative a lot easier to write.

      I recently tried to implement Hindley-Milner type inferencing without the State Monad and the code was nasty and complex with lots of state being returned all over the place (see https://github.com/visi-lang/visi/commit/cfe7d6fe5a6b25795a1c32ab2f18cfcbad1f9b54#diff-1 and all the atv, atv', etc. state) and then https://github.com/visi-lang/visi/blob/b8f06c73f66596af8333ab09d9528bada068a188/core/src/Visi/Typer.hs  Note that all the state stuff is handled in the State Monad rather than cluttering up the logic of the code.  I've come to really like the State Monad a lot... it makes me feel somewhat imperative while being functional. ;-)
      • views
      • Tweet
    • 1
      17 Nov 2011

      It was 20 years ago today...

      • Edit
      • Delete
      • Tags
      • Autopost

      It was 20 years ago today that I embarked on an epic computer journey that defined my life as a coder and a business-person.  On November 17th, 1991, I laid down the first lines of code for the Mesa spreadsheet.

       

      Mesa was a spreadsheet for NextStep and continues (without my help) to be a spreadsheet for OS X (which is the updated version of NextStep.) At the time I started coding Mesa, the spreadsheet category on NextStep was surprisingly crowded with an entry from Lotus, the amazing, but non-traditional Improv, and WingZ from Informix.  Additionally, a venture funded company was working on traditional, native NextStep spreadsheet called PowerStep.

       

      I built a company, Athena Design, while building Mesa.  We launched Mesa in August 1992 and within 6 months, Mesa was the dominant spreadsheet in the NextStep market.  While some called me a Lone Wolf, in fact Athena and Mesa were an amazing collaboration by a stellar team.  Put another way, I built Mesa and Athena with a little help from my friends (at this point, please start listening to the Beatles Sgt. Pepper’s)

       

      What was amazing about Mesa was we built it based on talking to spreadsheet users in the NextStep community.  NextStep sold heavily into financial services and those folks wanted to be able to tick real time data from Reuters and other data feed services, perform calculations, and trigger external events.  Mesa did this.  In fact, working with IBM and Reuters in the late 1990s, I discovered that Mesa was the original art for the “Real Time Spreadsheet.”  Additionally, Mesa was an early example of a spreadsheet component that could be embedded in other applications (maybe it was the first, although my friend Debby Meredith apparently wrote a Smalltalk spreadsheet that could be embedded as well.)

       

      While the Next, and subsequent OS/2, OpenDoc, Taligent, and Be markets were not large enough to support a growing company, what Mesa represented was that a small team of amazing people who listened to users and mixed in some of their own vision could fundamentally change the landscape.

       

      Five years ago, when I discovered Scala and started coding Lift, I made the decision, once again to eschew the status quo of MVC and, instead, learn from what users and developers need.  For the last 4 years, Lift has been the best web platform for building Comet, Ajax, and Secure web apps.  Lift has grown and evolved, yet the core decisions about how Lift worked have remained correct and solid, and users like Foursquare and the Guardian agree.

       

      Modeling Lift and Mesa on user-needs rather than machine needs is a different approach.  It’s an approach that centers the product on the user rather than the machine.  Sometimes the difference is subtle and sometimes it’s not, but in the end, and  as Kernighan and Ritchie taught us, people time will always get more valuable and computing cycles will always get cheaper.

       

      Now, today, 20 years to the day after I started my epic journey, I am launching into a new journey: Visi.Pro.

       

      Visi.Pro brings Cloud Computing to the rest of us.  Visi.Pro is HyperCard for the iPad.  Visi.Pro lets users build iPad/iPhone apps on the iPad (or Mac) and deploy them seamlessly across the Cloud including using Cloud resources such as persistence, data sources and data sinks.

       

      Visi.Pro provides a complete environment from language to IDE to run-time to data/app/component emporium.  Visi.Pro provides a complete environment for the rest of us to create interactive, powerful apps.  A video of the vision, a vision statement, and more can be found at http://visi.pro.

       

      Building Lift and the Lift community, I have realized that standing on the shoulders of giants is the best way to build something world-changing.  The best giants around as the folks who make up the open source world and a substantial portion of Visi.Pro including the language and much of the iPad code will be open source under an MPL license.  This means that if others want to build stuff off the Visi language, a language so simple and powerful that any Excel or PHP developer will be at home with it, they are welcome and encouraged to do so.  You can check out more about the language and such at http://visi.io Please check out the code and the community... please contribute back to the conversation and the code.

       

      Building Visi.Pro and Visi.io will be a long, tough learning process.  It’s going to be interesting to learn from the PHP and Excel users in the world.  It’s going to be great understanding the kinds of things business people and moms and teachers want to build on the iPad.  It’s going to be like skiing double-diamond black slopes to build an invisible type system into Visi so that the users are always guided to do the right thing.  It’s going to be spectacular to get the Program Language Theorists to work through a type algebra (yes, Visi will allow an algebra in the type system) along side a teacher describing a grading app.  But what will really generate a tsunami of joy is when people are able to build amazing, interactive, real-time, cloud-backed apps on their iPad.  I can’t wait for that day and I know it’s going to be a long, tough, and spectacularly rewarding journey for all involved!

       

      Before I ask you to join me on this journey... before I ask you to join the Visi conversation, I want to talk about some changes in me and how this will impact the Lift community.

       

      For most of my career, I have aligned myself with the dark horses and the lost kittens.  I bet on an ousted Steve Jobs and his Next platform.  I bet on OS/2 and OpenDoc when Windows was a better choice.  I bet on Jean-Louis Gassée and BeOS because he told great stories about RepoDepo.  I bet on Java and WebLogic in 1996.  I bet on Scala.  Some of those amazingly risky bets worked out and others, well, didn’t.  This time, I’m betting on the clear winner.  It’s clear that iOS will dominate the OS/computing landscape for the next generation.  It’s clear that the cloud and interconnected and partially connected computing will be the way it’s done for the rest of my professional life.

       

      So, rather than choosing the dark horse, I’m going to bet on the winner.  And rather than choosing an existing category and simply building the best technology for that category, I’m going to create a new category (or more properly revive a lost category... the category of “everyone can program this machine and make it beautiful” category.)  I’m going to fundamentally change the way people program for the iPad and the Cloud. I’m going to kick a dent in the universe.

       

      My commitment to Lift remains.  I love Lift.  I love the Lift community.  I remain in awe of the amazing committers.  I am stunned and amazed by the folks who have committed to using Lift and I remain committed to Lift and the folks who have adopted Lift.  For most of 2011, I have spent about 12 hours a week in the Lift community... working on the mailing list and closing tickets.  Most of this year, I’ve been doing Lift-related consulting and much of my contributions to the Lift code-base has been for my clients.  I will continue to spend 12 hours average a week in the Lift community.  What is going to change is that the tickets I close, the code I write for Lift, is going to be entirely community-focused.  It’s going to be based on what the community needs rather than what my clients need.  Longer term, I will find a way to make Visi and Lift play together.  They are both my children and I love them... although sometimes newborns need a little more attention than 5 year-olds.  The key change is that I will not be available to consult on Lift-related projects in the future.

       

      So... what do I want from you?  

       

      I want your brains.  I want your input.  I want your language ideas.  I want your app ideas.

       

      Are you involved with Rust, Roy, Haskell or other amazing languages?  Have you built stellar iPad apps like Codea and Blueprint?  Please join the conversation.  We can share ideas and together be more than the sum of our individual parts.

       

      Are you someone who wants to build something on your iPad?  Something beautiful and amazing?  Something that you can share via the cloud with others in real-time?  Something that sucks data from SalesForce, Twitter or a million other data sources or sinks on the Internet?  Please join the conversation.

       

      Visi.Pro is going to be a totally epic journey and I look forward to you joining the team and making Visi.Pro life-changing for millions of iPad users.

       

      Thanks!

       

      PS -- Visi.Pro and Visi will always be defined, developed and built with strict adherence to Apple’s policies about what it allows on the App Store and on the iOS.  Visi.Pro, like the amazing Codea or Numbers, is a development environment and interpreted runtime.  I welcome any public or private (at Apple’s option) conversation with Apple regarding Visi.Pro to clarify the iOS and App Store rules and to insure that what we do with Visi.Pro is done clearly on the correct side of the line and with Apple’s happy blessing because, at the end of the day, our goal is to empower iPad and iOS users to rock their respective worlds!

      • views
      • Tweet

    • Search

    • Archive

      • 2012 (4)
        • January (4)
      • 2011 (4)
        • December (2)
        • November (2)
    • Obox Design

  • Visi

    I'm a geek... always have been. I'm CEO of Visi.Pro and commit on the Lift Web Framework project. I wrote Beginning Scala. Done lots of other geeky things in my life. I'm also a dad. I live in San Francisco.

    2247 Views

  • Get Updates

    Subscribe via RSS