7 ms·

I consider regular expressions to have the rare and elusive "write-only" flag set. Those bastards are almost impossible to decipher after the fact. I incrasing

I consider regular expressions to have the rare and elusive "write-only" flag set. Those bastards are almost impossible to decipher after the fact. I incrasingly consider dynamic languages to fall into the same "write-only" camp. One week get work done fast and efficiently. A few weeks later a new edge case is encountered and it doesn't work. Figuring out exactly why can be more than a little frustrating. Dealing with code other people wrote can be even worse. Yes the language is dynamic. No the expectations are not. If you call a function with some object and it's not the right kind then it's either not going to work or it won't work like you expect. Jumping into the middle of a system and trying to figure out what the requirements and expectations are for every object in every function is a collosal waste of time. Yes it could be documented, and that takes even more time! Static typing makes it remarkably clear and straight forward.

deleted 12y ago
[deleted]
nine_k 12y ago
The OP says that much of the static typing benefits are in documenting code. Having code properly documented, in a machine-verifiable form, is no small benefit. It's what maintainability is based on.
- dllthomas 12y ago
  It's worth noting that one can hack together some machine-checkable documentation orthogonal to typing, too. As a limited example, I do this with inline TODOs (in a greppable format) while I'm working my way through a problem.
  - carussell 12y ago
    Machine-verifiable TODO items sounds interesting. If this comment was bait, it worked. Where're some examples I can look at?
    - dllthomas 12y ago
      I don't have much relevant posted anywhere. The gist is "git grep TODO", but I do a little extra work to make it extra convenient with vim's quickfix buffer: search: @git grep -n "$$PATTERN" todo: @PATTERN=TO''DO make search \ | sed -n 's/$[^ \t]*$$.*TO''DO \(([0-9]*)$\):\?$.*$/\1 \3 \2\4/p' | sort -k 2 Running ":make todo" in vim then pulls everything of the form "TODO (1):" out, sorts according to priority (the value in parentheses), and dumps them into my quickfix buffer (including the locations), which I can easily step through. I also surface changes in the todo list as comments in my git commit buffer, for reference.
bunderbunder 12y ago
This is about where I've come down. Back when my job involved writing a lot of greenfield code that I'd also never have to look at ever again, I was pretty fond of dynamic languages. Nowadays I'm working on a big product with a codebase that ain't getting any younger. For this job, I'm inclined to say static typing is a godsend. Sometimes you can tell a lot about what a function's supposed to do by its parameter and return types that you can't tell by its probably-nonexistent comments or its cryptic name. That said, the last two languages I've worked in both allow you to forego strong typing in favor of duck typing, and sometimes that feature's a godsend, too. I'm starting to think of it roughly the same as I think about mutability: Dynamic typing may not be a great default for maintainability reasons, but at the same time sometimes it's great to have the option for pragmatism's sake. (None of this being anything I can back up empirically, of course.)
oakwhiz 12y ago
Whenever you find yourself potentially writing "write-only" code, it's worth it to take the extra time to split everything with newlines and insert lots of comments. Some people think over-commenting is bad, but in my opinion, I'd rather take verbose comments over obfuscated code any day.
- dllthomas 12y ago
  In my experience: Accurate comments and confusing code is better than no comments and confusing code, which is better than confusing comments and confusing code. Clear code is better than any of these, regardless of the comments. Necessary comments with clear code is better than no comments with clear code, which is better than superfluous comments with clear code, which is better than inaccurate and confusing comments with clear code (in which case the easiest transition is to "no comments with clear code).

deleted 12y ago

[deleted]

nine_k 12y ago

The OP says that much of the static typing benefits are in documenting code. Having code properly documented, in a machine-verifiable form, is no small benefit. It's what maintainability is based on.

dllthomas 12y ago
It's worth noting that one can hack together some machine-checkable documentation orthogonal to typing, too. As a limited example, I do this with inline TODOs (in a greppable format) while I'm working my way through a problem.
- carussell 12y ago
  Machine-verifiable TODO items sounds interesting. If this comment was bait, it worked. Where're some examples I can look at?
  - dllthomas 12y ago
    I don't have much relevant posted anywhere. The gist is "git grep TODO", but I do a little extra work to make it extra convenient with vim's quickfix buffer: search: @git grep -n "$$PATTERN" todo: @PATTERN=TO''DO make search \ | sed -n 's/$[^ \t]*$$.*TO''DO \(([0-9]*)$\):\?$.*$/\1 \3 \2\4/p' | sort -k 2 Running ":make todo" in vim then pulls everything of the form "TODO (1):" out, sorts according to priority (the value in parentheses), and dumps them into my quickfix buffer (including the locations), which I can easily step through. I also surface changes in the todo list as comments in my git commit buffer, for reference.

bunderbunder 12y ago

This is about where I've come down. Back when my job involved writing a lot of greenfield code that I'd also never have to look at ever again, I was pretty fond of dynamic languages. Nowadays I'm working on a big product with a codebase that ain't getting any younger. For this job, I'm inclined to say static typing is a godsend. Sometimes you can tell a lot about what a function's supposed to do by its parameter and return types that you can't tell by its probably-nonexistent comments or its cryptic name. That said, the last two languages I've worked in both allow you to forego strong typing in favor of duck typing, and sometimes that feature's a godsend, too. I'm starting to think of it roughly the same as I think about mutability: Dynamic typing may not be a great default for maintainability reasons, but at the same time sometimes it's great to have the option for pragmatism's sake. (None of this being anything I can back up empirically, of course.)

oakwhiz 12y ago

Whenever you find yourself potentially writing "write-only" code, it's worth it to take the extra time to split everything with newlines and insert lots of comments. Some people think over-commenting is bad, but in my opinion, I'd rather take verbose comments over obfuscated code any day.

dllthomas 12y ago
In my experience: Accurate comments and confusing code is better than no comments and confusing code, which is better than confusing comments and confusing code. Clear code is better than any of these, regardless of the comments. Necessary comments with clear code is better than no comments with clear code, which is better than superfluous comments with clear code, which is better than inaccurate and confusing comments with clear code (in which case the easiest transition is to "no comments with clear code).