IMAP is a protocol that you can only love if you haven’t had to try to implement it. I say “try to” because there are so many incompatible almost-implementations that you will never actually implement IMAP.

Replacing it with something more sane seems like a good use of time.

If you want to use JSON and paging but are stuck with regular IMAP servers, you can use https://EmailEngine.app between your app and the mail server.

I'd rather implement IMAP than HTTP, TLS, JSON, and whatever other shit is involved here. All of those points apply to the WWW more than anything else.

No one implements HTTP, JSON, and TLS. There are libraries for every single language imaginable. The more shared parts of the stack, the less wasted effort so you only have to implement the parts specific to sending and receiving email.

Only if you're insistent on willfully misreading them.

[no application protocol implementer] implements HTTP, JSON, and TLS [because there are well-worn implementations that can just be used for the purpose].

HTTP is a massive standard that takes thousands of man hours to implement. It's not something that "just exists" out there. I guess maybe the intent is that if you don't have Google writing your standard library you shouldn't even be able to check your mail. I'm not a huge fan of IMAP (I wrote a client implementation for IMAPv4 a long time ago) but it's ridiculous that using what amounts to "SMTP for hypertext" as a transport layer is now common practice.

HTTP libraries do "just exist" for every usable language because almost everything is based on HTTP. Its a piece of common platform that someone puts the effort once and then you have opened up almost everything relating to network protocols. Basing your protocol on HTTP now means you have an absolutely huge amount of stuff for free. Error handling, encryption, verification, streaming, the whole set of tooling around hosting HTTP protocols like nginx, load balancers, etc.

I'd challenge you to find a single production suitable language which _doesn't_ have a http library.

TCP/IP is a standard that takes a long time to implement well. I've had to implement TCP/IP exactly once in my career (maybe a couple times more if you count just "lobbing" crafted datagrams), but I've just "used" existing implementations hundreds of times.

Similarly, HTTP is a big standard that takes a long time to implement well. But very few people will have to implement it: they will use existing implementations.

Why do you call JSON shit? It's incredibly useful and I use it all the time, am I missing something?

JSON has a few rough points that make it frustrating to parse. Like for example, most values requiring open and ending tags, no trailing commas allowed (so you must either be lax and non-compliant or backtrack the parser on last element), and other similar edge cases.

This results in making it extraordinarily easy to break most parsers in use, today. For example, to kill Python:

    n="$(python3 -c 'import math; import sys; sys.stdout.write(str(math.floor(sys.getrecursionlimit() - 4)))')"

    left="$(yes [ | head -n "$n" | tr -d '\n')"

    echo "$left" | python3 -c 'import json; print(json.loads(input()))'

That's a less than 1000-character long object, that can explode. Whilst there are more robust parsers you can get for Python, it doesn't change the fact that generating bad JSON is _easy_.

So when you're handling something like email, on a mobile device which may drop a partial connection, you need a hell of a lot of extra work to show the partial download, which might even be everything except the closing braces, or you have to discard the whole thing - which isn't kind to your user.

> JSON has a few rough points that make it frustrating to parse.

Even so, parsing JSON is a well-understood problem, and there are tons of mature libraries to parse and generate it. I'd much rather work with a JSON-based protocol than one which made up its own wacky data format.

The same goes for the use of HTTP. It may not be the ideal protocol for accessing mail, but everyone knows how to work with HTTP, and tools to interact with it are plentiful.

> Its JSON-centred roots and HTTP are conventional,

> so special parsers are not needed: this is quite intentional.

Two lines from a song rjbs and I made (but never published) about JMAP a few years ago, back when I was a Fastmail employee, set to the tune of the Major-General’s Song.

I almost always enjoy the faffing around "well I don't like JSON personally therefore it's a bad fit for email" in every one of these threads.

Hey, it could be worse. It could be YAML.

YAMP you mean

> Even so, parsing JSON is a well-understood problem, and there are tons of mature libraries to parse and generate it. I'd much rather work with a JSON-based protocol than one which made up its own wacky data format.

The same could easily be said for mbox and maildir. These have been around forever, and if you have a library for JSON, you've probably got a library for those two, as well. But parsing them tends to be less error-intensive if you hit some kind of connection interruption.

The complaint for JSON in JMAP tends to come down to - does it improve the current status quo?

> But parsing them tends to be less error-intensive if you hit some kind of connection interruption.

Never heard of the ">From" problem? :)

mbox has a well-documented escaping problem -- many tools which parse mbox files will mistake a line which begins with the word "from" for the start of a new message. As a result, many tools which generate mbox data will insert a ">" before the start of those lines, mangling the data slightly to prevent corruption.

But that's besides the point. mbox/maildir are data storage formats, not network protocols. The corresponding network protocols (POP and IMAP) have their respective problems as well, though.

JSON's not a network protocol, either. It's a data storage format, too. :p

Yes, they all have problems. That's... Our industry. You pick and choose your problems. Hence why it's easy to point out rough edges in JSON, and it's easy with mbox or maildir, too.

> JSON's not a network protocol, either. It's a data storage format, too. :p

JSON is a data exchange format, it’s always been intended as a way to communicate between systems. You can use it for data storage just fine, but it’s not the primary role of the format.

Mbox was not designed as an exchange / interchange format, but as a storage format for MUA, with some possibility of interoperability.

How well supported are mbox and maildir relative to JSON?

Do you have multiple high quality implementations for supporting mbox or maildir in nearly every language and framework in active use today?

If not, then they’re nothing like JSON.

> Do you have multiple high quality implementations for supporting mbox or maildir in nearly every language and framework in active use today?

Yes.

They're builtin to Python's stdlib [0]. There's dozens for JS. Part of the PHP stdlib. [1] A number for Rust. Several for Go. And so on, and so forth.

[0] https://docs.python.org/3/library/mailbox.html

[1] https://www.php.net/manual/en/function.imap-createmailbox.ph...

> Part of the PHP stdlib.

That's an IMAP library, not mbox/maildir, and it's part of an extension, not the standard library.

The parsing of mbox and maildir storage formats is orthogonal to the mailstore access protocol, isn't it? Does JMAP propose a new mailstore format?

S-expressions are better, and something that sees so much usage should have a dedicated format. In a saner world, this work would already be done so that each protocol needn't define the octets on the line. Regardless, IMAP already exists.

It's a diseased mind that takes a shitty programming language, JavaScript, and turns it into a shitty structured data format.

IMAP is an ancient behemoth in strong need of modernization. JMAP is the replacement we have. Could modernization have been done with a dedicated protocol? I guess so. But no one (including you) did the work to get it done, so JMAP it is.

> Could modernization have been done with a dedicated protocol? I guess so.

But probably not because it adds an other layer of friction and complexity to deployment, which doesn’t do much good to your odds.

And it requires an entire additional ecosystem of inspection and protection capabilities to appear.

Not to mention the parsing and serialisation of a bespoke protocol, and the risk of all the usual framing and escaping errors in the protocol.

It also requires going to Iana for a port.

> so JMAP it is

Except it isn't. As you say, IMAP could do with modernisation; JMAP isn't that, it's a replacement.

If you want to replace a protocol that's in very widespread use, then your replacement needs to offer decisive benefits to operators and users, otherwise they won't switch. JMAP seems to offer benefits only to developers.

>As you say, IMAP could do with modernisation

In theory that's doable. In practice modernizing a protocol with extensions is though, since support ends up patchy. Especially when the big email providers have few reasons to make a documented, non-propriety extension. Why would they when they can instead push people to their propriety apps?

It's definitely possible that JMAP doesn't catch on. In that case, we'll probably just keep languishing with non-modernised IMAP.

The key is getting client support, especially in mobile (where there is a noticeable user benefit) and in open source software.

> JMAP seems to offer benefits only to developers.

I find this argument shortsighted. If it benefits developers then it does benefit users. Making developers' lives easier means they produce code faster (users like things done sooner), have fewer bugs in their code (users don't like buggy code), and have more time to implement other features (users like featureful software). I don't see how that doesn't benefit users.

That's not the way this works. I needn't accept the WWW garbage graphomaniacs attempt to force upon others.

(shrug) I could probably say about IMAP that it looks like it has been developed by hardcore Lisp fanboys. Boils down to someone’s yum being someone else’s yuck.

Hey, I love IMAP. For all its faults it is pretty powerful and good.

I've spent a lot of time on it, but the reasons that JMAP was developed still exist and are still valid :)

That's called a personal problem. It's not the responsibilty of a website owner to make his website constantly rot for the sake of strangers.

I suppose all of my fellow machine code programmers here are too busy discussing politics or something. I look forward to participating yet again, using my custom machine code development tool to write very compact and very efficient little games. I've so many ideas for games built up over the years, but must settle with the reality that implementing all of them in one month is unrealistic. Regardless, I aim to get two or even three finished, and as always will document my work in detail on my website.

Oh no, they’ll have all the Microsoft certifications too.

>You still cannot disable pull requests on a GitHub repository.

>I just want to publish software that I think is neat so that other hobbyists can use and learn from it, and I otherwise want to be left the hell alone.

Don't use GitHub. I don't. Random dipshits aren't even aware of me.

>To continue the inclusive nature of open source, we need to be able to trust a wide range of identities, but still with verified integrity. This implies a federated model for identities, perhaps similar to how we support federated SSL certificates today

Oh yes, of course Google supports TLS-flavoured snake oil to match the TLS snake oil.

I'm shocked MicroSoft is extending open source after embracing it so well, shocked.

I'm now recycling a previous comment of mine on this topic:

Companies used to have employees write code, rather than stitch together random garbage written by random dipshits who could be tricked into using loose licenses. That's one cause for concern. The only reason open source receives support is because it helps corporations defang Free Software and get gratis labor.

All of this new security theatre is always about trust and reputation, and not trusting those disgusting lone programmers such as me or other silly things; it's always really about doing anything but truly auditing that yucky code.

I have a completely opposite view. Striving for perfectness can be very toxic and create an environment where growth is impossible if you don't match someones definition of "perfect". It's not about excuses, it's about compromises, making progress, growing in our own pace and being human.

You both make good points.

Striving for perfection is a toxic habit (not just to your team, but to yourself too). However, there's also a category of people that write sloppy/unthoughtful code at the expense of their colleagues. Often times this is just due to inexperience, and we should reach out with advice and mentorship, but also have patience with their pace of improvement.

However, there's also a subset of people who abuse this compassion to get away with being sloppy intentionally (ie lazy). We should be mindful that these people exist, as they also create resentment/contempt, which also creates a toxic work environment.

Can you provide some rough statistics of each group size from your personal experience? Not asking to trap you but I am genuinely interested whether in practice it is useful to focus on the underlying cause.

Intentionally sloppy vs. inexperienced/tired/overworked/ADHD sloppy

Intentionally sloppy is someone I would categorise as being persistent sloppy, and showing no interest in improving themselves, but also a resistance to advice, and/or feedback. It sounds silly, because "who wouldn't wanna improve?", but sometimes they can't tell the difference between saying/wishing it and doing it.

I'd say I probably had a handful of such colleagues out of roughly ~70 devs I've worked with. They were all good people though, and had different reasons for their "sloppyness," but I think it kinda boiled down to being slightly more insecure and egotistical, or self-serving than I'm personally comfortable with (not that I hold it against them; all these traits are gradients). One was very open that he doesn't care about maintenance burden, and couldn't understand why I'm frustrated by the idea of amalgamated hacks. It was just the cost doing business to him. I sometimes think about this attitude and the wonder of I'd be happier by caring less about quality and maintainability than I do right now.

There's other components to all the other kinds you listed, IMO. People who are inexperienced tend to learn from their mistakes and don't repeat them (or at least try not to) once they know better. People who are tired/burnt out also show this indirectly outside of code in different ways. And people with ADHD don't tend to be sloppy in my experience, but they tend to just have a more erratic cadence (depending on how well they can maintain focus), or just be a bit sporadic (ie not get anything done for almost two weeks then have a barrage of PRs on Thursday/Friday).

All of these can be addressed if the person is willing to improve, though.

“I sometimes think about this attitude and the wonder of I'd be happier by caring less about quality and maintainability than I do right now”

Probably. Do they get paid any less than you? At the end of the day it’s your employer that benefits from your commitment to quality, not you. Your employer is also the one paying your colleague, so unless your his/her boss it’s not really you who gets to judge the quality of their work.

Thank you for a detailed response. In my limited experience I don't think I ever met anyone who genuinely didn't give a fuck. Some people were slower than others, some had a "5 pm and I am off" attitude (but without dropping work on others on exit), some were stuck in their old ways of doing things but no one was actually malicious.

Like you said, it is a gradient. We are all a bit different, in my work it was much more beneficial to me and everyone involved to just understand each other honestly, without judgement. That way it is much easier for everyone to find a good path to work happily and grow as people.

Some do not want to improve that much and I still think it's ok as long as it doesn't hinder anyone else's work. They may get switched to simpler and less challenging work over time but there's usually plenty of that to go around.

I'm not sure I'd be comfortable, calling it "disgusting."

It's different from the one I tend to apply, in my own work.

I used to work for a famous Japanese imaging corporation. Their brand was pretty much synonymous with "Quality."

They got that way, by practicing Perfection as a religion. It could be very, very tough, to deal with, but it gave me a great appreciation for a Quality mindset, in my own work.

The result is that even my lash-up, throwaway code, tends to be better than many folks' final release code.

This has great advantages for me. In fact, I just experienced one, a few minutes ago. If the baseline code is of as high Quality as I can possibly make it, then I can avoid lash-ups, or at least, reduce their severity, later. I refactored a fairly complex server interaction timeline, and it was made much easier, because I was pretty damn anal, when I first wrote it, maybe six months ago.

I think this is a good point I didn't convey in my hastily-written-in-10-minutes-blog-post-that-I-didn't-expect-to-reach-the-HN-front-page.

I can fall into perfectionism, but I find this a suboptimal mindset for healthy outcomes.

Excellence seems the far better path.

Keeping a high bar still, but not expecting something that's unreasonable.

Continuing to challenge yourself to get better, but not expecting yourself to have achieved something already that's out of your grasp.

For me it's about trajectory and momentum over perfection.

Aim high, but have compassion for yourself as you push forward.

This is not embracing mediocrity, it is not disengagement, slacking, or merely rejecting perfectionism. It is understanding that the process of growth and improvement exacts a toll, and that growth is not always a pure function of time invested.

How does one practice perfection without succumbing to overoptimistic expectations and the burnout follows?

They use perfection as a target, and any deviation is considered a national emergency. They will have all-day meetings, with screaming matches, over whether or not to release with a known issue.

It is a lot of pressure. Not for the faint of heart. They are demanding as hell. Their testing/QA is crazy. 3,000-line Excel punchlists. If even one item on that list fails, the whole shooting match is sent back.

You can't argue with the results, though. They have been selling very expensive optical gear, for over 100 years, and people base their entire careers on this gear.

That said, I think they are really struggling, these days, and I believe that their conservatism and rigidity play a big part in that.

Mathematics can be applied to programming, for sure. However, much of programming is encoding of business processes. Such that, unless you expand your scope for all business process also being applied mathematics, I'm not sure this is that instructive.

Let's use the linux kernel as an example, since it does very few, well-defined things, and still doesn't work. This comes from an inability to imagine better, an unwillingness to use proper tools, and an attitude that kernel panics be acceptable.

It's fine to solve a vague problem by simply having the machine ask for human direction in a few cases. It's not fine to have the machine do something inappropriate or crash because a valid case wasn't handled in any way.

Everything below these vague areas can, and should, be perfect. People who claim this be an unobtainable goal are liars.

I strongly disagree on this. If you really think nobody working on these problems imagines better, I assert you are being highly insulting to the people working on these problems. Both in the Linux kernel and otherwise.

Successful systems that solve real world problems are not perfect. This works in your favor though, as when you release your project, its perfection will be a great competitive advantage

The trick is defining a subset of a larger problem that you can solve perfectly--and know what isn't solved for next time.

>programming is applied mathematics

You may want to rethink this one

I've noticed a difference in tone:

> The site is openly racist and antisemitic and it regularly advocates a second genocide of Jews.

> „Right now, Nick Lim is like a wounded elk”, says internet researcher Guilmette, who monitors the websites’ every move. „It is time to move in quickly for the kill, before he gets away again.”

If I didn't know better, I'd assume these people don't want others to be able to advocate for certain ideas. It's funny how that works. One side gets to use the freedom of speech excuse when, say, targeting children, but merely disagreeing with that magically becomes hate speech, which totally isn't free speech, and must be mercilessly destroyed.

Oh well, people can go into the streets if they want to speak and, hey, once it really comes to that point there will be more than strong words now won't there be?

I would love for you to elaborate what exactly you mean by one side "targeting children".

Hacker News is part of the elite, so that will never happen. Just look at how VC and YC companies Uber and AirBnB have eroded workers' rights and zoning laws for elite profit. That's the secret with all of these companies; they claim that using computers means they needn't follow the laws. Look at how YouTube shows children things no television network ever would've been allowed to show them, for another example.

Most specifically, Hacker News, were its current peers to decide to cease to do business with it, can find other peers.

> That's the secret with all of these companies; they claim that using computers means they needn't follow the laws. Look at how YouTube shows children things no television network ever would've been allowed to show them, for another example.

I haven't seen evidence that YouTube is breaking the law in this regard. The law governing network TV is complicated and pinned philosophically on the finite airwaves that are a national resource (so there are some trade-offs a private institution makes with the public, represented by the government and laws, for the exclusive privilege of having its use of a slice of bandwidth protected from interference). No such "finite national resource" management concern exists for data from private websites travelling across privately-owned wires onto private computers at the request of individuals in the privacy of their own homes.

> If a carpenter chops his fingers off, it's not the fault of the saw.

That would be an effective argument, but this vile shit has existed for decades without being fixed, for no good reason. This saw is specifically designed to slice fingers off, rather than do useful work, for no reason.

> Having a base level expectation of competence for operators is normal.

UNIX expects perfection, while providing none of its own.

> A separate text input is just stdin by another name.

No, nitwit, it prevents in-band signalling, which is the entire problem here.

Anyway, I use Emacs for everything, and don't have these issues. With wget, I use -i - to enter multiple URLs at once, but it would also defeat this.

Thanks for saving me a reply lol

To the article:

It's fine to handle an explicit subset of a problem. What's not fine is not making this clear. Real software can generally have a well-defined domain and range, which this article muddies with its example.

> This works but is quitter talk.

It's a valid solution. Expressing weird recipes as lists of normal recipes is perfectly fine.

> If we want to include recipe expansion as a feature of our model, we need to make the algorithm more complicated to handle the single edge case of fondant.

Yes, it turns out writing correct software sometimes requires this, even for a small amount of overall cases. That's no argument against not handling all cases.

To the parent poster:

I expect someone incapable of writing perfect software to claim it to be impossible, yes. I'd upload an article I've written proving my point, but it's about correct software, so it would just get ignored here.

Software is mathematics, and mathematics can be perfect.

> This is why I laugh at talk of "bug free" software. The best you can do is zero reported bugs. Temporarily.

No, this is the best the incompetent can do, but I won't let them drag me down to their level.