Pirates of the JVM Series

We’re sailing along in the Pirates of the JVM series with fair winds and a following sea. Today’s stop in the Functional Ocean: Lux! We talked with the creator of the Lux programming language, Eduardo Julian, about its advantages and disadvantages, its core principles, and more.

Our JVM adventure carries on today with a new stop in the Functional Ocean. We’ve been all over the map so far, with stops along the Functional Ocean and the Dynamic Sea. Today, fair winds and a following sea have led us to the tiny island of Lux, where the sun is always shining bright and the sunsets are gorgeous.

Lux – Background information

JAXenter: What was your motivation for inventing Lux? What does Lux have to offer that other languages fail to provide?

Eduardo Julian: I became frustrated at Clojure’s design and lack of types. On the other hand, Haskell had amazing design, but it still had some flaws I wasn’t comfortable with; and its meta-programming wasn’t as good as I wanted.

Working on Lux started from a desire to mix both Clojure and Haskell and get the best of both worlds. Since then, I have been constantly researching and coming up with new ideas for how to make Lux transcend its predecessors and become a truly great language.

Lux is a statically-typed Lisp, which is great for Clojure users who want to use a statically-typed language and Haskell and Scala users who want to use a lisp. It has great support for concurrency; offering promises, functional-reactive programming, software-transactional memory and the actor model.

Lux offers amazing tools for meta-programming, like having access to the compiler’s state, and having first-class types as data-structures. It is also meant to run in many environments and inter-operate with many different technologies (JVM, JavaScript, .Net, Python, Ruby, LLVM, and God knows what else).

JAXenter: Can you describe the core principles of the language (if possible with short code examples)?

Eduardo Julian: Lux has three main principles:

#1: Elegance over expediency

One of the things that turned me away from Clojure was that much of its design felt like a hack. There are many things I forgive about it, since they are the result of ideas which probably sounded great when they were originally conceived, but didn’t turn out so well later. But a lot of the flaws of Clojure, I feel, are the result of negligence, lack of research, and favoring short term practicalities over good design.

In Lux, I work very hard to polish everything so the design of the language and its libraries is the best it can be. I take very seriously all the feedback I get about things which could be improved, since I don’t ever want to feel like Lux isn’t achieving its maximum potential.

#2: Diversity over dogma

I believe nobody really knows how to write software.

We have a bunch of ideas and theories, but anybody who claims to know what the one true way of writing software is either a fool or a liar. Because of that, Lux takes the approach of providing tools to programmers, and leaves them with the choice of how to design their software.

Whereas Erlang forces actors on you, and Go forces CSP on you, Lux gives you promises, functional-reactive programming, software-transactional memory and the actor model.

Want to use ML-style modules? Lux has them. Want type-class style polymorphism? Lux has it (as of v0.5.0).

As a language designer, it’s not my job to tell you how to code. It’s my job to help you do the best work possible.

#3: Bottom-up over top-down

I believe that software is like an organism that grows over time, instead of a giant block of marble you’re supposed to carve into shape. Because of that, Lux greatly favors composable abstractions. Even Lux’s fundamental data-structures (variants and tuples) are composable, both at the type and the value level.

That means you can combine functions to produce data-types that the functions are not even aware of, through the use of combinators.

For example:

(type: PrivacyModifier #PublicPM #PrivatePM #ProtectedPM #DefaultPM) (def: privacy-modifier^ (Syntax PrivacyModifier) (let [(^open) Monad] ($_ alt (this! (' #public)) (this! (' #private)) (this! (' #protected)) (wrap []))))

In this example, I’m able to create instances of PrivacyModifier, by just combining individual syntax parsers that know nothing of that type.

JAXenter: What would a typical program with Lux look like? (if possible with code example)

Eduardo Julian: I mention 2 programs in the Lux repository that people can take a look at, if they want a sample of Lux.

Lux Tutorial – This one is a bit of a toy project that implements a TODO list. It’s rather quick-and-dirty, as its purpose is to demonstrate how to use some of the basic features of the language, and how to do some JVM interoperation.

Luxdoc – Luxdoc is a more serious program, since I actually use it to generate the documentation for the wiki. It’s very heavy on the meta-programming, so you can use it to learn some of the more advanced concepts in Lux, like writing functions that interact with compiler data or that compute with types (in this case, to generate documentation).

JAXenter: For what kind of applications/use cases is Lux well-suited? – for which ones it is not?

Eduardo Julian: Lux is meant to be a general purpose language, and it’s my desire to be able to use it for back-end, front-end, mobile and desktop development.

Also, being able to use Lux for distributed programming and Internet-of-Things is important, since I’ve worked on some of that.

With that said, Lux’s priority is not to be the fastest language in the world, so you might still prefer compiled-to-native language such as C and C++ for computation-intensive tasks and systems programming.

JAXenter: What is the current state of the language?

Eduardo Julian: Lux went from being something only I could use at the beginning of 2016, to something mature enough for other people to try.

The compiler is very stable, and the standard library has grown a lot, and is very high-quality.

I think Lux is finally at a point in which people can try it for writing real software.

JAXenter: How about your plans?

Eduardo Julian: For a long time I have been promising that Lux would run on multiple platforms, but the delivery of that promise has been delayed, since I always had several high-priority tasks that took precedence over that.

The 0.5.0 release was the first one in which I made good on that promise, by adding support for Android.

For 0.6.0, JavaScript support will be added, and I plan on porting Lux to one new platform per release, until I have achieved my goal of making Lux a universal language.

JAXenter: How can people interested in Lux get started?

Eduardo Julian: The best way to get started with Lux is to read the book, located here. I make sure to keep it updated with the latest in Lux whenever I make a release.

Also, people can join the mailing-list and the Gitter chat-room, where I can answer any question and provide examples and guidance.

Finally, anybody can contact me at luxlisp@gmail.com

Eduardo Julian has been a developer since 2008. He’s already researched a variety of programming languages, frameworks and databases. Eduardo is a versatile and adaptive programmer. He learns passionately and quickly and is hungry for all things new.

Don’t forget to check out the Pirates of the JVM series.