What is that thing? Seven deadly things you should get to know in Ruby

gistfile1.txt

Every object is not a snowflake. They are all made of the same basic stuff:

  Learning Ruby is hard, and can be intimidating. It seems there are an infinite number of rules to learn, and things to learn
  about. Metaphorically, that's true, but a programming language is like any spoken language. There are infinite ways to
  express yourself, but only a finite amount of letters you need to learn in order to speak it. Like letters in a language,
  Ruby has a finite set of Data types that govern it's behavior. Knowing that can help new programmers when looking at
  unfamiliar objects. Here are seven to get you started.

The seven deadly objects

  Strings, Integers, Symbols, Boolean Values, Nil, Arrays, Hashes

  5 to warm up, then 2 to put them in.

Strings and Integers/Numbers

  Break down most objects far enough, and have one of the two
  
Arrays and Hashes:

  They collect things, and hold things. Those things are usually, when broken down far enough, Strings and Numbers.
  They can hold themselves, and eachother. Don't let them confuse you. Focus on what it is they are carrying.
  
Symbols:  :hello

  Kind of like a less changeable/mutable sequence of characters. (research this for use cases)
  
The Boolean twins - True and False:

  Lots of conditions with these two. Used to determine what path to take.
  
Nil, the nothing nemisis: Not an empty string, not zero. It's just nothing.

  It will usually cause you error problems, but knowing what the program says is nil will help you solve them.
  
There are other dangers out there (structs?), but for now, worry about the things that go bump in Module 1.

  Remember these core parts are a good place to start when looking at something unfamiliar, but they are not the only things
  the new thing could be. Start by asking, "is it one of the seven deadly objects?". If not, thank your lucky stars, then find 
  out what the hell it is.

start with strings and numbers separately, then go to syms, nil, 

Enums exercises

Hey. Just saw this. Here's some thoughts. Take what you want, leave what you don't. Say it in your own words if you like, use mine if you like mine.

Symbols have an example of the literal, :hello, (a literal is syntax you can type in a Ruby program that becomes an object when run), but none of the other types do. eg there is no [] for arrays, or {} for hashes.

---

For Symbols, I'd say something like: Strings that can't be changed (fancy people call this "immutable"), and always evaluate to the same location in memory. This makes them good at being optimized, because after calculating a value, they can just remember it for the next time you ask, since it won't ever change! It also means you can check if two symbols are the same by looking at their location, which is much faster than checking character-by-character.

But most people just use them, because they're prettier :P

---

"The Boolean twins" Probably worth mentioning that nil will behave like false in any boolean operation, and any other object than nil and false will behave like true. Might also be worth associating them to the related operations. eg you probably won't ever see an array on either side of &&, you won't ever see each called on true. Even if you don't put that in the article, it would be a good exercise for you to do ^_^

---

Nil: Tecnhically it is something (it is an object), it is just used to represent the idea of nothing, ie "if an object is missing, you will find nil in its place". The warmest coat in an empty closet. The winner of the marathon that got cancelled. The best friend of the hermit. The age of the misanthrope's first love. The meaning of life to the nihilist. The electron's position (or, conversely, its momentum). The temperature colder than absolute zero.

Might also be worth mentioning that an empty collection is not nil. The warmest coat in the empty closet is nil, because there is no coat to choose. But there is still a closet, so the closet is not nil, it is just empty.

ie a collection of nothing is an empty collection. An empty array or an empty hash, for example.

---

Something I've been thinking about lately for figuring out how to use hashes and arrays: if you just need to keep track of a bunch of things, put them in an array. But if you need to keep track of them based on something else, use a hash, and that other thing is the key. Eg when you want to call your friend, you don't sequentially go through all your phone numbers until you locate them, instead you type in their name. So you are mapping your friends name to your friend's contact information... a hash. If I tell you that people have names and ages and addresses, those things are all objects, but we are talking about them based on their names, so the user is a hash, with keys of name, age, address, whose values are a String, an Integer, and probably another hash. The books on my bookshelf are an array, because I think about them as a collection. Even if I order them, I still search through them one at a time until I find the one I want to read. The shirts in my closet are an array. The texts on my phone, I just read them in the order they came in, I don't try to find the one that I received at 8:53 AM on June 7th 2015. But directories on my computer are hashes, because I choose the one I want to go to based on its name, not by iterating through them until I find the one I want, or remembering that my downloads folder is the fifth directory.

---

I'd omit the comment about structs, they're objects like any other one you make. They just seem scarier, because you give a recipe for what you want, and it inflates into an object. But really, if students are comfortable with attr_accessor,
which inflates into then they're already comfortable with this idea.

---

As an aside, and you don't have to talk about this, but I'm noting that we use blocks constantly, and they are a super powerful and mind-expandy way to think, but yet they get so little attention.