On Sat, Jul 29, 2017 at 6:36 PM <dogan.k...@dodobyte.com> wrote:
> I just want to know sincerely, if people REALLY need generics so much, or
> they are just complaining because they are used to it and it's in their
> favorite programming language.
>
>
Generics tend to serve at least two purposes in a programming langauge.
What you are doing is that you are essentially extending functions such
that they have two types of parameters: term parameters (which is what Go
has now) and type parameters which instantiate the given function for those
types. The output type is always a term[*]. Most generics can be boiled
down to this very idea in the end and most of the notation can be reified
by expansion.
One reason to want this is simply that it avoids typing. Your example of
expanding a Max function for each possible type is a common one.
The other primary reason as to why people want something like this is
precision: you can describe the intent of a program more precisely which
means that the compiler is able to catch more programming mistakes up
front. The obvious benefit here should be when programming in the large
with many people working on the same code base. If we can capture more bugs
at compile time, they don't end up occurring when running programs.
As secondary reason is that once you start combining generic features, you
really need to start relying on the compiler telling and hinting you about
where you are mistaken in your use-case. If you had tried a variant based
on interface{} and reflect, you are likely to mess it up.
In principle, maps or arrays could have been implemented such that they
would require the use of an interface{}. But this would make more brittle
programs. Hence, the language defines maps and arrays as generic
constructions. If you look at package builtin, it defines (for
documentation purposes) builtin.Type and builtin.Type1. These are
subsequently used in different invocations where you need the invocation to
be generic: copy(), close(), append(), cap(), len(), ...
What proponents of generics are saying is that they want access to the same
kind of functionality at the language level so they can define their own
functions to work like the ones above. Clearly, the compiler must
understand the notion of generic type(!), but it doesn't give that power to
the programmer.
You can argue that Turing completeness means you can implement anything
with anything as long as it is Turing complete. But by that argument, we
could as well be writing assembly still because, after all, you can
implement anything in assembly. Programming languages are about applying
select restriction in order to achieve more. For instance by building a
programming language which doesn't make use of a goto construction, even
though assembly is all jumps and program counter manipulation.
On the other hand, it should be mentioned that Go already has an
abstraction feature in the interface construction. And some uses of
generics can be resolved simply by rephrasing them in an interface. Yet
there are certain things which cannot be expressed if you don't have a
type-level variable.
(Aside: I don't write enough Go to have an opinion on whether or not it
would be right to add generics to Go. But based on my experience with other
languages, I enjoy programming with them there. )
[*] You can explore what it means to have the output be either a term or a
type. See e.g., F* or Idris.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
