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 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 suspect the #1 optimization in making a fast-to-compile language is just simply "Don't make C++".
Feb 16 2014
next sibling parent 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:

 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.
Feb 17 2014
prev sibling 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 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 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
Feb 23 2014
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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.
 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
Feb 16 2014
prev sibling next sibling 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 next 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 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 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
prev sibling next sibling 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 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 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
Feb 20 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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?
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:
 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
Feb 20 2014
parent 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
prev sibling 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 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 next sibling parent "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
prev sibling 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.

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.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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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:

 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
Feb 17 2014
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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 next 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 next sibling parent 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 are coming from C++, Java, D, C# where the mental model is generics based. Coming from C, Self, Lisp, the mindset is different. So the evidence is that the last 20 years hasn't resulted in just one answer, we are still in a period of interesting work being done both with and without generics. The analysis that is missing here is what works and doesn't work with and without generics. We have some evidence just no final conclusion. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 20 2014
prev sibling next sibling parent Ziad Hatahet <hatahet gmail.com> writes:
--089e0160cd1c9698bb04f2dae92a
Content-Type: text/plain; charset=ISO-8859-1

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 --089e0160cd1c9698bb04f2dae92a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T= hu, Feb 20, 2014 at 10:21 AM, Russel Winder <span dir=3D"ltr">&lt;<a href= =3D"mailto:russel winder.org.uk" target=3D"_blank">russel winder.org.uk</a>= &gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex">The thing here is that those people who are actually using= Go for real<br> problems, are finding ways of using the interface{} construct to achieve<br=

iv><div>The downside to doing that; however, is taking a performance hit, c= orrect? 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.</div> <div><br></div><div>--<br>Ziad</div><div>=A0</div></div></div></div> --089e0160cd1c9698bb04f2dae92a--
Feb 20 2014
prev sibling next sibling parent "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:

 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
prev sibling next sibling parent 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
prev sibling next sibling 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 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
prev sibling next sibling parent "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
prev sibling next sibling 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 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 next 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
prev sibling next sibling parent "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), 
 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).
Feb 21 2014
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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