[quotemstr]

> Implementing protocols correctly is hard

That's why it's a best practice to specify protocols at a very high level (e.g. using cap'n'proto) instead of expecting every random sleep-deprived SDE2 to correctly implement a network exchange in terms of read() and write().

[blueflow]

That why you have to read the specs of the protocol you want to implement. Its a matter of engineering rigorousness. Brute-forcing until "it works" doesn't cut it.

[vlovich123]

I think you're missing the fact that experience has taught us repeatedly that separating the protocol definition from the wire format is a good idea. But sure, feel free to ignore the many lessons and blame it on individuals as if anything could be implemented free from human laziness, error, & economic demands (which btw is ironically a lack of engineering rigour which I was always taught as you assume that humans will be lazy, corrupt, make mistakes & that economics of making things as cheap as possible are a real part of engineering & not something to handwave away as "they're not doing real engineering").

[robryk]

To steelman the GP's POV: there are other parts of solutions to problems where similar levels of rigour are required and cannot be filled in by using a preexisting library (state machines for distributed business logic come to mind as an example). Eliminating the need for that here doesn't help that much in general, and might even make things worse, because it gives people less experience with tasks demanding rigour before they tackle ones that are both subtler and harder.

[vlovich123]

Learning to blindly follow a spec for the purposes of parsing the SMTP wire protocol doesn't give you extra ability to follow the state machine or distributed business logic specs better. It just adds to the overall opportunities for you to make a mistake. This also ignores the fact that SMTP specs is split across multiple RFCs with no single normative version which further complicates the probability that you implement the spec correctly in the first place.

Engineers get better faster because they leverage better tools and build tools to overcome their own shortcomings and leverage their strengths, not by constantly being beat into shape by unforgiving systems.

To be fair, what you and OP said is not an uncommon mentality. It's even shared in a way by Torvalds:

> [easier to do development with a debugger] And quite frankly, I don't care. I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing.

> Quite frankly, I'd rather weed out the people who don't start being careful early rather than late. That sounds callous, and by God, it _is_ callous. But it's not the kind of "if you can't stand the heat, get out the the kitchen" kind of remark that some people take it for. No, it's something much more deeper: I'd rather not work with people who aren't careful. It's darwinism in software development. It's a cold, callous argument that says that there are two kinds of people, and I'd rather not work with the second kind. Live with it.

He has similar views about unit tests btw.

I personally would prefer to work with people who are smart & understand systems and have machines take care of subtle details rather than needing to always be 100% careful at all times. No one writing an SMTP parser is at Torvald's level.

I'm not arguing that this excuses you from being careful or failing to understand things. I'm saying that defensively covering your flank against common classes of mistakes leads to better software than the alternative.

[im3w1l]

> This also ignores the fact that SMTP specs is split across multiple RFCs with no single normative version which further complicates the probability that you implement the spec correctly in the first place.

This is a point I agree with and the fact I see it mentioned so rarely, that standards are split across multiple RFC's makes me suspect that people don't mention it because they don't know because they never read them in the first place, and rather try to follow the implementation of some existing program.

[256_]

It can get tedious and annoying, but I don't think it actually affects the likelihood that you'll implement something wrong. The RFCs link to each other when needed. Also groups of RFCs often get combined and edited into a single revised RFC for simplicity.

This makes me wonder: How could the IETF's approach to standardisation be improved? I'm not sure how to fix this problem without overhauling everything.

[blueflow]

Research is also a real part of engineering. One should not omit it and end up with a SMTP implementation like in the article.

[ninkendo]

Yeah someone should get in their Time Machine and tell those idiot SMTP RFC authors in the 1980s that they should have used a wire format that wouldn’t be invented for another 30 years.

[Gigachad]

You don’t need to understand SMTP to send email. You just use a library that implements it and lets you just pass in a html doc.

[Joker_vD]

Reading is for nerds. Real programmers™ write. And they write code, for the machine, not docs or specs or any other silly stuff intended for interhuman communication.

[bregma]

Ah, yes, the Agile manifesto.