30+ fps with 10 creatures on iPhone 5S.

Usually, but it depends on cultural context.

For example, where I'm from (West Ireland), the term "Lads" is often used for everyone regardless of gender. One might hear a lady say she's "Going out with the lads" when describing a night out, with even a mostly female group of companions.

Basically, we should try to not use language which excludes others, but in some cases the person is actually using gender-neutral language from their culture and does not intend to exclude anyone.

It all depends on context. "I'm going to go hang out with the guys." yes, exclusive. "Hey guys, I'm going to work." not exclusive. Try focusing on the meaning being conveyed and not the glyphs representing it.

I don't think the issue is as simple as that. Here is more on the topic: https://subfictional.com/2012/07/02/language-matters-stop-us...

I don't know where this author comes from, but obviously not the Northeast or West coasts of the US where "guys" has been used to refer to mixed gender groups for decades. It's no different that "y'all" which is more popular in other parts of the country. Words and phrases change meaning all the time. The essay fails to understand such a simple concept and is just plain stupid because of it.

The strangest part of that article is this:

  I understand how ingrained the “guys” habit might be for 
  some of you. It was for me. After several months of 
  concerted, conscious effort, I still slip and say it on oc-
  casion.

So even the author herself used the word with completely gender neutral intent, but then she insists that others can't. It's like she's looking for reasons to be offended.

Not really. She is conciously trying not to use it, and admits to accidentally slipping up when she reverts to unconciously choosing biased terms. She seems to want others to do the same thing, and think about the words they are using, and their potential impact, which is a Good Thing generally.

What the author is trying to say is that this label is deeply ingrained into our cultural stereotypes but we should strive try to change the situation.

A lot of people are looking to be offended these days.

That's been true since forever. It's just now that people are offended about things like word choice rather than race, gender, religion, or parents, occupation, etc.

Either way, that's no excuse to stop thinking about things.

Douglas Hofstadter wrote a classic essay on this as well: http://www.cs.virginia.edu/~evans/cs655/readings/purity.html

This one is right up there with A Modest Proposal.

The link leads to a non existent article :|

Fine on Firefox, Linux Mint 17.1.

That was on iOS. Works well in Safari on Mac.

I don't see a reasons for null to exist in a new language in 2015.

How do you model a "zero or one" relationship without null?

Maybe your answer is "with Optional" (or Option, or Maybe). We just choose to use union types and have "Nil | T" (Nil or T) be the same as "Option(T)" in other languages.

Yes, Maybe (Optional) is the way to go. The difference is, with nil you basically make every type optional allowing it to have nil as a value.

Well, in Crystal Nil is a separate type that can be combined with others. But, say, a String is always a String, it doesn't implicitly have the Nil type. Same goes with every other type.

Maybe you are thinking of Java/C#, where reference types can also be null, but this is not true in Crystal. It's also in a way similar (but not quite) to Swift, where optional types are different than types that can't be null.

It's a nice approach, I like it. There is a difference between Option[T] and (T | Nil) that's worth mentioning, however.

Option[T]'s are composable. For example, let's say we have a "get" method to get the value for a given key, whose type looks like:

    get :: String -> (T | Nil)

If we were using Option[T]'s, it would look like:

    get :: String -> Option[T]

So let's say we have a map, and want to lookup a key (syntax is made-up):

    let m: Map[String,(Int | Nil)] = make_some_map()
    let result: (Int | Nil) = m.get("some-key")

If result is nil, was the value of the key nil, or was the key not in the map?

With Option[T]:

    let m: Map[String,Option[Int]] = make_some_map()
    let result: Option[Option[Int]] = m.get("some-key")

Here result will either be None, in which case the key wasn't in the map, or Some(None), which means the value of the key was None.

So there is an observable and potentially useful difference between (T | Nil) and Option[T].

Do you have a technical write-up of how Crystal does that? Or otherwise some links/papers that explain the principle in a language accessible for someone who is basically self-taught and lacks a formal CompSci education?

Sounds exactly like union types in Ceylon (http://ceylon-lang.org/documentation/1.1/spec/html/introduct...), which is an interesting approach.

I find the distinction important as it allows to establish a contract without falling into defensive programming. Null pointer analysis is great, I admit, but how it would help to write a library function without checking explicitly if its parameter is nil?

It's ONE way to go. There are others.

Sum types supported in the language such as in Ceylon is another one.

And yet another one is safe dereferencing operators (?.) such as in Kotlin.

And to be honest, (T | Nil) is pretty difficult to distinguish from (Maybe a = a + 1). Complaints feel difficult to motivate to me anyway.

They both accomplish the same thing: no unexpected null. The exact mechanism was never the interesting part. Maybe being monadic does offer some other benefits but the killer advantage is the responsible handling of nil. Crystal doesn't seem to have a foundation in monadic programming so the type unions seem like a reasonable approach there.

The advantage of the monadic approach is that it's easy to abstract over, because it's just an ordinary type in the language. So e.g. in scala I can call the same "sequence" method on a List[Option[Int]] as I do on a List[Future[Int]] or a List[ErrorMessage \/ Int]].

Unions seem like more of a language-level feature, so I'm not sure you could abstract over them in the same way.

I totally agree. Ridding yourself of nils via the Maybe monad offers incredible abstraction potential, but would feel out of place in Crystal's Rubyishness without deeper thought into bringing other monads into play too.

Nonetheless, I am thrilled that we are seeing more and more languages that don't have implicit nullability on any type.

I re-read my initial comment and can see some ambiguity in my phrasing "Maybe being monadic ...". That wasn't me saying "maybe it is true that being monadic..." but rather "the fact that Maybe is monadic..."

That just depends upon whatever type abstraction capabilities Crystal grows. It probably won't be getting higher-kinded nominal types so generalizing over Monad is sort of dead in the water anyway.

> How do you model a "zero or one" relationship without null?

With something that leaves "Nullpointer analysis" obsolete/useless.

A tiny observation here: we don't do "null pointer analysis". We do this kind of analysis for every type: if you invoke a method on a type and that method doesn't exist, you get a compile error. In the case of a type union, all types must respond to that method. "Nil | T" is just one particular type union, but you can also have "Int32 | String", etc.

To be replaced with an analysis that finds unmatched cases (like None when you assumed Maybe)?

Okay. I'm migrating my Wunderlist lists to plain text now.

Message about DDoS attack could cause another wave of DDoS performed by thousands of users continuously refreshing a website to see if it's up.

GitHub's website loads pretty fine for now. The team is working on the traffic filtering now, the status page said.

Right, just communicate directly with your colleagues when GitHub is down. This is exact workflow Git was designed to work with.

Wondering who is continuously DDoSign GitHub last time...