Live data from Hacker News

Low level is easy (2008)

yosefk.com

41–50 of 103 posts

Re: Low level is easy (2008)

#41
I wonder how much of this is due to the fact that the programming education today comes from a top-down approach, where one starts with a high-level language with little knowledge of the underlying system or the layers of abstraction on top of which it runs. Your upper year courses is where you begin learning more about operating systems, computer architecture, and the like.

Naturally, those programmers become focused on the high-level content because that's what they're brought up with/am comfortable with.

It would be interesting to see courses being taught from a bottom-up approach, maybe not at the gate/transistor level but rather at the assembly level. Teach the basic instructions, move on to C, then move on the high level languages - I actually learned programming this way and found that it helped a lot in understanding why and how things happen the way they do.

Re: Low level is easy (2008)

#42
post #2

I have known this for many years but found it difficult to explain to others. Backends are so much easier to build compared to frontends, and I mean decent and reliable ones. The attitude of the backend people of looking down upon frontend people is really stupid and unsubstantiated. Though scalable backends are increasingly getting their own layers of complexity these days, but still, on the backend you will never d…

>The attitude of the backend people of looking down upon frontend people is really stupid and unsubstantiated.

I think the high horse is because frontend dev is hard. The backend has more methodical tooling. Javascript is not considered a clean language even if it has improved.

It would be nice if you could use clean modern tools but the web is forced to support legacy browsers so it is what it is.

I personally like the full stack and don't look down in either direction, but I understand the sentiment.

Re: Low level is easy (2008)

#43
post #26

Earlier quoted context omitted.

> Backends are so much easier to build compared to frontends, and I mean decent and reliable ones. Evidence would suggest otherwise. I can build a decent and reliable frontend with a no code solution. That's not to say frontend is "easy", just that trying to say which is harder is ridiculous. They're different. I personally don't like working on frontends because it feels like getting on a hamster wheel that spins fa…

A backend can just say ‘no’ if it gets a number in a format it doesn’t like. If a user enters a number incorrectly on a frontend, a frontend can’t just say no. It might have to try its best to parse the number, or if it can’t, the error has to be presented in a user friendly way. A frontend can’t just throw an exception and say Bad Request.

> If a user enters a number incorrectly on a frontend, a frontend can’t just say no.

Followed by the distant sound of enterprise, banking, and government frontend devs laughing.

Re: Low level is easy (2008)

#44
post #22
post #9

Earlier quoted context omitted.

>, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design." I think I understand the intuition behind that... in other words... coding an os kernel seems to have less entropy, less degrees-of-freedom, less subjectivity ... than frontend programming like paint…

TempleOS is the one pure operating system created without any debates. RIP Terry A. Davis.

The only OS endorsed by the Holy C.

Re: Low level is easy (2008)

#45
post #6

I used to be naive and think frontend was just pushing pixels around and messing with html. Now that I like to think I know better. I think people generally perceive low-level/backend work as more objective, scientific, and rigorous.

Currently learning embedded development. There’s a kind of precision needed in this space that wasn’t important in higher level mostly frontend work. I need to know that the loop executed exactly twice since the last update, or whatever. But there’s also a ton of stuff I don’t need to worry about. Input sanitization, animation curves, view layering, network request invalidation, stuff like that. I think the premise is wrong. There is no easy or hard domain. It’s all about the specific thing you’re doing within that domain

Re: Low level is easy (2008)

#46
post #9
post #5

There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?" "An operating system," replied the programmer. The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said. "Not so," said the programmer, "When…

>, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design." I think I understand the intuition behind that... in other words... coding an os kernel seems to have less entropy, less degrees-of-freedom, less subjectivity ... than frontend programming like paint…

Perhaps another way to describe this intuition is that with operating systems, the developer is also the subject matter expert and the one setting the requirements. When you are the one setting requirements, those requirements are going to seem inherently less arbitrary than requirements set by someone else.

Re: Low level is easy (2008)

#47
post #26

Earlier quoted context omitted.

> Backends are so much easier to build compared to frontends, and I mean decent and reliable ones. Evidence would suggest otherwise. I can build a decent and reliable frontend with a no code solution. That's not to say frontend is "easy", just that trying to say which is harder is ridiculous. They're different. I personally don't like working on frontends because it feels like getting on a hamster wheel that spins fa…

A backend can just say ‘no’ if it gets a number in a format it doesn’t like. If a user enters a number incorrectly on a frontend, a frontend can’t just say no. It might have to try its best to parse the number, or if it can’t, the error has to be presented in a user friendly way. A frontend can’t just throw an exception and say Bad Request.

I disagree. Have you ever worked in finance? Inconsistent or unexpected number/date formats have to be dealt with. And to add to it, the formats can be binary and not just text that you can look at it and sort of "figure it out". Often times these files are coming from other large institutions and getting them to fix their data takes days if ever. In the mean time there is daily processing that has to get done in order to trade at the next day's opening.

A system can't just reject data it doesn't like.

Re: Low level is easy (2008)

#48
post #2

I have known this for many years but found it difficult to explain to others. Backends are so much easier to build compared to frontends, and I mean decent and reliable ones. The attitude of the backend people of looking down upon frontend people is really stupid and unsubstantiated. Though scalable backends are increasingly getting their own layers of complexity these days, but still, on the backend you will never d…

A backend dev may argue that the frontend is complicated _unnecessarily_. You don't need your bloated, complicated frameworks. In most cases, website would be better for the end user if you stopped trying to over-design the frontend.

Frontend is hard so we use lots of frameworks which makes frontend hard so we use some more frameworks.....

Re: Low level is easy (2008)

#49
post #25

Earlier quoted context omitted.

Someone else has already mentioned in this thread that backends only ever interact with other programs, not humans. This fact alone makes it easier to design, implement and scale. And like I said elsewhere it is in fact so much easier that a backend can be built to be 100% correct and bug free, while for any more or less interesting and useful frontend it is practically impossible to achieve.

That's nonsensical. User input is passed to backends all the time, and results in just as many difficulties there. From SQL injection and other "untrusted input" problems, to dealing with migrating five years worth of user data to a new system because the old backend can't keep up, to trying to keep every piece of data in a consistent state. Look at CAP theorem: it literally says "you can't have a perfect system here…

I think the CAP theorem is a bit overstated. It’s not, “You can’t have a perfect system,” but “You can’t have a system which is both available and consistent during a network partition.” True, and interesting, and useful to know, but if “100% available” is in your requirements to begin with, you are doomed to fail and the CAP theorem is just more nails in the coffin.

To me, the “you can’t have a perfect system” is really just, “You can’t have 100% availability, and you can’t have 100% durability either.” The hard part is then convincing the users of your system that even though your system seems perfect, they should be prepared for it to fail.

IMO the backend API solution is somewhat easy. 503 Service Unavailable. Then the front-end needs to somehow present a meaningful error message to the user, with a plan for how the user can accomplish their desired action or at least save their state and try continuing later… which can get insanely complicated…

Re: Low level is easy (2008)

#50
I guess I'm just an idiot ¯\_(ツ)_/¯

I guess let's define what "low-level" is because I see a lot of abstractions in low level stuff. A couple years ago I had a sudden interest in the x86 platform. That entire architecture just seems like a piling of new abstractions on top of legacy stuff. And the hardware platform it typically runs on seems impossible to understand without being an insider. I remember trying to fully understand the entire UEFI boot process, and all the stuff below it and other modern components. The docs we're horrendous, and at times seemed non-existent for a lot of stuff and it was just too much information to try to take in.

I don't think I'll ever come around on the tooling. C is just a bit too barebones for me and I'm not fond of the "portable assembler" aspect of a lot of behavior being offloaded tot eh platform, which I now have to know in depth. I can read it, and write a little bit, but I don' think I could ever become good at it or enjoy it. C++ seems immeasurably complicated and i recall reading the phrase "I've been learning C++ for 10 years" the other day. There are some languages I don't mind as much. I like Ada, but no one uses it anymore. I'm working on what I suppose you could consider some systems software at the moment, and have resorted to using higher level languages that provide features or abstractions that provide exactly what I need (notably Erlang bitstrings) and only dropping to C when I need it.

I've tried other things too: driver development on both Windows, Linux, and BSDs (when the docs are decent, this is the thing I've tried that makes the most sense), FPGA stuff (For some reason, I can never wrap my head around digital logic, It makes sense at a very abstract level, but combing components into useful designs is just so foreign to me)

Post reply on HN