Changes requested to goals doc

[jonmeow]

Just tracking a few changes to the goals #51 requested by @josh11b

(not making these up-front due to decision in progress)

[jonmeow]

193: overarching goal can be decomposed into a few specific aspects.

josh11b:
Do we want to say anything about "reasonably fast by default" or "favors constructs that can be compiled to efficient code" or something like that? It was the sort of statement I just assumed was in the goals until I reread this section. The way this is written now, we could create a slow language as long as it was predictable and had an inline assembly escape hatch that was painful to use and hence rarely used.

jonmeow:
TODO in #106

Note though, I don't think this is an issue right now due to "leave no room for a lower level language" -- inline ASM is still breaking the "rules and structure of Carbon". Arguably it may be unavoidable, but I think the implications should address most of your concern, could maybe just be more explicit.

364: to understand.

josh11b:
"... and the resulting performance more predictable"?

jonmeow:
Adding as a TODO; #106

424: scalability options for build systems of large software.

josh11b:
Do we want to say anything about development vs. release builds here? If the overall goal is fast development, separate compilation would mostly apply to development builds. For the same reason, incremental build and link performance may be as or even more important than separate compilation.

jonmeow:
I'll think this over, it definitely seems too much for this change. #106

439: is good but insufficient. Both SIMD and SPMD must be directly addressable in

josh11b:
I found it a bit unclear what point these two sentences about SIMD and SPMD were after. Are SIMD & SPMD supposed to be an exhaustive list of ways of implementing parallel constructs? Is this specifying that there should be at least three ways of writing parallel code (SIMD, SPMD, and something higher level that compiles to one of the other in some mysterious black box way)? Is it saying there is some relationship between SIMD/SPMD and the native programming models of platforms we want to target?

jonmeow:
TODO work on phrasing; #106

442: OS/environment distinctions such as desktop versus mobile versus bare metal.

josh11b:
Add "embedded" here? I'm thinking of examples like game developers writing software for game consoles, which doesn't really fit in any of the three categories.

jonmeow:
TODO work on phrasing; #106

584: and having reasonable test coverage that passes under sanitizers.

josh11b:
Wording nit: tests are the thing that pass under sanitizers, not coverage

jonmeow:
TODO work on phrasing; #106

[chandlerc]

Another one to capture here is a formatting quirk w.r.t. the emdash used with the John Carmack quote. Applying the hyphenation rule from the style guide here seems odd as this isn't a hyphen.

[jonmeow]

"... and the resulting performance more predictable"?

I'm skipping this one: after adding the paragraph to the performance goal, I think it's not necessary, especially in the "Code that is easy to read, understand, and write" section. The relevant sentence/paragraph from 364 is currently focused on understandability.

[jonmeow]

"Add "embedded" here?"

Around 442, embedded could be added, as could microcontrollers, etc. I think we need to let the success criteria address this -- we shouldn't aim to have this duplicate that. Also, a 4-way "versus" I think becomes really just quite difficult to read. To whit, rephrasing a bit, and dropping "bare metal" rather than adding "embedded"

[josh11b]

"... and the resulting performance more predictable"?

I'm skipping this one: after adding the paragraph to the performance goal, I think it's not necessary, especially in the "Code that is easy to read, understand, and write" section. The relevant sentence/paragraph from 364 is currently focused on understandability.

I think this document would still benefit from some statement establishing a link between simple implementation and predictable performance, beyond stating we want them individually.

[jonmeow]

"... and the resulting performance more predictable"?
I'm skipping this one: after adding the paragraph to the performance goal, I think it's not necessary, especially in the "Code that is easy to read, understand, and write" section. The relevant sentence/paragraph from 364 is currently focused on understandability.

I think this document would still benefit from some statement establishing a link between simple implementation and predictable performance, beyond stating we want them individually.

I agree, and think that my changes to the performance section do that.

[josh11b]

I must be missing some change, I don't see anything like that. Could you give me a quote to search for?

…

On Wed, Jul 22, 2020 at 4:10 PM Jon Meow ***@***.***> wrote: "... and the resulting performance more predictable"? I'm skipping this one: after adding the paragraph to the performance goal, I think it's not necessary, especially in the "Code that is easy to read, understand, and write" section. The relevant sentence/paragraph from 364 is currently focused on understandability. I think this document would still benefit from some statement establishing a link between simple implementation and predictable performance, beyond stating we want them individually. I agree, and think that my changes to the performance section do that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#106 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUNHVZPJCHIHP7LCUZZA53R45WXZANCNFSM4OVBAFAQ> .

-- Josh

[jonmeow]

I must be missing some change, I don't see anything like that. Could you give me a quote to search for?
…
On Wed, Jul 22, 2020 at 4:10 PM Jon Meow @.***> wrote: "... and the resulting performance more predictable"? I'm skipping this one: after adding the paragraph to the performance goal, I think it's not necessary, especially in the "Code that is easy to read, understand, and write" section. The relevant sentence/paragraph from 364 is currently focused on understandability. I think this document would still benefit from some statement establishing a link between simple implementation and predictable performance, beyond stating we want them individually. I agree, and think that my changes to the performance section do that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#106 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUNHVZPJCHIHP7LCUZZA53R45WXZANCNFSM4OVBAFAQ .
-- Josh

"Idiomatic code should have good performance."

[josh11b]

I must be missing some change, I don't see anything like that. Could you give me a quote to search for?
…
On Wed, Jul 22, 2020 at 4:10 PM Jon Meow @.***> wrote: "... and the resulting performance more predictable"? I'm skipping this one: after adding the paragraph to the performance goal, I think it's not necessary, especially in the "Code that is easy to read, understand, and write" section. The relevant sentence/paragraph from 364 is currently focused on understandability. I think this document would still benefit from some statement establishing a link between simple implementation and predictable performance, beyond stating we want them individually. I agree, and think that my changes to the performance section do that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#106 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUNHVZPJCHIHP7LCUZZA53R45WXZANCNFSM4OVBAFAQ .
-- Josh

"Idiomatic code should have good performance."

That does not capture what I was trying to convey. Yes, idiomatic code should have good performance. And yes, it says performance should be predictable. I had requested something additional conveying, in the simple implementation section, that a simple implementation is part of our strategy from for achieving the goal of predictable performance. Right now nothing in the doc captures that link.