Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hard-won lessons: Five years with Node.js

blog.scottnonnenberg.com

Post reply on HN
Print view View original

271–280 of 365 posts

Re: Hard-won lessons: Five years with Node.js

#271

Post by barleymash »

josteink wrote: post #232

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…

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?

Re: Hard-won lessons: Five years with Node.js

#272

Post by _pmf_ »

libertymcateer wrote: post #263
josteink wrote: post #232

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…

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

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.

Re: Hard-won lessons: Five years with Node.js

#273

Post by therpe1 »

rusk wrote: post #194
rapsey wrote: post #158

Earlier quoted context omitted.

No I want to use the command line. https://maven.apache.org/guides/getting-started/maven-in-fiv... Maven quick start first command: > mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false Then it generates stupidly deep Java structure. and next you have to write a verbose xml. They even say: > The POM is huge and can be daunting…

Maven is a "bad example" - it's horrible. Everybody agrees.

Maven is great. Not perfect but it's far better than the alternatives. And every single time I've seen somebody come along and insist they have a better alternative the result is always worse or requires significant custom development.

As for the idea that Java IDEs like Eclipse and IntelliJ are these "big heavy tools" -- it's just silly and outdated. It might've been true 15 years ago. (Flashback to 2004 and getting a cup of coffee while Eclipse starts.) These days Eclipse and IntelliJ launch instantly and feel just as lightweight as the command line. I'm often running multiple IDEs at the same time with no performance impact.

Any Java shop that's any good doesn't depend on an IDE. The idea that you can't do anything without an IDE is wrong. A team doing continuous integration and deployment is damn well going to make sure that everything that needs to be done can be done from the command line. Nobody cares what you use to edit code on your own computer as long as you don't use tabs!

Re: Hard-won lessons: Five years with Node.js

#274

Post by mattmanser »

lhnz wrote: post #243
josteink wrote: post #232

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…

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

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.

Re: Hard-won lessons: Five years with Node.js

#275

Post by josteink »

beaconstudios wrote: post #260
lostboys67 wrote: post #246

Earlier quoted context omitted.

"but a compiler does not by definition have to compile your code before deployment" Huh? Not sure many experienced developers would agree with you a JIT Compiler is quite different to a real compiled language C Fortran Etc

a compiled language, yes. But the function of a compiler, between a compiled language and an interpreted language, remains the same. It translates code from one representation to another.

This is really simple. Do you use V8 to compile your code or to run it?

Just because V8 has a compiler, doesn't make it a compiler. Do you see the difference?

Re: Hard-won lessons: Five years with Node.js

#276

Post by lhnz »

mattmanser wrote: post #274
lhnz wrote: post #243

Earlier quoted context omitted.

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

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.

Re: Hard-won lessons: Five years with Node.js

#277

Post by srpablo »

foldr wrote: post #219
digitalzombie wrote: post #134

Earlier quoted context omitted.

> Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. Ain't nobody is going to compare performance against Erlang for numerical number crunch. It was never built for that. It's not even a fair comparison. It's like comparing a race car against a hybrid prius and saying the race car suck at mpg. They're built for different purposes. Ilk implies as if Erlang is some crap flavor flav tech. It is no…

>It was never built for that. It's not even a fair comparison. No, but it means I can write relatively computationally intensive server side code in JavaScript rather than having to switch to C and use an FFI. It's always nice to have decent performance, even if it's irrelevant most of the time for web programming. Erlang is great but its ecosystem is tiny compared to Node's, and as a programming language it's at lea…

> Erlang is great but its ecosystem is tiny compared to Node's, and as a programming language it's at least as quirky as JavaScript.

I disagree with this; while the syntax is unusual for many, its semantics are extremely simple and clear. I don't think it has anything quite like:

* JavaScript having `null` and `undefined`. * JavaScript lacking have proper integers. * JavaScript strings being UTF-16, so things like "".length don't work. * Scoping of 'this'. * The unmanageable automatic typecast rules * Semicolon insertion. * JavaScript `with (x) {` (maybe a cheap shot since it's so uncommon, but we are talking about language design).

Main quirks I can think of for Erlang are when people trip up over "strings", >, and iolists. But I'd love to hear where others run into proper semantic quirks.

Re: Hard-won lessons: Five years with Node.js

#278

Post by mattnewton »

hota_mazi wrote: post #94
mattnewton wrote: post #76

Earlier quoted context omitted.

The edit/refresh cycle starts to slow as the project grows in Java, but node has pretty close to zero startup time and is interpreted. That plus a repl supports a much more explorative coding style where things work as fast as you can add them. No JVM restarts, compilations, or going back to change types or api's in the middle of a thought.

> The edit/refresh cycle starts to slow IDEA and Eclipse compile your code as you write it. And with Hotswap, you don't even need to redeploy anything. They also all offer REPL's that are much more sophisticated than anything Javascript has to offer. I think you haven't used a JVM language and its ecosystem in a very long time.

I use Java today daily, and came from Node. It is slower to have the compile step, even on very powerful machines, dynamic types are faster to change, and there are many caveats to hot reload. The repl comment was about is about speed, not sophistication. When something happens instantly versus a tiny pause, you don't think about seeing your change immediately on save, versus batching many changes together and then testing them. This turns out to be faster for me for explorative work. Many people agree. Just trying to explain. /shrug

Re: Hard-won lessons: Five years with Node.js

#279

Post by mattmanser »

lhnz wrote: post #276
mattmanser wrote: post #274

Earlier quoted context omitted.

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 d…

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.

Re: Hard-won lessons: Five years with Node.js

#280

Post by root_axis »

josteink wrote: post #232

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…

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.

Post reply on HN