Programming languages to watch: LiveScript, Julia, Elixir
adambard.com
adambard.com
http://en.wikipedia.org/wiki/JavaScript#Birth_at_Netscape
Edit: It seems it is intentional:
"LiveScript was one of the original names for JavaScript, so it seemed fitting. It's an inside joke for those who know JavaScript well."
Though, I'm one of the ones who had the same kind of problem when Mozilla named their new browser Firebird (before becoming Firefox).
We have two presentations on languages targeting the Erlang VM, Elixir and Joxa, as well as other goodness...
(Disclaimer, I am the organiser)
http://www.cafepress.com/mostlyfunctional
(Shameless plug...)
We're based in the States, but the owner is a Brit. I'm sure he'd jump at an excuse to head back and do some recording in the UK.
Partial application is a technique where you take a function that requires n arguments, pass in the first one and get a function that needs n-1 arguments.
Currying is a technique where you take a function that takes n arguments and turn it into a function that can be partially applied. E.g. in Haskell it works with tuples as arguments. There is function 'curry :: ((a, b) -> c) -> (a -> b -> c)' and its counterpart 'uncurry :: (a -> b -> c) -> ((a, b) -> c)'.
add3 = (a, b, c) --> a + b + c
x = add3 1
y = x 1
z = y 1 # z = 3
The main difference between the two I see is that partial application basically binds a certain argument to a fixed value, while currying only changes the way the function is called (thus allowing for easier partial application). It is easier to see on a function with more than two arguments. Imagine f:(A×B×C)->D. Currying it will yield f':A->(B->(C->D)), so you would call it as f'(1)(2)(3). On the other hand, partially applying on first argument it would yield f'':(B×C)->D.
[1]http://joearms.github.io/2013/05/31/a-week-with-elixir.html
Lisp Flavoured Erlang:
In comparison, I don't see a bright future for Dart nor Livescript (although I secretly root for Dart because I have more confidence in Google to take this language somewhere interesting).
It is LLVM based, and already really fast even though it is still a 0.2 and the JIT seems to have a lot of room for optimisation.
Whats more, it seems to offer just the right blend of language features: - Easily include C libraries via a simple ffi [1] - It is homoiconic like Lisp and thus allows for fantastic macro facilities [2]
- It has solid parallel programming support via a Coroutines implementation (Tasks) (similar to Goroutines as far as I can tell)
- It is a non-pure functional language
- In contrast to Go it has generics, so functional constructs like map, apply, drop, reduce, fold, partition & friends are already in there (or can easily be implemented) [3]
- It has optional types, so that you can assign types and the compiler will check for it and mark errors and will be able to create optimised code, but you don't have to [4]
- Running external programs is a joy [5] (Example: a=readall(`echo hello`))
The community seems to be very alive. There's a simple web framework called "Morsel" and I've recently set it up against a couple of contenders from the web framework benchmark (cpoll-cppsp, phreeze, and some others), and even though it is still a version 0.2, the performance for the json serialization benchmark would be pretty close to Scalatra (I yet have to publish these numbers, will do so soon).
I really hope that Julia will grow, as I love the choices that went into the design of the language, and it would be a shame if it would be only a replacement for R instead of something much bigger, as it is such a nice language.
[1] http://docs.julialang.org/en/latest/manual/calling-c-and-for...
[2] http://docs.julialang.org/en/latest/manual/metaprogramming/
[3] http://docs.julialang.org/en/latest/stdlib/base/#general-col...
[4] http://docs.julialang.org/en/latest/manual/types/
[5] http://docs.julialang.org/en/latest/manual/running-external-...
There're way too many interesting languages these days :)
Agreed about too many interesting languages though :)
http://stackoverflow.com/questions/5721496/learning-java-so-...
http://stackoverflow.com/questions/11358929/what-should-a-sc...
http://www.reddit.com/r/Clojure/comments/1ev4u5/what_do_i_ne...
Well, no, that's not quite right. Really, it's more like someone took Matlab and made it a real general-purpose language, and built it close enough to C to be generally fast, not just fast at a few things. Matlab actually has more in common with Clojure, being a JVM language.
I'd say they're pretty different niches.
What would you call a lambda calculus reducer numerically?
especially these seem very interesting:
http://julialang.org/blog/2013/03/julia-tutorial-MIT/
It's also a huge plus that they can pretty much call any python inline:
http://nbviewer.ipython.org/url/jdj.mit.edu/~stevenj/IJulia%...
So we have the fall back python libraries and can do plotting etc..
Hmm.
I really don't understand why each language ecosystem has to go through this phase. What would be so bad about implementing packaging the way it has been done in OSGi for a decade? It's language agnostic, since the bundle can export/import namespaces or arbitrary capabilities, it has solved the dependencies-are-a-graph-not-a-list problem, it supports versioning and multiple parallel versions of the same package.
I just finished the data science coursera class, and while we used Python, we didn't get into R. I've played around a little R on my own, and while I certainly don't think it's too difficult to learn for a programmer with a math background, as a programmer I feel much more at home with Python. Given the choice, I'd rather use Python than R just because it feels more natural to me.
If Julia is a truly a programming language, I'd agree that it would be more of a competitor with python than R (in the sense that its audience would be people like me who would lean toward python)... but I think it could be very successful by making it very easy for a programmer to stay within a programming language. In other words, it wouldn't compete with R, it would compete with python by bringing what you get from R to a programming language.
function(x1, x2) becomes (function x1 x2)
R has a number of warts as a language (e.g. how it deals with copying objects in memory, amongst others), however it's just as "real" as Python, which also has its warts.
I do like the direction Julia's heading, even if I'd prefer to see something like Clojure/Incanter, or better still, something like Racket be the next baton holder.
Some of this may also simply be a result of doing some exercises in Python (in the coursera class), and not doing any R. I was pretty bummed that we didn't't get at all into R in the coursera class, because sometimes just getting set up a little bit (like having some sample skeleton files for homework) and a few exercises can make a big difference. Not meant as a knock on the course, which was free and (I thought) very good. But a bit of exposure to R would be helpful (while I appreciate the importance of visualization, I do think that given the choice between tableau and an intro to R, I'd definitely have preferred R).
R was really where I started to see the world through functional eyes. I originally came to R with a background involving a little C, a little Perl, a little ObjC, and a whole lot of Python.
Eventually, I hit a point with R where I was trivially doing pretty complicated things that would have been... ugly in Python. Even my Python now looks more like R. This was partly due to finding Peter Norvig's Udacity course, but also partly due to the fact that his somewhat un-"pythonic" python style really, really resonated with my R-tainted brain.
I'm curious; can you give any examples?
https://gist.github.com/pschmied/5903410
I make no guarantees about the quality of my hackish code :-)
Anyway, on the topic of R, I highly suggest the Johns Hopkins data related courses on Coursera. Many of them use R as the central tool, and the three I've taken really stood out for how much the instructors reminded me of getting a private tutorial from a bright colleague on an area of their own expertise.
Based on your description, you'd probably already know most of what would be covered, but the Roger Peng class on "Computing for Data Analysis"[1] is starting again soon, and it includes an overview of R that might have some gems for you. I liked that the lectures were relatively succinct, and the assignments put it in practice.
For X to be the next baton holder, X would need to be quite widely adopted, and the superficially matlab-like look and feel of Julia should really help in this.
Livescript looks like it fixes some of the warts of Coffeescript while also raising the level of abstraction.
Julia is something I've already been looking at. I'm a bit torn on it -- it has vastly fewer libraries than Scipy and R so I don't know if I'm ready to "wear the hair shirt". At this point in life I'm more concerned with doing stuff with existing libraries than building the libraries myself.
Elixir I'm less excited about, because I'm not so excited about Erlang. I feel that Scala provides all of what I'd want from Erlang, along with better sequential performance.
The incredible PyCall.jl package allows use of existing Python libraries from Julia with automatic object translation, including no-copy use of NumPy arrays:
https://github.com/stevengj/PyCall.jl
There is also heavy work on a Julia IPython kernal, which is under testing right now and very close to release.
Some other cool features of Elixir:
...
* List comprehensions
To clarify a little bit, `syntax-parse` is actually not its own model for macros but is a sophisticated front-end for Racket's underlying macro system (described in this paper: http://www.cs.utah.edu/plt/publications/jfp12-draft-fcdf.pdf). Also see Jay McCarthy's blog article that tries to clarify this: http://jeapostrophe.github.io/2013-07-22-123list-post.html
Racket's macro system and Kernel's fexprs are pretty fundamentally different, so I don't think the comparison is very apt. In particular, Racket's macros can be entirely compiled away.
My point was the mental model I refer to when using $lambda is simpler and easier to understand than my mental model for syntax-case, syntax-rules, syntax-parse and friends. The very fact that 'Racket's macros can be entirely compiled away' complicates my mental model which must now accommodate 'phases', compile-time/run-time dichotomies, require for-syntax, etc.
Not saying not to use it, but my use case has to overcome that question.
The big weakness of CoffeeScript IMHO currently is the weak organizational structure of the community. I don't see a clear path where the project is going, and already there are forks/parallels like livescript and IcedCoffeeScript, both with their own strengths.
The output is usually more readable than a lot of JQuery plugins I've seen ;-)
I regard CoffeeScript and its cousins as tools rather than frameworks or languages.
Even if all of the world's copies of the CoffeeScript compiler disappeared tomorrow afternoon, in between sips of tea, your compiled code would still run on every JS runtime (back to IE6), and would still be compatible with all other JavaScript libraries, and future versions of CoffeeScript as well.
Unless you're using native (or shim'd) map and similar constructs instead.
(Or, for that matter, if you're otherwise used to writing code where block scope isn't the rule.)
> The way that it creates "that" variables for temporarily holding on to "this" for a while is idiomatic.
Unless you're using bind instead.
I suppose it's true enough that people can in fact learn good things from the CS compiler output. But the JS that CS writes is not necessarily the JS an experienced dev would write or would have to write to achieve the same goals -- even taking into account the principles behind "best practices."
Also true: no matter how good something is, there'll always be someone eager to put it down.
Aaand, therefore, you might not suggest to people that a good way to learn to write good asm would be to study the output of a C compiler. However educational that experience might be.
> Also true: no matter how good something is, there'll always be someone eager to put it down.
Not sure where this is coming from unless you think we're having a conversation about the merits of a language, instead of the merits of learning another language from the output of a transpiler.
Any discussion of currying vs partial function application needs to start by explicitly stating what the author intends each to mean.
Haven't used LiveScript yet.
I feel TypeScript doesn't offer much beyond static type checking, and this can be compensated by using closure compiler together with LiveScript.
http://elixir-lang.org/getting_started/5.html
There is a book on Elixir coming out from Pragmatic Programmers sometime and will be written by Dave Thomas, which might generate a certain buzz too. This may be a good time to dive into it a bit more.
...Coffeescript stole the spotlight and nobody wants to hear about anything else, but it's mediocre and boring language-wise!
A big part of the original idea with CoffeeScript was to exhaustively annotate the compiler so that folks could take it, and run off in more radical directions. Whereas CoffeeScript is intentionally conservative (no standard library beyond what JavaScript offers is allowed, for example), the fact that LiveScript is a fork off Coco, which is a fork off CoffeeScript, is a wonderful tangent.
There are static and optional typing flavors, asynchronous-flow-control flavors, macro-oriented flavors, functional ones, contract ones, and of course the rewrite of the basic language itself. In open source, there's enough spotlight for all of 'em.