4 ms·
> Perhaps 70% of developer time is spent dealing with parsing, serialization, and persistence. Values are encoded to and from JSON, to and from various binary f
by ripter 11y ago
> Perhaps 70% of developer time is spent dealing with parsing, serialization, and persistence. Values are encoded to and from JSON, to and from various binary formats, and to and from various persistent data stores… over and over again.
This is not my experience at all. I've spent maybe an hour or two in the last few months on parsing, serialization, and persistence. For the work I do, these are all solved problems.
> Another 25% is spent on explicit networking. We don’t merely specify that a value must be sent from one node to another, we also specify how in exhaustive detail.
Honestly I'm not sure what the author means by this. If I have a value others might want to know about, I just trigger an event. There is no "exhaustive detail' going on. (Plus events are easy to grep).
>Somewhere in between all this plumbing code is a tiny amount of interesting, pure computation, which takes up the remaining 5% of developer time. And there’s very little reuse of that 5% across applications, because every app is wrapped in a different 95% of cruft and the useful logic is often difficult to separate!
Boiler plate code used to be an issue, but the languages I still use have ways around it. (macros, first class functions, extending, etc). We build modules and libraries and controls, all reusable code that lets me spend most of my time being bored in meetings.
- jackmaney 11y ago>> Perhaps 70% of developer time is spent dealing with parsing, serialization, and persistence. Values are encoded to and from JSON, to and from various binary formats, and to and from various persistent data stores… over and over again. > This is not my experience at all. Yeah, unless you're tinkering around in a side project just to learn something, don't build your own JSON parser or writer. I've spent WAY more time thinking about how to structure my data for serialization than how to serialize it. For the vast majority of use cases, serialization is such a solved problem that if there isn't an obvious way to proceed, you're probably doing it wrong. >> Another 25% is spent on explicit networking. We don’t merely specify that a value must be sent from one node to another, we also specify how in exhaustive detail. > Honestly I'm not sure what the author means by this. Doing low-level socket programming? Maybe? But in the grand scheme of things, that's probably a fairly specialized use case.
- mercurial 11y agoIf you're doing low-level anything, it's usually because you're interested in the "exhaustive detail". This is quite confusing. > Also as a result, Unison has a simple story for serialization and sharing of arbitrary terms, including functions. Two Unison nodes may freely exchange data and functions—when sending a value, each states the set of hashes that value depends on, and the receiving node requests transmission of any hashes it doesn’t already know about. Using nameless, content-based hashes for references sidesteps complexities that arise due to the possibility that sender and receiver may each have different notions of what a particular symbol means (because they have different versions of some libraries, say). Yeah, I can see how this is going to solve the problem of persistence and networking once and for all. Or not. As for sidestepping the problem of having different versions of the same library on different nodes and serializing data, that's going to work fine until the first rename, or when node A with version 1 of the library sends a data structure with half the fields understood by version 2 of the library on node B...
- sixbrx 11y agoHe addresses this issue - see the part about using hashes for everything so neither names nor lib versions matter, only the contents do, identified by hashes.
- hyperpallium 11y agoMaybe the author started this project some years ago, before parsing and network libraries were common? Because if you don't have libraries, he's right. Starting from scratch can yield radically better solutions than how tech/market happened to evolve.
- nkassis 11y agoIt would have to be extremely old for that to be true. All the problems he mentioned have had some form of solution for decades. Some uses cases needed significant changes in those solutions (ex: need for NoSQL DBs) but most development have stayed in a zone where the available patterns existed for the things he mentioned.
- breadbox 11y agoIndeed. I think this is the key takeaway from that whole passage: > These numbers are made up, of course
- hyperpallium 11y agoI agree on parsing/serialization/persistence; but when interacting with a new JSON format, although the parsing is free (via a library), you still have to interpret/bind/integrate it into your own app's data structures. Often this is implicit in looking up values in the JSON, then calling something with them - but there's still that intermediate layer. If you're often dealing with new JSON formats (and I think most developers aren't), this integration/gluing would take up a large proportion of development time.
- slowmovintarget 11y agoFollowed by: > These numbers are made up, of course...
- tzakrajs 11y agoI have no idea what world the author comes from, but it doesn't remind me of my day to day development efforts using Python.