> I almost never write code directly (it's always Claude)
Who, then, understands the code? If the answer is "no one really", entropy will overwhelm your codebase sooner or later. Otherwise, you need to read the code, and for that the knowledge of language is still relevant.
> If the answer is "no one really", entropy will overwhelm your codebase sooner or later. Otherwise, you need to read the code
I think about this on the regular -- I know the answer is currently "you own the code, so you have to understand it", but to unlock the true productivity multiplier, in the future, the answer has to be "no one really".
I think about it using the concepts from my job (academia) -- to actually have PhD student-level intelligence means that you have to trust that it does a good enough job that you can focus on other stuff. Professors often bring the correct ideas or intuitions, but they have to trust the PhD student to write the code and/or fill in the gaps in the proofs -- they can advise them on the high-level issues during a consultation, but that's about it.
I am pretty bad at working in the current LLM workflow -- it is tough for me to focus on reading a TCS paper for review, keeping all the details and invariants in my head, but every 5-10 minutes go to my PC, completely switch contexts/projects, read the code and think about the LLM's comments, suggest the next step, and then go back to reading.
I do, with different tools and most of the time at a higher level of abstraction. The same way we understood the machine code 2 years ago, even though we didn't write it directly. Just another layer, nothing more.
I don't think you can really understand assembler without writing it and since compilers are fairly deterministic and get constant attention most of us using them haven't truly had to fight with what turned out to be a compiler bug.
Whereas LLMS regularly produce shit. One can excuse them for not understanding one's turn of phrase or whatever but it amounts to the same problem in the end - you have to understand the output language a lot better than most people ever had to understand assembler.
> Ah fun fact, why do we use the word “right” and “left” but also use the word “right” as correct/lawful and use left as thing that is well, left? A linguist theory says that people always been predominantly right handed, so the way you use tools is the “right” (correct) hand, and the one you don’t, well it’s the hand that is “left”.
It's a bit more varied, even in the Indo-European family. What does tend to happen is that the words for handedness get positive (right) or negative (left) associations in idioms, but additional meanings are not universal. In French, "droit" additionally means right (as human right), but not "correct" (yes it does have a bunch of adjacent meanings). In German, "recht" gets to mean "law" or "justice", shared by some Slavic languages ("pravo") -- but not all of them, which have the word "desno", without any association with rights/justice/correctness. The Latin "dexter" gave us "dexterity" and "dexterous", but also nothing alluding to justice. Et cetera.
As an aside, "left" originating from "left over" sounds like folk ethymology to me. Dictionaries point to "weak" as the original meaning.
Latin languages also have the words sinister, izquierdo (which seems to come from esku-okerr - crooked hand) for left.
The tendency to associate the right with positive and the left with negative is pretty much ubiquitous in Western civilization up until fairly recently.
I have a fairly exotic viewpoint on this. The left/right asymmetry (for the lack of a better term) is a small part of a larger asymmetry that's difficult to explain (at least to my satisfaction): up is better than down, light is better than dark, positive is better than negative, higher human faculties are better than lower desires, right is better than left. In my mind, none of these should inherently have a good/bad association. Is a valley worse than a hill? Is a positive electric charge better than a negative one? But, for some reason we have this cultural, linguistic baggage where what seem like highly abstract objects are rooted in a very basic world of good and bad.
I find this fascinating.
I would go as far as to add the male/female asymmetry to this: seemingly senseless, yet historically present. I'd say the rabbit hole truly starts when you get into Western esotherics and see how they associate right, up, light, male, order, knowledge as if they're different expressions of the same thing, and analogously for left, down, dark, etc.
Makes sense; up gives you a better vantage point, so its easier to see danger. Not to mention that it gives you a fighting advantage; your attacker would have to run uphill to get to you, tiring them out.
> light is better than dark
Humans rely heavily on our sight, and we tend to operate in the daytime. If you were a nocturnal animal, I'm sure you would consider dark to be better than light.
> positive is better than negative
Getting something is better than giving it away.
> I would go as far as to add the male/female asymmetry to this: seemingly senseless, yet historically present
As a native non Indo European language speaker, aware of the many differences to Indo European languages, it is noteworthy that this however is similar in both. Oikea ja vasen, right and left. Oikea ja väärä, right and wrong.
In clothing you have the right side and the reverse side while here it's oikea ja nurja. Again similarities but nurja has this twisted and dark connotation. Or upside down = nurinperin.
> I went to Finland, and there were ships going from Finland to Estonia, carrying people just to buy cheaper alcohol there. They went back to Helsinki with shopping bags full of vodka. Makes you wonder how does it look Tallin in drinking statistics.
They just need to exclude the shops in a 150 m radius from Terminal D in the Tallinn harbor to get accurate statistics, the Finns rarely go beyond that ;)
Secure as defined by a duo of monopolists. It's a contractual concept and doesn't have a firm relation to security-related characteristics. I'd trust GrapheneOS to be as secure as anything Google is capable of releasing, but that doesn't help them if Google refuses to vouch for a device running their OS. Which is also why your check/credit card analogy falls flat.
> Considering the amount of money at stake, Software is a deeply, deeply unserious and careless industry, and a great many practitioners are also deeply unserious and careless people.
What else do you expect, given the economic incentives on one side, and the immaturity of the discipline on the other? Writing robust software requires time, money and competence, in a purely empirical approach, since we have no fundamental theory of software. The pressure is for quantity and features in minimum time. The approaches are incompatible, and economics win every time.
> You must belong to the club of folks who use hashmaps to store 100 objects.
Apparently I belong to the same club -- when I'm writing AWK scripts. (Arrays are hashmaps in a trenchcoat there.) Using hashmaps is not necessarily an indictment you apparently think it is, if the access pattern fits the problem and other constraints are not in play.
> It's amazing how much we've brainwashed folks to focus on algorithms and lose sight of how to actually properly optimize code. Being aware of how your code interacts with cache is incredibly important.
By the time you start worrying about cache locality you have left general algorithmic concerns far behind. Yes, it's important to recognize the problem, but for most programs, most of the time, that kind of problem simply doesn't appear.
It also doesn't pay to be dogmatic about rules, which is probably the core of your complaint, although unstated. You need to know them, and then you need to know when to break them.
Most code most people work on isn't about algorithms at all. The most straightforward algorithm will do. Maybe put some clever data structure somewhere in the core.But for the vast majority of code, there isn't any clear algorithmic improvement, and even if there was, it wouldn't make a difference for the typically small workloads that most pieces of code are processing.
I'll take it back a little bit, because there _is_ in fact a lot of algorithmically inefficient code out there, which slows down everything a lot. But after getting the most obvious algorithmic problems out of the way -- even a log-n algorithm isn't much of an improvement to a linear scan, if n < 1000. It's much more important to get that 100+x speedup by implementing the algorithm in a straightforward and cache friendly way.
My core complaint is that folks repeat best practices without understanding them. It's simple to provide API semantics that appear like a map without resorting to using hashmap. I fear python style development has warped people's perception for the sake of simplifying the lives of developers. And all users end up suffering as a result.
> Why can't the cyclists slow down when they see that there's a human obstacle in front of them?
They usually do. (The considerate and/or non-confrontational ones. There are always idiots, and people have the tendency to remember negative outliers and project their behavior on the group as a whole, which is unfortunate.) However, slowing down isn't the whole story. Riding a non-motorized bicycle is much easier if the rider can keep moving, however slowly, so it would be considerate in turn for the pedestrian to step aside and let the cyclist pass, if possible. A distracted pedestrian can be warned by a bell.
Separately, delivery riders as a category have an incentive to ride as quickly as possible, which is a recipe for conflict. Removing that incentive means removing or completely reimagining the service. I don't think that anybody has a solution or mitigation at present.
Depends. If one is aware of the meaning of section numbers, that "(5)" is very obviously suggesting that there is a file format named "crontab" which is documented. It's also pretty reasonable to suppose that the command and the file format of the same name are related.
A novice might miss the convention and the connection. Man pages are not quite novice material.
Maybe they could update man files so that it lists crontab(file format) instead of crontab(5)? Whenever I've seen numbered man pages in the past, I thought it was just a page number in the manual for the program
Hell, you don't even have to have a handle on what the section numbers mean for these things to be useful. The appearance of something in a "SEE ALSO" section indicates that the manual page author thought that that thing was both related to the thing being documented and worth reading if the current man page didn't answer all of your questions.
I can't count the number of times that following the trail laid out by 'SEE ALSO' sections a step or three has lead me to the exact thing that I never knew I needed to be using. Chasing those sections down is almost always well worth the three to ten minutes spent.
And, like, if one is expecting a man page to cover in detail everything even vaguely related to what it documents, and one doesn't feel one has ten minutes to spend reading things that people thought were important to bring to your attention... well, I guess one could go ask an LLM to slop out some related words. That'll probably take less than ten minutes, though correctness is not at all guaranteed.
Who, then, understands the code? If the answer is "no one really", entropy will overwhelm your codebase sooner or later. Otherwise, you need to read the code, and for that the knowledge of language is still relevant.
reply