On 2013-11-12 18:59, Paulo Pinto wrote:

> - A framework done on top of J2EE, as if J2EE wasn't enough

There's always a framework to put on top of another :)

-- 
/Jacob Carlborg

To be fair, there is a kind of mental satisfaction that comes from being able to hold the language spec in one's head. I've used Go about as much as I've used D, and while I understand the semantics of Go and its stdlib almost completely, I've probably not familiar with even a tenth of the functionality in D (which is of course because D has a lot more functionality).


On Wednesday, 13 November 2013 at 07:23:40 UTC, Paulo Pinto wrote:
>
> It just shows the kind of distortion field Go developers suffer from.

 Go is a boring language, kind of like Dart, I guess Google just sucks at language design? The do use an awful lot of Java, perhaps it has caused irreparable damage

On Wednesday, 13 November 2013 at 07:55:59 UTC, Froglegs wrote:
>  Go is a boring language, kind of like Dart, I guess Google just sucks at language design? The do use an awful lot of Java, perhaps it has caused irreparable damage

If you were working in an Enterprise (TM) with coworkers who were potentially competence-challenged, would you want them having access to the power of D's compile time code generation? Would you like to read and debug code that randomly intermingled D's different function call methods; having to determine whether foo.bar represents calling the bar method of foo, calling the function bar with foo as an argument, or accessing the field bar on object foo?

On Wednesday, 13 November 2013 at 08:39:06 UTC, logicchains wrote:
> On Wednesday, 13 November 2013 at 07:55:59 UTC, Froglegs wrote:
>> Go is a boring language, kind of like Dart, I guess Google just sucks at language design? The do use an awful lot of Java, perhaps it has caused irreparable damage
>
> If you were working in an Enterprise (TM) with coworkers who were potentially competence-challenged, would you want them having access to the power of D's compile time code generation? Would you like to read and debug code that randomly intermingled D's different function call methods; having to determine whether foo.bar represents calling the bar method of foo, calling the function bar with foo as an argument, or accessing the field bar on object foo?

Speaking from my enterprise seat, there are lots of "potentially competence-challenged coworkers" in off-shore projects.

Maybe Google's target audience?

--
Paulo

On Wednesday, November 13, 2013 09:51:33 Paulo Pinto wrote:
> On Wednesday, 13 November 2013 at 08:39:06 UTC, logicchains wrote:
> > On Wednesday, 13 November 2013 at 07:55:59 UTC, Froglegs wrote:
> >> Go is a boring language, kind of like Dart, I guess Google just sucks at language design? The do use an awful lot of Java, perhaps it has caused irreparable damage
> > 
> > If you were working in an Enterprise (TM) with coworkers who were potentially competence-challenged, would you want them having access to the power of D's compile time code generation? Would you like to read and debug code that randomly intermingled D's different function call methods; having to determine whether foo.bar represents calling the bar method of foo, calling the function bar with foo as an argument, or accessing the field bar on object foo?
> 
> Speaking from my enterprise seat, there are lots of "potentially competence-challenged coworkers" in off-shore projects.
> 
> Maybe Google's target audience?

This conversation definitely seems to be taking a turn for the worse. Go was created by folks who believe in its goals and paradigms and believed that they could better serve those by creating a new language than by using existing ones. As I understand it, it was completely an engineering-driven solution and not business-driven at all. Google really had very little to do with its creation. It's just that the engineers who created it happened to be working at Google. And while we may not like the direction that Go went in, that doesn't mean that it's worthless or primarily intended to prevent bad programmers from fouling things up. Clearly, it does a good enough job that many programmers have taken a liking to it and written good, useful programs in it.

Personally, I have no interest in it and think that its designers made some very poor choices, but that doesn't mean that we should be making fun of it or make fun of Google for being the place where the engineers who created it work. The fact that Google let its engineers spend company time on creating a new programming langueg says very good things about Google, even if the language itself ultimately isn't what we'd like.

- Jonathan M Davis

On Wednesday, 13 November 2013 at 08:39:06 UTC, logicchains wrote:
> On Wednesday, 13 November 2013 at 07:55:59 UTC, Froglegs wrote:

> If you were working in an Enterprise (TM) with coworkers who were potentially competence-challenged, would you want them having access to the power of D's compile time code generation? Would you like to read and debug code that randomly intermingled D's different function call methods; having to determine whether foo.bar represents calling the bar method of foo, calling the function bar with foo as an argument, or accessing the field bar on object foo?

Unfortunately, yes, you did hit a nail here. I don't really like this way of "calling" functions. If they were only properties, OK, but for general functions...

I dunno if it is implemented, but I recall Walter beign quite supportive of accepting that:

foo.bar;

is a function call...

A lot of confusion stems from the fact that properties are seen more like functions than variables (in the D community). I feel it should be the other way around.

Or, simply, get rid of properties completely until better ideas come.

On Wednesday, 13 November 2013 at 09:12:40 UTC, Jonathan M Davis wrote:
> On Wednesday, November 13, 2013 09:51:33 Paulo Pinto wrote:
>> On Wednesday, 13 November 2013 at 08:39:06 UTC, logicchains wrote:
>> > On Wednesday, 13 November 2013 at 07:55:59 UTC, Froglegs wrote:
>> >> Go is a boring language, kind of like Dart, I guess Google
>> >> just sucks at language design? The do use an awful lot of
>> >> Java, perhaps it has caused irreparable damage
>> > 
>> > If you were working in an Enterprise (TM) with coworkers who
>> > were potentially competence-challenged, would you want them
>> > having access to the power of D's compile time code generation?
>> > Would you like to read and debug code that randomly
>> > intermingled D's different function call methods; having to
>> > determine whether foo.bar represents calling the bar method of
>> > foo, calling the function bar with foo as an argument, or
>> > accessing the field bar on object foo?
>> 
>> Speaking from my enterprise seat, there are lots of "potentially
>> competence-challenged coworkers" in off-shore projects.
>> 
>> Maybe Google's target audience?
>
> This conversation definitely seems to be taking a turn for the worse. Go was
> created by folks who believe in its goals and paradigms and believed that they
> could better serve those by creating a new language than by using existing
> ones. As I understand it, it was completely an engineering-driven solution and
> not business-driven at all. Google really had very little to do with its
> creation. It's just that the engineers who created it happened to be working
> at Google. And while we may not like the direction that Go went in, that
> doesn't mean that it's worthless or primarily intended to prevent bad
> programmers from fouling things up. Clearly, it does a good enough job that
> many programmers have taken a liking to it and written good, useful programs
> in it.
>
> Personally, I have no interest in it and think that its designers made some
> very poor choices, but that doesn't mean that we should be making fun of it or
> make fun of Google for being the place where the engineers who created it
> work. The fact that Google let its engineers spend company time on creating a
> new programming langueg says very good things about Google, even if the
> language itself ultimately isn't what we'd like.
>
> - Jonathan M Davis

Point taken. I should have thought better before posting. Just got carried away due to some of our project's status.

Sorry about that and my excuses to anyone that felt bad with my remark.

Despite my critic, I do see lots of use cases where Go might be useful and would happily used it over C, although D would be even better. :)

No more replies from me on this thread.

..
Paulo

On Wednesday, 13 November 2013 at 09:12:40 UTC, Jonathan M Davis wrote:
> Personally, I have no interest in it and think that its designers made some
> very poor choices, but that doesn't mean that we should be making fun of it or
> make fun of Google for being the place where the engineers who created it
> work. The fact that Google let its engineers spend company time on creating a
> new programming langueg says very good things about Google, even if the
> language itself ultimately isn't what we'd like.
>
> - Jonathan M Davis

For the record, I wasn't making fun of Go when I spoke of its readability being a particular virtue. If I was managing a large project with programmers of divergent ability then I might well pick it for that reason alone. The design choices might seem poor from the perspective of someone looking for a language that gives them lots of power, but if you look at it from the perspective of a language designed to minimise the power of co-workers (and anybody else) to write difficult-to-understand code, it's designed magnificently.

An example of this is how, in order to avoid ambiguity, both automatic dereferencing and the -> operator from C were omitted from the language. This means that if pt is a pointer to a struct, then I have to write (*pt).X to access field X of that struct, as opposed to pt.X in D or pt->X in C, making it completely clear to anybody glancing at the code that pt is a pointer.

On Wednesday, 13 November 2013 at 10:19:34 UTC, logicchains wrote:
> On Wednesday, 13 November 2013 at 09:12:40 UTC, Jonathan M Davis wrote:

> struct, then I have to write (*pt).X to access field X of that

It is in our guidelines too. I almost never write "->".