HCoder.org

First impressions of Elm

For my next pet project I decided to learn Elm. Elm is a functional language similar to Haskell, that compiles to JavaScript. These are my first impressions so take them with a grain of salt.

Syntax

Elm’s syntax is similar to Haskell’s. I had tried to learn Haskell a long time ago but failed miserably because I couldn’t understand the types. I did not find Elm’s syntax to be a problem, and it was nice and simple, especially compared to Elixir, the last language I had learned. However, I think it was the first time in my life that I wished I had had a small syntax description or guide before diving too deep into the language. For me there were two confusing things:

1. Sometimes I saw a bunch of words that were separated by spaces or by commas, and it took me a bit of time to realise that function arguments are separated by spaces, but elements in a list or similar are separated by commas.

2. Compound types that have more than one word, like List Int. That one is easy to figure out of course, but when I saw Html Msg I had no idea what it meant. I’m still not completely sure, in fact.

The first point in particular has an implication: if you use the result of a function call as an argument for second function you must enclose the first function call in parentheses. This all seems super obvious in retrospect, but when staring at code that uses a DSL-like library to generate HTML in a language you’re starting to learn… well, it would have helped to have the first point spelled-out. Example:

    ul []
     (List.map (tagView sectionPage)
        (ModelUtils.getSectionTags section))

Here we have a call to the function ul that has two arguments: an empty list and another list, namely the result of the call to List.map. Note how the whole List.map must be enclosed in parentheses: otherwise, it would be interpreted as a call to ul with four arguments, not two. In the same way, both arguments to List.map must be enclosed in parentheses, too.

Elm Architecture

Although strictly speaking you don’t have to use it, the Elm Architecture is a fundamental part of Elm. It’s the high-level pattern for application architecture when writing Single-Page Applications in Elm, the main usecase for the language. The pattern is very similar to redux and friends in React, but it’s nicer and more natural in a functional, statically-typed language like Elm.

In short, it means separating your application in sub-applications that have a model, a React-style view produced from the model, a set of messages the view can send, and an update function that receives messages and changes the model. Besides, Elm supports commands and subscriptions, which gives a nice, clean interface for WebSockets and other things.

Conclusion

Although I’ve been looking forward to going back to ClojureScript, and in particular learn and play with Om Next, Elm is certainly a worthy contender and totally worth checking out, especially if you’re using React and you want to go one step further.

I admit I did get frustrated now and then with the static types, and at first a bit with the syntax (see the two points above) and the indentation. However, all in all I enjoyed learning and using Elm a lot, and it feels very clean, productive, and just nice to program in.

The application I wrote was very small, though, and I didn’t quite get to explore patterns in how to split an application in several sub-applications. I did read a bit about it but didn’t get to use anything fancy.

And if you want to see what I built, head over http://rpg.hcoder.org/ for the site, or https://github.com/emanchado/rpg-catalog for the code.

• elm
• frontend
• functional programming
• programming
• programming languages
• web
• webapp

First impressions of Elixir + Phoenix

I had been curious about Elixir for some time. After all, the promise of having the best of Erlang with a more palatable syntax was very attractive indeed.

A couple of days ago I finally finished a small project in Elixir using the Phoenix web framework, which is a sort of “Elixir on Rails”. These are my first impressions of both Elixir as a language and Phoenix as a framework. Take all this with a grain of salt: most of it is pretty subjective, and it’s from the perspective of a total Elixir/Erlang noob.

Elixir

I used Introducing Elixir for learning, which turned out to be a bad choice because it can feel like an intro to functional programming using Elixir, not so much an in-depth book about Elixir for someone who knows functional programming. In fact, the book preface says:

If you’re already familiar with functional languages, you may find the pacing of this gentle introduction hopelessly slow. Definitely feel welcome to jump to another book or online documentation that moves faster if you get bored.

Elixir is a bit of a mindfuck for me in that it looks like Ruby, but it’s not object-oriented at all. The language also seems to value convenience a bit too much for my taste (sacrificing simplicity or consistency). In particular, I find the extra, convenience syntax for symbols in maps extremely annoying:

%{"blah" => 1}  # string as a map key
%{blah: 1}      # symbol as a map key (instead of %{:blah => 1})

Another case of different syntax options is the if statement. These two are equivalent:

if x > 10 do :large else :small end
if x > 10, do: :large, else: :small

I seem to recall this has something to do with macros, but all that syntax sugar feels weird. And all those colons, sometimes before, sometimes after a word, look ugly and confusing to me.

I have other, smaller peeves, but they’re subjective or unimportant. However, they strengthened the impression that I didn’t like the syntax.

In conclusion, the syntax reminded me of ES2015: syntax and exceptions for convenience, which makes it feel inconsistent, complex, and hard to remember. It constantly reminded me of the fat arrow function in ES2015.

Phoenix

Phoenix came with its own, related mindfuck: it looks like Rails and often feels like it, but there aren’t classes. That confused me a couple of times, but I guess it’s just a matter of getting used to it.

I think I liked it generally, and it felt productive, but I also felt that there was too much magic and generated code. Not as bad as with how I remember Rails (from many years ago), but enough to make me feel uncomfortable. Also, take into account that my project was a perfect fit for the framework: a small, mostly CRUD application.

I did get to try both tasks and channels, which were really cool, for example with the automatic reconnect in channels (they are implemented using WebSockets) without having to write any special code.

Conclusions

It was interesting to learn Elixir, but I’m curious about Erlang now. As in, I like the concepts behind Elixir (which are mostly Erlang concepts) and I’m not in love with Elixir’s syntax, so if I had to build a system that needed that kind of scalability and reliability I would consider Erlang.

• elixir
• functional programming
• phoenix
• programming
• programming languages
• web
• webapp

Music Explorer

Lately I’ve worked on several small projects, mostly to learn new technologies. The newest one is music-related: a piano that shows scales and chords “in context”, to learn and explore music theory. The idea came about because my first instrument was the guitar, and music theory is pretty hard to make sense of when you’re playing the instrument. It’s just too hard to remember all the notes you’re playing, let alone realise when two chords in the same song are repeating notes because those notes might be played in different positions (eg. one chord might use E on the open sixth string, and another might use E on the second fret of the fourth string).

I remembered that when I started playing around with a piano, and I could figure out how to play a couple of chords, it was painfully obvious that they were repeating notes because they are in the same positions. In the same way, it felt much more natural and easier to figure out on a piano which chords fitted a scale, so I decided to write Music Explorer, and ended up even buying music-explorer.org to host it. I don’t have a particularly grand plan for it, but I’ll probably add at least some small improvements here and there.

If you are interested in the technical side of it, Music Explorer is written in JavaScript (EcmaScript 6, to be more exact). I learned to use React with JavaScript, Browserify, Sass/SCSS, Ramda, AVA, the fantastic JavaScript music library teoria and a bit more CSS while writing this so it was definitely a useful learning experience for me. The full source code lives in GitHub and it’s licensed under the MIT license so you can go have a look!

• chords
• es6
• free software
• javascript
• music
• music theory
• open source
• programming
• projects
• react
• scales
• web
• webapp

The ultimate TODO app

UPDATE: Bubug hasn’t been maintained for a long time and is now deprecated, sorry. The closest equivalent I have to a TODO application is Wiki-toki, my personal Wiki program.

I have been quite frustrated by TODO applications for some months now. They’re usually either too simple, or almost too complex and without features that I think are really valuable. In particular, there are two things that I don’t remember having seen in any TODO application:

1. Possibility to “postpone” a task, so it doesn’t appear in the main view for a defined time.

2. Possibility to associate a task to a “person to nag”.

When you have a lot of small tasks to do, and they are not the kind of things you put in a BTS (say, stuff that you have to do that is not really connected to some project’s code) I think these two features are really useful, and I was surprised that no applications I saw seemed to have those. I mean, don’t people have the same problems as me?

That’s why, as I had mentioned, I started writing my own TODO application: I’d have what I wanted, and I’d learn a thing or two about Merb, DataMapper and jQuery. The application has several design limitations that I used to simplify things, like not having any notion of users (single user app without authentication) or supporting only a “title” for the tasks, without any longer description. It isn’t something I really plan to publish for other people to use (I mean, the code is in my Darcs repo, I’m just not going to make a project page for it or anything like that), so I don’t really care how much it fits other people’s needs :-)

As it is a pet project and I didn’t really mind how long it would take to finish it, I started by making some mockup of the application in HTML (+ a bit of Javascript with jQuery), and once I was happy, I started with the actual design and code. I think some parts of the code are nice, and it has some Ajax sweetness, but I admit I haven’t used it yet for myself: only as a kind of underpowered BTS for the application. Maybe I’ll upload some screenshot some day. In the meantime, feel free to download and try it out ;-)

• merb
• projects
• Ruby
• todo
• webapp