[HN Gopher] Low level is easy (2008)
___________________________________________________________________
Low level is easy (2008)
Author : yagizdegirmenci
Score : 120 points
Date : 2021-07-29 12:44 UTC (10 hours ago)
(HTM) web link (yosefk.com)
(TXT) w3m dump (yosefk.com)
| dang wrote:
| It has been easy over the years:
|
| _Low-level is easy (2008)_ -
| https://news.ycombinator.com/item?id=20568736 - July 2019 (26
| comments)
|
| _Low-level is easy_ -
| https://news.ycombinator.com/item?id=7538150 - April 2014 (56
| comments)
| the_only_law wrote:
| I guess I'm just an idiot -\\_(tsu)_/-
|
| 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)
| nathell wrote:
| 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 designing an accounting
| package, the programmer operates as a mediator between people
| having different ideas: how it must operate, how its reports must
| appear, and how it must conform to the tax laws. By contrast, 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."
|
| The warlord of Wu nodded and smiled. "That is all good and well,
| but which is easier to debug?"
|
| The programmer made no reply.
|
| - The Tao of Programming, 3.3
| jasode wrote:
| _> , 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 painting GUI pixels and Javascript-framework-
| of-the-month.
|
| But there's a lot of subjectivity and philosophical debates
| about low-level os design:
|
| - the famous "Worse is Better" essay tries to explain
| difference between "New Jersey approach" (Bell Labs UNIX) vs
| MIT approach of error handling in a system routine [1]
|
| - famous debate between Linus Torvalds and Andrew S. Tanenbaum
| about microkernels vs monolithic kernels [2]
|
| - David Cutler (designer of VMS & Windows NT) criticizing UNIX
| i/o architecture[3]
|
| - even lower level than o/s is cpu design where some criticize
| RISC-V not having arithmetic overflow traps in the minimum base
| specification. And in the 1990s, the RISC (MIPS philosophy) vs
| CISC (Intel philosophy) was a big debate.
|
| [1] https://dreamsongs.com/RiseOfWorseIsBetter.html
|
| [2]
| https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...
|
| [3]
| https://retrocomputing.stackexchange.com/questions/14150/how...
| pdpi wrote:
| > 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 painting GUI pixels and Javascript-
| framework-of-the-month.
|
| I don't think that's the right takeaway. A decade ago I
| worked as an SAP consultant, and did some payroll projects in
| it. The display part of it was easy. All they wanted was a
| great big table display, the moral equivalent of a read-only
| Excel spreadsheet. No faffing about with CSS or Javascript or
| whatever.
|
| No, the real complexity was the freaking business logic.
| Office workers, executives, contractors all had different
| rules for how their pay was calculated, there were all sorts
| of line items that applied to different classes of employee
| differently. The company had spent years building those
| reports by hand and there was a whole lot of organisational
| knowledge hidden in their heads, corner cases and exceptions
| all over the place. The sort of thing you can navigate in
| your head relatively easily if you've been doing it for years
| on end, but a newcomer has no chance of understanding - so a
| lot of iteration was involved in getting where we needed to
| be.
|
| Put fiddly business logic and rapid iteration together, and
| you're burying yourself under a massive pile of spaghetti
| code in no time, flat. Trying to keep all of that sane both
| for myself and for whomever came after me was challenging in
| ways that none of the more systems-y work I've done since has
| ever replicated.
| cgh wrote:
| Yes. This is why the much-maligned (around here) category
| of "enterprise software" is so hard and why the results are
| often kind of shitty.
| lliamander wrote:
| 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.
| ekster wrote:
| Exactly, working at a low level still means that "the
| programmer operates as a mediator between people having
| different ideas". The different people are just hardware
| builders instead of library writers.
| phendrenad2 wrote:
| But I think that even with all of that, writing an OS is
| still much easier than an accounting package. The way forward
| is paved smooth by hundreds that have gone before. And by
| that I mean, hundreds of Unix clones have been made and open-
| sourced. Things like microkernels and NT-style I/O
| architecture are esoteric things that you only see in the
| embedded world (which Google seems to be limiting Fuchsia to
| at the moment) and enterprise-oriented operating systems
| (like Windows, which home users only use out of a weird quirk
| of history).
| makapuf wrote:
| Genuinely interested, do you have some pointers about what
| you mean by NT-style IO? How would you characterize it?
| wincy wrote:
| TempleOS is the one pure operating system created without any
| debates. RIP Terry A. Davis.
| andai wrote:
| You mean, Terry won all of the debates ;)
| TchoBeer wrote:
| The only OS endorsed by the Holy C.
| yup00 wrote:
| Exactly.
|
| Dig around in C land and you'll find 100s of opinions, even
| more libs and toolkits that came and went out of fashion.
|
| Web stacks are "computing" to industry right now. In the 80s
| and 90s it was OS and database.
|
| If low-level had the old economic attention, we'd see the
| same activity and mess as we did in the 80s and 90s. Everyone
| has a compiler to tell you about, and a build system DSL
| that's just right for your problem!
|
| But big corp largely controls that and so a new layer of
| abstraction was added via web, and we're seeing a shift now
| to less UI, and machine driven decision making that just
| gives us the next step in the recipe.
|
| Frankly I don't mind technology for navigating human society;
| buying stuff and literal navigation.
|
| I still unplug with musical instruments and the forest.
|
| The addictive applications we've built in technology; games,
| social and multimedia, got really banal for me a long time
| ago. If I hear things like "Itsa me, Mario" or something
| about Halo I recoil at the cringe.
|
| I guess I don't want my psychedelic noise wrapped up in
| branding and consumerism.
| ibeckermayer wrote:
| That seems pretty dumb. There aren't competing ideas about how
| an operating system should work?
| yosefk wrote:
| BTW it's not obvious that an OS is harder to debug.
|
| A logical error in an accounting package can probably often
| only be found by a checking tool that has the equivalent of all
| the functionality of the package under test.
|
| OS bugs are more likely to have the side effect of violating
| language invariants (which eg KASan, UBSan and KCSan often
| detect), or violating protocols (so you can stress-test eg a
| TCP implementation and detect the bug), or it can violate API
| invariants (so you can use some API-level stress test like
| stress-ng to detect the bug.)
|
| All of these tools are much less complex than the software
| under test. I think the warlord of Wu made the comment about
| debugging before massive automated testing, compiler
| instrumentation etc were a thing.
|
| And I think a similar argument can be made wrt software and
| hardware-level visibility/tracing mechanisms - again an OS will
| end up being easier than higher-level software given a good
| investment in tooling.
| allo37 wrote:
| I recently switched from being a more general "software" dev to
| an embedded systems dev. Despite the fact that I'm using mostly
| C, I find everything much easier in general.
|
| There are so many less layers of abstraction and "magic" to dig
| through that at I can always figure out what's going on easily
| enough. I think this article hits the nail on the head.
| reidjs wrote:
| 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.
| kennywinker wrote:
| 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
| digitallyfree wrote:
| 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.
| planet-and-halo wrote:
| It's been plugged a bunch of times on HN, but "The Elements of
| Computing Systems" really helped me with this as a self-taught
| dev.
| markus_zhang wrote:
| Staying as far from business as possible while still keep a thin
| line of contact with it, IMHO is the best way to live a
| programmer's life. Even when programming low-level systems such
| as Operating System or Compilers one still keeps a thin line of
| though of real world business through communicating with your
| users.
| armchairhacker wrote:
| This applies so much do gamedev.
|
| I've tried Unity, Unreal, and Godot. But I've never been able to
| produce anything, because there's just so much to learn. Rigging,
| particle systems, AI pathing, etc. And so much weird bugs and
| workarounds. Unity in particular sometimes seems like it was
| hacked together, and there's always multiple ways to do
| everything (DOTS, UI, animation), the broken "beta" way and the
| "legacy" way.
|
| In contrast, I write my own engine, and even though I have to
| make everything it's so much easier. All I need to know is
| graphics and code. My game engines are much more intuitive to me
| because I wrote them. And no workarounds, because if the engine
| has a bug, I can fix it at the source. Of course, this means I
| end up making smaller games and it's harder to collaborate with
| others. But it's better than no games at all.
|
| With the like 20+ different game engines out there I know I'm not
| alone.
| ekster wrote:
| A good way to learn game engines is to build a series of games
| that only require you to learn a few new things with each
| iteration. The same way you wouldn't roll your own game engine
| that has all the features of Godot on your first try.
| makeworld wrote:
| You might enjoy raylib, a library for videogame programming.
|
| https://www.raylib.com/
| reidjs wrote:
| Do you actually finish the games? I've tried the DIY game
| engine approach before, but I never have finished a substantial
| game before because I get caught up in the weeds.
| andai wrote:
| Beware the eternal enginedev... many a brave soul have fallen
| to this trap.
| matheusmoreira wrote:
| Developing the engine is so much more fun though.
| fermentation wrote:
| I think this is why developing emulators is fun. Once
| you're done, the games have already been made for you!
| bitwize wrote:
| The way out is to focus on the game. Only build up the
| engine to the point the game needs it to be built. The bulk
| of your focus should be on game logic, even when you take
| writing the engine into account.
|
| Granted, I haven't finished my game this way, but the
| engine isn't really the bottleneck. It's deciding on, and
| implementing, appropriate behaviors, often for silly,
| fiddly corner cases.
| armchairhacker wrote:
| Sort of :). Most of the games are "technically" playable, but
| not quite ready for distribution (buggy, missing settings),
| and I've never published.
|
| The main issue is that I make most of the game, then realize
| that it's really unbalanced and the controls are clunky and
| it isn't that fun. So i lose interest. Probably related, I
| don't really enjoy video games anymore because I get bored
| too easily.
| wly_cdgr wrote:
| Sounds like you've finished tons of games. The games just
| happen to be sandbox gamedev games - i.e., the engines
| themselves. Release the engines!
|
| Also, you could just go work as an engine programmer in AAA
| or for Unity/Unreal/etc....
| dllthomas wrote:
| > if the engine has a bug, I can fix it at the source
|
| While this is probably going to be easier in something you
| wrote, note that it's possible in both Godot (F/LOSS) and
| Unreal (despite being proprietary they give you access to the
| source for free when you sign up).
| armchairhacker wrote:
| Yeah it's definitely possible but a lot harder. Working on my
| own code is easier than someone else's code. Of course they
| would say the same.
|
| Collaboration is a really important skill that i work hard to
| improve. Just not when making video games.
| smasher164 wrote:
| Anyone who becomes sufficiently experienced in a domain will
| inevitably learn and take advantage of their underlying
| platform's characteristics.
|
| A web developer who wants an app to load and render quickly will
| take advantage of the browser's characteristics. For example,
| loading compressed assets in the right order to get a short time-
| to-first-paint, updating styles without reflowing the page, using
| requestAnimationFrame to render animations at a consistent frame
| rate and play nicely with the event loop, etc.
|
| Likewise, a systems programmer ends up learning the quirks of
| their OS and hardware. For example, loop tiling to take advantage
| of cache locality, reducing data dependencies to reduce pipeline
| hazards, using splice() to copy data on Linux to avoid context
| switching, etc.
|
| It's all _just_ programming. Even if the distance from hardware
| is different, the concepts are consistent. Historically, hardware
| has been under-documented, which I think led to the community
| glorifying low-level programming. But under-documented and buggy
| platforms are essentially universal nowadays, so I think the low-
| level vs high-level distinction is not very useful.
| romesmoke wrote:
| I took a compiler construction course this year, and successfully
| passed it. We implemented an imperative/functional hybrid, with
| dozens of the implied (the Prof had warned us)
| swearing/cursing/regretting/all-nightering along the way. The
| employed toolchain comprised flex, bison, and LLVM, all wrapped
| with C++ and running on x86_64.
|
| I still don't feel any confidence around user-space code. Lots of
| stuff was abstracted away--especially during the code generation
| part. Before taking this course, I had imagined that _every_
| component of _my_ compiler would be hand-crafted by yours truly.
| Note that I do not expect an undergrad course to demand such
| levels of skill.
|
| The thing I want to say, I guess, is this gut feeling that there
| are projects more appropriate than a compiler to draw your first
| userLand blood. Like a memory allocator, for instance; in my
| opinion, systems programming carries far all-arounder knowledge
| on its shoulders, with knowledge meaning a reliable
| representation of what takes place under the hood of a modern
| computer, in a comfy level of abstraction (program, threads,
| data, memory hierarchy, user, kernel, etc).
|
| I am afraid, however, that I'm just too amateur to actually
| judge, and that I'm projecting a considerable amount of CS-
| revolving insecurities on the above statements. Any help with
| clarifying that is deeply appreciated.
| mojuba wrote:
| 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 deal with frameworks
| with _millions of entry points_. If you don 't believe me, UIKit
| alone exposes I think about half a million public symbols.
|
| Nevertheless, I chose the path of the frontend (specifically
| mobile) because it fascinates me when a lot of people see on
| their screens something that you have built. A lot more than
| building a system that only the internal frontend devs are going
| to appreciate (or not).
| dahfizz wrote:
| 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.....
| tenaciousDaniel wrote:
| Something I've noticed is that when you're building a backend,
| your program only ever interfaces with other programs. You can
| establish a reasonably predictable protocol. But when you build
| a front-end, you're interfacing with the human brain and all
| the messiness that that entails. It's an incredibly difficult
| thing to do well.
| legulere wrote:
| I think the biggest difficulty in front ends is that they are
| statefull. Backends are usually stateless and pass through
| data from a data store or a cache.
| mojuba wrote:
| This is exactly why frontends are orders of magnitudes more
| difficult to build if equal quality standards are applied to
| both back and front ends.
|
| A front end is a state machine that relies on a bunch of
| enormous framework layers. Give me an app, mobile or web, and
| I'll find a glitch or two in the first few minutes of using
| it.
|
| Backends on the other hand, like you said, only ever talk to
| other programs. And that means building a 100% correct and
| bug free backend system is not such a fantastical goal.
| jensensbutton wrote:
| > 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 faster than in any
| other domain. ymmv though.
| mojuba wrote:
| > I can build a decent and reliable frontend with a no code
| solution
|
| Things that can be built that way are not interesting. Of
| course you can just assemble online stores without writing a
| single line of code, but that's not exactly programming. We
| are talking about frontends that have some sort of novelty or
| at least non-standard flows in them.
| jensensbutton wrote:
| The parent made no such distinction. And your comment
| applies to just as much to backends as frontends. If a
| backend is "easy" to make reliable then it's probably not
| very interesting.
| woah wrote:
| Seems like you don't know much about building frontends.
| jensensbutton wrote:
| Sounds like you don't know much about building backends.
| thrashh wrote:
| 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.
| iamricks wrote:
| Or you just send the input to the backend and have the
| backend tell the frontend to tell the user "backend said
| no"
| foo_barrio wrote:
| 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.
| kennywinker wrote:
| > 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.
| valenterry wrote:
| > Backends are so much easier to build compared to frontends,
| and I mean decent and reliable ones.
|
| That's actually true. What makes backends harder (or rather
| slower?) to build though is the longlivety of the data
| involved. Backends that don't deal with data are indeed simpler
| than frontends in my experience.
|
| > The attitude of the backend people of looking down upon
| frontend people
|
| That has nothing to do with the complexity. It comes from the
| fact that frontend is more approachable and also more hip. It
| attracts more "amateurs" or people who don't know what they are
| doing, for one reason or another. The result is that technology
| on the backend-side is more advanced and mature than on the
| frontend side - though that might be a bit subjective and not
| apply to specific areas.
|
| You actually give your own example: "frameworks with millions
| of entry points" and a dozen new ones every year. :) However, I
| think frontend is in the progress of catching up - e.g.
| Javascript is currently replaced with Typescript, which is not
| being looked down upon by backend people, at least not as much.
| vagrantJin wrote:
| > Javascript is currently replaced with Typescript, which is
| not being looked down upon by backend people, at least not as
| much.
|
| For some reason - unbeknownst to God and his prophets, very
| smart, intelligent folk want to use a BMX as farming tool to
| plough and till the soil. Now we aren't going to ask silly
| questions like - why use a bmx when you have a whole barn
| full of tractors.
|
| No.
|
| We are going to ask how to get maximum output from the pedal
| mechanism. How to replace the human with a robot so we plough
| faster and how best to install solar panels for day time
| power source as well as highly specialized lithium ion cells
| made specifically for this purpose, so we can cover more
| ground.
|
| A farmer, who has been farming for his whole life, really
| belived the tractors with billions of man hours in commercial
| farms, trusty, easy to fix and operate with a plethora of
| mechanics to fix and improve them.
|
| But that just gives the farmer a vague existential crisis,
| what really gets him in the dumps is how they get the the
| goods to and from the farm. See he has big lumbering trailers
| and a few modernis rigs. Hes been using them forever, they
| are insured and also have possibly the highest reliability of
| transport. The new farmers merely smirk at the diesel autos.
| They have sonething better, smaller, faster and many of it.
| Quadbikes hooked to trailers. Hundreds and thousands of them.
| Apparently a central computer, bless it, controls and
| _orchestrates_ the many quad bikes. The old farmer feels lost
| and helpless everytime he goes out to harvest. His trusty
| harvester looks impossibly old and slow, steady as she goes.
| No matter that she can haul a few hundred tons a week, it is
| nowhere new sophistacted than the _automated_ quadbikes -
| zipping in and out with their 80kg loads at break neck speed.
| It 's like watching a symphony.
|
| He wonders what they actually grow there. Seeing such
| advanced alien technology ,to him at least, these new farmers
| must be planting something more delicate than rice, yield
| higher than wheat, and sturdier than simple corn. Surely, he
| reasons, his life is all but over.
|
| But is it?
|
| _The FOMO chronicles, Afseyuk, 2020_
| tux3 wrote:
| >If you don't believe me, UIKit alone exposes I think about
| half a million public symbols.
|
| That's interesting, do you have a source for this?
|
| For reference the Qt5 framework only has about 25k publicly
| documented functions and the shared libs expose ~100k symbols.
| mojuba wrote:
| Honestly I don't remember but someone counted all the public
| symbols which included constants too.
| blacktriangle wrote:
| I think that passes the smell test. They're at the same order
| of magnitude and UIKit includes a ton of optional
| functionality that is situationally used where Qt would
| likely pull in a 3rd party lib.
| majormajor wrote:
| The difficulties of backends usually come from one of these
| areas that I don't think you're giving proper credit:
|
| - scale - a frontend shows one user's view at once, a backend
| may need to be updating state for millions of users without
| slowing anyone's experience down. But these sorts of things are
| somewhat different than just "backend code", it's often closely
| tied to infra and data designs, which doesn't necessarily look
| like "backend coding" but is critical to make the rest work.
|
| - business logic complexity - often the backend teams are
| tasked with working with frontend to figure out a simple, user-
| friendly API surface for the app _and also_ to figure out how
| to make that work with the various not-written-down, not-even-
| fully-enumerated business logic permutations and backend-data
| permutations that could be going on. If they do their job
| right, the frontend can show different screens with values from
| the API ready to plug in for a particular scenario without
| having to worry about the combinatorial rules behind the scenes
| that led us to want to show the user THIS screen instead of any
| other one. The difficulty there isn 't a mathematical or "hard"
| one, it's that the product team probably has no idea just how
| gnarly the set of business rules they sketched out actually
| gets. A backend has to support everything the frontend client
| can do today, but often ALSO support a bunch of things the
| public frontend apps don't yet do (whether this is for admin
| tasks, or for future readiness, or what).
|
| I'm not sure I see the significance of the number of symbols in
| UIKit - you usually don't need all of them, I assume, and I
| know that there are some common patterns that get re-used a
| lot. Is it so different from in backend when there are dozens
| of databases you could choose, and a bunch of frameworks for
| each of a bunch of different languages you could choose, but
| for most problems it's not going to make a huge difference?
|
| One thing that often hides the difficulty on backend is that
| the frontend team might be interacting with just one or two
| backend teams that then interact with a different set of teams
| behind them, etc. But the true "backend vs frontend" question
| has to include ALL of those teams, even the ones you don't
| directly interact with, since they're all in the critical path.
|
| "Hard frontend problems are harder than easy backend problems"
| - ok, sure. But that's not a very interesting comparison.
| mojuba wrote:
| 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.
| majormajor wrote:
| 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, you have to choose." That's a backend
| problem with literally no "100% correct and bug free"
| answer!
|
| (With regard to the original article here, your error is
| that you're assuming modern backend software is closer to
| "low level" than "high level" compared to frontend code. It
| really isn't. And in terms of running your code, it's often
| at a HIGHER level than an app running directly on a user's
| device - you're in containers on VMs on someone else's
| hardware in a cloud environment, say.)
| klodolph wrote:
| 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...
| majormajor wrote:
| If your backend is frequently throwing 500 errors and
| "convince the users of your system that this is OK" flies
| with your management, sure, backend is easy!
|
| But that's often not the requirement... 100% available
| isn't the requirement per se either, but "as available as
| possible because outages cost us $XXXX/minute" is. And
| pushing that number up is HARD.
|
| And remember the context of this thread: we have a claim
| here that backend IS easy and that it CAN be "100%
| correct and bug free." Saying this allows for random-ass
| 500 errors whenever stuff is broken is such a huge copout
| as to make that original claim meaningless.
| klodolph wrote:
| > If your backend is frequently throwing 500 errors and
| "convince the users of your system that this is OK" flies
| with your management, sure, backend is easy!
|
| Strawman argument. I think you're responding to something
| I didn't write. The argument is kind of absurd.
|
| > ...but "as available as possible because outages cost
| us $XXXX/minute" is.
|
| "As available as possible" is not a reasonable
| requirement. If this is your requirement, you're in deep
| shit, but for different reasons. The problem is that you
| can generally spend more money to get more uptime. At
| some point, you have to say that the cost of more uptime
| is too dear.
|
| You can do experiments, testing, and simulation to get a
| more quantitative handle on the trade-off between uptime
| and resources spent. If you care that much, that is. But
| "as available as possible" is a bad requirement because
| there's no way to tell if it's satisfied.
|
| What ends up happening is that people unsatisfied with
| uptime can blame you for not having enough uptime, but
| they aren't telling you _how much is enough._ The purpose
| of having a requirement is to record an agreement between
| different teams about "how much uptime is enough uptime".
| It can be the wrong number, and it can be revisited, but
| if it's not a number (with a way to measure it), you
| won't be able to calculate other numbers like "how many
| database replicas do I need?"
|
| > And remember the context of this thread...
|
| I'm responding to the CAP theorem bit. You said that the
| CAP theorem means, "you can't have a perfect system here,
| you have to choose", and I think that this is misstating
| the CAP theorem.
|
| > Saying this allows for random-ass 500 errors whenever
| stuff is broken is such a huge copout as to make that
| original claim meaningless.
|
| 503 errors aren't random. They happen when the backend is
| unavailable. It's not a random "stuff is broken" error--
| that's 500.
|
| This is not a cop-out. Services _will_ sometimes be
| unavailable. The 503 status is the correct way to signal
| this to the front-end. The fact that the back-end returns
| a 5xx series error code does not mean that there is a bug
| in the back-end.
|
| Likewise, if the service is important enough, your front-
| end should be able to respond to a 503 error with some
| kind of reasonable workflow for the user.
| mojuba wrote:
| A lot of the times the part of the backend that renders
| pages and handles user input can be assumed to be part of
| the frontend, I'm not talking about those. I meant
| backend as an API.
|
| I honestly think you've never built a decent sized, non-
| trivial mobile app for example, and you probably have no
| idea how tedious and difficult it is to produce something
| that will be pleasant for the users to deal with.
| majormajor wrote:
| I mean, if you say "parts of the backend are actually the
| frontend"[0] and "parts of the backend area actually the
| infra" and say "backend" is just a CRUD api that talks to
| a database: sure, that can be easy. But I've rarely seen
| backend jobs that don't require touching the 90% of the
| iceberg that's underwater...
|
| So it's a stupid definition. I haven't built a large
| mobile app, _but I 'm not claiming frontend dev is easy._
|
| _You 're_ claiming backend dev is easy but your argument
| so far reduces to "it's easy because the hard parts
| actually aren't part of it" which is tautological and
| pointless. You're not even just claiming it's easy,
| you're claiming it can be built 100% correct and bug
| free.
|
| What's the most complicated backend system you've built?
| What database, what user scale, what traffic scale, what
| technologies, what servers, etc?
|
| [0] the part of the backend that renders pages, if one
| exists, and the part that validates user input should be
| VERY VERY different components, anyway...
| mojuba wrote:
| Hundreds of thousands of daily active users, I built both
| the backend and the mobile app. I think I'm familiar with
| common problems on both sides. Trust me, dealing with UI
| platforms is orders of magnitude more pain in the arse if
| you set the quality standards to the highest. Even the
| codebases were approx. 1 to 20-25.
| jensensbutton wrote:
| Backends also need to design/build for their operators.
| gedy wrote:
| > The attitude of the backend people of looking down upon
| frontend people is really stupid and unsubstantiated.
|
| Agreed, personally when I've heard this, it's frequently due to
| the "backend" devs really struggling with the complexity of
| user interface needs, especially UI state. This is the root of
| a lot the "JavaScript is such a trainwreck" type comments too.
| jayd16 wrote:
| >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.
| spdionis wrote:
| I don't think backend people deny frontend is hard. The
| problem is frontend is hard for all the boring reasons.
| api wrote:
| The most annoying thing about frontend is the shifting sands.
| Not only is it complex but APIs, browsers / windowing systems,
| OSes, and UI/UX fads are constantly shifting. You often have to
| rewrite the damn thing every few years or it looks "old," and
| when people see apps that look "old" they assume they're not
| maintained or are of low quality.
___________________________________________________________________
(page generated 2021-07-29 23:01 UTC)