Visi Language Blog

Communications from the Visi Language Project

  • Visi 0.1.1 patch

    20 Apr 2012

    A quick patch to Visi

    @tylerweir got Visi into a state where it was not correctly parsing a model, so I added a catch around the outer-most model loop and if an exception is raised, the reason for the error will be printed on stderr.

    @puffnfresh discovered problems pasting code into the Visi edit.

    Those issues are fixed in Visi 0.1.1. And today, you can download Visi 0.1.1 and play with it.

    What is Visi

    Visi is a modeling language targeted at Excel and Access and HyperCard and FileMaker users.

    Visi is a statically typed, functional language that’s beautiful and easy.

    Visi is a language for the Cloud computing and a wide variety of devices.

    Visi is an open source project that you’re encouraged to participate in.

    Thanks!

    Thanks for the bug reports, guys.

  • Visi 0.1 for OS X

    18 Apr 2012

    Woo Hoo! Visi 0.1 is available for OS X

    I Love Shipping Software.

    And today, you can download Visi 0.1 and play with it.

    What is Visi

    Visi is a modeling language targeted at Excel and Access and HyperCard and FileMaker users.

    Visi is a statically typed, functional language that’s beautiful and easy.

    Visi is a language for the Cloud computing and a wide variety of devices.

    Visi is an open source project that you’re encouraged to participate in.

    What’s in this release

    The 0.1 release is a Mac OS X wrapper around the core Visi computation engine.

    You are able to define models, load them and save them.

    The parser will parse a model and send messages to the UI to update the list of sources and sinks (inputs and outputs).

    The type checker works correctly and will type check.

    The error display is just a raw “toString” of the error message, so there’s no nice IDE line number jump-to stuff.

    The only types currently supported are String, Number, and Boolean. Data structures and structural typing is not yet supported.

    The computation engine runs correctly such that you can updates sources (inputs) and the sinks will dynamically change.

    There are sample files in the distribution so you can see some basic examples of the code.

    Why this release is important

    The release demonstrates that anyone with Xcode 4.2+ and Haskell 7.4.1 can build the Visi code.

    The release gives people a chance to play with simple models and see how they work.

    Near Future

    On the UI side:

    1. Improve Error Reporting/Highlighting
    2. Dynamic updating of the model as you type
    3. Markdown model display so you can see real pretty models

    On the core engine side:

    1. Get data types working so you can define data and functions/methods to operate on the data
    2. Git integration so that GitHub becomes the place where models are stored and shared
    3. Finish support for structural typing
    4. ObjectiveC integration so that Visi models can define interoperate with OS X and iOS UIs

    What I want from you

    I hope you (yes, you) will download Visi and play with it a little.

    I hope you will join the conversation with questions and comments.

    I hope you’ll enhance the code.
    I’ll be at BayHac ‘12 this weekend if anyone wants to hack on Visi with me!

    Thanks!!

    David

  • Why Visi is written in Haskell

    24 Jan 2012

    Visi and Visi.Pro started life based on ideas I had when I was working on Apache ESME.  One of the key features of ESME, a feature I wrote in a couple of hours 'cause I was bored, was "Actions".  Actions allowed a user to declare what to do with messages that arrived in their timeline.  You could filter messages (only show 20% of the messages from my overly chatty co-worker).  You could email messages (if it's an @ message to me and it's from my boss, email it and text me.)  You could cause arbitrary actions by generating HTTP POST requests to external services based on certain criteria (post to Twitter all messages in my timeline with the #Lift tag.)  Actions made ESME different because it allowed a user (not a programmer) to define what to do as stuff flowed into their timeline.  ESME was an SAP ecosystem project and we imagined that items in your timeline would include events generated from ERP systems: shipping exceptions, sales events (closed an order, received payment, etc.) and using Actions to manage the events seemed like a really cool idea.

    ESME was and is based on Scala and Lift.  I do not think ESME could have been written in such a short time with such a small team back in 2008 with any other technology.

    I wanted to start an exploratory project within the then incubating ESME project and see what we could do to create an event based system and event-based grammar for defining complex systems.  The Apache overlords where not happy with the exploration or the fact that I wanted to explore using Git on GitHub, so I shelved the project, but not the idea.

    For the next couple of years, the idea of an "event processor in the cloud that could be managed by anyone" rattled around in my head.  I've got pages in notebooks here and there about how the system could work, what the revenue models were, etc.  In June 2010, I wrote a complete business plan for a cloud-based event management system.  Having revenue from users to pay for the service plus a cut of revenue from data feed providers (a model influenced by Apple's App Store) seemed to make sense.  At that time, I envisioned the system was built on Lift and Scala.

    I got side-tracked in the summer of 2010 assembling a team and writing a business plan, etc. and I put the cloud event thing on the shelf.  I ultimately did not join the team that I assembled and by the time 2011 rolled around, I was up to my eye-balls in family stuff.  My wife went away to run a trial for 4 months (she won $310M for her client) and my mom passed away.  Sometime in the Spring on 2011, I bought an iPad for the kids so they could watch Sponge Bob and other stuff on the flights down to visit my wife in Southern California.

    The iPad changed my world-view on computing devices.  The iPad is, in my mind, the first material change in the way people use computing devices since the Apple ][.  Everything between the Apple ][ (the IBM PC, the Mac, laptops, netbooks, etc.) were incremental advanced on the technology that preceded them.  But the iPad was different.

    It was in May, after I had spent a week with an iPad and no other computing device, that I realized that PCs and the Web were legacy.  This isn't "disappear tomorrow" legacy.  This is "in 15 years, most people will not starting new web app project" legacy.  Just like client-server is legacy, but there's still plenty of Windows-specific client-server code being written.

    It was in May that I added "and a client component that runs on the iPad and iPhone" to my "event processor in the cloud" idea.  Having a client component, a beautiful, rich, interactive, tactile, wondrous client component because the driving force in my thinking.  Chatting with folks like my friend Bill Fernandez (Bill also did some amazing work on ESME) about the idea drove my thinking to making a programming system like HyperCard that was useable by lots of people.  Given my spreadsheet background, especially my real-time spreadsheet background, gave rise to ideas around how to imagine a language for describing event processing and user interactions and such.  Those ideas crystalized into Visi and Visi.Pro.

    One of the gating factors with iOS, the operating system on iPad and iPhone, is that there's no JVM or anything JVM-like.  There's only native code (well, there's LLVM as well, but the Scala-LLVM project is not that far along.)  So my choices of language for the project were reduced to things that compiled to native code.  I no longer have interest in manually managing memory and I like functional programming... it's how my mind has been re-wired.  Plus, I'm a statically typed kind of guy... that meant that my language choices boiled down to OCaml and Haskell.  Both had ARM cross-compilers and both were mature languages with mature ecosystems.  Sadly, because Scala is still the language I'm most comfortable with and the language I'm most productive in, I could not use Scala for Visi.

    OCaml is arguably the easier choice for Visi.  It's conceptually a lot closer to Scala than is Haskell.  The iOS cross-compilation tools for OCaml are much more mature than those for Haskell (although Stephen Blackheath's GHC-iPhone is coming along very nicely.)  Interacting between OCaml and ObjC is much easier than any Haskell/ObjC bridge.  Unfortunately, as many times as I try and as much excellent encouragement I get from Paul Snively, I just can't get into OCaml.  I don't know why and it's purely subjective and it's probably something broken in my brain... but OCaml always feels like an ill-fitting scratchy wool sweater to me.  This is not meant as a criticism of OCaml, but I don't like eating brussel sprouts either... it's just a taste thing.

    So, that left Haskell for me.  Haskell has some really helpful stuff.  The Haskell parser-combinator library is excellent and mature... helpful for writing a language.  Haskell's runtime is amazing in the way that computations (threads) can be suspended nearly costlessly.  This makes as lot of the stuff in Visi easy to write... basically some of the computation logic (including laziness) is already built into Haskell, so rather than writing a lot of the pieces myself, I get them for free.  The cost with Haskell is that pure, lazy, monadic is hard and slow and long-slogging (although it's proved remarkably solid.)

    I revisited the Haskell vs. OCaml decision last week because Paul kindly spent a lot of time discussing the strengths of each language/runtime.  But at the end of the day, Haskell keeps proving itself the right choice for Visi.

    I hope that going through the history of Visi and Visi.Pro and the choices I made in the system and in the tools will help folks understand why Haskell (okay, there's no compelling Haskell vs. OCaml argument that I've made) and more importantly why the choice of platform dictated a language choice other than the language I am most comfortable in: Scala.  Put another way, this is the first time since I wrote Mesa in Objective-C and C++ that I was not serially monogamous with a language. ;-)

  • Literate Visi

    13 Jan 2012

    In master, Visi is now a literate programming language.

    Visi models (models are descriptions of business logic as well as sources of input and sinks to output) are valid GitHub flavored Markdown documents.  Any code blocks (delimited by a line starting with ```) are considered Visi code and are parsed according to the Visi grammar.  Anything outside the ``` blocks are regular Markdown.

    Why is Literate Programming important?

    Programs and models and other things that instruct computers how to work are stories.  They are stories we tell our future selves or other people.  Part of the story is the description of what the computer is supposed to do, but another, much more important part of the story, is why.  Why did we write the code?  Why should someone care about the code?  Why did we make certain choices in the code?

    Literate Programming allows us to write a story and wrap that story about the business logic of our program.

    What are the two main complaints about spreadsheets?  They are hard to audit and they are hard to understand.  Visi is a language that replaces the row/column relationship language of Excel-style spreadsheets with a more natural, descriptive way of associating input to output, defining the logic that transforms input to output.  Wrapping prose *around* the model rather than embedding the prose in comments in a program or a model makes the prose the focus of the eye and hopefully the focus of the authors thoughts.

    Literate Visi allows the generation of documentation, HTML or PDF or otherwise, directly from the models themselves.  They are the documentation.

    I'm working on the test harness for Visi so that as the language evolves, the tests will evolve as well.  The harness will read models from a directory and those will be the test.  But, BUT, BUT they will also be documentation for the language itself.  Visi's tests will turn directly into HTML that will serve as the language's natural tests and documentation.

    I'm stoked about this!

  • Visi the Language vs. Visi.Pro the platform

    08 Jan 2012

    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.

  • What is Visi?

    05 Jan 2012

    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

  • Program lifecycle phases

    05 Jan 2012

    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?

  • Wow... Visi works

    16 Dec 2011

    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.

  • Mmm... sweet tasty state monads

    12 Dec 2011

    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. ;-)

  • It was 20 years ago today...

    17 Nov 2011

    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!

>> @visi_io's Tweets: