3 ms·

I also wish more things in JS were expressions - having var statements as expressions in particular would help a lot with arrow functions. Algebraic data types

by spion 11y ago

I also wish more things in JS were expressions - having var statements as expressions in particular would help a lot with arrow functions. Algebraic data types (and pattern matching) are definitely features that should be present in every language - the difference of modeling things without and with them is like night and day. TypeScript's type system is indeed more forgiving, but mostly because the language is designed for migrating existing JS codebases to it. You can then tighten the grip significantly by adding `--noImplicitAny`. The most unfortunate TS unsoundness issue at the moment is that null/undefined are acceptable values for all types - I really wish they'd fix that... What are the options for JS FFI in Haxe? Is there something less awkward to use (perhaps a more user friendly FFI library) than http://old.haxe.org/doc/advanced/magic#javascript-magic http://old.haxe.org/doc/advanced/magic#javascript-magic ? - Side note: automatic semicolon insertion was not a huge mistake, and Douglas Crockford saying it was doesn't make it so. If you follow 2 simple rules, you wont need any semicolons: 1) Dont put a new line between `return`/`throw`, and the returned/thrown expression (newlines inside the expression are fine) 2) Prepend `;` to a line starting with `(` Crockford had a minifier bug related to #2 and solved someone else's problem with #1 then declared a rule to always use semicolons (which doesn't even help with #1)

pluma 11y ago
Here's the rules you need to follow if you use semicolons: 1) Use a semicolon. 2) There is no rule 2. EDIT: This may seem flippant but the point is that humans make mistakes and the more rules you have to obey, the more mistakes they will make. Especially beginners. ASI (automatic semicolon insertion) and double-equals (weak comparison vs triple-equals strict comparison) aren't bad because they don't work, they are bad because they allow for unnecessary mistakes in return for a minimal reduction of characters you need to type. Despite all the rationalizations, the primary reason some programmers prefer to rely on ASI is purely aesthetics. That's okay, but there's no point in trying to construct artificial arguments to defend that preference. If a future version of the language somehow manages to eliminate the need for those rules, I'll be the last person to tell you to stick to your semicolons. Until then, it's still a voluntary handicap.
- spion 11y ago
  Even if you use semicolons, you still need the extra rule about return/throw statements. Otherwise the following will surprise you: return { property: value }; (Whats the value returned? Its `undefined`) Therefore, "Use a semicolon" is insufficient. Or rather, its about as sufficient as "Don't start a line with (". Which means that the rule(s) for using semicolons are no more complex than the rules for not using them. This is precisely why "follow these simple rules" is not enough. I believe that us programmers would really benefit if we stopped following and perpetuating best practices without understanding (and explaining) the reasons behind them very throughly. If you want less cognitive overload, use a language with less warts, or a language with a type system. Lint-like rules that don't come with a reason are useless and result in a false sense of security

by spion 11y ago

pluma 11y ago

Here's the rules you need to follow if you use semicolons: 1) Use a semicolon. 2) There is no rule 2. EDIT: This may seem flippant but the point is that humans make mistakes and the more rules you have to obey, the more mistakes they will make. Especially beginners. ASI (automatic semicolon insertion) and double-equals (weak comparison vs triple-equals strict comparison) aren't bad because they don't work, they are bad because they allow for unnecessary mistakes in return for a minimal reduction of characters you need to type. Despite all the rationalizations, the primary reason some programmers prefer to rely on ASI is purely aesthetics. That's okay, but there's no point in trying to construct artificial arguments to defend that preference. If a future version of the language somehow manages to eliminate the need for those rules, I'll be the last person to tell you to stick to your semicolons. Until then, it's still a voluntary handicap.

spion 11y ago
Even if you use semicolons, you still need the extra rule about return/throw statements. Otherwise the following will surprise you: return { property: value }; (Whats the value returned? Its `undefined`) Therefore, "Use a semicolon" is insufficient. Or rather, its about as sufficient as "Don't start a line with (". Which means that the rule(s) for using semicolons are no more complex than the rules for not using them. This is precisely why "follow these simple rules" is not enough. I believe that us programmers would really benefit if we stopped following and perpetuating best practices without understanding (and explaining) the reasons behind them very throughly. If you want less cognitive overload, use a language with less warts, or a language with a type system. Lint-like rules that don't come with a reason are useless and result in a false sense of security