8 ms·

who cares, it's just a 100-line long script that probably won't be maintained or used anymore

by volgar1x 7y ago

jaynetics 7y ago
It would be more readable in almost any other widespread language, and I'm saying that as someone who does a lot of JS.
- BossingAround 7y ago
  This is quickly changing. Anecdotal evidence, of course, but I seem to come across a lot more scripts online in Node for some reason. And by 'scripts' I mean reproducers to various issues, such as triggering error state in an app I was working on. At first, I thought it was crazy. It kinda makes sense though, JS seems to be growing extremely fast.
  - AnIdiotOnTheNet 7y ago
    Just because more people are using it does not mean it is more readable. Footguns about in JS and it is remarkably easy to read the same code over and over again and not see them because of it. Readable languages are the kinds where not only do you understand what they're trying to do at a quick glance, but also what they actually do.
  - kerkeslager 7y ago
    As someone who has worked in Javascript basically since Javascript was invented, it's been "quickly changing" that entire time, and the majority of the changes have made things worse, not better. It used to be that you could trace your code through 15 layers of callback hell and eventually find the problem. Now there's 10 different syntactic sugars around callbacks, so you get to save a few characters of typing and then trace your bugs through 50 layers of callback hell, most of which are in some 0.0.1-alpha-versioned promise library which may actually just be a XSS attack. Improvement? I think not. Just because more people are doing it, doesn't mean it's improving. I'll believe things are going in a good direction when `{}.foo` throws an exception in all major JS implementations. But I'm not optimistic about that ever happening. My only hope for JavaScript right now is that it might die because WebAssembly lets a reasonable language achieve dominance.
    - crooked-v 7y ago
      > I'll believe things are going in a good direction when `{}.foo` throws an exception in all major JS implementations. But I'm not optimistic about that ever happening. It does. That's a SyntaxError.
      - kerkeslager 7y ago
        Okay, please make a little effort to understand meaning rather than taking things completely literally. Try one of the following: > ({}).foo undefined > var a = {}; undefined > a.foo undefined Now imagine hundreds of lines of code and a bunch of asynchronous callbacks occur between the last two lines, and imagine what that does for your debugging experience. Or watch Wat[1] and see if any of that is what you want your language to do when it happens. The fact that JavaScript throws an exception on `{ foo: 'bar' }.foo` and not `({}).foo` isn't exactly a defense of the language. [1] https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
        crooked-v 7y ago
        ({}).foo returning undefined is exactly what I'd expect. That's a basic part of how accessing properties in Javascript works, and wanting it to work differently is like wanting NullPointerException generation in Java to work differently. > Now imagine hundreds of lines of code and a bunch of asynchronous callbacks occur between the last two lines, and imagine what that does for your debugging experience That's what using typed signatures for your objects is for. It's not even substantially different from having, say, Java with an object with properties that can be nullable or Optional.empty().
        kerkeslager 7y ago
        > ({}).foo returning undefined is exactly what I'd expect. That's a basic part of how accessing properties in Javascript works, This is an excellent and succinct explanation of why JavaScript is a badly-designed language, and why I use better designed languages when possible. If the basic properties "work" when it makes no sense for them to work, your language is broken. > That's what using typed signatures for your objects is for. Explain more?
- fireattack 7y ago
  The biggest problem I have with JS in term of readability is IIFE. I know what it does, but it just looks ugly when you have hundreds of them in a program. The "semicolon in front" is even worse, needless to say. There gotta be a better way to design syntax for an async language.. right?
  - layoutIfNeeded 7y ago
    Wait, why do you need IIFE in post-ES6 JS? Just use let/const.
    - fireattack 7y ago
      Well, OP's example is using it, but I think it's for top level async/await (not a JS dev here)?
      - kehers 7y ago
        Yup
      - crooked-v 7y ago
        Top level await is in Stage 3, so it'll be baked into the general system before too long.
kerkeslager 7y ago
I'm not sure I could count the number of 100-line long throwaway scripts that I wrote that are still being used in production systems before I realized how dangerous that idea is and stopped treating any code as throwaway code. If I show my code to another human, there's a chance it will end up in production. The Pragmatic Programmer says to throw away prototypes, but in practice it always seems easier to click the merge button than to rewrite working code.
- lonelappde 7y ago
  Reverse-survivor bias. You aren't seeing the non-existence all the well engineered stuff you never had time to build "properly".
  - kerkeslager 7y ago
    So? If only 1 in 10 throwaway scripts survives, that can easily cost more in the long run than writing all 10 scripts in a sustainable way. The open secret is that you almost always have time to do it properly. Doing it properly doesn't take that much more time, and most deadlines are self-imposed and artificial. EDIT: Time isn't actually the most important cost. Not my code, but a coworker's throwaway script where he thought, "We'll just log this to a file for now" filled up a production DB server with log entries and took down a high-traffic e-commerce site for 6 hours. That easily cost more money than an entire career's worth of "doing it properly". There were obviously multiple mistakes that allowed that to happen, but removing the "we'll do this properly later" mistake would have prevented it.
    - an_ko 7y ago
      It sounds like the problem was really about failing to document technical debt. > Doing it properly doesn't take that much more time If you don't have a cutting board for a small thing, surely you wouldn't put your cooking on hold to drive out to the kitchen supply shop to buy a cutting board. You'd just use a stack of cardboard or something. (And make a note to buy a proper cutting board later, of course.)
andrewzah 7y ago
Temporary code is permanent code in many, many cases.

who cares, it's just a 100-line long script that probably won't be maintained or used anymore

jaynetics 7y ago

It would be more readable in almost any other widespread language, and I'm saying that as someone who does a lot of JS.

BossingAround 7y ago
This is quickly changing. Anecdotal evidence, of course, but I seem to come across a lot more scripts online in Node for some reason. And by 'scripts' I mean reproducers to various issues, such as triggering error state in an app I was working on. At first, I thought it was crazy. It kinda makes sense though, JS seems to be growing extremely fast.
- AnIdiotOnTheNet 7y ago
  Just because more people are using it does not mean it is more readable. Footguns about in JS and it is remarkably easy to read the same code over and over again and not see them because of it. Readable languages are the kinds where not only do you understand what they're trying to do at a quick glance, but also what they actually do.
- kerkeslager 7y ago
  As someone who has worked in Javascript basically since Javascript was invented, it's been "quickly changing" that entire time, and the majority of the changes have made things worse, not better. It used to be that you could trace your code through 15 layers of callback hell and eventually find the problem. Now there's 10 different syntactic sugars around callbacks, so you get to save a few characters of typing and then trace your bugs through 50 layers of callback hell, most of which are in some 0.0.1-alpha-versioned promise library which may actually just be a XSS attack. Improvement? I think not. Just because more people are doing it, doesn't mean it's improving. I'll believe things are going in a good direction when `{}.foo` throws an exception in all major JS implementations. But I'm not optimistic about that ever happening. My only hope for JavaScript right now is that it might die because WebAssembly lets a reasonable language achieve dominance.
  - crooked-v 7y ago
    > I'll believe things are going in a good direction when `{}.foo` throws an exception in all major JS implementations. But I'm not optimistic about that ever happening. It does. That's a SyntaxError.
    - kerkeslager 7y ago
      Okay, please make a little effort to understand meaning rather than taking things completely literally. Try one of the following: > ({}).foo undefined > var a = {}; undefined > a.foo undefined Now imagine hundreds of lines of code and a bunch of asynchronous callbacks occur between the last two lines, and imagine what that does for your debugging experience. Or watch Wat[1] and see if any of that is what you want your language to do when it happens. The fact that JavaScript throws an exception on `{ foo: 'bar' }.foo` and not `({}).foo` isn't exactly a defense of the language. [1] https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
      - crooked-v 7y ago
        ({}).foo returning undefined is exactly what I'd expect. That's a basic part of how accessing properties in Javascript works, and wanting it to work differently is like wanting NullPointerException generation in Java to work differently. > Now imagine hundreds of lines of code and a bunch of asynchronous callbacks occur between the last two lines, and imagine what that does for your debugging experience That's what using typed signatures for your objects is for. It's not even substantially different from having, say, Java with an object with properties that can be nullable or Optional.empty().
        kerkeslager 7y ago
        > ({}).foo returning undefined is exactly what I'd expect. That's a basic part of how accessing properties in Javascript works, This is an excellent and succinct explanation of why JavaScript is a badly-designed language, and why I use better designed languages when possible. If the basic properties "work" when it makes no sense for them to work, your language is broken. > That's what using typed signatures for your objects is for. Explain more?
fireattack 7y ago
The biggest problem I have with JS in term of readability is IIFE. I know what it does, but it just looks ugly when you have hundreds of them in a program. The "semicolon in front" is even worse, needless to say. There gotta be a better way to design syntax for an async language.. right?
- layoutIfNeeded 7y ago
  Wait, why do you need IIFE in post-ES6 JS? Just use let/const.
  - fireattack 7y ago
    Well, OP's example is using it, but I think it's for top level async/await (not a JS dev here)?
    - kehers 7y ago
      Yup
    - crooked-v 7y ago
      Top level await is in Stage 3, so it'll be baked into the general system before too long.

kerkeslager 7y ago

I'm not sure I could count the number of 100-line long throwaway scripts that I wrote that are still being used in production systems before I realized how dangerous that idea is and stopped treating any code as throwaway code. If I show my code to another human, there's a chance it will end up in production. The Pragmatic Programmer says to throw away prototypes, but in practice it always seems easier to click the merge button than to rewrite working code.

lonelappde 7y ago
Reverse-survivor bias. You aren't seeing the non-existence all the well engineered stuff you never had time to build "properly".
- kerkeslager 7y ago
  So? If only 1 in 10 throwaway scripts survives, that can easily cost more in the long run than writing all 10 scripts in a sustainable way. The open secret is that you almost always have time to do it properly. Doing it properly doesn't take that much more time, and most deadlines are self-imposed and artificial. EDIT: Time isn't actually the most important cost. Not my code, but a coworker's throwaway script where he thought, "We'll just log this to a file for now" filled up a production DB server with log entries and took down a high-traffic e-commerce site for 6 hours. That easily cost more money than an entire career's worth of "doing it properly". There were obviously multiple mistakes that allowed that to happen, but removing the "we'll do this properly later" mistake would have prevented it.
  - an_ko 7y ago
    It sounds like the problem was really about failing to document technical debt. > Doing it properly doesn't take that much more time If you don't have a cutting board for a small thing, surely you wouldn't put your cooking on hold to drive out to the kitchen supply shop to buy a cutting board. You'd just use a stack of cardboard or something. (And make a note to buy a proper cutting board later, of course.)

andrewzah 7y ago

Temporary code is permanent code in many, many cases.