5 ms·

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

Rusky 5y ago
> 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.
- User23 5y ago
  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.
  - oscardssmith 5y ago
    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.
    - jhgb 5y ago
      > 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.
      - lispm 5y ago
        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, ...).
        jhgb 5y ago
        "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".
remram 5y ago
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?
mark_l_watson 5y ago
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.
- Sanguinaire 5y ago
  I would say that Julia not only supports a REPL, but is heavily biased towards its usage - enough to be detrimental IMO.
  - vindarel 5y ago
    but its REPL is slow and not as interactive.
  - hpcjoe 5y ago
    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.
  - the__alchemist 5y ago
    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.
    - borodi 5y ago
      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.
- hpcjoe 5y ago
mtreis86 5y ago
"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/ https://docs.julialang.org/en/v1/manual/metaprogramming/
- ralphc 5y ago
  Multiple dispatch is a pretty strong legacy of CLOS as well.
ArchieMaclean 5y ago
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/ https://docs.julialang.org/en/v1/manual/metaprogramming/
jazzyjackson 5y ago
It’s fast as C and has a REPL.
lolinder 5y ago
> 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.
- zerr 5y ago
  One would say the target audience of Julia - matlab converts, would barely use that feature (macros) directly.
  - Recurecur 5y ago
    >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.
rezq 5y ago
try $ julia --lisp
- markkitti 5y ago
  $ julia --lisp ; _ ; |_ _ _ |_ _ | . _ _ ; | (-||||_(_)|__|_)|_) ;-------------------|------------------------------------ ---------------------- > (+ 1 2) 3 > (exit) https://github.com/JeffBezanson/femtolisp https://github.com/JeffBezanson/femtolisp
clcaev 5y ago
> 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-parser.scm https://github.com/JuliaLang/julia/blob/master/src/julia-par...
- leoc 5y ago
  I know hardly anything about either language, but 'Julia' does sound suspiciously like 'Dylan', and Dylan https://en.wikipedia.org/wiki/Dylan_(programming_language) https://en.wikipedia.org/wiki/Dylan_(programming_language) is usually described as a successor to Common Lisp in heavy disguise.
  - ssivark 5y ago
    The Julia authors have been open about how heavily they were inspired by Dylan. A little googling will throw up statements for anyone interested.
    - cbkeller 5y ago
      In particular, Dylan was one of only a few other languages to Take Multiple Dispatch Seriouslyᵀᴹ
- kumarvvr 5y ago
  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.
  - gizmo385 5y ago
    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.
- 5y ago
hpcjoe 5y ago
Try building from the source sometime, and reflect upon your statement.
- pfdietz 5y ago
  SBCL builds from source on my laptop in just over a minute.
jhgb 5y ago
> Julia has nothing to do with Lisp. Riiight... https://github.com/JuliaLang/julia/blob/master/src/ast.scm https://github.com/JuliaLang/julia/blob/master/src/ast.scm

> 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.

User23 5y ago
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.
- oscardssmith 5y ago
  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.
  - jhgb 5y ago
    > 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.
    - lispm 5y ago
      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, ...).
      - jhgb 5y ago
        "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".

remram 5y ago

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?

mark_l_watson 5y ago

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.

Sanguinaire 5y ago
I would say that Julia not only supports a REPL, but is heavily biased towards its usage - enough to be detrimental IMO.
- vindarel 5y ago
  but its REPL is slow and not as interactive.
- hpcjoe 5y ago
  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.
- the__alchemist 5y ago
  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.
  - borodi 5y ago
    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.
hpcjoe 5y ago

mtreis86 5y ago

"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/ https://docs.julialang.org/en/v1/manual/metaprogramming/

ralphc 5y ago
Multiple dispatch is a pretty strong legacy of CLOS as well.

ArchieMaclean 5y ago

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/ https://docs.julialang.org/en/v1/manual/metaprogramming/

jazzyjackson 5y ago

It’s fast as C and has a REPL.

lolinder 5y ago

> 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.

zerr 5y ago
One would say the target audience of Julia - matlab converts, would barely use that feature (macros) directly.
- Recurecur 5y ago
  >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.

rezq 5y ago

try $ julia --lisp

markkitti 5y ago
$ julia --lisp ; _ ; |_ _ _ |_ _ | . _ _ ; | (-||||_(_)|__|_)|_) ;-------------------|------------------------------------ ---------------------- > (+ 1 2) 3 > (exit) https://github.com/JeffBezanson/femtolisp https://github.com/JeffBezanson/femtolisp

clcaev 5y ago

> 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-parser.scm https://github.com/JuliaLang/julia/blob/master/src/julia-par...

leoc 5y ago
I know hardly anything about either language, but 'Julia' does sound suspiciously like 'Dylan', and Dylan https://en.wikipedia.org/wiki/Dylan_(programming_language) https://en.wikipedia.org/wiki/Dylan_(programming_language) is usually described as a successor to Common Lisp in heavy disguise.
- ssivark 5y ago
  The Julia authors have been open about how heavily they were inspired by Dylan. A little googling will throw up statements for anyone interested.
  - cbkeller 5y ago
    In particular, Dylan was one of only a few other languages to Take Multiple Dispatch Seriouslyᵀᴹ
kumarvvr 5y ago
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.
- gizmo385 5y ago
  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.
5y ago

hpcjoe 5y ago

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

pfdietz 5y ago
SBCL builds from source on my laptop in just over a minute.

jhgb 5y ago

> Julia has nothing to do with Lisp. Riiight... https://github.com/JuliaLang/julia/blob/master/src/ast.scm https://github.com/JuliaLang/julia/blob/master/src/ast.scm