Hacker News Reader

Comment by jdw64 | Hacker News Reader

When I was a college student (15 years ago), I first encountered C through A Book on C, and C seems like a language that is simple but can really do a lot. Looking at how old this language is, and how many concepts already used in modern languages were tried during its development history, is surprising. It's surprising that the concepts I thought were modern techniques today were already being tried decades ago—that is, before I was even born.

It's amazing that a method like the Bump Allocator was already tried.

How were the senior programmers able to do all of this? I'm just amazed.

View on HN

  > How were the senior programmers able to do all of this? I'm just amazed.

I think it has to do with a combination of factors that changed over the years. First of all computer science was viewed more theoretical and less applied at that time. A computer scientist would be interested in optimizing a certain algorithm instead of making an app.

Secondly the systems in that time where less complex meaning it was easier to understand and experiment with fundamental parts of the computer.

Lastly at that time "programming" was closer to the metal so a average computer scientist at that time would likely have more knowledge of the deep internals compared to an average programmer today.

  > C seems like a language that is simple but can really do a lot

I like to borrow a phrase from the realm of gaming: "easy to learn hard to master".

I have always thought about C being a language with "simple" syntax (but things like type declarations are hell), but very complicated semantics.

I think one of the issue in C is that some semantics do not have a syntax, you simply are required to write the code according to it. For example values/objects actually do have a type (effective type) and that is fundamentally what is deciding whether your access is UB. But you never declare that, you simply need to use the right type on access. Or there are ownership semantics in C, every usable interface description describes them in prose. If it's not defined, you are almost guaranteed to invoke UB. That's why I get a bit annoyed if Rust fanboys act like they own the concept of ownership, no it exists in C as well, but C does have different ownership semantics.

The phrase "to own the concept of ownership" is so cool.

The answer is more likely that modern students just don't learn their history and think they've cleverly come up with something new (after all, it's new to them). If you've learned your history you would understand it has ever been thus. Aristotle and Hesiod complained about it, and Aristophanes even wrote a play satirizing it that could be performed today and it would still be relevant.

Why do they go to university then? The entire point of an university is to get taught the fundamentals and be able to derive current (and thus future) knowledge yourself. If you simply want to learn the current state of a craft, that's what vocational schools are for.

University provides you the opportunity to research and understand the history. You don't need university for that, but the time, people, and resources available to you make it much easier.

But it's voluntary. Actually course curricula basically just drop hints at the history as part of a short perfunctory narrative. Along with the deeper conceptual instruction (framed according to the then-current beliefs), that's better than vocational instruction, but definitely falls short of the idealized liberal education. Ideally you survey the entire historical progression of a field, like St John's College does where, e.g., you start learning geometry by reading Pythagoras, or calculus by reading Newton, and then having vigorous discussion to suss how how thinking changed or didn't change between eras and how that might inform today's thinking. Not sure how much marginal benefit is had by going all-in like that, though, as a practical matter, except for very serious students.

Of course there is always a depth below, which to explore is entirely voluntary. But university courses don't train you directly on the layer you are going to solve the actual problems on your job, they test always at least on layer deeper and then maybe test for one specific algorithm/approach/problem as an example.

> you start learning geometry by reading Pythagoras, or calculus by reading Newton

You can do that, if you actually care about the history of mathematics, but normally it's enough if someone introduces you to a combined theory of e.g. Pythagoras and Newton.

So in a way you are saying, university is often not actually teaching temporal genesis, which I agree with, but my point is that it does teach causal genesis, with citations on the temporal aspect.

if you write your program first with pencil and paper u'll be amazed at what you can do yourself.

most people open an ide and start coding, or write some basic diagrams to get an overview/mental model. Back in the day any bitnlarge program would take hours to compile so really u did not want to have any bug or typo just to sit for hours until a compile error or logic mistake. Take it even further back to days before C and that is even more needed.

a lot of high level modern languages seem to alleviate that need, likely so that enterprise software can be written a bit faster because the features need to arrive faster.

still in more modern languages i'd recommend starting with pencil and paper, write most of it if not the whole thing out. u'll find much nicer patterns and will save yourself a bunch of refactoring. even for small programs.

When I was at school, I used to program on paper like this (due to not having a computer during class). It was accidentally a great exercise, that I think everyone should try. Because of it, I find myself writing mostly bug-free code on my first try these days (my bugs tend to happen on interactions between parts of a system I designed separately).

I had the same experience of writing almost no bugs when writing on paper. (Only conceptual bugs, e.g. in architecture or that I solve the wrong problem in the first place.) But when I now write code on a computer, I do introduce bugs. However I regularly find tricky and rare to occur race conditions or heisenbugs just by printing and reading the code from top to bottom, without a goal, just for entertainment. I did not know of the existence of the bug, before I find them. They stick out when you read it, because it's not what you have in your head that should be written there.

It helps me to print it in a different font/color and without syntax highlighting to force my brain to read it as new code, instead of simply assuming it's the same as I already know.

i recognise this. i do pen and paper still but i do also write bugs. when i do i try to make test programs to learn why, and ideally recognise where my pen and paper whent wrong, because those are gaps in my real understanding of how my language, the program or interactions with its environment and platform really work. Needless to say i always find myself having lots to learn still :). i think in reality only once or twice i wrote a program truly free of bugs. relatively trivial programs ofc (simple socket client/server with basic binary protocol or so. easy to reason about, no complex sync or threading requirements).

i never use syntax highlighting. one day someone told me it was very distracting, i turned it off and suddenly things were calm. Maybe its just taste but i do find it helpful. you really read stuff rather than assuming some color happening means its correct or incorrect subconsciously

> It's amazing that a method like the Bump Allocator was already tried.

The old saying "Necessity is the mother of invention" applies. Smart people + system constraints => ingenuity.

They came up with bump allocators because they had a blank mind, devoid of today's complexity. You would also come up with it if you were sat in front of a terminal with no internet. Ask anyone old enough.

Reply on news.ycombinator.com