Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On 2014-02-16 22:05:10 +, Walter Bright said: However, I agree that there may well be other reasons to not have them in Go, such as their simply not being especially useful in day-to-day programming; but I don't have enough experience with meta-programming to make such a judgment. Some years ago, I felt exactly the same way about generics. I have recently written some very interesting D programs, and I would have shocked my former self with nearly every function being a template. I could second this. When you have a strong type system as in D, it makes sense to have strong meta-programming to avoid rework. My current project reflects on all modules to look for classes which inherit from a particular base class -- and then wires those up for fast serialization and deserialization.This would be impossible to do at compile time in any other language, and impossible in most languages, and requiring slow run-time reflection in others. I've found a use for something similar to this in most projects I've done lately. In C# I use Linq Expressions to compile anonymous delegates at runtime to do something similar -- but the code is a nightmare. -S
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Monday, 17 February 2014 at 06:32:19 UTC, Paulo Pinto wrote: Well, supporting modules would already help. With luck C++ will get them around 2020. I think it won't matter by then. -- Paulo Someone said that 10 years ago. Whether it's true 5 years from now entirely depends on the state of the alternatives by then, not on the state of C++. Don't underestimate the resistance to change.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
Am 23.02.2014 05:00, schrieb SomeDude: On Monday, 17 February 2014 at 06:32:19 UTC, Paulo Pinto wrote: Well, supporting modules would already help. With luck C++ will get them around 2020. I think it won't matter by then. -- Paulo Someone said that 10 years ago. Whether it's true 5 years from now entirely depends on the state of the alternatives by then, not on the state of C++. Don't underestimate the resistance to change. Sure, it is always a matter if OS vendors would invest in another systems language or not.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Thursday, 20 February 2014 at 20:26:40 UTC, Russel Winder wrote: On Mon, 2014-02-17 at 22:19 +, 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. I meant it in the sense of actual slowdown related to binary size, or impossibility to fit a program on some embedded hardware.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Thursday, 20 February 2014 at 22:33:34 UTC, Paulo Pinto wrote: Am 20.02.2014 23:09, schrieb Walter Bright: On 2/20/2014 12:17 PM, Paulo Pinto wrote: 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. Isn't it interesting how the OOP everywhere mantra of the late 80's / early 90's has largely disappeared? Yes, like every new paradigm I think people tend to go overboard. Last example is the discussion about OOP vs FP, when most languages used in such discussions are actually multi-paradigm, even if they are functional first vs object first. Regarding OO, it is interesting to see how after all those years we are finally getting to the interfaces/traits usage coupled with generics, with little inheritance. Ideally of course, many people still haven't got to it. -- Paulo That makes me sad that D has Java's object model rather than let's say, scala's (which work with traits/interfaces).
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On 2/21/2014 5:27 PM, deadalnix wrote: That makes me sad that D has Java's object model rather than let's say, scala's (which work with traits/interfaces). D's object model works with interfaces.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Saturday, 22 February 2014 at 01:36:48 UTC, Walter Bright wrote: On 2/21/2014 5:27 PM, deadalnix wrote: That makes me sad that D has Java's object model rather than let's say, scala's (which work with traits/interfaces). D's object model works with interfaces. I'm talking about this: http://joelabrahamsson.com/learning-scala-part-seven-traits/
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Saturday, 22 February 2014 at 01:39:28 UTC, deadalnix wrote: On Saturday, 22 February 2014 at 01:36:48 UTC, Walter Bright wrote: On 2/21/2014 5:27 PM, deadalnix wrote: That makes me sad that D has Java's object model rather than let's say, scala's (which work with traits/interfaces). D's object model works with interfaces. I'm talking about this: http://joelabrahamsson.com/learning-scala-part-seven-traits/ https://gist.github.com/JesseKPhillips/9147869 Two notes, Creating an array required casting the first item to the common type. D doesn't let you creating a new object and implement an interface. It seems that std.typecons is getting tripped up on the final method fly() so it can't be used either.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Saturday, 22 February 2014 at 02:52:37 UTC, Jesse Phillips wrote: On Saturday, 22 February 2014 at 01:39:28 UTC, deadalnix wrote: On Saturday, 22 February 2014 at 01:36:48 UTC, Walter Bright wrote: On 2/21/2014 5:27 PM, deadalnix wrote: That makes me sad that D has Java's object model rather than let's say, scala's (which work with traits/interfaces). D's object model works with interfaces. I'm talking about this: http://joelabrahamsson.com/learning-scala-part-seven-traits/ https://gist.github.com/JesseKPhillips/9147869 Two notes, Creating an array required casting the first item to the common type. D doesn't let you creating a new object and implement an interface. It seems that std.typecons is getting tripped up on the final method fly() so it can't be used either. This code works fine: http://dpaste.dzfl.pl/c0b3a941d917
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Saturday, 22 February 2014 at 03:03:18 UTC, Meta wrote: This code works fine: http://dpaste.dzfl.pl/c0b3a941d917 That is an anonymous class, that is defining and instantiating the class, which isn't what the scala code was doing. (BTW this feature was added because Java could do it).
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Saturday, 22 February 2014 at 03:41:29 UTC, Jesse Phillips wrote: On Saturday, 22 February 2014 at 03:03:18 UTC, Meta wrote: This code works fine: http://dpaste.dzfl.pl/c0b3a941d917 That is an anonymous class, that is defining and instantiating the class, which isn't what the scala code was doing. (BTW this feature was added because Java could do it). Sorry, I thought you meant it doesn't allow you to create a new object that implements a certain interface, instead of creating a new object and then implement an interface. Looking at the Scala example again, I see it is indeed different.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Tue, 2014-02-18 at 07:45 +, 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.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Thu, Feb 20, 2014 at 10:21 AM, Russel Winder rus...@winder.org.ukwrote:
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
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Thursday, 20 February 2014 at 18:22:11 UTC, Russel Winder
wrote:
On Tue, 2014-02-18 at 07:45 +, 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.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
Am 20.02.2014 19:21, schrieb Russel Winder:
On Tue, 2014-02-18 at 07:45 +, 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
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Thu, 2014-02-20 at 19:32 +, 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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Mon, 2014-02-17 at 22:53 +, 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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Mon, 2014-02-17 at 22:19 +, 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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
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.
The thing here is that those people who are actually using
assembler for real problems, are finding ways of using the 'goto'
construct to achieve control flow for the problems they are
solving. Thus the evidence is
building that assembler as it is is effective and efficacious
without structured control flow mechanims.
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.
The analysis that is missing here is what works and doesn't work
with and without structured control flow. We have some evidence
just no final conclusion.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On 2/20/2014 12:17 PM, Paulo Pinto wrote: 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. Isn't it interesting how the OOP everywhere mantra of the late 80's / early 90's has largely disappeared?
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On 2/20/2014 12:21 PM, Russel Winder wrote: For me the jury doesn't yet have the evidence to be out. Well on Go/D/Python anyway. I'm still discovering how to write D code. It's actually kind of exciting how it looks less and less like C++ code.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
Am 20.02.2014 23:09, schrieb Walter Bright: On 2/20/2014 12:17 PM, Paulo Pinto wrote: 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. Isn't it interesting how the OOP everywhere mantra of the late 80's / early 90's has largely disappeared? Yes, like every new paradigm I think people tend to go overboard. Last example is the discussion about OOP vs FP, when most languages used in such discussions are actually multi-paradigm, even if they are functional first vs object first. Regarding OO, it is interesting to see how after all those years we are finally getting to the interfaces/traits usage coupled with generics, with little inheritance. Ideally of course, many people still haven't got to it. -- Paulo
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Thursday, 20 February 2014 at 20:26:40 UTC, Russel Winder wrote: On Mon, 2014-02-17 at 22:19 +, 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. Actually they do, as shown by the whole go get discussion and the current inability of Go's compiler to link against binary packages. -- Paulo
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Thursday, 20 February 2014 at 21:52:25 UTC, Araq 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, Thus the
evidence is
building that Go as it is is effective and efficacious without
generics.
The thing here is that those people who are actually using
assembler for real problems, are finding ways of using the
'goto' construct to achieve control flow for the problems they
are solving. Thus the evidence is
building that assembler as it is is effective and efficacious
without structured control flow mechanims.
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.
The analysis that is missing here is what works and doesn't
work with and without structured control flow. We have some
evidence just no final conclusion.
Nice post! :)
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Tuesday, 18 February 2014 at 07:45:10 UTC, Paulo Pinto wrote: It is like traveling back in time when parametric polymorphism was debated in university papers and everyone was inventing their own code generation tool. Back to mid-90's compiler technology when only Ada supported generics, C++ started to adopt some form of genericity at ISO meetings and everything else where academic languages like Eiffel, Modula-3 or Standadard ML. 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. I understand the sentiment that it is 'backwards', but what exactly on a practical level is harmful about people writing their own code generation tools? On Monday, 17 February 2014 at 22:53:47 UTC, 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? I'm aware of that, but I'm also aware that there are few things in the world more agonisingly complex than writing a C++ compiler. I think I read Walter say somewhere that it took him ten years! That's ten years of domain-specific experience working with generics in the language with the most complex implementation of generics in existence. My impression is that no amount of experience in other aspects of language design would be a substitute for this specific experience, and hence I think it makes more sense to attribute the effectiveness of D's generics implementation to Walter's extensive experience implementing generics than to attribute it to generics being easy to implement well. If generics are easy to implement, then why isn't there another language with the compile-time power of D that's not a monster like C++ or a Lisp?
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On 02/18/2014 10:42 AM, logicchains wrote: I think it makes more sense to attribute the effectiveness of D's generics implementation to Walter's extensive experience implementing generics than to attribute it to generics being easy to implement well. If generics are easy to implement, then why isn't there another language with the compile-time power of D that's not a monster like C++ or a Lisp? It's the 'compile-time power of D' that is not 'easy to implement' (there is not (yet) one D compiler in existence that actually can handle all of it in a reasonable way), not 'generics' (whatever that means exactly).
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Tuesday, 18 February 2014 at 07:45:10 UTC, Paulo Pinto wrote: It is like traveling back in time when parametric polymorphism was debated in university papers and everyone was inventing their own code generation tool. 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. 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. Thus, ad hoc polymorphism can generally only support a limited number of such distinct types, since a separate implementation has to be provided for each type. [1] I'd say inout is a example of parametric polymorphism in D. [1] http://en.wikipedia.org/wiki/Parametric_polymorphism
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
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.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
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 myFunT, 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)
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
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.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On 2/16/14, 12:09 PM, Russel Winder wrote: Someone with serious knowledge should wade into this campaign of FUD. The whole thread is wrong-headed. Thanks for mentioning this. It's an interesting thread. I posted a response: https://groups.google.com/forum/#!msg/golang-nuts/rxOz-QMyHr4/BbNR_H1zyKkJ Andrei
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On 2/17/14, 10:59 AM, Jesse Phillips wrote: On Monday, 17 February 2014 at 17:03:46 UTC, Andrei Alexandrescu wrote: On 2/16/14, 12:09 PM, Russel Winder wrote: Someone with serious knowledge should wade into this campaign of FUD. The whole thread is wrong-headed. Thanks for mentioning this. It's an interesting thread. I posted a response: https://groups.google.com/forum/#!msg/golang-nuts/rxOz-QMyHr4/BbNR_H1zyKkJ Andrei It looks like you've been completely ignored. This may be partly a logistics issue - my name appears garbled. And I love how the Sort package is their great example of implementing a generic algorithm. I consider it a package which demonstrates the problem with lack of generics. I would agree that Go's sort tends to confuse people about what problems can and cannot be solved with Go-style interfaces. Andrei
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Monday, 17 February 2014 at 17:03:46 UTC, Andrei Alexandrescu wrote: On 2/16/14, 12:09 PM, Russel Winder wrote: Someone with serious knowledge should wade into this campaign of FUD. The whole thread is wrong-headed. Thanks for mentioning this. It's an interesting thread. I posted a response: https://groups.google.com/forum/#!msg/golang-nuts/rxOz-QMyHr4/BbNR_H1zyKkJ Andrei It looks like you've been completely ignored. And I love how the Sort package is their great example of implementing a generic algorithm. I consider it a package which demonstrates the problem with lack of generics.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
Am 17.02.2014 20:08, schrieb Andrei Alexandrescu: On 2/17/14, 10:59 AM, Jesse Phillips wrote: On Monday, 17 February 2014 at 17:03:46 UTC, Andrei Alexandrescu wrote: On 2/16/14, 12:09 PM, Russel Winder wrote: Someone with serious knowledge should wade into this campaign of FUD. The whole thread is wrong-headed. Thanks for mentioning this. It's an interesting thread. I posted a response: https://groups.google.com/forum/#!msg/golang-nuts/rxOz-QMyHr4/BbNR_H1zyKkJ Andrei It looks like you've been completely ignored. This may be partly a logistics issue - my name appears garbled. And I love how the Sort package is their great example of implementing a generic algorithm. I consider it a package which demonstrates the problem with lack of generics. I would agree that Go's sort tends to confuse people about what problems can and cannot be solved with Go-style interfaces. Andrei 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
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Mon, 2014-02-17 at 21:00 +0100, Paulo Pinto wrote: Am 17.02.2014 20:08, schrieb Andrei Alexandrescu: On 2/17/14, 10:59 AM, Jesse Phillips wrote: On Monday, 17 February 2014 at 17:03:46 UTC, Andrei Alexandrescu wrote: On 2/16/14, 12:09 PM, Russel Winder wrote: Someone with serious knowledge should wade into this campaign of FUD. The whole thread is wrong-headed. Thanks for mentioning this. It's an interesting thread. I posted a response: https://groups.google.com/forum/#!msg/golang-nuts/rxOz-QMyHr4/BbNR_H1zyKkJ Andrei It looks like you've been completely ignored. This may be partly a logistics issue - my name appears garbled. And I love how the Sort package is their great example of implementing a generic algorithm. I consider it a package which demonstrates the problem with lack of generics. It is hard to disagree, and I really like Go for its goroutines and channels. I would agree that Go's sort tends to confuse people about what problems can and cannot be solved with Go-style interfaces. Andrei 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. There does appear to be a level of intransigence about the expression of the opinion, and indeed the whole dichotomy. I admire the attempt to provide strongly typed duck typing, and the challenge to the need for generics as an orthodoxy. However there is a time to declare a position not entirely viable and to look for a solution. My feeling is the Go core team should move from we haven't seen a generics system we like to we are actively investigating a generics system for Go. Sadly this can only be for Go 2 since they have declared an absolute backward compatibility position for Go 1. They are too focused with Java and C++ as models, to accept anything else as proof of them being wrong. Not to mention C#. And OCaml and Haskell. Sadly I don't have the time in the near future to try and design and implement a CSP (process and channels) system for D. Currently JCSP, C ++CSP2, PyCSP, Python-CSP are the realizations of CSP I know of, and all of them were a lot of work. Go has effectively proved that CSP (or at least it's equivalence of it: Rob Pike maintains he developed hos ideas independently in the Newsqueak, Alef, Limbo sequence) is an extremely sensible architecture for high performance concurrency and parallelism in a commercial context. Analogously DataRush has shown the effectiveness of a more general dataflow model in Big Data. What we really need is a couple of PhD students to work on this. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Monday, 17 February 2014 at 17:03:46 UTC, Andrei Alexandrescu
wrote:
On 2/16/14, 12:09 PM, Russel Winder wrote:
Someone with serious knowledge should wade into this campaign
of FUD.
The whole thread is wrong-headed.
Thanks for mentioning this. It's an interesting thread. I
posted a response:
https://groups.google.com/forum/#!msg/golang-nuts/rxOz-QMyHr4/BbNR_H1zyKkJ
Andrei
The fears about slow code are especially odd since ad-hoc
templates are an important tool to force constant folding and
many optimizations that requires inlining.
Moreover Go with first its class interface{} values will pay a
heavy price in dynamic dispatch, something that is optional and
not really pay what you use.
Granted code bloat is a real thing and you _might_ have
instruction cache problems, but the problem only ever show itself
when the working set of code exceed the instruction cache
capacity. Ie. a huge executable might not be a good predictor for
reduced instruction cache efficiency.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Monday, 17 February 2014 at 22:19:24 UTC, ponce wrote: Granted code bloat is a real thing and you _might_ have instruction cache problems, but the problem only ever show itself when the working set of code exceed the instruction cache capacity. Ie. a huge executable might not be a good predictor for reduced instruction cache efficiency. I heard a story of a C++ gamedev team that would use type-punning to reduce code size. std::vectorvoid* would be the only instantiation of std::vector + casts everywhere. That was for console binaries.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Monday, 17 February 2014 at 03:59:15 UTC, logicchains wrote: On Sunday, 16 February 2014 at 20:29:04 UTC, Walter Bright wrote: It's not exactly true. What has happened is I spent a LOT of time trying to make my C/C++ compiler fast. That experience has enabled me to design D so it is fundamentally fast to compile, and enabled me to pick an internal design for the compiler that I know will be fast. Isn't this kind of the point? The Go devs don't have the somewhat unique experience of having written a C++ compiler from scratch to guide them in implementing generics in Go, so it doesn't make practical sense to say D has fast-compiling generics, so why can't Go?. Just because a good generics system is theoretically possible, doesn't mean it's easy to design. Personally, I think comparing C++ to C shows that no generics is better than poorly designed generics (C++ templates). 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?
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Monday, 17 February 2014 at 19:08:46 UTC, Andrei Alexandrescu wrote: On 2/17/14, 10:59 AM, Jesse Phillips wrote: Andrei It looks like you've been completely ignored. This may be partly a logistics issue - my name appears garbled. Have you posted to that Google group before? If you hadn't, you would have had to wait a few hours for your post to be moderated before it appeared. I believe this is what happened, as I was active on the thread around the time it says you posted, but I don't recall seeing your post. I imagine that's why nobody noticed your comment, as it was inserted in the middle of the thread, so only people reading the whole thread from start to finish would notice it. Regarding the whole generics thing, I think it's important to note that the focus on them slowing compile time has been by the community, not so much the core designers. The language devs state that they just haven't found a generics model they're comfortable with yet. It's also work noting that Go's developers are from a C background; while they are of course extremely competent, there is no substitute for experience, and in my understanding they don't have the same experience with templates that you and Walter have via you being a C++ guru and him having written a C++ compiler. Lacking that experience, a much greater amount of foresight and planning is required to ensure that the form of generics implemented doesn't come back to bite Go, so I think their delay is understandable. There's also the Go 1.x compatability promise, so even if implementing generics was the number one priority in the language, it still couldn't happen until a few years from now when Go 2.0 is released.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Tuesday, 18 February 2014 at 01:21:43 UTC, logicchains wrote: Regarding the whole generics thing, I think it's important to note that the focus on them slowing compile time has been by the community, not so much the core designers. The language devs state that they just haven't found a generics model they're comfortable with yet. That maybe be true, but they also aren't looking for a solution, they don't see an urgency. This has made it so they don't take the time to explain the problems with each (there was a blog I had read which did some detailing of the trade offs, but can't find it to see if it was from one of the devs). I have my doubts that they will make generics a priority for 2.0 either. Of course, implementing generics isn't going to be enough for me. It is just an indicator. You are correct that they will want to get the implementation correct and avoid ruining Go as we know it; that just means they'll avoid all the other positive things I enjoy about D's templates and meta-programming features.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On 2/17/2014 1:32 AM, Paulo Pinto wrote: On Monday, 17 February 2014 at 05:51:09 UTC, Nick Sabalausky wrote: Besides, I suspect the #1 optimization in making a fast-to-compile language is just simply Don't make C++. Well, supporting modules would already help. With luck C++ will get them around 2020. I think it won't matter by then. Heh. I shudder to think what they might end up looking like, too. C++ deserves some credit for gaining some of D's features here and there, but they're never (and likely can't ever) be as nice and clean as their D counterparts.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Tuesday, 18 February 2014 at 06:11:38 UTC, Nick Sabalausky wrote: On 2/17/2014 1:32 AM, Paulo Pinto wrote: On Monday, 17 February 2014 at 05:51:09 UTC, Nick Sabalausky wrote: Besides, I suspect the #1 optimization in making a fast-to-compile language is just simply Don't make C++. Well, supporting modules would already help. With luck C++ will get them around 2020. I think it won't matter by then. Heh. I shudder to think what they might end up looking like, too. C++ deserves some credit for gaining some of D's features here and there, but they're never (and likely can't ever) be as nice and clean as their D counterparts. Apple is driving it, it is going to be a kind of hack so that they can marry the world of #include with a future world of import. You need a module map that describes the structure of the module. Which header files are responsible, and what libraries are part of the module. Here is the latest version I know of, http://clang.llvm.org/docs/Modules.html -- Paulo
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Tuesday, 18 February 2014 at 05:11:00 UTC, Jesse Phillips
wrote:
Of course, implementing generics isn't going to be enough for
me. It is just an indicator. You are correct that they will
want to get the implementation correct and avoid ruining Go
as we know it; that just means they'll avoid all the other
positive things I enjoy about D's templates and
meta-programming features.
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 myFunT, S(a, b ~T, u, v ~S) (~T, ~S, ~S){
return a + b, u*u, v*v
}
Nothing like D's capabilities, but it's enough for most of my
needs. What's the problem with just using an unofficial
preprocessor for generics? If one package became popular enough
amongst the community, that might be enough to convince the devs
to adopt it when Go 2.0 comes around.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Tuesday, 18 February 2014 at 06:50:36 UTC, logicchains wrote:
On Tuesday, 18 February 2014 at 05:11:00 UTC, Jesse Phillips
wrote:
Of course, implementing generics isn't going to be enough for
me. It is just an indicator. You are correct that they will
want to get the implementation correct and avoid ruining Go
as we know it; that just means they'll avoid all the other
positive things I enjoy about D's templates and
meta-programming features.
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 myFunT, S(a, b ~T, u, v ~S) (~T, ~S, ~S){
return a + b, u*u, v*v
}
Nothing like D's capabilities, but it's enough for most of my
needs. What's the problem with just using an unofficial
preprocessor for generics? If one package became popular enough
amongst the community, that might be enough to convince the
devs to adopt it when Go 2.0 comes around.
It is like traveling back in time when parametric polymorphism
was debated in university papers and everyone was inventing their
own code generation tool.
Back to mid-90's compiler technology when only Ada supported
generics, C++ started to adopt some form of genericity at ISO
meetings and everything else where academic languages like
Eiffel, Modula-3 or Standadard ML.
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.
--
Paulo
[Fwd: Re: [go-nuts] Re: Generics false dichotomy]
Someone with serious knowledge should wade into this campaign of FUD. The whole thread is wrong-headed. --- Forwarded Message From: Aram Hăvărneanu ara...@mgk.ro To: Jonathan Amsterdam jbamster...@gmail.com Cc: golang-nuts golang-n...@googlegroups.com, Michael Jones m...@google.com, Jonathan Barnard jonathan.t.barn...@gmail.com Subject: Re: [go-nuts] Re: Generics false dichotomy Date: Sun, 16 Feb 2014 11:03:38 +0100 On Sun, Feb 16, 2014 at 2:51 AM, Jonathan Amsterdam jbamster...@gmail.com wrote: D doesn't pay too much of a compilation penalty for its generics D pays a huge penalty in compilation speed for generics. D generics are turing complete, making compilation time potentially unbounded. Dmd might build their standard library quickly, but this says nothing about the fundamental issue. Potentially unbounded compilation times are unacceptable for Go. -- Aram Hăvărneanu -- 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/groups/opt_out. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On 2/16/2014 12:09 PM, Russel Winder wrote: Someone with serious knowledge should wade into this campaign of FUD. The whole thread is wrong-headed. A handy link: https://groups.google.com/forum/#!topic/golang-nuts/rxOz-QMyHr4
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On 2/16/2014 12:09 PM, Russel Winder wrote: Someone with serious knowledge should wade into this campaign of FUD. The whole thread is wrong-headed. I enjoyed this comment: The D guys have thrown a lot of time behind making their compiler fast It's not exactly true. What has happened is I spent a LOT of time trying to make my C/C++ compiler fast. That experience has enabled me to design D so it is fundamentally fast to compile, and enabled me to pick an internal design for the compiler that I know will be fast. The actual time I've spent profiling and tuning DMD for speed has been minimal, though I've still gotten caught by a few mistakes. And there's this regression: https://d.puremagic.com/issues/show_bug.cgi?id=12137
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
Russel Winder: [Quoted] Potentially unbounded compilation times are unacceptable for Go. That person still has to realize that in D there's also compile-time function execution, that could lead to equally unbounded compilation times, and is currently quite slow... :-) Bye, bearophile
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
Am 16.02.2014 21:29, schrieb Walter Bright: On 2/16/2014 12:09 PM, Russel Winder wrote: Someone with serious knowledge should wade into this campaign of FUD. The whole thread is wrong-headed. I enjoyed this comment: The D guys have thrown a lot of time behind making their compiler fast It's not exactly true. What has happened is I spent a LOT of time trying to make my C/C++ compiler fast. That experience has enabled me to design D so it is fundamentally fast to compile, and enabled me to pick an internal design for the compiler that I know will be fast. The actual time I've spent profiling and tuning DMD for speed has been minimal, though I've still gotten caught by a few mistakes. And there's this regression: https://d.puremagic.com/issues/show_bug.cgi?id=12137 Walter, they tend to speak about Go compilation times as if Modula-2, Turbo Pascal, and who knows what else, didn't already had that in the mid-80's. Go's fast compilation times are easy to sell to developers that never used native code compilers besides C and C++ ones. So many in the Go community think it was kind of an achievement of language toolchain. -- Paulo
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On 2/16/2014 12:54 PM, bearophile wrote: That person still has to realize that in D there's also compile-time function execution, that could lead to equally unbounded compilation times, Amazingly, D hasn't solved the halting problem. I'm so ashamed :-)
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On 2/16/2014 12:09 PM, Russel Winder wrote: Someone with serious knowledge should wade into this campaign of FUD. The whole thread is wrong-headed. However, I agree that there may well be other reasons to not have them in Go, such as their simply not being especially useful in day-to-day programming; but I don't have enough experience with meta-programming to make such a judgment. Some years ago, I felt exactly the same way about generics. I have recently written some very interesting D programs, and I would have shocked my former self with nearly every function being a template.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
--- Forwarded Message From: Aram Hăvărneanu ara...@mgk.ro To: Jonathan Amsterdam jbamster...@gmail.com Cc: golang-nuts golang-n...@googlegroups.com, Michael Jones m...@google.com, Jonathan Barnard jonathan.t.barn...@gmail.com Subject: Re: [go-nuts] Re: Generics false dichotomy Date: Sun, 16 Feb 2014 11:03:38 +0100 D pays a huge penalty in compilation speed for generics. D generics are turing complete, making compilation time potentially unbounded. Dmd might build their standard library quickly, but this says nothing about the fundamental issue. Potentially unbounded compilation times are unacceptable for Go. Go pays a huge penalty in execution speed. Go is turing complete, making runtime potentially unbounded. The programs written in Go that have actually been created might execute quickly, but this says nothing about the fundamental issue. Potentially unbounded execution times are unacceptable for D. But Go's fundamental problems don't even stop there. In order to build even just the Go compiler itself, a series of shell scripts are provided http://code.google.com/p/go/source/browse/src. Batch and bash are both turing complete, therefore Go's very own buildscripts have potentially unbounded compilation times. In reality, they won't actually execute forever unless someone screws up and does something stupid, but reality, of course, is unimportant. What's *really* important here are highly unlikely scenarios that have yet to ever actually surface and can't be handled without resorting to such inexcusably difficult and drastic measures as pressing Ctrl and C simultaneously. Go-nuts really is nuts, apparently.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Sunday, 16 February 2014 at 20:29:04 UTC, Walter Bright wrote: It's not exactly true. What has happened is I spent a LOT of time trying to make my C/C++ compiler fast. That experience has enabled me to design D so it is fundamentally fast to compile, and enabled me to pick an internal design for the compiler that I know will be fast. Isn't this kind of the point? The Go devs don't have the somewhat unique experience of having written a C++ compiler from scratch to guide them in implementing generics in Go, so it doesn't make practical sense to say D has fast-compiling generics, so why can't Go?. Just because a good generics system is theoretically possible, doesn't mean it's easy to design. Personally, I think comparing C++ to C shows that no generics is better than poorly designed generics (C++ templates).
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On 2/16/2014 10:59 PM, logicchains wrote: On Sunday, 16 February 2014 at 20:29:04 UTC, Walter Bright wrote: It's not exactly true. What has happened is I spent a LOT of time trying to make my C/C++ compiler fast. That experience has enabled me to design D so it is fundamentally fast to compile, and enabled me to pick an internal design for the compiler that I know will be fast. Isn't this kind of the point? The Go devs don't have the somewhat unique experience of having written a C++ compiler from scratch to guide them in implementing generics in Go, The Go devs have some pretty strong backgrounds themselves. I think it's reasonable to figure they can handle the task just fine. Besides, I suspect the #1 optimization in making a fast-to-compile language is just simply Don't make C++.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Monday, 17 February 2014 at 05:51:09 UTC, Nick Sabalausky wrote: On 2/16/2014 10:59 PM, logicchains wrote: On Sunday, 16 February 2014 at 20:29:04 UTC, Walter Bright wrote: It's not exactly true. What has happened is I spent a LOT of time trying to make my C/C++ compiler fast. That experience has enabled me to design D so it is fundamentally fast to compile, and enabled me to pick an internal design for the compiler that I know will be fast. Isn't this kind of the point? The Go devs don't have the somewhat unique experience of having written a C++ compiler from scratch to guide them in implementing generics in Go, The Go devs have some pretty strong backgrounds themselves. I think it's reasonable to figure they can handle the task just fine. I partly agree. If you follow the discussions, they seem to focus mainly in Java, C++, while ignoring D, Ada, Eiffel, Modula-3, OCaml, Haskell, .NET and a few others. Besides, I suspect the #1 optimization in making a fast-to-compile language is just simply Don't make C++. Well, supporting modules would already help. With luck C++ will get them around 2020. I think it won't matter by then. -- Paulo
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Monday, 17 February 2014 at 03:48:28 UTC, Nick Sabalausky wrote: --- Forwarded Message From: Aram Hăvărneanu ara...@mgk.ro To: Jonathan Amsterdam jbamster...@gmail.com Cc: golang-nuts golang-n...@googlegroups.com, Michael Jones m...@google.com, Jonathan Barnard jonathan.t.barn...@gmail.com Subject: Re: [go-nuts] Re: Generics false dichotomy Date: Sun, 16 Feb 2014 11:03:38 +0100 D pays a huge penalty in compilation speed for generics. D generics are turing complete, making compilation time potentially unbounded. Dmd might build their standard library quickly, but this says nothing about the fundamental issue. Potentially unbounded compilation times are unacceptable for Go. Go pays a huge penalty in execution speed. Go is turing complete, making runtime potentially unbounded. The programs written in Go that have actually been created might execute quickly, but this says nothing about the fundamental issue. Potentially unbounded execution times are unacceptable for D. But Go's fundamental problems don't even stop there. In order to build even just the Go compiler itself, a series of shell scripts are provided http://code.google.com/p/go/source/browse/src. Batch and bash are both turing complete, therefore Go's very own buildscripts have potentially unbounded compilation times. In reality, they won't actually execute forever unless someone screws up and does something stupid, but reality, of course, is unimportant. What's *really* important here are highly unlikely scenarios that have yet to ever actually surface and can't be handled without resorting to such inexcusably difficult and drastic measures as pressing Ctrl and C simultaneously. Go-nuts really is nuts, apparently. Worse, is that they think as acceptable to create templating tools, similar to what Borland and others offered with their compilers when templates started to be discusses at ISO. Sometime around the mid 90's, almost 20 years ago! Having a strong typed language without generics support in the 21st century is not understandable. -- Paulo
