Hacker News Reader

Comment by jmercouris | Hacker News Reader

Julia has nothing to do with Lisp. Also a language is neither fast nor slow, the implementation of said language is.

> Also a language is neither fast nor slow, the implementation of said language is.

I don't like how much this simplification gets used. Of course there is more than one way to implement a given language. But there is also more than one way to design a language, and that can have big effects on its implementation(s), and that's usually what people mean when they speak of "fast languages."

Not to mention that many languages only have one implementation, or else many that have all converged to the same performance characteristics.

And on top of that, it's rarely a question of how fast or slow an entire implementation is, either! Individual codebases or problem spaces need different things from their languages.

It’s not a simplification, it’s observing a basic category error. It’s confusing the procedure and the process. Consider for example how the same procedure executing in the same runtime on different processor families will result in highly divergent executing processes. And practically speaking even then they may not even be equivalent up to the explicitly or implicitly specified behavior. Nevertheless ideally when we talk about a language we are talking about a set of semantics that is independent of whatever mechanism executes the processes specified by procedures written in that language.

Some semantics are inherently slow though. If you are allowed to add fields to a class at runtime, you have to box all your objects. If you can eval in local scopes, you need to check to make sure you're running the right code. There are many types of semantic decisions with inevitable performance impact.

> If you are allowed to add fields to a class at runtime, you have to box all your objects.

Do you? You could restructure your data in memory if you wanted to, at least if the assumption is that adding a field is a rare operation.

I would not expect that such features are added under the assumption that it is rarely used.

Common Lisp for example has the assumption in the standard, that the object system is fully dynamic and supports a wide variety of live changes (adding/removing/changing of methods, classes, slots, superclasses, ...).

"Rarely" meaning compared to other elementary operations, such as function or method calls. So it makes sense to make function or method calls faster at the expense of making restructuring slower. That's basically the same principle as with Smalltalk and Lisp structures/objects being vectors as opposed to hash tables (like in Ruby or Python), even if it means that adding a field necessitates having to change the layout of existing instances. This way you'd need to also change the layout of other types that use the unboxed representation of the type being altered but the basic principle is the same and you already have the mechanism for updating your existing heap anyway -- so it should be possible and mere possibility of altering a type shouldn't necessitate boxing everything. "If you are allowed to add fields to a class at runtime, you have to box all your objects" should be no more correct than "if you are allowed to add fields to a class at runtime, all your object instances have to be hash tables".

> Julia has nothing to do with Lisp.

From the article, quoting the makers of Julia:

> We want a language that’s homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab.

In this case, the makers of the language clearly give a nod to Lisp as an inspiration, but even were that not the case, it's basically nonsense to say that any language "has nothing to do with lisp". Lisp has been a driving force in PL for a generation, and its influences are everywhere.

One would say the target audience of Julia - matlab converts, would barely use that feature (macros) directly.

>One would say the target audience of Julia - matlab converts, would barely use that feature (macros) directly.

The 'target audience of Julia' is everyone, not just 'Matlab converts'.

It is most focused on high performance numerics, but is a true general purpose programming language. I expect its use to grow explosively as more and more people recognize its elegance and power.

My perspective is that of a senior engineer with decades of experience with dozens of programming languages.

"The strongest legacy of Lisp in the Julia language is its metaprogramming support. Like Lisp, Julia represents its own code as a data structure of the language itself."

From https://docs.julialang.org/en/v1/manual/metaprogramming/

Multiple dispatch is a pretty strong legacy of CLOS as well.

> Julia has nothing to do with Lisp

Julia's surface syntax, among other parts of the core, are implemented in their own lisp dialect.

https://github.com/JuliaLang/julia/blob/master/src/julia-par...

I know hardly anything about either language, but 'Julia' does sound suspiciously like 'Dylan', and Dylan https://en.wikipedia.org/wiki/Dylan_(programming_language) is usually described as a successor to Common Lisp in heavy disguise.

The Julia authors have been open about how heavily they were inspired by Dylan. A little googling will throw up statements for anyone interested.

In particular, Dylan was one of only a few other languages to Take Multiple Dispatch Seriouslyᵀᴹ

OffTopic

One look at that parser code makes me, a seasoned web and desktop app developer with cocky high minded "architectural" thinking, shrivel with insignificance and embarrassment.

Mad respect to the process and people that makes this possible.

As someone who focuses almost exclusively on backend development, I look at complex ui code similarly. Mad respect to the people who have the vision and skill to design and write well incredible UIs.

On top of that, Julia's non-lispy surface syntax has a perfectly valid s-expression representation that can be displayed with `Meta.show_sexpr`, and for which you could hypothetically enable a repl in only a few lines (e.g. [1])

[1] https://gist.github.com/brenhinkeller/44051118c2f9d18b26dc76...

> Julia has nothing to do with Lisp.

Riiight... https://github.com/JuliaLang/julia/blob/master/src/ast.scm

Julia has a fair amount in common with Lisp, especially with macros.

You can use metaprogramming to edit the AST of a Julia program, like Lisp. See https://docs.julialang.org/en/v1/manual/metaprogramming/

Julia does support REPL style development, and the little I have used it, it was effective for deep learning, text processing, and SPARQL/linked data clients.

I would say that Julia not only supports a REPL, but is heavily biased towards its usage - enough to be detrimental IMO.

To clarify (Correct me if this isn't what you mean), Julia compiles not only program code, but dependency code each time you run a program. This can make simple programs and scripts take a long time to start. A common response is "Use the REPL", where it compiles the dependencies once at load.

Julia has a JIT compiler but it doesn't store the compiled code between sessions. This can add a delay on the first time you call a function. By keeping the REPL open you can avoid having these delays multiple times.

My biggest complaint is static compilation. There are things you can do with PackageCompiler, but they don't work for some of the code I write. This makes deployment of artefacts harder than it needs to be.

Most of the infrastructure is there in the code, it just needs to be tied together, in such a way that juliac file.jl -o file.x results in a deployable (preferably static) binary.

but its REPL is slow and not as interactive.

I've been writing "scripts" with it that extract multi GB data sets using various APIs, perform relevant processing, and spit out actionable visualizations and data.

The APIs are (these days) mostly web/REST-ish, though I'm starting to work on writing some wire-protocol stuff as well.

It (Julia) is an amazingly powerful language today. Excellent for data scientists and engineers, for deep and complex analytics. I am using it in a professional (e.g. paid) setting. Along side python, C++, and other things.

try

    $ julia --lisp

  $ julia --lisp
  ;  _
  ; |_ _ _ |_ _ |  . _ _
  ; | (-||||_(_)|__|_)|_)
  ;-------------------|------------------------------------ 
 ----------------------
  
  > (+ 1 2)
  3
  
  > (exit)

https://github.com/JeffBezanson/femtolisp

Of course they are, what do you call a language that does not permit a fast implementation, or a language that exposes low-level primitives specifically for performance work?

It’s fast as C and has a REPL.

Try building from the source sometime, and reflect upon your statement.

SBCL builds from source on my laptop in just over a minute.

Reply on news.ycombinator.com