Comment by gugagore | Hacker News Reader

Comment by gugagore | Hacker News Reader

I do think Julia is uniquely poised to provide a new kind of trade-off between concision, performance, understandability, etc. because of multiple dispatch, and great syntax for things like broadcasting.

Sometimes a practical algorithm does not look like a textbook algorithm, because they're different algorithms, but I think the main reason that there is such a discrepancy is:

1. math notation is many times quite ambiguous

2. there are a bunch of performance optimizations that end up being unsightly

I am not claiming it's easy work, but I think it's nice to try to find abstractions so that at least somewhere, the algorithm looks simple.

I don't, however, think that these code examples really make that shine at all. There are also choices I disagree with. For example, there is (paraphrasing) `map(vⱼ -> g(x, vⱼ), V)`. the `j` subscript is meaningless to me, and is an awkward combination of "point free" / "index free" notation with a higher-order function, and a more traditional spelling. Math texts love to do things like V = [v_1, ... , v_n]. That doesn't make sense to do in a programming language. instead of writing v_j, you just do V[j].

My favorite examples show the reference algorithm alongside the code (which cites it). The goal should be that the code provides enough similarity to the reference that it's easy to transition between the two and see past those necessary differences. For example:

https://twitter.com/tymwol/status/1305416942967283712

Imagine a world where papers are written as a Julia Jupyter Notebook (or other nb format) that compiles to both a pdf suitable for publishing and also to a library that is directly consumable. The phrase "I'm using an algorithm I found in this paper" would become a much more meaningful statement.

That is a great world. But considering that we still do not really know how to write e.g. generic code that operates on both immutable and mutable arrays, I think Julia is not there yet.

The other big thing missing in Julia that is IMO important here is more control over evaluation, like allowing lazy evaluation. You can build some of these features on top of Julia (e.g. https://github.com/RelationalAI-oss/Salsa.jl).

Math is usually not written with computation in mind, so some algorithm might e.g. re-evaluate f(x) multiple times. Compiler optimizations can help in some cases, as can a "dynamic" solution like memoization/caching. But again, I don't think Julia is "there" yet.

I don’t really get the first issue. If an algorithm doesn’t need to mutate a matrix then it will work for a mutable or immutable matrix. If it needs to mutate a matrix then how could it work for an immutable matrix? If you want a polyalgorithm that uses a mutating algorithm on mutable matrices and a non-mutating algorithm on immutable matrices, then you can just do that (and multiple dispatch makes it easy). What additional features are needed? Is there some language that “does this right”?

That was the premise of literate programming, but it did not took the world by storm.

https://en.wikipedia.org/wiki/Literate_programming

to make a related point, I think that notions of programming (e.g. scope, types, awareness of Hungarian notation) should influence how we write math more. I do not think the goal can be to make code look like "math" completely because there is so, so much punning in how most people write math.

Reply on news.ycombinator.com