3 ms·

> But these are not constraints of server-side or command line code, so it's absurd to write server-side code under these constraints. Server-side JavaScript sh

> But these are not constraints of server-side or command line code, so it's absurd to write server-side code under these constraints. Server-side JavaScript should not exist. Command line utilities written in Javascript should not exist. This is a myopic view entirely disconnected from reality. The purpose of code isn't to be perfect or pretty, its purpose is to do useful work. The most relevant constraint is always available resources which is dominated by human capital and experience. Productivity is measured using useful output, not code quality. > What part of using having a bunch of completely different ways to bind to events to read a file makes any sense? The part that puts food on the table. I can't name a single language I have any experience with that has One True Way™ of binding to events except for C and assembly which can only pass callable pointers around.

mgkimsal 6y ago
I don't think the GP was saying JS is bad because there's not 'one true way' to read from a file. I think the GP was saying it's bad because we're trying to get it to read from a file in the first place. ('Server-side JavaScript should not exist')
kerkeslager 6y ago
> The most relevant constraint is always available resources which is dominated by human capital and experience. Which is why it's particularly puzzling that JavaScript community ignores vast swaths of human capital and experience. Global state? Awesome! Principle of least astonishment? For the birds. Caring about security of your dependencies? What on earth for? > Productivity is measured using useful output, not code quality. Useful output is strongly correlated with code quality, and that correlation grows stronger as a project grows. > The part that puts food on the table. Sure, my billable rate is the same no matter what language I'm writing and if that's all you care about, okay I guess. But I've rewritten a server-side JavaScript application in Python, and my clients wouldn't hesitate to say that they got more for my billable hours than they did for the team of three JavaScript developers who wrote the original application. > I can't name a single language I have any experience with that has One True Way™ of binding to events except for C and assembly which can only pass callable pointers around. You need to take a bigger step back to understand what I'm saying. It's not about having One True Way, it's about keeping your code simple enough that you can read it when you come back to it a year later, you can break it into composable chunks, and reuse it. Every one of the ways on the page I linked forces you to think about an event loop in a process that's fundamentally procedural. It's fundamentally the wrong abstraction for the situation, but JavaScript literally can't represent a better abstraction.

mgkimsal 6y ago

I don't think the GP was saying JS is bad because there's not 'one true way' to read from a file. I think the GP was saying it's bad because we're trying to get it to read from a file in the first place. ('Server-side JavaScript should not exist')

kerkeslager 6y ago

> The most relevant constraint is always available resources which is dominated by human capital and experience. Which is why it's particularly puzzling that JavaScript community ignores vast swaths of human capital and experience. Global state? Awesome! Principle of least astonishment? For the birds. Caring about security of your dependencies? What on earth for? > Productivity is measured using useful output, not code quality. Useful output is strongly correlated with code quality, and that correlation grows stronger as a project grows. > The part that puts food on the table. Sure, my billable rate is the same no matter what language I'm writing and if that's all you care about, okay I guess. But I've rewritten a server-side JavaScript application in Python, and my clients wouldn't hesitate to say that they got more for my billable hours than they did for the team of three JavaScript developers who wrote the original application. > I can't name a single language I have any experience with that has One True Way™ of binding to events except for C and assembly which can only pass callable pointers around. You need to take a bigger step back to understand what I'm saying. It's not about having One True Way, it's about keeping your code simple enough that you can read it when you come back to it a year later, you can break it into composable chunks, and reuse it. Every one of the ways on the page I linked forces you to think about an event loop in a process that's fundamentally procedural. It's fundamentally the wrong abstraction for the situation, but JavaScript literally can't represent a better abstraction.