To view parent comment, click here.
To read all comments associated with this story, please click here.
If by readability, you mean more noise and clutter in source code, then I agree. If by readability, you mean the ability to decipher code, then I disagree.
Programmers don't decode code linearly, or one line at a time. Code is decoded in context of modules, classes, functions, blocks and surrounding code. Lets take your example:
perms = getPerms()
As far as I'm concerned "perms" is just a reference to data containing information about permissions. Cognitively speaking, that's perhaps all I need to know. Information about its type, size, properties, methods, attributes or behavior is almost likely irrelevant and thus a cognitive burden or distraction.
What's most important is if I can figure out the purpose of "perms" in the context it is being used. I don't see how prepending type information before "perms" makes code easier to decipher. Does it really matter whether "perms" is a float, string, list, vector, integer or custom object? Or is all we need to know that "perms" is just data containing information about permissions? My response to the last two questions is No and Yes for most situations.
The reality is that type information in source code has historically and conventionally been used to aid archaic compilers (especially for performance and optimizations), not to promote readability. The good news is that Modern sophisticated compilers can now determine, or "infer", type information without you having to litter source code with noise and largely irrelevant information (e.g. type information). Hopefully, the next generation compilers will have this as a mandatory feature.
I just don't see the correlation between adding type information in source code and improved readability. In fact, I see just the opposite.
> > I personally think types add readability
>
> If by readability, you mean the ability to decipher code,
> then I disagree.
Who are you to have an opinion on how I perceive things? How incredibly arrogant of you!
> Information about its type, size, properties, methods,
> attributes or behavior is almost likely irrelevant
Well, "almost likely" implies "not likely", so I guess I agree. Seriously, if you have to use the permissions data (and you probably do since you called getPerms()) then you need to know what it is.
> Does it really matter whether "perms" is a float, string,
> list, vector, integer or custom object? [...] No
Sure it does. I have to know if perms is a set of permissions or a map of sets or what. And once I know that it's a map I have to know if the keys are user IDs or user objects or groups or what. It could be almost anything. And then I need to know how to interpret the values, so I have to know if they are sets of permission IDs or permission objects or what, so that I can do with them what I need them for.
All this information has to be somewhere. If it's not in the semantics enforced by the language syntax then it'll have to be in the docs or some comments or somewhere. I personally prefer to have it in the language.







Member since:
2005-07-06
> Your claim that dynamically typed languages is not good
> for "complex" projects/problems is bogus.
I can't speak for the guy making that claim (or for anyone else for that matter), but I personally think types add readability, a lot.
E.g., consider these two lines:
var perms = getPerms()
Map<User, Set<Permission>> perms = getPerms()
Which one conveys more information?
The added information brings with it the burden of having to write more (although good code completion support helps a lot). If typing is optional many people don't use it, so as long as I don't have complete control over all code I use I want the language to have static typing.