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

[Joe Armstrong]

On Wed, Aug 19, 2015 at 1:39 AM, Steve Davis
<steven.charles.davis@REDACTED> wrote:
> Hi Roelof,
>
> Here you go:
>
> 1> [[{sorted, lists:sort(X)}, {count, length(X)}] || X <-
> [inet:module_info(exports)]].
> ...
> 2> [get_rc/0].
> ** exception error: an error occurred when evaluating an arithmetic
> expression
>      in operator  '/'/2
>         called as get_rc / 0
>
> What the book/lesson is trying to teach is probably not how to do basic
> operations on lists (which is notionally the point of the exercise). It’s
> actually trying to get you to reach for the right tool to do the job by
> getting you to explore the platform libraries and the power of the platform
> for yourself.
>
> Yes, I cheated above and used a comprehension above to present the answers
> you want, and also showed what happens when you get what you originally
> asked for. Likely you didn’t learn much from that, since what I typed in was
> born of spending time with the libraries and knowing what to do with a
> problem I’m presented with and understanding what erlang tells you when you
> get it “wrong".
>
> You need to be patient and find your own solutions to things, since if you
> are merely taking others’ solutions, you will never become a “power user”.
> It’s a hard slog, I don’t deny that.
>
> However, the REPL, particularly in your early learning lets you try things
> out instantly, and is invaluable help in breaking down a problem. You can
> try individual steps extremely easily - and in a way that is simply not
> possible with non-functional languages.

Yes ^ 100

I still use the REPL a lot when programming. I often try things out in
the shell and then when they work cut-and-paste the shell text into my
favorite. editor and prettyfy the result.

This is the oppose of TDD. TDD says

    step 1) - write a test case
            2) - run the test case
            3) - if step 2 fails fix the error
            4) - iterate

My workflow might be

          1) run a test case in the shell
          2) if it works cut-and-parse into editor and prettyfy
          3) iterate

If you're a beginner you should write modules "one function at a time"
testing as you go (I do this in all languages) - when you get more experience
you can take bigger steps.

The "one function at a time" bit is important - when you call a
function that you
have already written you should be confident that the called function
is correct - so errors in the new function should be in the new
function and not in the functions you are calling.

When I work this way the vast majority of errors are in the function
I'm currently writing.

My advice is "think top down" - program "bottom up" write small functions first
and build on them but have a clear idea in you head where you are going.

Try and think out your entire program before writing it and do experiments
where your understanding is unclear.

The best way to be an efficient programmer is not to write any code at all
if you think through an algorithm and realise it won't work then you save
yourself a heck of a lot of time programming.

Like most creative art forms programming is about seeing the world in
a particular way, an artist stares at a scene for hours wondering how
to represent it. A photographer plans there next photo. A programmer
thinks about their problem for a long time wondering how to represent it.

An guess what - tools (fancy editors, IDEs and the like) don't help
thinking - they do help the mechanics of entering the code (just like power
tools help a carpenter) but they don't *invent* algorithms, and they
don't slve problems.

Programming is a craft that takes years to get good at and it's not
easy - that's why it's fun. Things that are easy are no challenge

....



>
> If it’s any help or encouragement, it took me months to “grok” erlang and
> its unfamiliar ways, but once I had, I realized what I was missing. Each
> day, even after a few years, I learn something new and positive about the
> platform. It’s also been an empowerment in my relationship to computers; I
> can express concepts that would be essentially intractable in many popular
> languages.

I know the feeling - things that are obvious are surprisingly unobvious until
somebody points them out

>
> I wish you well in your journey (one that I have personally experienced) and
> offer the thought that it’s likely more rewarding, and more empowering in
> the long term, to sit with a problem, read the documentation that comes with
> Erlang (which is extremely good despite its many critics) and *find your own
> solution* than to look outside for help too quickly.
>
> Sure if you get totally stuck, there’s help here.

And if nothing else you can read long rambling discussions on how
to program :-)

>
> I can promise you that the long path and all the hard work to becoming an
> “erlang ninja” will be worth every second.

Well perhaps not every second - but the reward for hours of struggleing
with mal-placed commas and swearing over the inadequacy of
error message are flashes of insight.

T.S.Eliot had a nice line ...

    or music heard so deeply
   That it is not heard at all, but you are the music
   While the music lasts

He was really talking about programming - you are the computer while
you are programming - this is called "flow"

When flow happens hours pass in seconds and your programs will
just work.

Flow does not happen in open plan offices, nor while programmjng node.js

Have a nice day

/Joe


>
> /s
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>