Monday, 20 January 2014

Erlang syntax again ... and again ... and again ...


Every once in a while there is a blogg complaining about Erlang and its syntax. To save you the trouble here are the main syntax complaints:

- The use of ';' (and ',' and '.') is strange, different and very confusing. I.e. it's not like Java.
- 'if' is very strange. I.e. it is not like Java.
- Variables must start with an uppercase letter. I.e. it is not like Java.
- The record syntax is very strange.

Actually only the record syntax is strange. Unfortunately, given Erlang and the original requirements for records it is not really possible to do better. So while many have complained, very few have accepted the challenge of coming up with something that looks better and works, and no-one has succeeded.

What I don't understand is when people want Erlang to look like XXXX, their language of choice. This idea I find very strange for many reasons:

- Unless the XXXX is Lisp it usually has a much more complex and messy syntax than Erlang. While the Erlang syntax may be different it is actually quite small, simple, regular and concise; much more so than the common choices of XXXX are.

- Usually XXXX has completely different semantics from Erlang. In most languages the syntax is (hopefully) tuned to its semantics, at least Erlang's is, so using XXXX syntax for Erlang would definitely be trying to fit a square peg in a round hole.

- A more philosophical reason is that I think if a language looks like XXXX it should behave like XXXX, not like something completely different. If it behaves differently it will just cause confusion and disappointment in the long run: "It looks like XXXX, but my XXXX code doesn't work the way it is supposed to". This is actually a valid criticism.

While I can understand people may dislike the syntax of a certain language, even I dislike some syntaxes, I don't understand people who say "I was going to learn Erlang but the syntax was so strange I quit". For me the syntax is the easiest part of learning a new language, it is really just a RTFM. At last count I have actively programmed in the following languages: Basic, Fortran, Pascal, C, Lisp, Prolog, Erlang, Lua and a number of different assembly languages. I am now teaching myself Python and Haskell. Lisp and Prolog are really groups of languages but they are so similar I class them together. I don't know whether to include Awk and Sh as well. All have different syntaxes. And I don't think I am in anyway unique in this as most programmers will find that they actually have used many languages.

My point is that the syntax is the easy part of learning a new language, just look it up in the manual. It is learning the semantics of the new language and how to use it efficiently to solve your problems which are the major difficulties. How do I structure my solution to best make use of the language and its environment? This is where major rethinks will occur. This is what takes time to learn and understand. Not in what it looks like.

Robert

P.S. Yes, I have implemented another syntax front-end for Erlang, but it is Lisp based so that is quite a natural thing to do. Lisp has such a simple and powerful syntax so how could I not do it. It is the syntaxes from other languages which are more complicated and messy.

14 comments:

  1. I have only one remark about Erlang syntax, it is about the module definition. I don't understand why we have simultaneously:
    - mandatory "-module" (& equals to the file name)
    - only one module per file

    The module tag is basically redondant info, isn't it ? Why don't we get rid of it (or keep it, and allow multiple modules per file) ?

    ReplyDelete
    Replies
    1. That was a long time ago but I seem to remember that the "-module" came first. This was part of the syntax and how you defined a module. The requirement that the module name and the file name be the same came later and is actually part of the libraries, both the compiler and the code server. The compiler saves the BEAM code in a file with the same name as the module while the code server assumes that the code in a BEAM is for a module with the same name as the file. It would be easy for the compiler to save the BEAM in a file with the same name as the module. This would need no change to the code server. What you would need to do is take away the warning/correction in emacs.

      Seeing I view them, the module definition and the file name requirements, as being different types of properties I don't think we should remove the module definition. Changing the handling of the file names I would have nothing against. It really doesn't worry me either way.

      Delete
    2. Having multiple modules per file would be relatively easy to implement:

      - First just allow them syntactically. I would add the mandatory syntax that each module in the file must end with a "-end_module." declaration except for the last module where it is optional. This would ensure backwards compatibility for todays code.

      - Modify the parser to return multiple modules. (easy)

      - Modify the compiler to work on multiple modules. It could generate multiple files, one per module, with the same name as the module, which would mean that code server will work unchanged.

      - Modify the "c(mod)." shell command. (easy)

      A more difficult question is whether you actually want to do this, and why. I have not missed it but I have not really thought about it.

      Delete
  2. I recall the syntax learning curve did exist for me with Erlang, but I like the choices that were made regarding the syntax. Erlang source code reads like English (commas, periods, semi-colons) and anyone nervous about Erlang because of syntax just needs to know that you will one day like it very much.

    ReplyDelete
  3. Exactly. for me Erlang is to other languages what German is to other natural lanor the findingsguages. I mean: the Uppercase that mean a binding.
    I like the analogy between ";" and a "or", and between the comma and an "and".
    The only thing that i dislike is the irregularity between some commands, separeted by commas, and the end of a function, with a point. It can be a problem with cut/paste but... as you say, you just need to work a little...

    I love erlang simplicity. You learn all you need to know in 10 small days


    ReplyDelete
  4. I remember long rant written by Damien Katz on Erlang syntax and how this reduced his productivity. All because he thought refactoring code was difficult because of the syntax.

    I never felt like this about Erlang syntax. I actually like it. It's concise, elegant and to me it makes perfect sense.

    ReplyDelete
  5. I have a question in my mind for several month : does prts of the Erlang syntax come from German langage? The Bindings that begin with a Cap for instance.

    ReplyDelete
    Replies
    1. No, the variable syntax came from Prolog which starts variable names with an uppercase letter. I don't know where Prolog got it from. Actually there isn't that much left of Prolog syntax apart from the variables.

      Delete
  6. One more vote for current Erlang syntax. :) I really appreciate it.

    Of course, there is - probably - room for some improvements - Elixir's pipe operators ("|>") seems like nice candidate: http://www.neo.com/2013/08/27/two-days-with-elixir

    ReplyDelete
    Replies
    1. I am generally very cautious when adding things to the/a language for mainly two reasons:

      - It is much easier to add things than to remove them, at least when the language is past the initial development stage. Same with libraries of course.

      - It is too easy to add features, each of which is useful and reasonable like pipe, but the end result can be a right mess of a collection of ad hoc features lacking a clear sense of purpose and direction. Everyone wants *their* favourite feature in. There are all too many examples of this.

      The Erlang syntax is quite reasonable in these respects. Though, yes, there are some things I wish we had done differently. Did I hear anyone say "variable scoping".

      Some smart person said that for everything you add to a language you should remove something.

      Delete
  7. Yes, anyone can learn language syntax from reading the manual. But getting used to the syntax, learning to feel comfortable with it, may be taxing for many people, esp. if they are only experienced with a couple of "mainstream" languages. The most easily approachable languages are those with some kind of familiarity. This is the reason for the huge class of C-like languages. This is the reason why languages such as Python, which reads like English, are so popular. If you don't care whether Erlang escapes from its niche or "boutique" status, that's fine. But then don't complain that it doesn't get wider recognition or popularity.

    ReplyDelete
    Replies
    1. Yes, the C-like languages may be common but I contend that the C syntax just doesn't fit languages with a markedly different semantics like Erlang. It you look at the main functional languages in use today, for example F# and Haskell, you will see that they also have a very different syntax. To fit Elang into a C-like syntax would then entail a cutting away some of the features which make Erlang, and other functional languages, so much more powerful, for example pattern matching. And that would be stupid.

      I personally have completely missed that Python reads like English. Then you must also explain why Python is getting such a spread as its syntax is definitely not C-like, not a { } in sight. I think Python is quite a nice language though I don't see it is a radical step from many other main-stream languages. Its syntax doesn't worry me even though it is different from other languages I have used. And why should it, it is just syntax?

      I still contend that the most difficult thing with learning a new different language is the semantics, not the syntax. And yes, the Erlang semantics are different, especially if you haven't looked at a functional language before, or at least seriously tried to program in a "functional style".

      Delete
  8. There is possibly lot needed to be done by the students and favorably would help students to initiate with all those possible values which one must needed to occupy.

    ReplyDelete