[erlang-questions] hobbyists, erlang, elixir (was Improve $handle_undefined_function)

[Simon St.Laurent]

Evan Miller wrote:
> I worry that Erlang is missing out on a lot of potential developer
> talent because the platform's benefits tend to be back-loaded: it's
> great for the big-scale stuff, but it can be painful for a newcomer
> just tinkering around and seeing if stuff works. A hobbyist has to be
> both extremely tenacious and perhaps delusional to stick with Erlang
> long enough to realize the platform's benefits.

I agree that there are a lot of people who could benefit from Erlang,
and who don't participate because they think it's only for huge systems.
I'm having fun, but will admit that I could get a lot of things done
faster in other languages.

Is the answer Elixir? It might be. I'm certainly considering
'translating' Introducing Erlang. I don't think a simple translation
would be hard, though I suspect I'd have to restructure a fair amount.

One way or another, it's not hard to imagine a world of people getting
Erlang's benefits if we can make it seem friendlier. There's little
reason for Erlang to be the preserve only of people who write huge systems.

Thanks,
--
Simon St.Laurent
http://simonstl.com/
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Garrett Smith]

On Tue, Jan 22, 2013 at 5:41 PM, Simon St.Laurent <simo...@simonstl.com> wrote:
> Evan Miller wrote:
>>
>> I worry that Erlang is missing out on a lot of potential developer
>> talent because the platform's benefits tend to be back-loaded: it's
>> great for the big-scale stuff, but it can be painful for a newcomer
>> just tinkering around and seeing if stuff works. A hobbyist has to be
>> both extremely tenacious and perhaps delusional to stick with Erlang
>> long enough to realize the platform's benefits.
>
> I agree that there are a lot of people who could benefit from Erlang, and
> who don't participate because they think it's only for huge systems. I'm
> having fun, but will admit that I could get a lot of things done faster in
> other languages.

"Huge system" feels abstract to me. In my experience, "systems" tend
to extend beyond a single language, VM, OS process, server -- maybe
data center.

I think Erlang is great for programming in general. It helps to
enforce -- or at least encourage adherence to -- certain principles
that are applicable anywhere:

- Side effects are the source of myriad problems and should be avoided
when possible

- Isolation (a bulwark) is the first requirement of reliability

- Fault detection and recovery (restoring to a known state) is the
second requirement of reliability

- Less code is easier to understand and maintain than more code

- State has costs that are easy to underestimate (and hiding these
costs through language features is a disservice)

These principles will help a programmer build bigger, more complex
systems -- but they apply equally well to to small, simple programs.

I've been back in "C" world lately and it looks completely different
to me after having spent a few years with Erlang (I think any
functional language would apply though):

- Throw a dart a wall of C code and chances are you'll hit something
that's *terrifyingly* bad -- the fact that some code works at all is a
result of brute force trial and error (testing?) and hacking (bug
fixing?) [1]

- Function scope seems arbitrary -- it's sometimes hard to understand
why the C programmer uses functions at all -- e.g. a single function
containing 1000 lines of code with interspersed comments would be just
as readable and maintainable

- The world of side effects in C is sobering -- between global
variables and unconstrained pointer operations (missing const, casts,
etc.) the "obviously correct" snippet of code is unicorn rare

True, that's your average C program, but my rant extends to other
languages (at least their typical use). So Python, Ruby, Java, C#,
JavaScript -- pick one -- without careful discipline, your code can
quickly devolve into a horrific mess. [2]

Erlang is no panacea -- there's some make-you-blind bad Erlang code
out there. But if you take its path of least resistance (i.e. stop
trying to make it look and act like Ruby) you get most of the
principles above without much effort. Or at least you have to work to
violate them.

> Is the answer Elixir? It might be. I'm certainly considering 'translating'
> Introducing Erlang. I don't think a simple translation would be hard,
> though I suspect I'd have to restructure a fair amount.
>
> One way or another, it's not hard to imagine a world of people getting
> Erlang's benefits if we can make it seem friendlier. There's little reason
> for Erlang to be the preserve only of people who write huge systems.

The reason I started using Erlang was a) I was curious and b) I ran
into a concurrency problem that would have cost considerably more time
and effort to solve directly in C/C++.

I don't know if the general audience of programmers will simply pick
up a new language because "it's healthy". I ought to adopt Clojure and
Haskell because they're great languages and I'd be a better programmer
for it. I haven't yet because I have a toolkit of languages (Erlang,
C, Python, bash) that will almost certainly solve anything I run into
(excluding platforms with language affinity like iOS, Android, etc.)

So if you can get by with Ruby, you use Ruby. Don't switch to Erlang,
which looks scary, just because it's web scale.

I'm almost inclined to think the real solution (assuming there's a
problem, and I do) is that instructors *teach* this stuff! Why the F
are students learning to program with *Java*? Start with Erlang -- a
simple, pragmatic, functional language -- and then introduce the
features from other languages and how to effectively manage them!

In any case -- and I'm not trying to be disagreeable, this is best
discussed over beer in a pub -- I don't think being developer friendly
or emotionally affirming or creativity enabling is a problem that
needs to be solve here.

> Thanks,

Thank you for calling this topic out!

Garrett

[1] Of course there are high quality C programs -- I just don't run
into them very often

[2] I use this term in a strictly scientific sense

[Richard O'Keefe]

On 23/01/2013, at 2:56 PM, Garrett Smith wrote:
> I'm almost inclined to think the real solution (assuming there's a
> problem, and I do) is that instructors *teach* this stuff! Why the F
> are students learning to program with *Java*

Ah, said The Man In The Corner, drawing up his chair.
Let me tell you a story.

Once upon a time (about 1992ish) in a land where the moles
have beaks and swim and the deer jump on their hind legs
(Australia), a certain computer science department (RMIT)
decided that Pascal had reached its use-by date. What shall
we do? What shall we replace it with? Set up a committee!
I was on the committee. We set up a short list.
(1) Scheme.
Tiny language, amazingly capable, REPL so you can try
things out, implementations for all the machines we
cared about. And Rob Hagan at Monash had shown that
you could teach students more COBOL with one semester
of Scheme and one semester of COBOL than you could
with three semesters of COBOL.
(2) Miranda.
The commercial precursor of Haskell.
Melbourne University were also looking at this (or had
already switched to it) which would make it easier to
pick up some of their students.
(3) Ada.
Close enough to Pascal that our staff were comfortable with
it and our material would not need major revision.
A better Pascal than Pascal.
Handled concurrency about as nicely as an imperative language can.

What was the deciding factor?

Schools.

Our deliberations leaked, and we started getting phone calls from
careers masters saying "if you go all theoretical [read: (1) or (2)]
we'll tell our pupils not to study with you."

There's no point teaching the ideal course if nobody comes,
so (1) and (2) were abandoned and Ada was chosen.

Actually, I like Ada. And that's why I was disappointed a few years
later. The cry went up
- Ada is not sexy!
- Ada has no native graphics!
(X11 bindings, yes, but you needed to read C oriented books to
learn how to use X11 and then translate that to Ada.)
- Ada does't run in your browser!
- Ada doesn't have suitable books! (I don't agree.)
- Students won't be motivated!
I was not on the committee that switched to Java.

The belief was that if students couldn't make flashy graphicy
things in their web browsers -- this being a time when HotJava
was still around -- they would fall away and what's the good
of teaching the >right< stuff to an empty classroom?

The department I'm in now went straight from Pascal to Java; it was
not so much that we abandoned Pascal as that it abandoned us.
There were plenty of Java books to choose from, ranging from bad
to very bad, but that's Sturgeon's Revelation for you.

One problem is that Computer Science departments simply do not have
the time to teach everything they need to teach. Students want to
leave in 3 years with qualifications an employer will like, and
employers want 'practical' languages in CVs. I have a colleague
who cannot spell because he was taught to read using the Initial
Teaching Alphabet, so I'm less convinced about the educational
benefits of neat languages than I used to be.

[James Rosenblum]

For what its worth, in the mid 80's, my University's Computer Science program required every student to take a year-long course called Structure and Interpretation of Computer Programs. It was the *first* class any CS major took, and it was taught exclusively in Scheme. As far as I know they continue this practice.

I have been grateful for that experience ever since and have wished that the young-guns coming into my organizations had had a similar experience - so often their experiences and thinking has been locked into an "OO - Java (or C#) - hey JavaScript is Functional - Apache" mind-set. There is nothing wrong with this, per se, (and many of them are super talented), but I feel like I had a real advantage by my first experience being what it was. I have since learned and used a number of languages in academic and industry settings (Clipper, C, C++, Erlang, Pascal, SmallTalk, Visual Basic, etc.), but I continue to be served by that first-class.

I am convinced of the educational benefits of a functional language that better allows one to think about the nature of a problem to be solved and the structure of a solution as opposed to wrestling with the language

... now that was probably worth $.02 

---

From: Richard O'Keefe <o...@cs.otago.ac.nz>
To: Garrett Smith <g...@rre.tt>
Cc: erlang-q...@erlang.org
Sent: Tuesday, January 22, 2013 11:44 PM
Subject: Re: [erlang-questions] hobbyists, erlang, elixir (was Improve $handle_undefined_function)

[Simon St.Laurent]

On 1/23/13 9:29 AM, James Rosenblum wrote:
> I am convinced of the educational benefits of a functional language that
> better allows one to think about the nature of a problem to be solved
> and the structure of a solution as opposed to wrestling with the language

I never took CS, and my perspective is utterly biased toward independent
learners - aka the hobbyists of the subject line.

I think, though, that Erlang works well for this in that context as well
as in a more formal environment. Perhaps it isn't as pure as Scheme,
but it's easier to answer the key question "why" when it isn't assigned.

Writing Introducing Erlang convinced me that much of programming would
be easier if more people started with functional languages. It's not
actually that much more difficult to get started doing interesting
things, and there's a lot less time spent wandering lost in the program
trying to figure out where something broke.

As I look back on the broken way that I learned programming - through
BASIC and 6502 assembler - I see a lot of lessons I probably shouldn't
have learned. I also, though, see environments that, primitive though
they were, were set up to make interaction direct if occasionally arcane.

I was delighted to find Erlang's shell, which made using this compiled
language much friendlier. I was amazed by its remote capabilities. But
then I was bluntly disappointed by the difficulty of using it as an
environment - even a trivial environment - for interactive applications.
It became clear quickly that the beauty of my examples would have to
be abstract, because there wasn't going to be much I could show without
endless preamble to distract readers from the basics.

Erlang (or maybe it will be Elixir) has the power to be a language that
transforms computing. It has the right tools to solve common problems.

However, it may take some extra work to make it easier for people to see
that!

Thanks,
--
Simon St.Laurent
http://simonstl.com/

[Rustom Mody]

On Wed, Jan 23, 2013 at 10:14 AM, Richard O'Keefe <o...@cs.otago.ac.nz> wrote:

 

And Rob Hagan at Monash had shown that
     you could teach students more COBOL with one semester
     of Scheme and one semester of COBOL than you could
     with three semesters of COBOL.

Nice!  One of the difficulties in being a teacher is that we know:
- Yes, facts are important.
- Learning them is more important
- The learning-curve more so still.

In established disciplines like music-education this is a commonplace.
If we challenge the student too little, they lose interest; too much and wrong habits get fostered and set.

One problem is that Computer Science departments simply do not have
the time to teach everything they need to teach.  Students want to
leave in 3 years with qualifications an employer will like, and
employers want 'practical' languages in CVs.  I have a colleague
who cannot spell because he was taught to read using the Initial
Teaching Alphabet, so I'm less convinced about the educational
benefits of neat languages than I used to be.

The problem in CS is that we do not agree (or even know) what is easy, what is hard and how to calibrate from easy to hard. How many established teachers know that concurrency can be easier than it is in C/Java?

In this respect I maintain a list of traditional CS-edu-mistakes at
http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-1.html
and
http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-2.html

On the other hand I should mention that I just finished teaching a course on erlang.
I found it very hard.  I simply assumed that it is because I am too much of a noob to really 'get' it yet. [When one has taught programming for 25 years, its funny how often one hears a beginning student protest: "The compiler has a BUG!"]

However after seeing Simon's comments below, I feel a little mollified that perhaps I am a fool but not an utter fool :-)

On Wed, Jan 23, 2013 at 9:06 PM, Simon St.Laurent <simo...@simonstl.com> wrote:

I was delighted to find Erlang's shell, which made using this compiled language much friendlier.  I was amazed by its remote capabilities.  But then I was bluntly disappointed by the difficulty of using it as an environment - even a trivial environment - for interactive applications.  It became clear quickly that the beauty of my examples would have to be abstract, because there wasn't going to be much I could show without endless preamble to distract readers from the basics.

Erlang (or maybe it will be Elixir) has the power to be a language that transforms computing.  It has the right tools to solve common problems.

However, it may take some extra work to make it easier for people to see that!

[Joe Armstrong]

Old timer here ...

When I learnt programming (1967) ,
I could choose between FORTRAN and (it was rumoured, Algol)
but nobody knew anything about Algol so it was FORTRAN.

The turn round time for a program was three weeks
  
    week 1 - write code on paper forms - send to computer center to be turned into punched cards
    week 2 - review punched cards, if ok send to machine
    week 3 - results

The compiler helpfully stopped at the first syntax error which got you back to week 1 -
so if you had say ten errors in your program it would take 30 weeks to get it running.

This is a pretty good environment - teaches you not to make mistakes and to think first.

By about 1970 I was at university and turn round times were down to 4 hours
and you could punch your own cards - it was still FORTRAN

By 1974 I got access to a computer -- a honywell DDP516 - with a colossal 32 KB memory.
So the 474 pass FORTRAN compiler could compile a hundred line program in less than a week
(or so ...)

Things improved - I went to CERN and used the CRAY1 this could compile 100K lines of
FORTRAN in 1 picosecond (ie about a zillion times slower than my mobile phone today)

Still Fortran.

In 1974 (ish) I got to play with a DEC10 - Now I could write FORTRAN, Basic, assembler
and it had time-sharing (wow) turn round times of seconds. If I'd been In the USA I'd be Bill Gates,
but this was Edinburgh.

In 1976 I got a job programming a NORD10 in FORTRAN/Assembler and it was really fast
turn round times of seconds.

In 1980 ish I was still programming in FORTRAN - I forget the name of the machine
all files were in one directory, no full-screen editor, no revision control system,
I wrote about 150K lines of FORTRAN for it.

1985 I joined Ericsson - wow a VAX11/750 - new languages to learn. Bye bye FORTRAN

I learnt (with various degrees of proficiency) Lisp, Prolog, awk, bash, smalltalk, TCL,
and became proficient in Prolog (aggghhh - the beauty ....)

I also played with just about any language I could get my hands on (ML, forth, ...)

Then I (1986) got into my Erlang Phase (I couldn't really learn Erlang, 'cos it didn't exist,
so I invented it) - it was really an outgrowth of Prolog+Smalltalk with a bit of error recovery
concurrency and distribution throw in.

Then I learnt (badly) C - But Mike Williams said my C was crap and looked like Fortran so he
binned my C ... (why use malloc and free and pointers anyway ...)

I saw C++ coming and read the book - or at least tried to read the book - there's a dent
in the wall behind my piano, where the book hit the wall - Improvements to C should make things
easier not more complicated, I thought.

Time passed.

I tried Java (not impressed, ok it's better than C++, but oh so verbose, I used to get
programmers "white fingers" when programming FORTRAN you have to write hundreds of lines
to do the smallest thing - Java seemed similar - so verbose) - I also (later) tried
Python (ok), Ruby (ok), Lua(better), Javascript(I like :-)

It's actually taken me quite a long time to learn all these languages, and they didn't
all come at once. I had a good 15 years of FORTRAN - long enough to get good at it,
10 years of Prolog, 20 years of Erlang etc.

I also had a long time to assimilate the new ideas - the ideas in programming come pretty slowly
- once every twenty years or so somebody has a really good idea,  programming
today hasn't improved much in the last 20 years - it was mess then and it's still a mess.

IDE's and revision control systems have just made matters worse - now you have all the
old versions of the mess as well as the mess itself, and the IDE means you can't even see the mess.

The best IDE in the world is your BRAIN - it's a zillion times better than these
clicky things.

What's this got to do with education?

Suppose you're starting off.

You can choose between twenty odd languages (all of them good for one reason or another)
what took me 40 years to learn, you must try to understand in 2-3 years, this is just not possible.

What languages should a beginner learn, what languages should a school teach?

Now we get to the paradox of choice - because there are so many alternatives it becomes
impossible to choose.

Old timers say "choose the language appropriate to the problem" when you know 20 odd
languages (with varying degrees of proficiency) this is easy to say - but If you know
two languages Java and C then this isn't much help.

There are literally problems where the solution in a CLP language is a few lines
and is thousands of lines in C.

What would I recommend learning?

    - C
    - Prolog
    - Erlang (I'm biased)
    - Smalltalk
    - Javascript
    - Hakell / ML /OCaml
    - LISP/Scheme/Clojure

A couple of years should be enough (PER LANGUAGE).

Notice there is no quick fix here - if you want a quick fix go buy "learn PHP in ten minutes"
and spend the next twenty years googling for "how do I compute the length of a string"

The crazy think is we still are extremely bad at fitting things together - still the best
way of fitting things together is the unix pipe

    find ... | grep | uniq | sort | ...

and the *fundamental* reason for this is that components should be separated
by well-defined protocols in a universal intermediate language.

Fitting things together by message passing is the way to go - this is basis of
OO programming - but done badly in most programming languages.

If ALL applications in the world were interfaced by (say) sockets + lisp S expressions
and had the semantics of the protocol written down in a formal notation - then we could
reuse things (more) easily.

Today there is an unhealthy concentration on language and efficiency and NOT on how things fit together and protocols - teach protocols and not languages.

And teach ALGORITHMS.

Cheers

/Joe

(The dates in the above are approximate)