mrbald

Reading makes your writing better, listening makes your accent smoother. Nothing wrong with using ChatGPT for automating what you understand is a pain, just don’t automate what you do not understand yet, same as with any outsourcing. Not using it on a weekday would make me overspend time on searching in an inefficient way arguably making me dumber, because AI works better when you give a precise question and explain the precise context — that helps with human interaction in chats as well.

A Team-as-a-Service? Would be interesting to be able to create a Python script acting like a team of sales, project management, and engineering working together with telemetry and KPIs dashboard on top. If not to deliver anything useful then as a project management frameworks learning tool.

More like have easier to assess legality status.

We (humanity) need to invent a simple GPLv3 style license “You can derive any data on the data you see here, any derived data you sell or share should mention this place as a source and is subject to the same copyright as the source”. This will imply scraped datasets should become public and the law enforcement bodies will be able to work in an established framework to fight copyright and license crimes. Just blocking me from using any tools I want to make sense of the world around me (data on the internet sites being part of it) with crawlers and whatnot, is inherently evil, and is not logically consistent.

I myself almost exclusively use LLMs as a scoping/pathfinding tool, an extremely powerful version of search engine and a ultimately knowledgeable sparring partner if you will, did not even dare tasking it to write production code (so o4-mini, not Claude)

Central counterparty concept implemented by most exchanges is a valid service, as otherwise counterparty risk management would be a nightmare - an example of a useful “middleman”.

No, their python support repository readme explicitly tells it’s highly experimental.

Looks like every man and his dog is an expert on North Koreans. Did it occur to you that most citizen there are hostages of the own state and may be fighting hard to get a piece of bread on the table? I highly doubt they give a shit to the US, or the internet or the hacker wars of any kind.

Code should have a hierarchical structure, so one could read it on the high level of abstraction and also zoom in gradually, as necessary — this is what they usually mean by “code is the documentation”, plan the reading process as you plan the functionality.

It is a very important aspect of the readability, otherwise you will just sink in details when reading. But it is not easy to formally validate with tools, so naturally it is better to have both code and a picture and have discipline to keep them in sync.

"make sure it's something that can actually be checked" -- I'd love to find out about a sane (not purely academic, financially viable) way to do it. Since university days I know that a piece of paper is an irreplaceable tool - cheap and universal. I usually just draw it on paper, then code, then fix the code, then update the painting, and do it over again until both match each other and work. Never fails me.

Always have a drawn picture, if you cannot draw it you will fail to explain it to others (and to see design gaps) and inevitably everyone will think it’s an over engineered complex shit.

Design-wise:

The IO multiplexing — event loop(s), the completion callbacks go to the "Processing".

Processing — usually beneficial to model as a processing graph (tree/pipeline being specific examples of a graph without feedback loops). It's a clean, low overhead abstraction, easy to visualise (and thus discuss with others), easy to change structurally or in the "aspect oriented" way.

Examples in JVM world: Netty pipelines, AKKA actors, streams, and graphs, in C++ world ASIO & its executors sub-framework.

Queues/Threads is still a sufficiently low level to comfortably operate on.

"If one starts adding a thread here and a mutex there..." -- precisely that!

They are low level abstractions and they don't save from the hardest to debug and fix problems - race conditions and inconsistent states, especially in distributed applications.

No mainstream languages give you a solid high level abstraction to build on. Some frameworks, kind of, do: ASIO in C++, AKKA Typed Actors and Reactive Streams and JDK CompletableFuture in JVM world, etc.

Problem of getting the concurrency right is very much identical to the problem of getting the system design right.

In both cases it takes a lot of hard work to learn how to not produce "dead-borns" or "genetically pre-disposed".

In both cases the course of "least resistance" (using intuition instead of logical reasoning) used by many as the default will most likely fail you. To develop an intuition of what is easy and what is hard with both system design and concurrency design is a matter of years of hard work of trial and error.

The actual question is why the complexity is so counterintuitive. I think this is to do with the Dunning-Kruger effect (the less you know the more confident you are).

In both cases the solution seems to be to keep beginners away from this and to have the same consistent, peer reviewed, approach across the system, and a process of improving it in a structured way. And of cause prefer higher level abstractions -> computation graph, pipeline, event loop, etc. over just hacking an ad-hoc Frankenstein out of low level primitives (which seem totally "simpler" if you ask a beginner).