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

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

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.

On Tue, 2013-04-09 at 00:42 +0200, GoSucksButt wrote:
[…]
>   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).

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

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?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

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

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.

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!
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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.

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.

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