Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think the community is open to change of the language, given that the idea you propose is a good one.

The thing that led tarcieri to write the "Erlang is a Ghetto" post was that he proposed the addition of Ruby-style blocks to the Erlang language. And then Richard O'Keefe wrote back a post—not a very diplomatic one—which explains why Ruby-style blocks is a horrendously bad idea to add to any language.

The main reason that Erlang sometimes comes along as smug is because there are some people in the community who are extremely capable in their fields of expertise. You need a good argument to convince a semanticist that your informally specified language extension is worth anything, unless you can supply meta-theorems which explains why. Or at least provide proper semantics. In other words, you need a really good design.

If you have working code for your design, it is even better. If you have an EEP (Erlang Enhancement Proposal) you may even have your idea implemented. There is, for instance, an EEP called "Named funs" which extends and generalizes tarcieris proposal. It did not go in in time for R16, but it is still being worked on.

Parameterized modules were an experiment. Like Tuple funs (now removed), packages (now removed), and mnemosyne (now removed). They still live on outside the Erlang distribution but retains enough inside to support them via parse transformations.



> Richard O'Keefe

Heh, interesting. That brings up this interaction, which I feel characterizes some of the problem:

http://erlang.org/pipermail/erlang-questions/2013-January/07...

Loïc's response to him is worth quoting:

" You are confronted with the problem of wasting a lot of time writing basement level code to access and update deep values. You think "Great! I can write DSL or combinators to solve this!". Now you got two problems, and you haven't come any closer to solving the first one. The DSL still maps to functions which needs to access and update these values, and that code is still painful to write. Your next step is to think "Great! Let's generate all that code then!". Now you got three problems, and you better hope to have not made any error when writing that code generator or you'll waste a lot more time. Speaking of time, by the time you get to that point the PHP developer has already long finished his bug-free implementation of the same code and is moving on to other tasks."




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: