Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I would say it is best to do both TDD and have a statically typed language with explicit types written down for every variable. The latter mainly for readability. Let us look for a minute at how mathematicians write things. It is like 'let n be a natural number, let f be a function from the reals to the reals and so on...'. It would be very inconvenient if they wrote things like 'let us have some symbols n and f and you will now have to read the rest of the text to try to figure out what they are....'. It is quite telling that in python it now became customary to include a kind of docstrings to document every parameter. However, no automated process is checking these so they may not be true. So then we start using mypy and, voila, there we are again with static type annotations for every parameter. The whole dynamic language thing was just a detour that did not make anything better. They saved the author a few seconds at the cost of the person trying to read the code taking a few minutes to find out what the type of the parameter was. I also think one should use the 'auto' keyword in C++ quite sparingly.


> let us have some symbols n and f and you will now have to read the rest of the text to try to figure out what they are...

This point is mostly relevant for mathematics. When you define a variable in a program the reader can easily infer the type by the value it was initialised with. Sure, if you just see "10" you don't know if it's a byte or a long int, but that doesn't matter because only the compiler needs to infer those details. For reading the code it's enough to know it's an integer. I agree about complex types, though. In Python and pure JS it gets really complicated when you have to find out about a dictionary's/object's fields by looking at code inserting them one by one.


>When you define a variable in a program the reader can easily infer the type by the value it was initialised with.

This breaks exactly when you're dealing with more than one function. Then you have to guess the types of the whole chain of functions.

And maybe that function is used in multiple places, now you need to guess the types of all the places where this function is used.


While I agree with most of what you said, the things you mentioned are more about type inference and good naming than static vs dynamic typing. (While you definitely shouldn't) You can, for example, write Haskell without ever naming a single type.

Considering the use of features like auto, I personally prefer writing unspecified variables while programming and getting the statically inferred types live from the IDE, which for example aids when composing a complicated expression whose type I don't fully know while writing.


The auto keyword in C++ is great because it helps you avoid unintended type conversions in assignments. For that reason it should be used widely IMHO. The downside is that it makes it slightly harder to read code outside of an IDE.


> The downside is that it makes it slightly harder to read code outside of an IDE.

If that’s how you feel about auto, wait until you see something like rust’s post-facto type inference.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: