This one sentence sums up the sociological and psychological problems that retard progress in the tech industry:
"Experiments that show that Erlang is N times better than "something else" won't be believed if
N is too high."
That is exactly it. I've had those arguments where I was forced to tell a manager about another project I did for another company, a similar project where things went quickly and smoothly, using technology the manager was not familiar with. And every word I spoke was met with disbelief.
"And I hadn't even told him the truth. Actually, the shit coming out of Basco's pipes was a hundred thousand times more concentrated than was legally allowed. ... That kind of thing goes on all the time. But no matter how many diplomas are tacked to your wall, give people a figure like that and they'll pass you off as a flake. You can't get most people to believe how wildly the eco-laws get broken, but if I say "More than twice the legal limit," they get comfortably outraged."
(I'd include the previous paragraphs in the quote, to show the conversation the protagonist actually has about this, if my copy wasn't on loan to a friend right now, dammit! If anyone else can post that, that's be cool.)
Did they disbelieve it went smoothly as you described, or did they lack confidence in your conclusion that the _reason_ it went smoothly was because of the particular tools chosen?
Partial remedy: stick to easily measurable facts: number of people, budget, time to completion, number of detected bugs…
Then, when your manager inevitably does not believe you, ask him if he thinks you missed something (no), then ask him if he trusts you (yes), then contemplate the face of cognitive dissonance.
Ya, I had a manager laugh at me when I told him I had learned Erlang over the weekend (I am the resident "language lawyer", and Erlang's really not that complex). He didn't seem to be able to grok that a language could be so simple…
Languages are simple syntactically, but I'd have a hard time believing that anyone could pick up the set of idioms necessary to effectively use a new language in a few days.
Coming from a strong background of similar languages? Sorry, you're wrong there. Perhaps you aren't familiar with Erlang; it is the "everyman" of functional languages. The things I think you'd call "idioms" (not really sure what you mean as that's a very loose term), let's say recursive programming, pattern matching, carry over as-is from any number of other functional languages. Pattern matching? It's a mix of OCaml and Prolog. Terms? Imagine Scheme had tuples in addition to lists. Etc. The only "new" concept is the message system, which if you know anything about networking, is pretty straightforward.
In other words, if you know pretty much any other functional language, it's almost trivial to translate basic programs to & from into Erlang knowing little more than its syntax, which as you concede, is simple.
OTOH, if you're coming from, say, PHP, sure, learning Erlang will be difficult as first you have to understand functional programming. But you're asserting impossibility, so counter-examples are moot.
Ten Years… I've been coding over twenty years in more languages than I can count… I have a good idea how long it takes to learn a language well. Maybe I'm biased because it's the latest language I've studied, but Erlang was the first non-toy language where I skimmed the reference manual, said "huh, that was all unsurprising", and started coding effectively.
Thanks for the link, it expresses part of what I struggle to explain quite well.
One problem I have, which Norvig doesn't talk about, is that I'm currently moving from one ecosystem (Microsoft) to another (the Java world), and it's not just about the language, it's everything, all the toolchain is different and unfamiliar.
What's your definition of "picking up" a language?
A) Writing a "Hello, World"?
B) being able to fix a simple bug in a program?
C) Writing a small program that solves some domain problem
D) Writing a program that solves a "real world" problem, making use of the programming languages' strengths and conforming to standards (something that other people would let you commit into a repository unchallenged :) )
I'm certain A) takes only a few hours, and B) can be done in a day.
As Norvig says, you can do C) if you write in the new language like you would in a language you already know (not much of a problem if we're talking C# vs Java).
This roughly corresponds to my experience with Erlang; keeping in mind that "D" in Erlang relies heavily on its OTP ecosystem, which is fairly complex and different from most other languages.
Ignoring OTP, my ability to use the language proper was pretty much complete within a week, owing to its simplicity and my prior background in functional languages.
This is in contrast to C, which I have been using for around 15 years now, yet am still learning nuances of the language. (Things like: which integer operations are undefined on negative numbers; how integer promotion works with shift operators; how "restrict" interacts with scope.)
C is almost a fractal of nuance that does take years of experience to comprehend; Erlang has no nuance. (The closest thing to nuance I can think of is the relationship between integers and floats; and even then the takeaway is "it just works; don't worry about it". The only language in which I've seen the number hierarchy handled more cleanly is Racket.)
Erlang has a few syntactic conventions that will probably seem familiar only if you've used Prolog. But, like any other language syntax, you learn it pretty quickly and within itself it starts to makes sense.
This was actually the biggest syntactic stumbling block for me, but because I know Prolog. It's definitely not Prolog semantically, and differs syntactically as well (e.g. clauses are separated by "." in Prolog but ";" in Erlang); to this day I sometimes find myself writing Prolog in Erlang.
"Experiments that show that Erlang is N times better than "something else" won't be believed if N is too high."
That is exactly it. I've had those arguments where I was forced to tell a manager about another project I did for another company, a similar project where things went quickly and smoothly, using technology the manager was not familiar with. And every word I spoke was met with disbelief.