Isn’t that why the bell is for?
6,688 karma · joined April 24, 2019
It’s often hidden behind the syntax and implementation because of the layers of abstraction. A single operation (semantic wise) may be scattered over many statements, and some definition may be important in several subconcepts. It helps to be familiar with various technical concepts as possible. basic data structures like lists and trees, more advanced concepts like scheduling and concurrency, as well as platform concepts like files, process, networking,…
Why? Because they are implementation details that distract from the main conceptual model. It’s like how OpenBSD handle device discovery and configuration. Once you know that it’s a tree, you just need to remember how you build a tree and then most of the code are obvious. You can then discern the traversal stuff from the actual device configuration easily and know how to focus your reading.
Taking a problem or a wanted behavior and dissecting it down to logical manipulation is hard for those people. They can go down one or two layers but then they got lost while building the necessary abstraction. You can observe it pretty much in real time as they’re losing track of assumptions for the current context. Thinking that way is a skill and once you can do it, reading and writing code is pretty much effortless.
Both learning to write and learning to read is merely a proxy of learning to think. Doing one while not doing the other is handicapping yourself for no reason.
How many cathedral does the world needs? And even if you wanted to build a new one, it’s no longer the middle age. No one is inventing UNIX all over again. Lots of hurdles have been solved. The difficulty of software is not technical or implementation related, it’s mostly about defining the problem.
It can be done, but it’s not where the hype and the practice is. It’s all about number of commits, number of PR, churns in LoC, which has no bearing on software quality and usefulness.
Something like caddy[0] is just 2700+ commits over 7 years. That’s like 32 commits a month in average. Even if you apply an exponential decay (going from greenfield to mature project), the latter years would have been way peaceful. I know AI can help in some cases, but is it such a pressing need. That would been like taking a car to go somewhere less than 10m away.
Most (mature) open source projects progress a few changes at a time. Most of the time is about ensuring that nothing breaks due to the change.
> https://en.wikipedia.org/wiki/Ansatz
After an ansatz, which constitutes nothing more than an assumption, has been established, the equations are solved more precisely for the general function of interest, which then constitutes a confirmation of the assumption. In essence, an ansatz makes assumptions about the form of the solution to a problem so as to make the solution easier to find
Most models have relation to each other so it does not suffice to take one in isolation. It's one continuous world (in our knowledge) so almost everything relates to one other. The truthiness of something is not whether it fits some particular phenomena, but how does it generalize.
People that do think of using LLMs to accelerate 2 usually don’t think enough about 1. And from what I’ve seen, they quickly get tired of 3.
Most quality software I’ve seen usually starts from a small subset for the cycle and then incrementally add to it. LLM projects usually rush the building part and do too big of a job and it’s become cumbersome to design (sunken cost) and evaluate (too many variables). If you want to build shelters, you start with a small hut, not with a cathedral.
I don't think so unless you're talking about raw assembly. Even with C, you got structs (clump of data) and functions (which give us nice abstractions over pieces of logi) as well as syntactic sugar for branching and looping. OOP is a whole different model of design. And FP has a whole other basis of computation theory (evaluation and reduction from lambda calculus).
It's kinda like drawing in a sense. People think they know what something is and you ask them to draw a chair or a bike and they can't do it. So you ask someone to give you the specs of something like an attendance form, and they can't readily give it. Drafting the specs is the real cost, not implementing it.
> My anecdata is the opposite of yours; the people that feel like the _actually coding_ is the bottleneck tend to be the people that have the _most_ editor fluency, as they are(were?) motivated to remove the bottleneck.
If it were, we wouldn't have a drought of editor models. Vim and Emacs are decades old. Then VSCode is basically the same thing as sublime, kate, notepad++, and the various IDE out there. Coding isn't the bottleneck.
If there's one thing that I learned from AI proponents is that they don't value correctness. They only want to write more code every day. Which actually baffles me, because for a given feature set, there should be a Definition of Done, and the only work left should be slight alterations for oversight and dependency updates.
Unless you're talking about raw typing speed or using an unfamiliar language, I don't think that it is. Most languages have few tokens and syntax rules. The next layer is the symbols from the standard library and the dependencies. After came the conceptual models, which is where the abstract thinking happens (like how does an hashmap works or what writing to a file entails).
Speed at the level of the first two layers can be greatly improved by very basic completion (syntax and symbols), or by just copy pasting. Integration like vim's quickfix or emacs' compilation mode helps because that's where compilation errors happens.
My opinion (anecdotally verified) is that people that feel like coding is a bottleneck have no editor fluency.
If you do this and breaks the assumptions of the interface, it’s just recklessness. You don’t go and tweak functions without fully understanding the rules it established and how those rules are treated as axioms somewhere else.
> But notably compile time static type checking greatly reduces the risks involved
This is usually an excuse to not fully check the assumptions in a given piece of code. Like tbe warnings will be enough to take care of any issues. Type checking is not software correctness. I’ve seen badly defined type, type erasures, and various other issues that negated any value brought by the type system.
Why would you do that? Take common lisps, most of the functions has been standardized for ages. It’s like saying by slightly adjusting the rules of addition, you can break maths.
Something that is going to be used all over the codebase is basically axiomatic and needs to be written and modified carefully.
At least for me, typing code (in a language I know) is as easy as typing English (which is not my native language, but something I’m reasonably fluent in). Thinking in terms of generic computing concepts is equally as easy. Most of my time is spent on not contradicting what has been written before, not on what I need to express. Because the software needs to be coherent.
So the speed of coding is slow, because of all the double checks I need to do. Not because I don’t know which statements to introduce next. And that thinking happens at a meta level (state and its alterations) not at the syntax level.
I was pretty sure that was false. I did a quick check and found
https://develop.kde.org/docs/plasma/scripting/
This pretty much. My last job didn't really have QA so I did the next best thing which is writing a bunch of integration tests for the use cases that matters for the product. They were not an indication for correctness, but more like a canary to warn me if I break something while developing. Bugs reported by consumers usually warn me of area not well covered.
QA would play the same whole. They shouldn't need to check for code correctness, their most useful task is to surface bugs that breaks the product requirements (performance, security, business logic,...). And for that, having knowledge of the implementation is unnecessary. In the above example of writing integration tests, I took care of only using the public interface of the modules.
I wipe the whole thing and installed Fedora.
I could tolerate windows if I needed a particular set of software on it, but no way that I could use it as a daily driver.
Do remember that both the interface (the terminal) and the software environment is under the control of the same user. And terminfo is more of a translation layer than a database, more like the Linux virtual filesystem which hides away the different filesystem implementations. Or ALSA and DRM.
Going back to the issue on the software side, many time, the only check they do is checking if stdout is a file or a tty. If it’s the latter, their output is full of color and spinners, no matter if TERM is explicitly ’dumb’.
Isn’t the terminal info easily modifyable? You can add new entries at both the system and user level.
The only actual issues are capabilities. But just like all protocols, there’s need to be an agreement between the software and the terminal. And gradual degradation if some capability is not there. I have more issue with some software hardcoding escape sequences than with not being able to add new terminal entries.
> One reason is the classic photographer's question: "What is the best camera?" The one you have with you.
I have a Kobo Libra and while it’s bigger than the basic kindle I had (which I could put in my back pocket), it’s still fairly portable. The nicest thing is that I only need to press the power button to get back to what I was reading. Compare to unlocking the phone, open the app, locate the book and then opening it. Without being distracted.
This makes it a pain where you want to have a custom configuration. Like moving the cache to a ramdisk. My NVME disk is plenty fast, but rarely I want my browser cache to persist across a reboot. It's a pain to move the cache to /tmp/firefox-cache as an example (/tmp is a ramdisk on my laptop). Also a pain to backup profiles.
For a tool to be deemed useful, the benefits needs to be generally applicable while the cons needs to be accidental or be reduced enough to not be immediately harmful.