8 ms·

It's very hard to market a system when the first (and often last) comment on it is inevitably about the syntax, which isn't going to change after 25 years or so

It's very hard to market a system when the first (and often last) comment on it is inevitably about the syntax, which isn't going to change after 25 years or so, let's be honest, no matter unimportant it may be in the long run.

davidw 12y ago
It certainly doesn't make things easier, but it's not impossible. Python has done pretty well, despite tons of people foaming at the mouth about "the white space issue". Maybe it could have done better without that, but I think it's been a very successful language, all things considered. Think about some of the articles from people like patio11, and what kind of ideas they might apply were they trying to sell something like Erlang.
- mononcqc 12y ago
  Frankly, at this point I'd be happy to hear new opinions on it. What comes from us within the Erlang community seems to often be a repeat of itself. - Killer apps? done (Riak, CouchDB, RabbitMQ, Whatsapp, etc.) - Commercial use? done (Telcos, game companies, and so on) - Books? Done, 4-5 of them, getting more and more specialized even. - Static Type system? Well you can use Dialyzer and get some of it. The last things that seem to come up all the time are about documentation, the syntax, possibly renaming OTP (do people really get bogged down so much on an acronym?), and package management. There's no doubt to me a lot of work needs to be done regarding package management, but all previous attempts within the community more or less failed to bring something consistent, and we have rebar instead, with people fetching sources from git repositories and building them locally without always having proper versionning (and conflict resolution). Outside of this, there's little doubt in my mind that the unfamiliarity is the big issue, along with how hard it is to think in Erlang: nothing shared, immutable, with a Prolog look. Outside of all the rest, this is what I feel is the hardest, and fixing it means "don't be Erlang" (because books and whatnot seem to have a limited effect), which well, won't work as a solution for Erlang.
  - riquito 12y ago
    Well, personally I'd like to have some kind of namespace and do not have to prepend a personal string in front of every module I write (correct me if I'm wrong, I'm a newbie in Erlang). Until a little while ago the website http://www.erlang.org http://www.erlang.org looked old from any angle (I like the new design), but the documentation at http://www.erlang.org/doc/ http://www.erlang.org/doc/ feels really ancient. I know that the content is up-to-date, but at a first visit it seems like the documentation of a language that is not maintained (which is false). I think that when people start to learn something they want to either fill that they're learning something futuristic or that they're learning to build on the shoulders of giants; that page transmit me that the world has moved on and nobody cared to update the page. Erlang just needs better marketing.
    - mononcqc 12y ago
      For namespacing, Erlang used to have packages to provide something a bit like that: http://www.erlang.se/publications/packages.html http://www.erlang.se/publications/packages.html They ended up being rarely used, and were eventually stripped out of the system as they ended up confusing regulars more than anything. The issue with trying to add namespacing to Erlang is that people think of namespacing modules, but they forget about the other global namespaces: process names, ETS table names, and so on. They'd need to be done all at once, or otherwise they risk giving you inconsistent results. For example say I namespace myapp.mymodule.erl, and inside of this I contact the process named 'mymodule' and the table also named 'mymodule'. If I'm not careful and pass that name around, will it still refer to a global namespace (which can clash), or will it now refer to a different process and table in another namespace? Fixing this requires changing a lot about the language, I think, and it's probably a far bigger challenge than it looks. For documentation: there's http://www.erlang.org/erldoc http://www.erlang.org/erldoc that's a searchable one, and http://erldocs.com/ http://erldocs.com/ that provides more modern design to the reference manuals. Erlang may need better marketing, but as a person from the community, I'd like to hear what I could do. "Just do it better" is hard to build on, I guess. It's reminiscent of "make the logo pop more" for designers.
      - 12y ago
mseri 12y ago
There is Elixir [0], with its elegant Ruby-like syntax if that's the issue. [0]: http://www.elixir-lang.org http://www.elixir-lang.org
- mononcqc 12y ago
  That's not marketing Erlang, that's marketing Elixir, though. On another note, I disagree with calling the Elixir syntax elegant, but that's purely a matter of taste at this point.
  - zaphar 12y ago
    Thats not completely accurate. When people talk about Erlang they are talking about two different things at the same time. 1. Erlang the functional language with a syntax inspired by prolog. 2. OTP and the Erlang Runtime. The first one is an annoyance you grow to tolerate and sometimes even love. The second one makes you a fan the first time you actually need fault tolerance. Elixer gives you the second one and arguably improves on the issues with the first one. All of which to say "Its more nuanced than you seem to want to make it".
    - mononcqc 12y ago
      The distinction between language and runtime is right. I would disagree that Elixir improves issues of Erlang. I see it as plainly different, not a newer, better language on the Erlang VM. It does have the benefit of avoiding a few mistakes Erlang made (order of arguments in the standard library, for example), but for the vast majority of the time I spend developing in Erlang, that's a very minor part of it. The design objectives and decisions of the languages, the general tooling given (i.e. macros), and the approach the community takes to development has a much greater impact into how systems are shaped and built than the actual objective improvements they have done past Erlang mistakes that are the results of 25 years of existence, sealed in place through backwards compatibility promises. These are often not improvements, just a different way of doing it, and whether it's better or not will absolutely depend on the task at hand.
lostcolony 12y ago
And not to resume those arguments, but it's a red herring. Erlang benefits from having unfamiliar syntax. You end up learning the new paradigm as you learn the new syntax; it's too easy to shoehorn the old paradigm in if it's the old syntax ("I can write FORTRAN in any language").
gbhn 12y ago
I don't understand defenses of programming languages which seem to assume that syntax isn't a central issue. Syntax is the central issue of a programming language -- they all have very similar capabilities, in the end (thanks Alan Turing), and the core of a language is in how those capabilities are expressed in the syntax. If most people find the syntax any of {awkward, intimidating, unreadable, inscrutable, undesirable} then they won't use it unless they have to. This means programming languages are path-dependent. Perhaps in a different world, lisp-type syntax is how people think about programming. Or maybe in a different world Haskell syntax is the norm. But we live in this world, and in this world, such syntax is pretty much all of the above. This makes it harder for people to read and understand programs written in those languages. Since that's ultimately the central point of a programming language -- to make programs readable to human beings -- syntax is the primary thing on which languages are evaluated. Obviously there are other factors like available libraries, tools, platform support, and so forth, but syntax is an extremely important pillar.
- mononcqc 12y ago
  Semantics is the central issue of programming languages, not syntax. The syntax defines the form of a valid program, but gives no information about what it means. Semantics define what the execution of that program would be. For example, 'X = X+1' can be valid by the syntax of two languages, except one of them (say Erlang), will fail to do the pattern matching defined under operator '=', whereas the other will do an assignment where 'X' is now worth its former value plus one. There is a lot more meaning and deeper implications to defining what 'x = x+1' means than defining how to write it. Another example can be '1 + 3 * 5': this is an addition and a multiplication, but what's the operator precedence? In smalltalk, it would be '(1 + 3) * 5'. In forth it has another entirely different meaning. You can think of it this way: Erlang the language can have a mostly-equivalent semantic set of operations in LFE, which is a lisp. It could have had semantic equivalence with Elixir's syntax, but it didn't (because Elixir made different decisions with re-binding and whatnot). Even if Erlang had Elixir's syntax, it doesn't mean you'd have to stop caring about: pattern matching, recursion, shared-nothing, etc. Syntax is important, but it's not nearly as important or challenging as semantics are.
- rdtsc 12y ago
iopq 12y ago
C syntax is awful. So much crap just to call a function. a(b, c); in some languages it's just a b c (Haskell)
- pessimizer 12y ago
  Blasphemy! Languages can only be criticized for not looking like C, and if they actually are C, they can only be criticized for using pointers and allowing memory management. Downvoted to oblivion.
- oscargrouch 12y ago
  if i see: a b c 1 2 3 g a b what is that? sudoku? complete the phrase? too little syntax.. it doesnt say what it does.. besides f(x) is is math for centuries ;)
  - iopq 12y ago
    a(b)(c) which is then curried to a(b, c) if a is a function that takes two arguments (1)(2)(3) since they are literals it's probably an argument list to a function, but not valid by itself g(a)(b) etc. remember, in Haskell pretty much everything is a function
NDizzle 12y ago
I kind of like the syntax. I've been trying to learn erlang this year. When I put on my "erlang hat" - I think it's kind of like Bo Jackson leaving the baseball field and preparing to play football. It's just wildly different than the (shitty web stuff, mostly) things I've used in the past. I just hope I don't dislocate a thigh.
- saraid216 12y ago
  > I just hope I don't dislocate a thigh. Eh. Let it crash.
regularfry 12y ago
It's also hard to market a system which introduces the New Shiny very slowly. How long did it take to get maps in, for instance? I mean, I totally understand, and to a large extent approve of, their conservatism, but "this ecosystem is boring in a good way" is a hard sell to a generation brought up on 15 minute blog videos.
- ryanobjc 12y ago
  Also "the ecosystem is boring in a good way" doesnt fly when... well... strings.
  - klibertp 12y ago
    Stop that. IO List and Binaries (look at Elixir, also Cowboy and pretty much every optimized piece of Erlang code) solved this problem quite some time ago. Yeah, more syntactic sugar would be nice, but then - unlike many other languages - you can just write a parse transform and be done with it.
    - davidw 12y ago
      Strings are not a 'solved problem' in Erlang. Also "just write a parse transform" is not really encouraged very much because it'll make your code hard to read and maintain, something which is valued in Erlang land more than some super-tricky piece of really clever coding.

davidw 12y ago

It certainly doesn't make things easier, but it's not impossible. Python has done pretty well, despite tons of people foaming at the mouth about "the white space issue". Maybe it could have done better without that, but I think it's been a very successful language, all things considered. Think about some of the articles from people like patio11, and what kind of ideas they might apply were they trying to sell something like Erlang.

mononcqc 12y ago
Frankly, at this point I'd be happy to hear new opinions on it. What comes from us within the Erlang community seems to often be a repeat of itself. - Killer apps? done (Riak, CouchDB, RabbitMQ, Whatsapp, etc.) - Commercial use? done (Telcos, game companies, and so on) - Books? Done, 4-5 of them, getting more and more specialized even. - Static Type system? Well you can use Dialyzer and get some of it. The last things that seem to come up all the time are about documentation, the syntax, possibly renaming OTP (do people really get bogged down so much on an acronym?), and package management. There's no doubt to me a lot of work needs to be done regarding package management, but all previous attempts within the community more or less failed to bring something consistent, and we have rebar instead, with people fetching sources from git repositories and building them locally without always having proper versionning (and conflict resolution). Outside of this, there's little doubt in my mind that the unfamiliarity is the big issue, along with how hard it is to think in Erlang: nothing shared, immutable, with a Prolog look. Outside of all the rest, this is what I feel is the hardest, and fixing it means "don't be Erlang" (because books and whatnot seem to have a limited effect), which well, won't work as a solution for Erlang.
- riquito 12y ago
  Well, personally I'd like to have some kind of namespace and do not have to prepend a personal string in front of every module I write (correct me if I'm wrong, I'm a newbie in Erlang). Until a little while ago the website http://www.erlang.org http://www.erlang.org looked old from any angle (I like the new design), but the documentation at http://www.erlang.org/doc/ http://www.erlang.org/doc/ feels really ancient. I know that the content is up-to-date, but at a first visit it seems like the documentation of a language that is not maintained (which is false). I think that when people start to learn something they want to either fill that they're learning something futuristic or that they're learning to build on the shoulders of giants; that page transmit me that the world has moved on and nobody cared to update the page. Erlang just needs better marketing.
  - mononcqc 12y ago
    For namespacing, Erlang used to have packages to provide something a bit like that: http://www.erlang.se/publications/packages.html http://www.erlang.se/publications/packages.html They ended up being rarely used, and were eventually stripped out of the system as they ended up confusing regulars more than anything. The issue with trying to add namespacing to Erlang is that people think of namespacing modules, but they forget about the other global namespaces: process names, ETS table names, and so on. They'd need to be done all at once, or otherwise they risk giving you inconsistent results. For example say I namespace myapp.mymodule.erl, and inside of this I contact the process named 'mymodule' and the table also named 'mymodule'. If I'm not careful and pass that name around, will it still refer to a global namespace (which can clash), or will it now refer to a different process and table in another namespace? Fixing this requires changing a lot about the language, I think, and it's probably a far bigger challenge than it looks. For documentation: there's http://www.erlang.org/erldoc http://www.erlang.org/erldoc that's a searchable one, and http://erldocs.com/ http://erldocs.com/ that provides more modern design to the reference manuals. Erlang may need better marketing, but as a person from the community, I'd like to hear what I could do. "Just do it better" is hard to build on, I guess. It's reminiscent of "make the logo pop more" for designers.
    - 12y ago

mseri 12y ago

There is Elixir [0], with its elegant Ruby-like syntax if that's the issue. [0]: http://www.elixir-lang.org http://www.elixir-lang.org

mononcqc 12y ago
That's not marketing Erlang, that's marketing Elixir, though. On another note, I disagree with calling the Elixir syntax elegant, but that's purely a matter of taste at this point.
- zaphar 12y ago
  Thats not completely accurate. When people talk about Erlang they are talking about two different things at the same time. 1. Erlang the functional language with a syntax inspired by prolog. 2. OTP and the Erlang Runtime. The first one is an annoyance you grow to tolerate and sometimes even love. The second one makes you a fan the first time you actually need fault tolerance. Elixer gives you the second one and arguably improves on the issues with the first one. All of which to say "Its more nuanced than you seem to want to make it".
  - mononcqc 12y ago
    The distinction between language and runtime is right. I would disagree that Elixir improves issues of Erlang. I see it as plainly different, not a newer, better language on the Erlang VM. It does have the benefit of avoiding a few mistakes Erlang made (order of arguments in the standard library, for example), but for the vast majority of the time I spend developing in Erlang, that's a very minor part of it. The design objectives and decisions of the languages, the general tooling given (i.e. macros), and the approach the community takes to development has a much greater impact into how systems are shaped and built than the actual objective improvements they have done past Erlang mistakes that are the results of 25 years of existence, sealed in place through backwards compatibility promises. These are often not improvements, just a different way of doing it, and whether it's better or not will absolutely depend on the task at hand.

lostcolony 12y ago

And not to resume those arguments, but it's a red herring. Erlang benefits from having unfamiliar syntax. You end up learning the new paradigm as you learn the new syntax; it's too easy to shoehorn the old paradigm in if it's the old syntax ("I can write FORTRAN in any language").

gbhn 12y ago

I don't understand defenses of programming languages which seem to assume that syntax isn't a central issue. Syntax is the central issue of a programming language -- they all have very similar capabilities, in the end (thanks Alan Turing), and the core of a language is in how those capabilities are expressed in the syntax. If most people find the syntax any of {awkward, intimidating, unreadable, inscrutable, undesirable} then they won't use it unless they have to. This means programming languages are path-dependent. Perhaps in a different world, lisp-type syntax is how people think about programming. Or maybe in a different world Haskell syntax is the norm. But we live in this world, and in this world, such syntax is pretty much all of the above. This makes it harder for people to read and understand programs written in those languages. Since that's ultimately the central point of a programming language -- to make programs readable to human beings -- syntax is the primary thing on which languages are evaluated. Obviously there are other factors like available libraries, tools, platform support, and so forth, but syntax is an extremely important pillar.

mononcqc 12y ago
Semantics is the central issue of programming languages, not syntax. The syntax defines the form of a valid program, but gives no information about what it means. Semantics define what the execution of that program would be. For example, 'X = X+1' can be valid by the syntax of two languages, except one of them (say Erlang), will fail to do the pattern matching defined under operator '=', whereas the other will do an assignment where 'X' is now worth its former value plus one. There is a lot more meaning and deeper implications to defining what 'x = x+1' means than defining how to write it. Another example can be '1 + 3 * 5': this is an addition and a multiplication, but what's the operator precedence? In smalltalk, it would be '(1 + 3) * 5'. In forth it has another entirely different meaning. You can think of it this way: Erlang the language can have a mostly-equivalent semantic set of operations in LFE, which is a lisp. It could have had semantic equivalence with Elixir's syntax, but it didn't (because Elixir made different decisions with re-binding and whatnot). Even if Erlang had Elixir's syntax, it doesn't mean you'd have to stop caring about: pattern matching, recursion, shared-nothing, etc. Syntax is important, but it's not nearly as important or challenging as semantics are.
rdtsc 12y ago

iopq 12y ago

C syntax is awful. So much crap just to call a function. a(b, c); in some languages it's just a b c (Haskell)

pessimizer 12y ago
Blasphemy! Languages can only be criticized for not looking like C, and if they actually are C, they can only be criticized for using pointers and allowing memory management. Downvoted to oblivion.
oscargrouch 12y ago
if i see: a b c 1 2 3 g a b what is that? sudoku? complete the phrase? too little syntax.. it doesnt say what it does.. besides f(x) is is math for centuries ;)
- iopq 12y ago
  a(b)(c) which is then curried to a(b, c) if a is a function that takes two arguments (1)(2)(3) since they are literals it's probably an argument list to a function, but not valid by itself g(a)(b) etc. remember, in Haskell pretty much everything is a function

NDizzle 12y ago

I kind of like the syntax. I've been trying to learn erlang this year. When I put on my "erlang hat" - I think it's kind of like Bo Jackson leaving the baseball field and preparing to play football. It's just wildly different than the (shitty web stuff, mostly) things I've used in the past. I just hope I don't dislocate a thigh.

saraid216 12y ago
> I just hope I don't dislocate a thigh. Eh. Let it crash.

regularfry 12y ago

It's also hard to market a system which introduces the New Shiny very slowly. How long did it take to get maps in, for instance? I mean, I totally understand, and to a large extent approve of, their conservatism, but "this ecosystem is boring in a good way" is a hard sell to a generation brought up on 15 minute blog videos.

ryanobjc 12y ago
Also "the ecosystem is boring in a good way" doesnt fly when... well... strings.
- klibertp 12y ago
  Stop that. IO List and Binaries (look at Elixir, also Cowboy and pretty much every optimized piece of Erlang code) solved this problem quite some time ago. Yeah, more syntactic sugar would be nice, but then - unlike many other languages - you can just write a parse transform and be done with it.
  - davidw 12y ago
    Strings are not a 'solved problem' in Erlang. Also "just write a parse transform" is not really encouraged very much because it'll make your code hard to read and maintain, something which is valued in Erlang land more than some super-tricky piece of really clever coding.