> 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.

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.

>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.

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.

Interactive debugging is a useful tool, but it can encourage lazy reasoning. People just write something and step through until they notice some change they don't expect. That's fine and everything, but talking about "crutches" and tooling, it sounds like you may be a little biased toward big-IDE style development that makes the debugger the automatic answer v. some reasoning over the code and extra logging of potential trouble spots. There's nothing wrong with logging output v. stepping through in an interactive debugger per se.

Logging is lazy reasoning. Stepping through is simply seeing what is happening with a bug you can replicate. Stepping through is the step in debugging after reading the code.

Even after you've read the code and think you've spotted the problem, you should step through to 100% confirm you've understood the problem.

It's simply confirming the bug and the solution, it's good science, it's good practice. It's empirical.

My comment about the NaN bug: https://news.ycombinator.com/item?id=14156595

I disagree with that assessment. Users reported the order was wrong, he simply had to look at those users and their live data to replicate it.

Even in those scenarios, I rarely have to look at live data, reading the code is often enough to identify it or playing around a little bit. The patience to replicate a bug before trying to fix it.

This is the essence that sets apart a good debugger from a bad one. A bad one resorts to littering the code with print/log statements because either they can't replicate the problem or they simply can't run the code in their head.

I'm being unfair, it's not even that, they simply need more experience. When I was younger I remember complaining that exception stacks were utter gobbledigook, utterly useless. Now, I read one and often know exactly what the bug is. I was completely and utterly wrong, impatient and unwilling to admit my ignorance. At the time I thought I was wise and knowing. They're very useful, I simply didn't understand them.

My "simply" from above belies the years of experience I have.

I have had times when I used logging and then realized I should use a debugger instead.

I have had times when I used a debugger and then realized I was never going to find the problem that way; I needed a larger amount of information that only logging could provide.

I've only been programming about 30 years so I probably haven't hit my peak yet, but my guess is that even with more experience I'll still want to use both tools.

Debug logging doesn't have to be litter either. Instead of commenting out use log levels like with https://www.npmjs.com/package/debug-logger

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.

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.

> 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).

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

Frankly, I find your condescending insults to "x-developers" to be a sign of unsophistication, that aside, in my experience, logging is preferable to running a debugger in most situations. Logging gives you an immediate output about the particular state you're concerned with as opposed to using a debugger which slows you down while you fiddle with breakpoints, slowly step through code, hover your mouse over variables and watch values (which are essentially the same thing as logging variables) sometimes with its own side effects (.e.g networking timeouts because of paused execution). Also, logging is mandatory in production because attaching a debugger in production is, at best, a measure of absolute last resort and at worst a fireable offense.

A debugger is a tool like any other, and sometimes it provides unique benefits, like if you're new to a complicated project that lacks appropriate logging and/or you'd like to step through code to try and understand the code's flow, but for tackling individual issues, I would be concerned about non-junior developers who consistently rely on a debugger for solving problems in code.

Are you really implying writing a bunch of print statements is more "professional" than a debugger? Debuggers are incredibly useful in tracking certain things down and don't make you write and then remove a ton of logging statements. Sometimes logging is easier, sometimes debugging is, and not just for "junior devs".

> Are you really implying writing a bunch of print statements is more "professional" than a debugger?

This is quite a loaded question, so let's unpack it a bit.

1. I made no implications regarding anything, my point is explicitly laid out with clear reasoning and examples.

2. I never made any remarks regarding how the use of any particular tool reflects on one's professionalism. I am guessing you're conflating my remark with regard to junior-level experience with the qualities of professionalism, and if that's the case I'll clarify that being junior does not in any way reflect on one's professionalism.

3. Your flippant dismissal of logging as "a bunch of print statements" is unfortunate and broadcasts a blind-spot in your knowledge of how robust logging is a critical component of any properly engineered software project, especially network services of any kind. It's not an either or question, logging is a must-have business/operations concern, whereas a debugger is a nice-to-have developer concern.

> Debuggers are incredibly useful in tracking certain things down and don't make you write and then remove a ton of logging statements.

You shouldn't be writing and removing a ton of logging statements, logging should be a planned and permanent part of your application from the beginning with appropriate severity labelling for debugging as well as run-time analysis purposes. If you want to use a debugger, that's fine, but a debugger is not a replacement for logging.

> Sometimes logging is easier, sometimes debugging is, and not just for "junior devs".

As I already stated in this comment, that's a false choice, logging should be the minimum, the debugger is there if you really want/need it. I never stated that the debugger is only for junior devs, I said I'd be concerned if a non-junior dev consistently relied on a debugger for solving problems in code, which is not at all the same thing. The use of a debugger is appropriate at any experience level, but generally speaking, the debugger is a slow troubleshooting tool that is best suited for exploring code flow or unusual bugs that seem to defy bedrock assumptions about how the application should be functioning. They are not the best tool for everyday bugs and troubleshooting.

I agree that debuggers aren't always the right tool. Use it only when you have a reproducible bug configuration running on your desktop.

There are fancier setups than "print statements", like binary lock-free logs to circular memory maps. But in essence, print statements, yes.

And heh, I just realized that if you're using a debugger with reversible execution tracing, you're using EXACTLY a binary log file.

  > 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.

Some Node engineers do use debuggers sometimes, particularly those that came from environments in which this is common (Java, etc). However, many Node engineers I've worked with rely on unit testing, keeping functions very simple and intuition.

Btw the tooling in the Node ecosystem is actually pretty good.

All you've done is move the problem. What happens when the unit test fails and you want to step through the process to see why?

You also seem optimistic, unit test don't catch new bugs, they just test for typos and the bugs you already knew about.

> You also seem optimistic, unit test don't catch new bugs.

You write a new unit test using the data which caused the bug but expecting a non-error state. The error that is being thrown/rejected will have a stack trace you can inspect to find the line which threw. To find the real cause you need to read the code before this to find out how the bad state was created.

If you kept things small and simple, it is not so difficult to work out what went wrong. If you let things grow in complexity too much, you can however end up within a breakpoint/log quagmire.

In the idealized functional world that doesn't exist, maybe.

Programming anything beyond a small app is ultimately managing complexity and often fixing how the various moving parts don't quite work together as you intended.

You simply can't, and shouldn't, unit test that stuff.

>Weird to see people happy to be limited to such stone-age work-flows when fully capable debuggers have existed for almost all proper languages out there the last 30 years.

Even though node has a debugger with breakpoints, etc., an effective programmer will still use logging in situations like the ones in the article. Taking the first example, before he knew that NaNs were causing the problem, setting a breakpoint would have taken forever to reveal anything. You can't set a conditional breakpoint until you know what the condition is. Logging was the fastest way to get useful clues.

I disagree. He simply had to inspect the live DB and see what the state was when someone said the order was wrong.

Yeah this is pure ignorance. There is a time and place for advanced profiling/debugging tools, and there are times where using simple logging to debug things quickly is perfectly fine. You applying debuggers as a hammer to all the problems and all the people is the thing thats weird imho.

In some cases here, he's talking about fixing bugs in a production. It's not so simple to attach a debugger to a live application serving 100s of requests. Break and you just 500'd all users.

In others granted he's working locally and probably could have found the problems without logging, but that just comes down to preference IMO.

Node does have a debugger though and recently added official (though experimental) support for attaching the Chrome DevTools debugger [1]. Doing so was doable via 3rd party packages previously.

Edit: updated as author wasn't only talking about in-production.

[1] https://nodejs.org/api/debugger.html#debugger_v8_inspector_i...

>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.

PHP has had debugging for a long time, PHPStorm is pretty much now the standard in php development and includes full productivity in that area. It also doesn't face the issues web-JS has with pre-processing, post-processing and compilation of JS code that has to have a source map back to the original source.

This is a case of developper ignorance, not missing tools: v8 has an integrated debugger since 2009, and you can interact with it using the Chrome developer tools, probably the most used debugger frontend of all.

There are also debuggers for PHP :) No horse in this race, I write Python.

It also sounds to me like they didn't have any proper unit tests, which is quite a low-hanging fruit for sorting algorithms.

Also, while I agree mostly with you, there are cases where logging is more useful for debugging than using step-through debuggers. However, such problems are usually related to concurrency where a debugger may alter or even hide the problem, not stuff like this here.

Sometimes, there's no substitute for println debugging.

Particularly with real-time, concurrent code where you're interacting with an external system, bringing a thread to a halt in your debugger causes all sorts of false-positive timeout bugs. You get about one shot to break with the debugger, then your state is trashed and you have to start over.

This is absolute garbage. How can you state that users of a language are unsophisticated? You can make the argument that certain languages ALLOW you to be an unsophisticated developer, have lower barriers to entry, or give you enough rope to hang yourself, etc. But your logic here just does not make any sense. How can you call someone unsophisticated for KNOWING something?

I would bet that most developers know more than one language. So what if you develop with Python, C++, and Node? Does the singular fact that you develop with Node make you a shitty programmer?