[erlang-questions] How to make this work
Wed Aug 12 19:48:50 CEST 2015
On Wed, Aug 12, 2015 at 7:20 PM, Fred Hebert <mononcqc@REDACTED> wrote:
> On 08/12, Roelof Wobben wrote:
>> Im trying this exercise from the programming erlang book.
> Hi Roelof.
> Honest advice here is that you really, really need to sit down and read more
> carefully through the documentation you have at hand, and to try
> experimenting with your programs a bit. We've been through this months ago
> Here's a quick list:
> Feb 2015:
> - http://erlang.org/pipermail/erlang-questions/2015-February/083087.html
> Valid question from the exercise book, because too simple of a solution was
> indeed too simple.
> - http://erlang.org/pipermail/erlang-questions/2015-February/083162.html
> correct implementations, but you confused strings and atoms. Those were
> exercises from 'Erlang Programming' book. Atoms are introduced on p.19, the
> exercises on p.44. -
> This is a function again from Erlang Programming. The precise implementation
> you are looking for for sum_acc/3 is on page 68, and is not actually an
> exercise as mentioned
> - http://erlang.org/pipermail/erlang-questions/2015-February/083217.html
> You found a compile error for mismatching heads. I'm not sure when in the
> book it is, but I'd like to show you the link
> where I compiled the common compile errors, with their explanation and how
> to fix them.
> - http://erlang.org/pipermail/erlang-questions/2015-February/083233.html
> Valid enough question about list building, I have little to say here
> - http://erlang.org/pipermail/erlang-questions/2015-February/083240.html
> Error on the syntax of atoms, again introduced on p.19. The error *is* a bit
> cryptic though
> - http://erlang.org/pipermail/erlang-questions/2015-February/083301.html
> Exercise from the Erlang programming book. Trying the guards you had set in
> the shell with numbers would have revealed the problem directly (as pointed
> out in the first response)
> Fast forward to this month:
> - http://erlang.org/pipermail/erlang-questions/2015-August/085382.html
> I'll point you for some like this to the same learnyousomeerlang link in the
> future, it's also there!
> - http://erlang.org/pipermail/erlang-questions/2015-August/085410.html
> The problem there was an unexported function. The error you saw was probably
> something like 'undef'. In this case, and for other errors happening at
> runtime, I'd like to redirect you to
> http://learnyousomeerlang.com/errors-and-exceptions#run-time-errors which
> includes descriptions for such errors and ways to fix them in general. Note
> that the error is also described on page 70 of Erlang Programming.
> - http://erlang.org/pipermail/erlang-questions/2015-August/085419.html
> Dialyzer errors are legitimately confusing for a newcomer!
> - http://erlang.org/pipermail/erlang-questions/2015-August/085438.html
> Valid question from 'make it work -> make it beautiful' as a progress
> - http://erlang.org/pipermail/erlang-questions/2015-August/085496.html
> This very thread. The content there is from Programming Erlang (Armstrong).
> If it's the second edition, I don't have it, but in the first edition, the
> syntax to functions is explained on page 42. In Erlang programming (which
> you also have), it's on page 190, and in Etudes for Erlang, which you have
> also looked at, they're explained in chapter 7
> Don't get me wrong, I appreciate people posting to the mailing list. The
> thing is, I feel that it would be helpful for *your* learning as a whole to
> make use of the resources you have rather than coming to the list as often
> as you do. For one, the feedback loop and your progress will be much faster!
> Out of the 12 email threads I have linked here, at least 6 of them could
> have been solved by re-reading the learning material you have in your hands
> (because that's where you take exercises and examples from), or by
> experimenting rapidly with the shell.
> The other half were good questions to ask, so by all means, don't stop
> asking questions. Just make sure that you're not using us as your own
> private debugger!
> Old timers from the industry will tell you stories of when they had to take
> punched cards or hand-written programs, had to go to their university
> department to make them run, wait hours or days before finding if things
> were alright, and then repeating this over again for every bug.
Those were the days - it was actually three weeks.
send handwritten coding sheets to be turned into punched cards
get punched cards back and proof read them, if ok send to
computer centre. If not ok go to beginning
Get results back from computer. The good old FORTRAN compiler
stopped at the first syntax error it found and went no further.
So K syntax errors took 3*K weeks to debug *before* the program ran for
the first time.
The van came one a week and drove the punched cards to the computer
Once we had a visit to the computer center - the programmers wore
white lab coats - I was *very* impressed.
Years later the turn round time was down to a mere 3-hours and
we could punch our own cards.
Now the turn-round time is the time it takes the spring under the return
button to uncoil - (apart from when running XCode that is)
All I can say is that we thought a lot lot longer and harder before
submitting our programs - three week turn-round time makes you stare
really really hard at your code before sending it off.
So in the old days we did a lot of thinking and the machines did
very little. Now
the machines are so fast we don't do much thinking, and in a few years time
we probably won't do any!
and then I remember ....
<we know> Yawn ......
Sorry .... just an old timer
PS. Don't set Mike off - he'll go on and on about paper-tapes ....
starting with punched cards was incredibly luxurious
> When you ask us to solve such problems for you while you have all the
> information required, you might just be throwing yourself back 30-40 years
> in the past in terms of feedback loops!
> You've got the material, the tools, and visibly the drive to do that stuff.
> It's likely going to be simpler in the long run to make a few experiments,
> run them, and see if you can figure it out (or go back and re-read
> significant chapters in one of the many books you have on the topic) than
> the time it takes for you to write an email and wait for a response.
> erlang-questions mailing list
More information about the erlang-questions