4 ms·
- One thing not discussed in the article is type safety. But TC39 increasingly considers the impact of proposals on typed extensions to JS like TypeScript/Flow.
by eyelidlessness 5y ago
- One thing not discussed in the article is type safety. But TC39 increasingly considers the impact of proposals on typed extensions to JS like TypeScript/Flow. In your example, v must be a union type of the return types of each of the called functions.
- The pipeline operator can be used to assign to a const, to prevent further assignments. While const isn’t necessarily immutable, it is often idiomatically used to signal that the assigned value is intended to be final. The same can’t be achieved with your example without wrapping it in an IIFE, which is (IMO) much harder to follow than the pipeline operator.
- More subjectively, it (in the F# variant) encourages better interfaces. For most use cases where piping would be appropriate, it’s generally a good idea to make the data you’re processing the last parameter. This also, as the article notes, works well with partial application. Which in turn also encourages good practices like composition.
- junon 5y agoI think your first point is the only compelling reason (for me) yet I also hold the stance that TC39 shouldn't cater to corporate projects such as Typescript as they are not maintained by the same committee. Those are my opinions, however.
- eyelidlessness 5y agoThey aren’t catering specifically to TypeScript (or Flow), but rather to increased interest in type safety across the community generally. It’s worth noting though that the TypeScript team does participate in the standards process. And Microsoft has two members on the committee.
- Zababa 5y agoI do agree that they shouldn't cater to TypeScript or Flow or anything specifically, but I appreciate that they think about the impact of new changes on typing JavaScript. I find in general that code that can easily be statically typed is easier to understand and maintain.
- eyelidlessness 5y agoExactly this! And the inverse—where JavaScript devs complain that TypeScript types are overly complex and verbose—is just a symptom of the same principle. Those types are complicated because your interface is complicated! If you had a clear data flow/model the types will usually end up being much simpler too. This is somewhat less true in some frontend projects, where the underlying libraries/frameworks come with infectious built-in interface complexity (side-eyes React/JSX even though I quite like JSX otherwise).
- Zababa 5y ago> And the inverse—where JavaScript devs complain that TypeScript types are overly complex and verbose—is just a symptom of the same principle. Those types are complicated because your interface is complicated! Part of it may also be due to the limitations of TypeScript. Structural typing is not always the best choice. ADT support is also not the best.
- eyelidlessness 5y agoI definitely have wants for the TS type system, particularly in the area of nominal typing. But it’s usually not this IME. It’s usually that untyped JS often is written in an overly permissive style where anything goes, or where state and data flow is a big ball of mud, or both.
- junon 5y agoThat's false equivalence. Typescript is trying to bolt on strict, formal types to a prototypical language. Because the language doesn't map cleanly into formal types doesn't mean it's poorly designed. You'd need to have a lot of evidence that that were the case, as it's a bold claim about not just JavaScript, but programming language design in general - one that isn't entirely factual, IMO. Look at shell scripting. Imagine trying to apply a type system to shell scripts. It wouldn't map cleanly at all because (almost) everything is a string, and the operations define how those strings are interpreted - not the data itself. However for what it is, shell scripting is quite useful. Most would argue it has a simple interface, simple syntax, simple concepts. Perhaps a contrived example - my point mostly being that you can't draw conclusions like that.