January 3, 2015 by Daniel P. Clark

“Empiricism Like This”

No two people are the same.  When learning we have many different ways.  There are auditory learners, visual, and hands on.  Whenever you combine any, or all, of these methods the learning experience will become more vivid and better retained knowledge.

In my writings I’ve largely focussed on an exploratory experience.  A more hands on approach to learning.  You learn better by doing.  In my last article I shared things I had learned by experience .  And I, even though I’d learned this some time ago, was very excited to share this.  Mysteries revealed are exciting.  I wanted to express knowledge in such a way that you, and others, would benefit from it and be better for it.

Amongst Reddit users some flocked together to share their professional, experiential, or even personal input.  One common thread was the by-the-book mentality.  Saying the things I wrote about were:

“Kind of a strange, magical way of looking at things” – vsalikhov

‘Learning “when to use colon” is a bad way to learn Ruby. It’s like learning “when to use quotes” without ever learning what a String is.’ – rdpp_boyakasha

“I guess you can make a mental model based on empiricism like this without actually understanding what’s going on, but having the same mental model as the people developing the language is going to work a lot better for you.” – jrochkind

While these may very well be valid points, they lead to a very “fit you into the mold” kind of conformity.  I am all for standards, patterns, and understanding the intent in design from the original language creators.  I love learning each of them.  But I prefer some methods beyond looking at the languages core documentation.  Yes I like to include it, and I recommend it.  But I want to show you why I don’t want to be limited to it.

In a question posted to StackOverflow a relatively new developer asked about “Calling variable name of instance from within class“.  This showed he didn’t understand about the intent in design behind the language.  Which is fine.  One answer was posted as a proof of how this could not be done.  Yet I was intrigued:

Grabbing the variable name of the instantiated object is virtually unheard of. Most would design the Playlist class with an initialize method and assign the name when the playlist is created like Playlist.new(“NameofPlaylist”). Even so I’m intrigued by the question and I’m digging deep into the Ruby core to find if this is possible. Just know that the way you’re asking to have it done isn’t the way it’s designed to be done. – 6ft Dan

This lead me on a “magical” exploration of Ruby to find in what way I may accomplish this.  A not-by-the-book approach.  And you may be glad to hear, I was successful.  There is a hackish way to accomplish what this eager new developer had requested.  I will share the tools in which I accomplished it with.

First ObjectSpace is an awesome tool that can allow you to find every instance of any Object class that has been instantiated.  Second “Binding encapsulates the execution context at some particular place in the code and retains this context for future use”.  And the variable name could be retrieved with the method local_variables if called within the correct scope with binding.  So in experimenting I found the root scope of the application was typically the last Binding instance object returned from ObjectSpace.each_object(Binding).to_a (not so in Rails though).  So from there all I had to do was call local_variables within the scope of that binding and from within the Class match one of those variable instances to the Class instance via self.

So “Yes!” I went outside the book (as it were) and it was an exciting learning experience to do what was ‘impossible’!  If you would like to see the code and explanation on this see my StackOverflow answer.

 “Now let me tell you: If someone told me that something is impossible.  I will go out and do it.” … “You’re going to find the nay sayers everywhere you go” … “Don’t listen to the nay sayers. I mean how many times have you heard that you can’t do this and you can’t do that and that it’s never been done before?  I hear this all the time.  Some of it: I love it when someone says ‘No one has ever done this before.’  Because then when I do it; that means that I’m the first person who has done it.  So pay no attention to the people who say it can’t be done.” – Arnold Schwarzenegger

I do want to say I don’t claim to be an authority in this subject matter.  But I do claim that I love it, enjoy it, and I’m passionate about it.  I just want to share that passion with as many who will receive it.  And I hope that we all may be the better for it.

I don’t object to objections.  I’m glad people have spoken out against what I’d written.  It’s not always easy to take, but it’s necessary to be able to take criticism and learn from it.  You are no less the person you were when criticism is given.  If anything you are now better, and likely the wiser for it.  I’m actually glad people have taken the time to speak in regards to my writing.  It shows that they care about what is being said and they themselves want to shed light on the subject.

I will write things that I have learned.  There will be many times that I will be wrong.  I’m okay with that.  But please don’t leave me in the dark should I be wrong.  Let me know.

Now back to my point.  Is that my methods for learning are exploratory.  As in some of my previous writings I’ve compared myself programming as like unto being a detective with mysteries to solve.  This way of thinking keeps things exciting and I learn far more quickly in this manner.  If you make programming a chore then it becomes tedious, you’ll exhaust yourself with it, and you will learn less in the process.  If you make it your passion then your mind will thrive!

I want to leave one last code example on this point.  I was looking for an answer, not in any book, about a case/when switch scenario.  In the happen-stance that the Object being evaluated should change in memory and it hasn’t been assigned to any reference variable, is there a way to access it?

case "a"
when ->(n){n.next!.equal?("c")}
  puts "c"
when ->(n){n.next!.equal?("b")}
  puts "b"
when ->(n){n.next!.equal?("a")}
  puts "a"
  puts "The state failed to match up."
# => The state failed to match up.

I believe the answer is no.  You cannot find the in-memory value handed to case in this instance since it was not given to a variable in which to reference it.  In the when conditions the stabby procs actually change the object during the evaluation.  The changed object then never matches any of the when conditions and else is called.  I recommend that you DON’T DO THIS in any production code.

This was my way of experimenting with the design of the Ruby core language and testing what was allowed and seeing if the language was designed for just such a scenario.  In my findings this situation isn’t accounted for.  Yes I know this will likely never happen, and it’s too easy to just assign a variable to check such as my_var = “a”; case my_var.  But in my mind I was imagining streaming data of constant change and that in the time it takes for the conditional when to evaluate the “live” data, that it would’ve already changed.  This of course would make the whole case/when use case pointless.  But it’s still intriguing food for thought.

So now you have gleaned both of my learning behavior and how I help fuel my own learning experience.  Feel free to retort if that is in your nature to do so.  I am just glad to be sharing in what I both love and enjoy!  Hope you enjoyed this!  Please comment, share, subscribe to my RSS Feed, and follow me on twitter @6ftdan!

God Bless!
-Daniel P. Clark



Leave a Reply

Your email address will not be published / Required fields are marked *