On Sunday, 27 January 2013 at 13:16:59 UTC, Timon Gehr wrote:
> On 01/27/2013 12:35 PM, deadalnix wrote:
>> On Sunday, 27 January 2013 at 11:18:01 UTC, sclytrack wrote:
>>> On Sunday, 27 January 2013 at 10:54:05 UTC, SomeDude wrote:
>>>> On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis wrote:
>>>>>
>>>>> I hate optional parentheses with a passion
>>>>>
>>>>> - Jonathan M Davis
>>>>
>>>> Same here.
>>>
>>> In Delphi they are also optional and nobody uses them. However,
>>> everybody else doesn't use them.
>>>
>>
>> Delphi has no real functional capabilities.
>
> What about scala?

I'm not a scala specialist (however, one of my coworker is, so I'll ask him tomorrow) but my understanding is that that autocall functionality in scala is more limited than in D.

On Sunday, 27 January 2013 at 13:24:31 UTC, TommiT wrote:
> But, joking aside, I think that all hate against optional parentheses stems from the increase of ambiguity they indisputably cause. However, let's imagine a future where your perfect D IDE paints function calls red, and variables blue.

That is not good because in functional style, you manipulate
function like variable.

On Sunday, 27 January 2013 at 13:42:33 UTC, Dicebot wrote:
> On Sunday, 27 January 2013 at 13:24:31 UTC, TommiT wrote:
>> But, joking aside, I think that all hate against optional parentheses stems from the increase of ambiguity they indisputably cause. However, let's imagine a future where your perfect D IDE paints function calls red, and variables blue. Then, it will be obvious to you which identifiers are variables and which are function calls based on their color. In this situation it will feel silly to have to write those empty parentheses, because they don't make the code any less ambiguous (it's already perfectly unambiguous because of the colors) and, infact, those empty parentheses make the code (a bit) harder to read.
>
> If we require clever IDE to distinguish visually something as basic as data semantics and callable semantics it is an indicator language design is screwed. Relying on IDE features is what made Java unusable for expressive, robust code. I may use an IDE help when I need to learn architecture level connections in new project, but at scope level semantics for reader should be perfectly clear and unambiguous even if opened in notepad.
>
> 2 cents from vim user and optional parens hater here.

You're being an extremist here. From a vim user and automagic function call hater as well ;)

First many reliable code have been written in Java. Quite a lot of it in fact. And refusing IDE help make no real sense. Even vim is an IDE, and not a simple editor.

On Sunday, 27 January 2013 at 13:42:33 UTC, Dicebot wrote:
> If we require clever IDE to distinguish visually something as basic as data semantics and callable semantics it is an indicator language design is screwed.

Why is it an indicator of that?

> I may use an IDE help when I need to learn architecture level connections in new project, but at scope level semantics for reader should be perfectly clear and unambiguous even if opened in notepad.

Notepad opens text files. There is nothing that says that the source files of X programming language must be text files. It's just a convention, not a law or a real limitation in designing languages. Therefore you can't assume that an X source file can be opened and read with notepad. Someone might design a language that wouldn't rely on those symbols that just happen to be found on keyboards, but instead, relied more on text formatting and colors.

On Sunday, 27 January 2013 at 13:56:53 UTC, deadalnix wrote:
> You're being an extremist here. From a vim user and automagic function call hater as well ;)
>
> First many reliable code have been written in Java. Quite a lot of it in fact. And refusing IDE help make no real sense. Even vim is an IDE, and not a simple editor.

Probably, but that is a result of general mainstream moving to IDE-reliance. You need to sound somewhat radical to be noticed :) I did not say Java is not _reliable_. I have said it is not _expressive_ on language level and relies on boilerplate generation by IDE for something as basic as properties.

I do not use vim as an IDE - no plugins, no clever macros, no ctags etc. Any editor with file list, syntax highlighting and tabs works for me; it just happens that it is more convenient to use vim when you mostly do console stuff anyway.

That may come from the fact of having most commercial experience in large teams with huge legacy codebases - readability and support issues take there >90% of time and efforts, contrary to actually coding. Made me interested in languages that do enforce such stuff at language level.

On Sunday, 27 January 2013 at 14:11:13 UTC, TommiT wrote:
> On Sunday, 27 January 2013 at 13:42:33 UTC, Dicebot wrote:
>> If we require clever IDE to distinguish visually something as basic as data semantics and callable semantics it is an indicator language design is screwed.
>
> Why is it an indicator of that?

Because it fails to maintain and control semantics on its own.

> Notepad opens text files. There is nothing that says that the source files of X programming language must be text files. It's just a convention, not a law or a real limitation in designing languages.

Text is still most efficient form of providing information. Please call me back when something better will be invented. Then we can speak about minimal editing environment for it.

On 1/27/13 8:56 AM, deadalnix wrote:
> On Sunday, 27 January 2013 at 13:42:33 UTC, Dicebot wrote:
>> On Sunday, 27 January 2013 at 13:24:31 UTC, TommiT wrote:
>>> But, joking aside, I think that all hate against optional parentheses
>>> stems from the increase of ambiguity they indisputably cause.
>>> However, let's imagine a future where your perfect D IDE paints
>>> function calls red, and variables blue. Then, it will be obvious to
>>> you which identifiers are variables and which are function calls
>>> based on their color. In this situation it will feel silly to have to
>>> write those empty parentheses, because they don't make the code any
>>> less ambiguous (it's already perfectly unambiguous because of the
>>> colors) and, infact, those empty parentheses make the code (a bit)
>>> harder to read.
>>
>> If we require clever IDE to distinguish visually something as basic as
>> data semantics and callable semantics it is an indicator language
>> design is screwed. Relying on IDE features is what made Java unusable
>> for expressive, robust code. I may use an IDE help when I need to
>> learn architecture level connections in new project, but at scope
>> level semantics for reader should be perfectly clear and unambiguous
>> even if opened in notepad.
>>
>> 2 cents from vim user and optional parens hater here.
>
> You're being an extremist here. From a vim user and automagic function
> call hater as well ;)
>
> First many reliable code have been written in Java. Quite a lot of it in
> fact. And refusing IDE help make no real sense. Even vim is an IDE, and
> not a simple editor.

Language adoption is a complex phenomenon with many variables, and it's easy to neglect certain aspects when assessing the impact of others. Java started as a well-designed language albeit small and underpowered. It enjoyed the benefit of unwavering support from a large corporation and an estimated one billion dollars in marketing budget. (I remember in 1998 non-programming managers in NYC were talking "we must adopt Java!" without even knowing what Java meant. Java may as well be the only programming language in history to enjoy management support before programmer support.)

That has caused Java to evolve quite differently from languages with grass-roots support (e.g. C++, Ruby, PHP, or Python). Generally the latter languages grew with little tooling support aside from the traditional Unix toolset, and that is to some extent reflected in the languages themselves.

The same goes about C#, which was designed from day 1 assuming resources are available for dedicated tooling support. It would have evolved differently otherwise, and I assume many people would have a dimmer view of either Java or C# if they had to use it with vim and emacs.


Andrei

I think that "property as contract for accessing to variable" is good point. Maybe we have lack proper terminology, but idea is good.
Also it is can be pointed as "property itself - is static contract to accessing variable".

>>class A{
>>    private int i;
>>    int foo{
>>        out out(result){assert(result<=0);}body{return i; }
>>        in(int v)in{assert(v<=0);}out{assert(foo<=0);}body{ i = v; }
>>    }
>>}
Unified:
class A
{
    private int i;

    int foo
    {
        out{assert(@value<=0);}body{return i; }
        in{assert(@value<=0);}body{ i = @value; }
    }
}

@value - in getter it's return value;
@value - in setter it's param value;
void type is not allowed.

In theory, property always have only one in/out parameter of same type and performs lightweight actions.

On 01/27/13 15:11, TommiT wrote:
> There is nothing that says that the source files of X programming language must be text files. It's just a convention, not a law or a real limitation in designing languages. Therefore you can't assume that an X source file can be opened and read with notepad. Someone might design a language that wouldn't rely on those symbols that just happen to be found on keyboards, but instead, relied more on text formatting and colors.

Except we're not talking about such hypothetical language, but one where text
*is* the natural form for source code.
It also happens to be called "D", which means that it will be universally
expected to have certain properties.

Something can be a great idea in one context, while being an extremely bad one in another.

artur

On Sunday, 27 January 2013 at 14:26:20 UTC, Andrei Alexandrescu wrote:
> The same goes about C#, which was designed from day 1 assuming resources are available for dedicated tooling support. It would have evolved differently otherwise, and I assume many people would have a dimmer view of either Java or C# if they had to use it with vim and emacs.
>

That is kind of my point : such language is made for tooling. With the 2 side of the medal : tooling is great, because language have been made with tooling in mind, but coding without tooling is not the best experience.

Not that tremendous efforts are put now to introduce tooling in C++, and results are not as good as they are in Java/C#, simply because C++ is tooling hostile.

I know resource are a factor. But clearly not the only one. Doing some tooling on Java is braindead simple, the compiler provide everything you need to reuse it/parts of it.