This may possibly be intentional, but seems a bit confusing. The original name of Javascript was LiveScript when initially released with Netscape in the 90s.
Oh, and if you buy a ticket by Sunday you could win a FREE pair of conference pyjamas with the attractive slogan 'Old programmers never die they just become Mostly Functional'
I would absolutely love to attend this, but I don't think I could justify an international trip right now (getting married in 1.5 months). What are the chances you'll do another one next year?
What this article calls currying is actually partial application.
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)'.
You get a function that can take N arguments and return a value, or 1 to N-1 arguments and return a function representing a partial application, which itself exhibits the same behavior:
add3 = (a, b, c) --> a + b + c
x = add3 1
y = x 1
z = y 1 # z = 3
If you look at the compiled code, it is actually an abstraction over a partial application, but at that point is that not just an implementation detail?
Of all the "Javascript.next" languages I hear on a regular basis, it seems to me Microsoft's Typescript is the one most likely to become successful, if only because every time I read an article about it, most of the comments are extremely positive about it and it looks like there are already some fairly large projects written in it.
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).
I really like Julia. I'm currently playing around with it whenever I find some spare time. I don't see it as a competitor to R, I think it could well be something along the lines of Python or Go.
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.
I have been following Julia development for a while now (about a year and a half). It seems like it will be a great tool, but it is still VERY immature. The amount of breakage, especially with regards to important packages like plotting, has become something of an "in" joke. I'm really looking forward to seeing them get their package management situation worked out and a set of core packages nice and stable.
Julia does seem promising. Interesting that you see it as more along the lines of python than R.
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.
I've been reading the Julia docs this morning, and it actually looks like it might be a good fit for my problem domain (video); most of the real heavy computational lifting in my applications happens across a C API boundary, but I still push enough bits that having e.g. unsigned ints (gazes balefully at Gosling) is a requirement.
Wow, it's come along nicely since the last time I saw it. I seem to recall they didn't even have macros and were doing everything with eval. As somebody with no interest in scientific programming, Julia still seems like a very well thought out language. I'll have to try writing an application with it soon.
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:
I hope that some Elixir features make it in to Erlang but I guess I'm one of those rare people that likes the Erlang syntax a lot better. I don't really understand the hate for it, it seems so clear and specific. Anyway, if people want choices for an Erlang like experience, without the Prolog syntax, check out LFE:
The thing I don't like about Erlang's syntax is that often I have to change the character at the end of the line when I need to move a line. It makes refactoring more tedious. I have no problem with it when reading code :)
The language I'm most interested in currently is kernel: mathematically underpinned by the vau calculus, with a smart creator and steward, and a better abstract model for macros than even Racket's stellar syntax-parse. Implementations abound.
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.
When looking at languages like LiveScript (or CoffeeScript) I say to myself: "Javascript has been around for 18 years, how long will this be around for?"
Not saying not to use it, but my use case has to overcome that question.
One of the nice bonuses of targeting lowest-common-denominator JavaScript is that it makes things extremely compatible, and durable.
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.
With Coffeescript (I don't know about Livescript) the compiled output is close enough to hand-written Javascript that, if Coffeescript suddenly disappeared into a black hole, you could use the compiled output as source if needed.
I usually introduce CoffeeScript as "shorthand for best-practice Javascript".
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.
Julia is in a weird place. It improves in speed over R and Python, but the head start of both of these languages is strong. Also it will be some time until julia can provide equivalent support for GUI and Web programming.
Julia fits well as the next step from Matlab. I've already seen groups of engineers across various disciplines that have turned to Julia instead of Matlab.
How is currying better than partial function application (particularly with keyword arguments)? If your function isn't commutative, then it seems to give greater importance/flexibility to the first arguments.
As someone who has just this week started serious study of Erlang, I'll have to look at Elixir as well. Ending statements with periods does take some getting used to!
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.
[+] [-] enobrev|12 years ago|reply
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."
http://livescript.net/#name
[+] [-] tracker1|12 years ago|reply
Though, I'm one of the ones who had the same kind of problem when Mozilla named their new browser Firebird (before becoming Firefox).
[+] [-] xutopia|12 years ago|reply
[+] [-] gordonguthrie|12 years ago|reply
http://mostlyfunctional.com
We have two presentations on languages targeting the Erlang VM, Elixir and Joxa, as well as other goodness...
(Disclaimer, I am the organiser)
[+] [-] gordonguthrie|12 years ago|reply
http://www.cafepress.com/mostlyfunctional
(Shameless plug...)
[+] [-] goostavos|12 years ago|reply
[+] [-] rybosome|12 years ago|reply
[+] [-] lubomir|12 years ago|reply
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)'.
[+] [-] adambard|12 years ago|reply
[+] [-] why-el|12 years ago|reply
[1]http://joearms.github.io/2013/05/31/a-week-with-elixir.html
[+] [-] gnosis|12 years ago|reply
Lisp Flavoured Erlang:
http://www.trapexit.org/forum/viewtopic.php?p=40268
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] laureny|12 years ago|reply
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).
[+] [-] terhechte|12 years ago|reply
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-...
[+] [-] glesica|12 years ago|reply
[+] [-] susi22|12 years ago|reply
http://julialang.org/blog/
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..
[+] [-] geebee|12 years ago|reply
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.
[+] [-] jfb|12 years ago|reply
Hmm.
[+] [-] ioddly|12 years ago|reply
[+] [-] runarberg|12 years ago|reply
[+] [-] Synroc|12 years ago|reply
[+] [-] noelwelsh|12 years ago|reply
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.
[+] [-] ihnorton|12 years ago|reply
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.
[+] [-] AndyKelley|12 years ago|reply
[+] [-] ZoFreX|12 years ago|reply
[+] [-] sinkasapa|12 years ago|reply
https://github.com/rvirding/lfe
[+] [-] rhizome31|12 years ago|reply
[+] [-] oinksoft|12 years ago|reply
[+] [-] adambard|12 years ago|reply
[+] [-] colanderman|12 years ago|reply
[+] [-] _sh|12 years ago|reply
http://en.wikipedia.org/wiki/Kernel_(programming_language)
[+] [-] takikawa|12 years ago|reply
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.
[+] [-] ambirex|12 years ago|reply
Not saying not to use it, but my use case has to overcome that question.
[+] [-] jashkenas|12 years ago|reply
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.
[+] [-] noelwelsh|12 years ago|reply
[+] [-] bayesianhorse|12 years ago|reply
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.
[+] [-] vinceguidry|12 years ago|reply
[+] [-] bayesianhorse|12 years ago|reply
[+] [-] adestefan|12 years ago|reply
[+] [-] acjohnson55|12 years ago|reply
[+] [-] gohrt|12 years ago|reply
Any discussion of currying vs partial function application needs to start by explicitly stating what the author intends each to mean.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] kenjackson|12 years ago|reply
Haven't used LiveScript yet.
[+] [-] lightblade|12 years ago|reply
I feel TypeScript doesn't offer much beyond static type checking, and this can be compensated by using closure compiler together with LiveScript.
[+] [-] pc86|12 years ago|reply
[+] [-] lsdr|12 years ago|reply
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.
[+] [-] santialbo|12 years ago|reply
[+] [-] gpsarakis|12 years ago|reply