View mode: basic / threaded / horizontal-split · Log in · Help
July 19, 2012
Re: Just where has this language gone wrong?
> It's just syntax. Eliminating syntax noise is fine. Code should 
> look
> like what it does.

Not if "eliminating noise" equals to making things harder to 
understand.

When you say (int x) { return x; } it's clear about what it is, a 
_function_ without name.
July 19, 2012
Re: Just where has this language gone wrong?
On 07/19/2012 05:03 PM, Petr Janda wrote:
>> It's just syntax. Eliminating syntax noise is fine. Code should look
>> like what it does.
>
> Not if "eliminating noise" equals to making things harder to understand.
>

Harder to understand to whom? Optimizing stuff for beginners usually
makes it a PITA to work with.

> When you say (int x) { return x; } it's clear about what it is, a
> _function_ without name.

That expression looks eg. like this in Haskell:
\x->x

(If the type of x cannot be inferred to Int, then it is (\x->x)::Int->Int)

I agree that there is some non-uniformity. It should be possible to use
=> in named function declarations.
July 19, 2012
Re: Just where has this language gone wrong?
On 07/19/2012 04:39 PM, Petr Janda wrote:
> On Thursday, 19 July 2012 at 14:31:53 UTC, travert@phare.normalesup.org
> (Christophe Travert) wrote:
>> "q66" , dans le message (digitalmars.D:172716), a écrit :
>>> (so instead of calling a(b(c(d(e(f))))) you can just call a.b.c.d.e.f())
>>
>> rather f.e.d.c.b.a, if you omit the empty parenthesis after each letter
>> (but f).
>
> Ok, but the empty parenthesis is is important,

It is not.

> it tells you about whether it's a an object or a function.
>

(No, it does not. And even if it would, )

There is usually nothing that makes this distinction terribly
important.

Furthermore, to learn the meaning of a symbol, being able to look at its 
documentation or declaration is fully sufficient / required.

> It's another thing I hate about Ruby is that a parenthesis enforcement
> is weak.

I take that to mean you dislike ruby's function call syntax. That is a
very poor thing to dislike, there is no objective justification for it.
July 19, 2012
Re: Just where has this language gone wrong?
On Thu, Jul 19, 2012 at 9:03 AM, Petr Janda <janda.petr@gmail.com> wrote:

> It's just syntax. Eliminating syntax noise is fine. Code should look
>> like what it does.
>>
>
> Not if "eliminating noise" equals to making things harder to understand.
>
> When you say (int x) { return x; } it's clear about what it is, a
> _function_ without name.
>

Nothing is stopping someone from being explicit with their types like that,
of course.

Here is the original code written in a way that is probably more familiar
to you:

auto r = map!((int x) { to!(string)(x); })(uniq(sort([5, 3, 5, 6, 8])));

Personally I find the original version to be much more readable but that
does require a basic knowledge of D's syntax. People coming from other
languages are free to use the more classic way if they wish.  It's better
to learn idiomatic usage of a language, though, instead of forcing it to be
a language you are more comfortable in.

Regards,
Brad Anderson
July 19, 2012
Re: Just where has this language gone wrong?
On Thu, Jul 19, 2012 at 9:20 AM, Brad Anderson <eco@gnuk.net> wrote:

> On Thu, Jul 19, 2012 at 9:03 AM, Petr Janda <janda.petr@gmail.com> wrote:
>
>>  It's just syntax. Eliminating syntax noise is fine. Code should look
>>> like what it does.
>>>
>>
>> Not if "eliminating noise" equals to making things harder to understand.
>>
>> When you say (int x) { return x; } it's clear about what it is, a
>> _function_ without name.
>>
>
> Nothing is stopping someone from being explicit with their types like
> that, of course.
>
> Here is the original code written in a way that is probably more familiar
> to you:
>
> auto r = map!((int x) { to!(string)(x); })(uniq(sort([5, 3, 5, 6, 8])));
>
>
Ehm...forgot the return:

auto r = map!((int x) { return to!(string)(x); })(uniq(sort([5, 3, 5, 6,
8])));


> Personally I find the original version to be much more readable but that
> does require a basic knowledge of D's syntax. People coming from other
> languages are free to use the more classic way if they wish.  It's better
> to learn idiomatic usage of a language, though, instead of forcing it to be
> a language you are more comfortable in.
>
> Regards,
> Brad Anderson
>
July 19, 2012
Re: Just where has this language gone wrong?
On 07/19/2012 05:20 PM, Brad Anderson wrote:
> On Thu, Jul 19, 2012 at 9:03 AM, Petr Janda <janda.petr@gmail.com
> <mailto:janda.petr@gmail.com>> wrote:
>
>         It's just syntax. Eliminating syntax noise is fine. Code should look
>         like what it does.
>
>
>     Not if "eliminating noise" equals to making things harder to understand.
>
>     When you say (int x) { return x; } it's clear about what it is, a
>     _function_ without name.
>
>
> Nothing is stopping someone from being explicit with their types like
> that, of course.
>
> Here is the original code written in a way that is probably more
> familiar to you:
>
> auto r = map!((int x) { to!(string)(x); })(uniq(sort([5, 3, 5, 6, 8])));
                         ^
                       return
>
> Personally I find the original version to be much more readable but that
> does require a basic knowledge of D's syntax. People coming from other
> languages are free to use the more classic way if they wish.  It's
> better to learn idiomatic usage of a language, though, instead of
> forcing it to be a language you are more comfortable in.
>
> Regards,
> Brad Anderson
July 19, 2012
Re: Just where has this language gone wrong?
On Thursday, 19 July 2012 at 14:51:59 UTC, Timon Gehr wrote:
>> On another note, (copied from wikipedia)
>>
>> foreach(item; set) {
>> // do something to item
>> }
>>
>> what's with the lax syntax being allowed?
>
> s/lax/to the point/
>
>> Shouldn't it be at least specified "auto item"?
>>
>
> Why on earth would that be the case?
>
>> I'm sorry I don't mean to be a criticizer, but it seems to me 
>> that D is
>> trying to be a dynamic-like compiled language way too hard.
>
> It's just syntax. Eliminating syntax noise is fine. Code should 
> look
> like what it does.

Additionally, allowing to omit auto is actually consistent with 
the rest of the language, which also allows you to not explicitly 
write it if the code doesn't become ambiguous (for example, you 
don't need to do "immutable auto").

David
July 19, 2012
Re: Just where has this language gone wrong?
On 07/19/2012 08:03 AM, Petr Janda wrote:
>> It's just syntax. Eliminating syntax noise is fine. Code should look
>> like what it does.
>
> Not if "eliminating noise" equals to making things harder to understand.
>
> When you say (int x) { return x; } it's clear about what it is, a
> _function_ without name.

Others beat me to it but the anonymous function can be written more 
completely as

  function string(int x) { return x.to!string(); }

(Or 'delegate' depending on the situation.)

Allow me to add a take(..., 2) to the entire expression, which is to me 
the strongest reason why UFCS can be great:

    writeln(take(map!(function string(int x) { return x.to!string(); 
})(uniq(sort([5, 3, 5, 6, 8]))), 2));

The problem is, the 2 is related to take() but they are too far apart 
above. UFCS puts them together:

  a_long_expression.take(2)

I don't like UFCS everywhere but it is very helpful in many cases.

Ali
July 19, 2012
Re: Just where has this language gone wrong?
On Thu, 19 Jul 2012 14:44:20 +0000 (UTC)
travert@phare.normalesup.org (Christophe Travert) wrote:

> "Petr Janda" , dans le message (digitalmars.D:172727), a écrit :
> > On Thursday, 19 July 2012 at 14:31:53 UTC, 
> > travert@phare.normalesup.org (Christophe Travert) wrote:
> >> "q66" , dans le message (digitalmars.D:172716), a écrit :
> >>> (so instead of calling a(b(c(d(e(f))))) you can just call 
> >>> a.b.c.d.e.f())
> >>
> >> rather f.e.d.c.b.a, if you omit the empty parenthesis after 
> >> each letter
> >> (but f).
> > 
> > Ok, but the empty parenthesis is is important, it tells you about 
> > whether it's a an object or a function.
> > 
> > It's another thing I hate about Ruby is that a parenthesis 
> > enforcement is weak.
> 
> property (functions that behaves like fields) don't require 
> empty parenthesis. This feature has been extended to all function, 
> leading to the current situation. Some people would like this to 
> disappear, and enforce strict property.

That's already happening. It's just that for the moment you have to
pass -property into DMD. Then it'll enforce "Function calls always need
parens, propertied always omit parens". Supposedly, this behavior will
become the default at some point.
July 19, 2012
Re: Just where has this language gone wrong?
On 2012-07-19 16:39, Petr Janda wrote:

> It's another thing I hate about Ruby is that a parenthesis enforcement
> is weak.

I love that :)

-- 
/Jacob Carlborg
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home