Since i dont have much expericen with elixir i dont know why most of you think typespec doesnt help much. Any eg where typespecs doesnt work as like some other staticaly typed lang??
I can’t remember a single person on this forum hating or even disliking typespecs or static types.
5 Likes
No one hates them. The issues people raise with respect to static typing is that typespecs are opt-in and not really enforceable. So you can still compile your code and end up with runtime errors due to mismatched types. I admit to struggling with the syntax of typespecs for a while, but now I find them very useful for not only reading code but also organizing my thinking while writing code.
7 Likes
What those people want is for the typespecs to be strictly enforced, so you cannot compile the code if you have a mismatch. But as @stevensonmt mentioned, they are optional - basically just an extension of documentation.
2 Likes
I’m just learning Elixir and I tried typespecs once, but I found the error-messages very cryptical. Also I find the handling of multiple function heads confusing.
Dialyzer is happy if just one function matches the spec.
Anyway I ended up deleting all typespecs and adding a TODO “add typespecs” 
I don’t use typespecs because the time to utilize them is too long (in isolated CI), I find the syntax a bit hard to grok, and I believe that it’s very easy for the specs to not reflect reality. I once worked on a project where the team wanted to convince me that specs were a good thing. I looked through the existing source and a good many of the (passing) specs were completely incorrect. That was a major red flag about the specs being more harm than good.
This goes with another one of my general beliefs that “documentation kept separate from code will diverge 100% of the time”. Even putting them in the same file (on top of each other) is not enough. In order to truly be effective, they’d need to be used on every compile and fail to compile if they were invalid. Or be evaluated dynamically in the test suite such that any input/output that doesn’t match the spec raises an error (does this exist?)
I do let Dialyzer run via my VSCode extension and I actually find it fairly enjoyable. However, I view that as a development tool and not something I want to add 10+ minutes to CI for.
3 Likes
To me it feels like most of the “dislike” for typespecs is not actually about the specs, but dialyzer and the comparison to static type systems. For me typespecs are a way to lessen the need to hunt down into implementation details of the input/output of functions at higher levels in the codebase. This is even more useful when working with third party code.
Say I have a conn and want to know how headers are stored on it. Looking at Plug.Conn.t will provide me with that without needing to search for something similar in running text documentation. Also typespecs describe the data instead of giving examples. E.g. a input of pos_integer() is far more descriptive than having an example in the documentation use 4 as input.
In my experience not having typespecs mostly means not having any information like that at all, which makes working with the code, but also reviewing it, more difficult.
3 Likes
Oh yea, good point regarding usage of code more difficult. I forgot to add to my post that published libraries absolutely should have typespecs for the reasons you mentioned. It provides great documentation and people that do use typespecs benefit from it. My post was regarding my private applications.
1 Like
