Am 31.01.2012 14:55 schrieb "flying sheep" <truefly...@googlemail.com>:
>
> hi,
> i thought about the syntax and found some (imho) oddities:
>
> 1. varargs:
>
> it’s no problem to define a constructor to accept an optional List
> argument, i know, but defining your own “literals” has its own charm
> and is less tedious and more DRY.
>
> instead of new Set.from(['x', 'y']), new Set('1', '2', '3') could be
> used.
>
> 2. multistatement lambdas
>
> scala does function definitions like that: for functions without
> return value, you type def <name> <block>, for functions with one, you
> type def <name> = <statement|block>
>
> you have to use block braces for the first one, but can leave them out
> for the second (for e.g. getters). in functions returning something,
> the return value of the last statement in the control flow is returned
> if it is reached, but you can also break out of the control flow by
> using the return keyword. i think it’s nice and functional.
>
> i think dart’s lambdas (=>) are odd: they are as powerless as
> python’s,
What do you mean with "powerless"?
>but dart allows anonymous functions.
>
> i’s most likely too late to change it, but designating at the
> beginning if a function returns something (different than null) and
> then returning the last value is better than the C(++) way.
>
> what do you think? will “=>” be viewed like python’s lambda in the
> future (useful sometimes, but never fully thought through)?
What do you mean with "never fully thought through"?
I haven't understood what the concrete critics are.
BTW: AFAIC Scala has the exact same lambda construct, so I am confused by this post.
hi,
i thought about the syntax and found some (imho) oddities:
1. varargs:
it’s no problem to define a constructor to accept an optional List
argument, i know, but defining your own “literals” has its own charm
and is less tedious and more DRY.
instead of new Set.from(['x', 'y']), new Set('1', '2', '3') could be
used.
2. multistatement lambdas
scala does function definitions like that: for functions without
return value, you type def <name> <block>, for functions with one, you
type def <name> = <statement|block>
you have to use block braces for the first one, but can leave them out
for the second (for e.g. getters).
in functions returning something,
the return value of the last statement in the control flow is returned
if it is reached, but you can also break out of the control flow by
using the return keyword. i think it’s nice and functional.
i’s most likely too late to change it, but designating at the
beginning if a function returns something (different than null) and
then returning the last value is better than the C(++) way.
what do you think? will “=>” be viewed like python’s lambda in the
future (useful sometimes, but never fully thought through)?
Well, do you think it's a problem for developers to know that anythingin language has a returning value?
Anyway, this feature isn't prevent you from writing an old fasioned style.
But there is potentially a huge boost of language grow with that feature because programs can be the way more compact.
As much as I can follow the argumentation, it is a very small path where you can easily down at one side or the other.
Am 01.02.2012 20:38 schrieb "Bob Nystrom" <rnys...@google.com>:
> Whenever possible, we try to minimize the amount of
> new stuff you have to know to be productive in Dart.
That is a good maxime, but a subjective view of each user if you achieved that or not. It depends on where one comes from.
> It's really hard to get people to use a new language and it
> doesn't take much friction before they just give up entirely.
That is true, but the friction may also exist due to well known but annoying properties taken from the predecessors. Beside that, the decision if a property is a well known and good, a well known and bad, a new but highly appraised or a new but confusing concept is really tough and also subjective.
Sometimes I wish for something like plaedoyers (right word?) for and against features followed by a public voting, to get a better understanding of how the masses think about it. (Well, democracy in language design is not really doable,I know!)
> If statements make the language more palatable for
> some users, that adds value.
This is right. So the question is: Is it more palatable? Would it be really a friction otherwise?
> Of course, you can always avoid features you don't like in code you write. The problem is in code you read. If we made everything an expression in Dart it's only a matter of time before you run into code like:
>
> last(List items) {
> if (items.length > 0) items[items.length - 1];
> }
>
> That code is going to deeply confuse someone coming from a statement-oriented background because it looks familiar but it also doesn't look like something that would work at all.
>
Right. From an expression perspective mainly because it is incomplete. Where is the else? It *should* be invalid code!
> I like not having statements too, but in practice I don't think it makes that much of a code-size difference. Even in languages that don't have statements, many things like variable declarations are still "statement-like". We have => for single-expression method bodies which covers a lot of the simple use cases:
>
> last(List items) => (items.length > 0) ? items[items.length - 1] : null;
>
The current promises of familiarity may lead to the false impression that there may be no need to learn or develop an idiomatic Dart.
In my eyes it is much easier for a language to communicate a clean concept of idioms when they give the user recognizable advantages, than to communicate familiarity that is not achievable in all respects.
(I only say: C style type annotation, functions first-class, typing optional ... a weird combination ... born out of "familiarity"?)
> Whenever possible, we try to minimize the amount of
> new stuff you have to know to be productive in Dart.That is a good maxime, but a subjective view of each user if you achieved that or not. It depends on where one comes from.
That is true, but the friction may also exist due to well known but annoying properties taken from the predecessors. Beside that, the decision if a property is a well known and good, a well known and bad, a new but highly appraised or a new but confusing concept is really tough and also subjective.
Sometimes I wish for something like plaedoyers (right word?) for and against features followed by a public voting, to get a better understanding of how the masses think about it. (Well, democracy in language design is not really doable,I know!)
> If statements make the language more palatable for
> some users, that adds value.This is right. So the question is: Is it more palatable? Would it be really a friction otherwise?
> last(List items) {
> if (items.length > 0) items[items.length - 1];
> }
>
> That code is going to deeply confuse someone coming from a statement-oriented background because it looks familiar but it also doesn't look like something that would work at all.
>Right. From an expression perspective mainly because it is incomplete. Where is the else? It *should* be invalid code!
The current promises of familiarity may lead to the false impression that there may be no need to learn or develop an idiomatic Dart.