getify / Functional-Light-JS

Pragmatic, balanced FP in JavaScript. @FLJSBook on twitter.
http://FLJSBook.com
Other
16.6k stars 1.96k forks source link

Copyediting suggestions for Chapter 10 #130

Closed jtassia closed 6 years ago

jtassia commented 6 years ago

Chapter 10 suggestions/queries...

Edit suggestion 1:

Original: "At this point of the book, you now have all the raw concepts in place for the foundations of FP that I call "Functional-Light Programming"."

Suggestion: "At this point of the book, you now have all the raw concepts in place for the foundations of what I call "Functional-Light Programming"."

Edit suggestion 2:

Original: "For operations that will be proceed over time, all..."

Suggestion: "For operations that will be processed over time, all..."

Query 1:

Original: "to have any hope of making such complex code more readable, the author has to take a lot more concern than they normally would..."

Query: Replace "concern" with "care" ?

Query 2

Original: "But if you've understood Functional-Light Programming in this text, and now understood how asynchronous-time can be modeled..."

Query: Exchange the second instance of "understood" for "grasp" ?

Query 3

Kyle: Seems like sometimes it's "Observable" (cap) and sometimes "observable" (l/c). Should we be consistent one way or the other, or is there a reason why it's been styled like this?

Yes, I promise I've read the Contributions Guidelines

getify commented 6 years ago

Suggestion: "At this point of the book, you now have all the raw concepts in place for the foundations of what I call "Functional-Light Programming"."

Hmmm... the principles from this book are, quite literally, the foundations of FP. That subset, and the particular application of them, is what I call "Functional-Light Programming". By removing of "FP", I think we miss that "subset" notion.

Is there another way to say it which still preserves that idea?

Suggestion: "For operations that will be processed over time, all..."

This is a tough call. I used "proceed" to indicate that they drive themselves (in response to streams of external events, etc). "Processed" seems to indicate the program choosing what to do, when, where as "proceed" was meant to imply that the processing was more random and/or externally applied.

Original: "to have any hope of making such complex code more readable, the author has to take a lot more concern than they normally would..." Query: Replace "concern" with "care" ?

Sure.

Original: "But if you've understood Functional-Light Programming in this text, and now understood how asynchronous-time can be modeled..." Query: Exchange the second instance of "understood" for "grasp" ?

"grasped" (past-tense, to match)

Seems like sometimes it's "Observable" (cap) and sometimes "observable" (l/c). Should we be consistent one way or the other, or is there a reason why it's been styled like this?

I expected this question to come up! Not sure if you recall, but we had similar questions during editing of several of my YDKJS books, as well, specifically around "Promises" vs "promises". As then, I have the same mindset applied to my capitalization decisions here.

Here's my take on this: the notion of Observables (capitalized) is the proper noun form (general concept of it), like "Observables is a practice that ...", where we're referring specifically to that pattern, similar to how we capitalize "Functional Programming". By contrast, observables (non-capitalized) is the common noun form (specific instances of it), like "These values are observables that we can ...", similar to how we wouldn't capitalize "I have written this functional program".

Back in YDKJS, I made an identical argument for how "Promises" is the general interface feature of the language, whereas "promises" are the individual instances of values.

Does that make sense?

jtassia commented 6 years ago

I think Edit Suggestion #1 and #2 are OK as is, based on reading your feedback. Those make sense to me now! And I remember now about Promises/promises! Sounds good to me. :)

Added the other two edits to my branch.