Dex Lang: Research language for array processing in the Haskell/ML family | Hacker News Reader

Dex Lang: Research language for array processing in the Haskell/ML family

github.com

65 pointstim_sw8 comments

Looks great! Just high level enough for me to understand and easily readable.

Haskell style pure functions are a natural fit for shaders that are side effect free by design. Wonder how far you can go with abstractions like applicative functors for generic vector math etc. Could be quite powerful and when properly inlined without any perf hit.

Currently Futhark seems one of the best ways into that direction.

Pretty wacky syntax. I'm not a Julia fanboy, but I don't quite see the point of something like this over it.

From the "basis function regression" example:

    struct SolverState(n|Ix) =
      x : n=>Float
      r : n=>Float
      p : n=>Float

Why not just "Float[n]" or even "Float^n" if we're trying to get fancy? The syntax "n=>Float" suggests "n" is being mapped to "Float", which isn't what is happening.

Further on in the implementation of CG:

    r0 = b - (mat **. x0)

Matrix multiplication is "**."? I thought Python's "@" was bad, but this is certainly worse... is the goal to confuse MATLAB programmers and Python programmers simultaneously? Also, are the parentheses necessary to get the associativity correct? If so, Dex has some quite interesting operator precedence rules!

Further down:

    x' = s.x + alpha .* p

For scalar multiplication, we need ".*", with the "." on the left now? What's with the inconsistency?

This is leaving aside how much sense:

    result = apply_n(n_iter, SolverState(x0, r0, r0)) \s.
        ...

makes... is this really an improvement over a for loop? What's with the backslash and period?

There just seems to be a lot of syntactic noise with this language. Sorry to be so disparaging, but I just wonder if there's some motivation for it.

The reason languages like MATLAB and Julia have hewed to a fairly conservative syntax for array programming is because there's significant precedent for it. Fortran was widely used for a long time and stuck to a syntax which is sensible for engineers and mathematicians. Fortran is in fact still widely used---and this is fine! It has its place! MATLAB directly inherited Fortran's syntax. Julia deliberately copied MATLAB's syntax. There is a whole culture of programmers who are oriented around this syntactical approach. What's the point in choosing such a syntax which the majority of these programmers will find obtuse and unfriendly?

Dex lives in a crowded space but I like it.

It seems to be pragmatic in keeping the type system and the effect system simple (compared to Haskell, Koka).

Comparison to Futhark (in their paper);

"Dex has the benefit of being able to naturally express a parallel and work- efficient program instead of relying on opaque compiler optimizations"

(I hope that it catches up to Fedora's LLVM version)

I’ve had some super fun chats with at least one of the team members on that prject

I wonder how this compares to the array languages?

rather verbose: https://google-research.github.io/dex-lang/examples/tutorial...

> In particular, Dex does not force you to rewrite all operations in terms of batched tensor interactions, but allows for a range of interactions. Put more simply, when learning MATLAB students are told repeatedly to "avoid for loops". Dex gives for loops back.

This part is interesting, and one thing that would set Dex apart from other array languages. One of the things that imperative programmers find difficult when writing in array languages is thinking in terms of transformations on collections and sets, rather than managing a single item, and using control flow to handle multiple (loops usually). It seems like Dex is saying they will compile for loops to array operations, so that maybe it's easier for imperative programmers.

I have to wonder though... why? I mean, they point out that Matlab users are often told to avoid writing loops, but Matlab has certainly never forced anyone to write their code in batched tensor operations; for loops exist but they are sometimes slower than the built-in matrix operations. I say sometimes, because while it's been true in the past that for loops have been slower, I've found in recent iterations of the language that they are doing something to make them much faster -- whether that be JITing the code or something else, I'm not sure.

Anyway, I really wish this document would have given an example where what they are proposing is better than what you can do with arrays. In all of their examples, I would reach for a proper array language. For instance, they show this code:

  :t for i:Height. for j:Width. x[i, j] + 5.0
  ((Fin 3) => (Fin 8) => Float32)

In Matlab, this is just

  x + 5

which has always been the whole appeal of array languages (to me at least). So I don't see what bringing for loops back is buying us, unless they are a kind of gateway for imperative programmers.

I'll have to look more at this document, as I find the typed indexing intriguing, but I'm not sure what to make of it yet.

Reply on news.ycombinator.com