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.
Low level is easy (2008)
81–90 of 103 posts
Re: Low level is easy (2008)
#82The 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.
It is almost as if writing the low level code required to make a browser run well is hard...
Re: Low level is easy (2008)
#83There 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…
The accounting package is much easier to design if you have the same level of requirements for them. If the goal is to make a toy product then making an accounting package is trivial while a OS is not. If the goal is to make a product that will get a lot of users then making an OS is almost impossible while plenty of people sell accounting packages. Low level is only easier than high level if you don't intend to sell…
Requirements for an accounting system? That’d be hilarious if I wasn’t so traumatized by past experience. Seriously, the tensor product of jurisdictions, clients, strategies, and the various preferences of your rotating bosses—it’s a cascade of requirements that you could never satisfy.
Re: Low level is easy (2008)
#84Earlier quoted context omitted.
The accounting package is much easier to design if you have the same level of requirements for them. If the goal is to make a toy product then making an accounting package is trivial while a OS is not. If the goal is to make a product that will get a lot of users then making an OS is almost impossible while plenty of people sell accounting packages. Low level is only easier than high level if you don't intend to sell…
Requirements for an accounting system? That’d be hilarious if I wasn’t so traumatized by past experience. Seriously, the tensor product of jurisdictions, clients, strategies, and the various preferences of your rotating bosses—it’s a cascade of requirements that you could never satisfy.
Try to write a commercial OS that can compete with IOS, Windows or Linux. I doubt it is much easier, there are so many features people expect from a modern OS.
The point is that when you compete with the best in the world in any area then it will be hard to win. Low level code is only easy when low level code isn't an important part of your product. For example backends to web apps, you don't write any low level code for them. The networking is handled via application server frameworks, the data storage is handled via pre packaged database programs so you don't even have to open a file etc. It isn't low level, it is just high level glue code between different libraries. This works just fine since you aren't trying to compete using low level code, so using off the shelf products without almost any code written by you is fine. But when your product requires you to compete using low level code then it is really hard.
Re: Low level is easy (2008)
#85Earlier quoted context omitted.
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.
Beware the eternal enginedev... many a brave soul have fallen to this trap.
Exactly this. After lots of trial and error I’ve found it easier to build better engines by extracting and abstracting the common elements from my game development process than focusing solely on engine development. Really can’t describe how much my productivity has gone up since I switched my focus by adding constraints to my development process and narrowing my focus to more parochial problems instead of always pondering the general/wider abstractions. It seems that abstractions are the natural consequence of focusing on a narrow and concrete problem, but people instead try to directly jump to the wider abstract space without any bounds or constraints set, and eventually overwhelming themselves.
Re: Low level is easy (2008)
#86This 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.…
Everyone says not to write your own game engine but if you don't know another one it takes about the same amount of time to learn how to use it IMO.
The main justification is when you're working in a team everyone can use the same tools.
Re: Low level is easy (2008)
#87Shh, 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.
Re: Low level is easy (2008)
#88The 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.
It is almost as if writing the low level code required to make a browser run well is hard...
How much of that hardness is necessary, though? Backward compatibility is quite costly.
Re: Low level is easy (2008)
#89There 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…
hahah this is so good. you made my day
Re: Low level is easy (2008)
#90There 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…
Many are the sects who pursue the Way, and countless their contradictions! Those who write accounting apps, in contrast, are just hella boned by uninteresting complexity.
In my experience OS kernels just make more sense than most front-end code, regardless of the kernel design. There may be different plans for each kernel, but there is a plan. Major things change less frequently, changes are better thought-through, and people think more about what they're doing. Probably this makes economic sense, and the costs of kernel breakage are that much more than the costs of a broken UI, but definitely the kernel's design is easier to make -- because it has a design, rather than ever-shifting chaos.