baltar · HackerTrans

So their definition of "service" is "physical goods, platform services, software, websites, applications, and content". Does this mean that if I wrote, say, a 3D modelling tool for the Rift, than anything that my users create could be grabbed by them (and given to others) for free?

baltar

10 anni fadiscuss

It's not my job to pick a definition but Twitter's (and other social sites'). In fact, they already did (defining "hateful conduct"): "You may not promote violence against or directly attack or threaten other people on the basis of race, ethnicity, national origin, sexual orientation, gender, gender identity, religious affiliation, age, disability, or disease." Pretty basic stuff.

If it was my choice, I'd pick a wider definition, accepting that there will be an area of uncertainty and errors. However, I think that it is still far better to exclude some people (for a while?) than to e.g. subject many more people to constantly being called pejorative terms (including implications to being a slave, an animal or an exhibit)/belittled because of identity/violently threatened etc.

You could also see it this way: up to now the officially used definition was in effect that nothing is racist/sexist.

baltar

10 anni fadiscuss

> That's precisely why you don't optimize. If you find you need fast code, you use a different language.

Ah, now I get you :)

> First, generally you can tell by looking at a method's code what it's expecting you to pass to it.

Here we might differ, I would always prefer to state clearly in the function doc what types of parameter values are allowed. For example, even if you have a really simple little wrapper in javascript:

  function log(x) {console.log(x);}

Without documentation, you have to know what console.log can do for different types. So I'd definitely prefer this:

  /** 
   * Logs x to console.
   * @param x a value of a primitive type (other types are not guaranteed to be logged in a readable manner). 
   */
  function log(x) {console.log(x);}

> A gem will often define its own classes, which you might pass objects of around, (money, phone numbers) these will often be the primary focus of the gem, and how to use these objects will be written right there in the documentation.

Yes exactly, it will be documented as any public API should be. I have no problems using opaque types. But a function call(x) which expects x to be some object representation and not any old string (for which the library has constructors, e.g. PhoneNumber(string)) should surely document this, no?

baltar

10 anni fadiscuss

Simple: no racism, sexism or any other de-humanizing speech based on identity is "clean enough".

baltar

10 anni fadiscuss

"there was always a bulletin board an on a corner of it there was always some faded-from-to-many-xeroxes bit of humor/racism/sports fandom/sexism/dirty joke or other us-vs.-them thing "

This sort of dreck was as despicable then as it is now, off- or online. If people posting such things now leave Twitter, I'm all for it. They can go back to the stone age where they belong - oh wait, even then most people were likely better than that: http://www.deutschlandradiokultur.de/geschlechterrollen-fors... (in German).

baltar

10 anni fadiscuss

I don't see how Ruby saves you from optimising (to my limited knowledge, it's not exactly a fast language), but I agree with you that naming stuff sensibly and extracting functions (which you can then name sensibly) is most important for maintainability and can make "in-code" comments unnecessary in many cases. However I strive to always document what a function does if its not obvious -- though I'd call that "documentation" and not "comment".

Example for obvious: Int add(Int x, Int y) in a typed language. Example for not obvious: add(x, y) in an untyped (or "dynamically typed") language (Does it auto-coerce? How? Can it add complex numbers? In my particular representation? ...).

Someone mentioned that sometimes comments are useful e.g. to document a quirk/bug in library function you call, and I have some examples of that in my own code. But most often you should be able to rectify that by wrapping said function in your own one that omits the problem.

If a function seems impossible to give it a sensible name that isn't ridiculously long, split it up. The more clear code of the individual parts and how they are combined should give a hint of what is actually computed here. Maybe it's a new concept in your business logic, in which case providing a clear and exact definition makes sense anyway (put it into the appropriate place in your documentation). This whole procedure can take a significant amount of time, but it will be worth it in maintainance!