4 ms·

Not sure if it's irony or not. After all, this is not really accidental string concatenation but an easy to make type error which can go undetected due to the d

by atleta 5y ago

Not sure if it's irony or not. After all, this is not really accidental string concatenation but an easy to make type error which can go undetected due to the dynamic typing (and the lack of thorough type annotation in most code). The string concatenation in itself should not be a problem as it's really just string constants. (But again, it might be irony exactly because of this :) )

oaiey 5y ago
Unfortunately no irony. I come from a programming platform (C#) where productivity is a key element of language design. I highly doubt that Anders Heijlsberg would have accepted such a error prone concept like a literal free implicit operator on a key type like strings.
- atleta 5y ago
  Well, I guess it's true for most language that productivity is intended to be a key element of design. (For python, definitely. But I also remember James Gosling saying this about Java.) This implicit concatenation seems to come (inherited?) from C. I kind of remembered that some languages do support it for braking strings into multiple lines conveniently. I'm a bit surprised that it works even on line (I've never used it, because why would have I), but you'll likely to make the mistake on multiline statements anyway. I've also checked and it doesn't work in java (which I kind of remembered, though I mostly do python these days).
  - amelius 5y ago
    > for braking strings into multiple lines conveniently What is inconvenient about just adding a + at the end or beginning of the line?
ErikCorry 5y ago
In most languages an array with 3 elements has the same type as an array with 2 elements so the type system isn't going to warn you about the difference between ("foo" "bar", "baz") and ("foo", "bar", "baz")
- skitter 5y ago
  They still tend to differentiate between 2- and 3 element tuples (but I agree that the implicit concatenation is problematic).
- atleta 5y ago
  Fair enough. I was only thinking about the str vs tuple case. So when you have 2 elements in the parenthesis.

by atleta 5y ago

oaiey 5y ago

Unfortunately no irony. I come from a programming platform (C#) where productivity is a key element of language design. I highly doubt that Anders Heijlsberg would have accepted such a error prone concept like a literal free implicit operator on a key type like strings.

atleta 5y ago
Well, I guess it's true for most language that productivity is intended to be a key element of design. (For python, definitely. But I also remember James Gosling saying this about Java.) This implicit concatenation seems to come (inherited?) from C. I kind of remembered that some languages do support it for braking strings into multiple lines conveniently. I'm a bit surprised that it works even on line (I've never used it, because why would have I), but you'll likely to make the mistake on multiline statements anyway. I've also checked and it doesn't work in java (which I kind of remembered, though I mostly do python these days).
- amelius 5y ago
  > for braking strings into multiple lines conveniently What is inconvenient about just adding a + at the end or beginning of the line?

ErikCorry 5y ago

In most languages an array with 3 elements has the same type as an array with 2 elements so the type system isn't going to warn you about the difference between ("foo" "bar", "baz") and ("foo", "bar", "baz")

skitter 5y ago
They still tend to differentiate between 2- and 3 element tuples (but I agree that the implicit concatenation is problematic).
atleta 5y ago
Fair enough. I was only thinking about the str vs tuple case. So when you have 2 elements in the parenthesis.