Point 1 is particularly important nowadays: in the past months the majority of things I reported in code reviews are on LLM generated code, which was obviously never read by the human.
> We need the penalties to be something other than fines, which are ultimately treated by companies as routine costs of business.
It's true that fines are nothing more than predictable costs, so maybe an option would be fines in percentage of the incoming of the company: this way it could make a real impact. I know in some north Europe countries the speed limit fines are in percentage on the personal net worth.
Bail only works while waiting for the court date. I was talking about the actual sentence if found guilty.
Going after individuals instead of fining the company is still a better deterrent. Corporate fines are paid by shareholders and customers, not by the people who made the decision.
As a side note: If we believe that well paid lawyers can win all cases, there is nothing to discuss under this thread anyway. No fine or sentence can save us.
Income is too small, how about in terms of the highest market capitalization between deciding to do the bad thing and being convicted of the bad thing? Maybe some of these penalties should result in bankruptcies for the most egregious big players, and when I say bankruptcies I don't mean restructuring but actual corporate financial death: firesale auction the assets, debt holders lose much of their value, equity holders get squat, and all employees are out on their asses having been let go. Do it to a Microsoft or Google sized company, scare the piss out of the rest! Then implement protection policies to make it impossible to move headquarters out of the country without having product prices end up 2-4x higher, so domestic competition (which could be let to run tax free) can come up and fill the void. Also tax the hectomillionaires+ more heavily on assets, income, and capital gains!
I think that the fines should be the amount per crime that is being fined, plus the total amount of all revenue from whatever the fines are related to (including indirect, but only counted once).
Eliminators are undoubtedly the most difficult aspect of type theory. In this article we will try to make more clear how they work, but most importantly why we need them. This article will present some analogies between eliminators and constructs of programming languages (such Python, Rust, Scala, …) which can help who knows some basic of computer programming understanding eliminators.
I'm Italian and I don't like pasta al dente. Obviously neither overcooked, but I like it cooked. In fact it's a drama that since some years they started making pasta which remains al dente: I usually cook it at least 5 minutes longer than what is written and it is still slightly al dente: very disappointing.
You can increase the guess accuracy a little by looking for the "tLS" characters , skipping the first 3 chars. Also this is a mnemonic about TLS and identifies all strings starting with 5 dashes, excluding so most of yaml documents
Theoretically only one operation is sufficient: both NAND and NOR are universal gates, meaning all boolean operations are expressible in terms of only NANDs (or equivalently only NORs). The downside is that the expressions became longer.
In chip design, boolean logic circuits are often reduced to their simplest NAND/NOR representation, optimized, then translated to RTL, DTL or TTL as explained below:
I studied this heavily in my electrical and computer engineering (ECE) courses in the late 1990s, and wish that more programmers were exposed to it.
On that note, I never had a single spreadsheet course. Which is regrettable, as that would have tied functional programming to logic circuits. Then it's a small step to understand mutability, then monads (which are more difficult), how they negatively impact determinism, and how that greatly increases the mental load of tracking state in imperative programming. Leading to why futures, promises, deferreds and async programming in general should be avoided.
Unfortunately these insights are all but unknown today, which left us with the over-engineered soup of web languages and frameworks that bury us in mountains of unnecessary complexity. Which we tried to get away from when declarative and idempotent HTML/HTTP metaphors were invented late in the desktop computing era, when C++ and object-oriented programming dominated tech.
reply