5 ms·

I'm put off (not because of the formatting): http://try.purescript.org/?session=60f1839b-bd82-d9af-75ef-dcd936c4a0a2 http://try.purescript.org/?session=60f1839

I'm put off (not because of the formatting): http://try.purescript.org/?session=60f1839b-bd82-d9af-75ef-dcd936c4a0a2 http://try.purescript.org/?session=60f1839b-bd82-d9af-75ef-d... It adds weird syntax where it doesn't matter, like "<>" for string concatenation, but it doesn't cut down on noise where it does matter, i.e. the "list of records" in the example. I'm also wary of a language that puts "pure" right in the name. Purity is nice and often beneficial, but there's a point where it just becomes a crutch. That point which is where the FP adherents and the mainstream diverge.

lelf 7y ago
It’s not a syntax, it’s just a function (<>). Also how would you ”improve” list of records?
- gridlockd 7y ago
  > It’s not a syntax, it’s just a function (<>) Doesn't matter, it's annoying to type and read. What's wrong with '+'? (Rhetorical question, nothing is wrong with '+') > Also how would you ”improve” list of records? Admittedly, I had not thought of a better solution, but it looks noisy where supposedly such a language should look "clean". Perhaps something like this: examples:{title:string, gist:string} = [ { "Algebraic Data Types", "37c3c97f47a43f20c548" } { "Loops", "cfdabdcd085d4ac3dc46" } { "Operators", "3044550f29a7c5d3d0d0" } { "Records", "b80be527ada3eab47dc5" } { "Recursion", "ff49cc7dc85923a75613" } { "Do Notation", "47c2d9913c5dbda1e963" } { "Type Classes", "1a3b845e8c6defde659a" } { "Generic Programming", "3f735aa2a652af592101" } { "QuickCheck", "69f7f94fe4ff3bd47f4b" } ]
  - ulucs 7y ago
    Putting addition and concatenation under the same operator massively backfires when you start using math libraries. All of the language semantics is thrown out of the window when you can realistically sum or concatenate the same two elements, but the operator can only be used for one case (example: python and numpy). For the list of examples, you can just use tuples if you want the "clean" look. There is no need to change the record semantics which is the same in almost all languages.
    - gridlockd 7y ago
      > All of the language semantics is thrown out of the window when you can realistically sum or concatenate the same two elements, but the operator can only be used for one case (example: python and numpy). Huh? You can't realistically "concatenate" two numbers and you can't "add" two strings. You can only concatenate two strings, or a string and an (implicitly converted) number. You can only add two numbers, or the elements of two number arrays (or matrices). Plus isn't the "sum operator" (Σ). There generally is no sum operator, there's a sum function (which works on iterables). So what's the issue? It doesn't cause problems unless you confuse types, which shouldn't happen in a statically typed language. > For the list of examples, you can just use tuples if you want the "clean" look. Is that really true though? Can I initialize an array of records with tuples that are implicitly named? > There is no need to change the record semantics which is the same in almost all languages. This is basically C/C++ syntax, which somehow manages to be less verbose than many supposedly terser languages.

lelf 7y ago

It’s not a syntax, it’s just a function (<>). Also how would you ”improve” list of records?

gridlockd 7y ago
> It’s not a syntax, it’s just a function (<>) Doesn't matter, it's annoying to type and read. What's wrong with '+'? (Rhetorical question, nothing is wrong with '+') > Also how would you ”improve” list of records? Admittedly, I had not thought of a better solution, but it looks noisy where supposedly such a language should look "clean". Perhaps something like this: examples:{title:string, gist:string} = [ { "Algebraic Data Types", "37c3c97f47a43f20c548" } { "Loops", "cfdabdcd085d4ac3dc46" } { "Operators", "3044550f29a7c5d3d0d0" } { "Records", "b80be527ada3eab47dc5" } { "Recursion", "ff49cc7dc85923a75613" } { "Do Notation", "47c2d9913c5dbda1e963" } { "Type Classes", "1a3b845e8c6defde659a" } { "Generic Programming", "3f735aa2a652af592101" } { "QuickCheck", "69f7f94fe4ff3bd47f4b" } ]
- ulucs 7y ago
  Putting addition and concatenation under the same operator massively backfires when you start using math libraries. All of the language semantics is thrown out of the window when you can realistically sum or concatenate the same two elements, but the operator can only be used for one case (example: python and numpy). For the list of examples, you can just use tuples if you want the "clean" look. There is no need to change the record semantics which is the same in almost all languages.
  - gridlockd 7y ago
    > All of the language semantics is thrown out of the window when you can realistically sum or concatenate the same two elements, but the operator can only be used for one case (example: python and numpy). Huh? You can't realistically "concatenate" two numbers and you can't "add" two strings. You can only concatenate two strings, or a string and an (implicitly converted) number. You can only add two numbers, or the elements of two number arrays (or matrices). Plus isn't the "sum operator" (Σ). There generally is no sum operator, there's a sum function (which works on iterables). So what's the issue? It doesn't cause problems unless you confuse types, which shouldn't happen in a statically typed language. > For the list of examples, you can just use tuples if you want the "clean" look. Is that really true though? Can I initialize an array of records with tuples that are implicitly named? > There is no need to change the record semantics which is the same in almost all languages. This is basically C/C++ syntax, which somehow manages to be less verbose than many supposedly terser languages.