• foobar <foo bar.com> Jan 24 2011
• so <so so.do> Jan 24 2011
• foobar <foo bar.com> Jan 24 2011
• foobar <foo bar.com> Jan 24 2011
• foobar <foo bar.com> Jan 25 2011
• foobar <foo bar.com> Jan 25 2011
• foobar <foo bar.com> Jan 25 2011
• foobar <foo bar.com> Jan 25 2011
• so <so so.do> Jan 24 2011
• so <so so.do> Jan 24 2011
• so <so so.do> Jan 24 2011
• so <so so.do> Jan 24 2011
• so <so so.do> Jan 25 2011
• so <so so.do> Jan 25 2011
• so <so so.do> Jan 25 2011
• Torarin <torarind gmail.com> Jan 24 2011
• bearophile <bearophileHUGS lycos.com> Jan 24 2011
• foobar <foo bar.com> Jan 24 2011
• so <so so.do> Jan 24 2011

foobar <foo bar.com> writes:

Don Wrote:

 Steven Schveighoffer wrote:
 On Mon, 24 Jan 2011 13:36:36 -0500, bearophile 
 <bearophileHUGS lycos.com> wrote:
 
 There are six, seven or more people that wish to do something about 
 this situation. TDPL is the D2 reference, but few little changes over 
 its first edition are acceptable if they improve the D language a little.

 - Trass3r: asks if the code is ambiguous
 - Jonathan M Davis: does't like it and puts const/etc on the right
 - Simen kjaeraas thinks it's ambiguous though, and should be 
 disallowed, or at very least, discouraged.
 - Jens Mueller: Preferred style is to write const on the right
 - Andrej Mitrovic suggests to use   but says it clutters up source code.
 - I agree with Jonathan M Davis.

 What other people think about this situation? Do you want 
 const/immutable to be required on the right, or do you prefer the 
 current situation, or do you prefer some other solution?


 I wouldn't say that I *prefer* the current solution, but the current 
 solution is not so bad that I need it changed.
 
 It works fine, despite being confusing.  If it wasn't consistent with 
 the rest of the attributes, I'd say it was in need of changes, but it 
 fits within the scheme already outlined.


 It's a problem for all of the other attributes as well. I wish it were 
 disallowed for all of them.
 Incidentally, putting it afterward always works. Putting it before 
 doesn't always work, due to compiler bugs (for example, prefix 'pure' 
 doesn't work for inner functions).


This "problem" happens because D belongs to the C-family of languages which
puts the return type _before_ the function name.

Languages that don't follow this syntactic convention (some would call it a
mistake) have it very consistent and readable: 
attribute funcName inputParams -> outputParams { body }
This is the typical functional language design.

Of course I'm not suggesting to apply such a huge change to D but if I were to
design a brand new language than I would put the return type at the end. 

I feel that putting function attributes at the end increases this IMHO bad
design which boils down to a right-to-left programming language. 
I'm a native Hebrew speaker and it looks weird to me, so I can't imagine how it
could look right to any left-to-right language native speaker...

so <so so.do> writes:

 This "problem" happens because D belongs to the C-family of languages  
 which puts the return type _before_ the function name.


It has nothing to do with being a C-family language. C/C++ don't have  
this, and the rules are perfectly clear.
It is just unifying two or more unrelated things in one syntax for the  
sake of consistency (and compiler complexity?).

foobar <foo bar.com> writes:

so Wrote:

 This "problem" happens because D belongs to the C-family of languages  
 which puts the return type _before_ the function name.


 It has nothing to do with being a C-family language. C/C++ don't have  
 this, and the rules are perfectly clear.
 It is just unifying two or more unrelated things in one syntax for the  
 sake of consistency (and compiler complexity?).


C++ style aka Yoda style:
1. public double func(int input) const; 
2. const double func(int input); 
3. const double func(int input) const; 

VS. 
hypothetical left-to-right style:
1. public const func (int input) -> (double); 
2.  func (int input) -> (const double);
3. const func (int input) -> (const double); 

Which ordering makes for a more natural read?

foobar <foo bar.com> writes:

so Wrote:

 C++ style aka Yoda style:
 1. public double func(int input) const;
 2. const double func(int input);
 3. const double func(int input) const;

 VS.
 hypothetical left-to-right style:
 1. public const func (int input) -> (double);
 2.  func (int input) -> (const double);
 3. const func (int input) -> (const double);

 Which ordering makes for a more natural read?


 For you or for me? :)


Look at this from a "It reads like English" prospective and not from a "I'm an
experienced c++ programmer and therefore already used to this crap"
perspective. 
In other words, if you were just starting to learn your first programming
language, what would confuse you less? 

foobar <foo bar.com> writes:

so Wrote:

 Look at this from a "It reads like English" prospective and not from a  
 "I'm an experienced c++ programmer and therefore already used to this  
 crap" perspective.
 In other words, if you were just starting to learn your first  
 programming language, what would confuse you less?


 If i was starting to learn a language, everything would confuse me.
 I know C rules, i learned it with zero hostility to any other language, it  
 is perfectly natural to me.
 Ok you said your natural language is not English, how is that you still  
 speak it, could be because you just learned its basics?
 Which one is the Yoda now? Hebrew or English? Which one is natural? Or i  
 should ask which one is natural for "you"?


Boy you missed the point by about 2.5 light years.. 

All I said is that Since D is English based (terminology, etc) it would make
sense to follow a more English like word ordering in order to make the learning
curve less steep. It obviously doesn't apply to someone who's already ahead of
the learning curse such as yourself. 
There are Hebrew (and many other languages..) based programming languages out
there and analogously it would make sense to strive for a Hebrew look and feel
for those as well.

Your argument boils down to something like "Who needs cars? I'm riding my horse
Johnny since childhood..Feels natural to me" This has no relevance to an
objective comparison between a car and a horse.

foobar <foo bar.com> writes:

so Wrote:

 Boy you missed the point by about 2.5 light years..


 This can go forever as long as one of us resist to simple reasoning and  
 analogy,
 and the other one has the energy to continue.
 
 All I said is that Since D is English based (terminology, etc) it would  
 make sense to follow a more English like word ordering in order to make  
 the learning curve less steep.


 We are not teaching PL to monkeys, though i am not sure if they would find  
 this an issue.
 Math is another language and it is quite flexible, I don't see people that  
 left to right oriented use "one add two equal three",
 while the others use "three equal one add two" and flaming the others.  
 After you learn the damn rule (which is in the basics of any language),  
 both equally natural.
 
 Your argument boils down to something like "Who needs cars? I'm riding
 my horse Johnny since childhood..Feels natural to me" This has no
 relevance to an objective comparison between a car and a horse.


 No.
 And i can't get better than that so this discussion for me now pointless.


No one is flaming here, this is just an academic discussion and I'm sorry if
you took offense. 

The subject of this discussion is the learning curve and *not* about teaching
monkey to program.
 I'm simply stating that each language (programming or otherwise) has a
learning curve which can be statistically measured for an average human being.
Fact is that for the _same_ person it takes more time to learn C++ compared to
other languages. So I'm *not* talking about how smart you need to be in order
to learn C but rather how long will it take you to learn different programming
languages and comparing _the_languages_ based on that metric. 

Math is actually a very good example: It takes many years to learn math (from
first class to university) and therefore it has a very steep learning curve. 

Here's another perspective: 
A professor that teaches introduction to CS in first semester to students that
never programmed before needs to choose a programing language. One of the
criteria for choosing which language to use is of course the learning curve. 
I'm sure you know that not all universities choose c/c++ for this. In fact, I
know of several universities that use scheme as that first programming language.

foobar <foo bar.com> writes:

so Wrote:

 Here's another perspective:
 A professor that teaches introduction to CS in first semester to  
 students that never programmed before needs to choose a programing  
 language. One of the criteria for choosing which language to use is of  
 course the learning curve.
 I'm sure you know that not all universities choose c/c++ for this. In  
 fact, I know of several universities that use scheme as that first  
 programming language.


 C++ is complex, it is obvious why it is harder to learn.
 Other languages don't have this mostly because they are not as powerful (i  
 don't think i need to explain this).
 And this is what i mean, the reason its complexity, not the building  
 blocks we are talking about. (again, i don't believe this syntax has  
 anything to do with C++ being complex).


C++ is indeed complex and one of the reasons is its syntax (believe it or not).
There was even an academic project to re-syntax C++ with the exact same
semantics.
Of course it's not the only cause of complexity in C++ but it is definitely one
of the main ones. 

C++'s complexity has nothing to do with it's "power". D is as powerful and is
less complex to use which is why we are here and not on the C++ dev mailing
list. for example, D's classes/structs are way better than equivalent c++ code. 

foobar <foo bar.com> writes:

so Wrote:

 C++ is indeed complex and one of the reasons is its syntax (believe it  
 or not). There was even an academic project to re-syntax C++ with the  
 exact same semantics.
 Of course it's not the only cause of complexity in C++ but it is  
 definitely one of the main ones.


 If that is the case, you are probably right, but still i can't quite grasp  
 it.
 
 C++'s complexity has nothing to do with it's "power". D is as powerful  
 and is less complex to use which is why we are here and not on the C++  
 dev mailing list. for example, D's classes/structs are way better than  
 equivalent c++ code.


 Well if you think the complexity has nothing to do with power, how can you  
 use D as a counterexample? :)


"power" is a very subjective and problematic measure. We're discussing Turing
complete languages and nothing prevents me from implementing a
compiler/interpreter from one language to another thus gaining its "power". 
What we really want to talk is ease of expressiveness.
C++ is more complex than D which means its harder to express oneself in c++.
The difference is not that you can express something in one language but not in
another (Both are Turing complete) but rather the *difficulty* of expressing
the same thing in both languages.

That difficulty makes for a steeper learning curve. 

so <so so.do> writes:

 C++ style aka Yoda style:
 1. public double func(int input) const;
 2. const double func(int input);
 3. const double func(int input) const;

 VS.
 hypothetical left-to-right style:
 1. public const func (int input) -> (double);
 2.  func (int input) -> (const double);
 3. const func (int input) -> (const double);

 Which ordering makes for a more natural read?


For you or for me? :)

so <so so.do> writes:

 Look at this from a "It reads like English" prospective and not from a  
 "I'm an experienced c++ programmer and therefore already used to this  
 crap" perspective.
 In other words, if you were just starting to learn your first  
 programming language, what would confuse you less?


If i was starting to learn a language, everything would confuse me.
I know C rules, i learned it with zero hostility to any other language, it  
is perfectly natural to me.
Ok you said your natural language is not English, how is that you still  
speak it, could be because you just learned its basics?
Which one is the Yoda now? Hebrew or English? Which one is natural? Or i  
should ask which one is natural for "you"?

so <so so.do> writes:

 C++ style aka Yoda style:
 1. public double func(int input) const;


Also, you can't do this in C++.
Which was my point.

so <so so.do> writes:

 Also, you can't do this in C++.
 Which was my point.


Argh, hate it that you can't edit posts, ignore the second line.

so <so so.do> writes:

 Boy you missed the point by about 2.5 light years..


This can go forever as long as one of us resist to simple reasoning and  
analogy,
and the other one has the energy to continue.

 All I said is that Since D is English based (terminology, etc) it would  
 make sense to follow a more English like word ordering in order to make  
 the learning curve less steep.


We are not teaching PL to monkeys, though i am not sure if they would find  
this an issue.
Math is another language and it is quite flexible, I don't see people that  
left to right oriented use "one add two equal three",
while the others use "three equal one add two" and flaming the others.  
After you learn the damn rule (which is in the basics of any language),  
both equally natural.

 Your argument boils down to something like "Who needs cars? I'm riding
 my horse Johnny since childhood..Feels natural to me" This has no
 relevance to an objective comparison between a car and a horse.


No.
And i can't get better than that so this discussion for me now pointless.

so <so so.do> writes:

 Here's another perspective:
 A professor that teaches introduction to CS in first semester to  
 students that never programmed before needs to choose a programing  
 language. One of the criteria for choosing which language to use is of  
 course the learning curve.
 I'm sure you know that not all universities choose c/c++ for this. In  
 fact, I know of several universities that use scheme as that first  
 programming language.


C++ is complex, it is obvious why it is harder to learn.
Other languages don't have this mostly because they are not as powerful (i  
don't think i need to explain this).
And this is what i mean, the reason its complexity, not the building  
blocks we are talking about. (again, i don't believe this syntax has  
anything to do with C++ being complex).

so <so so.do> writes:

 C++ is indeed complex and one of the reasons is its syntax (believe it  
 or not). There was even an academic project to re-syntax C++ with the  
 exact same semantics.
 Of course it's not the only cause of complexity in C++ but it is  
 definitely one of the main ones.


If that is the case, you are probably right, but still i can't quite grasp  
it.

 C++'s complexity has nothing to do with it's "power". D is as powerful  
 and is less complex to use which is why we are here and not on the C++  
 dev mailing list. for example, D's classes/structs are way better than  
 equivalent c++ code.


Well if you think the complexity has nothing to do with power, how can you  
use D as a counterexample? :)

Torarin <torarind gmail.com> writes:

2011/1/24 foobar <foo bar.com>:
 This "problem" happens because D belongs to the C-family of languages which
puts the return type _before_ the function name.

 Languages that don't follow this syntactic convention (some would call it a
mistake) have it very consistent and readable:
 attribute funcName inputParams -> outputParams { body }
 This is the typical functional language design.


It is arguably more consistent to have the return type come first, as
in variable declarations:

int a = 4;
int foo() { return 5; }

Both "foo()" and "a" are now of type int.

Torarin

bearophile <bearophileHUGS lycos.com> writes:

foobar:

 This "problem" happens because D belongs to the C-family of languages which
puts the return type _before_ the function name.


Of course C++ has everything :-) See the trailing-return-type feature of C++0x:
http://en.wikipedia.org/wiki/C%2B%2B0x#Alternative_function_syntax
http://stackoverflow.com/questions/4523617/omit-return-type-in-c0x

Bye,
bearophile

foobar <foo bar.com> writes:

bearophile Wrote:

 foobar:
 
 This "problem" happens because D belongs to the C-family of languages which
puts the return type _before_ the function name.


 Of course C++ has everything :-) See the trailing-return-type feature of C++0x:
 http://en.wikipedia.org/wiki/C%2B%2B0x#Alternative_function_syntax
 http://stackoverflow.com/questions/4523617/omit-return-type-in-c0x
 
 Bye,
 bearophile


Of course they added it, they also experienced similar problems with the
current syntax since it is out of place in the reading order. 

so <so so.do> writes:

 Of course C++ has everything :-) See the trailing-return-type feature of  
 C++0x:
 http://en.wikipedia.org/wiki/C%2B%2B0x#Alternative_function_syntax
 http://stackoverflow.com/questions/4523617/omit-return-type-in-c0x

 Bye,
 bearophile


Now i am completely lost, i can't see any connection at all!