crabbone

Oh, it's not just a performance optimization. But you've said it yourself: "a new python interpreter and compiler". A lot of Python code out there lives with assumptions of CPython interpreter built into it. Pretty sure pytest would've been affected, should JIT replace the existing interpreter, for example.

Anyways. I don't believe that Python needs a JIT compiler. I don't believe that CPython can realistically replace its interpreter with JIT compiler without causing major problems with the community packages.

The way I see it: Python users today desperately want Java. They want it called Python because there's some vague memory still around of Python being cool and Java not being cool.

In Russian there's a children tale about a hungry soldier returning from a war and a greedy old woman who offered him a bed for the night. The old woman then pretends to have no food for dinner, and a soldier promises her a magic trick of making a porridge out of a hatchet. And so he tells the woman to put a pot on a stove with a hatchet in it, and step by step he makes her add all the ingredients necessary to make a porridge to the pot. The story gave birth to the idiom "hatchet porridge", which is used to describe anything that was created in a similar way: by deception, when another goal was allegedly being pursued.

So, to me, the current state of Python is this "hatchet porridge". None of its users want the actual Python (the hatchet is still sticking out of the pot), and they keep adding Java ingredients to the pot in hopes to cook up Java. And so was JIT. It just turned out to be too difficult to throw away the hatchet. An the porridge still has some chipped wood in it as well as a metallic taste.

After working as a programmer for about a decade, I went back to college to try to complete my education. This was when I first encountered code printed in a textbook. And it was just black monospace font on white paper. No color, not even bold / italic etc. It was Java.

Initially, it was much harder to read, both because of the habit I've developed and because, I think, the author also didn't use a "fancy" editor to write their code, so it wasn't formatted properly, didn't observe naming conventions. Well, your typical college professor writing. My first reaction was to type the code into the editor so I can explore it easier. This, of course, also provided syntax highlighting.

Of course, it took extra time. So, eventually, for shorter snippets, I'd just suffer, skipping all the typing part. I later discovered it to be somewhat helpful exercise when using Git diff or other Git commands that displayed code snippets in terminal w/o highlighting. But then the industry caught up to it, and now I don't have to read unadulterated Git output like that.

So, my conclusion so far: highlighting helps to discern the structure, to process larger blocks of code and to navigate it more efficiently. You can get better at reading code that's not highlighted, but it's never going to be as good as reading the highlighted code. It just seems like the struggle to even get to the level where it's palatable not worth it as there are very few situations where it would come in handy.

It will just take longer.

People inhabiting the Russian empire weren't all that bad. But there were multiple stages of descent into the atrocious society I remember from the late 90s. It also didn't go in a straight line. The 70s in the Soviet Union are remembered as the time of a "standstill" because for the average citizen, the life was mostly palatable, the living conditions gradually improved and people were genuinely nicer (than, say, during and right after the war, or in the early days after Stalin's death). They didn't know that the state, as a whole, was living on borrowed time sliding deeper into a credit hole.

This is also why the Russian version of "boomers" wants to go back to the Soviet times so much: they remember the 70s and how much nicer everyone was.

Oh, and since we are here already, I'm going to mention my favorite quote from Dostoyevsky (from memory, maybe not 100% correct):

> Poverty isn't a vice, but destitution, kind sir, destitution is a vice.

This was spoken by Marmeladov, a former government bureaucrat who started drinking after being laid off and to make ends meet took to prostituting his daughter, Sonya, the love interest of the protagonist, Raskolnikov. His idea was to say that there's a threshold in poverty, where a person breaks and succumbs to the vice being no longer able to afford to behave decently. Obviously, using himself as an example.

Poverty was also the motivation for Raskolnikov to kill the pawn shop owner, however, he didn't think about explaining his behavior in this way. I'm not sure Dostoyevsky himself would side with Marmeladov's explanation of the nature of vice, but he definitely considered it :)

Yeah. In general, I feel like programming is missing a glossary. Having this much freedom has its perks, but being unable to agree on basic terminology used in the industry seems like a price too steep to pay for the freedom.

In other fields (I'm more familiar with medicine), there are "bibles" that serve as a medium or the source of common language between professionals. If you are talking about radiology, then you open Basic Radiology by Chen, Pope and Ott on the designated page, and read the definition. And you know that another radiologist will do the same, and so you both have the same reference point.

In programming, even the basic stuff like variables, functions, types etc. aren't defined universally. Plenty of local environments will offer conflicting definitions (and often the definitions themselves are internally inconsistent).

Unfortunately, bodies like Wikipedia cannot serve as an authoritative source on such questions because instead they record the current state of events. They can't choose which definition to follow if there's no authority respected by the vast majority of programmers.

I was thinking about addressing the issues mentioned (multiple times before, but most recently) a couple days ago by a Facebook employee who was scared of releasing code that nobody understands.

I see two possible ways forward, not necessarily mutually exclusive.

* Make AI work with languages with reduced complexity. A lot of language complexity exists to make it (surprise!) easier for humans to deal with the language. For example, generics in a language like Java make it easier because they allow the programmer to write many similar programs just once. And because people are prone to make mistakes when working on repetitive code, generics are useful for people. AI, on the other hand, doesn't get tired. It doesn't care if it needs to implement the same template for a different type a dozen more times. So, if we give AI a language without generics, it will be just as happy, but it will eliminate a whole class of potential errors related to eg. up/down-casting of generic collections. Similarly, we could remove "dangerous" tools like infinite loops, or outlaw some system calls, producing less generic / more purpose-built languages (like PostScript!) Perhaps projects like OMeta could see some revival in this light?

* Replace, as much as possible, the work of testers with proofs, but not AI-generated proofs! The formal specification (which is another way to look at the proof, at least its statement) is where the human being needs to provide input to AI. If it's not possible to read the whole generated code, we need a tool more reliable than a test to convince ourselves that the code does what we want. Formal verification, or, even better, tests generated dynamically from formal specification (there's no need for AI to do that, this can be an entirely deterministic process) should be the way for the human to stay in the loop.

> The Linux kernel—one of the most well-tested pieces of software today,

I feel like these people aren't really experts in the field of testing... Linux is not known for its testing... there's plenty of good things one can say about Linux, but great testing isn't one of those.

Now, things that are well-tested are things that do critical stuff, like avionics, power-plant control, medical equipment, storage... It's software from a different league.

Linux is too big, too dynamic, too distributed between different authors to hope for great testing. And it's OK. I'd rather have more people being able to contribute, not being constrained by the difficulties of the testing than have a very well-tested and borderline useless system.

There's, unfortunately, another meaning for "validation" that's used in the adjacent context. All those form fields are validated, the tool that validates them is called, unsurprisingly, "validator"... To generalize this notion: "validation" can also mean compliance with an arbitrary set of rules, not necessarily the rules imposed by the product design.

I.e. a field in a government form for residence permit might validate if the date entered is between the applicant's arrival date and three months later. And screw the applicant who wanted to apply for the permit before they landed in the country (this is a not invented example).

Also, since I worked in "software validation", I feel like it's important to note that the dictionary definition is different from practice. For the most part, the task of validation is the one that should culminate in the testers OK'ing the shipment of the product. Typically, testers, as well as the rest of the company involved in the shipping, are painfully aware that the product doesn't meet the customer's requirements (or any formal or informal requirements). It is simply declared "valid" because the potential damage is assessed to be manageable. I.e. a product may as well be declared "valid" while having a list of "known defects".

It really depends on the place... When I was a student, I lived in the dorms. Three colleges shared the compound: there was an art students' building, the printing academy's building and the sports college building. We are talking about Western Ukraine here.

The whole compound was on the city's edge. There were two ways to get in there: a pawed road with two lanes and a sidewalk and a trail through a bunch of private houses. The later was not popular because it was longer and muddy during bad weather. I took the second route because the first one was used, beside others, by the sports students. When not in class, these guys looked for an opportunity to punch someone.

Unfortunately for me, I did take the shorter route twice, and both times ended up with major injuries. First time I ended up with the broken nose, second time with a concussion.

It was so bad, in fact, that eventually the city police organized a patrol that walked that road. There were police raids in the dorms as well. I knew two girls who got raped and virtually every student who lived in the same dorms had been beaten multiple times, they belongings taken etc. Same sort of people broke into my neighbor's room, beat him up and took his electric stove (virtually the only thing of value he had).

Very little if any of this was ever investigated let alone punished. The police was poor and understaffed and had a lot of their own problems to deal with. They wouldn't bother to even write down your complaint if you were so naive as to try to file one.

* * *

If anything, my conclusion from my experience is that people are garbage. People don't overtly abuse each other in rich countries because they are afraid of the discomfort that might cause them, the police is well-funded and will, especially, come after the law-abiding citizens first. In a rich country, people want to live by the law because it's gainful and opens a lot of opportunities. This also creates more trust and good will.

In poor countries, the difference between inside and outside of jail is smaller, crime is more attractive because there are fewer legal ways to get rich, violence is punished less and is more attractive as a way to resolve individual conflicts as the official way is dysfunctional. Also, there's not a lot of "fun" otherwise. Also, being "tough" is more important.

If the rich countries were to become suddenly poor, the crime and violence situation would also get worse.

> people left and that understanding was gone too.

This is not how it (supposed to) work. When an employee leaves, they are supposed to show the ropes to their replacement. And if they don't, the person hired into their position is expected to learn it anyways (it will just take longer). So, the knowledge about the product is preserved.

If your company is so unique that it simply... throws away the knowledge and just keeps the physical artifact produced by the now missing employee... that just sounds like an awful way to run a business. Maybe cheap, but awfully dangerous.

> However, we have an on-demand ability to get an arbitrary level of understanding quickly

You still seem to not understand the problem. The production outpaces understanding. The "quickly" you are talking about here is no more. For every thing you understand, two new not-yet-understood things appear. The speed of understanding is what's important, not the theoretical ability to understand, given infinite time.

I'm sorry to say that you misunderstood the question.

There's a huge, insurmountable void between "I don't understand all the code" and "nobody understands all the code", but you seem to think they are the same thing.

In your case, it's OK that you don't understand all the code because another employee who either produced or reviewed the code does. The company, as a whole, still has the understanding, albeit distributed among multiple employees.

The question is talking about the situation when nobody has the understanding. Understanding implies responsibility.

Compare this to eg. radiology department of a hospital. It has multiple radiologists, they read different images from different patients. They don't know much about the work of their colleagues unless they happen to share some of it. The head of the radiology department is still responsible for reviewing their work, but he or she, obviously, can't review all of it because of the time constraints. The system is designed to share the responsibility and the blame for mistakes. If a patient is misdiagnosed and harm results from the error, they may come back and sue the hospital. The investigation then will have to decide whether the head of the department did a decent job assessing other radiologists working in the department, and based on that assessment he or she may be also found guilty of the error. There's no universal answer here, but the idea is that the head of the department should put a reasonable effort into preventing such errors.

I can't see how software development is different in the sense of sharing responsibility. If you are a head of a department, you should be putting a reasonable effort towards ensuring product quality (and therefore understanding of the codebase). How is it determined? -- By independent industry experts, perhaps such experts would organize in some kind of advisory body that publishes best practices for managing the code writing process which explain the expectations and obligations resting on the shoulders of managers. What percentage of code written by the underlings is reasonable to review? How many underlings can serve under one manager? What is a reasonable amount of code produced by a single person? -- We don't have answers to these questions now, but I believe that we need them, and that the regulators will, eventually, start to demand that we have these or similar metrics, or else we would not be allowed to do our jobs.

Not going to work.

1. The reason OOP complained about AI code being shipped without comprehension is because they want to ship of it more and faster. If they had time, they'd review the code. Writing tests requires a lot more time than what people usually spend on code reviews (unfortunately, but that's how it is). And if you think you can generate tests, again, by using AI, then, the bad news are that now you have both the code you don't understand and the tests you don't understand. Don't forget that running tests also takes time, in some cases it takes longer than to write code. So, again, your benefits obtained from AI-generating code won't materialize.

2. Even if magically you were able to procure decent-quality tests (without understanding what you are testing!) There are still problems not addressed by testing s.a. reusability. If you don't understand what the code does, how can you possibly reuse it for something else? Perhaps a small modification or a generalization of the existing code would allow you to reuse the mostly tested codebase for the new feature, but since you don't know what it does, you've missed that opportunity, and, again, the AI-generated code came second in the race to ship the product faster (also, you've got a worse product).

* * *

The question of "how to deal with code we don't understand?" is by no means a new one. Dijkstra's structured programming was a response to precisely this question. His argument showed that programmers can't even anticipate all the potential problems to be found in a 16-bit adder and that exhaustive testing is prohibitively expensive. Therefore, he argued, we should restrict the kinds or programs we write to those that are easier to understand (and that's what he called "structured" programming).

Perhaps, we can find a similar sort of harness for AI writing code, where we can impose boundaries it cannot cross that ensure understanding. I have no idea what that can look like, but I'm absolutely sure that testing isn't it.

> With AI, everyone now gets to act like a PE.

I've heard this before many times, and it's simply not true. The resemblance is there, but there's also a fundamental difference. The difference is in whose name is on the commit, who embraces responsibility for things going wrong. PE will, at most, share responsibility with the person who actually authored the code, AI user is always responsible for whatever code their agent wrote.

As a PE you may skip reading all the code written by your underlings because your underlings have signed a contract with your employer and will be legally responsible for certain things, have they decided to do those.

In the case of actual PE, there's an actual programmer who, at least, believes he or she understands the code they wrote. In the case of AI, there maybe nobody.

Here's an interesting aspect though. There are companies (I'd know, since I worked for one), who sell a product where there's a part of code no engineer working for that company understands. In my case, that piece of code was a formula obtained from some former partner (a bank) to calculate something related to credit check. Nobody could explain why the formula was the way it was, but it was extensively used in testing to validate that our code produced the intended result when it came to this part of credit check. There's a folk tale about DB2 containing a binary blob whose source was likely written in Assembly and was since lost to time, which is essentially a magic component nobody really knows the internal workings of. I'm sure there are more pieces like that around in older companies.

Since I expect the regulators will soon start tightening the nuts on programming in general, especially since AI is asking for such an action, what will happen to these "magic" programs? If I were a regulator, I would have the company, under a threat of criminal punishment in some cases, to vow that they understand the code that went into making of their product and are therefore responsible for what it does. This is not the case today and only in a very few cases were software companies found guilty of criminal negligence... but I think that the writing is on the wall: with AI being used the way it is, the legislation requiring understanding is just around the corner.

I only have a second-hand experience with PhDs looking for jobs. It seems very similar to programming jobs market: it's saturated with worthless applications and the filtering on the receiving end is completely broken. I don't have numbers and wouldn't know how to measure it, but it feels like most applications never get assessed by relevant experts at all. Basically, no matter what you put in your resume it goes straight into the garbage bin.

So, your professor's rules are no longer relevant. There's nobody to speak to, no matter what you write it's not going to change anything. Thinking isn't a priority either.

You need to know people. That is all.

Anecdotally, I had this happen to me. For the context, I'm moving back from the Netherlands to Israel. I've been looking for a job in the Netherlands before giving up and leaving. Despite maybe a hundred or so applications that I've sent, I've never heard from anyone. I think, Dutch law requires a timely response to the application and so I would get template rejections most of the time. Sometimes seconds after applying.

Back in Israel, I also applied through LinkedIn and Indeed. But I also happen to be on the file in some HR agencies which supply candidates to the programming jobs. I've received an invitation from such an agency to interview for a job with a company I've already applied to through LinkedIn (and was promptly rejected). I've landed an interview, and when asked about my job hunting efforts in the Netherlands, I jokingly described the application through LinkedIn and the likes as futile, as nobody reads those applications.

The interviewer start beating his chest assuring me that they would never... I decided to withhold from them the fact that they actually would. I'm still at the... third interview with them now. So, we'll see how it goes.

Anyways. My larger point is: the automation brought to job hunting is very disadvantageous to the junior workforce. Connections always played a role, but now their role is exaggerated. The article describes it as decreased job mobility (nobody quits, so there are fewer jobs to hire people into). And while it keeps the appearance of low unemployment, the problem with it is that it's the same people who are unemployed all the time. Our unemployment model isn't prepared for this. The idea behind social security unemployment compensation is that you find a job relatively quickly and only need a few months to get by before you do. This doesn't work anymore, as unemployment lasts years.

This is bad on many levels: it lowers the number of professionals entering the field, it leads to the loss of expertise as older workers retire w/o having trained a replacement, the effort spent on acquiring expertise is wasted by the young workforce as they are forced to change direction.

> Those things are measurable.

You keep saying this without saying how did you measure...

> you can measure how many new media posts

How? I don't have that kind of capacity. Maybe someone else has, but I don't know anyone who does.

This all reads like a media stunt.

You are absolutely delusional. None of what you write is true.

> This is the entire point of build backends

This is false. Python doesn't have any format, any way of describing how to compile a package. There's a gaping void where such a specification should be. Every tool that does it, has its own bespoke way of configuring it. Most of them don't even care what PyPA has to say about it.

> is no longer true/hasn’t been true for several years.

This has been true as recently as this morning. Nothing has changed in the last twenty years, probably more. No change is planned. The people who put themselves in charge of the process are incompetent to the point that, just like you, they don't understand the assignment and produce piles of worthless garbage instead.

> Build backends are not perfect

Build backends is a nonsense invented by PyPA because they didn't understand what actually needs to be done. The whole concept is worthless. It doesn't address the issue: it doesn't have a generic method describing how to build a Python package. Python doesn't need build backends. This whole circus needs to go.

> you can run `uv add` or `pip install` and get a functional wheel

This has nothing to do with building packages. Ideally, these are supposed to install the already built packages. If, however, you accidentally veered into the "oh, crap, I have to build it now because for my platform there isn't a binary", then pip or uv will poop their pants about 50% of the time because the tool that is needed to build the package is not installed, or the dependencies are missing, or the wrong version of the tool is installed, or it's misconfigured etc.

Worse yet, they shouldn't build anything. This is a batshit idiotic idea that a package installer, by default, tries to build a package if a binary is missing. But, we live in the world populated by people without a drop of critical thinking, governed by worshiping tradition, and that's why these tools do what they do.