Does A Bearded Computer Scientist Ever Have To Worry About Job Security?

This one's about Ruby again.

Wanted to talk a bit about exception handling in the language.  It looks/works like something in between Python and Java, but with some cool extra features.  Here's a short little intro:

---

---

In Ruby, the equivalent of Java's explicit throw is the explicit raise.

def intentional_raise
  puts 'This is intentional I swear.'
  raise 'Oh %&*#!'
  puts 'No but seriously I meant to do that.'
end
intentional_raise

Typing all of this into the interactive ruby shell (irb), we get:

This is intentional I swear. 
RuntimeError: Oh %&*#! 
        from (irb):3:in `intentional_raise' 
        from (irb):6 
        from C:/Ruby193/bin/irb:12:in `<main>'

---

---

But say we want recover from the exception in some way, and maybe retrieve some info from it. We can use rescue for this.

def kentucky 
  puts 'Well hi!' 
  raise 'I was raised in Kentucky.'  
rescue Exception => e  
  puts e.message   
end
kentucky

This time we simply get the message from the Exception, rather than having to see all those ugly details:

Well hi!
I was raised in Kentucky.

---

---

As one might hope, you can also catch specific kinds of exceptions. And heck, a single rescue block can catch more than one kind, if you'd like! (Also note that you don't have to do all this stuff inside a function. Cuz that would be stupid.)

begin
  raise NameError, 'Your name is so horrible that I just had to say something.'
  x = 1/0
rescue NameError, ZeroDivisionError
  print 'I either caught myself before I said that rude thing out loud '
  puts  'or saved the world from your negligence in trying to divide by zero.'
  puts
end

begin
  raise SecurityError, 'During the debate festivities, not all parts of the perimeter were guarded.'
rescue SecurityError
  print 'Everything turned out okay at the debate festival, '
  puts  'in spite of potential security issues.'
  puts
end

begin
  raise 'Come at me bro! Do you even lift?!'
rescue    # could also say rescue Exception [or rescue RuntimeError, in this case]
  print 'I don\'t have a plan for dealing with any particular exceptions, '
  print 'and I\'m especially afraid of that aggressive one that speaks in memes, ' 
  puts  'so I\'ll just re-raise anything I run into.'
  puts
  raise 
end

Here, we get (note that this one wasn't run from irb):

I either caught myself before I said that rude thing out loud or saved the world from your negligence in trying to divide by zero.

Everything turned out okay at the debate festival, in spite of potential security issues.

I don't have a plan for dealing with any particular exceptions, and I'm especially afraid of that aggressive one that speaks in memes, so I'll just re-raise anything I run into.

C:/Program Files (x86)/Notepad++/exceptionTest.rb:17:in `<main>': Come at me bro! Do you even lift?! (RuntimeError)

---

---

'Nother Post for Today

This one's more directly related to ch13.

Today in 300 (where we're also talking about threads), Dr. Oldham grumbled something to the effect of "If you're dealing with multiple threads, you're going to be looking at some performance gains."*  And I seem to remember from my course in Ireland that concurrency can result in more efficient execution overall, even on single-processor machines.**  But in what situation would this be the case?  I mean, it's obvious that you're going to get more efficient execution if you have multiple processors and the processes that are being dealt with take advantage of this.  It's similarly obvious that it is desirable to utilize concurrency for a wide variety of purposes to at least simulate multiple things happening at once (user interfaces, graphical video games, etc.).  But how does it make sense that a single processor would be able to complete execution more quickly if it divides its time between multiple tasks?

To use an analogy:  I have three different kinds of bread-loaves and a toaster with a single slot.  I cut the loaves into slices.  Why should it be more efficient to alternate between slices of different types of bread, rather than just proceeding from one loaf to the next in order?  Isn't switching between bread-types just extra overhead?  (In fact, for many situations, this overhead can get out of hand very quickly if a process uses more threads than there are processors on the machine.)

What's an example of a situation where we could see an improvement in performance thanks to multithreading on a single-processor machine?***


*He actually said nothing that even vaguely resembles this sentence, but it sure sounded like this is what he was getting at.

**It is conceivable that I am misremembering this.

***Please note that, as this page mentions, "the design of concurrent applications is a very complex process that is normally performed by people who make a ton of money, because it takes years of study to figure out how exactly a given task can benefit from concurrent execution."  So maybe it's okay if we don't completely understand this just yet. 

For Science

Turns out that distributed computing has provided us with a lovely way to donate computational resources to research for good causes!  Through IBM's World Community Grid and BOINC (Berkeley Open Infrastructure for Network Computing), computer users with Internet access can volunteer their system's unused cycles to help solve massively time-consuming problems.  The work is broken down into little chores, and separate systems handle these little chores simultaneously, meaning that the unfortunately limited funding for the research doesn't have to be used entirely on computational technology.  And the work gets done much faster!  

Find out more at the World Community Grid website and consider participating!

Whoa there

I wanted to respond to Brooks' post from a couple days ago.  Rails has gotten a bad rap since Twitter switched to using Java/Scala.  This article, however contends that it isn't a problem of Ruby scaling poorly, but of the folks at Twitter using Rails incorrectly.  And this guy on stackoverflow also has a great (albeit somewhat old) comment on the stuff.

If you're curious about just how widely used some of these web frameworks are, check out this site.  PHP and ASP.NET dominate the field, of course.  It's interesting to note, though, that Ruby on Rails constitutes a negligible portion of the top million sites, but makes up a rather larger portion of the top 10,000.  (I'm not gonna say Rails was necessarily the key to their success or anything, but...)

One might also find it interesting that Amazon is one example of a site that makes use of Rails.

Paul Graham Is A Delightful Writer

Exhibit A: Revenge of the Nerds.
Exhibit B: Achewood (in no way Paul Graham-related but delightful, nonetheless)

Did anyone else find it interesting that many of the languages Paul Graham mentions in his article seem to be those whose inefficiency is often considered as one of their primary disadvantages (Python, Ruby, Lisp, Smalltalk)?  I assume that this is at least in part due to the fact that these less-used languages can speed up the coding process itself by providing enhanced writability.  But I guess a lot of computing tasks don't really demand the efficiency of C/C++/Java to begin with.

In other news, C++ still scares me.

Substancelessness

Again, not much original thought to contribute here.  It's interesting to see how utterly different Lisp/Scheme/Racket are from anything else we've looked at so far.  Conveniently, it feels a lot more natural than I had anticipated.  Looks like the wider use of recursion is really the most potentially mind-boggling trait of all this functional stuff that the book has presented in this first bit of Ch. 15, at least.

In fact, the Lisp/Scheme/Racket stuff may be coming somewhat more easily precisely because it's so foreign.  We're going in with an open mind, y'know?  Related to this idea, Brooks had a nice observation about the issue of thinking in terms of a certain language when you're coding. I wonder if this very problem might have contributed to making Scala seem so difficult.  After all, so much of the syntax was like Java.  And we were working in Eclipse, for which Java programming is the only frame of reference that many of us have.  Maybe that familiarity was more a drawback than an advantage.

The Blub Paradox

This is a pretty fantastic little article, right here.  It seems that it is now time to determine which language is the most powerful and use it exclusively until something better is created.  Is it still Lisp?  Or is it, perhaps... Ruby?  :O  We should probably figure this out once and for all during tomorrow's class.  

Not a lot to talk about this time.  Just very excited about getting into Lisp and whatnot.  (And to check out everyone's games tomorrow!)