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

Mining my mailbox for top email service providers

obem.be

Post reply on HN
Print view View original

91–100 of 110 posts

Re: Mining my mailbox for top email service providers

#91

Post by kerkeslager »

an_ko wrote: post #68
kerkeslager wrote: post #61

Earlier quoted context omitted.

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

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.

Re: Mining my mailbox for top email service providers

#92

Post by crooked-v »

kerkeslager wrote: post #40
BossingAround wrote: post #33

Earlier quoted context omitted.

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

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

Re: Mining my mailbox for top email service providers

#93

Post by lizmat »

bloopernova wrote: post #81
lonelappde wrote: post #47

Earlier quoted context omitted.

Modern Perl is fine too

I haven't used Perl in about 12 years, has it changed much since then? Do you have any links to good examples/comparisons?

To some, Raku is what Perl should have been by now: https://raku.org

Re: Mining my mailbox for top email service providers

#94

Post by jamestomasino »

ksahin wrote: post #45

I know the results are biased given it's a sample from OP inbox but I'm surprised not so see https://postmarkapp.com/ here. I thought they were pretty popular.

They're just for transactional emails, not for marketing ones. They wouldn't show very much based on how he's measuring.

Re: Mining my mailbox for top email service providers

#95

Post by roseway4 »

The methodology used excludes a number of services using SparkPost. For e.g. the excerpt below of an Intercom header. It's a challenging problem to solve given the complexity of email delivery and appreciate this was a fun project to take on.

Return-Path: Received: from mta-216-35.sparkpostmail.com (mta-216-35.sparkpostmail.com. [147.253.216.35]) by mx.google.com with ESMTPS id t13si7000210pgg.534.2020.02.03.08.37.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Feb 2020 08:37:30 -0800 (PST)

Re: Mining my mailbox for top email service providers

#96

Post by kerkeslager »

crooked-v wrote: post #92
kerkeslager wrote: post #40

Earlier quoted context omitted.

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

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

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

Re: Mining my mailbox for top email service providers

#97

Post by crooked-v »

kerkeslager wrote: post #96
crooked-v wrote: post #92

Earlier quoted context omitted.

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

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

({}).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().

Re: Mining my mailbox for top email service providers

#98

Post by crooked-v »

fireattack wrote: post #79
layoutIfNeeded wrote: post #77

Earlier quoted context omitted.

Wait, why do you need IIFE in post-ES6 JS? Just use let/const.

Well, OP's example is using it, but I think it's for top level async/await (not a JS dev here)?

Top level await is in Stage 3, so it'll be baked into the general system before too long.

Re: Mining my mailbox for top email service providers

#99

Post by ksahin »

jamestomasino wrote: post #94
ksahin wrote: post #45

I know the results are biased given it's a sample from OP inbox but I'm surprised not so see https://postmarkapp.com/ here. I thought they were pretty popular.

They're just for transactional emails, not for marketing ones. They wouldn't show very much based on how he's measuring.

It seems this post is about transactional emails, not marketing ones. CF the first paragraph!

Re: Mining my mailbox for top email service providers

#100

Post by fiddlerwoaroof »

iudqnolq wrote: post #59
jannes wrote: post #39

Earlier quoted context omitted.

What do you mean with "sandboxes fetch requests"? That's not a valid countermeasure at all... The grandparent was worried about the extension stealing his email's contents.

Absolutely. If the extension injects JavaScript into the page to examine the email it can run a fetch in the context of that page. I think the app store should warn that a page can send data to any website if it has permission to modify any page.

It’s been a while, but I’m pretty sure the permissions dialog explicitly calls this out.
Post reply on HN