Generics may kill your language

[Alvaro]

Hi everyone,

Just some facts related to the generics discussion:

- When Java added generics (2004), people started to look for another
languages:
- Ruby on Rails hype started around 2005.
- Groovy started on 2004.
- Scala started on 2004.

- The ECMAScript version 4 tried to add generics to Javascript. But
this version was finally discarded. ECMAScript 5 continued without the
generics approach.

- After writing the best-seller Modern C++ Design book, Andrei
Alexandrescu got involved in the D programming language development.
Which among other things, tried to simplify C++ templates.

These are only facts. Now anyone can have it's own conclusions.

Regards

[Florian Weimer]

* Alvaro:

> Just some facts related to the generics discussion:
>
> - When Java added generics (2004), people started to look for another
> languages:
> - Ruby on Rails hype started around 2005.
> - Groovy started on 2004.
> - Scala started on 2004.

Generics were added to Java around 1998, not in 2004. Scala creator
Martin Odersky was part of the design team for generic Java.

Oracle's version of Java for mobile devices still lacks generics. I
don't think that increases its popularity among programmers.

Go is quite distinct from Java, Javascript, and C++, and lessons from
those programming languages do not necessarily carry over.

[Jay Young]

http://imgs.xkcd.com/comics/correlation.png

[Kyle Lemons]

I think the Go team (and the community) is well aware that a poor implementation of generics is worse than none at all.  Based on their track record for (what I believe is) only implementing features that are simple, orthogonal, and carry their weight, I don't think we have anything to worry about.

If it's impossible for generics to meet that bar, then generics will probably never find their way into Go.

~K

[Paulo Pinto]

Strong type languages with generics, templates or parametric
polymorphism:
- Ada
- Eiffel
- Modula-3
- D
- C#
- VB.NET
- F#
- Ocaml
- ML
- Haskell
- Scala
- ATS
- Delphi
- C++
- ...

Some are successful in the industry even if only in specific fields,
some are successful in the academia, some are
already dead. And this is a very small list of languages with
"generics" concept.

I don't see a relation with your post.

[Paul Borman]

If any of these languages met the Go bar then I don't think Go would exist :-)

[stre...@gmail.com]

The only thing in Go that I miss VERY much is generics.

I really hope that generics will be added to Go some day.

[Nickos Ventouras]

On Jan 9, 9:28 pm, Florian Weimer <f...@deneb.enyo.de> wrote:

> > - When Java added generics (2004), people started to look for another
> > languages:
> >     - Ruby on Rails hype started around 2005.
> >     - Groovy started on 2004.
> >     - Scala started on 2004.
>
> Generics were added to Java around 1998, not in 2004.

Slightly OT to the general thread --which I find amusing--, but I
programmed Java in 1998 and there were no generics there. You made me
look, though, and Wikipedia states it as I remember it:

"Generics are a facility of generic programming that was added to the
Java programming language in 2004 as part of J2SE 5.0."

So, maybe there was some proposal/project to add generics to Java in
1998, but sure as hell, they were not added to the Java distribution
until 2004.

[Nickos Ventouras]

On Jan 10, 2:43 am, Paul Borman <bor...@google.com> wrote:

> If any of these languages met the Go bar then I don't think Go would exist
> :-)

Well, Go just has different goals.

It's not like there's some bar for language excellence that only go
meets...

[JONNALAGADDA Srinivas]

Alvaro,

On Monday, 9 January 2012 23:56:14 UTC+5:30, Alvaro wrote:

- When Java added generics (2004), people started to look for another
languages:
    - Ruby on Rails hype started around 2005.
    - Groovy started on 2004.
    - Scala started on 2004.

        Scala has had generics from the very beginning.  Probably you have not really seen Scala's standard library in detail.  Its capability to scare the uninitiated may be second only to that of C++'s templates.

 

- After writing the best-seller Modern C++ Design book, Andrei
Alexandrescu got involved in the D programming language development.
Which among other things, tried to simplify C++ templates.

        C++ is arguably the language with the highest number of `features'.  You could design any new language.  As long as it follows a C-style syntax, you could call it a simplification of C++.  And, not many will argue with you.

 

These are only facts. Now anyone can have it's own conclusions.

        Sure.  But, there are simpler ways of saying that you don't wish to have generics in Go. ;-)  No offence please!

        More seriously, as Kyle said, there is no danger of the Go team parting with prudence to implement a bad proposal, if ever!

                                                            Greetings,

                                                                    JS

____

http://oneofmanyworlds.blogspot.com

[Maxi]

In my opinion generics introduce more problems and complexity than
they solve. Is that little parcel of added type safety really worth a
huge additional language feature to Go? I don't think so
Generics make programmers think in "is-a" relationships, while "has-a"
would much simpler and easier to reason about.

Sure, there is always the argument that nobody is forced to use them.
But nobody is forced to use the hundreds of Scala features either, but
people still do, and if I may say so: it makes the entire language too
complex to use.

I'm using C just fine, and I never see a particular need for
generics.

[chris dollin]

On 10 January 2012 12:14, Maxi <trust...@googlemail.com> wrote:
> In my opinion generics introduce more problems and complexity than
> they solve. Is that little parcel of added type safety really worth a
> huge additional language feature to Go?

It's need not be "little", and it need not be "huge", and it also
gives an extra bunch of expressive behaviour.

> I don't think so
> Generics make programmers think in "is-a" relationships,

Really?

> while "has-a"
> would much simpler and easier to reason about.

> I'm using C just fine, and I never see a particular need for
> generics.

I've used C just fine, and a bunch of code I needed to write was
hand-coded generics for the Usual Suspects: sequences, finite
maps, etc.

--
Chris "allusive" Dollin

[Sebastien Binet]

On Tue, 10 Jan 2012 04:14:05 -0800 (PST), Maxi <trust...@googlemail.com> wrote:
> In my opinion generics introduce more problems and complexity than
> they solve. Is that little parcel of added type safety really worth a
> huge additional language feature to Go?

type safety isn't why I long for generics (go has interface{} for this,
for some definition of type safety...)
good performances w/o additional indirections is the reason (for me).

that said, I suppose we could get away w/o generics but using
interface{} (or special interfaces like sort.Interface) and still
recover some performances with a JIT (to de-virtualize calls), but
that's another can of worms :)

-s

[David Leimbach]

On Jan 9, 11:28 pm, streb...@gmail.com wrote:
> The only thing in Go that I miss VERY much is generics.
> I really hope that generics will be added to Go some day.

Can you be specific as to exactly where you miss it?

I will admit that sometimes Go has some design choices for built in
functions that seem to work generically and I come down with some form
of envy that I can't write code like that myself in Go (appending to
slices). At the same time it really hasn't come up that much. To be
honest however, I've written very little Go in the last couple of
months, which is something I plan to rectify. (While also learning
about Io)

Simplicity + Consistency does make it easier to reason about problem
solving in a language, sometimes, but consistency isn't as important
as simplicity I reckon. This seems to be the philosophy in Go.

I think it's a good exercise for those pining for generics to try
solving some problems without them, the Go way, and then see if they
still want generics. In fact, I would love to see such discussions and
exercises here, as I think it'd benefit people who are thinking the
same.

Dave

[⚛]

On Jan 10, 8:28 am, streb...@gmail.com wrote:
> The only thing in Go that I miss VERY much is generics.

Could you submit a piece of code where you are missing generics very
much?

[Mikhail Strebkov]

There are two things that I've faced during participation in Google aichallange 2011 (Ants):

The first is "math" package. I had to re-implement most of the functions for ints.

The second is "container/list" - the syntax like l.Front().Value.(int) is worse than just l.Front().Value where Value is already an int.

[Chris Hines]

I also used Go in the AI Challenge (Ants). See my comments in this post. The section, "I had to avoid interface values in performance critical loops," is most relevant to this thread.

There may be other solutions to this problem, but I can't help but think that using C++ STL libraries (or something comparable) with a compiler capable of inlining simple functions would provide better performance without the need to duplicate the source code and make type specific edits to get higher performance versions of basic algorithms and data structures.

[ancientlore]

I would rather live without generics unless it can be a really good
implementation. I could have used generics in two cases.

The first case was my go-tripit library, where I needed to create
custom UnmarshalJSON functions for numerous structs to work around
some nuances of the incoming JSON. It was quite boilerplate, so I
created a small Go program using the template library to generate my
code. Here is one example:

https://github.com/ancientlore/go-tripit/blob/master/airsegmentptrvector.go

The template I used is here:

https://github.com/ancientlore/go-tripit/blob/master/genvect/vector_template.go

There may have been a better way to handle the problem, but I haven't
found it yet. It seems like the custom UnmarshalJSON code won't be
called except on a concrete type.

The second case where I could have used generics is my go-avltree
library, where I specialized the implementation for strings and Pairs:

http://code.google.com/p/go-avltree/source/browse/trunk/stringtree.go
http://code.google.com/p/go-avltree/source/browse/trunk/objecttree.go
http://code.google.com/p/go-avltree/source/browse/trunk/pairtree.go

In both cases I was able to proceed without generics - it was an
intriguing challenge that made me think a lot about idiomatic Go. The
issue was somewhat artificial in the go-tripit example, but in the
avltree example it's the typical issue of generics applied to
containers.

-Mike

[Mikhail Strebkov]

I would rather live without generics unless it can be a really good implementation. 

So do I. But I think that really good implementation of generics will be much better that no generics at all (e.g. better than creating a small Go program using the template library to generate code).

[SteveD]

On Jan 10, 9:51 pm, Mikhail Strebkov <streb...@gmail.com> wrote:
> The first is "math" package. I had to re-implement most of the functions
> for ints.

Fair enough, but imagine if math _only_ provided generics - then every
Go program using math would suffer from the associated overhead.
Looking at C++, the problem (as I see it) is that people went template-
crazy - _everything_ became a template, whether it was a good
engineering decision or not. Here I think we can trust the Go team
not to overuse a good idea and keep generic use to a minimum in the
standard libraries. For instance, a single UTF-8 string type is much
more manageable than separate std::string and std::wstring types
constructed from a template implementation.

> The second is "container/list" - the syntax like l.Front().Value.(int) is
> worse than just l.Front().Value where Value is already an int.

That's the main benefit of generics in Java, less explicit
typecasting. Java-style generics would require less typing, although
this list type would remain rather inefficient compared to a real
generic specialization, much as Java's LinkedList container only can
contain objects which need to be boxed and unboxed for primitives.

The main argument for generics remains this: that copy 'n paste
specialization is more error-prone than generic specialization.

steve d.

[⚛]

Is the code available somewhere (such as: github.com)? I would like to
see it for myself.

[Carl]

Hello,

after thinking about this topic for a while I did a little research
and I noticed that you are mixing C++ Templates and (apparently) Java
Generics together as being more or less the same thing, which they
are not.

This was discussed at length already here:
http://stackoverflow.com/questions/36347/what-are-the-differences-between-generic-types-in-c-and-java

Some claim C++ templates are more or less just a glorified copy and
paste (macros), built into the compiler, to make it look coherent.
While this is a broad simplification I think it gets the general
concept across quite well (parameterized programs).

Actually macros go way back, and some designs are actually
surprisingly coherent and advanced, see also Lisp.

If you notice both C++ templates and Java Generics were added to
those languages years later. I feel that is why those features have
such an inherent negativ appeal to some programmers. Because these
functionalities came along later in the guise of stepchildren and
something about it feels like patchwork.

however, maybe not everything needs to be done in the compiler

... there are actually already a number generalized preprocessors
out there which can do many of the basic functions that might be
needed in some of these specialized cases where parameterized code is
needed.

... and yet another thought that pops to mind is that some of these
issues might also be handeled by a nice high-powered programable
editor for code generation and manipulation (which would likely also
have implications for code refactoring work).

[SteveD]

On Jan 11, 6:18 pm, Carl <2ca...@googlemail.com> wrote:
> out there which can do many of the basic functions that might be
> needed in some of these specialized cases where parameterized code is
> needed.

It's a good way to get a feeling for new notation without doing the
prototyping with the compiler.

> issues might also be handeled by a nice high-powered programable
> editor for code generation and manipulation (which would likely also
> have implications for code refactoring work).

That's a promising idea. Any smart editor could be taught to do that
(my favourite Scite is easy to extend using Lua)

It would be easier and safer than copy 'n paste.

steve d.