Programming memes

[T3sl4co1l]

Tim

[Tomorokoshi]

That's so true it hurts.

[free_electron]

how many programmers do you need to change a lightbulb ?

They can't do it ! its a hardware problem ...

[Ice-Tea]

[SiliconWizard]

So true... That's a good one! 

[dmills]

Pretty sure I have interviewed that guy, on several occasions, and I am am very much afraid I have hired him once

[hans]

[Tomorokoshi]

(Image removed)

Pretty sure I have interviewed that guy, on several occasions, and I am am very much afraid I have hired him once

I watch for a skills list 20 items long on the resume. Then I dig into one or two, and inevitably we get an answer something such as, "Yeah, we had LabVIEW, like, for like one semester, and that was, like, really long ago... like a couple years ago."

And so they list it, and so they get rejected. Kind of like parts with bogus datasheets.

[brucehoult]

(Image removed)

Pretty sure I have interviewed that guy, on several occasions, and I am am very much afraid I have hired him once

I watch for a skills list 20 items long on the resume. Then I dig into one or two, and inevitably we get an answer something such as, "Yeah, we had LabVIEW, like, for like one semester, and that was, like, really long ago... like a couple years ago."

And so they list it, and so they get rejected. Kind of like parts with bogus datasheets.

There's a tension here.

I can learn to use/do almost anything you want, on a time scale that is trivial in the context of a permanent (or even 2 - 3 year) job. I don't have time to learn everything that you *might* want, in advance of getting the job.

But if HR don't see their correct buzzwords listed on your CV then you don't even get the chance for an interview.

Simple example: C, C++, Obj-C, Java, C#, Python, Perl, Ruby, JavaScript, PHP, Kotlin, Scala, Swift, Go, Rust are all so similar that if you can program in one of them (especially if that one is C++ lol) then you can pick up any of the others quickly if you need to. But is anyone expert in *all* of them? Hell, no.

The same with assembly languages. I cut my teeth on 6502, Z80, PDP11, VAX, then moved on to 6809, 68000, PowerPC, MIPS, ARM, ARM64, RISC-V. I've even done .. ugh .. x86 from time to time .. e.g. 18 months ago I crested a simple scheme for on-the-fly mapping RISC-V instructions to x86_84 that outperformed QEMU by a factor of two and often ran RISC-V code on an i7 only 30% slower than gcc optimised native x86 code.

You've got some wacky home-grown programming language or CPU? I'm pretty sure I can cope...

Fortunately, there is a way around lying to the HR drones to get an interview and then being quizzed on stuff you don't actually know: approach the people you'll be working with (especially future supervisor) directly, or at least do something cool that they'll notice, and have THEM come to you and say "Why don't you come to work for us?" and then they *tell* HR to hire you.

My (spare time) work on the above-mentioned RISC-V emulator is one of the things that got the attention of SiFive and led to them hiring me. My work on the Boehm–Demers–Weiser garbage collector led to both Samsung and before them Mozilla offering me earlier jobs. The vast majority of other jobs have come from getting someone to introduce me to their boss.

In 35 years I've only got *one* (1) job via the traditional job agency/CV route. Shotgun sending out of CVs is a mug's game, and heck of a depressing.

[Dielectric]

Getting back to the memes... Have you seen this one?



(easy one, I'm just posting to get the notifications!)   

[dmills]

"Everyone knows that debugging is harder then writing it in the first place, so if you write code as cleverly as you are able, how will you ever hope to debug it?"

I forget who said it, but it is horribly true.

Regards, Dan.

[nugglix]

It's from Brian W. Kernighan.

See:
http://www.defprogramming.com/quotes-by/brian-w-kernighan/

PS: And it's so damn true...

[Mr. Scram]

"Everyone knows that debugging is harder then writing it in the first place, so if you write code as cleverly as you are able, how will you ever hope to debug it?"

I forget who said it, but it is horribly true.

Regards, Dan.

Write code in an hour. Debug that weird thing happening for the rest of the day. 

[free_electron]

So true... That's a good one! 

if the arduino was connected to a laptop that has internet : add IoT specialist.

[free_electron]

The new Cray is so fast it can finish an endless loop in just under 4 hours....

The only thing faster than a Cray , is the new Cray.

[SiliconWizard]

4 hours... nice uptime for a Win 10 box! 

[thermistor-guy]

(Image removed)

Pretty sure I have interviewed that guy, on several occasions, and I am am very much afraid I have hired him once

I watch for a skills list 20 items long on the resume. Then I dig into one or two, and inevitably we get an answer something such as, "Yeah, we had LabVIEW, like, for like one semester, and that was, like, really long ago... like a couple years ago."

And so they list it, and so they get rejected. Kind of like parts with bogus datasheets.

There's a tension here.

I can learn to use/do almost anything you want, on a time scale that is trivial in the context of a permanent (or even 2 - 3 year) job. I don't have time to learn everything that you *might* want, in advance of getting the job.

But if HR don't see their correct buzzwords listed on your CV then you don't even get the chance for an interview.
...
Fortunately, there is a way around lying to the HR drones to get an interview and then being quizzed on stuff you don't actually know: approach the people you'll be working with (especially future supervisor) directly, or at least do something cool that they'll notice, and have THEM come to you and say "Why don't you come to work for us?" and then they *tell* HR to hire you.

My (spare time) work on the above-mentioned RISC-V emulator is one of the things that got the attention of SiFive and led to them hiring me. My work on the Boehm–Demers–Weiser garbage collector led to both Samsung and before them Mozilla offering me earlier jobs. The vast majority of other jobs have come from getting someone to introduce me to their boss.

In 35 years I've only got *one* (1) job via the traditional job agency/CV route. Shotgun sending out of CVs is a mug's game, and heck of a depressing.

Excellent. Great to hear that there's hope for inventive people without cookie-cutter resumes.

[Sparky49]

[helius]

The Daily WTF has a large collection of terrible programming.

[bd139]

I currently deal with things that are worse than the daily WTF. Joy to buying out a competitor.

[ajb]

The Daily WTF has a large collection of terrible programming.

So do most MCU vendor frameworks.

[bd139]

Hahaha yeah I’ve been fighting XC8 toolchain this week. Just went and wrote the fucking code in assembly in the end.

[brucehoult]

There's some terrible code there, but the good news is modern compilers are pretty good.

For example I tried the "return true if x >= y" one.

bool ge(int x, int y){
    bool v;
    if (x > y) v = true;
    if (x < y) v = false;
    if (x == y) v = true;
    return v;
}

 gcc -O2 gave (on x86_84):

   cmpl   %esi, %edi
   setge   %al
   ret

On RISC-V64:

   slt   a0,a0,a1
   xori   a0,a0,1
   ret

(this is as good as you can do, as there isn't a "slte a0,a0,a1" or "sgt a0,a1,a0". slt/slti/sltu/sltiu is all you get (unsigned and immediate variants))

On Thumb2:

   cmp   r0, r1
   ite   lt
   movlt   r0, #0
   movge   r0, #1
   bx   lr

On ARM64:

   cmp   w0, w1
   cset   w0, ge
   ret

[T3sl4co1l]

Oooh, as I'm working with AVR right now I'm a little curious how that would evaluate.

Specifically, with -O0 it should be awful, more or less literal.  GCC is notoriously verbose on -O0.

Should be able to produce comparable results on -Os or -O3 though.

Tim

[brucehoult]

Oooh, as I'm working with AVR right now I'm a little curious how that would evaluate.

Specifically, with -O0 it should be awful, more or less literal.  GCC is notoriously verbose on -O0.

Should be able to produce comparable results on -Os or -O3 though.

I should have done AVR as I have the compiler lying around. Both -Os and -O2 produce...

    ldi r18,lo8(1)
   cp r24,r22
   cpc r25,r23
   brge .L2
   ldi r18,0
.L2:
   mov r24,r18
   ret

That's as good as you can get. Of course it's hampered by being only an 8 bit CPU, but in this case that's only one extra instruction. "cpc" is a bit of a clever instruction .. 6502 and so forth couldn't do that so easily -- they'd need to compare the high bytes first and only do the second compare if they were equal

[SiliconWizard]

Oooh, as I'm working with AVR right now I'm a little curious how that would evaluate.

Specifically, with -O0 it should be awful, more or less literal.  GCC is notoriously verbose on -O0.

Well, -O0 more or less disables all optimizations, as it allows for exact debugging.
With -O0, every C line should translate to some object code to allow stepping through the whole code while debugging. So this is expected.

Starting with -O1, this kind of trivial-to-optimize code is reasonably optimized. Higher level of optimizations may make use of specific target instructions, but on very simple targets, that may not make a difference (again for trivial code such as this, more complex code may benefit from many kinds of additional optimizations). Function parameters may also be passed as registers instead of using the stack.

[nuno]

Oooh, as I'm working with AVR right now I'm a little curious how that would evaluate.

Specifically, with -O0 it should be awful, more or less literal.  GCC is notoriously verbose on -O0.

Should be able to produce comparable results on -Os or -O3 though.

I always compile to AVR with -Os, it produces good results. -O3 applies more aggressive (and space hungry) speed optimization techniques such as loop unroling, but the AVR core is already fast.

In general, relevant space can be saved with only these 3 techniques:

• Declare with static all variables and functions not needed in other files.
• In functions where volatile variables are accessed more than 1 or 2 times, copy them to local variables at entry, manipulate local variables and copy them back to the volatiles at the end (typically interrupts... mind the mutual exclusion access).
• Declare main as int __attribute__((noreturn)) main () .

If very tight on space and can't/don't want to move to a bigger flash chip, GCC can sometimes be oriented to produce a smaller code by rearranging parts of the flow structure - the .LST file is our best friend when optimizing very aggressively.

[NorthGuy]

There's some terrible code there, but the good news is modern compilers are pretty good.

That's where compilers shine - optimizing "terrible" code. But nobody writes code like this. Thus, real world optimizations aren't equally impressive.

[brucehoult]

There's some terrible code there, but the good news is modern compilers are pretty good.

That's where compilers shine - optimizing "terrible" code. But nobody writes code like this. Thus, real world optimizations aren't equally impressive.

When programs write code it's often pretty horrible. I haven't looked too hard but verilator is likely to be an example. It's main sin that I know of is making functions waaaaay too long.