D4no0

D4no0

I think you are discussing about a feature that nowadays compilers have, full type inference. The idea is not far away from how dialyzer success typing works, but it is more constrained. I think an example is in order to make it more clear:

Example 1:

a = 30
b = add_three(a)

# This should display an error at compile-time, because the inferred type is number
List.first(b)

# This also should display an error at compile-time, because from operation number + 3 can be inferred that the parameter is a number
add_three("sad string")

fun add_three(number) do
  number + 3
end
1
Post #41
adw632

adw632

You asked for an example and I provided the closest example that exists for BEAM languages where type inferencing is strictly better than static type declarations.

@dimitarvp You’re arguing on an unfair basis and purposely missing the point.

Gleam uses type inferences to obtain strong typing which is the point I am trying to make as something similar to but not identical to what I am describing (as I also want value constraint checking).

In Gleam, type annotations or declarations are not required, the types are not static in the sense they don’t have to be statically declared by the developer and even if used, they don’t actually influence the type inferencing whatsoever, the compiler knows despite what decorations you use. The code is therefore amenable to a change in types without refactoring because it’s not an echo chamber of repeat yourself static type declarations on everything.

It is telling that you have expressed numerous times that you live in a land of refactoring hell and your reaction was one of incredulousness that refactoring was not of any consequence to me within my development.

Understand that brittleness actually emerges from static type declarations and it begets more code and a lot more code churn. Add throws onto things, async and all the type ceremony that inferior languages do and sure, life is a refactoring nightmare. I avoid these tarpits and I don’t want Elixir sliding down this slippery slope into the tar either.

I don’t think I have said it enough, as clearly it did not get through:

I do not want to be reminding the compiler what the type or value constraint is all over my code, I want strong typing and value constraint inferencing without the developer overhead or effort of manually maintained static types.

You disagree with the above it seems.

I simply want more checking than you, for much less effort and I do not want the Elixir language being ruined through well intentioned but brittle static type declarations which you seem to think is the only way.

Elixir typespecs and specs are already an eyesore and overhead that I cannot wait to be rid of with type inferencing.

0
Post #42
Nicd

Nicd

I guess it’s a problem of differing terminology but I don’t see what Gleam has to do with strong typing as it compiles to Erlang (strong typing) and JavaScript (weak typing), at least in the traditional meaning of the terms. But the type inference in Gleam is not complete and the compiler asks you to add types if it can’t deduce what you are doing.

If we look at some real Gleam code I wrote: src/glemplate/renderer.gleam · 5fae861c8649506405e88c5b79214979a20c8b85 · Mikko Ahlroth / Glemplate · GitLab

We can see that mostly the types can be left out in two cases: variable assignment and return values. These can usually be inferred by the compiler, but it’s still very much static typing, since static typing is not an alternative to type inference (Gleam has both).

If you want type inference that can guarantee that the compiler knows what types your variables / arguments / return values are, then it sounds to me that you want static typing with type inference, like Gleam or TypeScript do. I’m not sure type inference can meaningfully be done without static typing – we have surely seen with Erlang and Elixir that Dialyzer is not enough, and misses very obvious error cases (as it just doesn’t have enough information).

3
Post #43
dimitarvp

dimitarvp

I have never said that I “live in refactoring hell”. Why do you feel the need to invent stories to make a point?

This is the case in Rust and OCaml at least and other newer languages are going the same route.

You seem to be saying “I don’t want languages without type inference” which is OK. Who is fighting you on this and why do you feel the need to emphasize it as much? :thinking:

He we will have to agree to disagree. You have (1) repeatedly ignored an important discussion point that I made – namely that you are putting two techniques on an arena and are looking at which one is better, and I asked why not use both? – then (2) you go on lengthy diatribes claiming your opinions as fact, and finally (3) you say I argue in bad faith.

I mean OK, if it makes you feel better. ¯_(ツ)_/¯

I will disengage because this is not productive at all. You don’t seem to be responding to me, you are responding to things that bothered you long before you engaged in this thread. And you fixated on me as if I am everything wrong with programming these days. :sweat_smile:

0
Post #44
dimitarvp

dimitarvp

Yep I know what type inferencing is, and I agree with @Nicd that it’s difficult or impossible to achieve it without actual static typing.

0
Post #45
D4no0

D4no0

The thing that it compiles to doesn’t matter, the actual enforcement and type inference happens inside the gleam → erlang compilator, so the only question is how constrained the language is.

It’s impossible, the best you can get is what dialyzer currently offers. I think the argument shifted at some point from arguing about the usefulness of static typing, to the boilerplate the classical static typing implementation creates in function definitions.

0
Post #46
Nicd

Nicd

On further thinking you are of course correct here. :slight_smile:

1
Post #47
dimitarvp

dimitarvp

That boilerplate is very overrated at least in Rust and OCaml (can’t remember about Haskell). Gleam seems quite concise as well.

To call adding a single word to a function argument “boilerplate” is a bit unfair.

0
Post #48
benwilson512

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

There is no need to employ personal attacks here. It’s frustrating when people don’t get your point, but please remain respectful.

0
Post #49
D4no0

D4no0

If the current compiler technology is capable of doing this without you having to write signatures to every function you do, then I would always go for inference over defining the type in the signature. You don’t lose any benefits of static typing and at the same time you don’t have the verbosity of redefining types that people hate.

1
Post #50