Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What should a systems/low-level software engineer know?

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 231 posts

Re: Ask HN: What should a systems/low-level software engineer know?

#91

Post by aswanson »

SamReidHughes wrote: post #75
jstimpfle wrote: post #70

Earlier quoted context omitted.

Programs written in this mindset might be the number one reason why C has a bad reputation. Of course, if you just emulate what other languages automate for you, you should better write in these languages. But in reality, why C is still the best programming language for large projects (IMO) is exactly that the programmer is allowed to choose a suitable structure, such that the program can fulfill the technical requir…

What. What good programs are written in C that don't have well-structured memory management the way C++ does it with RAII? Edit: "But in reality, why C is still the best programming language for large projects (IMO) is exactly that the programmer is allowed to choose a suitable structure, such that the program can fulfill the technical requirements. Other languages force the project into a structure that somehow neve…

What are your thoughts on D or Rust as they compare to C++?

Re: Ask HN: What should a systems/low-level software engineer know?

#92

Post by signa11 »

Waterluvian wrote: post #43
tonysdg wrote: post #39

Earlier quoted context omitted.

A quick word of warning: be sure to treat C and C++ as two completely separate languages that just happen to have similar syntax. Yes, you can use C++ as "C with classes" (I and many others sure have at times), but you're doing yourself a disservice most of the time if you do.

Huh. I always perceived C to be a subset of C++.

imho, c :: c++ == ipv4 :: ipv6 (where '::' should be read as 'is to' relation)

Re: Ask HN: What should a systems/low-level software engineer know?

#94

Post by zozbot123 »

m-ee wrote: post #16
flipnotic wrote: post #4

In embedded and systems-level programming, something I find indispensable is knowing what values fit in what types (for example, an 8-bit type can represent a maximum of 256 values; a 16-bit type can represent 65536 values). This comes up incredibly frequently, and having it be second nature will benefit you. A lot of the time, this gives you a starting place for how your inputs and outputs should look, what your met…

Also the ability to understand and check the performance impact of these choices. For example at a old job on an embedded motor controller the previous engineer had learned 'floats are slow never use them on a microcontroller' and went and removed them from the code wherever he found them. However in the motor control update loop this meant using longs (or possibly even long longs, I don't remember) in a couple calcu…

Fixpoint arithmetic is going to be significantly more efficient than floating point in many cases, except where you need to use relatively-uncommon operations/functions (which are hardware-accelerated in the FPU), or in cases where the same value might span multiple orders of magnitude (i.e. a direct win for the floating point representation). The inner loop of a microcontroller is not generally one of these cases, though exceptions might be out there.

Re: Ask HN: What should a systems/low-level software engineer know?

#95

Post by turbinerneiter »

If your are looking towards embedded:

* put a cap between power and ground

* get some nice ESD-birkenstocks

* don't listen to anybody telling you how it's done

The start of the art is BS and we need a revolution. There will be so many people who tell you that you can only do it in C and if you don't, you can't be taken seriously. The result is that everybody is keeping to C and nobody invests time in bringing new ideas to the field. The chip vendors stubbornly ship you really, really bad C SDK's and have no interest in doing better, for reason beyond my comprehension.

As you mentioned Rust - there is a Rust working group for embedded targets and they do cool stuff, but it's hard and a lot of work. Also, hardware is basically a huge block of global mutable state, so that is a problem to wrap ones head around.

But eventually we have to get rid of "C is the only serious option" which is an argument made by people who know how to write "safe" C and perpetuated by people who can't, but act like it.

[Before you react - I know this is an "extreme" statement and it's not 100% accurate and there is much more nuance to it - it is exaggerated for comic effect ;)]

Re: Ask HN: What should a systems/low-level software engineer know?

#97

Post by megous »

Calloggs wrote: post #78
jm__87 wrote: post #56

Earlier quoted context omitted.

Maybe it is just me, but I've seen this issue multiple times where a programmer used a regular expression thinking they were clever, only to have it backfire later when there was some corner case not covered by their regex (which likely would have obviously been caught if they had just taken the time to write out each case as an if statement). You're usually just gaining complexity in exchange for fewer lines of code…

Regardless of implementation (regex vs. conditionals), there should be sufficient unittesting to make sure that all the corner cases are tested. For embedded systems, the complexity tradeoff is relevant though, since a regex library will (probably) take up more code space than some conditionals.

Just use re2c. There's no library.

Re: Ask HN: What should a systems/low-level software engineer know?

#98

Post by [deleted] »

pjc50 wrote: post #85
SamReidHughes wrote: post #75

Earlier quoted context omitted.

What. What good programs are written in C that don't have well-structured memory management the way C++ does it with RAII? Edit: "But in reality, why C is still the best programming language for large projects (IMO) is exactly that the programmer is allowed to choose a suitable structure, such that the program can fulfill the technical requirements. Other languages force the project into a structure that somehow neve…

> What good programs are written in C that don't have well-structured memory management the way C++ does it with RAII? MISRA C standards, popular in embedded projects especially automotive, ban the use of memory management altogether. The whole point of RAII is that the compiler manages it for you as far as it can. This is impossible in C because you have to do it manually. You might end up writing malloc() at the to…

[deleted]

Re: Ask HN: What should a systems/low-level software engineer know?

#99

Post by ninjakeyboard »

I am somewhat of a systems engineer but more in the distributed systems space rather than embedded systems. I guess:

- runtime/space complexity and general algorithmic heuristics to know how the system will perform, or to be able to fix scale issues in the code.

- network characteristic (eg fallacies of distributed computing)

- CAP theorem and applying it to real world designs

- A co-ordination tool like zookeeper

- Understanding of the technological lay of the land (eg compression like snappy, different tools and approaches for communication like zeroMq, kafka

- Metrics and alerting - eg get how to instrument with statsd and know how and where to alert.

- Concurrency concerns and scheduling - you can get away with understanding futures and the actor model and can steer away from threading fortunately. (eg elixir/OTP or Akka)

Re: Ask HN: What should a systems/low-level software engineer know?

#100

Post by Something1234 »

turbinerneiter wrote: post #95

If your are looking towards embedded: * put a cap between power and ground * get some nice ESD-birkenstocks * don't listen to anybody telling you how it's done The start of the art is BS and we need a revolution. There will be so many people who tell you that you can only do it in C and if you don't, you can't be taken seriously. The result is that everybody is keeping to C and nobody invests time in bringing new ide…

What would putting a single cap directly between power and ground be? Wouldn't that be a short circuit or boom?
Post reply on HN