nox_

Cf. `try` becoming a keyword, when there are hundreds of calls to a method named `try` in Servo, one of the largest Rust projects in existence.

The inflate crate is absolutely devoid of tests and full of unsafe code though, so the foundations of all of that are quite weak.

I implemented them in R17. José doesn't dislike them but doesn't have a syntax that fits Elixir for them, given parens around arguments of a lambda are optional.

I have rarely read things that were that much wrong. Just because the code can be represented as a data structure, or just because the compiler is written in its own language, that doesn't make a language homoiconic.

Erlang is not homoiconic. Did you mean Elixir? Neither are anyway.

Metaphors make sense, that reusing of isomorphism doesn't, however you quote Greek words to justify your means.

Isomorphism was already a word before Nodejitsu abused it. Your examples are acronyms and abbreviations.

Nevermind that this concept is not even worth a name.

In which universe is polymorphism the opposite of isomorphism? Couldn't we just have said "JavaScript that runs everywhere" instead of trying to sound educated?

Replying with an attack and closing comments is definitely something a douchebag would do. Free or opensource doesn't mean you get to be irresponsible about what you release or maintain, if your project has some caveats they should be listed explicitly.

You introduced a closure there. Bindings set in if, case, receive, etc will spill in their surrounding environment. Obviously they won't spill outside closures without mutable terms, which BEAM lacks.

The bits about SSA transformation needed to be done by hand in Erlang are a bit fun, because that's considered a feature in the Erlang realm.

The scoping rules aren't the same for the very reason you dismiss as an implementation detail.

Scare quotes: http://en.wikipedia.org/wiki/Scare_quotes

You can. And even if you couldn't, what I mentioned is still different scoping rules, whether you put scare quotes or not.

Variables in Elixir can be rebound, and there are no unsafe variables at all in Elixir.

Sharing a common subset does not make them "fundamentally the same language".

Quotes don't magically let you say wrong things.

When two languages have different scoping rules, they don't have the same semantics. When two languages differ in their opinion about macros, they don't have the same semantics.

When two languages have different semantics, they are different languages.

And finally, when two languages have fundamentally different syntaxes, the idioms promoted by their creators differ, and thus problems are solved in different ways.

They are not fundamentally the same language, no.

Syntax is the least of your worries when learning a new language. Elixir isn't Ruby. Some new projects may be developed in Elixir but it will never supplant Erlang.

Hah, yeah, let's port everything for no obvious reason.

Elixir's compiler emits Erlang forms, and then relies on OTP's Erlang's compiler. It is not a direct process.

- Elixir compiles directly to Erlang byte code

No, it compiles to Erlang. Which is then compiled by the Erlang compiler.

For the terse badmatch error and such, you might be interested in Shippai:

https://github.com/nox/shippai

Why was this downvoted when it clearly shows how this article is misguided? Just because a language uses parentheses for some of its constructions doesn't mean we can call Lisp syntax.

Too bad that this isn't type checking in the traditional sense though. That's just runtime tag checking.

"Tries" is the operative word here. There is a documented history of utter incompetence in Linguist.

And what exactly is standard about this?

C++ gets often recognized as C.

The disambiguation test for C++ headers is ridiculous:

      matches << Language["C++"] if data.include?("#include <cstdint>")

There is no unicity check anymore; I just kept the first one special because some private code at GitHub seems to rely on the primary_extension property for the Gist editor. As I can't hack this (it is private), I can't remove it entirely.

Except that primary_extension does not serve any purpose.

Do you mean, a fix like https://github.com/github/linguist/pull/985?

My understanding is that primary_extension is simply used to short circuit analysis when it's unique to a language.

No, the primary_extension is only used in a gists_helper.rb file outside the Linguist repos. Note that the feature is deprecated anyway.

https://github.com/github/linguist/blob/master/lib/linguist/...

Yes, Erlang patterns are non-linear, Haskell has view patterns. Neither are more powerful than the other. They are just different.

Erlang non-linear patterns fit more with the semantics of match where an already bound name isn't shadowed, view patterns fit well into Haskell because of the ensured purity.