Skip to content
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

Minor English fixes #29338

Merged
merged 1 commit into from
Sep 25, 2018
Merged

Minor English fixes #29338

merged 1 commit into from
Sep 25, 2018

Conversation

mark-summerfield
Copy link
Contributor

Using foo/bar/baz examples is fine for abstract thinkers but unhelpful for applied thinkers. Using "realistic" (but neutral, non-distracting) names works for applied thinkers and is just as easy for abstract thinkers, so in my view is to be preferred. For example, instead of struct Foo bar baz end, I'd have done, e.g., struct Tag name value end, etc. Similarly, I'd replace obj with child, parent, sibling or link. I haven't done this of course because this is a doc policy decision and I'm just doing English fixes. (Well I changed xx to data since the former looks like a 'fixme' tag.)

Another global thing I've noticed is that the docs clearly have multiple authors so there is a fair amount of stylistic inconsistency. Doesn't matter for online docs, but wouldn't be nice if turned into book form.

The .md files tend to have quite long line lengths. I have tried to preserve the lines to make the diffs simpler to read but personally I'd have used a maximum line width since that's easier to edit and diff across a wide range of editors.

The OrderedPair example shows how to enforce an invariant by throwing an exception. This is fine of course, but I think an additional or alternative example should be given that shows how to preserve an invariant where possible, e.g.,
OrderedPair(x,y) = x > y ? new(y,x) : new(x,y), or a different example altogether. Unless 'fixing' like this is bad practice in Julia?

Liked the OurRational and SummedArray examples and the explanations that followed them.

Using foo/bar/baz examples is fine for abstract thinkers but unhelpful for applied thinkers. Using "realistic" (but neutral, non-distracting) names works for applied thinkers and is just as easy for abstract thinkers, so in my view is to be preferred. For example, instead of struct Foo bar baz end, I'd have done, e.g., struct Tag name value end, etc. Similarly, I'd replace obj with child, parent, sibling or link. I haven't done this of course because this is a doc policy decision and I'm just doing English fixes. (Well I changed xx to data since the former looks like a 'fixme' tag.)

Another global thing I've noticed is that the docs clearly have multiple authors so there is a fair amount of stylistic inconsistency. Doesn't matter for online docs, but wouldn't be nice if turned into book form.

The .md files tend to have quite long line lengths. I have tried to preserve the lines to make the diffs simpler to read but personally I'd have used a maximum line width since that's easier to edit and diff across a wide range of editors.

The OrderedPair example shows how to enforce an invariant by throwing an exception. This is fine of course, but I think an additional or alternative example should be given that shows how to preserve an invariant where possible, e.g.,
OrderedPair(x,y) = x > y ? new(y,x) : new(x,y), or a different example altogether. Unless 'fixing' like this is bad practice in Julia?

Liked the OurRational and SummedArray examples and the explanations that followed them.
@KristofferC
Copy link
Member

Thanks for working on this @mark-summerfield!

@KristofferC KristofferC added the docs This change adds or pertains to documentation label Sep 24, 2018
@ViralBShah
Copy link
Member

This appears good to merge.

@fredrikekre fredrikekre merged commit 94aa39b into JuliaLang:master Sep 25, 2018
@mark-summerfield
Copy link
Contributor Author

Thanks @KristofferC I really appreciate you saying so.

KristofferC pushed a commit that referenced this pull request Sep 30, 2018
KristofferC pushed a commit that referenced this pull request Feb 11, 2019
KristofferC pushed a commit that referenced this pull request Feb 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs This change adds or pertains to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants