3 ms·

Yet more architecture astronaut behavior by people who really should just be focusing on ifs, fors, arrays, and functions.

triyambakam 1y ago
Architecture astronaut is a term I hadn't heard but can appreciate. However I fail to see that here. It's a fair overview of newish Node features... Haven't touched Node in a few years so kinda useful.
- chickenzzzzu 1y ago
  It's a good one with some history and growing public knowledge now. I'd encourage a deep dive, it goes all the way back to at least CPP and small talk. While I can see some arguments for "we need good tools like Node so that we can more easily write actual applications that solve actual business problems", this seems to me to be the opposite. All I should ever have to do to import a bunch of functions from a file is "import * from './path'" anything more than that is a solution in search of a problem
  - MrJohz 1y ago
    Isn't that exactly the syntax being recommended? Could you explain what exactly in the article is a solution in search of a problem?
  - WickyNilliams 1y ago
    Did you read the article? Your comments feel entirely disconnected from its contents - mostly low level piece or things that can replace libraries you probably used anyway
- VPenkov 1y ago
  The term originates from a Joel Spolsky article (or at least it's where I know it from). It's a great read: https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect... Feels unrelated to the article though.
programmarchy 1y ago
One of the core things Node.js got right was streams. (Anyone remember substack’s presentation “Thinking in streams”?) It’s good to see them continue to push that forward.
- chickenzzzzu 1y ago
  Why? Why is a stream better than an array? Why is the concept of a realtime loop and for looping through a buffer not sufficient?
  - bblaylock 1y ago
    I think there are several reasons. First, the abstraction of a stream of data is useful when a program does more than process a single realtime loop. For example, adding a timeout to a stream of data, switching from one stream processor to another, splitting a stream into two streams or joining two streams into one, and generally all of the patterns that one finds in the Observable pattern, in unix pipes, and more generally event based systems, are modelled better in push and pull based streams than they are in a real time tight loop. Second, for the same reason that looping through an array using map or forEach methods is often favored over a for loop and for loops are often favored over while loops and while loops are favored over goto statements. Which is that it reduces the amount of human managed control flow bookkeeping, which is precisely where humans tend to introduce logic errors. And lastly, because it almost always takes less human effort to write and maintain stream processing code than it does to write and maintain a real time loop against a buffer. Hopefully this helps! :D
  - dwb 1y ago
    A stream is not necessarily always better than an array, of course it depends on the situation. They are different things. But if you find yourself with a flow of data that you don't want to buffer entirely in memory before you process it and send it elsewhere, a stream-like abstraction can be very helpful.
  - cluckindan 1y ago
    Streams have backpressure, making it possible for downstream to tell upstream to throttle their streaming. This avoids many issues related to queuing theory. That also happens automatically, it is abstracted away from the users of streams.
flufluflufluffy 1y ago
what? This is an overview of modern features provided in a programming language runtime. Are you saying the author shouldn’t be wasting their time writing about them and should be writing for loops instead? Or are you saying the core devs of a language runtime shouldn’t be focused on architecture and should instead be writing for loops?
deleted 1y ago
[deleted]

triyambakam 1y ago

Architecture astronaut is a term I hadn't heard but can appreciate. However I fail to see that here. It's a fair overview of newish Node features... Haven't touched Node in a few years so kinda useful.

chickenzzzzu 1y ago
It's a good one with some history and growing public knowledge now. I'd encourage a deep dive, it goes all the way back to at least CPP and small talk. While I can see some arguments for "we need good tools like Node so that we can more easily write actual applications that solve actual business problems", this seems to me to be the opposite. All I should ever have to do to import a bunch of functions from a file is "import * from './path'" anything more than that is a solution in search of a problem
- MrJohz 1y ago
  Isn't that exactly the syntax being recommended? Could you explain what exactly in the article is a solution in search of a problem?
- WickyNilliams 1y ago
  Did you read the article? Your comments feel entirely disconnected from its contents - mostly low level piece or things that can replace libraries you probably used anyway
VPenkov 1y ago
The term originates from a Joel Spolsky article (or at least it's where I know it from). It's a great read: https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect... Feels unrelated to the article though.

programmarchy 1y ago

One of the core things Node.js got right was streams. (Anyone remember substack’s presentation “Thinking in streams”?) It’s good to see them continue to push that forward.

chickenzzzzu 1y ago
Why? Why is a stream better than an array? Why is the concept of a realtime loop and for looping through a buffer not sufficient?
- bblaylock 1y ago
  I think there are several reasons. First, the abstraction of a stream of data is useful when a program does more than process a single realtime loop. For example, adding a timeout to a stream of data, switching from one stream processor to another, splitting a stream into two streams or joining two streams into one, and generally all of the patterns that one finds in the Observable pattern, in unix pipes, and more generally event based systems, are modelled better in push and pull based streams than they are in a real time tight loop. Second, for the same reason that looping through an array using map or forEach methods is often favored over a for loop and for loops are often favored over while loops and while loops are favored over goto statements. Which is that it reduces the amount of human managed control flow bookkeeping, which is precisely where humans tend to introduce logic errors. And lastly, because it almost always takes less human effort to write and maintain stream processing code than it does to write and maintain a real time loop against a buffer. Hopefully this helps! :D
- dwb 1y ago
  A stream is not necessarily always better than an array, of course it depends on the situation. They are different things. But if you find yourself with a flow of data that you don't want to buffer entirely in memory before you process it and send it elsewhere, a stream-like abstraction can be very helpful.
- cluckindan 1y ago
  Streams have backpressure, making it possible for downstream to tell upstream to throttle their streaming. This avoids many issues related to queuing theory. That also happens automatically, it is abstracted away from the users of streams.

flufluflufluffy 1y ago

what? This is an overview of modern features provided in a programming language runtime. Are you saying the author shouldn’t be wasting their time writing about them and should be writing for loops instead? Or are you saying the core devs of a language runtime shouldn’t be focused on architecture and should instead be writing for loops?

deleted 1y ago

[deleted]