I’ll be one of the first people to admit that I have a small obsession with new and different computer languages. Part of this is likely due to the voice in the back of my head repeatedly asking "is there a better way to describe this"? Usually the things that invoke this the most for me are signal processing (or general math) and computer interfaces as most languages seem to produce verbose and hard to work with code. I spend a fair bit of time searching for more expressivity to ease these pain points and the desire to avoid other possible horrors such as the impedance mismatch that some languages have with basic tasks like string processing. So far I have been drawn past a large sea of languages ranging from C to lisp to erlang to haskell to tcl to ruby to matlab and a large, yet enumerable, set of other languages. Most of these languages don’t get too much use outside of some casual reading through the introductory tutorials and whitepapers on the language, but most of the time there is still some kernels of interesting ideas to be gleamed from the docs.

For each language I end up going through I just have to ask the question: "Does this fall into a niche that doesn’t already have a good enough language?" Most of the time the answer to that is no. go for instance seems to be a very well put together language with good development tools, but I don’t have any good use for it as almost all of my lower level programming cannot coexist with the non-deterministic garbage collection and higher level tasks seem to have better alternatives.

Right now I have three main languages that I’m stalking the news feeds of: Julia, Nimrod, and Felix. So without further adue here are some quick blurbs on those languages for any fellow window shoppers.

Julia - http://julialang.org/

Julia is a scientific programming languages that for my uses is a vastly improved reincarnation of MATLAB. It is faster, more expressive, easier to use, easier to extend, and it seems to have a more actively growing community to boot. In this context I can say that Julia is a heck of a lot more expressive in just having a much more formalized type system from matlab, which is greatly enhanced by the use of multimethods as a replacement for MATLAB’s approach of having untyped and optional arguments for every function.

The use of llvm in julia is unsurprising given that llvm is getting much more popular for writing compilers and just in time compilers, but in this case the gains are absolutely stunning. Depending upon the workload given to Julia either time is spent in very thoughly inlined and optimized llvm generated code or extereemely throughly optimized linear algebra systems BLAS/ATLAS/LAPACK/etc/etc. This results in code that is pretty quick and slowly getting a bit quicker. Loading packages isn’t the fastest thing as compilation is almost always running a decent batery of optimization passes, but it isn’t too bad. I’m looking forward to seeing the approaches here to dump out precompiled code in some sort of serialized/relocatable format, as this has been on their todo list for a while and I have not seen a concise example of llvm memory dumps yet.

For those who are unfamiliar with aforementioned multimethods, they are essentially a logical extension of function overloading in the context of hierarchical type systems. With these methods you can have a function with the signature

foo(type1 a, type2 b, type3 c)

And this function will be called if the type classes or the super type classes of a,b,c match the given set of types. When you start dealing with the various optimized containers this approach ends up working quite well and for the cases where this does not seem to quite work out there are union types as well as some form of generics.

At this stage of its development I consider julia to be very usable, though I do generally end up submitting a number of patches to upstream repositories while working on it. It does have the quality that it is fun to work on, so that is still a relatively minor complaint overall.

As per the metaprogramming here macros are a first class inclusion in the language and as such it is generally quite easy to work with the AST and rewrite things as needed. Notably this portion is lacking some major polish when it comes to debugging though, as there are many cases where errors will seemingly come out of the macro definitions and not their use. While that might seem minor at first it results in a lot more print() style debugging than you might otherwise desire.

I like this language enough that there will likely be some further posts here using it, though there are still no guarantees on the rate of these posts :p

Nimrod - http://nimrod-lang.org/

Nimrod is a language that falls into the general category of better C, and they seem to be doing a pretty good job at a few of the pieces and they have a relatively fast development speed. The compiler is fast, it has excellent metaprogramming capabilities, more multimethods, a flexible gc system, fairly easy to use C bindings, and an improved memory model for threading. Unlike julia I don’t actually have a set use for nimrod at the moment, but when I find one it will get some use.

For metaprogramming this language might have one of the best examples of writing a small, yet useful DSL that I have seen in some time (http://nimrod-lang.org/talk01/slides.html) The macro code is short and it does not have many surprises, the compiler takes care of the optimization quite well, and the DSL itself does not seem to require any additional oddities to make its description concise. After looking through this I was just reminded of common lisp’s cl-who, which similar to the example, defines another html rendering DSL. Virtually no language can rival common lisp’s flexibility when dealing with almost completely mutable parsing capabilities with it’s replaceable read-table, but it looks like nimrod can take care of a variety of real world applications

The manual mentions compiling to an avr target which indicates that it can keep a pretty low footprint when needed, though I’m not sure I’d put it there as they don’t clarify the memory footprints at the moment. If I’m packing something other than C on one of those tiny chips it might be AmForth as that one has shown itself to be pretty much the smallest interactive language that you can get on an avr with reasonable levels of interactivity.

I’m sure most programmers have at some point realized that multithreading is one of the quickest ways to make yourself a personal hell when coding a larger application. It is easy to get things wrong and very hard to fix them, but it is a needed element of programming to have good latency and bandwidth figures. The easiest way to avoid pain is to avoid pain is to make sure that data is shared very selectively and several languages have been emphasizing the use of channels to pass messages between threads to limit the contact of data. I first saw this emphasis with Go, but nimrod has this as a core philosophy going as far as to ensure that each thread has an entirely separate heap.

Felix - http://felix-lang.org/

I have been watching felix for perhaps two years now on and off. While I don’t think I’ll end up using felix for anything outside basic tinkering for quite some time it still is a very interesting language, though not necessarily for the reasons you might think after reading through the last two sections. In this case it is the development logs and mailing list discussions that keep me on a slow drip of news about this language.

Some of the discussions revolve around one of the more unique feature (IMHO) of the language, which is the fact that it actually maintains C++ interoperability, which is typically a very difficult proposition. This idea really catches my imagination as interacting with many of the GUI options out there requires C++ to get all of the subclassing done right. Yes, you can use things through smoke/swig and get a mostly working interface for languages like ruby/python/lisp, but none of those bindings have really felt satisfactory.

As per the mailing list itself, the language is almost entirely built by one person who seems to like tweaking all of the little details, so reading his postings feel quite similar to http://lambda-the-ultimate.org/ each a piece of what would otherwise be a small paper on language design. The language itself appears to be still quite malleable and all of the components are not really nailed to one way of doing things. This would seem to be a side effect of having a fairly small user-base. I also don’t think it is the most approachable language at the moment, as examples are sparse (though they are slowly populating) and it likely doesn’t help that I don’t have much of a history with ML based languages. However this is still a language that I’m going to be staring at for quite some time to admire all of the details.

I might consider hoping on this train if some really useful library pops up in part due to the fact that I think felix could end up creating a very nice and succinct model of programming. My basis for this can be summed up by a recently made comment on the mailing list by felix’s author "…​ You have to understand Felix accumulates grammar like other languages accumulate libraries .. because in Felix the grammar is PART of the library.". So, in conclusion I don’t understand everything going on with felix and that’s it’s appeal, a curiosity that I hope to see grow.