It's too bad there aren't more streaming JSON parsers like oboe.js[1]. It would be nice if parsing libraries always supplied an event-based approach like this in addition to parsers that build up the entire data structure in memory.
Taking out patents is like FOSS, though, in that the effect is that, once the patent is gone, anyone can work in that area without worrying about infringing that patent. So, even if the occasion might be a threat to a multi-billion dollar company, this is a case where helping such companies is well-aligned with the needs of the FOSS movement.
I remember getting that book from the library and reading it cover to cover. I never really tried to do any of the experiments, though, but it was definitely my favorite science book as a kid because it wasn’t full of safe and boring experiments
The macOS utility Audio MIDI Setup allows you to pick separate devices for this and it also lets you separate the device for system sounds from the device for other sounds.
Maybe it will work out, but I think we’ll regret this experiment because it’s the wrong sort of “force accelerator”: writing tons of code that should be abstracted rather than just dumped out literally has always caused the worst messes I’ve seen.
We’ll see if this is a good idea when we start having millions of lines of LLM-written legacy code. My experience maintaining such code so far has been very bad: accidentally quadratic algorithms; subtly wrong code that looks right; and un-idiomatic use of programming language features.
The funny thing here is BEAM is “immutable infrastructure as a programming language environment” which, to me, is strictly superior to the current disjunction between “infrastructure configuration” and “application code”.
Erlang defaults to pure code and every actor is like a little microservice with good tooling for coordination. There are mutable aspects like a distributed database, but nothing all that different from the mutable state that exists in every “immutable infrastructure” deployment I’ve seen.
The idea that copyright is necessary for this is ridiculous: copyright is necessary so that publishers and other middlemen can sell copies of their catalog, often with no more than a pittance to the artist. I’ve talked to a bunch of published authors who spent years of hard work on their books who receive no money at all, or an insignificant amount, from ongoing sales.
My experience is building streaming systems using “exactly-once delivery” primitives is much more awkward than designing your system around at least once primitives and explicitly de-duplicating using last-write wins. For one thing, LWW gives you an obvious recovery strategy if you have outages of the primitive your system is built on: a lot of the exactly once modes for tools make failure recovery harder than necessary
The problem with autoincrement in this context is you can’t reproduce the right value when replaying the input streams for your stream processing job. Hashing some combination of values and using that as a primary key solves this problem nicely and, when you’re using bitemporal data modeling, makes it easy to correct mistakes. The point of standardization is compatibility, not standardizing the sequence of keys used.
An issue I've always had with UUIDs and ULIDs is there isn't a great way to generate one deterministically, as far as I can tell: for a lot of use-cases, being able to reprocess data and generate identical IDs is really useful and there isn't a standard way that I know of to achieve this.
Houston is actually a good example of this: the city has no zoning laws and so the workplaces are relatively evenly distributed across the metropolitan area. It may not be ideal, but you don’t really appreciate this aspect of the city as a visitor.
I wonder if this could be solved with partitioning on the deleted_at column; you’d only need two partitions: one for live data (deleted_at is null) and one for deleted data. Then, in Postgres at least, you could just query the live partition directly when you want to skip deleted records.
> It's kind of impressive that Common Lisp is the only language I use where I can't expect code written today to work next month due to Quicklisp lacking versioning outside of the date attached to dists.
I think the lack of version pinning is a positive force in stability: reducing the pain of breaking changes increases the likelihood that library authors will break things.
Lisp macros don’t actually make code harder to read and think about and, unlike the way widely used tools like Flink and Spark do code generation, it’s easy to see what the generated code looks like.
In practices, images are just a deployment tool in CL and most people don’t actually do “version control” by saving and restoring images or using hot code reloading. However, these features enable a development experience that I find much more pleasant than any other language I’ve tried.
I don’t think so, it’s been a while, but I think there were tools for copying history between cvs servers. I don’t remember CVS being particularly difficult to manage.
I use CVS, RCS and Subversion on my personal projects for several years before I learned git. I don’t remember any of them being a pain to setup for small projects and Sourceforge provided free CVS hosting for small projects.
OCSP sounds to me like a really bad idea: certificate expiration is already a significant cause of issues and now we add a whole new way for certificates to break your site?
I think, for most cases with partial validation, you should parse the fields first into valid types for those fields and store them in a hashmap or something. When all the fields have been collected, parse the hashmap into your aggregate type.