kpmah

Experimenting with operational transforms with https://rootdoc.app

I wanted to try a non-trivial project with AI assistance and I enjoy writing compilers, so https://vegen.dev

I'll write up my experience in a blog post

I watch this show, but one of the most annoying things about it is that the traitors are incentivised to murder the smartest, most intuitive players first, leaving people they can manipulate easily. Maybe you could argue the smartest move is to play dumb.

This is at its worst in the second Australian season, which is an incredibly frustrating watch.

I recently came across (but haven't yet used) Typia, which appears to let you do validation with regular TypeScript syntax: https://github.com/samchon/typia

Author here, 8 years on.

Although the advantages are real, I can't say I have had much opportunity to implement schemas like this. The extra complexity is usually what gets in the way, and it can add difficulty to migrations.

I think it would be useful in certain scenarios, for specific parts of an application. Usually where the history is relevant to the user. I think using it more generally could be helped by some theoretical tooling for common patterns and data migrations.

Another misconception is that they somehow scale horizontally "better". They do let you scale components independently of each other, but this isn't as useful as a lot of people seem to think it is.

Even if it doesn't directly cause extinction, it could do things like destabilise nuclear powers.

Science denial. It's not going to stop at 'a little warmer'.

https://skepticalscience.com/10000-years-warmer.htm

A review of 'Apocalypse Never': https://yaleclimateconnections.org/2020/07/review-bad-scienc...

Obviously you're in a better position to evaluate the trade-offs for your application than I am, so I'm not saying your decision is wrong, but this can potentially decrease availability if your application depends on both PostgreSQL AND Redis to be available to function.

To spell out good reasons for doing this:

If you're already using Postgres, you can avoid increasing operational complexity by introducing another database. Less operational complexity means better availability.

You can atomically modify jobs and the rest of your database. For example, you can atomically create a row and create a job to do processing on it.

I'm a type enthusiast, but dynamic languages make a lot of sense for small programs that either give you an immediate answer or fail to run (i.e. not long running, few branches).

In those cases, the difference between a compile-time check and a run-time check is much smaller.

I've worked at a place where this was cargo-culted and it worked horribly. All the worst aspects of 'services-first' design.

I think this works much better when each team is working on what could be regarded as a complete end-to-end product e.g. a database. It works poorly when each team is working on part of a product.

The NHS is one of the most efficient health systems in the world.

The discussion here is frustrating because people are assuming that you'd pass the SQL directly to your database backend and expose your entire schema and all your data.

SQL is just a query language, just like GraphQL, and is no less 'secure'. You can still have a layer between the front end and application database.

A practical way to use SQL would be to expose the subset of data that is visible to the user and allow that to be queried by SQL, just like it would be by GraphQL or REST.

This spreadsheet-style functional programming is quite similar to a (very limited) prototype I wrote a while ago: https://kevinmahoney.co.uk/ocell/#example/polynomial.json

To add to that, I think the biggest thing to take away from Conway's law is that splitting teams of developers becomes a technical problem. If your goal is to efficiently build a product, technical expertise needs to go into that decision.

This is why I say Conway's law is a bad thing for modules (regardless of how inevitable it is): technical considerations are often not taken into account, and technical design is ossified by team structure.

I think what I'm trying to say is that my definition of a module as a "unit of encapsulation or understanding" is the more inclusive and general one, as it includes network and process boundaries. The OP's use of the word is the restrictive one because it excludes language-level modules. I say this because security and isolation are not typically goals of language-level modules.

This is fine to talk about, of course. It's just confusing to reconcile the article with my definition of modules, which I thought to be the common one.

Specifically in the context of modules, I think it is a bad thing. It's hard to describe because I do it quite intuitively, but (very broadly) the way I find module boundaries is by trying to find the minimal interface for the maximal amount of code. For me, this usually revolves around some kind of data structure.

Importantly, this is completely independent of team structure. The boundaries between teams are not necessarily the minimal interface.

IMO this is a confused take on modularity. I think isolation and security are related concepts, but not what modules are for. Those things have to follow module boundaries, but they're not the goal of modules. For me, modules are about understanding; in order to use this code you don't need to read all of it, you just need to understand the interface. Modularity is for humans, not computers.

They do often follow Conway's law, but that's not a desirable thing. Most modules are outside of that kind of context -- they're in libraries written by people you don't communicate with at all!

I'm interested in people's opinion here. I'm also planning an article on the relationship between services and modularity.

The main problem I have with the 'monolith first' advice is that it implies 'microservices later'. It feels like people have forgotten how to build good, simple, modular code.

If it is so obvious, why are all the legal challenges, even the ones involving Trump-appointed judges, failing? Why can't the challengers come up with a scrap of evidence?

As with Rust's 'unsafe', the fact that you can explicitly circumvent checks doesn't make those checks useless. If something goes wrong you know exactly where to look.

But, in the general case, who is this lowest common denominator programmer you are writing for? I can probably work out a few lines of terse Haskell more quickly than a page or two of boilerplate Java, because that's what I'm familiar with. Readable code is about pattern recognition, and everybody has a different set of patterns.

"Shakespeare for Dummies" works because English speakers tend to have a shared cultural familiarity that you can write for, but programmers typically don't.

That's not to say style isn't important. I'd say consistency is more important than any notion of simplicity, because once the reader has recognised a pattern they can re-recognise it quickly.

have a DefaultContract entity of some kind somewhere

This is the OO mindset described at the bottom - the odd compulsion to have a reified entity for every concept.

A lot of people have missed that the representation you persist doesn't have to match the representation you present. In this case, don't store default contracts, but present them e.g. via a database view.

The problem with a narrow OO mindset is that it encourages encapsulation and atomic objects with hidden state. Simply gluing those pieces together can create suboptimal representations - a more holistic thought process is better.

I think you are vastly overstating the risks of changing requirements. It is usually easy to go from a less permissive model to a more permissive one, but the opposite is often difficult.

I also experiment a lot with structural editing. My latest project is an editor for a lisp-like language for building small audio synth programs: http://kevinmahoney.co.uk/ocellator/

Hazel looks fantastic - I don't think I've come across it before. I think an obstacle structural editors have to becoming more widely adopted is that they start out very general and don't immediately solve a problem that people have. You can usually build little toy programs but not much more. What I've tried to do is to focus on creating an editor for a small DSL that helps with a specific problem.

I've had some problems understanding the Laplace transform. Maybe somebody here can point me towards some material.

I have an interest understanding how IIR filters are designed, and I always get stuck at this part in DSP books. The Laplace transform is used, but as well as finding the mathematics difficut I don't really understand why it is being used at all. I think it is trying to replicate the effect of an analog circuit?

I had a go at writing a type-inferred composable language for database queries a few months ago: https://github.com/KMahoney/squee