JavaScript
-
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
-
This post did not contain any content.
It's my favorite language too, but I also find this hilarious.
-
So, just don’t use JavaScript?
That's also my understanding: "Javascript is great because you can use other languages and then transpile them to JS."
-
This post did not contain any content.wrote on last edited by [email protected]
It's because
+is two different operators and overloads based on the type to the left, while-is only a numeric operator and coerces left and right operands to numeric. But frankly if you're still using+for math or string concatenation in 2025, you're doing it wrong. -
It's because
+is two different operators and overloads based on the type to the left, while-is only a numeric operator and coerces left and right operands to numeric. But frankly if you're still using+for math or string concatenation in 2025, you're doing it wrong.I know nothing about javascript, what is wrong with using + for math? perhaps naively, I'd say it looks suited for the job
-
This post did not contain any content.
It makes sense though
-
I know nothing about javascript, what is wrong with using + for math? perhaps naively, I'd say it looks suited for the job
It's much better to make your own function that uses bitwise operations to do addition.
function add(a, b) { while (b !== 0) { // Calculate carry let carry = a & b; // Sum without carry a = a ^ b; // Shift carry to the left b = carry << 1; } return a; }(For certain definitions of better.)
