> 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.

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.

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?

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

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! :)

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

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.

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).

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.

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/