Numerry's prototype

As many new projects, from scratch or not, prototyping is an essential step. For side projects, which are often small try-outs, a prototype is not needed as the project is the prototype. Numerry is a full fledged application, a collection of prototypes in a sort: the graph database, the web frontend, the backend with the server and the graph execution, etc. It’s manageable as a collection of prototype components, but it’s still, for a one-man army on his spare time, quite a challenge. What I need is a high level prototype to get the whole picture. This will allow me to get a better idea of what is needed, what is not, what can; to get a proper design and refine it.

Let’s start with the graph database. Currently, I’m wrapping my head around writing one, from scratch as well. Not the best idea to get a toy application of the door quickly. I’m thus opting for Neo4j, the default industry standard for graph databases. With this experience, I’ll be able to see what are the limitations I see, the workarounds I need to use, but also all the good and strong points this database offers; it’s not the standard without reason.

I’ve been listening to the Graphistania podcast for some time; you should try it, it’s very interesting. I subsribed to the Neo4j YouTube channel; I guess some good content is to be expected as well. I’ve already read one book about it. I have more in my SafariBooksOnline queue. I’m also attending a meetup next week in Amsterdam, organised by Neo4j. You got it, I dive into it. Despite my reticence to the JVM, it’s definitely the right decision for now. I need to get some practical experience on graph databases. See what works, how, understand the workflow, how to deploy it on production: I need to fully understand the paradigm of graph databases if I want to write a one to get to the core of the problem; or maybe I won’t and stick to Neo4j.

Haskell is a fantastic language for prototyping. If it compiles, it shows that I’m on the right track, that what I want to do is likely to work, and that I have the right pieces, in order. Yet, I am still wondering of which Javascript tool to use for the frontend: GHCJS, PureScript, Elm, Snap templates and plain javascript?

This Tuesday, as every first Tuesday of the month, I was at the Functional Rotterdam meet up. There we did a new coding dojo, using Haskell. It was fun, as always. I still had in mind the Why closure? video from one of the organiser, Vijay Kiran, which accentuated my attention on Clojure. We decided that next time we’d do a Dive into Clojure session. That’s very exciting! So exiting actually that I decided on my way back home to write my prototype in Clojure(Script).

Let’s thus pause Haskell for a moment and get some Clojure fun. don’t ask me why Clojure, I’ve just given you the link to a good video above! Jokes aside, I’m going to explain in more details why I choose it for my prototype.

First, I’ve always been curious about Lisp. When I was looking for learning functional programming, I looked at Emacs Lisp of course, then Common Lisp, then Erlang because I’m a CouchDB fan, then Haskell that got me. Building a prototype is the perfect opportunity to learn a dialect of Lisp, get the language, in particular the famous data-as-program and the legendary Lisp macros. I’ll also be more confident toying around in Emacs Lisp.

Second, and don’t fall out of your chair, I chose it because it’s dynamically typed. I know it’s going to bite at some point, but I hope I won’t reach that point with my prototype, and just enjoy the easiness of dynamically typed languages. The transparency between Python dictionaries and JSON is something I still enjoy when programming in Python.

Third, ClojureScript. I keep hearing a lot about it, it looks very promising; now it’s time to see it in action. Then I can make a better decision for how I’m going to implement the front end of the real version of numerry. I don’t know that much about it, but I’ve heard only good things about it. Make me even more curious.

Fourth, the JVM. Not that it’s attractive at all, but I felt like I should at one point in my career bite the bullet, and get more familiar with it. See and experience the ecosystem, the libraries, and the tools. I write native code at work and outside work with Haskell, I’m curious about what using the JVM brings, if it’s as interoperable as it claims, what are the performance penalties, etc.

Fifth, the community. The same, only heard good things about the Clojure community. The few Clojurians I know are nice, smart and welcoming. That’s really what made me giving Clojure a shot. I’m sure I’m not going to regret it.

One last point. Using a different language than Haskell will force me not to reuse it, which is the whole point of making a prototype. I’ll switch back to it for the real application, with hopefully a good solution for the front end and the database. If you see me writing that I keep it for numerry, please shout at me, and if you’re around Delft, get me to Doerak to pay for your next rounds of Dutch craft beers, I’ll be the one thanking you.