12 ms·
You might want to give this a look: https://github.com/Microsoft/TypeScript https://github.com/Microsoft/TypeScript
by dunstad 9y ago
You might want to give this a look: https://github.com/Microsoft/TypeScript https://github.com/Microsoft/TypeScript
- vladimir-y 9y agoit's more than just a type checker
- alkonaut 9y agoMy point exactly. If people who liked type systems could stand to use the JS type system (and I only barely managed to write type system without scare quotes), we wouldn't have TypeScript. Or Cofeescript. Or Purescript. Or Elm. Or Fable. Or Flow. Or even ES6.
- spacetexas 9y agomaybe because browsers and backwards compatibility exist and we cant just change the language as we please?
- hasenj 9y agoWhat's wrong with TypeScript?
- alkonaut 9y agoI haven't used it enough to have a detailed opinion but from what I can see it looks like an excellent language.
- weberc2 9y agoI'm having a hard time discerning his point based on the languages he listed. I think his point was that the type theorists weren't fans of JS so they built languages that compiled to it, but CoffeeScript and ES6 don't have type systems either, so either he isn't very familiar with the languages he listed or he's making a different point.
- alkonaut 9y ago> CoffeeScript and ES6 don't have type systems either All languages have type systems. Including ES5, ES6 and CoffeeScript. They might be weak and dynamic but they are type systems none the less. > I think his point was that the type theorists weren't fans of JS I'm fairly sure that's the case (no data though) > or he's making a different point. My point was (a bit toungue in cheek) that seeing how many alternatives that keep popping up for avoiding JS (the language), it seems that a lot of people who like programming languages to the point where they can create one, do not like JS.
- sillysaurus3 9y agoHi. I'm interested in type theory, and I'm a big fan of JS. shrug Is it really so hard to believe? Imagine if the browser's scripting language didn't have closures or prototypical inheritance. It was possible. JS was a pretty good compromise between power and simplicity.
- alkonaut 9y ago> Hi. I'm interested in type theory, and I'm a big fan of JS. fan of JS as a whole package (Language, ecosystem, ...) or JS only as a language? The whole package is very attractive, and I can see how people accept ES5 (the language) for the opportunity to work with JS the ecosystem. JS the language I think has some cool features and with ES6 it's even an acceptable language to work with, but I just fail to come to terms with some of the smaller warts. The feeling I'm looking for in a language is "this is carefully designed to be consistent, simple and free of idiosyncraces and suprises". With equality, scoping, coercions etc in ES5 that realy is NOT the feeling. ES6 is so much better, but once you pick an ES5 alternative there are so many other choices. > JS was a pretty good compromise between power and simplicity. I really don't get why people think JS is "simple" though. It's fantastically complicated. Mostly accidentally though., because of the little warts in scoping/equality/coercion etc. Again, ES6 is a lot better - but still very very not simple compared to e.g. Java.
- Cyph0n 9y agoWhy is everyone forgetting Scala.js?
- tytytytytytytyt 9y agoThey always do. I think people want to complain about things and still not actually try nicer alternatives.
- electrum 9y agoOr Kotlin: https://kotlinlang.org/docs/reference/js-overview.html https://kotlinlang.org/docs/reference/js-overview.html
- fasquoika 9y agoBecause if they listed every language that compiled to JS the actual point of their comment would get buried?
- Cyph0n 9y agoThe focus of the original comment was on compile-to-JS languages with strong(er) type systems. Scala.js should be at the top of that list. Try again.
- jonsterling 9y agoTypeScript, the language which only just this month added a flag to turn off their completely incorrect subtyping rules for functions! A flag! I remember reporting this bug years ago, and they said it was "by design, since JS programmers prefer to think of functions as covariant in their input". Well, I prefer to think of 2+2 as equalling 5.
- LambdaComplex 9y agoI don't know nearly enough about type systems to understand this. Can you explain what subtyping rules are, and how TypeScript's are wrong? And can you explain what "covariant in their input" means?
- kreetx 9y agoHere is a good and down-to-earth explanation: https://www.stephanboyer.com/post/132/what-are-covariance-and-contravariance https://www.stephanboyer.com/post/132/what-are-covariance-an...
- Dylan16807 9y agoCovariant: A variable needs to have an Animal. You can put a Cat in the variable. Contravariant: A variable needs to have a function that accepts Animals. You can't put a function that accepts only Cats, or it will crash on other kinds of animal. But you can put a function that accepts all LivingThings. So when something is covariant you can use a more specific type, and when it's contravariant you can use a more generic type. When it comes to function parameters, typescript lets you use either. You can replace any type with any related type, even if you're going in the wrong direction. They did this to make certain use cases simpler, at the cost of weaker typing.
- Filligree 9y agoThat helps, thanks. Can you explain the naming? What sort of variance is the second case contra?
- aaheel 9y agoThat's something more precise i would say.