Doing a PhD is an iterative process of doing something you believe in, questioning your belief and adjusting what you do so that you continue doing something you believe in.  This is similar to driving with a navigational app.  You start with some route it calculated at first, but then some unexpected traffic starts to accumulate, and the app  recalculates route for you.  This happened to me several times so far during my PhD, and it’s happening right now as well.

Can I Have This Without That?

Readers who follow my blog may noticed I have not posted “progress reports” on Cedalion2 for a while now.  I started these reports to force myself to dedicate time to that project.  That worked for a while, but then came life and took my time away.  Specifically, these were the preparations to SPLASH2016, which went great both in terms of presenting my research, for which the highlight was a demo of the FishTank platform, and in terms of the interesting talks I saw and more than that, the interesting people I met, people like Federico Tomassetti and Will Byrd.

But it was right after that, after seeing all the great work that is going on in the world of programming languages, that I started doubting myself regarding the direction I am taking with my research.

IMO, the most interactive form of presentation in a conference such as this is a poster.  It is not the medium that gives you the most exposure (that would be a talk at the right track, and this year the right track was SPLASH-I, where I held my demo), but it’s definitely the best way to get valuable feedback.  I presented a poster at the conference that gave the theoretical background behind FishTank: a concept my adviser and I call “Application Embedding“.  Interestingly, a common response I got was “can I have this, without that?” with “this” being FishTank, and “that” being Cedalion, or logic programming, or projectional editing.

If you Build It, Will they Come?

In the 1989 film “Field of Dreams“, Kevin Costner hears voices in his corn field saying: “If you build it, they will come“.  The meaning was that If he built a baseball field in his corn field, the spirits of many dead past baseball legends will come to play there.

When I started working on Cedalion, I had this voice in my head.  If I built it, if I built it well enough, if I wrote enough tutorials or make enough instructional videos and wrote enough blog posts and tweets, they (the user community) will come (to use Cedalion).  But this has not happened (yet).  Why?  That’s the million-dollar question.

I think Cedalion is the meeting-point of two unpopular notions: declarative programming and projectional editing.  I’m a big believer in both, but me believing in them does not mean others believe in them as well.  Most people in our profession use text editors to write software in imperative languages.  For the most part, the editors suck, the languages suck, we know it, but move on.  Why? Because they work. We are able to deliver, and we’re becoming better and better at it.  And there’s the first law of engineering: If it ain’t broken, don’t fix it.

Asking Tough Questions

Given the questions I got at SPLASH, I need to ask myself some tough questions:

• What is it I want to achieve?
• Which of my (academic) children do I love more? Which is more important, Cedalion or Cloudlog?

and even tougher questions like:

• What do I want to do with my life after I graduate?

The latter is important because it derives what I need to do before I graduate.   Is it all about getting the degree so that I could move on with my life? or is the PhD program a platform to help me build something I later want to pursue through employment in the industry?

What I Want to Achieve

My high-level goal is to democratize software.  What does it mean?  It means that I want to lower the bar people need to cross when they have an idea for an application that can make their lives or the lives of others, better.  Many share the same goal.  Programming languages such as Scratch make programming accessible to children (and interestingly enough, projectional editing is a big part of it).  Spreadsheet applications are actually programming languages making programming accessible to non-programmers in various professions (and interestingly enough, declarative programming is a big part of it).  So within this big goal of democratizing software, I am focusing on web applications.  I think web applications have a big role in our lives.  Today, the complexity of web applications limits the abilities of individual or even small companies to build useful, usable, scalable applications.  Democratizing this field will increase diversity and allow the little people have a say in the new world order that the Internet is slowly casting upon us.

As I see it, there are two dimensions in democratization of software: skill and effort.  Scratch and spreadsheets span the skill dimension, allowing people who are not trained as programmers, or hold a CS degree, to write software. I focus more on the effort dimension – allowing (skilled) developers to write software with significantly less effort than using traditional approaches.  With CS education being so widespread, I think it is valid to address effort as a first step, and skill as a second step.

Cedalion or Cloudlog?

Cedalion is intended to democratize programming languages.  Allow ordinary developers (OK, developers who know Cedalion…) to make their own language constructs and their own little languages (DSLs).  It’s hard for me to objectively assess how much skill is needed to do that.  Skill is not a single dimension as I tried to describe it in the previous paragraph, and I think people who wish to program Cedalion and create DSLs need to first unlearn many things in programming, such as imperative programming and textual editing.  But from an effort point of view, I can speak from my own experience that Cedalion gives a good balance between the effort it takes to define a DSL, and the effort it takes to use it.

But it could very well be that the skill it takes to define a DSL in Cedalion goes well beyond the skill it takes to program Cedalion. To define a DSL you need to first be able to imagine that DSL, and then be able to express its semantics.  I came to know many programming languages geeks during my short academic career.  For most of them, dreaming-up a language is not an uncommon thing.  But for the vast majority of programmers, this is not something they do often, or ever.  It’s hard to tell at this point how feasible this is going to be.

Cloudlog, on the other hand,  comes to democratize web applications directly (and not by democratizing programming languages).  It is based on an unconventional approach, in which the business-logic is stored in the database, alongside the data.  Like Cedalion, it requires a lot of unlearning, especially from people who are used to building web application in traditional methods.  However, unlike Cedalion, which sets the bar very high with regards to the skill you  need in order to make the best of it, with Cloudlog I believe the bar is much lower.  I don’t think it’s as low as to be used by non-programmers. You need to understand your business logic, and know how to express this knowledge in a formal language.  But I believe it’s not as hard as specifying a language.

So I think it makes sense to try to separate Cloudlog from Cedalion.

FishTank.js

Along these lines I did a thought experiment, trying to design a system I called FishTank.js. As the name suggests, it’s the FishTank platform, programmable in Javascript.  FishTank is an implementation of the Cloudlog data language, but Cloudlog rules allow code in a general-purpose language to be given as guards.  For example, indexing of facts based on text can include keyword extraction from the fact, which needs to be implemented in a general-purpose programming language.  The original FishTank prototype uses Cedalion as that language (so Cedalion DSLs can be used).  In the hypothetical FishTank.js, Javascript is used for this purpose.  Javascript is not the best language for this kind of things, but it is not the worst.  It is, however, very popular (#8 according to this ranking), and is very common in this kind of applications (e.g., the map/reduce logic for MongoDB and CouchDB).  But, as I was thinking more and more about the details, the idea looked less and less appealing.

The problem is not as much in Javascript itself, but in its being a good fit for this purpose.  I don’t want to go into all the details here, but the point is that Javascript code integrated into Cloudlog would not be pretty.  This made me look for an alternative language.

FishTank.clj

There are many programming languages that are (1) more popular and easy to learn then Cedalion, but (2) friendlier to the concepts of Cloudlog than Javascript.

Recall that in Cloudlog, the code (the business-logic) is data, stored on the database.  This is the flip-side of the “code as data” principle that guides many programming languages (including Prolog and Cedalion, but not Javascript). These so-called “homoiconic languages” are languages that have rich literals for expressing structured data, and use these literals to express code.  Javascript has literals to express arrays and objects, but it’s hard to imagine writing a program with them.

The LISP family of languages was where homoiconicity started.  Today, Common-Lisp, Scheme and Racket are different in many ways, but keep at least one thing in common: a program is a nesting of lists.  Clojure is yet another member of the Lisp family, built over the JVM.  It has a few interesting features that would make it adequate for being both the general-purpose language used in conjunction with Cloudlog (e.g., for indexing), and as the implementation language for a new version of FishTank.  These things are:

• Homoiconicity: OK, I’ve mentioned this already, but it’s a big deal.  We can define facts, rules and “logic” using the same base language.
• core.logic: A logic-programming DSL based on miniKanren.  It has a lot of interesting features, but most of all, it’s logic programming!  core.logic predicates can be easily and naturally play the role of “guards” in Cloudlog, and implementing them can be done in either core.logic itself, or in plain  Clojure, in which case they get access to everything you can do in Clojure.
• Running on the JVM: It’s important if we want this as an implementation language.  Provides access to a wealth of third-party libraries and state-of-the-art JIT compilation.
• Persistent data structures: In Clojure all the basic aggregate types (lists, vectors, maps, etc) are persistent, meaning that changing them (e.g., replacing a value for a key in a map) results in a new object (e.g., a new map), and the old one is left untouched.  This has important consequences for multithreading — you almost never need to lock!  An example for where this is used is in the Datomic database, a database that by itself has a few very interesting ideas, but also demonstrates that Clojure can be used for implementing such systems.

Clojure is #50 in popularity, on the same ranking where Javascript is #8 – just on the edge of not being ranked at all. It’s ranked lower than Haskell (#23), Scala (#32), Lisp (#33) and Scheme (#39).  But it does have an active community, regular conferences and a wealth of libraries and frameworks.

Conclusion, or Lack Of…

I don’t know if what I wrote above is convincing or not.  For me, a proud father of two languages, letting go of one of my creations in favor of another one is a tough decision to make.  A lot of things are going in favor of Cedalion, and I’m not ready to give up on it so soon.  However, if I think there is a better chance to make a difference in the world by separating Cedalion and Cloudlog to two different solutions, so you can take one without the other, shouldn’t I take it?

I guess I have a lot of thinking ahead of me…