This reminded me of the recent brilliant talk about design of Julia: "Julia: to lisp or not to lisp?" ▶ this video
in “Nim Programming Language 0.14.0 released” · View on HN
Julia: to Lisp or not to Lisp? on HackerTube: recommended by 4 Hacker News commenters across 8 separate months, 2016–2022.
talk · intermediate · evergreen
Stefan Karpinski's European Lisp Symposium 2016 talk asks whether Julia is a Lisp. He covers the features it borrows from Lisp, such as macros and closures, and where it departs, including syntax and its type system, with generated machine code shown.
HN commenters recommend it as a brilliant talk on Julia's design and how it is or isn't a Lisp.
“the recent brilliant talk about design of Julia”
13 Hacker News comments link this video. Each one links back to its thread.
This reminded me of the recent brilliant talk about design of Julia: "Julia: to lisp or not to lisp?" ▶ this video
in “Nim Programming Language 0.14.0 released” · View on HN
Ah, the Julia talk ( ▶ this video ) was just great. Showing the generated machine code is so hackerish yet so rare these days. :-/
in “European Lisp Symposium 2016” · View on HN
Stefan Karpinski (one of the core Julia contributors) gave a talk (in 2016, so rather dated as far as the Julia syntax and whatnot go) about how Julia is secretly more lisp-y than even lisp & Scheme. The core of this argument is that most language specifications dedicate many pages to defining how arithmetic works, whereas Julia is actually just able to define that in Julia code as part of the stdlib (the implementation just calls out to LLVM intrinsics, but nonetheless, super neat!). `Int64` is actually defined in a Julia file. ▶ this video
in “From Common Lisp to Julia” · View on HN
I'm a great admirer of Julia, but I doubt it would appeal to those seeking a "true" lisp/scheme. Even if it's has a sane macro system, and much of the same power. You can indeed see s-expressions (search for "s-expression") : [link] This nice talk mentions a bit on how Julia is (not) a lisp (if I recall correctly): "Julia: to Lisp or not to Lisp?": ▶ this video This might also be of interest: [link] As well as (maybe) clasp: [link]
in “Chicken Scheme 5.0” · View on HN
You might also want to have a look at Julia. It's not really a lisp, but it sits on top of a scheme - and it has a rather interesting, pragmatic type system: "Julia: to lisp or not to lisp?": ▶ this video [link] Maybe compare and contrast with Maxima?: [link]
in “Common Lisp homepage” · View on HN
I'm not sure if "special language" is a particularly apt description of what Julia is. SQL is a "special" language. At any rate - a lisp-like language with llvm backend, package manager, and a (small, but not trivial) group of users writing real software - what's not to like? I (still) recommend the talk: "Julia - to lisp or not to lisp?", that gives a quick overview of some of the design choices: ▶ this video For me, I like that it has a real story trying to balance "actual integer math" (not this silly machine constrained twos-compliment hack" and "you could conceivably write a ray tracer that wasn't unusably slow" :)
in “Some fun with π in Julia” · View on HN
Speaking of talks on Julia, I'll again recommend: ▶ this video "Julia: to Lisp or not to Lisp?" from the European Lisp Symposium in May 2016. I found it was rather illuminating on Julia in particular and lisps and programming languages in general.
in “A Look at How Traders and Economists Are Using the Julia Programming Language” · View on HN
From the linked [lwn] article: "Another example he gave demonstrates the slowness of the C runtime: import itertools sum(itertools.repeat(1.0, 100000000)) That will calculate the sum of 100 million 1.0s. But it is six times slower than the equivalent JavaScript loop. Float addition is fast, as is sum(), but the result is not. Larry Hastings asked what it was that was slowing everything down. Modzelewski replied that it is the boxing of the numbers, which requires allocations for creating objects. Though an audience member did point out with a chuckle that you can increase the number of iterations and Python will still give the right answer, while JavaScript will not." Reminded me about the excellent talk about Julia: "Julia: to Lisp or not to Lisp?" ▶ this video One things he points out early is that both the C99 and the R6RS Scheme spec is 20% numerical. Because correct and (reasonably) fast numbers and arithmetic is actually pretty hard to get right on a computer - if you want to abstract away hardware "short-cuts" and allow for precise arithmetic by default. It will be interesting to see how much type hints (eliminating some of the boxing/unboxing) will help python. And if it turns out to really be a good fit for the language -- everyone wants "free" performance, but transitioning to a (even partially) typed language is certainly not "free". Another point with the above loop, is that ideally, even if it can't be optimized/memoized down to a constant - it really shouldn't have t
in “Why is Python slow” · View on HN
Best talks in my opinion: * [link] * ▶ this video Notable mentions: * [link] * [link] * [link] I liked OpenGL lightning talk as well: * [link]
in “European Lisp Symposium 2016” · View on HN
Personally, I think when you write Julia in shorthand form, it looks nothing like ruby or basic. for example, check out parts of the stdlib: [link] but in the end, julia really is a lisp: ▶ this video
in “PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)” · View on HN
> Actually, in general Julia is surprisingly Lispy for a language with Algol-family syntax. It's less surprising if you know there's still a version of the Julia REPL that works with sexpressions: ▶ this video
in “Some Insights from a Julia Developer” · View on HN
> ... a relatively fast functional language that replaces most of the brackets with indentation. You might like sweet expressions coupled with a common lisp, a scheme or racket: [link] [link] ... Or perhaps have a look at Julia: [link] "Julia - to Lisp or not to Lisp": ▶ this video [ed: and as mentioned below, there's also wisp: [link] ]
in “A Lisp that runs Python (2016)” · View on HN
My initial thought was that this was about a project building atop of clasp, like CANDO: [link] [link] [link] But this does seem a bit more like Julia? "Julia: to Lisp or not to Lisp?" ▶ this video Then there's also the Axiom system, which I guess is primarily for symbolic computation, but I don't know if it might make sense to use it as a building block for statistical software? [link]
in “Back to the Future: Lisp as a Base for a Statistical Computing System [pdf]” · View on HN