4 ms·

Because you're wrong. Do spend six months doing hobby array programming. Your view will change.

by rscho 5y ago

jiggawatts 5y ago
It's on my bucket list. But it seems so niche that I suspect I'll never use it. My only motivation is that I've been tempted to develop a toy programming language myself that is as high-level as Rust or C++ but explicitly designed for "wide" processing platforms such as GPUs or many-core processors with SIMD instruction sets. All I'm saying is that the concept of array programming -- like pure functional programming -- may be valuable, but the syntax is not.
- geocar 5y ago
  > the concept of array programming -- like pure functional programming -- may be valuable, but the syntax is not. You would not be the first person tempted to try and separate the two, but I think it is impossible. Every attempt to do so I have ever seen has lost too much in the translation that the four-values I have for programming are no longer conserved.
- rscho 5y ago
  https://futhark-lang.org/ https://futhark-lang.org/ Is the closest you'll get to that, I think. It took a whole team of big brains to make it, and the author stated it was highly non-trivial to make something like that.
  - jiggawatts 5y ago
    Interesting, but not quite what I had in mind. My idea was loosely based on a code search engine Google had for a while before they killed it off. I'm not sure exactly how they did it, but I very strongly suspected that they implemented regular expressions over database indexes. A simple b-tree index is just a set of sorted strings. If you have a lot of sorted strings and you squint at it, you can see how it picks out common prefixes, like a tree. (You can literally store it with the prefixes factored out, and then you have a trie.) For a fairly wide range of regular expressions, and a tree of sorted strings, you can implement a search over the b-tree. E.g.: the search "[bx](a+)foo" can be implemented via finding the range starting with "b", then the range starting with "x". For each range, find the sub-range starting with "ba", "xa", etc... Each step takes logarithmic time, and can be done in parallel. In theory, it takes only about a hundred times longer to find a ten matches in a million strings than it would take to match a single string. Wouldn't it be nice if you could take an algorithm such as "match regex" that normally takes a 'scalar' string and have the compiler automatically create a version that can take an array of sorted values, like the database index? The idea is that much like how array programming languages eschew scalars and pass arrays all over the place to gain efficiency, my language would pass sets all over the place, and gain a different type of efficiency.
- klibertp 5y ago
  I just can't understand how even experienced programmers can fixate on syntax. In my - repeated tens of times by this point - experience the syntax is important for a few months (tops!) at the beginning of using a language, and then stops to matter almost completely. What experiences would make someone convinced otherwise? There's an argument against too high complexity of syntax, but most general-purpose languages out there are very similar in this regard...
  - jiggawatts 5y ago
    There's empirical evidence, loads of it, that this simply isn't true. Syntax absolutely does matter, in all walks of life, not just programming. We're not infinite, error-free computers like some sort of mathematical abstraction. We have squishy meat brains evolved to tell stories around a campfire. As a random example: I learned Rust just for fun, and something that repeatedly caused hours of frustration is that unlike every other modern language, it allows identifier shadowing. This compiles and runs just fine: let a = 5; let a = "wat?" Practically no other language allows this, because it is a recipe for errors. Internally, compilers typically use single static assignment, so the above would be processed something like this: let a_1 = 5; let a_2 = "wat" For a compiler to track this is no problem. For a human? It's a problem. Maybe not for trivial examples like this, but if dozens of identifiers are littered across a huge function it can be a challenge to keep track of which one is which if the names are the same but they're... not the same. Especially if the change is subtle. We're not computers, that's why we make them out of silicon and metal and sell them for money.
    - rscho 5y ago
      Syntax can certainly be more or less suitable to a particular problem or even to humans in general, but (dis)allowing identifier shadowing is part of the semantics of the language (i.e. what the syntax means). One could say: "there should be syntactic cues if we are to allow variable shadowing". That would be a well-defined criticism of syntactic issues. BTW, most modern languages do allow identifier shadowing. The particularity of Rust and the object of your criticism is allowing it in the same scope as the definition. But again, the only way you'll be able to apprehend array language notation is by writing enough of it to become somewhat fluent. It doesn't mean you have to like it, but remember it was the object of a Turing award and that's usually a good indicator of something relevant.

Because you're wrong. Do spend six months doing hobby array programming. Your view will change.

by rscho 5y ago

Because you're wrong. Do spend six months doing hobby array programming. Your view will change.

It's on my bucket list. But it seems so niche that I suspect I'll never use it. My only motivation is that I've been tempted to develop a toy programming language myself that is as high-level as Rust or C++ but explicitly designed for "wide" processing platforms such as GPUs or many-core processors with SIMD instruction sets. All I'm saying is that the concept of array programming -- like pure functional programming -- may be valuable, but the syntax is not.

geocar 5y ago
> the concept of array programming -- like pure functional programming -- may be valuable, but the syntax is not. You would not be the first person tempted to try and separate the two, but I think it is impossible. Every attempt to do so I have ever seen has lost too much in the translation that the four-values I have for programming are no longer conserved.
rscho 5y ago
https://futhark-lang.org/ https://futhark-lang.org/ Is the closest you'll get to that, I think. It took a whole team of big brains to make it, and the author stated it was highly non-trivial to make something like that.
- jiggawatts 5y ago
  Interesting, but not quite what I had in mind. My idea was loosely based on a code search engine Google had for a while before they killed it off. I'm not sure exactly how they did it, but I very strongly suspected that they implemented regular expressions over database indexes. A simple b-tree index is just a set of sorted strings. If you have a lot of sorted strings and you squint at it, you can see how it picks out common prefixes, like a tree. (You can literally store it with the prefixes factored out, and then you have a trie.) For a fairly wide range of regular expressions, and a tree of sorted strings, you can implement a search over the b-tree. E.g.: the search "[bx](a+)foo" can be implemented via finding the range starting with "b", then the range starting with "x". For each range, find the sub-range starting with "ba", "xa", etc... Each step takes logarithmic time, and can be done in parallel. In theory, it takes only about a hundred times longer to find a ten matches in a million strings than it would take to match a single string. Wouldn't it be nice if you could take an algorithm such as "match regex" that normally takes a 'scalar' string and have the compiler automatically create a version that can take an array of sorted values, like the database index? The idea is that much like how array programming languages eschew scalars and pass arrays all over the place to gain efficiency, my language would pass sets all over the place, and gain a different type of efficiency.
klibertp 5y ago
I just can't understand how even experienced programmers can fixate on syntax. In my - repeated tens of times by this point - experience the syntax is important for a few months (tops!) at the beginning of using a language, and then stops to matter almost completely. What experiences would make someone convinced otherwise? There's an argument against too high complexity of syntax, but most general-purpose languages out there are very similar in this regard...
- jiggawatts 5y ago
  There's empirical evidence, loads of it, that this simply isn't true. Syntax absolutely does matter, in all walks of life, not just programming. We're not infinite, error-free computers like some sort of mathematical abstraction. We have squishy meat brains evolved to tell stories around a campfire. As a random example: I learned Rust just for fun, and something that repeatedly caused hours of frustration is that unlike every other modern language, it allows identifier shadowing. This compiles and runs just fine: let a = 5; let a = "wat?" Practically no other language allows this, because it is a recipe for errors. Internally, compilers typically use single static assignment, so the above would be processed something like this: let a_1 = 5; let a_2 = "wat" For a compiler to track this is no problem. For a human? It's a problem. Maybe not for trivial examples like this, but if dozens of identifiers are littered across a huge function it can be a challenge to keep track of which one is which if the names are the same but they're... not the same. Especially if the change is subtle. We're not computers, that's why we make them out of silicon and metal and sell them for money.
  - rscho 5y ago
    Syntax can certainly be more or less suitable to a particular problem or even to humans in general, but (dis)allowing identifier shadowing is part of the semantics of the language (i.e. what the syntax means). One could say: "there should be syntactic cues if we are to allow variable shadowing". That would be a well-defined criticism of syntactic issues. BTW, most modern languages do allow identifier shadowing. The particularity of Rust and the object of your criticism is allowing it in the same scope as the definition. But again, the only way you'll be able to apprehend array language notation is by writing enough of it to become somewhat fluent. It doesn't mean you have to like it, but remember it was the object of a Turing award and that's usually a good indicator of something relevant.