2 ms·

It's rapidly becoming a two tier world with two types of programmers: those who are well trained in coding within known environments, and those who are like the

by api 11y ago

It's rapidly becoming a two tier world with two types of programmers: those who are well trained in coding within known environments, and those who are like the folks in The Matrix films who ate the red pill-- they know what's really going on.

jpatokal 11y ago
It's been like that for decades. Or do you really know what assembler your program compiles down to?
- djcapelis 11y ago
  For some of them, absolutely. I change the assembly output and reassemble to verify that the atomics are necessary and fixing the cases I think they do. As far as I'm concerned, if you're not removing the atomic instructions to make sure the breaks happen that you expect to happen, you're not really testing your code.
joezydeco 11y ago
I'm an embedded systems engineer. It's always been that way for me: I own and compile the bootloader, kernel, filesystem, runtime libraries, and the application code. I have the schematics and gerbers for my boards. I have the reference manuals for every chip. What's weird is watching people play with stuff like Raspberry Pi and they expect things to just apt-get and launch like it's always been done for them. And most of the time it does just work that way. Except when it doesn't.
- louithethrid 11y ago
  many development enviroments would do good with some graphics representation of how much of the plattforms capabilitys is actually used up during a test run, how cache friendly the code is, and how much your latest changes affected this. And this coloured columns need to show in every svn/git commit message. Profiling needs to be not something that the embeded guy does after you messed it up. Jerry Commited: +25% more time spend in function xy, due to chace unfriendlyness.. If you see it, and your colleagues see it, it becomes a issue. If it becomes a issue the perpetrator will look into it.

by api 11y ago

jpatokal 11y ago

It's been like that for decades. Or do you really know what assembler your program compiles down to?

djcapelis 11y ago
For some of them, absolutely. I change the assembly output and reassemble to verify that the atomics are necessary and fixing the cases I think they do. As far as I'm concerned, if you're not removing the atomic instructions to make sure the breaks happen that you expect to happen, you're not really testing your code.

joezydeco 11y ago

I'm an embedded systems engineer. It's always been that way for me: I own and compile the bootloader, kernel, filesystem, runtime libraries, and the application code. I have the schematics and gerbers for my boards. I have the reference manuals for every chip. What's weird is watching people play with stuff like Raspberry Pi and they expect things to just apt-get and launch like it's always been done for them. And most of the time it does just work that way. Except when it doesn't.

louithethrid 11y ago
many development enviroments would do good with some graphics representation of how much of the plattforms capabilitys is actually used up during a test run, how cache friendly the code is, and how much your latest changes affected this. And this coloured columns need to show in every svn/git commit message. Profiling needs to be not something that the embeded guy does after you messed it up. Jerry Commited: +25% more time spend in function xy, due to chace unfriendlyness.. If you see it, and your colleagues see it, it becomes a issue. If it becomes a issue the perpetrator will look into it.