Does Elixir make other languages obsolete?

Yes I agree semi colons and brackets are old school. About Scala is also old language some kind bridge between Java and Haskell. I suppose the purpose for Scala is to guide OOP java programmers to FP.

There is also interesting topic static vs dynamic languages and modern static languages The End of Dynamic Languages.

4 Likes

But our beloved Elixir is a dynamic language :open_mouth:

1 Like

Indeed itā€™s not! Every variable has a certain type, and you canā€™t change it, never!

2 Likes

Guess it depends on your interpretation - but Iā€™d think that not having to specify the type makes it dynamic?

Edit: from the Elixir Lang site:

Elixir is a dynamically typed language, so all types in Elixir are inferred by the runtime. Nonetheless, Elixir comes with typespecs, which are a notation used for:

  • declaring custom data types;
  • declaring typed function signatures (specifications).

Yeah, I just took a look again at the definition, and you are right, Elixir is dynamically typed. Iā€™m wondering with what I have confused it hereā€¦

2 Likes

Were you thinking about immutability?

1 Like

Nope, it was a typing thingā€¦

1 Like

Possibly weakly typed vs strongly typed? As far as I can tell, those terms donā€™t have rigid definitions, but though dynamic, elixir does seem to be pretty strongly typed.

2 Likes

Reading about that, it seems to be that.

1 Like

About languages https://dzone.com/articles/should-your-static-go-static. Elixir should fit place next to Erlang.

1 Like

No language is ever obsolete.

All art is defined by itā€™s constraints.
Silent film doesnā€™t become bad film once sound is added.
Itā€™s just that the rules by which one judges it shifts to encompass a broader palette and understanding.
When part of the palette isnā€™t there, the art is in how you achieve relatable goals with different grammars.

Itā€™s still a useful post and insight, but binary doesnā€™t become obsolete when you have hexidecimal, or vice versa,

They inform one another.

5 Likes

I enjoyed your point of view. I think itā€™s an interesting debate if a programming language/programming/software development can be considered an art or not.

I consider it a craft, at least.

4 Likes

Another interesting article Static vs. Dynamic Functional Languages

2 Likes

Where is soundcloud using Crystal?

You were confusing dynamic typing with strong typing. Elixir is a Strong, Dynamic typed language. Contrast that with something like ML or Swift which are Strong, Staticly typed languages, and C/C++ which are Weak, Staticly typed languages. I canā€™t think of a weak, dynamically typed language.

You should not think of them but:

  • php
  • javascript

are used quite a lot

I guess thatā€™s true isnā€™t it :slight_smile:

ā€œUncaught TypeError: undefined is not a functionā€

1 Like

I think it was mentioned in this talkā€¦

This lib is a good example of Elixir and Rust working together and the author explains why quite well https://github.com/Anonyfox/elixir-scrape#future-development

Just like many others also expressed in this topic, I do not think any language will make any other language obsolete, besides possibly earlier versions of that same language, simply because all languages have different goals, and therefore different good/bad qualities.

Because the ā€˜goodnessā€™ of languages is a partially ordered set, and not a fully ordered set, there cannot exist such a notion of deprecation.


As for the strong vs. weak typing: Strong/weak are not very useful terms to use, since they are rather ambiguous and are used with different meanings in different contexts.

The difference between strict and dynamic typing is very clear, of course: (The enforcing of) dynamic typing happens during execution, while static typing is enforced at compilation time. The advantage of the former is some kind of flexibility (for better or worse, depending who you ask) while the latter allows for more security on shipping something that contains less faults.

These two groups however both have their own subcategories. Languages like Ruby and Python are duck typed, which means that they accept nearly everything, as long as the receiver knows about the names the caller expects. There is no check to see if the answer makes sense for the caller, however (other than the checks you write yourself).

Languages like Assembly and FORTH are basically untyped: It is completely up to the programmer to make sure that nothing goes wrong, and if something does, the program might crash very violently.

Languages like C, Java, C#, C++ etc. are partially strictly typed, in that there are many things that are impossible to express in their typing language. Also, these languages do not do type inference, which means that you will always need to supply the expected types yourself to function calls. This makes the working with types more of a hassle than a feature, because it makes it harder to switch what implementation of some protocol you are using.

Languages like Elixir, Erlang and Prolog are structurally typed. This means that it is possible to re-use a variable name multiple times in a pattern match (it willl match if these two locations are indeed structurally the same):

def foo(a, a), do: "Both arguments are the same"
def foo(_a, _b), do: "Arguments are different"

But in e.g. Haskell this is not allowed

foo a a = "Both Arguments are the same" -- Compile time error!

Instead we need to use a guard:

foo a b | a == b = "Both Arguments are the same"
            | otherwise = "Arguments are different"

Languages like ML, Haskell and Rust are statically typed and do have type inference, meaning that you can, in nearly all cases, leave the specific type signatures out, making it easy to refactor code in the future.

Then there are languages like Idris and Ada, that are dependently typed. This means that types are data structures and data structures are types. It means that your types might depend on properties of their values, meaning that you can give a lot of guarantees at compile-time. The drawback is that it takes a lot of extra understanding to know how to properly write a proof that something is allowed (ā€˜Yes Idris, this list really is not emptyā€™), and therefore has a high learning curve.

Note that I have only talked about the different typing systems, without going into detail of subtyping (contemporary OOP) vs. Supertyping (functional Type Classes), or other properties that make these languages different.


Every language has their own advantages and disadvantages.

In my dream world, people would use languages like Haskell a lot more. However, because it has quite a high learning curve, this is not very realistic. There are many more problems (i.e. building websites or simple web apps) in which less strong languages might increase developer efficiency (and face it, developer availability).

There are many languages/tools, and when a new language/tool pops up and it solves a certain set of problems in a nice way, some developers will switch to this new language/tool to solve those kinds of problems. That does not at all mean that all problems are solved better by this new language/tool. Instead, it only means that developers have more tools to pick from to solve their problems.

If we slice the pie in more pieces, it does not mean that there is suddenly less pie, nor does it mean that languages suddenly do not get any pie anymore.

4 Likes