This are merely instanceof switches. Generics mean that you write
fun(a,b): return a+b
and if the a + b is doable, it will be done. You don't need to specify the list of types that accepts this syntax. The difference between this and duck typing is that you can also specify interfaces (or traits in c++) that will say that this type is quackable so
fun(a <? implements Quackable>): a.quack()
is reusable. What is the difference between this and simple interface implementation? It took me some time to find this example in the narrowest version possible.
class <T has trait Number> Complex(a T, b T):
Complex<T> operator+(Complex<T> other): return new Complex(this.a + other.a, this.b+other.b)
Complex<T> operator-(Complex<T> other): return new Complex(this.a - other.a, this.b-other.b)
Complex<T> operator*(Complex<T> other):
return Complex(this.a * other.a - this.b * other.b, this.a * other.b + this.b * other.a)
The generic renders this code reusable, so if only you can create a new type, let's say vector, that supports +,-, and multiply you can have complex algebra on those vectors
One of my pet-hates is fellow developers who call an implementation 'generic', but when you peek inside, there's just if-statements that (at best) cover the already-known input types.
Usually I point to Generics as an example of what "generic" actually means: You peek inside List<T>, it doesn't know about your type, it does the right thing anyway.
I saw your programming language on reddit and now here too. To me first looking at it, I think its built straight for parallelism, Didn't know you were on hackernews too, interesting stuff and I will try to keep an eye out hopefully for this language but what are some stuff where you think it can be really useful for?
You implemented type-checking. For a project this ambitious, I am surprised here.
“Generics” should mean that the compiler or interpreter will generate new code paths for a function or structure based on usage in the calling code.
If I call tragmorgify(int), tragmorgify(float), or tragmorgify(CustomNumberType), the expectation is that tragmorgify(T: IsANumber) tragmorgifies things that are number-like in the same way.
For a compiled language this usually means monomorphization, or generating a function for each occurring tuple of args types. For an interpreted language it usually means duck-typing.
This is not a bad language feature per se, but also not what engineers want from generics. I would never write code like your example. The pattern of explicit type-checking itself is a well-known codesmell.
There is not a good usecase for adding 2.0 to a float input but 1 to an integer input. That makes your function, which should advertise a contract about what it does, a liar ;)
8 comments
[ 3.7 ms ] story [ 31.0 ms ] threadOne of my pet-hates is fellow developers who call an implementation 'generic', but when you peek inside, there's just if-statements that (at best) cover the already-known input types.
Usually I point to Generics as an example of what "generic" actually means: You peek inside List<T>, it doesn't know about your type, it does the right thing anyway.
This is different from ‘parametric polymorphism’, which is what people call generics.
Your list_contains function should be able to just do a == comparison regardless of whether it's an int or a string.
This is effectively no different than adding a parameter to one of your non-"generic" functions and just swapping behaviour based on that?
Why not just use a weakly typed language and add type checking were needed?
It seems strange to put in so much effort for type checking then only to throw it overboard by implementing something that ignores type.
“Generics” should mean that the compiler or interpreter will generate new code paths for a function or structure based on usage in the calling code.
If I call tragmorgify(int), tragmorgify(float), or tragmorgify(CustomNumberType), the expectation is that tragmorgify(T: IsANumber) tragmorgifies things that are number-like in the same way.
For a compiled language this usually means monomorphization, or generating a function for each occurring tuple of args types. For an interpreted language it usually means duck-typing.
This is not a bad language feature per se, but also not what engineers want from generics. I would never write code like your example. The pattern of explicit type-checking itself is a well-known codesmell.
There is not a good usecase for adding 2.0 to a float input but 1 to an integer input. That makes your function, which should advertise a contract about what it does, a liar ;)