4 ms·

I wonder how this compares to the array languages?

082349872349872 4y ago
rather verbose: https://google-research.github.io/dex-lang/examples/tutorial.html https://google-research.github.io/dex-lang/examples/tutorial...
- ModernMech 4y ago
  > 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.

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

ModernMech 4y ago
> 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.