www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Opportunity

reply Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<<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 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
 platform with unreified generics. At least C# got that right. 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.

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



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?



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 next 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 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 compared to what Delphi/Java/C# offer. -- Paulo
Apr 08 2013
prev sibling next sibling parent "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 when compared to what Delphi/Java/C# offer.

Visual Studio + Visual Assist for C++ is not far off from C#, 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
prev sibling next sibling parent 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
prev sibling next 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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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
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 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
prev sibling next sibling parent "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
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 when compared to what Delphi/Java/C# offer.

Visual Studio + Visual Assist for C++ is not far off from C#,=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 next sibling parent 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 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
prev sibling next sibling 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.

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 next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=

 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 platform with unreified generics. At least C# got that right. 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. 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
prev sibling 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
 platform with unreified generics. At least C# got that right.

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 "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
 platform with unreified generics. At least C# got that right. 
 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
prev sibling next sibling 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 "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 "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
prev sibling next 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 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
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 next sibling parent "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.

documentation generation should be left to doxygen-like tool. Wait ...
Apr 09 2013
prev sibling next sibling 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.

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