crabbone
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.
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.
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 :)
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 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.
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.
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".
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.
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.
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.
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.
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.
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.
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.
> 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.
Packaging, in this context, means a unified interface that describes to the tool what needs to happen to the source code in order for it to be transformed into a binary package. There are about a dozen tools that can package Python binary modules, setuptools, SWIG, bind11 and so on. Each does it in a completely different way. In practice, if you want to build the packages now available on PyPI, you will not be able to come up with a single tool that can build every one of them, probably, not even half of them.
All this talk about standardized metadata is worthless because of what actually goes into the package. The metadata is the least of your problems when packaging Python code.
Nobody cares if package metadata is standardized. The tools aren't. The tools are the problem, not the package format.
Well, if the poster says something that is blatantly untrue, how would you call them? Liar describes exactly someone who intentionally tells something that isn't true.
Trying to grow a business that relies on bespoke hardware in the age of cloud monopoly is an uphill battle.
The company I talked to explained the use of FPGA by saying that FPGAs are offered by major cloud vendor, and so are a commercially viable direction. While making their own dedicated chips is not only a lot more expensive, but also doesn't have a lot of customers (people don't want to maintain their own h/w, especially of a bespoke variety). The bespoke part might be why Samsung didn't pursue the idea. Essentially, if eg. AWS doesn't buy this from you and makes it an offering that customers may reasonably rely on, it's too hard to sell.
They also told me that they've started as a h/w shop and that they have competitors who are building ASICs rather than programming FPGAs to do the same (with, potentially, even more performance gains).
This completely changed the perspective for me. Before, I had this idea that if I need to optimize database performance, I'd first look at indices. Then, at how much memory is available to the database for various tasks. Only after that, I'd look at I/O performance, but, mostly, because of fsync configuration.
It wouldn't even appear to me as a possibility that the compute can become the culprit of optimization. But, apparently, it's a new hot thing.
* * *
From my experience with storage testing, which also included quite a bit of pg-bench exposure... My impression was this: the sort of query that is used for performance benchmark matters the most. It will define the optimization direction. Blindly trying to add or speed-up one resource or another is not going to be an efficient strategy. In the database world, there's this idea of an "ideal" benchmark. Without too much detail, it imagines an "ideal" business accounting back-end, the sort of queries it would have to execute. It defines an "ideal" unit that roughly encompasses one "sale", and then it measures how many such "sales" a business can perform per unit of time. This will translate into some ratio of selects / inserts / deletes / updates with some index hits and some linear searches etc. But it's all extremely vague and it's very hard to adapt this benchmark to the actual business needs of the database being tested.
There's also a question what to optimize for: the resource usage? the response speed? the concurrency? In some scenarios, I can see how storage would factor in, but there are also certainly scenarios where using a faster, in some sense, storage will not result in any meaningful gains.
What's missing for me here is how the data-centers can be connected to generating comments on social media. They are simply not good for doing that. For example, the IP ranges of data-centers are well known, it would be very easy to distinguish between a comment originating from a plausibly private-looking network and data-center network. They are also easy to ban wholesale.
The typical h/w in a data-center isn't designed for the tasks like publishing multiple plausibly authentically looking comments. It would need to pretend to run multiple desktop browser sessions or multiple phone browser sessions. It would need to do this to accumulate some cookies to create an appearance of a real user.
Data-centers are cost-effective when you need to do things in aggregates, or if you have tasks that require large amounts of compute / storage / network. They offer no obvious benefit when it comes to imitating multiple individual desktop or phone users because their h/w is more expensive than the consumer-grade variety. The obvious better way to do that is to buy cheap phones in bulk and run them through user-space application that automates Web browsing.
In a way, what you are suggesting is like building a train track in order to take your child to school: you can make it work, but it will be a lot more expensive than just walking, or, at most, driving to school.
You could, of course, repurpose a data-center to run a bunch of emulators and have some h/w to plug in a bunch of SIM cards, but... why? It probably won't be very cost-efficient, and you need some bespoke h/w and virtualization solution to do it...
The bot traffic the news about bombing data-centers refers to is the crawler type. They collect information and index it for later searches, they don't interact with social media.
NB. valid and high value targets are not the same. Valid means it furthers some military goals while minimizing civilian impact. High-value means that it has a potential to alter opponent's strategy.
I'm on the fence about whether data-centers are valid targets. But, even if they aren't, it's not a terrible thing to do to bomb them, as it will not have any severe adverse effects on the civilian population. Of course, in the context of a war where there are much worse things to bomb. But the parent was making a comment about data-centers being high-value targets, and I don't see a way to justify that. It probably doesn't even factor into the calculations of the military strategists.
The reason why Ukraine, Russia and Iran are targeting data-centers is because they are easy targets with a lot of expensive equipment, but they don't really impact the military operation. So, they aren't high priority targets. Bomber airplanes, air defenses, launchers for ballistic missiles, command centers, factories manufacturing strategic military equipment, telecommunications, energy infrastructure would be the examples of high priority targets. The data-centers are more of a "we have excess drones, why not use them?"
I find it hard to believe that the military will intentionally use civilian data-centers for its own purposes. At least, not for the core of its operations (for auxiliary functionality: maybe). Military data-centers are likely to be in protected locations, perhaps using different h/w that addresses the cooling problem.
Also, it's a bit myopic to think that AI is having such a universal and large impact on society. Jobs that provide essential goods and services are, by and large, unaffected by AI. Farmers, construction workers, cooks etc. don't really use any of the AI stuff on the day to day basis, if at all.
Since Mariupol fell to Russia, they never counted the dead. There are horror stories of the bodies not being buried for month after surrender, and in some cases, Russians simply pawed over the places with many dead (a prominent example is the theater in the city center, but there were more).
The numbers you are quoting are the "counted" ones. Mariupol, Sieverodonetsk, Kherson, saw a lot of deaths that were never counted.
Sorry to bring another conflict into the picture, but it's useful to illustrate the point. In Gaza, the "health ministry" used a different "technique" to count the dead. Normally, to establish that someone died, there has to be a qualified medical professional at the scene, they also have to get a hold of identifying documents (or else, they will be counted as "John/Jane Doe", but in the morgue, much later). In some "special" cases a non-medical professional may record a death (they are usually defined using the language like "the head is more than 50 cm away from the rest of the body" etc.) But they switched to "incorporating reports from the news sources" (i.e. if some newspaper reported X people killed in some event, they just added X to the tally).
After the front line stabilized in Ukraine, they had no reason (or excuse) to count their civilian casualties in the way Gaza administration did, so, they never incorporated those who were never properly reported. And that's why we have a relatively "low" numbers. If Ukraine is ever able to regain control of the territory captured after 2022, these numbers are bound to go much, much higher, as they will have to deal with eg. property ownership and would have to either declare the previous owners as deceased, or actually find them.
Some nice things had been lost, some nice things had been found. Maybe it's also because OSX was also somewhat of a downgrade from OS8/OS9 in terms of user experience. Especially, Finder became a lot worse. So, people didn't feel very motivated to upgrade, and it made the switch easier... But, overall, there was very little struggle, the time we'd spend setting up the newspaper / magazine for print didn't really change.
Well... now, when I think about it, most of us used PCs at home. So, maybe it's not a fair comparison. But, even people who had Macs as their home / personal computers didn't seem to have any issue with the switch.
I think, some people kept the keyboards that came with G3/G4 (the clear heavy plastic ones with black key caps). They could be used with PCs. People didn't keep them to preserve the Mac-style layout (it wouldn't work anyways iirc), they just liked the quality of the physical product and accepted that some keys won't work the same way they did on a Mac.
Even though you could connect Mac mouse to a PC, I don't think anyone used that.
However, next week, I started getting calls from other Lycamobile numbers, where it sounded like the same Indian guy, but now he presented himself as a police officer who wanted to arrest my bank account :)
The moral of the story: if you have a phone number, it's been already sold to some shady call center in South-East Asia and it's just a matter of time before they will try to scam you or use your phone for some nefarious purpose. I don't think Lycamobile is unique in how bad their system is and how much they want to extract every last penny from you buy outsourcing every service to foreign companies with zero responsibility and questionable work ethics.
No matter how old, most people have zero introspection or analytical ability, and even if they do, they would not put it on display because that would put them in the "weird" category.
A typical women's profile will differ by country though. This is how most of this stuff looks:
* South-East Asia: women describe themselves as "simple", "down to earth", "family oriented".
* English-speaking Africa: "god-fearing", "faithful".
* Western Europe: "like to travel", "love animals", "live off the land".
Sometimes with a mix of trivia, like whether they are divorced, how many children, smoking cigarettes.
I don't really know what makes people match, but if I have to guess, people go by non-verbal cues they find the the pictures. People reveal a lot about themselves in they way they dress, where and how they take the pictures.
In general, my experience with counseling, therapy, social workers et al. were that you might be better off spending the money on a rollecoaster ride. At least it's guaranteed to end.
Especially the social workers. I have an impression that their exams have an inverted grading scale: you need to score below a certain threshold to graduate.