61–70 of 135 posts
> 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. Off-topic but.. by using Lisp one can refocus that 70% to actually solving problems.
> 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.…
> 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.…
>> 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 ti…
I also suspect (being a language design geek, and also having worked with some very large distributed systems) that the reason why this is seductive is also why it's unworkable. I think I probably do spend close to 70% of my time dealing with networking and data formats (and yes, I use off-the-shelf serialization formats and networking protocols), but that's because a watch is very different from a phone which is very different from a persistent messaging server which is different from a webpage, and Bluetooth is very different from cell networks which are very different from 10G-Ethernet in a DC. Try to dump your server data structures directly to your customer's cell phone and you're about to have a lot of performance and security problems.
Earlier quoted context omitted.
>> 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 ti…
Maybe 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.
Your time would be much better spent writing a plug-in for Eclipse or IDEA.
Unison is also already the name of a file sync program written in OCaml, a team collaboration service, a proprietary newsreader and apparently a security management (access control/intrusion detection/firewall/etc) platform. The file sync is probably the most popular, and the one that first came to mind. I realize that the exclusive namespace for software titles is shrinking, but I think that when you already have th…
It was also the name of a popular general midi soundfont :)
Pro Tip: if I have to dig through eight paragraphs of fluff to find out what the fuck your product is, then you REALLY need to rethink the description of your product. In particular, it was not at all clear what was meant by a "programming platform". Until I finally stumbled onto the description below, I thought it was just another web-based IDE. > What is the Unison platform? At a high level, it consists of three co…
Earlier quoted context omitted.
Maybe 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.
It 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.
I really enjoyed reading about functions being identified by their hashes, and what advantages that could have.