[erlang-questions] Erlang for youngsters

Thu Jun 19 23:53:31 CEST 2014

I like the idea.
Unfortunately they only have a Windows version, so I cannot check it out :-(

Thomas Lindgren writes:

> In the dark ages Ken Kahn demoed ToonTalk, which I thought was a pretty neat way of teaching concurrent programming (with actors) to kids.
>
> ToonTalk - Wikipedia, the free encyclopedia
>
>  
>  ToonTalk - Wikipedia, the free encyclopedia
> ToonTalk is a computer programming system intended to be programmed by children. The "Toon" part stands for cartoon. The system's presentation is in the form of animated characters, including robots that can be trained by example. It is one of the few successful implementations ou...  
> View on en.wikipedia.org Preview by Yahoo  
>
> Or this:Computer scientists ask "What is ToonTalk?"
>  
>  Computer scientists ask "What is ToonTalk?"
> The Computer Science behind
> ToonTalk ToonTalk is an interpreter for a concurrent constraint
> programming language.   
> View on www.toontalk.com Preview by Yahoo  
>
> Best,
>
> Thomas
>
>
>
> On Monday, June 16, 2014 2:47 PM, Fred Hebert <mononcqc@REDACTED> wrote:
>  
>
>>
>>
>>There's a lot to discuss in this thread (and Joe's one last week). This
>>is a bit of a rambling from me, but yeah. 
>>
>>On 06/16, Torben Hoffmann wrote:
>>> Why is Erlang HardToLearn?
>>> 
>>
>>We should ask newcomers. When I started, Erlang was hard to learn for
>>specific reasons: terminology, availability of information (we had the
>>series of blog posts about an Erlang bank in OTP and the trapexit
>>cookbooks, and that was most of it if you didn't feel like paying for a
>>book)
>>
>>Since I've learned the language, the context changed in massive ways.
>>LYSE is available, Cowboy has gained docs, Chicagoboss has a manual,
>>more books have come around, more tutorials have been published, more
>>talks have been made available.
>>
>>The problem isn't solved, but as a community, we shifted it to a new
>>different area. Newcomers will have had the difficult pressure point
>>somewhere else, and newcomers should therefore be able to tell us what
>>*they* found hard, without having more experienced people contradicting
>>them on many points -- We learned at a different time in a different
>>context.
>>
>>We should ask people who have quit learning the language. Sometimes we
>>will disagree, sometimes it will be due to their background of areas of
>>interest, but there is a lot to for us to learn there.
>>
>>We should ask people who don't feel like learning it. We have pieces of
>>data, such as people not liking the documentation, but we don't know
>>*why* that is. Fixing the doc without fixing what's wrong is a bad idea,
>>the same way premature optimization is.
>>
>>
>>>   how to think like an Erlanger.
>>> 
>>> 
>>> I think that a learning resource focused on teaching people the Erlang model from the
>>> ground up would be a great improvement. A clear narrative around how do we solve a
>>> problem the Erlang way. Teaching the basic constructs is not the problem.
>>> 
>>
>>Architecture is a definitive place where that needs to happen. I
>>remember fumbling around wondering "but what do I make a process?" --
>>not sure if it's still an issue.
>>
>>I remember (and still often encounter) the issue of algorithms and
>>datastructure. Everything you've learned before tends to assume O(1)
>>access to mutable memory and it's no longer true. But then again, the
>>relevance of this depends who you want to teach to. People who already
>>program, or people who don't program yet.
>>
>>> My initial target for such a learning resources would be young people in the higher
>>> grades of elementary school, say 12-15 years. Why? Because I want to influence them
>>> before their minds are totally corrupted by other programming models.
>>> 
>>
>>Ah, so you want to be the first one to corrupt their minds, then!
>>
>>Snark aside, if we want to teach children, we should reach out to
>>organisms such as https://www.codeclub.org.uk/ (who do this *every
>>day*). We should look at what it is they do, ask them, see what they
>>recommend, and tell us what wouldn't work.
>>
>>We can also look at How To Design Programs
>>(http://www.ccs.neu.edu/home/matthias/HtDP2e/), a book and site designed
>>to teach programming to new people. They show you how to animate rocket
>>ships in the first chapter. Erlang books (mine included) tell you what
>>an atom is and why you should care. That's okay, they're not meant for
>>newcomers.
>>
>>Or we can try reinventing the wheel based on what we feel is really
>>important, but what we feel is really important likely doesn't overlap
>>super well to what is important to a teenager. There are people who
>>dedicate their lives to working on that problem, they're the ones from
>>whom we should be looking for for guidance.
>>
>>Many of us know Erlang, but few of us know how to teach. A lot of us
>>have forgotten what it is like to not know how to program.
>>
>>> 
>>> What is better about Elixir from a learning standpoint is, in my highly subjective
>>> opinion, that you can get started quite easily with the mix tool.
>>> 
>>
>>If we want to reach out to crowds who aren't familiar with programming
>>at all, mix isn't gonna cut it either. Look at Scratch
>>(http://scratch.mit.edu/), look at Logo, look at Racket's graphical
>>language (http://docs.racket-lang.org/teachpack/2htdpimage-guide.html),
>>look at Arduino's documentation
>>(http://arduino.cc/en/Tutorial/HomePage). You've mentioned elm, which
>>looks like it has another great intro.
>>
>>We have a long way to go, whether Elixir or Erlang is being used. Most
>>people still put Erlang's sweet spot into the 'server' area in Garrett's
>>data. Do we have to make the person we're gonna teach to care about
>>servers to have teaching Erlang worth their time? Because it looks like
>>otherwise, we might as well teach them a language more adapted to what
>>they care about, not one adapted to what we care about.
>>
>>If we plan on reaching out to the already-programmign crowd, then yes, a
>>tool like Mix is useful. It would also be useful within Erlang for its
>>community. Rebar templates aren't even that far from allowing a lot of
>>that functionality, but the community hasn't banded together to do it.
>>
>>There are probably deep-rooted reasons for it -- many of us adopted
>>Erlang when you managed dependencies by downloading them and checking
>>them in your repo, used makefiles all the time, and whatnot. The stuff
>>rebar or erlang.mk do is already convenient enough for a lot of us to
>>have felt the pain eased away, at least to the extent where we're not
>>compelled to help fix the problem anymore. The workarounds are nicer
>>than what we had before, so workarounds it will be. Forever.
>>
>>The same is true for the documentation. They're mostly reference manuals,
>>which by definition are to be used as a reference -- it is expected you
>>know their content and are only looking up additional information, or
>>data to help you recall what you already learned. They won't be good to
>>learn (the tutorials are nicer, but who knows about them?), and none of
>>the regulars will have any incentive to fix it.
>>
>>Anyway, that's a long rant enough.
>>
>>Regards,
>>Fred.
>>
>>_______________________________________________
>>erlang-questions mailing list
>>erlang-questions@REDACTED
>>http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>>_______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-- 
Torben Hoffmann
CTO
Erlang Solutions Ltd.
Tel: +45 25 14 05 38
http://www.erlang-solutions.com