Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript’s quirks: How inconsistencies make the language more complex

blog.asana.com

Post reply on HN
Print view View original

201–210 of 216 posts

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#201

Post by tigershark »

blobs wrote: post #116
twotwotwo wrote: post #80

These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch a common JavaScript bug (typoed property names), structural static typing matches the dynamic duck typing JavaScript authors had already been working with (though I see how nominal would be useful), and it's awesome they found a workable hack for discriminate…

> TypeScript crew have managed to build something that can get traction where other efforts have not. You mean Microsoft managed to get traction? It seems most TS proponents don't realize TS is a success because they fell for smart marketing and serious money behind the project, not because it's a better language than 'other efforts' like for example Purescript or Dart. But every comment I make against TS seems futil…

Typescript unlike Dart, Purescript, Fable and BuckleScript is a superset of JavaScript so you don’t have to change anything in your existing JavaScript project to start using Typescript. Also JavaScript interop is a breeze and a huge percentage of the libraries have already typescript binding and it’s a huge advantage compared to using the aforementioned languages.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#202

Post by Shacklz »

Findeton wrote: post #106
twotwotwo wrote: post #80

These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch a common JavaScript bug (typoed property names), structural static typing matches the dynamic duck typing JavaScript authors had already been working with (though I see how nominal would be useful), and it's awesome they found a workable hack for discriminate…

As someone that uses the language everyday, these are real quirks on the language, but they are not showstoppers. The benefits of using exactly the same language in front-end and back-end, with shared types and everything, largely offset the small quirks. However sometimes I kinda miss some functional stuff that you can for example find in Scala or Rust, like pattern matching. Specifically, we've had experience using…

Pattern matching is definitely something I also miss. For input validation and Optional/Either types, io-ts/fp-ts (https://github.com/gcanti/io-ts) fulfill my needs perfectly, especially io-ts is something I can't recommend enough. Saved me so many headaches from sudden breaking changes in APIs we consume.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#203

Post by Fannon »

Findeton wrote: post #106
twotwotwo wrote: post #80

These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch a common JavaScript bug (typoed property names), structural static typing matches the dynamic duck typing JavaScript authors had already been working with (though I see how nominal would be useful), and it's awesome they found a workable hack for discriminate…

As someone that uses the language everyday, these are real quirks on the language, but they are not showstoppers. The benefits of using exactly the same language in front-end and back-end, with shared types and everything, largely offset the small quirks. However sometimes I kinda miss some functional stuff that you can for example find in Scala or Rust, like pattern matching. Specifically, we've had experience using…

Pattern matching seems to be a current proposal, also driven by Microsoft: https://github.com/tc39/proposal-pattern-matching

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#204

Post by Fannon »

cryptica wrote: post #148
nicoburns wrote: post #127

Earlier quoted context omitted.

Type systems can be thought of as low-cost (in terms of dev time) declarative tests. Which should leave you with less to test in your actual tests. They also give much quicker feedback than tests.

Is TypeScript low-cost? Most TS projects I've worked on had at least a 10 to 30 seconds build waiting time per iteration. This means that every time I make a change and run the tests, I need to wait 10 to 30 seconds. With my iterative test-driven approach, I probably iterate about once every minute on average (also, my development iteration time gets faster as I become more experienced in the project). So 30 seconds…

Are you aware of tsc options like --watch and --incremental ?

Combined with other live-reloading tools like nodemon or jest --watch you can have almost the same speed of your development-test-run-debug loops as in plain JS. But you do gain an additional instant feedback channel from the compiler.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#205

Post by cryptica »

the_gipsy wrote: post #182
cryptica wrote: post #146

Earlier quoted context omitted.

My JavaScript integration and unit tests do something better; they tell me exactly what features I broke as a result of my refactoring and let me fix things in the best way possible without regard for the previous structure of the code (which may no longer be relevant anyway; there is usually a good reason why we do refactorings in the first place! It's rarely just about renaming things). I have many stories on the s…

I have the exact opposite opinion on "code lockdown". I believe that unit and integration tests heavily lock down code, so much as being mere checksums. In a project with >90% coverage, I would find refactors dreadful. After any substantial change beyond adding stuff, there were always a myriad of tests failing. Not hard to fix, but simply tedious and dreadful. On the other hand, I have an Elm project with no unit te…

Well designed tests lock down features not code. That's why I mostly write integration tests.

I write unit tests once the project is stable and usually only for parts of the logic that are either very complicated or operationally critical. I try to avoid implementing 'very complicated' modules as much as possible.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#206

Post by bt4u »

heavenlyblue wrote: post #172
bt4u wrote: post #108

Earlier quoted context omitted.

There's no such thing as an untyped programming language that's used in the real world. JavaScript and typescript definitely aren't. Maybe you mean dynamically typed

There’s always that “intellectual” who would say something smart while being absolutely wrong.

Sure. But I'm not wrong

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#207

Post by bt4u »

Sharlin wrote: post #154
bt4u wrote: post #108

Earlier quoted context omitted.

There's no such thing as an untyped programming language that's used in the real world. JavaScript and typescript definitely aren't. Maybe you mean dynamically typed

This is just a question of semantics. In mainstream programming language jargon it’s ”dynamically typed”, while in (applied) type theory it’s ”untyped” or, perhaps more accurately ”monotyped” or ”unityped”, because types are fundamentally invariants of a program that can be verified without executing it .

Yeah why bother using correct terminology, it's just semantics. Plus is minus. Compiler is interpreter. Up is down. Leg is arm. Let's all just use our own personal definition of things, it doesn't matter

Dynamic typing is not "untyped" in formal theory, I have no idea where you got that from

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#208

Post by Shacklz »

shhsshs wrote: post #58
stefan_ wrote: post #25

Earlier quoted context omitted.

io-ts [1] is what I think most people use for this 1: https://github.com/gcanti/io-ts

Personally I dislike the fact that io-ts requires taking a pure functional programming approach to this validation. For most cases I just want to throw an error if something doesn't match up. My main use case for this is validating that my UI and backend API have the same ideas about the shape of the data, which will either always work or always fail. All errors should be caught during development and testing, so the…

We wrote a bunch of utility methods around io-ts at work with custom error reporting/handling, otherwise it can indeed feel a bit too fp-/boilerplate-heavy for your every day frontend development, especially in combination with other stuff such as rxjs/redux.

But once you have those set up, it's an easy breeze, and the benefits are enormous. Our helper-method with the hopefully self-explanatory name "validateOrThrow(t:TypeGuardForT)" is essentially called at every point where there is some form of incoming external data, and the amount of debugging-headaches that have simply disappeared because of this is mind-blowing.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#209

Post by marcosdumay »

platz wrote: post #181
marcosdumay wrote: post #165

Earlier quoted context omitted.

Aeson is not straightforward at all. Just try doing what the GP is saying he wants to do, you will discover you can't. It is a very good library if you control both sides of the communication, and have fit for purpose interfaces. Otherwise, you are better with any lower level library. Besides, what is it with the strictness of Haskell JSON libraries? There's nothing that will even accept Window's BOM.

You don't have to define a type for Json data in Haskell if you don't want to. Defining a full type is only norm/preference. With Aeson, You always have the option work with a map directly and pull out properties by name. That is also especially useful when you can't predict what keys or shape the data will have

I don't want to detract from Aeson. It's a great library. If you control both ends of your channel, it can be more convenient than the equivalent encoding and decoding on Javascript, and making a JSON library that is more convenient than JS is no small feat.

But it's a very complex library. It may not show at your code interface, but that complexity is there at the documentation and type errors. It is also famous for generating bad runtime messages. There is even another library for fixing this, at the cost of even more complexity.

If you fall outside of its optimum usage scenario, it won't afford you more functionality than a low level parser, so you are much better saving that complexity and going with the parser.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#210

Post by platz »

marcosdumay wrote: post #209
platz wrote: post #181

Earlier quoted context omitted.

You don't have to define a type for Json data in Haskell if you don't want to. Defining a full type is only norm/preference. With Aeson, You always have the option work with a map directly and pull out properties by name. That is also especially useful when you can't predict what keys or shape the data will have

I don't want to detract from Aeson. It's a great library. If you control both ends of your channel, it can be more convenient than the equivalent encoding and decoding on Javascript, and making a JSON library that is more convenient than JS is no small feat. But it's a very complex library. It may not show at your code interface, but that complexity is there at the documentation and type errors. It is also famous for…

Ok, so use a parser then? Not sure what this has to do with comparison to dynlang/js.

OP was complaining that it's hard to type some kinds of payloads.

Sure you could write a custom parser for it.

With fromJSON in fact this is what you write. Maybe if you've only been driving Json instances generically, you never actually written a fromJSON instance in Aeson? I only use generic deriving in the simplest cases.. otherwise just write the fromJSON instance parser

My point was that you can defer parsing up front and just return a map of you don't want deal with the shape.

But sure you could write a custom parser as well, that falls more into the typed philosophy though than what js folks are used to

Post reply on HN