Live data from Hacker News

Low level is easy (2008)

yosefk.com

91–100 of 103 posts

Re: Low level is easy (2008)

#91

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.…

Yes! I coded many games with Flash/AS3, which is regarded as low level these days, but it actually had a lot of abstraction over the rendering. For years I would battle with the opinions of the framework, usually attempting to smooth over it with my own even higher level framework.

It wasn't until I start coding directly with HTML canvas that I was finally able to produce code and workflows without the battle. I don't understand why pushing and popping to transformation stacks isn't the norm, when it is just sooo much cleaner. As soon as an underlying framework introduces an object hierarchy for rendering state, in the form of a display list or scene graph, it takes away so much of your ability to structure game state how it best makes sense. I would even say that ECS (entity, component, system) is often times an attempt to smooth over the opinionated framework problem, but it isn't all that great compared to plain and simple data structures for your game state.

I wish more people were using rendering libraries such as Kha (http://kha.tech/), building tooling on that sort of tech, and making those lower levels more robust and portable.

Re: Low level is easy (2008)

#92
post #70

Earlier quoted context omitted.

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 momen…

Genuinely interested, do you have some pointers about what you mean by NT-style IO? How would you characterize it?

I was referring to the "David Cutler (designer of VMS & Windows NT) criticizing UNIX i/o architecture" comment above, which apparently refers to Dave Cutler's criticism of Unix as "Get a byte, get a byte, get a byte byte byte", which seems to me to refer to the Unix/Linux style of programming (in which programmers overuse things like getch() and putchar()). Whew.

But. There's another, much bigger difference between Unix and VAX/VMS/WinNT: The way I/O operations are handled in the kernel itself. In Unix systems, the kernel just passes I/O operations directly to the driver code, which immediately tries to do the operations on hardware. It's a very microcontroller-ish view of the world. WinNT treats I/O operations as sort of a "packet" which encodes the operation to be performed. That packet passes down through the layers of the kernel, including 3rd party modules and eventually drivers, until the operation is performed on hardware. Then, another packet percolates back up the stack to your app with the result.

Things like antivirus, dropbox, etc. can insert themselves into the stack and intercept/modify/reroute I/O operations and results globally.

I think that Linux probably has something like this, or you can probably cobble it together by using async I/O, io_uring, and/or eBPF.

Re: Low level is easy (2008)

#93

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.…

You might enjoy raylib, a library for videogame programming. https://www.raylib.com/

This looks look great, thanks for sharing.

Re: Low level is easy (2008)

#94
post #17

Earlier quoted context omitted.

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 mean…

>Give me an app, mobile or web, and I'll find a glitch or two in the first few minutes of using it I find that a very strong claim, is it rhetorical or meant literally? If the latter, what can you find in (say) whatsapp* ? (*: aside from messages delaying or appearing out-of-write-order, which are probably backend bugs inevitably arising from its distributed nature)

I deleted WhatsApp a while ago so can't say right now. It is a pretty mature app that hasn't added big features in years I think, so I wouldn't expect a lot of bugs in it, but take a look at their version history on App Store, there are plenty of purely bug fix releases only this year.

Re: Low level is easy (2008)

#95
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…

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 momen…

A consequence of AT&T originally not being allowed to sell UNIX and the existence of the Annotated UNIX book.

Without it, UNIX would have been as esoteric as anything else and most likely would have died instead of sprung multiple clones.

Re: Low level is easy (2008)

#96

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 abstracte…

I feel your pain. I recommend reading the absolutely wonderful book "Crafting Interpreters" by Bob Nystrom. For me, it demystified a lot of what you mentioned.

Re: Low level is easy (2008)

#97

The last few months I have developed a web app. The shit you have to go through to make basic stuff work is insane. I would get depressed if this was my full time job. How browser can be one of the most important technologies and still suck so hard is truly mind boggling.

> The shit you have to go through to make basic stuff work is insane.

Isn't that always the case when you are jumping on a new area?

Re: Low level is easy (2008)

#98
post #70

Earlier quoted context omitted.

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 momen…

Genuinely interested, do you have some pointers about what you mean by NT-style IO? How would you characterize it?

[deleted]

Re: Low level is easy (2008)

#99
post #87
post #77

Shh, don’t tell people this - we’re trying to keep the other programmers out. ;) In all seriousness embedded feels like the last safe place for a programmer like me, who grew up in the [redacted ancient decade] and has watched with befuddlement the tumescent froth of abstractions in other programming disciplines. I just can’t do web programming, for example. I did for many years but it broke my spirit and made me rea…

Any tips for starting in embedded? I don't necessarily want to switch paths, just tinker with something at home. But something realistic that a modern embedded engineer would work on, not say making a light blink with an Arduino.

My first stab at prototyping was with an STM32 discovery kit, a couple of breadboards, and a bag of random parts. The best advice I can you give you though is start with an idea. Do you want to do sensing, audio, LED art, a tiny game console, a robot? That’ll determine the kinds of hardware you should get and will direct your learning. I can also recommend Making Embedded Systems by Elecia White.

Re: Low level is easy (2008)

#100
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…

> Backends are so much easier to build compared to frontends, and I mean decent and reliable ones.

Backend:

- running a migration on a table of 100 million rows... in MySQL 5.6. Well, things can get complicated.

- building the infrastructure and monitoring of a k8s cluster

- debugging concurrency bugs

I think these topics are not really easier than their frontend counterparts. I do believe some aspects of frontend development are harder than some of backend development (and the other way around). I do not think, in general, that "backends are so much easier to build compared to frontends" though.

Post reply on HN