-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Why Elm?" section: condense "lots of rules" with "some bugs are impossible" #35
Comments
The separation was intentional, as I feel like intro to elm materials can be somewhat cheerleader-y about the language's strictness. I wanted to faithfully describe the rules before explaining why they are good, so that readers can have their own initial reaction to them. That said, I could definitely be missing a rewrite here. Would love to see an alternate draft. |
I would like to work on an alternate draft, so I'll piggy back on this issue but let me first describe my motivations, so you can let me know if this merits a separate issue (or if the ideas themselves have already been though through.) My idea has been to separate the "Elm brings benefits of statically compiled language programming to front end" parts, from the "Elm gives you a framework like React/JSX" part. I think these are two distinct points to using Elm, and it would help to clarify that. Additionally, I want to take this opportunity to make the language a bit more "active," in the sense largely conveyed in this guide or perhaps this one about writing persuasive essays. I'll ping folks if I don't hear back in a day or two, before I proceed to work on a PR. PS: re the original point, I actually agree with @raorao that separating the concept from the evidence is in fact a Good Thing, so given that I'm probably not going to fix the original request, this shd maybe go to a new issue. |
This is the intention of the current draft, as the "framework" stuff is mostly explained in "Building User Interfaces." If you feel like "Why Elm?" talks too much about frameworks, I would definitely appreciate a PR to fix.
I would need to see some examples of fixes to be convinced. The voice of curriculum is intentionally passive -- this is not a piece of argumentative writing, and as such should not emphasize the subject over statements of fact. My sense is that curriculum should be expository, not argumentative. (though this may simply may be my bias, as I was trained in news writing, which roughly fits in to the expository category of the classical rhetorical model). I would not be surprised if I was guilty of poorly deploying passive constructions (e.g. "mistakes were made" vs "we made a mistake") and perhaps that is what you mean to fix. Again, I would love to see some specific examples of possible issues. |
Fair enough - I'll submit my suggestions as a PR and you can feel free to Certainly the expository style came through, but the "we'd argue that ... On Tue, Nov 1, 2016 at 4:33 PM, Srinivas Rao [email protected]
|
The few paragraphs starting at
I think this part could be shorter and made to sound more motivating if the list of rules and the list of benefits were combined into one list (since each rule corresponds to preventing a certain type of bug).
The text was updated successfully, but these errors were encountered: