www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [Fwd: Re: [go-nuts] Re: Generics false dichotomy]

reply Russel Winder <russel winder.org.uk> writes:
Someone with serious knowledge should wade into this campaign of FUD.
The whole thread is wrong-headed.

------- Forwarded Message --------

 From: Aram Hăvărneanu <aram.h mgk.ro>
 To: Jonathan Amsterdam <jbamsterdam gmail.com>
 Cc: golang-nuts <golang-nuts googlegroups.com>, Michael Jones
 <mtj google.com>, Jonathan Barnard <jonathan.t.barnard 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
 <jbamsterdam 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+unsubscribe 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.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
Feb 16 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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
Feb 16 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
Feb 16 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
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
Feb 16 2014
prev sibling parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
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).
Feb 16 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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 

simply "Don't make C++".
Feb 16 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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.



 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
Feb 16 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 2/17/2014 1:32 AM, Paulo Pinto wrote:

 On Monday, 17 February 2014 at 05:51:09 UTC, Nick Sabalausky wrote:



 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.
Feb 17 2014
parent "Paulo Pinto" <pjmlp progtools.org> writes:
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:



 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
Feb 17 2014
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
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.
Feb 22 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
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.
Feb 22 2014
prev sibling parent reply "Asman01" <jckj33 gmail.com> writes:
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?
Feb 17 2014
parent Russel Winder <russel winder.org.uk> writes:
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
Feb 20 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Feb 16 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
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 :-)
Feb 16 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 16 2014
parent Shammah Chancellor <anonymous coward.com> writes:
On 2014-02-16 22:05:10 +0000, 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 

delegates at runtime to do something similar -- but the code is a 
nightmare.

-S
Feb 23 2014
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
 ------- Forwarded Message --------

 From: Aram Hăvărneanu <aram.h mgk.ro>
 To: Jonathan Amsterdam <jbamsterdam gmail.com>
 Cc: golang-nuts <golang-nuts googlegroups.com>, Michael Jones
 <mtj google.com>, Jonathan Barnard <jonathan.t.barnard 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.
Feb 16 2014
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 17 February 2014 at 03:48:28 UTC, Nick Sabalausky 
wrote:

 ------- Forwarded Message --------

 From: Aram Hăvărneanu <aram.h mgk.ro>
 To: Jonathan Amsterdam <jbamsterdam gmail.com>
 Cc: golang-nuts <golang-nuts googlegroups.com>, Michael Jones
 <mtj google.com>, Jonathan Barnard 
 <jonathan.t.barnard 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
Feb 16 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 17 2014
next sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
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.
Feb 17 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 17 2014
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
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
Feb 17 2014
next sibling parent Russel Winder <russel winder.org.uk> writes:
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.




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.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
Feb 17 2014
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Feb 18 2014
prev sibling parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
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.
Feb 17 2014
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
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.
Feb 17 2014
parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
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 myFun<T, 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.
Feb 17 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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 myFun<T, 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
Feb 17 2014
next sibling parent reply "logicchains" <jonathan.t.barnard gmail.com> writes:
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?
Feb 18 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
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).
Feb 18 2014
prev sibling next sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
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
Feb 18 2014
parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
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.
Feb 18 2014
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
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 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
Feb 20 2014
next sibling parent reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
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.
Feb 20 2014
parent reply Russel Winder <russel winder.org.uk> writes:
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
Feb 20 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 20 2014
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
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 based. Coming from C, Self, Lisp, the mindset is different.




before the said languages got any form of generics.

I don't miss those days.



--
Paulo
Feb 20 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/20/2014 12:17 PM, Paulo Pinto wrote:


 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?
Feb 20 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 20.02.2014 23:09, schrieb Walter Bright:

 On 2/20/2014 12:17 PM, Paulo Pinto wrote:


 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
Feb 20 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
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), 

 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).
Feb 21 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 21 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
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/
Feb 21 2014
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
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.
Feb 21 2014
parent reply "Meta" <jared771 gmail.com> writes:
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
Feb 21 2014
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
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).
Feb 21 2014
parent "Meta" <jared771 gmail.com> writes:
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.
Feb 21 2014
prev sibling parent reply "Araq" <rumpf_a web.de> writes:
 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.
Feb 20 2014
parent "Paulo Pinto" <pjmlp progtools.org> writes:
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! :)
Feb 20 2014
prev sibling parent Ziad Hatahet <hatahet gmail.com> writes:
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
Feb 20 2014
prev sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
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)
Feb 18 2014
prev sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
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.
Feb 17 2014
next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
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::vector<void*> would be the only 
instantiation of std::vector + casts everywhere. That was for 
console binaries.
Feb 17 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"ponce"  wrote in message news:loreiqmesicuysdtmgvb forum.dlang.org...


 I heard a story of a C++ gamedev team that would use type-punning to 
 reduce code size. std::vector<void*> would be the only instantiation of 
 std::vector + casts everywhere. That was for console binaries.


We had a similar thing in the compiler for a long time, with void* arrays 
underneath and a very thin (inlineable) typesafe wrapper on top.  I met a 
lot of resistance when trying to change it to a fully templated struct, 
until benchmarking showed the performance difference was negligible.
Feb 17 2014
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
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
Feb 20 2014
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 20 February 2014 at 20:26:40 UTC, Russel Winder 
wrote:

 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.


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
Feb 20 2014
prev sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 20 February 2014 at 20:26:40 UTC, Russel Winder 
wrote:

 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.


I meant it in the sense of actual slowdown related to binary 
size, or impossibility to fit a program on some embedded hardware.
Feb 21 2014