On Wednesday, 13 November 2013 at 11:30:14 UTC, eles wrote:
> 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 "->".

Ah, right. I just tested, and turns out Go does actually automatically dereference pointers to structs, but not to arrays. So if arrp is a pointer to an array, writing arrp[0] is a syntax error in Go, and it must be written as (*arrp)[0]. D on the other hand, as far as I'm aware (correct me if I'm wrong), would automatically dereference the pointer.

On Wednesday, 13 November 2013 at 02:54:05 UTC, eles wrote:
> On Tuesday, 12 November 2013 at 17:59:50 UTC, Paulo Pinto wrote:
>> Am 12.11.2013 17:10, schrieb eles:
>>> On Tuesday, 12 November 2013 at 15:35:48 UTC, Dicebot wrote:
>>>> On Tuesday, 12 November 2013 at 15:27:36 UTC, bearophile wrote:
>>>>> Ali Çehreli:
>>>> Sometimes I have feeling language researchers live in some strange
>>>> imaginary world and never actually check how their
>>>
>>> Lambda the Ultimate and Javaland.
>>
>> Well, in defence of Javaland, it is a consequence how easy it
>
> I hesitated to add Javaland to the list, exactly because of that. I believe it was successful because, first, was designed *by a company* (just like C# is) and, second, because it was mostly like C++ but with increased verbosity (and that means less cryptic and easier to follow a diff).
>
> I am not the first to consider that Java's verbosity is a good thing for a company. But, I confirm that: in my day-to-day job, we use C (and some C++). You would be amazed how much our guidelines lead us towards increased verbosity (names, annotations/comments, declarations).

Java is popular because it's a general purpose language and an
alternative to c++ with following advantages:

- much better IDE support
- OOP by default, all libraries and frameworks follow it
- rich standard library, so that everyone uses java.lang.String
and it's over, while C/C++ libs still try to reinvent their own
string classes (which often have completely different
interfaces), XML, HTTP etc. built-in to the language
- easy to learn, easy to write (no .h/.cpp madness, no cryptic
template errors, no 10 ways to initialize a variable)
- good performance, slightly behind C/C++ in most cases, way
ahead of Python/Ruby/etc.
- mature GUI frameworks with great RAD tools

and many more.

On Tuesday, 12 November 2013 at 11:09:24 UTC, Luís Marques wrote:
> I think you will be pleased with the argument, given D's philosophy:
>
>     https://yinwang0.wordpress.com/2013/11/09/oop-fp/

Yep, 100% agree. We should use both, and think ahead whether to take first or the second approach to solve the problem at hand.

Regarding Java rumbling about nouns and verbs... I think in the long run it is a better practice to name your class/method in a way that helps developers understand what it does. Yes, some people write long names, but that most often comes from their company/team coding style. Nothing wrong with that really, and it is not just Java community that does this... (first that comes to mind: thread_stackTop() )

On Tuesday, 12 November 2013 at 11:09:24 UTC, Luís Marques wrote:
> I think you will be pleased with the argument, given D's philosophy:
>
>     https://yinwang0.wordpress.com/2013/11/09/oop-fp/

“functions are also objects”. Yes, they are. http://en.wikipedia.org/wiki/Category_theory

On Tuesday, 12 November 2013 at 11:09:24 UTC, Luís Marques wrote:
> I think you will be pleased with the argument, given D's philosophy:
>
>     https://yinwang0.wordpress.com/2013/11/09/oop-fp/

The thing I don't like with many such "pure paradigm" languages is not actually the fact that they stick to a single approach and harm the toolset. It is the fact that they define set of abstractions and then try to tie those to existing computer hardware. With modern insanely clever optimizing compilers it may even work performance-wise but it harms learning curve in least pleasant way. If language is built as bottom-up abstraction, it is relatively trivial to learn for someone familiar with assembly level. Any such language. If it is built top-down from imaginary abstraction set, it is always a completely new thing every time and you often have no idea what certain concept actually means (like, is "function" here really a function or some obscure wrapper that emulates it?)

I would favor pure FP languages much more if computers would have existed that operated in similar matter on hardware level but it does not seem like a real thing to happen ;)

On Wednesday, 13 November 2013 at 12:05:51 UTC, logicchains wrote:
> On Wednesday, 13 November 2013 at 11:30:14 UTC, eles wrote:
>> 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 "->".
>
> Ah, right. I just tested, and turns out Go does actually automatically dereference pointers to structs, but not to arrays. So if arrp is a pointer to an array, writing arrp[0] is a syntax error in Go, and it must be written as (*arrp)[0]. D on the other hand, as far as I'm aware (correct me if I'm wrong), would automatically dereference the pointer.

nope. a pointer can be indexed like in C. ptr[n] is equivalent to *(ptr + n) irrespective of what the target type of the pointer is. Fully expanded for T* ptr  : *(cast(T*)( (cast(void*)ptr) + (T.sizeof * n) ))

On 11/13/13 4:05 AM, logicchains wrote:
> On Wednesday, 13 November 2013 at 11:30:14 UTC, eles wrote:
>> 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 "->".
>
> Ah, right. I just tested, and turns out Go does actually automatically
> dereference pointers to structs, but not to arrays. So if arrp is a
> pointer to an array, writing arrp[0] is a syntax error in Go, and it
> must be written as (*arrp)[0]. D on the other hand, as far as I'm aware
> (correct me if I'm wrong), would automatically dereference the pointer.

If the purpose was to make it clear dereference is happening (presumably to have people understand the efficiency issues associated), I wonder why they didn't make memory allocation or indirect calls (both of which abound in Go) more visible. Was there some other intent behind (*pt).X?

Andrei

On Wednesday, 13 November 2013 at 12:05:51 UTC, logicchains wrote:
> On Wednesday, 13 November 2013 at 11:30:14 UTC, eles wrote:
>> 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 "->".
>
> Ah, right. I just tested, and turns out Go does actually automatically dereference pointers to structs, but not to arrays. So if arrp is a pointer to an array, writing arrp[0] is a syntax error in Go, and it must be written as (*arrp)[0]. D on the other hand, as far as I'm aware (correct me if I'm wrong), would automatically dereference the pointer.

I don't think so. D would index the pointer (as if it pointer to an array of slices).

On Wednesday, 13 November 2013 at 16:12:01 UTC, Andrei Alexandrescu wrote:
>
> If the purpose was to make it clear dereference is happening (presumably to have people understand the efficiency issues associated), I wonder why they didn't make memory allocation or indirect calls (both of which abound in Go) more visible. Was there some other intent behind (*pt).X?
>
> Andrei

Looking through the Go spec, it seems I was confused. A pointer to a struct can be used with just pt.X, and a pointer to an array *arrp can be used with just arrp[0], but a pointer to a _slice_ *slcp can only be used with (*slcp)[0], not slcp[0]. I have no idea why this is.

On Thursday, 14 November 2013 at 02:37:52 UTC, logicchains wrote:
> On Wednesday, 13 November 2013 at 16:12:01 UTC, Andrei Alexandrescu wrote:
>>
>> If the purpose was to make it clear dereference is happening (presumably to have people understand the efficiency issues associated), I wonder why they didn't make memory allocation or indirect calls (both of which abound in Go) more visible. Was there some other intent behind (*pt).X?
>>
>> Andrei
>
> Looking through the Go spec, it seems I was confused. A pointer to a struct can be used with just pt.X, and a pointer to an array *arrp can be used with just arrp[0], but a pointer to a _slice_ *slcp can only be used with (*slcp)[0], not slcp[0]. I have no idea why this is.

Because slices are always references, so you have a double indirection.