Perhaps another way to look at it is the programmer's migration path, or how to
get them from where they are today to a place where they're using Rust even
more effectively.
In that regard, programmers can get off the ground immediately with traditional
C-style programs:
auto tmp;
if (p) {
foo();
tmp = bar();
} else {
tmp = baz();
}
But then you can show them that, as an *additional* feature, you can use a
block as an expression by leaving off the final semicolon:
auto tmp = if (p) { foo(); bar() } else { baz() };
Not the best example, but hopefully I'm halfway getting the point across? I
guess what I'm saying is, rather than trying to explain how the whole system
ties together, the language can be presented in stages -- start with
traditional C-like syntax, then add a moderate dose of expressionliness.
Dave
On Nov 24, 2010, at 9:59 AM, Graydon Hoare wrote:
> On 10-11-24 09:06 AM, Patrick Walton wrote:
>
>> An alternate way of thinking about proposal #3 is that, as a rule of
>> thumb, ";" always means "ignore the result of the previous statement".
>> Formulating it this way might ease the cognitive load on users.
>
> While I always appreciate having new ways of explaining a language feature, I
> should relate a certain pithy phrase often related by Lessig about politics,
> which applies equally to languages: "if you're explaining, you're losing".
>
> Our business here is, in a large measure, to anticipate what users will
> *already* be thinking, and to figure out something that fits well enough to
> be unsurprising, palatable.
>
> (While, of course, having superior precision and safety properties than the
> sum of their vague and contradictory expectations :)
>
> The problem is that our target market is largely people from statement
> languages, who simply don't have this issue. So modeling their assumptions
> directly means "various other techniques" to solve the same design pressures
> -- ternary expressions, use of subordinate functions with inlining and
> constexpr modifiers ... -- and we're sort of taking a sober second look at
> that whole path and wondering if the expression-language people live in a
> substantially better world. And if so, how to get there without losing the
> statement-language audience.
>
> Hard/subtle/tradeoffy design issue.
>
> -Graydon
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
