DEV Community

loading...
Cover image for What Do You Think About Types?

What Do You Think About Types?

solkimicreb profile image Miklos Bertalan ・1 min read

I accidentally posted this on Sunday for a short time, just after promising to continue as a weekly Monday series. In case you saw that post or commented on it, I'm sorry. This is the final republished version.

A few things are becoming de-facto solutions in JavaScript with a lot of tutorials but without much discussion about the practical benefits and reasons. The goal of this series is to talk about these topics.

The rules:

  • Speak about the whys, not the hows. It's okay to include a few favorite libs and patterns but it should not be the main focus of your comment.

  • No Googling! I am interested in Your opinion, experience, anecdotes, and gut feelings.

  • Your comment might get linked or quoted in the weekly summary if you are not asking otherwise. I never quote comments in a negative context.


This week's topic is Types

  • Do you prefer strongly or weakly typed languages?

  • Do you have a favorite language type system wise? What makes it better than the rest?

  • Can you mention situations when using types caught early errors for you?

  • How does TypeScript relate to group projects? Does it make the barrier of entry and cooperation simpler or more difficult compared to vanilla JS?

  • Whatever pops into your mind about types.

All comments are welcomed, there is no wrong answer!

Discussion (11)

pic
Editor guide
Collapse
fpuffer profile image
Frank Puffer

I prefer statically typed languages. I guess the main reason is that types provide valuable documentation for interfaces. They help explaining how to use interfaces correctly and make it harder to use them incorrectly.

Of course it can be cumbersome to declare variables of complex types but that's why modern statically typed languages have type inference.

Actually I never really understood where the supposed productivity boost offered by dynamically typed languages should come from. Maybe it works well for quick prototypes or applications with very short lifecycles. Most software I am working on needs to be maintained for some years.

Collapse
solkimicreb profile image
Miklos Bertalan Author • Edited

I think interface description can be achieved with decent naming only. In this regard type info is just an additional word in the name. It is not essential for a nice description but it catches misuse early.

This is something nice, I must admit. I used to have a lot of if blocks to catch runtime type errors of the arguments in my OSS code because not everyone reads the docs. Since TypeScript got so popular I just add a type def file to my projects. If someone wants type safety they can use TypeScript and vanilla JS guys can still refer to the docs.

Thanks for the (repeated) comment and sorry for the mess with Sunday's post. 😄

Collapse
kayis profile image
K

After using C/C++, Java, Go, TypeScript etc. I wasn't too convinced about types.

But OCaml/Reason changed this. Pattern matching is a pretty practical feature which reveals the use of a static type system right at the start.

Collapse
solkimicreb profile image
Miklos Bertalan Author

Thanks, I will check it.

Collapse
drbearhands profile image
DrBearhands

In impure languages, such as java and c, types primarily seem to be a performance feature. You can get a property of a complex type by adding an offset to the memory location of the parent type.

In pure languages, types have a wider reach as they span over effects and errors as well as data. So in this sense, impure languages tend to have a partial type system at most. This is why many people don't get the point of types.

Going further, you can be a whole lot more specific in your type system. A number isn't just a number.

That said though, I've had plenty of errors in JS and python that would have been prevented with even a basic compile-time type system. "Undefined is not a function", simply using the wrong variable, or forgetting to take a property of a value rather than the value itself. It's easy to forget such details if the algorithm you're working on is taking the majority of your attention.

Collapse
jfbrennan profile image
Jordan Brennan

Written 1,000s of lines of Java and 1,000s more of JavaScript. Cannot think of a single instance where my JavaScript bugs were type related, but definitely have run into issues where Java freaked out because I tried to set an Array to an ArrayList...or something stupid like that!

TypeScript is overrated imo. It's a relatively few people doing it because it makes their JavaScript feel "right" to them (they often come from statically typed languages) and then there's just masses of people following because "it's 2019, duh!"

Collapse
solkimicreb profile image
Miklos Bertalan Author • Edited

Now that I think about it, I never really used the benefit a weak typing in JS. Can anybody mention a case when they changed the type of something (primitive or complex) after declaration and it felt like the right thing to do? I think I mostly enjoy weak typing because I have to write less code, not because it is weak.

Collapse
solkimicreb profile image
Miklos Bertalan Author • Edited

I am more on the contra side again. I used to code in a few statically typed languages (mainly Java) before settling with JS and I enjoy this typeless abomination very much. I feel like I don't need types and I can't mention a case when I ran into a sneaky type related error. This might be false self-comforting though, maybe I never traced my errors far enough before I fixed them.

I only use TypeScript when I am forced by the project requirements but I am not wildly against it. I understand people who like it and I let them be with one exception maybe. I am not a big fan of OSS TypeScript projects. I think TypeScript makes the barrier of entry higher and fends beginners away. Maybe vanilla JS is just as arcane to full-time TypeScript users as TypeScript is to JS newbies though, I don't know.

In general, I am not good with types and I hope to see some exciting comments from the pros. In this field, I am beginner enough to change my mind quickly.

Collapse
itr13 profile image
Mikael Klages

I very much prefer static or inferred typing, the more static testing a language has, the less time I lose on running the program until I notice a simple issue. In the worst case I (or somebody else) might not notice at all until much later.

Some IDEs have less reliable autocompletes when using dynamic typing too, which can be another point of slow-down.

The bigger the codebase, the higher the chance of unintuitive typing, and the more developers, the more chances each of those unintuitive typings have to make somebody do a mistake.

Collapse
solkimicreb profile image
Miklos Bertalan Author

I very much prefer static or inferred typing, the more static testing a language has, the less time I lose on running the program until I notice a simple issue. In the worst case I (or somebody else) might not notice at all until much later.

This sounds nice. I usually use vanilla JS with a linter which catches a lot of stuff without running the code. I guess the same would be true about static typing.

Some IDEs have less reliable autocompletes when using dynamic typing too, which can be another point of slow-down.

Yes, I feel like JS autocompletion is far from perfect. (I did not spend much time on setting it up though.)

The bigger the codebase, the higher the chance of unintuitive typing, and the more developers, the more chances each of those unintuitive typings have to make somebody do a mistake.

Honestly, I can't think of an occasion when I checked another dev's code and types would have helped me understand it faster. I either know the correct type on an instance or have to go through a lot of code to understand what the dev wants. (I wouldn't trust interfaces when the code is messy.)

Collapse
larsklopstra profile image
Lars Klopstra ⚡

I really like flexible languages like TypeScript or Dart, sometimes it's just too obvious or redundant to add types to a method or variable (bool, string, void).