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

examples of "orthogonality" questionable #541

delocalizer opened this Issue Mar 31, 2017 · 2 comments


None yet
3 participants

delocalizer commented Mar 31, 2017

@gvwilson A quibble - I don't believe that the examples of . and .. given here in lesson 2 and wildcard expansion given later in lesson 4 are really examples of orthogonal design; . and .. are simply conveniences provided by the filesystem, and wildcards are a convenience provided by the shell. Orthogonal design is design for composability and lack of side-effects. I think the line "they are interpreted the same way by every program" is particularly problematic because it might imply that if you were to write a new program, you should handle . and .. or * and ? specially in your cli args, to maintain "orthogonal design". If you want to introduce the concept of orthogonality I believe it would be better off in the lesson on pipes, with the example of coreutils (mostly) being designed to use stdin and stdout streams in the same way, allowing pluggable combinations of things.


This comment has been minimized.

navjotk commented Mar 20, 2018

I agree with this thought. This is exactly what I thought when I was going through the lessons - that ./.. and wildcards aren't very good examples of orthogonality - STDIN/STDOUT are better examples.


This comment has been minimized.


jttkim commented Mar 21, 2018

Technical . and .. can be used in the same way with all programs because they're all coded using the same API / libraries to access files by name. So the the statement that "they are interpreted in the same way by every program" is correct, and the consistency of interpretation comes from using the same mechanism of interpretation, so this is orthogonality -- the libraries are an orthogonal component that is factored out from almost all programs.

Explaining this technical background is probably too distracting / difficult for this lesson, and without more explanation the "interpreted the same way by every program" phrase can indeed leave novices with a misconception that consistent interpretation is achieved by code duplication.

A solution might be to keep focus on the user level at this point, and replace "hey are interpreted the same way by every program" with "you can use these elements with all programs".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment