039 RR Programming Language Fundamentals
The Rogues talk about programming language fundamentals.
Show Notes
The Rogues talk about programming language fundamentals.
Transcript
DAVID:
My cold medication is so good, that Chuck just had a brain fart.
CHUCK:
Hey everybody, and welcome to episode 39 of the Ruby Rogues podcast. Before we get started, I wanna mention that we are sponsored by New Relic. You can find them at newrelic.com. and I will also have a little banner up on the website. If you click on that banner, then they'll know that you came through us which helps us out. And I'm also going to put a link up, so that if you go to rubyrogues.com/newrelic, then that will also take you to them, and let them know that we referred you -- which would be nice, because they like to know those things. And with that, we will get into our panel.
This week on our panel, we have David Brady.
DAVID:
Hi, this is David Brady, and I'm wearing Avdi’s gold bikini.
CHUCK:
Woohoo! We also have James Edward Gray.
JAMES:
Hey, everybody.
CHUCK:
And finally, we have Josh Susser.
JOSH:
Ooh, I'm ‘finally’. [Chuckles]
CHUCK:
I guess I'm ‘finally, finally’. I'm Charles Max Wood from teachmetocode.com. And this week, we are going to be talking about Programming Language Fundamentals.
DAVID:
Oh, good lord. So one of you is ‘finally’, the other is ‘finally, finally’. You guys are so glad, you need to be so greatful James and I didn’t throw an exception. [Laughter]
CHUCK:
Is that a Rails error? Double ‘finally’ error?
DAVID:
Yeah, a ‘finally, finally’. Oh you are going to be so great. Just stack the finallys. Finally, Finally, Finally…
CHUCK:
[Chuckles]
JOSH:
Can we edit this part out? [Chuckles]
JAMES:
What?
[Laughter]
JOSH:
Never mind.
DAVID:
Oh, my first joke in the show, and you wanna edit me out. [Laughter]
CHUCK:
Yeah, next time Dave talks, it will just be “Bleeeeeeeeeeep.”
JOSH:
[Chuckles] So, programming language fundamentals. Well, this question started as something like, ‘Can Ruby be the first language that you teach someone?’
JAMES:
Yeah, actually that was a good point. I think it was Avdi that started talking about it, was like, he was working with someone and teaching him to program and he asked about certain languages for teaching to program. And he said that he didn’t think Ruby was a good language for that – which kind of surprised me. And then, I asked him why and his reasoning was the fundamentals were hidden by the incidentals – I believe that he said -- in twitter speak, where he obviously didn’t have a lot of room to elaborate. But I found that interesting.
JOSH:
Yeah, kind of like serious cybernetics corporation. [Laughter]
JOSH:
You know, the rock-solid product development philosophy, was that their fundamental design flaws were completely hidden by their superficial design flaws.
DAVID:
Nice. So this guy’s argument is because Ruby is clean, and makes it easy to provide great abstractions, you shouldn’t teach this. You should take a programmer and throw them in to the obscurity of the weird… side effect crap, so that they can't see… “You know what, kid? Why don’t you learn a real language like PHP!”
JOSH:
So, I think that Avdi has a point. Ruby is a really great language for programming, if you know what you are doing. And we can get into this, but I think Ruby is probably an okay candidate for teaching language as well, if you do it the right way. But Ruby has a lot of stuff in it. It's a real kitchen sink kind of language, and I think that you can get distracted by all the syntactic sugar, and bells and whistles, and cool things. And it's hard to know like what's the good core to focus on when you are learning.
JAMES:
Okay, so I believe as part of the discussion, there were several suggestions thrown out. And I believe Avdi actually favored a kind of C/Lisp approach as an early language. So to speak to what just Josh said there, Lisp would definitely fall in the category of not a lot of kitchen sink kind of stuff. I mean, okay common Lisp has a lot of…
DAVID:
I would refine that and say, ‘Scheme’ rather than Lisp. Because Scheme is a classic FP language. It only got three operators…
JOSH:
Right. I think there are six concepts in the entire Scheme language.
CHUCK:
Right. But the thing is that most people are going to wind up programming in a sort of C syntaxbased language. So is Lisp really the right way to go? I mean, I guess it comes down to your philosophy of whether or not you are teaching them syntax along with the programming concepts, or whether or not your focusing strictly on the concepts and not worry about the syntax.
JOSH:
Yeah, I'm going to obviously put in a word for Smalltalk, but let me do a little back story here. Alan Kay created Smalltalk to be the language that you would program the Dynabook in. And a lot of people look up those stuff on their own. I'm not going to go into it. But then Smalltalk became a big focus of it was teaching children how to program. And they went into schools and they taught children to program using Smalltalk.
And there was this really great interesting thing that happened when they were doing this is silicon valley. And they taught a class of grade schoolers how to program using Smalltalk. And everybody did really well; all the students get really well with it -- except for two of them. And then they take a look at those students to see why they were having such problems. And they talked to their parents and all that. And it turned out that both of them were the children of programmers who worked at Hewlett Packard, and had computers at home, and had previously taught these children how to program using BASIC.
So these kids had a really hard time mapping their concepts of what you could and couldn't do in a programming language into Smalltalk. They built up this mental model of what you could do in a
program, and Smalltalk was really different from BASIC, so they couldn’t map their model over. So that’s a pretty long way of saying that the concepts that you learn in a language are really important. And whether you are learning it in a Lisp type syntax or a Smalltalk type syntax or C type syntax, it's really the concepts that are the important thing -- iteration, recursion, delegation, what have you.
JAMES:
Yeah, I wanna speak to that a little. I have always thought that that's the key. Learning to program, the syntax is the stupid… it doesn’t matter at all part. And that’s exactly the reason why if you are an experienced programmer, after you have a few languages under your belt, you can pick up a new language in no time all. You know what I mean? It's mostly a matter of getting used to the syntax and learning the differences in that language. But especially, like if you are moving from a functional programming language to an object-oriented language or an object-oriented language to an object-oriented programming language, you already know how to think like a computer – which is the horrible part of programming.
CHUCK:
[Chuckles]
JAMES:
That’s why we are so bad, because you have to dumb everything down and you know…
CHUCK:
[In a robot voice] “I don’t know what you are talking about.”
DAVID:
[Chuckles]
JOSH:
Well, there are some languages that have some fundamentally different concepts, like if you look at Haskell or Erlang.
JAMES:
That’s a good point. And AppleScript. [Laughter]
JAMES:
Just had to get that in there, sorry.
CHUCK:
There are even some fundamental things about JavaScript that are different from other languages. And that’s something that I think most of us use on a regular basis in our web development.
JAMES:
That’s an interesting question. JavaScript was brought up during this debate as a good language to learn on. And I believe the reason was due to the accessibility of it. Like that everybody has a web browser, and everybody can just throw together a little page and start writing some JavaScript coding in it.
DAVID:
No, the reason is the speaker was a freaking moron. [Laughter]
DAVID:
Okay, the fundamental flaw in thinking here is Ruby is a bad language to teach, because you can't just give somebody Ruby, and have them learn that one language and have them be a good programmer, right? Okay, give me any language that we can teach you – just that language – and have you be a good programmer. I mean, besides Smalltalk. And there just isn’t one, right? You can start in C, but now I really want you to go learn a high level language like Ruby or Smalltalk. You can start in Smalltalk, now you really want to learn a functional programming language. You can start in Haskell. But now I really want you to learn a stateless concurrent language like Erlang.
And the reality is, you can't take a single language and become a really, really good programmer. And JavaScript is the worst freaking language of them all, out there. Don’t get me started on JavaScript. Oh wait, it's too late.
[Laughter]
There's no way to find out what the limits of the system are. You can't tell if you are about to run out of memory; your script just stops working, because the browser decided that this compiled version of the browser only has a stack level of 400 or only have a stack level of 4,000, or only has so much heap spec. And there's no mechanism in the language to find out how much stack or heap you have available to you. It's a complete, utter piece of crap -- a toy language. And that even includes the ECMAScript 5 specification. It's a piece of crap.
But that said, you should learn it. It's a very interesting language to try and think in. It should be one of the languages you learn, but you shouldn’t start with JavaScript and end with JavaScript, and think you are a programmer. You should start with Ruby and end with Ruby, and think you are a programmer. Shouldn’t start with C or C++ or Haskell, or Erlang and end with one language and think you're a programmer. And there’s a lot of people out there who do, do this, and a lot of them are either C or PHP programmers, and they’ve only learned one language and they’ve learned all the ins and outs and all of the wacky side effects of it. And they think they are programmers.
JOSH:
Good rant, man. So I'll build on that a little. I know a number of programmers, they are professional web developers, and the only three programming languages that they know really anything about are Ruby, JavaScript and Shell.
CHUCK:
Shell, being BASH or Z Shell or whatever?
JOSH:
Yeah, that counts as a language and they can do some stuff in that. But it just flabbergasts me that if you ask them a question like, “What's the difference between a linked list and an array?” …fundamental structures, their eyes just goes over and they have no idea what you are talking about.
CHUCK:
Right.
JAMES:
Yeah, that’s the advantage of seeing all the different languages, right? It's that you get to see for example, Ruby doesn’t even have a length list in the standard or core library, right? Now it's trivial to build one, it's like one line with the struct if you want. Obviously you wanna put some nice… on it eventually, but it doesn’t have one. But it doesn’t go to a language like Lisp, where everything is a linked list, right? And so you would spend all the time learning that.
So I think David is kind of right, in that, the exposure matters, you know? How are you going to understand actor models if you’ve never spent any time in Erlang or some language like that, you know? Whereas if you spend time in Ruby, and you try to do concurrency in Ruby, that’s probably a good way to learn about fork, because you know, Ruby really bases its concurrency around fork until we get the newer VMs and finally have some of the needed threading capabilities and the ability to not use a global interpreter. But that’s very recent, so.
CHUCK:
And so I think just to kind of pull everything together, what we're talking about here is some languages really excel in some areas and not others. But I think that’s just kind of a general thing. And the other point that seems to be coming up is that a lot of it depends on the problem you are trying to teach them to solve. And so if it's web development, then you are going to pick a language that does well with that. And if you are trying to teach them to solve like sys admin types of problems, then you are going to pick a language that excels in that way.
The thing that I think is really interesting… there are two points that comes to mind. One is so you would pick the language that kind of gives you the maximum exposure to the concepts that you think are important. And so you can make an argument then for Ruby or Java or C or Lisp or Smalltalk or whatever, depending on what you are trying to teach these programmers to understand.
The other point is that… my brain just totally blanked.
DAVID:
[Chuckles]
CHUCK:
[Chuckles] Sorry.
JOSH:
You know, memory segmentation falters sometimes?
CHUCK:
Yes, exactly.
JAMES:
That was hilarious. It was such a good roll too.
CHUCK:
I know. I was on a roll.
JAMES:
[Chuckles]
DAVID:
My cold medication was so good, that Chuck just had a brain fart.
CHUCK:
Yeah, a couple of miles away.
JOSH:
[Chuckles]
CHUCK:
Whoa, Dave.
DAVID:
[Chuckles]
JAMES:
I think what you were saying is fairly accurate though, Chuck. Like for example, you know, can you fork processes, redirect outputs, all that using Ruby? Yes, of course you can. You know, set environment variables and stuff like that. However, do the same thing in BASH, and it's easy because BASH is built around doing that kind of stuff. That’s what it does.
CHUCK:
So my other point is the thing that I forgot that I now remember, is that basically, you can teach people these constructs; you can teach them the concepts, you can teach them the language, you can teach them the syntax, you can teach them all of these things, but ultimately, the thing that makes them a good developer is experience.
And I've been reading Outliers. I don’t know if you guys have read it. That's by Malcom Gladwell. Fascinating book. Anyway, I just read the chapter about 10,000 hour rule, and it ties in a lot with what Andy hunt – in Pragmatic Thinking and Learning – where the experts are the ones with the experience and kind of instinctually know what to do and what to use.
And I don’t know if you can really teach that. I mean, you can definitely guide people into learning those things, and give them problems that force them to solve those sorts of things and find the right solutions, but I'm not sure how you teach people or get them to that point where they are a ‘good developer’, simply because you can't give them that kind of experience by having them read the book or spend a few hours thinking around with whatever language you are dealing with.
JOSH:
Yeah, that sounds about right. So back to one of my opening statements about you could use Ruby as a good first language. I think that’s probably true, because Smalltalk is essentially a subset of Ruby, right? [Chuckles] And it's been shown that you can use Smalltalk as a good teaching language.
CHUCK:
Yeah, let’s just get that out of the way right now. Smalltalk is Ruby dialect.
JOSH:
[Chuckles] Well, Ruby is essentially a superset of Smalltalk. It's Smalltalk plus some Lisp, plus some Perl.
DAVID:
So is Ruby a [unintelligible] of Smalltalk?
JOSH:
Yeah, I think so. I've been really happy using Ruby. Most of the programming style that I've developed working in Smalltalk works really well in Ruby. And in fact, that was like the thing that kicked off my tweet storm yesterday. I tweeted something about hating everything about JavaScript and CoffeeScript and Backbone, and suddenly, there were 100 replies and… [Chuckles] But I was doing some work browser coding and I was looking at the code, and it was just this whole mishmash of crap. You call a function that returns to you a function, that you call that returns to you another function that actually does the thing you wanna do. And it's like, this is not object-oriented programming; this is functional programming.
And I probably just need to sit down and write a good rant to my blog about how having language systems that have multiple design centers is not a good way to go. And that’s one of the problems with programming in JavaScript and even Ruby is that, there's no strong guidance to say, “Okay, you have to be an object-oriented language. You have to use object-oriented design center as your primary focus. ”And it's too easy to go off and do functional things. And there's really nothing wrong with functional programming, except that it's not as good as object-oriented programming.
[Laughter]
Besides that, if you wanna do functional programming, have at it. More power to you.
DAVID:
Hang on, I'm typing something in to Twitter. [Laughter]
JOSH:
But don’t try and mix the styles because it's just going to get you in trouble. You won’t know how to understand the logic of your program structure. So, but said, Ruby has everything you need in it to teach someone object-oriented programing or probably functional programming if you wanted to go that way, but it's probably not the best choice for that. Yeah, it’s like don’t start up teaching people Ruby by telling them about all the weird edge cases and bizarre features and things like that. You start with the core of objects and messages, and variables and classes and inheritance. You can focus on those things just fine.
JAMES:
So I actually found that a little surprising when you tweeted it yesterday, Josh, that like why would you start with an object-oriented language and not teach objects in like the first lesson. And I think like I actually agree with that, like the messages and stuff like that. Did you mean creating objects though? Because I don’t do that when I teach the first lesson.
JOSH:
Yeah, I didn’t mean that how to define classes and things like that.
JAMES:
Okay.
JOSH:
I just said like what is the fundamental execution model of the language… [Chuckles]
JAMES:
Right.
JOSH:
And I have a friend who’s learning Ruby right now. He's learning to program. He's in a Ruby programming class, and I looked at his syllabus and they didn’t get to like objects and classes until like the third or fourth lesson of the course. And I said, “You know, I'm going to tell you what objects are.” [Chuckles] And we spent about 15 minutes having conversation about having objects and messages and classes, and inheritance – I didn’t get into polymorphism. Let’s just talk about the basics of object has identity state and behavior, and had a conversation about that. He totally got it. He showed that he understood what it meant. And that seems like a really fine way to start when you are teaching a language.
DAVID:
Yeah, I think a lot of the detractors of Ruby as a learning language is that there is so much weeds to get off into the… yeah, it's a fine OO language to teach somebody. You can demonstrate. It blows people’s minds -- specially if they have seen a little programming anywhere else – that you can call 3.to_string. You can call a method on an integer? What? It's all objects baby, except for the things that aren’t. And that’s the problem, right? Except for the things that aren’t. In Ruby, constants aren’t variables… right? That whole thing. But if you treat the language as let’s just stay on kind of the beginner’s version of Ruby. Let’s just keep the landing gear down, keep the training wheels on, can we teach well with this language? And I think the answer is a resoundingly “Yes.”
This is going to be a really bad comparison, but I wanna point out this is what the language is designed for. It's as easy to teach as Visual Basic. And I know a lot of people hate that language, but VB was meant to be a programing language to teach non-programmers to program. It was to teach guys with MBAs, that didn’t know how to program, how to write their own gorgeous UIs, which crappy spaghetti code behind them. And the language really, really exceled at doing that. And Ruby is even easier than Visual Basic at teaching people how to write simple beginner’s programming language.
JOSH:
That’s interesting. Do you know what’s the first programming language most people learn is?
DAVID:
My guess would be BASIC.
JOSH:
Excel.
JAMES:
Ooh! Very nice.
JOSH:
It's a language where the control structures are geometric.
JAMES:
Right. You can see the list, you can see the arrays. You can…
JOSH:
Right, the data structures and the control structures are all based on the geometry of things, and that’s something people are good at understanding. And but yeah, if you look at the number of people who write formulas in excel and build excel spreadsheets, there's probably far more of them than there are professional programmers.
JAMES:
Right, and it comes out, I think I've mentioned before I'm taking a marketing class right now. We were actually talking about a bit ago about excel being… if you wanna see somewhere where an app is needed, look for a problem people are solving with excel. Because, It's a coping mechanism, right?
CHUCK:
Yeah, I actually have a client approach me that basically said, “Yeah, we have all of our patient data over in this database over here and everything else is in excel spreadsheet, and that's what they wanted to solve was exactly that.” Because otherwise, they have to pass the spreadsheets around and worry about which version is the latest and all that stuff. So, that makes sense.
Yeah, one other thing that I like about Ruby 4, it's teach ability is just that the syntax is very forgiving, so you don’t have to focus on it as much. If somebody puts parenthesis in or what have you, it doesn’t hurt things. So you know, you don’t have to worry about, “Make sure you have all your semi colons in, and make sure it compiles, and make sure it this and that.” You know, you just write it up and run it and whether or not you got it right.
JOSH:
Oh, it's so much better than teaching someone Java. In Java, you have so much ceremony, and you have to do so much stuff to make the compiler happy, that doesn’t really add to the value of your program. It's not expressive. It doesn’t help you. So yeah, Java is a horrible choice for teaching but yet that’s what most colleges have been using.
CHUCK:
Yeah, that’s what I've learned in college.
DAVID:
I was about to disagree with you both and say that there is something good, something nicely didactic about the fact that you have to have the open paren, close paren, semicolon that you have to have that, or your program doesn’t work. And I literally flipped in the middle of hearing you guys describe this. And the reason why is because on the one hand, it's really nice that if you forget a parenthesis, your program is not going to work. And that it's nice, it's succinct, it's got to work this way, or it's not going to work. This actually a false idol, because there's absolutely no rule that says you get all your parenthesis and semicolons in the right place, your program will actually work. And I've met a lot of programmers think that that’s true.
JOSH:
[Chuckles]
CHUCK:
Well yeah, it's totally a place where they go for comfort is that, “I have it all defined inside these curly braces.” And you know, really, that doesn’t particularly matter when it comes to doing good programming.
DAVID:
Just in case I haven’t drawn enough hate mail for the people out there, this applies all the way up to static analysis. It's of the devil.
JAMES:
So I had a couple of things that I thought about when we were talking about this topic. One, here’s a fun question for the room. What programming language did you learn on? I've actually been figure that out for myself.
CHUCK:
That's a good question.
JOSH:
The first programming language that I learned was synthetic programing on a TI58-C calculator.
JAMES:
Gotcha. One of my early knee-jerk reactions was that I learned to program on my TI-85, I think. But actually, as I kept digging deeper, I decided that wasn’t where I learned to program.
JOSH:
I took a BASIC programming class in school around that time, so I don’t know exactly which language I learned first. The calculator is much more interesting than the basic language, but I learned basic in high school as well.
CHUCK:
I kind of did both. When I was in eighth grade, I saved up and bought a TI-85 calculator, and I
programed on that quite a bit. But at the same time, I was also in this… it was kind of this elite math club. I don’t know how to explain it, but it was actually you can take. We prepared for like the math counts and state math contests and all that stuff.
DAVID:
You get stuffed in lockers by a nicer quality of jock? [Laughter]
CHUCK:
Not quite. [Chuckles] But anyway, as part of this club, we actually started programing in Pascal. So I did a little bit of both. And in elementary school, we did a little Turtle Logo…
JAMES:
That is what I was going to say I learned with – with Logo.
CHUCK:
So it's kind of a mix of those. And then when I was in high school, I took an electronics class, and I took it all three years of high school or the last three years of high school. Anyway, so while I was in there, we got to the point where we were actually building more complex circuits, and the final chapters of the advanced electronics class was actually they gave us an 8085, and we would actually input the bits for the command for the chip, and then it would store it in a buffer. So we were actually programing basically in binary against this 8085 chip to get the outputs that we wanted.
JOSH:
That’s great. Absolutely the lowest level crap that I've done was when I was doing Smalltalk virtual machine development. This is at Xerox, and Xerox had this really cool way of building computers, so that they could do language research, where they had writable control store, so you can program the microcode.. you can program in microcode and create the machine language instruction set. And that was Lisp was written in on these Xerox machines, and that’s with Smalltalk was written in and there was actually a language called Mason, which was a lot like Ada, that was also implemented that way.
So basically you say, “Okay, we are going to define a virtual machine and then we are going to implement all of the opcodes, all of the bytecodes for this language as machine level instructions that we've built in microcode.” And microcode is kind of ridiculous to program in. You really have to think like a computer and you are have these incredibly wide instructions, and the section of it says, “What to do with the ALU.” And another one says, “What to do with the memory controller.”
And you can get yourself in trouble by creating instructions that can take longer to settle than the cycle time of the processor, and you have to know not to do that kind of stuff. It's just completely bizarre programing in microcode. But doing that for a year was a really incredible experience because everything after that was high level for me. [Chuckles]
CHUCK:
Yeah, I have to say when I was in college, I was a Computer Engineering major, which is much kin into electrical engineering than it is Computer Science. And yeah, so one of our projects was we designed a chip and then we actually got a chip that was similar in design into what our assignment had been, and we started writing operating system level things. So we had to write the interrupt code for the chip in the class and we had to do all that in assembly, basically using all of those stuff.
So I mean yeah, you get in to that level of detail. I mean, you have no debugger. Your debugger is, “Oh crap, it didn’t work. Let’s go scour the code.” If you are lucky, you are working on a virtual chip, so maybe you can like kind of freeze it and step through it, but we didn’t have that luxury. So I mean, really it's a different level of programming. And then we did a lot of C, I mean, everything else that we did in that class was C, and the computer science class were all Java and C++. So you kind of get the full range there, but yeah, it's really interesting where it can take you. It's the challenges, the problems that come up that yeah, you would never get that in Ruby or Java. And so, are those languages worthless? No. it really just comes down to what you need to know.
JOSH:
So one of the things that people don’t have to think about when they are programing in Ruby or JavaScript, is memory allocation and de-allocation. Memory management is not a thing that you worry up about at all.
JAMES:
Uh-oh, we are going to get in a fight here.
JOSH:
No, we're not.
DAVID:
[Chuckles] Yes you are.
JOSH:
You are going to agree with me, James. Programming in C or Assembly or Pascal or whatever, where you have to explicitly allocate and free memory on your own, and understand the implications of allocating a bunch of memory, and the overhead of just dealing with all that is really important experience. And it's great… it's like in the karate kid, where he has to do the wax on, wax off. And you know, you are never waxing a car when you are fighting, but for him, it built up muscles that he could use when he was fighting. So it think it's the same thing. You learn a language like C, and you learn some of the underlying stuff that programs do, that’s an abstracted way when you get to Ruby, I think that's really valuable knowledge. And when you are running around in Ruby, and allocating a gazillion new strings because you have some weird little DSL parsing thing, is completely non-optimal for memory management, that can have a big impact on your program.
CHUCK:
So what you are saying is that having an understanding of how the heap works and how it's managed at a lower level when you get to the higher level languages can really help you understand, “Okay, when I'm allocating all of these, I need to clean up my references, so that they'll go away.”
JOSH:
That and a number of other things. So James, do you agree with me?
JAMES:
Yes, I think in general I do. Although I wanna say yesterday, when I heard Avdi say that, “The fundamentals are hidden by the incidentals,” is the reason he wouldn’t teach Ruby. I thought that was ironic, because the reason I would consider Ruby a good learning language is – and I'll probably get hate mail for this – but I would rather teach memory management in Ruby, than I would in C. Like I've done it; I've thought someone how memory allocation works and things like that, using Ruby as a language. It's not impossible.
You know for example, even if you just write a stupid simple loop in Ruby that does way too much allocates way to many objects, kicks in garbage collection all the time, and the program will just slow down and run like.... And you can do that no problem, and then you can look at it in top and watch the memory, see when garbage collection kicks in, especially when you are like printing output, because the world pauses, and the number goes back down. And then you can walk them through the steps of what’s being done there.
And while you don’t see the malloc/free, you will see that, “Look, here we made a new object, made a new object, made a new object.” You can use… object space I think has ways to print out the object counts so you can print those out, watch those numbers, climb, and climb, and then all of the sudden, the world stops while garbage collection tries to get ahead. And this is why people think Ruby leaks memory, right? Because what do we all do? We have closures everywhere because those are blocks, they capture the surrounding state. You don’t clean that block up, so basically, that memory is tracked forever and things like that. So I agree that that’s all happening in Ruby, and you need to have some level of awareness of it. And a lot of us get better awareness foreign language like C, which is explicitly forcing you to malloc/free, you know?
CHUCK:
You know what’s going to happen now, Avdi is going to listen to this podcast and his next book is going to be Memory Management in Ruby.
JAMES:
[Chuckles]
DAVID:
No, this is the first episode that generates hate mail from one of Ruby Rogues. [Laughter]
DAVID:
It says, “Screw you, guys.”
CHUCK:
Or Steve Klabnik. He always has an opinion about us, right?
DAVID:
Yeah, I'm excited because he's coming to Mountain West Ruby Conf. I'm so excited.
CHUCK:
[Chuckles]
DAVID:
What it comes down to I think is that in a low level language, you have to take care of all these incidentals or they will bite your hands clean off. So you learn very quickly to keep your hands inside the car, right? And on a big language like Ruby, that’s very polite and very friendly and very caretaker, it cuddles you quite a bit. Languages like that, that I don’t see this as a defect. I see this as a total feature – especially for learning – is that you can sit somebody down and say, “Let’s just tell the computer to do what we want.”
If you read the Smalltalk manual, they actually say, “Don’t worry your pretty little head about what the objects are doing right now. It's magic. Just let yourself believe in the magic. We'll figure out the fundamentals later.” And I think you should do that with Ruby. And once you’ve got this down, this real idea that it's magic, you just tell the computer to do what you want, then maybe your second language should be C. Let’s pull you down, almost in the hardware level, and then… there is no garbage collector, right? Let the memory manager eat your lunch. Let all these stuff attack you and just totally you’re your trash, so that you then realize that, “Wait, nothing has changed. I still have to tell the computer to do something and it does it.”
It just happens to be there's a whole lot more control, but there's also… what the system does for you, the system also does to you. And if you can take Ruby and get that mindset of, “I'm a programmer. I tell the machine what to do.” You go down to C, and instead of this mentality that a
lot of us have, that when we're in C, “Oh, I'm the programmer. I'm beset by all the things I must do.” No, no, no, no, no, you are the programmer; you get to tell the computer what to do. Just remember that you are now in control of everything, and you now have to take over the control of the autonomic nervous system. You stop telling the computer to breathe, it will die.
CHUCK:
[Chuckles]
JOSH:
It's the difference between driving your car, and overhauling the engine.
JAMES:
Yeah. I agree with it. Like I learned C, but it definitely wasn’t my first, second, even third. I was going to say Logo was my first. And actually debated that one with myself for quite a while. Like, does it count? But I decided that it did because it taught me how to do things like loop or conditionally do something and that is the heart of programming, right? And so I decided that it did count.
And then after that, I've moved on to [unintelligible]. Yeah, I was like one of the three people that had one of those. But it came with like thousand page BASIC manual, and I thought myself BASIC from that. And then after that, it was a lot of programming on TI-85 and I think later, TI-89. And I think they call that language at some variant of Pascal. It was actually closer to BASIC, in my opinion.
And then, I did take a Pascal class in high school, so I learned some of that. And you know, I
picked up C, but it's way down the road. It's not the first thing that I played with. C still pretty bad when I do have to actually sit down and write something, because I don’t spend enough time doing it. I've never gotten very good at it. So I like was David says that you should stop there at some point. It should be on the path that you visit. But I don’t think you should start there.
JOSH:
Right. Okay, so that's great. I agree with you there. What about like odd little languages like Forth?
JAMES:
That’s a great question. I actually have a pretty good opinion on that. Like, you know the pragmatic programmers tell you, “Learn one language every year.”
JOSH:
Yeah.
JAMES:
I love that practice; learning new things each year. Right now, my practice language this year is Emacs Lisp. Don’t ask me how that’s…
DAVID:
Woo!
[Laughter]
JOSH:
It's messing up your use of parenthesis in Ruby.
JAMES:
Right. Now Josh complains about my tweets, because they have too many parenthesis in them. [Laughter]
CHUCK:
def method ((( parameters ))))…
JAMES:
That’s right.
JOSH:
So Forth…
JAMES:
Yeah, I watched people doing this learn language a year thing. And it's interesting; watch them because they tweet about it. It's like, “Oh, now I'm learning Ruby. Now I'm learning Scala. And now, I'm learning Clojure.” And it's like, yeah, they are really just bouncing from fad language to fad language. And like, once you’ve learned a broad object-oriented language well, like Smalltalk or whatever, you are not going to get that much out of learning another one. And so my advice is, yeah, you should learn a new language. I actually agree with that. But, make some of them bizarre or complimentary, you know? So like Forth is a great example because I would classify it as bizarre. But things like…
DAVID:
Prolog
JAMES:
Prolog, right. For sit down and read then really learn regular expressions. I mean like, all the way; to the forward and backward and things like that. The strange, unusual languages; I think you get more out of that, because you learn unusual way to look at things, which is the whole point.
CHUCK:
I definitely agree. And I think more than just that you think is odd, but pick something that really kind of forces you into something that you could do better. So for example, my understanding is that Erlang or Haskell or one of them is really focused on concurrent programing. And so if you don’t know that well, and you need to learn it, then by all means, pick that language or pick some of these other languages that force you like Smalltalk if you think you need to improve on objectoriented programming. My understanding is that that’s a great way to do it. So it's not just picking those weirdoes that are out there, but actually picking the programming languages that force you into the areas that you want to improve on.
DAVID:
I wanna point out that Forth, I don’t consider that an odd language at all. Forth is basically Lisp without the parenthesis. If you sit down and try to figure out how to write… like everybody who seen Lisp will say, “Oh, it's a good idea. I wish I could give it a parenthesis.” That Forth. You just flip the operators around, so that they come at the end, and you now have… it's an RPN language, so if you spend a lot of time goofing around in your calculator -- especially with an HP calculator -programming for those, Forth makes perfect sense.
JOSH:
David, your orientation as a programmer is confusing, your orientation as someone who writes in code. [Chuckles]
DAVID:
[Chuckles]
JOSH:
Yes, everything is Turing equivalent, and Lisp at its heart is a stack machine. But nobody really thinks of it that way. It's same thing in Smalltalk. Smalltalk is a stack machine. If you look at the byte code instruction in Smalltalk push this, pop that. But you don’t use the language that way. Forth is like the ultimate stack machine language. And it's the best thing in the world to learn, if you really wanna master low-level abstractions, and you want a simple system that just lets you focus on one or two things.
DAVID:
So Forth actually has a couple of really key distinct advantages. The first of which is the really cool bumper sticker that says, “Honk Forth, love if then.” The second really cool advantage is that it is a language for which it is incredibly easy to write a compiler. And so, a lot of small, embedded machines, the first compiler that comes into a distance with these machines is a Forth compiler.
And the only Forth program you write is the C compiler.
JOSH:
[Chuckles]
DAVID:
And then you are done, right?
JOSH:
Yeah, you can do a Forth compiler in one page of Forth.
DAVID:
Yeah. And you can also do it in three pages of assembly language. You can take microcode. If you’ve got a machine that manages a stack and hardware, you can write a Forth compiler in yeah, 300 opcodes, 500 opcodes. It's a very tiny, tiny language. It's very easy to compile. It's hard to write, but very easy to compile that language.
CHUCK:
Alright, cool.
DAVID:
Before we get to the picks, I need to pre-emptively cut off some hate mail. I don’t think static analysis is a bad idea; I think it's an absolutely a brilliant idea. I think every way you can check your code is a brilliant idea. I just think believing static analysis is the end-all be-all, and that is what we are seeing come out a lot of these Java schools and programming as a trade technology school is that, if your program passes it's static analysis, it must therefore be perfect. That's what I wanna say with that. I just wanna cut off the hate mail before it starts.
CHUCK:
[Chuckles] Alright. Let’s do the picks. Josh, you wanna go first?
JOSH:
Last week, when I was trying to get a… you made me last, and this week, when I have nothing to say, you pick me first. [Chuckles]
CHUCK:
You are welcome.
JOSH:
You are a master at your craft. I actually do have a pick. And that’s the RubyMine IDE. I spent years working in Smalltalk that had this amazing IDE. And for those who live under a rock, IDE is Integrated Development Environment. And that was one of the big selling points of Smalltalk was that you are not stuck in just a text editor; you have an environment that really understands your program and can help you navigate it, and can help you make decisions about how you structure it. So the Smalltalk IDE, totally awesome.
For some reason, Ruby has not evolved a good set of development tools. There's a great IDE or at least… it's a very challenging language for building those things. And I think personally, the dynamic nature of Ruby makes it incredibly difficult to build these things, and static analysis falls over pretty quickly. And you don’t have the Smalltalk image which holds the entire compiled programming in memory at once, so you don’t have to help you out. But that said, there's a lot that you can do just being clever.
And I was pretty resistant using RubyMine for a couple of years, mainly because when I first tried using a couple of years ago, the experience of just editing text, and manipulating the characters in the program was pretty clunky compared to Textmate. And it wasn’t a very good citizen on the Macintosh. Those problems have been solved now. It's actually a pretty decent text editor, and the Mac integration is acceptable.
And I've actually been really enjoying using the IDE features. You see a message, a method name, in a method and you can click on it and just navigate to the place in your code where that’s defined. So I've been enjoying it. The multilingual integration is really great. You can do both Ruby and JavaScript. And it even has support for CoffeeScript and Sass and Scss and HAML. So it's been a pretty good and useful productivity tool for me in programming.
JAMES:
I'm just curious, what did you use before that, Josh?
JOSH:
Textmate. And Textmate actually is not bad at all, and if you're pretty good with using regular expressions in searching, it's almost as fast to find things in Textmate as it is clicking on something in RubyMine -- but it requires a little more thinking to do.
DAVID:
I have James’s Textmate book, and I use it… I don’t wanna hurt your feelings, James. The whole book is great. I like the whole book. I find it really, really useful but I have it bookmarked to the page that talks about command def option command shift G for the find in file, replace in file, the find replace in Textmate, the keys are not optimal. And I guess the Textmate book is good and you can read through it and you can go back and use it as a reference, but for me, the reference is that one page. How the hell do I find and replace in Textmate from the keyboard.
CHUCK:
[Chuckles]
JAMES:
That's hilarious.
CHUCK:
Yeah, they should build in Vim key bindings that will solve all your problems, right Dave?
DAVID:
No. [Chuckles] Although I've almost got Emacs running in a full blown VM with a GUI, so I should be able to run Textmate inside Emacs and I'll be okay.
JOSH:
Okay guys, I didn’t wanna accidentally start the editor wars episode. [Laughter]
DAVID:
Yeah, the only sentence that if you remove ‘accidentally’, then the sentence becomes true. I did wanna do that. [Laughter]
JOSH:
Yeah, we'll do ‘Vim versus Emacs’ next episode.
JAMES:
Yes!
CHUCK:
We really should. And I think we should open it up to things like Textmate and IDEs, just so that we can talk about… because I think we've all used a lot of the different options out there and it would be fun to talk about.
JOSH:
[Chuckles]
DAVID:
I really think we should totally do an Editor Wars episode.
CHUCK:
Okay. I'll bring Gary Bernhardt. He'll be on my team.
[Laughter]
DAVID:
Actually, I'm going to be on the same team as Gary Bernhardt, which is that both of us have used both, and are proficient at both. And we have one that we prefer over the other, but we actually… I was actually surprised about this. But Gary bernhardt, he's got, if you go to Destroy all Software, he's got an Emacs tutorial. And he basically says, “Here's all the things that Emacs does that I love, that Vim doesn’t do.”
CHUCK:
Yeah, yeah, I claimed him first.
DAVID:
[Chuckles] Fine. Then you have to be on our team.
CHUCK:
Alright, James, what are your picks?
JAMES:
Okay, I've got a couple of picks this time. First I was surprised to see, I was looking back through our picks to see if sort of been nominated or not and it hadn’t been. So I'm going to nominate PuzzleNode. It's a programming problem site and I've been using it teaching some Ruby lately. So I've been using it as just like sample problems. It does have a couple of minuses, which the first minus the problem difficulty range is massive to problems I can solve in literally 15 minutes, to problems that took me a very long time. So there's a very large range, and you just can't really tell looking at the problem.
DAVID:
Question number 3/20 is prove that p = np.
JAMES:
Right. [Chuckles] So you have to be really careful there, because you can definitely bite off some big ones there. But you know, usually just by reading them, you can kind of tell roughly what the difficult level is.
CHUCK:
Isn’t that the one that was put up by Ruby Mendicant University?
JAMES:
Yeah, it is. It's by Greg and Gregory Brown and the guys that work on Ruby Mendicant University. And they use it as like entry exams I think for the university, so working these problems is kind of one of the barriers that I get in. the other thing about it is when you submit your solution, all you can is thumbs up, thumbs own, basically. So if you are wrong, you don’t know why you are wrong -which can be a little rough as far as figuring it out. But I have found that that kind of pushed me to some creative solutions.
Like in once case where I was wrong and I couldn’t tell why, so I actually added a piece to it that would make it easy for me to visually verify. And obviously, the whole bunch of example, but I just kind of went through and started really visually verifying , until I found a problem, you know? And I found that actually pushed me to be surprisingly creative. So it didn’t turn out to be as bigger minus as I thought. But anyway, the problems aren’t good. They give you inputs and outputs and they are usually pretty well described and stuff like that. So if you are the kind of person like me that enjoys working programming problems, or you are just trying to improve your Ruby or something like that, I recommend working the puzzle nodes problems – they are pretty good.
My other recommendation, which is not code related. Judging by the feedback I've received in twitter, my most popular pick ever was when I picked Zoë Keating for her cello music. And I have a new quasi Zoë Keating pick. Some people pointed out that radio lab had an episode on Zoë Keating, which is true. That’s how I found out about her as well. And then I'm continuing to work on radio lab episodes, and one of their later episodes is about this event, where they remixed… they did a big challenge for remixing the classical song in Terry Riley’s in C. And it's really great. They had I think it was like 17 or something like that. There's a lot of remixes for this one classical song.
And they are very all over the place; you'll be surprised in kind of techno sounding stuff, some kind of nature sounding stuff. Anyways, it's all on a CD. And Zoë Keating does one of the remixes on that CD and not surprisingly, it's one of my favorites. But there's also some other good ones on there. There’s like two maybe, that I don’t enjoy, but I did enjoy many of them. And it's a pretty cool CD, again kind of programming music kind of stuff, so I'm going to go ahead and recommend that as well, since everybody likes Zoë Keating pick. Those are my picks.
CHUCK:
Cool. David, what are your picks?
DAVID:
Alright, so I'm going to deviate from a long history of staggeringly useful picks, and absolutely practical, pragmatic things. And I'm actually going to recommend today, my pick is Star Wars uncut. This is a website where they have basically taken the entire Star Wars Episode iv, the good one, the very first one, they cut it up into 15 second segments, and then crowd sourced a fan remake.
So basically, you go to the website, you find any 15 minute segment of the movie that you like and you remake it however you want. And people have come in, and they’ve done anything from graphics done on like a TI99… Oh, I never got to pick what I learned on first, and it was BASIC on a TI-994A. But anyway, the graphics like pixelated, 40 character column graphics. It's like VGA resolution. They are not even VGA – CGA resolution graphics, all the way up to live action, people running around with a kid in a trash can for R2D2, and a tall guy wrapped in gold tinfoil. And it looks like tinfoil. I mean, it looks awful.
And what they did is they got enough submissions, that they basically said, “That 15 second segment is brilliant. Let’s take all the brilliant ones and string them together.” And so starwarsuncut.com, they have released the full 2 hour Start Wars movie – or however long the feature length is – made up of these 15 seconds… the best of 15 second segments.
To say that the movie is a little disjointed is an understatement. As you go from one 15 segment by person, to the next, to the next. And literally, you go from horrible ‘could have done it on my calculator’ level graphics, to live action, back to crappy CGI, over to Legos in stop motion, over to clay dolls in stop motion. It's absolutely the most horrifying thing that you have to go see. It's absolutely brilliant.
JOSH:
It's a work of… it's a staggering achievement.
DAVID:
Yes.
JOSH:
[Chuckles] I've only watched like the first 15 minutes of it, but it's pretty amazing. My favorite bit is like the tall, like pudgy guy with a beard, dressed up as Princess Leah.
[Laughter]
DAVID:
Yeah, it is the most beautiful train wreck. [Laughter]
JAMES:
It scared me how this is sounding cool to me. [Laughter]
DAVID:
That is the right reaction. The is the correct mindset. Ambivalence, ambivalence.
CHUCK:
Yeah, go watch it now before the motion picture association goes and takes it down.
DAVID:
Yeah, my review of this Star Wars uncut is, “I'm so excited, I'm so afraid.” [Laughter]
DAVID:
That's my pick.
JOSH:
I was wondering if they have a download link for it.
DAVID:
If you go to starwarsuncut.com, there is a link up the top for ‘watch the uncut movie’ which is starwarsuncut.com/watch.
CHUCK:
Yup. And if they do take it down, I hope the put it up on bit torrent because that will really tick the motion pictures people off. Anyway, so my picks. First off, I got a brand new mouse, and I'm sure everybody else in the world have one of these mice. It's the apple mouse that doesn’t have any buttons on it. I think it's the magic mouse, is that right?
JAMES:
Yeah. That’s not really magic.
CHUCK:
[Chuckles] It's magic to me. I just swipe my fingers.
DAVID:
Yeah, the buttons are actually there, they are like one part per trillion.
CHUCK:
Anyway, I'm loving this thing. I mean, I can scroll, I can right click, left click everything. It's cool, and it's Bluetooth, which is the big thing for me, because if you look at my desk -- and I'm pretty sure Dave is the only one that’s actually seen my desk --- I mean, I have my mixer, and mute button, which works for my microphone, but doesn’t work for Skype, because Skype for some reason got switched back over to my webcam for the audio. But then I've got my digital audio recorder, and this big mess of wires. And so, taking just one wire out of the mess, it really appealed to me.
DAVID:
I have been in the room where Chuck alleges that his desk is, and I can't actually testify that I have seen his desk.
CHUCK:
[Chuckles] Yeah. You can't see the top of my desk. Anyway, that was something that I really got excited about. And the other pick, the one that let me get this recorded, my two year old is sick, and so my wife left my office door open -- which is why Josh could hear my son yelling. And my wife left the door open, so I could hear her if she needs anything, but she was downstairs watching a Dora movie. So my other pick is Dora the Explorer, just because it buys me time to get stuff done.
DAVID:
I would have stood up and cheered if you had said, “My next pick is tranquilizer darts.”
CHUCK:
[Chuckles] “Benadryl, lots of it!”
DAVID:
“Daddy, I want…”
CHUCK:
[Chuckles] Don’t tempt me, Dave.
DAVID:
I can't wait to be a parent.
CHUCK:
[Chuckles] Yeah.
DAVID:
And then I'm going to keep waiting.
CHUCK:
[Chuckles]
JOSH:
I think there are actually laws that prohibit you from becoming a parent. [Laughter]
JAMES:
Or if there’s not, we will start them.
DAVID:
Yeah, there's a lobby. [Chuckles]
CHUCK:
Oh man, it would only take me about ten minutes to have enough evidence to keep Dave from ever adopting.
DAVID:
[Chuckles]
CHUCK:
He’s laughing because it's true.
JAMES:
Yeah, it's actually weird, like how come adoptions don’t have a devil’s advocate?
CHUCK:
[Chuckles]
DAVID:
He’s like, “This baby has obviously been bad. Give them to Dave.” [Laughter]
CHUCK:
Anyway, so that’s all we have here. I just wanna remind everybody that we would be reading land of Lisp and we'll be doing it on the 22nd of February. We are going to have Conrad on. I just noticed that if you look at the cover, it's Conrad Bartsky MD.
JAMES:
That's the number one question on my list of questions.
CHUCK:
Yeah, I'm planning on asking him that too.
JAMES:
I wanted to ask him how much Lisp gets used in being MD.
CHUCK:
Yeah, there you go.
DAVID:
How much gets used in his Lisp.
JOSH:
[Chuckles] And is Lisp invasive or non-invasive?
JAMES:
Ooh, good question.
CHUCK:
Anyway, the other thing is we are in iTunes, so go leave us a review, we really appreciate that. There's a link on the website if you want to subscribe. You can also subscribe on your other devices by clicking on the RSS link. And I'm working on getting the podcast in to a few other directories. I've had a few request for Stitcher radio, so were working on that as well. And so keep an eye out if you are using Stitcher or any of those other directories instead of iTunes, and we'll see if we can make that available to you that way. Other than that, we'll catch you next week, and thank you for listening.
JAMES:
Bye everybody.
DAVID:
Love you everybody. Remember, “It's the amps, not the volts.”
JAMES:
Nice.
039 RR Programming Language Fundamentals
0:00
Playback Speed: