EEVblog Electronics Community Forum

General => General Chat => Topic started by: DJPhil on April 22, 2010, 12:39:52 am

Title: XKCD was interesting today
Post by: DJPhil on April 22, 2010, 12:39:52 am
I'm sure some of you have heard of the webcomic XKCD. Today's was a good one for electronics, and I thought you guys might enjoy it.

http://www.xkcd.com/730/# (http://www.xkcd.com/730/#)

I think my favorite bit was the arena. :)
Title: Re: XKCD was interesting today
Post by: GeoffS on April 22, 2010, 01:01:09 am
I was going to make it but my local supplier is all out of flux capacitors  >:(
Title: Re: XKCD was interesting today
Post by: David on April 22, 2010, 12:50:38 pm
That would make a nice t-shirt!
Title: Re: XKCD was interesting today
Post by: JoeB83 on November 16, 2015, 06:25:36 am


(http://imgs.xkcd.com/comics/snakes.png)

That's a good one.  ^-^
Title: Re: XKCD was interesting today
Post by: AlfBaz on November 16, 2015, 02:25:58 pm
hit random a few times and came across this... would been handy in that thread we had about using goto :)


(http://imgs.xkcd.com/comics/goto.png)
Title: Re: XKCD was interesting today
Post by: free_electron on November 16, 2015, 03:11:47 pm
I don't understand the fuss about the usage of 'goto'.
even the most 'properly' constructed code will compile down to using JMP instructions. which is nothing more than a goto.
Title: Re: XKCD was interesting today
Post by: T3sl4co1l on November 16, 2015, 03:20:29 pm
Not necessarily true -- although I don't know of any languages which compile semantic constructs into e.g. function calls.  That is, putting the inner braces of each execution path into their own functions.  And by function, I mean, using CALLs instead of JMPs.

But the higher level semantics are much more valuable than the machine code that implements it, at least for average development.  In this post-computational-abundance world, the programmers' bandwidth is the limiting factor.  (Well, almost.  One would hope.  Of course, more computing power always means bigger and slower high level libraries, or scripting languages.  So...)

And, that said, I would enjoy if assembler were designed with indentation in mind.  Many (older?) assemblers won't even accept it -- they expect strict whitespacing.  That makes it very hard to read and write structured code.  Usually, big comment blocks are used.

Tim
Title: Re: XKCD was interesting today
Post by: AndyC_772 on November 16, 2015, 03:24:52 pm
goto xkcd (https://www.eevblog.com/forum/chat/xkcd-was-interesting-today/msg801557/#msg801557)
Title: Re: XKCD was interesting today
Post by: ECEdesign on November 16, 2015, 07:08:40 pm


(http://imgs.xkcd.com/comics/snakes.png)

If you hover over the image on the website it says:

"The last band of color indicates the snake's tolerance for being held before biting."  ;D
Title: Re: XKCD was interesting today
Post by: rolycat on November 16, 2015, 07:59:13 pm
Yesterday's strip was good, and (somewhat) electronics related:

(http://imgs.xkcd.com/comics/flashlights.png)

The most powerful hand-held torch (flashlight) I could find is the X-LED XHP DualBeam, which the manufacturers reckon is 50,000 lumens.
They are apparently working on a 1 million lumen LED light, but since this will consume 5 kW you probably won't be able to slip it in your pocket.
Title: Re: XKCD was interesting today
Post by: AF6LJ on November 16, 2015, 08:58:27 pm
I'm sure some of you have heard of the webcomic XKCD. Today's was a good one for electronics, and I thought you guys might enjoy it.

http://www.xkcd.com/730/# (http://www.xkcd.com/730/#)

I think my favorite bit was the arena. :)

Been around for a long time but still funny as hell. :D
Title: Re: XKCD was interesting today
Post by: IanB on November 16, 2015, 09:00:03 pm
The most powerful hand-held torch (flashlight) I could find is the X-LED XHP DualBeam, which the manufacturers reckon is 50,000 lumens.
They are apparently working on a 1 million lumen LED light, but since this will consume 5 kW you probably won't be able to slip it in your pocket.

Well, put two 28 V power tool batteries in series and that will give you 56 V. Such batteries can comfortably supply 100 A, so there's 5 kW. More lantern sized than pocket sized perhaps, and it won't run for very long, but it would be cool on a dark night.
Title: Re: XKCD was interesting today
Post by: kfitch42 on November 16, 2015, 09:20:37 pm
Well, put two 28 V power tool batteries in series and that will give you 56 V. Such batteries can comfortably supply 100 A, so there's 5 kW. More lantern sized than pocket sized perhaps, and it won't run for very long, but it would be cool on a dark night.

A quick google told me that the Makita 28V battery is 3.0Ah. So, we are talking less than 2 minutes at 100 Amp. I am guessing these things aren't designed for continuous operation at 100A. So, hopefully they won't last long enough to heat up to thermal runaway...

But, at least you will be able to see what you are doing while jump starting a big diesel truck: https://www.youtube.com/watch?v=AsTJKSH7mCU (https://www.youtube.com/watch?v=AsTJKSH7mCU)
Title: Re: XKCD was interesting today
Post by: NANDBlog on November 16, 2015, 10:39:39 pm
I don't understand the fuss about the usage of 'goto'.
even the most 'properly' constructed code will compile down to using JMP instructions. which is nothing more than a goto.
Because memory leak, and dinosaurs.

BTW if you want bright flashlights, try them with Maxwell supercapacitor banks. 75V 1800A from something that fit into a backpack.
Title: Re: XKCD was interesting today
Post by: HackedFridgeMagnet on November 16, 2015, 11:30:21 pm
(https://imgs.xkcd.com/comics/exploits_of_a_mom.png)

Had this one on the fridge. My son was fascinated by it even though he was young and didn't know what SQL was.




https://xkcd.com/1133/ (https://xkcd.com/1133/)
Is currently on the fridge:
Title: Re: XKCD was interesting today
Post by: suicidaleggroll on November 16, 2015, 11:45:53 pm
In addition to the above, I like these ones:
(http://imgs.xkcd.com/comics/hard_reboot.png)

and

(http://imgs.xkcd.com/comics/code_quality.png)
Title: Re: XKCD was interesting today
Post by: Delta on November 17, 2015, 12:03:38 am
goto xkcd (https://www.eevblog.com/forum/chat/xkcd-was-interesting-today/msg801557/#msg801557)

Well played, Sir.
Well played!
Title: Re: XKCD was interesting today
Post by: rs20 on November 17, 2015, 12:21:06 am
I don't understand the fuss about the usage of 'goto'.
even the most 'properly' constructed code will compile down to using JMP instructions. which is nothing more than a goto.
Because memory leak, and dinosaurs.

Ironically, I have a soft spot for goto in one particular usecase: preventing memory leaks on error conditions (athough I don't use it in this situation professionally, and I generally abhor goto in every other case). Example:

Code: [Select]
void main() {
  FILE* f1 = fopen( ... );
  if (f1 == NULL) {
    printf("Failed to open f1\r\n");
    return;
  }

  Object a = makeObject();
  if (a == NULL) {
    printf("Failed to make a\r\n");
    goto finalize_f1;   
  }

  ...

  if (nasty.error()) {
    printf("Ouch\r\n");
    goto finalize_a;
  }

  ...

finalize_a:
  a.finish();
  delete a;
finalize_f1:
  fclose(f1);
}

Obviously in this case the Object could have been allocated on the stack; but it's more the problem of issuing cleanup method calls like close() -- which may well delete objects internally. Of course more featured languages have things like the defer block, which is one of many ways to avoid this pattern.
Title: Re: XKCD was interesting today
Post by: IanB on November 17, 2015, 12:43:15 am
Ironically, I have a soft spot for goto in one particular usecase: preventing memory leaks on error conditions (athough I don't use it in this situation professionally, and I generally abhor goto in every other case). Example: ...

In C++ the RAII pattern can be used to good effect where resource cleanup should happen for all exit paths including errors and exceptions.
Title: Re: XKCD was interesting today
Post by: rs20 on November 17, 2015, 12:45:33 am
Ironically, I have a soft spot for goto in one particular usecase: preventing memory leaks on error conditions (athough I don't use it in this situation professionally, and I generally abhor goto in every other case). Example: ...

In C++ the RAII pattern can be used to good effect where resource cleanup should happen for all exit paths including errors and exceptions.

Indeed, I really like RAII, although it's not available in pure C of course. I've been meaning for a while to see what the overhead for using C++ on AVR is...
Title: Re: XKCD was interesting today
Post by: Delta on November 17, 2015, 01:22:48 am
I'm just learning C, so don't have a clue, but...

I fully understand that abusing goto can result in awful spaghetti code, but the "thou shalt not us goto under any circumstances" mantra seems almost cult-like!
Title: Re: XKCD was interesting today
Post by: JoeO on November 17, 2015, 01:27:09 am
I'm just learning C, so don't have a clue, but...

I fully understand that abusing goto can result in awful spaghetti code, but the "thou shalt not us goto under any circumstances" mantra seems almost cult-like!

C code can be written without using GOTOs. 
Title: Re: XKCD was interesting today
Post by: Maxlor on November 17, 2015, 02:31:52 am
I'm just learning C, so don't have a clue, but...

I fully understand that abusing goto can result in awful spaghetti code, but the "thou shalt not us goto under any circumstances" mantra seems almost cult-like!
You can break the rules once you've mastered them, but not before. It's neither a mantra nor cult-like, it's just something meant to preserve as much global sanity as possible.
Title: Re: XKCD was interesting today
Post by: Delta on November 17, 2015, 02:53:10 am
I'm just learning C, so don't have a clue, but...

I fully understand that abusing goto can result in awful spaghetti code, but the "thou shalt not us goto under any circumstances" mantra seems almost cult-like!

C code can be written without using GOTOs.

I'm sure it can be written without using a lot of things!  So surely that's not a reason by default. 

I have read a fair bit about this on stackexchange and other sites, and it seems that people will go to (pun not intended, sorry) extreme lengths, writing convoluted code, just to avoid a goto!  That's when it seems to me like more dogma than engineering!
Title: Re: XKCD was interesting today
Post by: Delta on November 17, 2015, 02:54:27 am
I'm just learning C, so don't have a clue, but...

I fully understand that abusing goto can result in awful spaghetti code, but the "thou shalt not us goto under any circumstances" mantra seems almost cult-like!
You can break the rules once you've mastered them, but not before. It's neither a mantra nor cult-like, it's just something meant to preserve as much global sanity as possible.

I am looking forward to that day!
Title: Re: XKCD was interesting today
Post by: IanB on November 17, 2015, 03:26:27 am
I have read a fair bit about this on stackexchange and other sites, and it seems that people will go to (pun not intended, sorry) extreme lengths, writing convoluted code, just to avoid a goto!  That's when it seems to me like more dogma than engineering!

One of the most important things about good code is that the algorithm and logical flow should be clear to a human reader. Inappropriate use of goto's can go against this, which is why goto's are frowned upon. If an occasional goto is used in a clear and logical way, for example to jump to an error handler, then that should not be seen as a problem.
Title: Re: XKCD was interesting today
Post by: Delta on November 17, 2015, 03:45:27 am
That's my understanding, Ian.  But it seems a lot of people think that goto should categorically not be used, at all, ever.  That's what seems daft to me.
Title: Re: XKCD was interesting today
Post by: hamster_nz on November 17, 2015, 04:08:14 am
good ... should be clear to a human reader. Inappropriate use of goto's can go against this

I pretty much agree a 'goto' is a special tool for a special case. Could it be that source code has inherently one-dimensional aspects to them (the flow of the program counter / instruction pointer through the code, the way the call stack works), and a goto works against this mind set by allowing unstructured jumps?

I've never seen anybody say that flowcharts are bad, as they allow you to draw arrows across logical boundaries, maybe they need a rule that you should never 'cross the streams'?

Neither in formal state transition diagrams, where you can jump between arbitrary states however you see fit. When you convert a FSM to code you basically end up with spaghetti.

I definitely remember the "no goto" rule being around in the early 80s in the time of structured BASICs, PASCAL and COBOL... Maybe a lot of it is hangover from old languages where your GOTOs used the line number as the target for jump, rather than a label. Those days were really nasty - if you renumbered code you could shoot yourself in the foot sooooo badly. These days the destination for a goto is has limited scope, and so at least it has a bit of structure to it.

One C coding standards I had to follow in the 90s recommended this construct for processing errors:

Code: [Select]
void some_func(void)
{
  do {
    if( ! something_that_might_error() ) /* e.g. malloc or fopen() */
      break;

    if( ! something_else_that_might_error() )
      break;

    <do the real work>

    return 1; /* Success */
  } while(0);

  <error handling code>
  return 0; /* Failure */
}

It was a poor man's way of exception handling, or abusing C to give 'goto' like functionality without actually using the word.

Anyhow - just idle musings rather than me saying anything of any value.
Title: Re: XKCD was interesting today
Post by: suicidaleggroll on November 17, 2015, 02:49:51 pm
I'm sure it can be written without using a lot of things!  So surely that's not a reason by default. 

I have read a fair bit about this on stackexchange and other sites, and it seems that people will go to (pun not intended, sorry) extreme lengths, writing convoluted code, just to avoid a goto!  That's when it seems to me like more dogma than engineering!

Go spend a week debugging/flowcharting an old FORTRAN 77 research code written by a scientist.  You'll light your hair on fire and run out of the building screaming before you make much headway, but from then on every time you see or write the words "goto" or "common" in any program in any language, it will give you a mild case of PTSD.

Using one here or there for error handling/cleanup is fine, but it's too easy to fall into their "lazy" trap and start using them WAY too liberally, which ultimately ends up making the code nearly impossible to read or debug.  It's best to just avoid them altogether, at least until you have a good grasp of the damage they can cause and know ways you can avoid them while maintaining readability.