On Tuesday, 18 February 2014 at 12:13:56 UTC, Tobias Pankrath wrote:
> I have a hard time to subsume D's type system under parametric polymorphism, while I see how Javas generics may be. This may just be way over my head, but I'd rather say D has a sophisticated way of ad-hoc polymorphism that provides ways to generate overloads on demand, contrary to the wikipedia statement that ad-hoc only allows for a fixed amount of overloads.

"[ad hoc polymorphism] is also known as function overloading or operator overloading[...] This is in contrast to parametric polymorphism, in which polymorphic functions are written without mention of any specific type."

For awhile I would have supported the claim that Go has parametric polymorphism, but "while still maintaining full *static* type-safety" prevents that.

On Tuesday, 18 February 2014 at 06:50:36 UTC, logicchains wrote:
> Maybe it'd help things if they just directed any inquiries regarding generics to the most popular preprocessor package? There are a few around the community. I even wrote a tiny one myself this morning; it can only handle simple functions like:
> func myFun<T, S>(a, b ~T, u, v ~S) (~T, ~S, ~S){
>     return a + b, u*u, v*v
> }

I can't claim code generation to be a terrible option, after all D is code generation. I certainly have created, and used many myself, and then there is also Regex and Pegged demonstrating such power. But it is not without its problems, one of which is right there in your comment.

* Debugging becomes more difficult, line numbers don't match.
* It is easy to hide details about what code actually exists.

But a preprocessor has extra negatives

* People will develop their own solution to a problem.
* Adds a dependency to the project
* Each project will use different preprocessors to address the same problem or different problems (compatibility between preprocessors?.
* Such projects won't be considered while the language evolves
** Either the generator syntax will be poor (hiding in comments, which aren't actually sacred in Go)
** Or the generator risks breaking from language changes

However I don't think most of those who desire generics appreciate the benefits of code generation and it would not be reasonable to point them to such a solution (cpp has left a bad taste in most peoples mouth)

This project was an interesting take on solving the perceived problem. http://clipperhouse.github.io/gen/ (it even had to fix the problems with the sort package)

On Monday, 17 February 2014 at 20:00:18 UTC, Paulo Pinto wrote:
> You have provided a very nice answer.
>
> The problem with Go generics is religious, I might have to eat my own words, but I seriously doubt they will ever support it.
>
> They are too focused with Java and C++ as models, to accept anything else as proof of them being wrong.
>
> --
> Paulo

That's a bad thing for software in general, but arguably a good
thing for us.

On Tue, 2014-02-18 at 07:45 +0000, Paulo Pinto wrote:
[…]
> We are in 2014, not in the early 90's. So to ignore what happened in mainstream language design in the last 20 years, is nothing more than an opinionated political decision against generics.
[…]

As far as I am aware, Go is the first attempt to have a strong statically typed language enforce a duck typing approach to objects at run time. Go has no classes, so the only generics possible is at the function level.

The thing here is that those people who are actually using Go for real problems, are finding ways of using the interface{} construct to achieve polymorphism for the problems they are solving, Thus the evidence is building that Go as it is is effective and efficacious without generics.

It has to be said most people who say "how can you survive without generics are coming from C++, Java, D, C# where the mental model is generics based. Coming from C, Self, Lisp, the mindset is different.

So the evidence is that the last 20 years hasn't resulted in just one
answer, we are still in a period of interesting work being done both
with and without generics. The analysis that is missing here is what
works and doesn't work with and without generics. We have some evidence
just no final conclusion.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Thu, Feb 20, 2014 at 10:21 AM, Russel Winder <russel@winder.org.uk>wrote:

> The thing here is that those people who are actually using Go for real problems, are finding ways of using the interface{} construct to achieve polymorphism for the problems they are solving,


The downside to doing that; however, is taking a performance hit, correct? There would always be an indirection when accessing methods via an interface, as opposed to having generics. Compare the Sort package to how C++ is able to inline the custom sorting routine.

--
Ziad

On Thursday, 20 February 2014 at 18:22:11 UTC, Russel Winder
wrote:
> On Tue, 2014-02-18 at 07:45 +0000, Paulo Pinto wrote:
clip
>
> The thing here is that those people who are actually using Go for real
> problems, are finding ways of using the interface{} construct to achieve
> polymorphism for the problems they are solving, Thus the evidence is
> building that Go as it is is effective and efficacious without generics.
>

I once worked on a project where we used Fortran to develop a GUI
app
(without the help of any sort of GUI toolkit) for image
processing.
I remember struggling to find ways to make it re-use code, but the
general means of code reuse was copy-paste.  I replaced part of
the
tool with a QT based (C++) tool, that had MUCH better
functionality with
a fraction of the code, but the project leader had no interest in
that
because he only knew Fortran (he was a scientist, not a
programmer, so
I can see why he didn't want to change his baby to C++ though).

Anyway, my point is: the fact that we found a way to do it doesn't
necessarily mean that it was a good idea.

How good these Go solutions to polymorphism are, I cannot comment
on as
I don't know Go, but hopefully their 'ways' are more elegant than
our way of writing a GUI app in old-school Fortran.

Am 20.02.2014 19:21, schrieb Russel Winder:
> On Tue, 2014-02-18 at 07:45 +0000, Paulo Pinto wrote:
> […]
>> We are in 2014, not in the early 90's. So to ignore what happened
>> in mainstream language design in the last 20 years, is nothing
>> more than an opinionated political decision against generics.
> […]
>
> As far as I am aware, Go is the first attempt to have a strong
> statically typed language enforce a duck typing approach to objects at
> run time. Go has no classes, so the only generics possible is at the
> function level.

Not really, it is called structural typing in the ML family of languages.

>
> The thing here is that those people who are actually using Go for real
> problems, are finding ways of using the interface{} construct to achieve
> polymorphism for the problems they are solving, Thus the evidence is
> building that Go as it is is effective and efficacious without generics.
>
> It has to be said most people who say "how can you survive without
> generics are coming from C++, Java, D, C# where the mental model is
> generics based. Coming from C, Self, Lisp, the mindset is different.


I used common base object in Turbo Pascal, C++, Oberon(-2), Java and C#,
before the said languages got any form of generics.

I don't miss those days.



--
Paulo

On Thu, 2014-02-20 at 19:32 +0000, Craig Dillabaugh wrote: […]
> I once worked on a project where we used Fortran to develop a GUI
> app
> (without the help of any sort of GUI toolkit) for image
> processing.
> I remember struggling to find ways to make it re-use code, but the
> general means of code reuse was copy-paste.  I replaced part of
> the
> tool with a QT based (C++) tool, that had MUCH better
> functionality with
> a fraction of the code, but the project leader had no interest in
> that
> because he only knew Fortran (he was a scientist, not a
> programmer, so
> I can see why he didn't want to change his baby to C++ though).

:-) or perhaps :-(

The HEP community have been trying to switch to C++ from Fortran for the last 20 years with some success. However they continue to use some libraries written in Fortran 4 (well actually Fortran G).

> Anyway, my point is: the fact that we found a way to do it doesn't necessarily mean that it was a good idea.

I agree completely. But I also say that you have to try, just in case you find something new that turns out to be something good and useful. On the other hand there is a point at which you have to review and potentially admit the whole enterprise was a waste of time.

I think the Go experiment has not reached a decision stage as yet.

Go routines are superb. Reliance on return codes and no exceptions is less so. compile time strongly typed duck typing is still an experiment awaiting a result.

> How good these Go solutions to polymorphism are, I cannot comment
> on as
> I don't know Go, but hopefully their 'ways' are more elegant than
> our way of writing a GUI app in old-school Fortran.

Different, possibly somewhat more elegant. I don't think we have enough evidence as yet to really come to a conclusion.

The problem here is all the hidden variables. This is not a properly structure experiment where variables are under strong control. There are infact too many variables to analyse the whole thing easily, and then there is all the emotion and prejudice to filter out.

For me the jury doesn't yet have the evidence to be out. Well on Go/D/Python anyway.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Mon, 2014-02-17 at 22:53 +0000, Asman01 wrote:
[…]
> 
> I don't think so. Did you know that some of they are the same guys from Bell Labs which created C, UNIX, Plan9, UTF8 etc?

Yes, but the core issue is that the language they have come up with is being used for purposes outside those competencies. This could either lead to new insight or tribalism based on past glories.
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Mon, 2014-02-17 at 22:19 +0000, ponce wrote:
[…]
> Granted code bloat is a real thing and you _might_ have instruction cache problems, but the problem only ever show itself
[…]

Code bloat in what sense? Go is founded on static compilation so as to avoid the dynamic library binding "problem". So executable are 5 to 100MB which is code blat in my book. On the other hand they don't have library versioning problems which is the bane of Posix.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder