5 ms·

This looks like how I used to work with BASIC back in the 80s: > I finally added extremely verbose logging ... started adding logging ... Verbose logging to th

This looks like how I used to work with BASIC back in the 80s: > I finally added extremely verbose logging ... started adding logging ... Verbose logging to the rescue ... I had the right logging in place ... My first step was to jump in and add some key logging statements ... added extremely verbose logging 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. 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.

nilliams 10y ago
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_integration_for_node_js https://nodejs.org/api/debugger.html#debugger_v8_inspector_i...
ovi256 10y ago
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.
scient 10y ago
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.
lhnz 10y ago
> 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.
- mattmanser 10y ago
  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.
  - lhnz 10y ago
    > 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.
    - mattmanser 10y ago
      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.
douche 10y ago
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.
devwastaken 10y ago
>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.
libertymcateer 10y ago
> 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 10y ago
  Freshness also raises comments higher, not just voting. In time this one will drop.
- _pmf_ 10y 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 10y 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_ 10y 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).
brlewis 10y ago
>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.
- mattmanser 10y ago
  I disagree. He simply had to inspect the live DB and see what the state was when someone said the order was wrong.
barleymash 10y ago
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?
root_axis 10y ago
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.
- jimmaswell 10y ago
  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".
  - zlynx 10y ago
    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.
  - root_axis 10y ago
    > 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.
blauditore 10y ago
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.

nilliams 10y ago

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_integration_for_node_js https://nodejs.org/api/debugger.html#debugger_v8_inspector_i...

ovi256 10y ago

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.

scient 10y ago

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.

lhnz 10y ago

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

mattmanser 10y ago
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.
- lhnz 10y ago
  > 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.
  - mattmanser 10y ago
    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.

douche 10y ago

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.

devwastaken 10y ago

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

libertymcateer 10y ago

> 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 10y ago
Freshness also raises comments higher, not just voting. In time this one will drop.
_pmf_ 10y 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 10y 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_ 10y 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).

brlewis 10y ago

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

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

barleymash 10y ago

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?

root_axis 10y ago

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.

jimmaswell 10y ago
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".
- zlynx 10y ago
  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.
- root_axis 10y ago
  > 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.

blauditore 10y ago

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.