goals and style in user-facing code

[kybr]

i would like to start a conversation about our goals and style in user-facing code (i.e., examples). i've sketched out some of my position in the comments of this refactored example:

https://github.com/AlloSphere-Research-Group/allolib/blob/style_opinions/examples/ui/dynamic_scene.cpp

[grrrwaaa]

I'm lurking, but can I just say that I entirely agree with these comments and the rationales.

[mantaraya36]

I also agree with everything, except for the << operator. I added this as a way to simplify usage and to make code shorter. I'm very interested in hearing how students haver received this.

…

On Tue, Mar 5, 2019 at 11:06 AM Graham Wakefield ***@***.***> wrote: I'm lurking, but can I just say that I entirely agree with these comments and the rationales. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#22 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAatx9YfZQ4lttrMNDM8voblgE8kYolTks5vTsAugaJpZM4bfD6P> .

[kybr]

sorry. i sent that before it was done.

while students have not complained about this usage of <<, they do struggle with << and >> generally.

in c++ >> and << mean "shift bits right" and "shift bits left". they also mean "pull from stream" and "append to stream" respectively. neither of these usages have any basis is math where they mean "much greater than" and "much less than". this last meaning would make some sense to a person new to programming.

c++ "stream" i/o makes use of << and >>. that's the usage that new students come across (and struggle with) first. IMHO, c++ stream i/o is awful. take a poll of nearby c++ users and see how many favor printf! it's atomic, well-documented, and ubiquitous. i avoid using the >> and << operators for anything other than bitshifting. IMHO it is a mistake that our OSC implementation uses >> (e.g., Message m; float f; m >> f;) New students struggle with >> and << when used in the traditional c++ contexts: stream i/o and bit-shifting. so let's not introduce a new meaning and usage for >> and << in user code.

in this use, << is put forward as a shortcut for adding parameters to a gui. +=, +, or .reg() (with chaining) would work just as well. there is nothing in << that suggests it is natural or obvious to use it to add a parameter to a gui. any operator in this case would be less readable (IMHO) than a method such as .reg or .add. if the point is to save typing, we could use variadic template function to allow something like .add(p1, p2, p3, p4, p5).

let's please leave << and >> for bit shifting and stream operations.