[erlang-questions] How can I make a list of this

Richard A. O'Keefe ok@REDACTED
Thu Aug 20 08:00:02 CEST 2015


On 20/08/2015, at 12:13 am, Roelof Wobben <r.wobben@REDACTED> wrote:

> oke, but I do not have a list of tuples but a list of lists that contain tuples,
> 
> So I have this  [ [ {1,2}, {2,3}],  [ { 1,3} , { 2,1} ] ]
> 
> and I do experiment a lot in erl but I seem to be lost. 

Many years ago when I was a teenager I wanted to learn to fly
an aeroplane.  My father took me to a local aerodrome and had
me given lesson 1.  It was great.  I could *do* this.  To get
lesson 2, I had to get a student pilot licence.  So I had to
have a medical examination, ECG, the works.  And I was rejected
on the grounds that I needed glasses.

I'm still upset by that.  I had heard of lots of flying accidents
caused by people flying in circumstances (low to the ground) or
conditions (darkness, clouds) that they were not trained for,
in order to show off or at least not to look bad to their
companions.  I had never heard (and still haven't) of an accident
caused by someone's glasses falling off.  And there was NO test
to probe "which would you prefer? To look like an idiot to your
friends, or to put their lives at risk?"

Personal application: asking for help on this list about
points that seem pretty obvious to the people answering does
not make you look impressive.  At first sight!  To me, it
makes you look like someone I *might* trust to fly me.  To
be brutally honest, I sometimes get the feeling "oh no, not
another message from Roelof Wobben", but heck, I'm *paid*
to teach people about programming.  (OK, so those are
*other* people who are enrolled here.  But still...)  But
there's _always_ something to learn from giving a lesson.

Let me get to the point.  In preparation for the lessons I
thought I was going to get, I read a couple of books.  In
one of them I found this advice:

   When something goes wrong,
   DON'T JUST DO SOMETHING, SIT THERE!

I've come across basically the same advice in several contexts,
including dealing with stroppy lawnmowers.

   DON'T JUST DO SOMETHING, SIT THERE!

What is my present situation?
How do I want it to be different?
Is the problem that I have the one I thought I had?
What I was doing just now was wrong, maybe I should stop doing that.
Can I approach this another way?
What if I just take it apart, clean the parts, and put them
together again (works for lawnmowers but NOT aeroplanes in flight)?
Maybe I should take the dog for a walk as a distraction.
(If you can do that from an aeroplane in flight you have a
very strange dog.)

A well known phenomenon is "regression under stress to first
learned behaviour".

   1. Learn method M1.
   2. Learn method M2 which is better in some way.
   3. Be put under stress.
   4. Be given a task for which M2 is more appropriate.
OOPS.  We tend to revert to M1.

Floundering around lost while programming is stressful, and
in such circumstances we *all* tend to revert to the habits
we learned earlier.  If you learned Lisp then C you'll be
trying to emulate #'(LAMBDA (...) ...).  If the other way
around, you'll be trying to emulate *p++.  (I am *so*
lucky that C was about the 80th programming language I
learned.)

Another phenomenon is "mental set".  From Wikipedia,
" A mental set is a framework for thinking about a problem.
 It can be shaped by habit or by desire.
 Mental sets can make it easy to solve a class of problem,
 but attachment to the wrong mental set can inhibit
 problem-solving and creativity."

That is, we can consciously or *unconsciously* adopt a
particular way of approaching a problem and we not only
tend to stick with it, we tend to forget that any other
way of approaching it might be possible.  One of the
things we have to do when we get stuck is to try to
step back and try to unjam our framework.

This actually ties in with the "hypnosis" that Scott Adams
(creator of "Dilbert") keeps talking about in his blog,
which turns out to be more the Bandler and Grinder "Structure
of Magic" stuff.  For example, in my country, the Prime
Minister is pushing for a change to the flag.  A majority of
people in the country are either passionately devoted to
the flag we have, or don't care about flags one way or another,
and would prefer to see the money spent on say health care or
child poverty or something.  We're going to get two
referendums, like it or not.  You'd think the first one would
be "do you want to change the flag?" and the second would be
"which of these designs do you prefer?"  But it's going to be
the other way around.  People were asked to submit designs.
Then a panel of so-called experts picked a short list of four.
The first referendum is going to ask us which of the four
*new* designs we prefer.  Then the second one will ask us
whether we want to stick with the old or adopt the winner of
the first referendum.

This back-to-front approach is not incompetence.
Putting the "which new one?" question first *REFRAMES*
the question from "do you want to change the flag" to
"which new design do you want to change to" so that by
the second referendum people will be feeling "but I
already picked this new design".

Half the art of politics is the art of controlling how a
problem is described, so that you control how people
perceive it, so that your solution looks good.  Another
example here is the way every random change is called a
"reform", even by journalists who ought to know better.

What's that got to do with you?  If you get stuck,
maybe you should try describing the problem a different
way.  Instead of talking about a "list of tuples",
maybe you could talk about "a set of descriptors",
or noting that a full function specification is
Module:Name/Arity, "a set of incomplete descriptors".
Maybe instead of saying "a nice X" you could say
"an X that is like this Y".  








More information about the erlang-questions mailing list