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

[Roelof Wobben]

Op 20-8-2015 om 8:00 schreef Richard A. O'Keefe:
> 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".
>
>
>
>

I think that is one part of the problem,
The other part is that I "just" started with Erlang so the language is 
unfamiliir in terms of
which part casn help me solve the problem. Is it a LC  or a map or just 
pattern matching.
The last part can , in my oponion , only be solved by doing things. I 
could read a thousand
books but to solve a problem myself I learn a lot more.

Roelof

>


---
Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware.
https://www.avast.com/antivirus