Past Meetup

LuvvieScript - with Gordon Guthrie

This Meetup is past

19 people went

Details

The old polyglot world of large software development teams supported by diverse operational teams no longer works. The current software environment demands teams that are capable of dripping software releases to the public by continuously deploying features. Modern teams are increasingly eschew normal operations support for DevOps - where the systems maintenance and monitoring is done by the software developers.

These ways of working are only possible where features can be delivered 'meat to metal' by the software devs - from human factors and design (usually in the browser) through to the server and load distribution infrastructure - down through persistent storage to the disk and back up to end user.

Traditional heterogeneous environments, for instance client-side javascript speaking to server side Ruby speaking SQL to persistent storage, are increasingly problematic in this world. Each transition between two languages creates an impedance gap which slows down development and debugging and (usually) fractures the teams. Node.js is an attempt to create an impedance-free development environment by having a common language (Javascript) client-side and server-side. Some people don't think bring the callback single threaded model to the server is wise. However the rise of support for source maps in the browser means that 'compile to js' languages are becoming viable options. Clojure Script has led the way.

LuvvieScript is an attempt to bring pattern-matching, event-driven, actor-based functional programming to the browser in a strict sub-set of Erlang (but not OTP!). The browser is intrinsically low concurrency (around 10ish 'things' on a normal web page) and needs only primitive restart semantics.

The production toolchain for LuvvieScript is to take a syntactically valid Erlang module compile it to core Erlang and transpile that to a valid javascript Abstract Syntax Tree (the Parser API from Mozilla). That JS AST can then be manipulated with normal Javascript syntax tools before being converted to valid Javacript with an associated source map using tools like ESCodegen. Additional runtime requirements (for instance dependent modules that require co-loading) can be specified using custom attributes in Erlang which enable the developer to arbitrarily annotate the Erlang Abstract Syntax Tree.

The resulting deployment environment will include an in-page client-side 'run-time' and a set of server-side Erlang libraries that will encapsulate the browser-server comms enabling the front and back-end processes to send each other messages transparently (and front-end processes to send each other ones too). The developer will no longer directly script the Dom - but operate on a client-side model which will be rendered to the Dom. In this world user actions (mouse clicks, key presses, etc, etc) will present to the developer as messages and have to be actively subscribed to - making for a recognizably 'gen server' style of client-side programming.

About The Author:

Gordon Guthrie has been programming since the (late) 1970s, was Chief Technical Architect at if.com (http://if.com/) - the Service Architect at the City of Edinburgh and more recently CEO/CTO of Vixo. He has only been programming Erlang for a single decade unfortunately.