I must admit that I was a bit shocked when I realized that the author had used javascript for this task. At first I assumed that he was scripting some webmail interface but then I saw that he was using 'emailjs-imap-client'.
I understand that people use what they're familiar with and there seems to be a vibrant ecosystem for JS outside of the browser but it'll never not be weird seeing it take over what would once have been written in Perl or Python, especially since for a long time all I heard about Javascript was "well yeah it sucks but it's not like I have a choice if I want to script in the browser".
Software is eating the world, and the web is eating software.
I disagree. JavaScript is one of those languages who's default failure mode seems to be to pretend everything worked and just produce nonsensical results.
I've mentioned it before, but reading this book and applying its concepts (along with judicial use Damian Conway's Perl Best Practices) changed my view of Perl from "well, I guess I'll use it since it's here," to "I really enjoy using Perl".
Mark Jason Dominus's Higher-Order Perl was another enjoyable read, for its advice on using Perl as a more functional programming language.
What would have been a shell script in the 1980s, a Perl script in the 1990s, a Python script in the 2000s, is now a JS bundled with an outdated Chromium build aka an Electron app.
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.
And what utility did it provide while it was in production for the effort that was put into it? We had a nasty nasty 3k line Perl script “in production” at a former client for like 10 years. It was written in a couple of weeks by another outside vendor and did it’s job well enough. It had basically zero abstractions. Minimal dependencies. Did one thing and was well commented on intent. The investment vs utility made it last a long time. Yee, rewriting a decade later with minimal Perl knowledge wasn’t fun but the business rules had also evolved so we really used it as reference docs and did just fine
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.
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.)
> It sounds like the problem was really about failing to document technical debt.
Technical debt is inevitable, and it will never be adequately documented. That's not really the situation we're talking about here.
This is more about stuff that was written with the mindset of "this will go into prod" versus "this will never go into prod". If your code is never going into prod, it's often acceptable to have huge, critical bugs--that's a very different thing from technical debt.
> 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.)
Well, sure, but this is a great example of why analogies aren't a good way to make arguments.
You're talking about using the right tools, not doing things properly. Sure, if I don't have the right tools, I'd do the best I can with the tools I have. But you'd better bet that a professional chef shouldn't just skip chopping the carrots because "it's just a throwaway dish, no need to do this properly" when there's a chance that it's going to be served to a food critic.
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.
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.
> 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.
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.
({}).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().
...and get warnings later when you attempt to access anything that's not propertyA, propertyB, or a JS builtin, as well as warnings if you attempt to use either without verifying whether it's undefined or not, as well as warnings if you then try to use them in places restricted to non-matching types.
With Typescript, you can turn on full strictness and make these build-rejecting compile-time errors, too.
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.
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?
Was Python faster than javascript a long time ago? I'm not super old and javascript has always been way faster in my mind, but it's fine. Python has many great libraries for doing heavy computations very quickly.
As as a hardcore Perler and JS eng of 20 years - yes, Perl or Python would've been the best tool for the job. Perl in particular due to its regex readability.
I understand that people use what they're familiar with and there seems to be a vibrant ecosystem for JS outside of the browser but it'll never not be weird seeing it take over what would once have been written in Perl or Python, especially since for a long time all I heard about Javascript was "well yeah it sucks but it's not like I have a choice if I want to script in the browser".
Software is eating the world, and the web is eating software.