www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Opportunity

reply Russel Winder <russel winder.org.uk> writes:
<<Originally sent to wrong list, sorry if this appears a cross-posting.>>

Given that the entire C++ standards committee will be at ACCU 2013, I've
decided to do a lightning talk on why D and Go are better tools for any
native coding problem than C++.

	pigeon[500] pigeons;
	pigeons[random(500)] =3D new cat;

:-)
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Apr 08 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/8/13 10:22 AM, Russel Winder wrote:

 <<Originally sent to wrong list, sorry if this appears a cross-posting.>>

 Given that the entire C++ standards committee will be at ACCU 2013, I've
 decided to do a lightning talk on why D and Go are better tools for any
 native coding problem than C++.

 	pigeon[500] pigeons;
 	pigeons[random(500)] = new cat;

 :-)


This is great. Let us know how we can support you.

It would be interesting to hear how your argument for Go addresses its 
tenuous interface with C, pervasive indirect calls, and compulsive use 
of GC.


Andrei
Apr 08 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 08.04.2013 18:11, schrieb Andrei Alexandrescu:

 On 4/8/13 10:22 AM, Russel Winder wrote:

 <<Originally sent to wrong list, sorry if this appears a cross-posting.>>

 Given that the entire C++ standards committee will be at ACCU 2013, I've
 decided to do a lightning talk on why D and Go are better tools for any
 native coding problem than C++.

     pigeon[500] pigeons;
     pigeons[random(500)] = new cat;

 :-)


 This is great. Let us know how we can support you.

 It would be interesting to hear how your argument for Go addresses its
 tenuous interface with C, pervasive indirect calls, and compulsive use
 of GC.


 Andrei


Lets not forget the lack of generics, the religious view against dynamic 
linking and errors for unused variables and imports.
Apr 08 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 08 Apr 2013 23:51:12 +0200
Paulo Pinto <pjmlp progtools.org> wrote:

 
 ...[Go's] religious view against dynamic linking... 
 


And that's despite Google's other product, Android, expecting
certain things to be linked dynamically - a bit of corporate
schizophrenia which I find rather amusing. :)
Apr 08 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 08, 2013 at 06:55:39PM -0400, Nick Sabalausky wrote:

 On Mon, 08 Apr 2013 23:51:12 +0200
 Paulo Pinto <pjmlp progtools.org> wrote:

 
 ...[Go's] religious view against dynamic linking... 
 


 
 And that's despite Google's other product, Android, expecting
 certain things to be linked dynamically - a bit of corporate
 schizophrenia which I find rather amusing. :)


[...]

Corporate schizophrenia is not all that rare. In fact, any corporation
of sufficiently large size often exhibits such symptoms, IME.  The view
of corporations as single, coherent entities is one I've always been
skeptical of.

Be that as it may, upon my latest update of git HEAD of dmd / druntime /
phobos, I noticed the beginnings of dynamic linking in Phobos. I haven't
tested how well this works with 3rd party D dynamic libraries yet, but
this is a wonderful step forward! I'm looking forward to full dynamic
library support in D in the near future!!


T

-- 
Real Programmers use "cat > a.out".
Apr 08 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 8 April 2013 at 21:51:11 UTC, Paulo Pinto wrote:

 Am 08.04.2013 18:11, schrieb Andrei Alexandrescu:

 On 4/8/13 10:22 AM, Russel Winder wrote:

 <<Originally sent to wrong list, sorry if this appears a 
 cross-posting.>>

 Given that the entire C++ standards committee will be at ACCU 
 2013, I've
 decided to do a lightning talk on why D and Go are better 
 tools for any
 native coding problem than C++.

    pigeon[500] pigeons;
    pigeons[random(500)] = new cat;

 :-)


 This is great. Let us know how we can support you.

 It would be interesting to hear how your argument for Go 
 addresses its
 tenuous interface with C, pervasive indirect calls, and 
 compulsive use
 of GC.


 Andrei


 Lets not forget the lack of generics, the religious view 
 against dynamic linking and errors for unused variables and 
 imports.


The error for unrecheable statement is really of the same kind.
Apr 08 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 9 April 2013 at 00:47:09 UTC, deadalnix wrote:

 On Monday, 8 April 2013 at 21:51:11 UTC, Paulo Pinto wrote:

 Am 08.04.2013 18:11, schrieb Andrei Alexandrescu:

 On 4/8/13 10:22 AM, Russel Winder wrote:

 <<Originally sent to wrong list, sorry if this appears a 
 cross-posting.>>

 Given that the entire C++ standards committee will be at 
 ACCU 2013, I've
 decided to do a lightning talk on why D and Go are better 
 tools for any
 native coding problem than C++.

   pigeon[500] pigeons;
   pigeons[random(500)] = new cat;

 :-)


 This is great. Let us know how we can support you.

 It would be interesting to hear how your argument for Go 
 addresses its
 tenuous interface with C, pervasive indirect calls, and 
 compulsive use
 of GC.


 Andrei


 Lets not forget the lack of generics, the religious view 
 against dynamic linking and errors for unused variables and 
 imports.


 The error for unrecheable statement is really of the same kind.


I know it is hard to balance these type of errors, but unused 
imports and variables seems a bit extreme.

--
Paulo
Apr 08 2013
next sibling parent reply Timothee Cour <thelastmammoth gmail.com> writes:
 I know it is hard to balance these type of errors, but unused imports and
 variables seems a bit extreme.


seems like go won't support temporarily suppressing such errors (see
http://weekly.golang.org/doc/faq#unused_variables_and_imports) (nor in
fact having compile flags affecting semantics, so no
version(identifier) constructs).

However D should have opt-in flags for those:
--warn_unused_variable
--warn_unused_import
--warn_unused_lib (for pragma lib statements)
--warn_unused_version (for unused version identifiers, indicating a
potentially mis-spelt version identifier given at compile time)
--warn_unreachable_code
likewise, with error instead of warn

Is there any work on that?
Apr 09 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 9 April 2013 at 07:18:45 UTC, Timothee Cour wrote:

 I know it is hard to balance these type of errors, but unused 
 imports and
 variables seems a bit extreme.


 seems like go won't support temporarily suppressing such errors 
 (see
 http://weekly.golang.org/doc/faq#unused_variables_and_imports) 
 (nor in
 fact having compile flags affecting semantics, so no
 version(identifier) constructs).


They something like version(identifier), you are forced to have 
separate files for each version(identifier), where identifier is 
an architecture or OS.

module.go
module_linux.go
module_windows.go
module_arm.go

Actually I prefer this way when coding in any language with 
conditional compilation support, because I have seen one too many 
#ifdef spaghetti in enterprise code.

It always starts in one single spot because of a function that 
requires different compilation support, with the amount of people 
coming and going, eventually it grows to a point where new 
developers have to take the role of the pre-processor to make any 
sense out of the code.




 However D should have opt-in flags for those:
 --warn_unused_variable
 --warn_unused_import
 --warn_unused_lib (for pragma lib statements)
 --warn_unused_version (for unused version identifiers, 
 indicating a
 potentially mis-spelt version identifier given at compile time)
 --warn_unreachable_code
 likewise, with error instead of warn

 Is there any work on that?


Seems like a nice idea.
Apr 09 2013
parent reply Timothee Cour <thelastmammoth gmail.com> writes:
 Actually I prefer this way when coding in any language with conditional
compilation support, because I have seen one too many #ifdef spaghetti in
enterprise code.


The problem is mitigated in D because conditional compilation follows
the language scoping. So the benefits of DRY code outweigh the added
complexity, which is very minor with proper IDE support: visualD
supports graying out bad code blacks that are known statically to be
false, and I've just made similar enhancement request for monod, see
https://github.com/aBothe/Mono-D/issues/269
(working on that with Alexander Bothe)

On Tue, Apr 9, 2013 at 12:42 AM, Paulo Pinto <pjmlp progtools.org> wrote:

 On Tuesday, 9 April 2013 at 07:18:45 UTC, Timothee Cour wrote:

 I know it is hard to balance these type of errors, but unused imports and
 variables seems a bit extreme.



 seems like go won't support temporarily suppressing such errors (see
 http://weekly.golang.org/doc/faq#unused_variables_and_imports) (nor in
 fact having compile flags affecting semantics, so no
 version(identifier) constructs).



 They something like version(identifier), you are forced to have separate
 files for each version(identifier), where identifier is an architecture or
 OS.

 module.go
 module_linux.go
 module_windows.go
 module_arm.go

 Actually I prefer this way when coding in any language with conditional
 compilation support, because I have seen one too many #ifdef spaghetti in
 enterprise code.

 It always starts in one single spot because of a function that requires
 different compilation support, with the amount of people coming and going,
 eventually it grows to a point where new developers have to take the role of
 the pre-processor to make any sense out of the code.





 However D should have opt-in flags for those:
 --warn_unused_variable
 --warn_unused_import
 --warn_unused_lib (for pragma lib statements)
 --warn_unused_version (for unused version identifiers, indicating a
 potentially mis-spelt version identifier given at compile time)
 --warn_unreachable_code
 likewise, with error instead of warn

 Is there any work on that?



 Seems like a nice idea.
Apr 09 2013
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 9 April 2013 at 08:01:58 UTC, Timothee Cour wrote:

 Actually I prefer this way when coding in any language with 
 conditional compilation support, because I have seen one too 
 many #ifdef spaghetti in enterprise code.


 The problem is mitigated in D because conditional compilation 
 follows
 the language scoping. So the benefits of DRY code outweigh the 
 added
 complexity, which is very minor with proper IDE support: visualD
 supports graying out bad code blacks that are known statically 
 to be
 false, and I've just made similar enhancement request for 
 monod, see
 https://github.com/aBothe/Mono-D/issues/269
 (working on that with Alexander Bothe)


Nice :)
Apr 09 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, April 09, 2013 00:18:32 Timothee Cour wrote:

 I know it is hard to balance these type of errors, but unused imports and
 variables seems a bit extreme.


 
 seems like go won't support temporarily suppressing such errors (see
 http://weekly.golang.org/doc/faq#unused_variables_and_imports) (nor in
 fact having compile flags affecting semantics, so no
 version(identifier) constructs).
 
 However D should have opt-in flags for those:
 --warn_unused_import
 --warn_unused_lib (for pragma lib statements)
 likewise, with error instead of warn
 
 Is there any work on that?


No. As I understand it, Walter is against adding flags like that to dmd. He 
doesn't want a lot of stray flags which affect what is and isn't a warning and 
the like. He doesn't even like the fact that warnings exist in the first place 
- which I'm inclined to agree with. If it's something that has to be fixed, it 
should be an error, and if it doesn't have to be fix, don't warn about it, 
because any good programmer is going to have to fix all of the warnings anyway, 
ultimately making it not much different from an error anyway. Stuff like you're 
suggesting really should be left up to lint-like tools.


 --warn_unused_variable


Warning about unused variables could be a big problem, because they're heavily 
used in traits and RAII, and having -w makes _any_ kind of warnings worse, 
because they'll then affect what code does and doesn't compile.


 --warn_unused_version (for unused version identifiers, indicating a
 potentially mis-spelt version identifier given at compile time)


Impossible to warn about, because by definition, not all version identifiers
are 
used at once, and users can define their own.


 --warn_unreachable_code


This is already a warning.

- Jonathan M Davis
Apr 09 2013
next sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Tuesday, 9 April 2013 at 18:22:33 UTC, Jonathan M Davis wrote:

 Stuff like you're
 suggesting really should be left up to lint-like tools.


And profiling should be left to a profiling tool and 
documentation generation should be left to doxygen-like tool. 
Wait ...
Apr 09 2013
parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 9 April 2013 at 18:39:59 UTC, Tobias Pankrath wrote:

 On Tuesday, 9 April 2013 at 18:22:33 UTC, Jonathan M Davis 
 wrote:

 Stuff like you're
 suggesting really should be left up to lint-like tools.


 And profiling should be left to a profiling tool and 
 documentation generation should be left to doxygen-like tool. 
 Wait ...


Yes. Having profiler and ddoc as standard, but separate tools 
would have been better. But no need to make situation even worse.
Apr 09 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/9/2013 11:22 AM, Jonathan M Davis wrote:

 No. As I understand it, Walter is against adding flags like that to dmd. He
 doesn't want a lot of stray flags which affect what is and isn't a warning and
 the like. He doesn't even like the fact that warnings exist in the first place
 - which I'm inclined to agree with. If it's something that has to be fixed, it
 should be an error, and if it doesn't have to be fix, don't warn about it,
 because any good programmer is going to have to fix all of the warnings anyway,
 ultimately making it not much different from an error anyway. Stuff like you're
 suggesting really should be left up to lint-like tools.


Yes, that's an accurate assessment of my opinion on the matter. Warnings are a 
sign that one has made a mistake in the language design. That's perfectly 
acceptable in, say, C, where there are many known mistakes but the C Standards 
committee finds it impractical to fix. Hence, warnings become the most 
reasonable avenue to improve the language.

In D we have the opportunity to fix. Warnings in D are often proposed when 
reasonable people do not agree on what the correct behavior of the language 
should be, but I regard such compromises as a copout.

Another bad problem with warnings (and we also have this issue with deprecation 
errors) is an increasing amount of D code relies on asking the question "does 
this expression compile without errors". A lot of sand gets thrown in those 
gears with compiler switches that turn language features on and off.
Apr 09 2013
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 09 Apr 2013 14:22:21 -0400
"Jonathan M Davis" <jmdavisProg gmx.com> wrote:

 
 If it's something that has to be
 fixed, it should be an error, and if it doesn't have to be fix, don't
 warn about it, because any good programmer is going to have to fix
 all of the warnings anyway, ultimately making it not much different
 from an error anyway. Stuff like you're suggesting really should be
 left up to lint-like tools.
 


The way I see it, warnings *are* a lint tool. (Which is part of why I've
always disliked -w and use -wi instead.)
Apr 09 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, April 09, 2013 18:00:43 Nick Sabalausky wrote:

 On Tue, 09 Apr 2013 14:22:21 -0400
 
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote:

 If it's something that has to be
 fixed, it should be an error, and if it doesn't have to be fix, don't
 warn about it, because any good programmer is going to have to fix
 all of the warnings anyway, ultimately making it not much different
 from an error anyway. Stuff like you're suggesting really should be
 left up to lint-like tools.


 
 The way I see it, warnings *are* a lint tool. (Which is part of why I've
 always disliked -w and use -wi instead.)


Except that with a lint tool, you can ignore some of them and usually can 
adjust what it outputs, possibly have suppression files, etc. Such tools are 
far more flexible than simply turning all warnings on or turn them all off. And 
with compiler warnings, you need to fix them all - even if they really don't 
need to be fixed - or you risk missing the ones that _do_ matter among all the 
ones that don't. It's bad practice for a project to have any warnings at all. 
So, the situation with compiler warnings and lint tools is really quite 
different, especially when the compiler has no flags to control warnings except 
to turn them all on or off. I really wish that dmd had never had warnings in 
the first place. I think that we would have been better off without them. This
is one area where I'm actually in full agreement with Walter.

- Jonathan M Davis
Apr 09 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/9/2013 7:34 PM, Jonathan M Davis wrote:

 This is one area where I'm actually in full agreement with Walter.


I'm glad there's at least one!
Apr 09 2013
parent "Dicebot" <m.strashun gmail.com> writes:
On Wednesday, 10 April 2013 at 03:43:47 UTC, Walter Bright wrote:

 On 4/9/2013 7:34 PM, Jonathan M Davis wrote:

 This is one area where I'm actually in full agreement with 
 Walter.


 I'm glad there's at least one!


Count me in, too. Compiler warnings are atrocity.
Having standard lint-like tool packaged with compiler is not 
though ;)
Apr 10 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-04-10 04:34, Jonathan M Davis wrote:


 It's bad practice for a project to have any warnings at all.


It depends on what you want with warnings. If we decide that warnings 
are like a lint tool in D then it won't be bad practice.

-- 
/Jacob Carlborg
Apr 09 2013
prev sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Tuesday, 9 April 2013 at 18:22:33 UTC, Jonathan M Davis wrote:

 Is there any work on that?


 No. As I understand it, Walter is against adding flags like 
 that to dmd. He
 doesn't want a lot of stray flags which affect what is and 
 isn't a warning and
 the like. He doesn't even like the fact that warnings exist in 
 the first place
 - which I'm inclined to agree with. If it's something that has 
 to be fixed, it
 should be an error, and if it doesn't have to be fix, don't 
 warn about it,
 because any good programmer is going to have to fix all of the 
 warnings anyway,
 ultimately making it not much different from an error anyway. 
 Stuff like you're
 suggesting really should be left up to lint-like tools.


I personally think that there might be some benefit to an 
official discussion about lint-like tools. The schedule for the 
Conference has a lecture about AnalyzeD, which is the only 
official lint-like tool I've heard of so far. That is either 
meant to remain a third-party operation, or it is meant to at 
some point come closer to being an "official" lint-like tool.

I understand that D tries to clearly separate errors from legal 
code. But I'm sure lint-like tools have their place. It seems a 
little weird that there is nothing standard (that I've found, at 
least) about that topic. D has many standard things, unittest, 
ddoc, assert, etc., but no standard lint-like tools. My 
understanding of lint-like tools is that they address the areas a 
compiler shouldn't address, namely those which can generate false 
positives. But just because it could generate a false positive 
doesn't mean that it should be completely ignored.

Is there a way standardize a set of warnings such that some 
lint-like tool could be "compliant" with the standard warnings? A 
standard might help people focus on this issue better.
Apr 09 2013
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2013-04-08 at 23:51 +0200, Paulo Pinto wrote:
[=E2=80=A6]

 Lets not forget the lack of generics, the religious view against dynamic=


=20

 linking and errors for unused variables and imports.


OK so every language has it's religious side: Go's obsession for static
linking is indeed a problem and cgo is not really the solution.

Another religious element is that the language is tiny (which I find
good), and distributed version control for imports is included in the
language (which I think is brilliant). I want this is C++, D, Java,
Groovy, Python, Kotlin, Ceylon, Scala. etc., etc. Why are 21st century
languages still not connected to 21st century version control? For me,
Go has introduced so seriously sane innovation here (*).

I am not a fan of the unused variables and imports being errors, but I
can live with that. What I can't live with is the fascism of gofmt. Yet
I do :-(

I have yet to find anyone who can tell me why Go must have generics with
a cogent argument that makes sense to me. OK so C++ has generics;
templates, how wonderful. Java has generics, and type erasure, great.
Scala, Ceylon and Kotlin have huge infrastructure to reify generics on a

Go idea of total separation of state and behaviour not a good
experiment, after all JavaScript, Python, etc. have shown this works
even without static type checking.

I generally don't actually care about the state of the objects in a
container, all I care about is whether they responds to the messages I
want them to respond to. Let's do object-oriented programming: state is
supposed to be hidden behind the behaviours. Why does this mean I have
to bind the exact behaviours to a given state?

(*) Though it wasn't the core developers that pushed it into the
language!
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Apr 09 2013
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 9 April 2013 at 08:17:40 UTC, Russel Winder wrote:

 On Mon, 2013-04-08 at 23:51 +0200, Paulo Pinto wrote:
 […]

 Lets not forget the lack of generics, the religious view 
 against dynamic linking and errors for unused variables and 
 imports.


 OK so every language has it's religious side: Go's obsession 
 for static
 linking is indeed a problem and cgo is not really the solution.


I already advocated in go-nuts that an import mechanism similar 
to Object Pascal, D and many others makes more sense, to no avail.


 Another religious element is that the language is tiny (which I 
 find
 good), and distributed version control for imports is included 
 in the
 language (which I think is brilliant). I want this is C++, D, 
 Java,
 Groovy, Python, Kotlin, Ceylon, Scala. etc., etc. Why are 21st 
 century
 languages still not connected to 21st century version control? 
 For me,
 Go has introduced so seriously sane innovation here (*).



First, not all enterprise developers happen to live in GitHub 
land or
the other source control urls they support.

Second, as nice as it may be, it has issues with versioning, 
branching and security access for the said URLs, which they don't 
seem willing to fix.

In the enterprise world not everyone compiles from source 
everything.

This raises issues with their approaches.


 I am not a fan of the unused variables and imports being 
 errors, but I
 can live with that. What I can't live with is the fascism of 
 gofmt. Yet
 I do :-(

 I have yet to find anyone who can tell me why Go must have 
 generics with
 a cogent argument that makes sense to me. OK so C++ has 
 generics;
 templates, how wonderful. Java has generics, and type erasure, 
 great.
 Scala, Ceylon and Kotlin have huge infrastructure to reify 
 generics on a



Performance and avoiding to write casts everywhere in otherwise 
generic code.

I find really unfortunate that most people seem to always focus 
on generics in the Java world, when almost every single static 
language has some model of generics.


 Why is the
 Go idea of total separation of state and behaviour not a good
 experiment, after all JavaScript, Python, etc. have shown this 
 works
 even without static type checking.


Dynamic languages are generic by nature, of course they don't 
need generics.
Apr 09 2013
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 9 April 2013 at 08:17:40 UTC, Russel Winder wrote:

 I have yet to find anyone who can tell me why Go must have 
 generics with
 a cogent argument that makes sense to me. OK so C++ has 
 generics;
 templates, how wonderful. Java has generics, and type erasure, 
 great.
 Scala, Ceylon and Kotlin have huge infrastructure to reify 
 generics on a

 Why is the
 Go idea of total separation of state and behaviour not a good
 experiment, after all JavaScript, Python, etc. have shown this 
 works
 even without static type checking.


+1!

Types are not the only way bind data and behaviour, nor is 
binding necessary at all.
Apr 09 2013
parent "Dicebot" <m.strashun gmail.com> writes:
-1

Having polymorphic overhead for a basic concept of generic 
algorithm is a hardly acceptable luxury in embedded/gamedev 
programming language. Same goes for dynamic reflection vs static 
one.
Apr 09 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/9/13 4:17 AM, Russel Winder wrote:

 On Mon, 2013-04-08 at 23:51 +0200, Paulo Pinto wrote:
 […]

 Lets not forget the lack of generics, the religious view against dynamic
 linking and errors for unused variables and imports.


 OK so every language has it's religious side: Go's obsession for static
 linking is indeed a problem and cgo is not really the solution.


I think this thread has collected a good amount of arguments (of the 
devil's advocate style) you might also encounter from informed attendees 
during and after your talk.

I expect arguments against D to be mainly based on completeness of 
definition, quality of implementation, and of course current adoption.


 I have yet to find anyone who can tell me why Go must have generics with
 a cogent argument that makes sense to me. OK so C++ has generics;
 templates, how wonderful. Java has generics, and type erasure, great.
 Scala, Ceylon and Kotlin have huge infrastructure to reify generics on a

 Go idea of total separation of state and behaviour not a good
 experiment, after all JavaScript, Python, etc. have shown this works
 even without static type checking.


I think one of the less savory things the Go culture has done is to 
compromise the notion that generics are desirable in that language, to 
the extent that n00b posts asking about it are met with derision.

Lack of generics makes it very tenuous to do meaningful work on 
algorithms and their associated data structures. To compound the matter, 
Go itself doesn't follow its own preaching (thou shall shun generics and 
use interfaces throughout) for its own essential data structures 
(arrays, associative arrays, and channels) - all of which are generic in 
ways unattainable to client code. You can only go this far by claiming 
two data structures are enough and algorithms based on map/reduce are 
unneeded because there are loops.

I have some material for an article entitled "Why Go is not my favorite 
programming language". I decided in the end to cease work on that 
because it would be too controversial.


Andrei
Apr 09 2013
next sibling parent "GoSucksButt" <gohater gmail.com> writes:
 I think this thread has collected a good amount of arguments


   GO SUCKS
Apr 09 2013
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 9 April 2013 at 15:50:11 UTC, Andrei Alexandrescu 
wrote:

 Lack of generics makes it very tenuous to do meaningful work on 
 algorithms and their associated data structures.


Why?



 To compound the matter, Go itself doesn't follow its own 
 preaching (thou shall shun generics and use interfaces 
 throughout) for its own essential data structures (arrays, 
 associative arrays, and channels) - all of which are generic in 
 ways unattainable to client code.


Every language has primitives that have special privileges. I 
don't think this can be used as an argument against Go.



 You can only go this far by claiming two data structures are 
 enough and algorithms based on map/reduce are unneeded because 
 there are loops.


Two *primitive* data structures. There's nothing stopping you 
from creating your own data structures - they just won't be 
generic like the built in ones.
Apr 09 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/9/13 12:54 PM, Peter Alexander wrote:

 On Tuesday, 9 April 2013 at 15:50:11 UTC, Andrei Alexandrescu wrote:

 Lack of generics makes it very tenuous to do meaningful work on
 algorithms and their associated data structures.


 Why?


Is this an actual question?


 To compound the matter, Go itself doesn't follow its own preaching
 (thou shall shun generics and use interfaces throughout) for its own
 essential data structures (arrays, associative arrays, and channels) -
 all of which are generic in ways unattainable to client code.


 Every language has primitives that have special privileges. I don't
 think this can be used as an argument against Go.


Of course not. The point here is that it's disingenuous to claim 
generics are useless because they're successfully replaced by 
interfaces, yet in the same breath use generics for a few select cases.


 You can only go this far by claiming two data structures are enough
 and algorithms based on map/reduce are unneeded because there are loops.


 Two *primitive* data structures. There's nothing stopping you from
 creating your own data structures - they just won't be generic like the
 built in ones.


This is repeating what I said.


Andrei
Apr 09 2013
prev sibling parent "Jesse Phillips" <Jessekphillips+d gmail.com> writes:
On Tuesday, 9 April 2013 at 16:54:30 UTC, Peter Alexander wrote:

 On Tuesday, 9 April 2013 at 15:50:11 UTC, Andrei Alexandrescu 
 wrote:

 Lack of generics makes it very tenuous to do meaningful work 
 on algorithms and their associated data structures.


 Why?


I think the answer to that is working on implementing an 
algorithm to work on a data structure not provided by the 
language can only reach as far as the type you implemented the 
algorithm for. Thus the work done to implement that algorithm 
wasn't very meaningful as it isn't reusable.

On a similar note. Earlier I was having a discussion with someone 
who was stating, "The problem with the whole generics complaint 
is that people tend to focus on Go's lack of generics to mean Go 
lacks any safe polymorphism at all." He was quite aware "What Go 
doesn't have is parametric polymorphism."

I was kind of worried that it would be impossible to specify a 
different sort for a data type. I ended up writing some code to 
sort a slice of Time[1]. I was glad to find out I was wrong, but 
also very concerned with what I did find.

1. http://ideone.com/eVWfnk

- There is a built in function make which takes a type! That was 
interesting.
- Data doesn't provide a default means to sort.
- I had to write the data access of the array!
- I also couldn't get the functions to take a slice of time, 
instead I had to define a TimeSlice which was a slice of time.

Needless to say WTF! That was with a built in data structure, at 
least I know it will work with any custom structure.
Apr 09 2013
prev sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Tuesday, 9 April 2013 at 15:50:11 UTC, Andrei Alexandrescu 
wrote:

 I have some material for an article entitled "Why Go is not my 
 favorite programming language". I decided in the end to cease 
 work on that because it would be too controversial.

 Andrei


Probably a good idea. People might accuse you of having an axe to 
grind, even if you didn't. Besides, being negative is often an 
indication of insecurity. My goal is only to be negative when 
it's personal. And for it never to be personal, if I can help it.
Apr 09 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/9/2013 1:17 AM, Russel Winder wrote:

 I have yet to find anyone who can tell me why Go must have generics with
 a cogent argument that makes sense to me.


Can Go do this:

--------------
import std.stdio;
import std.array;
import std.algorithm;

void main() {
     stdin.byLine(KeepTerminator.yes).
     map!(a => a.idup).
     array.
     sort.
     copy(
        stdout.lockingTextWriter());
}
------------
(Read lines from stdin, sort the lines, write the sorted result to stdout.)

This makes heavy use of generics in order to implement pipeline programming.
Apr 09 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/9/2013 1:17 AM, Russel Winder wrote:

 I have yet to find anyone who can tell me why Go must have generics with
 a cogent argument that makes sense to me.


I was strongly opposed to generics for a long time, but finally changed my mind.

One thing I learned about templates from Andrei and Scott Meyers is that one
can 
write programs that manipulate types. For example, for a variadic function an 
array of types represents the types of the actual arguments. This can then be 
used to create a typesafe printf, which is what we have in std.stdio.

Another thing we can do with templates that is hard to imagine doing with other 
means is the compiler's hook into making a precise GC. In object.d, there's a 
template named RTInfo(T). For each call to new(), the compiler passes along a 
static value generated by RTInfo!T, where T is the type of the data being
allocated.

What this means is the compiler (and language) needs NO KNOWLEDGE of what the
GC 
needs. The library implementer is free to innovate whatever kind of tables are 
necessary. It means that radically different GCs can be built and swapped in
and 
out without change to the compiler or language. It means that anyone who wants 
to build a better GC can do so without forking the compiler.
Apr 09 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/10/2013 05:57 AM, Walter Bright wrote:

 On 4/9/2013 1:17 AM, Russel Winder wrote:

 I have yet to find anyone who can tell me why Go must have generics with
 a cogent argument that makes sense to me.


 ....
 What this means is the compiler (and language) needs NO KNOWLEDGE of
 what the GC needs. The library implementer is free to innovate whatever
 kind of tables are necessary. It means that radically different GCs can
 be built and swapped in and out without change to the compiler or
 language. It means that anyone who wants to build a better GC can do so
 without forking the compiler.


What about precise tracking of stack references?
Apr 10 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/10/2013 05:55 PM, Timon Gehr wrote:

 On 04/10/2013 05:57 AM, Walter Bright wrote:

 On 4/9/2013 1:17 AM, Russel Winder wrote:

 I have yet to find anyone who can tell me why Go must have generics with
 a cogent argument that makes sense to me.


 ....
 What this means is the compiler (and language) needs NO KNOWLEDGE of
 what the GC needs. The library implementer is free to innovate whatever
 kind of tables are necessary. It means that radically different GCs can
 be built and swapped in and out without change to the compiler or
 language. It means that anyone who wants to build a better GC can do so
 without forking the compiler.


 What about precise tracking of stack references?


/stack references/references on the stack/s
Apr 10 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/10/13 11:56 AM, Timon Gehr wrote:

 On 04/10/2013 05:55 PM, Timon Gehr wrote:

 On 04/10/2013 05:57 AM, Walter Bright wrote:

 On 4/9/2013 1:17 AM, Russel Winder wrote:

 I have yet to find anyone who can tell me why Go must have generics
 with
 a cogent argument that makes sense to me.


 ....
 What this means is the compiler (and language) needs NO KNOWLEDGE of
 what the GC needs. The library implementer is free to innovate whatever
 kind of tables are necessary. It means that radically different GCs can
 be built and swapped in and out without change to the compiler or
 language. It means that anyone who wants to build a better GC can do so
 without forking the compiler.


 What about precise tracking of stack references?


 /stack references/references on the stack/s


Zose do need some magic.

Andrei
Apr 10 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/10/2013 9:13 AM, Andrei Alexandrescu wrote:

 What about precise tracking of stack references?




 Zose do need some magic.


Yup.
Apr 10 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/10/2013 11:13 AM, Walter Bright wrote:

 On 4/10/2013 9:13 AM, Andrei Alexandrescu wrote:

 What about precise tracking of stack references?




 Zose do need some magic.


 Yup.



But I should amend that since D can call any code with a C interface, and has 
zero knowledge of what is on the C stack, and may also be handed blocks of C 
data of unknown types, there are limits to precise tracking of all references.

At best a D collector can be "mostly copying".
Apr 10 2013
prev sibling parent reply "GoSucksButt" <gohater gmail.com> writes:
On Monday, 8 April 2013 at 14:22:54 UTC, Russel Winder wrote:

 <<Originally sent to wrong list, sorry if this appears a 
 cross-posting.>>

 Given that the entire C++ standards committee will be at ACCU 
 2013, I've
 decided to do a lightning talk on why D and Go are better tools 
 for any
 native coding problem than C++.

 	pigeon[500] pigeons;
 	pigeons[random(500)] = new cat;

 :-)


  Go better than C++ for Games ?  Keeep dreaming buddy!

I like D but half of what makes a language useful are tools/IDE's 
etc, and D is just not comparable to C++ yet on this front.
Apr 08 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 08.04.2013 23:05, schrieb GoSucksButt:

 On Monday, 8 April 2013 at 14:22:54 UTC, Russel Winder wrote:

 <<Originally sent to wrong list, sorry if this appears a cross-posting.>>

 Given that the entire C++ standards committee will be at ACCU 2013, I've
 decided to do a lightning talk on why D and Go are better tools for any
 native coding problem than C++.

     pigeon[500] pigeons;
     pigeons[random(500)] = new cat;

 :-)


   Go better than C++ for Games ?  Keeep dreaming buddy!


Not all games need to be the next Crysis.


 I like D but half of what makes a language useful are tools/IDE's etc,
 and D is just not comparable to C++ yet on this front.


If that was a major issue then what to say about C++ tooling when 


--
Paulo
Apr 08 2013
next sibling parent reply "GoSucksButt" <gohater gmail.com> writes:
  Go better than C++ for Games ?  Keeep dreaming buddy!


 Not all games need to be the next Crysis.


  Yes but you are forgetting, Go Sucks Butt! Shitty language all 
around, even if C++ wasn't so much faster, still no reason to use 
Go. For the performance it offers(Crap), you could use LuaJIT for 
a far more enjoyable time(and it has coroutines just like Go, and 
probably runs faster).



 I like D but half of what makes a language useful are 
 tools/IDE's etc,
 and D is just not comparable to C++ yet on this front.


 If that was a major issue then what to say about C++ tooling 




remaining issue is mostly compilation speed which is the fault of 
the monkeys on the C++ committee not seeming to care enough about 
this issue(not a priority for C++14 wtf??)
Apr 08 2013
parent Russel Winder <russel winder.org.uk> writes:
On Tue, 2013-04-09 at 00:42 +0200, GoSucksButt wrote:
[=E2=80=A6]

   Yes but you are forgetting, Go Sucks Butt! Shitty language all=20
 around, even if C++ wasn't so much faster, still no reason to use=20
 Go. For the performance it offers(Crap), you could use LuaJIT for=20
 a far more enjoyable time(and it has coroutines just like Go, and=20
 probably runs faster).


Not what I would call a well-reasoned or data-driven argument. Have you
tried gccgo?

BTW Go does not have coroutines.


 I like D but half of what makes a language useful are=20
 tools/IDE's etc,
 and D is just not comparable to C++ yet on this front.


 If that was a major issue then what to say about C++ tooling=20



=20

 remaining issue is mostly compilation speed which is the fault of=20
 the monkeys on the C++ committee not seeming to care enough about=20
 this issue(not a priority for C++14 wtf??)


Clearly you live in a Windows world. I don't have a licence to go there.
Nor the finance.

In the Eclipse, IntelliJ IDEA, NetBeans, Emacs, VIM universes, C++
support is hideous especially when templates are involved. Support for
Java, Kotlin, Go, Ceylon, Groovy, JRuby, Jython, Python is huge in
comparison.

Isn't it the case that #include leads directly to uncontrollable
compilation times?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Apr 09 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 08 Apr 2013 23:47:56 +0200
Paulo Pinto <pjmlp progtools.org> wrote:


 Am 08.04.2013 23:05, schrieb GoSucksButt:

   Go better than C++ for Games ?  Keeep dreaming buddy!


 
 Not all games need to be the next Crysis.
 


And not all games would *want* to ;)  I've always liked FPSes, but when
I tried Crysis 2 (and the MP beta of Crysis 3), I didn't see what the
big deal was. Not that it was bad or anything, but just "meh". And
that's referring to both gameplay and graphics. Sure, it was
pushing a metric assload of pixels and polys, but it still looked like
any other non-indie title out there (except a bit more "pixeley" - as if
the mip-mapping was biased too much towards the "detailed" end).
Ultimately, good graphics have always been about art direction, not
rendering throughput, and good games are about gameplay, not how closely
your studio can imitate ILM or Pixar or [insert name of your favorite
novelist].

Of course, I do still completely agree with the importance of
soft-realtime-processing issues in games. No gameplay or art direction
is going to sufficiently compensate for choppy or stuttery animation.

OTOH, sometimes you can get away with more than you'd think:
PSN's "Sound Shapes" seems to be doing pretty well (at least my brother
and I enjoy it quite a bit and the online community is active), and
yet that has very clear GC-stalls now and then. Or at least something
that feels a lot like a GC stall. It only lasts for maybe 100-500ms,
and only every few minutes of gameplay, so while it's ugly, it doesn't
end up being a game-breaker. 

Just my random thoughts on the matter ;)
Apr 08 2013