TypeScript and new pet project

Around two months ago I started a new pet project. As always, I built it partly to solve a problem, and partly to learn some new language or technology. The problem I wanted to solve was showing images and maps to players when playing table-top role-playing games (and, while at it, manage my music from the same place). The language and technology were TypeScript and to a lesser extent ES2015. As always, I learned some things I didn’t quite expect or plan, like HTML drag-and-drop, Riot, a bit more Flexbox, and some more canvas image processing. The result is the first public version of Lyre, my program to help storytellers integrate music and images into their stories (especially useful for semi-improvised or interactive stories).

But the reason for this post is to talk a little bit about the technology. I admit that I haven’t really studied TypeScript thoroughly (I mostly learned bits and pieces while programming), but I think I like it to the point that it might become my front-end language of choice when I cannot use ClojureScript or similar.

So, what’s so great about it? Essentially, it’s ES2015 with optional types. The bad thing is that it needs special incantations to be able to use regular JavaScript modules, and in most cases you don’t have types defined for non-TS modules so you end up with type any for everything. The good thing is that it’s extremely familiar for people who know ES2015, because it’s almost the same, and that of course you can specify types wherever you want to. I am not the biggest fan of static types, but after trying it I think I really like the idea of optional types. Moreover, types in TypeScript are relatively open and feel like they fit very well in the JavaScript ecosystem. Two examples:

1. Apart from enums, you can create union types that eg. are as simple as a choice between two strings, like type Mode = “off”

   “on”.

2. Interfaces can be used to specify the properties, not just methods, that should be available in an object. Among other things, it’s possible to specify that an object should have certain specified properties plus any number of extra properties as long as their values are of a given type.

They have other interesting features, like union and intersection types, type guards for functions, decorators, generics and others things. I haven’t really used most of those, but I realised that I liked TypeScript when I was writing some JavaScript and found myself missing the optional types.

For actual editing I’m of course using Emacs, in this case with TIDE. Although the refactoring capabilities are very limited, the rest worked quite well and I’m very happy with it.

The other bigger thing I learned was Riot. Which, sadly, I didn’t like as much: I found it very confusing at times (what does this point to in the templates? it seems to depend on the nesting level of the ifs or loops), ended up with lots of rebinding of methods so they could be safely passed around in templates, and generally felt that I spent too much time fighting with it rather than writing my application. Now, some of these problems might have been caused by Riot-TS and not Riot itself, but still the experience wasn’t that great and I don’t expect to use it again in the future. Again, bear in mind that I mostly tried to learn on the go, so maybe I was doing everything wrong :-)

In conclusion, I love these projects because I end up with something useful and because I always learn a bunch of things. In this case in particular, I even learned a language that positively surprised me, even if I’m not a big fan of static typing. Again, if you want to have a look at the result, you can learn about Lyre and download the code from GitHub.

• games
• languages
• narration
• pet
• programming languages
• projects
• role-playing games
• rpg
• static typing
• typescript

First steps with Scala

So I had promised to write a bit more about my initial experience with Scala. Here it is.

In my previous post I had explained why Scala in the first place, and I had mentioned that almost all of my knowledge comes from having read a bit of “Programming Scala”. Some of my highlights:

• It has a REPL for experiments.

• Immutable variables (see “Variable Declarations”).

• Type inference (see “Inferring Type Information”).

• The Option type (see “Option, Some, and None: Avoiding nulls”).

• The handy import syntax (see “Importing Types and Their Members”).

• The flexible syntax that allows for DSLs (see “Methods Without Parentheses and Dots” and “Domain-Specific Languages”).

• The flexible for loop (see “Scala for Comprehensions”).

• Pattern matching (see “Pattern Matching”, and make sure you don’t miss the examples with types, sequences, tuples with guards or case classes).

• Traits (see chapter 4, “Traits”).

• The nice XML library that comes with Scala (see chapter 10, “Herding XML in Scala”).

And note that I haven’t read that much of the book. In particular, I expect to like a lot of things about the functional aspects of Scala (described in chapter 8, “Functional Programming in Scala”).

That’s about learning the basics of the language. When I tried to make a small application to access the Flickr API, things worked really smoothly, which is always encouraging: using scalaj-http for the HTTP requests is a breeze, and parsing the resulting XML to get the interesting pieces was also pretty straightforward. Another nice surprise was the ScalaTest library.

Only when I had to start writing a bit more “real-world” code, I had to use some Java libraries. And I have to say, that was by far the worst part of programming in Scala. I only had to make some very simple date calculations, but that turned out to take more or less as long as the rest of the code I had written. Or at least, much more frustration. To write that small piece of code, I had to learn some API that didn’t make any sense to me; it took me a while to find the right, non-deprecated way of doing things; and all along I felt that the designers of that API were more focused on how proud they were of their “correct”, decoupled design that on making it simple and practical for the actual programmers using that library. My impression of the JavaMail library wasn’t actually much better, but at least the first thing I copied and pasted worked well enough.

And before I finish, I wanted to mention a couple of things about tools. Although I’m currently using Emacs, I did give Eclipse and NetBeans a try. Probably those tools are not for me, so take my experience with a pinch of salt, but I found them really confusing or they didn’t work at all for some reason. However, Scala mode and ensime for Emacs worked well for my, for now, limited needs, and frankly, I’d rather stay with Emacs that having to edit code in Eclipse or some other editor.

I still have several things pending, like finishing the Scala book, trying out sbt, experiment more with ensime and the Scala mode and write a library to access the Opera Link API. But it looks like it’s going to be a lot of fun :-)

• languages
• programming
• scala

The quest to learn a new programming language

Some time ago I realised I wasn’t all that excited about any programming language. All the languages I knew were, for some reason or another, annoying and I didn’t really feel like having any pet projects. That, combined with the idea that learning new stuff is good, pushed me to try and learn some new programming language.

Choosing one was actually kind of a problem: it had to be “mainstream” enough that it wouldn’t just be a theoretical exercise (I wanted to use it to write actual code, not just to learn it) and yet different enough to what I was used to. It also had to be “stable” enough that I didn’t have to install it from sources or follow the development of the compiler/interpreter. That didn’t really leave me a lot of options, I thought. The only ones I could think of, really, were Haskell, Go, Lisp and Scala.

Haskell I had tried to learn, and I more or less failed. I did learn the basics and I tried to start writing a Sudoku solver with it, but I got demoralised quite quickly. I felt it was a bit too exotic for actual work, and it was a bit of a downer that it took me so long to write some simple unit tests for some basic code I started to write (I couldn’t get my head around the type system and I was fighting with something really silly for many hours). Go, well, I didn’t even start learning because the Go installation instructions totally freaked me out. Not that I didn’t understand them, but the idea of fetching the sources of the compiler just to learn a programming language turned me off. And don’t get me started with the name of the compiler (dependent on the architecture, no less!), the separate linking step or the 90s-style “.out” file name for the binaries. So that left me with Lisp and Scala.

Lisp, I did know a bit. I had learned some basic Lisp at the university, and liked it quite a bit back then. I had also read part of the excellent “On Lisp” and I thought it was really cool. I still had my doubts I could use for actual work, but I was willing to give it a try. So I borrowed the (also excellent) book “Land of Lisp” from a friend and started reading, trying to learn a bit. The process wasn’t too bad, but I had the increasing feeling that in the end it would be too exotic for me, and I found the syntax too annoying. I was learning some practical Lisp, but it was taking really long to learn interesting things. And when those interesting things came, I felt they were too obscure for me, and I needed a lot of thinking to even understand the examples. But I decided to give it a try anyway, and I went ahead and tried to write some simple code to use some web service (the final goal was to write some example code for the Link API). In this case, the deal breaker was that the OAuth library I found depended on an obscene number of Lisp packages, many of which were recommended to be downloaded directly from GitHub (srsly? fuck this shit).

That left me with Scala. I had mixed feelings about it. At a first glance it looked interesting, but it was compiled, related to Java and more or less centred on concurrency. I tried to learn Scala by reading “Programming Scala”, which turned out to be more fun and productive than I had anticipated. I’m considering buying the “dead tree” version, but I have so many books to read that I don’t know when I’ll do that. So, what did I like about Scala so much? It made me feel like when I learned Ruby: it had fairly powerful features (pattern matching, traits, type inference, others I forget about) but with a readable, easy to understand syntax. It’s like the Robin Hood of programming languages, stealing features only available in impossible-to-understand languages, and bringing them to the masses. It also felt good liking a statically typed language, I didn’t think that was possible for me anymore :-)

But enough for now. Some other day I’ll write some more details about Scala and about my pet project FlickrMemories.

• functional
• go
• haskell
• languages
• lisp
• programming
• scala