4 ms·

I suspect that developers tend to fall into roughly two kinds of backgrounds. That is static/compiled (c/java/etc) languages vs dynamic/interpreted (ruby/python

by fouc 8y ago

I suspect that developers tend to fall into roughly two kinds of backgrounds. That is static/compiled (c/java/etc) languages vs dynamic/interpreted (ruby/python/js/etc) languages. Perhaps this leads to a different coding styles & expectations. The former end up with a preference for strong typing. Perhaps their coding style also depends on that. The latter don't seem to find types to be a source of bugs.

akiselev 8y ago
To me it seems more like two wildly different forms of PTSD. For the former group (those who prefer static typing), unmaintainable and poorly documented spaghetti code has been the most identifiable source of pain in their career while for the latter, it has been long iteration times due to bureaucratic nightmares caused by compiler and management. Like early childhood experiences, each programmer I've discussed the subject with seems to have their own unique professional experience that has molded their opinions. It's less a religion and more a coping mechanism for bad experiences.
- jondubois 8y ago
  For me, bureaucracy and TypeScript go hand in hand. There are benefits to using TypeScript, but they're not worth the problems. TypeScript gives an illusion of added productivity and safety but when you actually look at results, bug density is exactly the same as JavaScript. As a TS developer, most of your time is spent on catering to the compiler's complaints, but doing so doesn't actually yield any benefits in terms of producing high quality software. TS and TSLint are bandaid solutions which don't address the root problems behind what makes code bad (which 99% of the time comes down to bad design/architecture). TS simply cannot prevent bad design/architecture - It can only formalize it. It's nice to have linted code with everything typed and statically locked into place but that means very little in terms of actual code quality.
  - akiselev 8y ago
    The reason Typescript has been so successful is that many of us don't have a choice in whether the beauracracy exists or not and have to pick up the pieces. Typescript is, by definition, a bandaid. That's what it was designed for.
- jrs95 8y ago
  Personally I've had a good amount of both experiences, and that's convinced me that either one will suck if you let them. Only good development practices can save you.
ska 8y ago
This is a very old conversation; it's worth noting that dynamic compiled languages (e.g. common lisp) are a thing also. Having a good REPL can change the way you look at it also. Weak typing and dynamism just don't go well together, but other combinations are fine. Strong dynamic typing can lead to an "exploratory" approach to coding that looks a bit like what the author describes except that you can do it in such a way that your program compiles and runs the whole time you are fleshing it out, which is nice. I find this sort of exploratory programming to be by far the most productive available in a research/prototyping mode. I do think the model falls down a bit when multiple programmers are involved, and in production. You could argue this is a feature though, as it is strong incentive to not ship the prototype ...

by fouc 8y ago

akiselev 8y ago

To me it seems more like two wildly different forms of PTSD. For the former group (those who prefer static typing), unmaintainable and poorly documented spaghetti code has been the most identifiable source of pain in their career while for the latter, it has been long iteration times due to bureaucratic nightmares caused by compiler and management. Like early childhood experiences, each programmer I've discussed the subject with seems to have their own unique professional experience that has molded their opinions. It's less a religion and more a coping mechanism for bad experiences.

jondubois 8y ago
For me, bureaucracy and TypeScript go hand in hand. There are benefits to using TypeScript, but they're not worth the problems. TypeScript gives an illusion of added productivity and safety but when you actually look at results, bug density is exactly the same as JavaScript. As a TS developer, most of your time is spent on catering to the compiler's complaints, but doing so doesn't actually yield any benefits in terms of producing high quality software. TS and TSLint are bandaid solutions which don't address the root problems behind what makes code bad (which 99% of the time comes down to bad design/architecture). TS simply cannot prevent bad design/architecture - It can only formalize it. It's nice to have linted code with everything typed and statically locked into place but that means very little in terms of actual code quality.
- akiselev 8y ago
  The reason Typescript has been so successful is that many of us don't have a choice in whether the beauracracy exists or not and have to pick up the pieces. Typescript is, by definition, a bandaid. That's what it was designed for.
jrs95 8y ago
Personally I've had a good amount of both experiences, and that's convinced me that either one will suck if you let them. Only good development practices can save you.

ska 8y ago

This is a very old conversation; it's worth noting that dynamic compiled languages (e.g. common lisp) are a thing also. Having a good REPL can change the way you look at it also. Weak typing and dynamism just don't go well together, but other combinations are fine. Strong dynamic typing can lead to an "exploratory" approach to coding that looks a bit like what the author describes except that you can do it in such a way that your program compiles and runs the whole time you are fleshing it out, which is nice. I find this sort of exploratory programming to be by far the most productive available in a research/prototyping mode. I do think the model falls down a bit when multiple programmers are involved, and in production. You could argue this is a feature though, as it is strong incentive to not ship the prototype ...