Hacker News Reader

Comment by amelius | Hacker News Reader

What I'd like to know when learning a new language is: why can't this be done in an existing language?

Take for example the R programming language. Things you do in this language can be perfectly well done in e.g. Python too. Same goes for the MATLAB language.

View on HN

R (1976)[1] and Matlab (1984)[2] both predate Python (1991)[3], so I guess the answer is because the 'existing' language didn't exist.

As far as Julia goes it aims to bring strong typing and very fast native performance for numerical operations. Neither of which R, Matlab, or Python provide. Seems perfectly reasonable to me.

[1]: http://en.m.wikipedia.org/wiki/S_(programming_language)

[2]: http://en.m.wikipedia.org/wiki/MATLAB

[3]: http://en.m.wikipedia.org/wiki/Python_(programming_language)

Uhh, R is not from 1976, S is - as you note from your footnotes.

There's a direct and strong lineage, but they're not the same.

As someone who remembers when version 1.0 of R was released, I can say pretty confidently that it was well after 1976 :)

Isn't this... exactly what the linked paper tries to explain? The very first three bullet points are a great overview of the traditions Julia breaks away from, and the rest explains how the language enables that.

Can you clarify which parts can easily be done in other languages and how?

Julia is homoiconic, so it can do things non-homoiconic languages can't do. E.g. symbolic differentiation of Julia expressions.

Of course Lisp and Scheme can do this too, but it's virtually non-existent in any common language today. SICM makes heavy use of this.

Now, is there any other language with Lisp-like macros and static typing?

Typed Racket?

Never heard of it. Will check it out.

Racket is a scheme derivative, actually it consists of several languages including some domain specific ones, that all are compatible with each other. It also has a _very_ nice C foreign function interface (much better than Haskells for example).

Thanks for the note. When I first heard "typed racket" I thought: "oh no, an obscure dialect of an already obscure language" and I was slightly disappointed, but now I understand that typed racket is not a derivative of racket, but rather racket is a domain of languages including typed languages. This makes it much more interesting to me. Thanks for the note.

Is that the one with

    (: fun (natural natural -> real))

procedure signatures?

I believe so.

Typed clojure

R is actually homoiconic. It's somewhat awkward and not a language feature that many packages exploit, but it's there. I wouldn't describe R as having Lisp-like macros, though... maybe "macro-like functions."

edit: and _definitely not_ static typing.

When do you call a language "homoiconic" exactly? When it exposes its own AST (abstract syntax tree) structure? In that case, you can call any language homoiconic, whenever somebody builds a library that can transform a given AST back into executable code.

I'm not sure if it is a very distinctive feature.

It's not about any "given" AST, it's about having a computable representation of any code. For example, if I pass you a higher order mathematical function that calculates the first derivative of another function (f), you can create an algorithm that integrates the function symbolically, thus obtaining (another) primitive (related to the original f by a constant).

Note that I mean to symbolically calculate derivatives and integrals, not numerically. A homoiconic language can deconstruct any object representing code and can construct another object based on the underlying structure of the original, not based on any particular value of the original. The original doesn't even need to be invoked at all.

In mathematical parlance, a homoiconic language allows implementing functionals, as opposed to mere higher-oder functions (which is nothing more than function composition).

Please note that all this works with higher-order functions. You don't have to have a textual representation of the function. A.i. you don't parse your own source code.

LISP was actually invented to be able to implement functionals and symbolic calculations like this. The original paper demoed implementing function differentiation (among other things).

So, to understand what you are saying, is it true that in LISP, you can write a function F that can take any function object G, and turn it into an equivalent AST of G?

The spirit of your statement is true, but the precise formulation is incorrect. In LISPs, when you pass a function, you pass a list that defines the function. There is no special "turn into AST" step. Executable code is data, and you can create genuinely new executable code out of this data. There's no special "turn code into data" or "find the data corresponding to this code" step. Code just is data.

Reply on news.ycombinator.com