JavaScript
-
This post did not contain any content.
Imagine doing math with strings and then blaming the language not yourself
-
Imagine doing math with strings and then blaming the language not yourself
The risk is when it happens unintentionally. The language is bad for hiding such errors by being overly 'helpful' in assuming intent.
-
The risk is when it happens unintentionally. The language is bad for hiding such errors by being overly 'helpful' in assuming intent.
Sure, but at this point it's your own fault if you don't use Typescript to keep these issues from happening.
-
Sure, but at this point it's your own fault if you don't use Typescript to keep these issues from happening.
So, just don’t use JavaScript?
-
It makes perfect sense if the Lang objective is to fail as little as possible. It picks the left side object, checks if the operand is a valid operand of the type. If it is, it casts the right variable into that type and perform the operand. If it isn't, it reverses operand positions and tries again.
The issue here is more the fact that + is used both as addition and as concatenation with different data types. Well, not an issue, just some people will complain.
Computing a nonsensical result is itself a failure. Continuing to run while avoiding giving an error in that case accomplishes nothing but to make the program harder to debug.
-
So, just don’t use JavaScript?
I wouldn't use raw JS for anything new, yes. Typescript however is an excellent language.
-
I don't even know Haskell but it seems like (" ( , ) ") would be an instance of boob.
(.)is a valid expression in Haskell. Normally it is the prefix form of the infix operator.that does function
composition.(.) (2*) (1+) 3=((2*) . (1+)) 3=2 * (1 + 3)=8.But, the most common use of the word "boob" in my experience in Haskell is the "boobs operator":
(.)(.). It's usage in Haskell is limited (tho valid), but it's appearance in racy ASCII art predates even the first versions on Haskell. -
That is just the tip of the iceberg:
Haha that’s a great site. But I think the C example is actually reasonable behaviour.
-
Instead of trying to make it work, javascript could just say "error." Being untyped doesn't mean you can't have error messages.
I think it's less about type system, and more about lack of a separate compilation step.
With a compilation step, you can have error messages that developers see, but users don't. (Hopefully, these errors enable the developers to reduce the errors that users see, and just generally improve the UX, but that's NOT guaranteed.)
Without a compilation step, you have to assign some semantics to whatever random source string your interpreter gets. And, while you can certainly make that an error, that would rarely be helpful for the user. JS instead made the choice to, as much as possible, avoid error semantics in favor of silent coercions, conversions, and conflations in order to make every attempt to not "error-out" on the user.
It would be a very painful decade indeed to now change the semantics for some JS source text.
Purescript is a great option. Typescript is okay. You could also introduce a JS-to-JS "compilation" step that DID reject (or at least warn the developer) for source text that "should" be given an error semantic, but I don't know an "off-the-shelf" approach for that -- other than JSLint.
-
Also, you contradicted yourself just then and there. Not a single of your examples does string concatenation for these types. It's only JS
- In https://lemm.ee/comment/20947041 they claimed "implicit type coercion" and showed many examples; they did NOT claim "string concatenation".
- However, that was in reply to https://lemmy.world/comment/17473361 which was talking about "implicit conversion to string" which is a specific type of "implicit type coercion"; NONE of the examples given involved a conversion to string.
- But also, that was in reply to https://lemm.ee/comment/20939144 which only mentions "implicit type coercion" in general.
So, I think probably everyone in the thread is "correct", but you are actually talking past one another.
I think the JS behavior is a bad design choice, but it is well documented and consistent across implementations.
-
Sure, but at this point it's your own fault if you don't use Typescript to keep these issues from happening.
"Use a different language" is a common defense of javascript, but kind of a weird one.
-
This post did not contain any content.
If you're consciously and intentionally using JavaScript like that, I don't want to be friends with you.
-
"Use a different language" is a common defense of javascript, but kind of a weird one.
Not really, considering Typescript only adds static types to JS. It's not a different language, it's an extension.
-
Imagine doing math with strings and then blaming the language not yourself
The problem is consistency.
-
This post did not contain any content.wrote on last edited by [email protected]
Javascript is a dogshit language that everyone is stuck with. The best that we can hope for is the likes of typescript take the edge off of it. Even though it's like smearing marzipan over a turd. At least it's ok if you don't take a deep bite.
-
So, all you've mustered is some lame-ass whataboutism?
Have a good daySo you don't have a suggestion. Got it.
-
So you don't have a suggestion. Got it.
Of course. Nothing beats JS, oh guru mighty guru
-
- In https://lemm.ee/comment/20947041 they claimed "implicit type coercion" and showed many examples; they did NOT claim "string concatenation".
- However, that was in reply to https://lemmy.world/comment/17473361 which was talking about "implicit conversion to string" which is a specific type of "implicit type coercion"; NONE of the examples given involved a conversion to string.
- But also, that was in reply to https://lemm.ee/comment/20939144 which only mentions "implicit type coercion" in general.
So, I think probably everyone in the thread is "correct", but you are actually talking past one another.
I think the JS behavior is a bad design choice, but it is well documented and consistent across implementations.
Read the thread again, it seems you slipped somewhere. This was all about the claim that implicit conversion to string somehow could make sense.
-
(.)is a valid expression in Haskell. Normally it is the prefix form of the infix operator.that does function
composition.(.) (2*) (1+) 3=((2*) . (1+)) 3=2 * (1 + 3)=8.But, the most common use of the word "boob" in my experience in Haskell is the "boobs operator":
(.)(.). It's usage in Haskell is limited (tho valid), but it's appearance in racy ASCII art predates even the first versions on Haskell.The pioneers of ASCII art in the 70s and 80s are the unsung heroes of porn.
-
Of course. Nothing beats JS, oh guru mighty guru
So all you've mustered is some lame-ass ad-hominem? Have a good day
