6 ms·

> Based on this, it's hard not to state that current Node-developer are the new PHP-developers: Unsophisticated, completely unable to see when the tools at hand

> Based on this, it's hard not to state that current Node-developer are the new PHP-developers: Unsophisticated, completely unable to see when the tools at hand are lacking, and happy with a with whatever they can get running. Comments like this are not the problem with HN. The fact that they get voted, literally, to the top, is.

brlewis 9y ago
Freshness also raises comments higher, not just voting. In time this one will drop.
_pmf_ 9y ago
Do you know why I, personally, agree with this statement to the greatest extent? Because 17 years ago, I had this same naive development workflow. With PHP, exactly as OP mentioned. Whenever someone mentions static typing, the canned response from JS developers is "Oh, haha, we actually have unit tests for this" (usually accompanied with a patronizing smile for the obsolete waterfall programmer). Yet when dealing with a real world dynamically typed application from some mediocre company, there are (surprise) no unit tests at all.
- cookiecaper 9y ago
  Unit tests are a completely inadequate replacement for typing even if they actually do exist, which, as you stated, is pretty rare. I think the best compromise is optional typing. The language should encourage it by default, but allow some variables to be declared as dynamic/untyped. This greatly simplifies things like parsing of JSON data, which should essentially all be considered a string until there's some reason to consider it something else, but enforces consistency and safety through most of the application. Haxe does a pretty OK job with that.
  - _pmf_ 9y ago
    > I think the best compromise is optional typing. The language should encourage it by default, but allow some variables to be declared as dynamic/untyped. Like C#'s dynamic keyword (not to be confused with its var keyword, which just does type inference).
mattmanser 9y ago
It's not a bad comment, it's just blunt. I also have a similar stories as the parent commentator, 8-10 years ago when you had even more awful programmers I would sometimes agree to fix something for someone desperate as their own coder had disappeared/failed/etc.. Sometimes even in a language I'd never even used. I'd open some random PHP project, or VBScript, or whatever and find loads of commented out print statements surrounded by some godawful code. And it'd often be quite a simple logic bug that I could see straight away. Regularly using logging for debugging is often an inexperienced developer's crutch. It's a red flag, the sign of the desperate, that they can't comprehend their own code or don't seem to understand the business logic. It can be a bad substitute for replicating the problem, reading the code + using a debugger. Sometimes it really is justified. The author seems to have relied on it a lot though.
- brlewis 9y ago
  >Sometimes it really is justified. Like in the situations in the article. That's why the comment in question is not just blunt. It's a bad comment. A good comment would take a specific instance of using logging and said why setting a breakpoint / using a debugger would have solved that particular mystery faster.
  - mattmanser 9y ago
    I've read the article. Obviously I haven't seen the actual problem, but as an experienced developer, I feel that: NaN bug doesn't sound like it needed logging Mutability bug doesn't sound like it needed logging Dependencies and versions bug doesn't sound like it needed logging The Documentation and versions bug doesn't sound like it needed logging Obviously we're not seeing the whole picture or the whole bug. But that's 4/5. Most of those sound like they needed a simple step-through. For example, in the documentation and versions async.js bug, he added "extremely verbose" logging where it appears that a simple step-through would have immediately revealed to him the passed arguments were wrong and the signature of the method didn't match the documentation. Which would have made him realize he had the wrong version. The only one where I would expect to have to use logging is the tests bug.

brlewis 9y ago

Freshness also raises comments higher, not just voting. In time this one will drop.

_pmf_ 9y ago

Do you know why I, personally, agree with this statement to the greatest extent? Because 17 years ago, I had this same naive development workflow. With PHP, exactly as OP mentioned. Whenever someone mentions static typing, the canned response from JS developers is "Oh, haha, we actually have unit tests for this" (usually accompanied with a patronizing smile for the obsolete waterfall programmer). Yet when dealing with a real world dynamically typed application from some mediocre company, there are (surprise) no unit tests at all.

cookiecaper 9y ago
Unit tests are a completely inadequate replacement for typing even if they actually do exist, which, as you stated, is pretty rare. I think the best compromise is optional typing. The language should encourage it by default, but allow some variables to be declared as dynamic/untyped. This greatly simplifies things like parsing of JSON data, which should essentially all be considered a string until there's some reason to consider it something else, but enforces consistency and safety through most of the application. Haxe does a pretty OK job with that.
- _pmf_ 9y ago
  > I think the best compromise is optional typing. The language should encourage it by default, but allow some variables to be declared as dynamic/untyped. Like C#'s dynamic keyword (not to be confused with its var keyword, which just does type inference).

mattmanser 9y ago

It's not a bad comment, it's just blunt. I also have a similar stories as the parent commentator, 8-10 years ago when you had even more awful programmers I would sometimes agree to fix something for someone desperate as their own coder had disappeared/failed/etc.. Sometimes even in a language I'd never even used. I'd open some random PHP project, or VBScript, or whatever and find loads of commented out print statements surrounded by some godawful code. And it'd often be quite a simple logic bug that I could see straight away. Regularly using logging for debugging is often an inexperienced developer's crutch. It's a red flag, the sign of the desperate, that they can't comprehend their own code or don't seem to understand the business logic. It can be a bad substitute for replicating the problem, reading the code + using a debugger. Sometimes it really is justified. The author seems to have relied on it a lot though.

brlewis 9y ago
>Sometimes it really is justified. Like in the situations in the article. That's why the comment in question is not just blunt. It's a bad comment. A good comment would take a specific instance of using logging and said why setting a breakpoint / using a debugger would have solved that particular mystery faster.
- mattmanser 9y ago
  I've read the article. Obviously I haven't seen the actual problem, but as an experienced developer, I feel that: NaN bug doesn't sound like it needed logging Mutability bug doesn't sound like it needed logging Dependencies and versions bug doesn't sound like it needed logging The Documentation and versions bug doesn't sound like it needed logging Obviously we're not seeing the whole picture or the whole bug. But that's 4/5. Most of those sound like they needed a simple step-through. For example, in the documentation and versions async.js bug, he added "extremely verbose" logging where it appears that a simple step-through would have immediately revealed to him the passed arguments were wrong and the signature of the method didn't match the documentation. Which would have made him realize he had the wrong version. The only one where I would expect to have to use logging is the tests bug.