<story><title>Donald Knuth used an Erlang-like notation</title><url>http://videlalvaro.github.io/2016/10/knuth-first-erlang-programmer.html</url></story><parent_chain><item><author>pmontra</author><text>To the eye of a developer used to more modern languages that also shows some bad choices in the design of the Erlang syntax. Basically everything that makes the source code less readable than the original: uppercased variables, the minuses that prefix the module and export statements, the wierd =:= operator. I add the also wierd &amp;lt;&amp;gt; binary and string concatenation operator, not used in this example.&lt;p&gt;The semicolon-period statement separators&amp;#x2F;terminators are in the original and in natural languages, but newer languages proved them to be useless. Probably compilers in the 80s needed some help by the programmer to be fast.&lt;p&gt;Elixir fixed some of the worst offenders, kept others and added something. Examples: the &amp;lt;&amp;gt; is still there but at least we can interpolate strings Ruby like, the useless do at the end of almost every defsomething declarations (the compiler should get it by itself.)&lt;p&gt;But every languages has its wierdnesses, the contest is to have the least of them.</text></item></parent_chain><comment><author>OskarS</author><text>It&amp;#x27;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 (&amp;quot;1 + 1 = 2&amp;quot; is false in prolog, while &amp;quot;1 + 1 =:= 2&amp;quot; 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.&lt;p&gt;On the other hand, it&amp;#x27;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 &amp;quot;is&amp;quot;. The differences make sense if you&amp;#x27;re deep into Prolog, and it&amp;#x27;s rich capacity for designing new operators is arguably a strength of the language, but it&amp;#x27;s clearly an obstacle to beginners.&lt;p&gt;I absolutely adore Prolog, but it&amp;#x27;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).</text></comment>
<story><title>Donald Knuth used an Erlang-like notation</title><url>http://videlalvaro.github.io/2016/10/knuth-first-erlang-programmer.html</url></story><parent_chain><item><author>pmontra</author><text>To the eye of a developer used to more modern languages that also shows some bad choices in the design of the Erlang syntax. Basically everything that makes the source code less readable than the original: uppercased variables, the minuses that prefix the module and export statements, the wierd =:= operator. I add the also wierd &amp;lt;&amp;gt; binary and string concatenation operator, not used in this example.&lt;p&gt;The semicolon-period statement separators&amp;#x2F;terminators are in the original and in natural languages, but newer languages proved them to be useless. Probably compilers in the 80s needed some help by the programmer to be fast.&lt;p&gt;Elixir fixed some of the worst offenders, kept others and added something. Examples: the &amp;lt;&amp;gt; is still there but at least we can interpolate strings Ruby like, the useless do at the end of almost every defsomething declarations (the compiler should get it by itself.)&lt;p&gt;But every languages has its wierdnesses, the contest is to have the least of them.</text></item></parent_chain><comment><author>rdtsc</author><text>&amp;gt; Basically everything that makes the source code less readable than the original: uppercased variables, the minuses that prefix the module and export statements,&lt;p&gt;Capitalized variables stand out from lower cased functions. I find that makes it easier to read than having everything lowercase. It&amp;#x27;s enforced so all the code has to follow that convention.&lt;p&gt;Semicolon at the end of a function clause indicates there is another function clause following it, that is a useful affordance when navigating code.&lt;p&gt;&amp;gt; The minuses that prefix the module and export statements&lt;p&gt;Well in natural language you use dashes to create an itemized list. Would # be better like in include statements in C&amp;#x2F;C++? Maybe the alternative is to introduce some &amp;quot;defun &amp;#x2F; fun &amp;#x2F; def &amp;#x2F; function&amp;quot; keyword to define functions and another keyword &amp;quot;directives&amp;quot;? But that is less ergonomic, I really like how function definitions don&amp;#x27;t have to start with an extra keyword and they are just function names starting on the left side of the page.&lt;p&gt;&amp;gt; the wierd =:= operator.&lt;p&gt;Yap that is a weird one. = is used for pattern matching so reusing it for equality &amp;#x2F; equivalence testing might be ambiguous.&lt;p&gt;&amp;gt; Basically everything that makes the source code less readable than the original:&lt;p&gt;The original has &amp;quot;remainder of _ divided by _&amp;quot;. That looks ok in a small example but repeating that phrase throughout the program many times is probably not the best idea.&lt;p&gt;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 &amp;quot;modern&amp;quot; language like Javascript which looks &amp;quot;familiar&amp;quot; but is not very consistent and full of gotchas (see the famous wat video on that).</text></comment>