We have seen the thing in programming. I'm not a gatekeeper, I love seeing more people to code. On the other hand, along the way, we lost the joy of the journey and only fixated at the destination.
Result is more software at lower quality. The reason is statistics. When you increase the population, you increase the population of every kind of programmer, and people who want the result are favored in most competitive sectors because corporations want something somewhat working yesterday.
...and here we are.
Now programmers talking about code quality is stoned en-masse. If it's somewhat working then it's good. Efficiency, resiliency, maintainability and sustainability is an afterthought. Some of my friends who loved debating programming language theory now don't even care about the code. They don't write it, just vibe, and they don't plan to come back to "older, caveman style of development".
Some universities are also adding fuel to the fire: They "prepare students for the job", not teaching the science, but the parts that corporations need for the job only.
Though, hardware was cheap and people were expensive, and now code is cheap and hardware is expensive now. We'll see.
The point I was trying to make was not "enjoying the process for the sake of it", but paying attention and spending effort on the journey created better software at the end.
When you look at older software, most of it was higher quality than the things we have today. A web site contained more information in a more readable way, more features in a smaller footprint. Same for native applications.
Now we slap what we found online together and calling it done. Everything is sparse, takes ages to load, centuries to submit and everything is so disconnected and async that some simple features are straight out impossible.
This is what fixating on the destination brought us. I dare you to download something you purchased 3 months ago via a 4096 character S3 link they have sent you, and double dare you to ask customer support for a new link. I'll bet that with a 80% chance they have no way to verify your serial number, even.
Have people completely forgotten how to read? I'm saying your analogy between software and math is completely, irreconcilably flawed. I don't need to read the rest of your screed because this is a thread about math not software.
Somebody said that lowering the bar is not good. Somebody else asked for examples, and I provided an example. So, if you want to be pedantic, that doesn't track well, because what I answered was not about mathematics.
If you want something about mathematics, computation is mathematics, as software is. So, my example tracks the same way in mathematics.
Finding solutions without understanding its parts or the path is equally detrimental to mathematics as it is detrimental to software.
Maybe you need to read a bit slower and think along the way. Using AI too much blunts critical thinking skills in some, as I read.
What was the end of the proof thing you mathematicians use, was it "Q.E.D."?
> computation is mathematics, as software is. So, my example tracks the same way in mathematics.
brother i already addressed this literally in my first response to you: the reason software went to shit is because it became commodified (ie a thing produced in a factory) not because it's computational nor because the bar got lowered. seriously read my whole original reply again and see whether you really disagree before just re-asserting your rant on SWE.
> Finding solutions without understanding its parts or the path
you didn't read the post at all did you? it's emphatically about deep understanding over blind results.
> Using AI too much blunts critical thinking skills in some, as I read.
Are you arguing that all the metal we have in our cars, buildings, airplanes is still being forged by hand? That that the furniture people are buying off Amazon is handmade? That stonework isn't primarily done these days with concrete pours?
>(which is that people who enjoy math will continue to be able to).
You posited that code is not like art, because it's primarily written for money and not for pleasure. But that's a stupid fucking argument, because there are plenty of crafts out there that are both done for money and pleasure (often by the same people!).
Half of modern academia, for one. Universities have turned into degree mills with the expectation that >50% of the population requires a college degree, regardless of whether they actually have any interest or need for one beyond doing it because it's a prerequisite for a good career, independent of whether said career actually uses the knowledge in any way.
Not that I actually agree that math was at the right level of gatekeeping. It definitely feels intentionally opaque beyond reason, and I think it's why LLMs are able to cut through the obfuscation and solve problems that maybe wouldn't actually have been considered quite so hard if mathematicians did a better job of making their work accessible.
I really do hate to pile on with negative comments, but there are several at best misunderstandings and at worst errors in this:
1. TFA argues that malloc is for dynamic memory allocation and that arrays are for fixed counts. Sort of. In modern C, you can always char someArray[someValue]; what you cannot do is char someArray[someValue] = { '\0' }; making malloc good for the case where you need some initialization, but then you should probably be using calloc or some other call.
2. TFA indicates that top will tell you how much memory your process is using. Uh, sorta kinda maybe not always? Reporting memory utilization is a black art, top was built before current opacity, and this area is never as clear and clean as it seems. I have a tab group called "true memory usage" which consists of a dozen or more pages to remind how many edge cases there are here. hic sunt draconis
3. TFA kinda sorta implies that malloc means a system call and a change to brk, but TFA also mentions that malloc isn't a system call but a libc call: if you have previously called malloc and freed memory, or if your task's space is large enough, malloc might not involve a system call at all and brk/srbk might not be involved, since libc may have satisified your memory request from your existing task space.
It reads like a fine, clear, and correct article, but it isn't, really. Sad to say, because it did read really well.
The asynchronous behaviour raises interesting questions as to whether or not this is a bug or working as intended, and whether or not the io_uring API should offer controls to allow the calling application to decide.
With synchronous intra-machine calls we mostly take it for granted that pending modifications die with the caller.
But with inter-machine communications we mostly take it for granted that the sending machine and its entire local area can disappear and operations it sent will complete.
Of course, there are exceptions, especially when APIs/systems offer atomicity, consistency checks, etc.
But without express design intent, or preferably caller intent, one can argue both sides of the asynchronous intra-machine case and be right.
I guess my thinking isn't so much that this happens as that it happens implicitly.
But rivers have been mathematical for only something less than ~60 years, no? Mandelbrot's paper on the length of the coastline of Albion was in the mid 60s or so, and the math that made rivers mathematical (fractals, chaos theory) came after that (within my lifetime!).
Rivers are mathematical only because we have so improved our mathematics in recent times (when my parents were born, they were random and non-deterministic, mysterious).
The question of code ownership highlighted in some of the comments herein (e.g., "when you build software, you own it... "No, I specifically don’t. My company owns it...") takes me back to a paper I read years ago on password management and extrinsic risk: The basic idea was that employees have no real motivation to maintain password hygiene because they bear little to no risk of password compromise. They are asked both to be productive and to be secure, they are more likely to be sanctioned for productivity problems than security problems, so they sacrifice company security in favour of employment safety.
We've seen commentary along these lines re AI productivity gains Vs code maintenance costs and quality concerns for months/years now, but somehow, for me at least, viewing this through the lens of code ownership (literal ownership, not metaphorical/moral ownership in the 'take pride in your work and do it well, regardless' sense) makes this extrinsic risk all the more clear.
It also makes me think of the estimated billions lost to spreadsheet errors: non-programmers unaware that they were programming creating spreadsheet macros that appeared to do exactly what they wanted, but that in reality only did so most of the time, with edge cases and error handling omitted entirely, leading to significant financial losses for their employers.
In that case, the lack of sanction is far clearer: They were not programmers, they did their best, no one noticed and it wasn't their job to do so, etc.
The case of AI isn't that different, especially since it is just as available to the non-programmer as it is to the cavalier, or to the pressured junior, or to the responsible, take-ownership-and-maintain developer.
AI without governance and program management leads organizations to assume unqualified and unquantified risk with diffused responsibility; outside the small class of take-ownership-and-maintain professional, all risks are extrinsic to individuals so why should they care if it gets the job (mostly) done?
They don't and they won't.
(Reaches for popcorn to watch imminent train wrecks whilst hoping his water supply remains uncompromised.)
Sure, the sun is white, more or less (cf comments re human perception and what "white" really means).
But when did humans first perceive the sun as white? We can only reliably say "sometime on or after 12 April 1961", the day Gagarin went into space. Prior to that, as far as we know, all humans saw the sun as some other colour, most often yellow or red, depending on the time of day.
Since Newton's prism, we had pretty good reason for believing it was likely white, reasons that got stronger in the 19th C with improved theories of optics, the discovery of atomic spectra, etc. I'm curious to know when we confirmed for sure its whiteness, and whether this was before October 1957 (Sputnik) or after Gagarin or somewhere in between.
The direct light from the Sun is yellowish, because the blue light of the sky is subtracted from it.
If the sky is covered with clouds, then the light is white, because the blue sky light is mixed again with the direct Sun light.
If the sky is clear and there is an unobstructed view of it, the light reflected by a white object will be the sum of the light coming from the sky to the object and directly from the Sun to the object, so it will be white. For example this is true for white clouds and white snow.
This, i.e. that the Sun outside the atmosphere is perfectly white, has been understood for a long time, since the 19th century.
Your last paragraph is pretty much what I said. The sun being white is a recent development in human knowledge, and our recent and very good theory was only confirmed empirically very recently indeed.
That's why I love my induction range: all the benefits of gas (near instant heat control and response, even cooking, etc.), none of the asthma or benzene!
I’m lucky we have a proper range hood that vents outside so I feel better about gas. If this is the same paper I read a year or two ago, or related to it, apparently that reduces the “pollution” in the house by like 90% or more. Going off memory though so someone correct me if I’ve got it wrong.
If the hood breaks down or the stove needs to be fully replaced, I will probably flip to induction. I had one in my old apartment and it was great
I have a regular electric cooktop and it sucks, I wish I had induction. The heat control and response is unbelievably slow. It takes too long to heat up, but MUCH longer to cool down. If you overshoot, it's bad. Also, at least for mine, the range is not proportional. Medium heat to high heat is basically no difference.
TFA mentions s/Philosopher/Sorcerer/ in HP, which I confess to having confused me greatly (are Americans THAT ignorant that they are unaware of the concept?) and pleased me, since the Canadian publishing house stuck with en-GB throughout, AFAICT.
As a multilingual Canadian capable of understanding most English and French accents, I'm grateful for those who preserve and persevere with their home patois.
Funnily enough, I had a hard time with Bradley's accent the first time viewing Hot Fuzz but many hours of BritBox and Acorn and a few hours of HarbourCustoms later, no problems at all!
It reminds me of the game localisations of the 90s, where all too often they decided a game was just too Japanese for our small American brains to comprehend
I'm largely unfamiliar with his work, but in reading the article and viewing a few works online, I was struck strongly by the resemblances between his work and that of Alex Colville, 17 years his senior. To say that Hockney "restored the human form to art" and to ignore, to not even mention, Colville, seems hagiographic and willfully ignorant.
I'm in no way asserting that Colville restored the human form to art either, just observing that Hockney was far for alone in using the human form to convey aspects of his meaning.
reply