131–140 of 147 posts
[pedantically: the theory generated by a program and the theory generated by the axiomatisation in the heads of its programmers should be equivalent, but if you only have one it'll be easier to derive the former given the latter than the other way around]
> “Humans learn from examples, not from “core concepts” Nitpicking maybe but I disagree with tfa on this point; not all humans work this way. Those of us who might actually prefer the general -> specific direction are already largely ignored in k12 and may only begin to thrive in higher education. Since we’re already kind of underserved, there’s no need to also deny that we exist!
This also stood out to me as obviously wrong in the article. Since time immemorial, we have taught math by teaching the core concepts and building on them incrementally. Since people do successfully learn how to do math, this directly disproves the author's claim that people don't learn that way.
Math is usually introduced by way of examples (counting apples and such), and it could be that using those more would make more complicated topics more accessible.
https://worrydream.com/refs/Lockhart_2002_-_A_Mathematician'...
From Code Complete: “The smaller part of the job of programming is writing a program so that the computer can read it; the larger part is writing it so that other humans can read it.” (P.733) Has stayed with me for ~20 years.
"Programs are meant to be read by humans and only incidentally for computers to execute." From the preface to the first edition of Structure and Interpretation of Computer Programs by Abelson & Sussman (which predated Code Complete by a decade). It's a maxim I live by although my employers always seem to insist on the computers executing part for some reason.
Bit of a side issue for me: I was working on my Unity game the other day and thought to myself, have IDE's really not progressed all that much in the last 10-20 years? Default intellisense has definitely gotten a lot better, but apart from that and a few other minor things the whole concept of coding feels pretty much the same today as back then. The biggest positive change for me is outside of the editor, it has bec…
I think the reason the text editor experience hasn't improved that much is because it's not often a bottleneck. Thinking and learning are the hardest parts of programming. Typing faster doesn't help that much.
At any given moment, the programmer cares about different aspects of code. One moment, they're trying to correctly structure an abstraction layer; an hour later, they may be debugging an issue that needs them to walk up and down the abstraction ladder several times. One moment, they need to understand the data flow on success path; the other, modify the overall parallelism characteristics of the program.
Cramming all these conflicting requirements and cross-cutting concerns into the same files, to be read and written directly, is what's bottlenecking us. That's why we have never-ending holy wars on what is "clean code", why our editors work on such low conceptual level, why we get languages like Haskell or Rust, packed with cutting-edge math research output. We're hitting a Pareto frontier - trying to make some things more readable and explicit makes other things harder.
The solution is to stop working on code files directly, and let software synthesize views amd editing interfaces - textual and graphical - on demand. Many perspectives on the same underlying artifact, that itself will not need to be optimized for human consumption.
People learn things differently. I really need the "core concept" first, before diving into examples, (unless the core concept is extremely simple). Many tutorials are like hand-holding Lego building. Here's your Lego pieces, watch me and follow me in building this toy project, and you'll know how to Lego at the end of the day. I just don't function very well in this model. I want to know how and why decisions are ma…
I could reproduce solutions, but I never understood them.
Years after I saw a bunch of good practicable examples and I just understood what the concept was about.
After this realization, I refined my learning approach.
1. Fly over the core concepts.
2. Try a bunch of examples until I understand why I would need the concept.
3. Read the core concept thoroughly to eliminate the edge cases that are missing in the naive examples.
Earlier quoted context omitted.
I cannot agree more. I also want to add that I hate these "project generators" such as create-react-app when I'm just getting started. (It's just an example: I'm glad I learned React long before its existence.) They create an opinionated folder structure with template files and preconfigured tools. I don't function well in this model: if I don't immediately have a high-level overview of what the created files do, why…
I absolutely loathe those “frameworks“ with billion files in billion directories. If can't start with single file and build upon it - it is complete trash. Android projects with Gradle come to mind.
1. Create new project.
2. Carefully inspect every file in the project. Remove everything non-essential from every file.
3. Repeat step 2, until things just don't work and find out why they don't work.
After that work is done, you'll be with few files which are somewhat easier to understand than the original state.
On my experience, people who create tools, usually have good built-in defaults, so you can actually delete almost everything.
It’s not.
Earlier quoted context omitted.
I think the reason the text editor experience hasn't improved that much is because it's not often a bottleneck. Thinking and learning are the hardest parts of programming. Typing faster doesn't help that much.
It is, but not directly. The practice of working directly on canonical plaintext representation is what's bottlenecking programming. At any given moment, the programmer cares about different aspects of code. One moment, they're trying to correctly structure an abstraction layer; an hour later, they may be debugging an issue that needs them to walk up and down the abstraction ladder several times. One moment, they nee…
Problem is all such systems has proven to be worse than text on most dimensions.
> “Humans learn from examples, not from “core concepts” Nitpicking maybe but I disagree with tfa on this point; not all humans work this way. Those of us who might actually prefer the general -> specific direction are already largely ignored in k12 and may only begin to thrive in higher education. Since we’re already kind of underserved, there’s no need to also deny that we exist!
Pages of dense text with lots of jargon, like a recent K8s course I've been doing are just something I find utterly useless for learning unless it involves a good amount of accompanying hands-on learning.