Hacker News Reader

It's worth noting that Erlang gets a lot of that weirdness from its progenitor language, Prolog, where arguably some of that stuff makes more sense. For instance, the =:= operator is an equality operator that forces arithmetic evaluation, unlike = which is just used for unification. In Prolog, this is a fairly crucial difference ("1 + 1 = 2" is false in prolog, while "1 + 1 =:= 2" is true) and there needs to be language constructs that make the distinction clear. Given that, having different operators is a sensible solution to the problem.

On the other hand, it's arguably true that Prolog has an over-reliance on a massive swath of operators. All of these operators represent some variation of the concept of equality: =, ==, =:=, =@=, #=, and "is". The differences make sense if you're deep into Prolog, and it's rich capacity for designing new operators is arguably a strength of the language, but it's clearly an obstacle to beginners.

I absolutely adore Prolog, but it's a real shame that development of logical programming basically stopped with it. It would be as if functional programming never properly progressed beyond early Lisps. Its a shame that Erlang borrowed so much of its syntax, when the syntax is clearly not its strongest suit (though it fits Prolog better than Erlang).

> The differences make sense if you're deep into Prolog

They make sense academically, but they only slow down language adoption.

> Basically everything that makes the source code less readable than the original: uppercased variables, the minuses that prefix the module and export statements,

Capitalized variables stand out from lower cased functions. I find that makes it easier to read than having everything lowercase. It's enforced so all the code has to follow that convention.

Semicolon at the end of a function clause indicates there is another function clause following it, that is a useful affordance when navigating code.

> The minuses that prefix the module and export statements

Well in natural language you use dashes to create an itemized list. Would # be better like in include statements in C/C++? Maybe the alternative is to introduce some "defun / fun / def / function" keyword to define functions and another keyword "directives"? But that is less ergonomic, I really like how function definitions don't have to start with an extra keyword and they are just function names starting on the left side of the page.

> the wierd =:= operator.

Yap that is a weird one. = is used for pattern matching so reusing it for equality / equivalence testing might be ambiguous.

> Basically everything that makes the source code less readable than the original:

The original has "remainder of _ divided by _". That looks ok in a small example but repeating that phrase throughout the program many times is probably not the best idea.

Overall, after reading large code bases of Erlang, Python, C++, C#, and Java. I would put Erlang right behind Python and readability and how ergonomic it is. The most important thing about it is it is small and self-consistent. Contrast that with a "modern" language like Javascript which looks "familiar" but is not very consistent and full of gotchas (see the famous wat video on that).

One must not compare dynamic type language ergonomics with a static one - different niches ;-)

There is an interesting overlap in Haskell, Standard ML and OCaml as they do type inference. Hence they read like a dynamically typed language, but forces a strict typing discipline by deriving the types from the written code by inference.

Modern?

1990 Erlang is presented at ISS'90, which results in several new users, e.g Bellcore

Python was conceived in the late 1980s[1] and its implementation was started in December 1989

Both (and pretty much all languages other than the first ones) borrow heavily from languages that came before them.

You deem that syntax "weird" only because you're experience is with other families of languages. If we all grew up writing Prolog, we'd think the algol C-like languages looked weird.

History of Computing should be a required course for CS majors.

One thing I don't like about Elixir is the Ruby-style "optional" sytax e.g. `IO.puts "hello"` vs `IO.puts("hello")` and the whole keyword list arguments syntax sugar thing. I mean, I get it now, but it's sorta hard to read as non-Ruby beginner.

Hmm you can just use `IO.puts("hello")`

The point is some people don't, making it harder to read that code.

I am afraid the ability of people to write hard to read code is infinite. If you are using Elixir in a production project your team can set a guideline to always use () I have not looked into it but it also likely can be enforced by a linter.

>To the eye of a developer used to more modern languages

Perhaps its the eye of the developer "used to more modern languages" that has the problem?

I started in the 80s with BASIC, Pascal, C and Perl :-)

The point is that languages generally got better syntaxes along the years. Restricting ourselves to a niche, it's not that Ruby, Python and JavaScript are young (20+) but Ruby got it almost right from the beginning, Python maybe (it has more oddities but it could be a matter of tastes) and JavaScript is evolving a better syntax. Even PHP is getting more readable.

>The point is that languages generally got better syntaxes along the years.

Some of the popular languages got more sugar, but compared e.g. to Lisp are they really an improvement?

Heck, even Go is not that different than Algol-68.

Sugar somewhat matters. We could debate if it really makes us better and faster developers or if it's only an addiction. For sure I don't want to go back to Perl even if it shares the same basic programming model of Ruby. Heck, I don't even want to go back to Python, because it looks like Ruby with a bad skin disease (I'm working on two Python projects right now.) C and Java instead are substantially different beasts because of the garbage collection. I don't want to go back to manually manage memory and that's not sugar. Obviously I'd be back to malloc on those platforms where there are no alternatives. Luckily I don't work on them.

The semicolons usually help me when I'm reading code. I'm not sure if it's because of me being used to them or how my brain is wired. Probably both.

If I were designing a programming language though (no worries, not going to happen), I'd probably still omit the semicolons because I feel (got nothing concrete) that most people don't like them.

On the other hand, I'm not sure how one would objectively eliminate the redundancy without hurting readability by humans and/or machines. Curious if there's some research about this.

Even in natural language the semicolon is a weird construct: one can write perfectly well without it. The same cannot be said of the period for instance, or even the comma. And semicolon's cousin, the colon, serves a very specific purpose, which also makes it indispensable.

I personally find Erlang readable while C not so much. Maybe it has more to do what you are used to than the actual syntax.

> the useless do at the end of almost every defsomething declarations (the compiler should get it by itself.)

That's actually one of the things I personally love about Elixir relative to other Ruby-like-syntax languages (including Ruby itself). Sure, it might technically be extraneous and unnecessary, but it's a nice bit of consistency. Why shouldn't def and defmodule and what have you not be ordinary statements that take a block as an argument?

This is, in fact, consistent with the 'def foo, do: bar' shorthand format in Elixir (and related shorthands like 'if foo, do: bar, else: baz'). No need to have a bunch of different statements that can start a new scope when it's just three more characters to throw a ' do' at the beginning of each of them. Consistent and clear.