Posts with keyword: cs330


Can Your Programming Language Do MapReduce?

Joel Spolsky has a great, understandable description of what MapReduce is and why you might care. He also speaks to the benefit of learning functional programming, even if your first job interviewer isn't going to ask you "Have you even programmed in {Lisp, Scheme, Haskell}?" We're all going to care a lot more about things like MapReduce as the number of cores on a chip goes up exponentially.
Continue reading {Can Your Programming Language Do MapReduce?}


John McCarthy on the Elephant Programming Language

John McCarthy(click to enlarge) He wasn't on the program, but this morning's keynote was given by Professor John McCarthy--the inventor of LISP and coiner of the term "artificial intelligence." This morning, he's talking about Elephant 2000, a programming language designed for writing programs that interact with people. One of the things he points out that I find interesting is the idea that the compiler should generate required data structures without the user having to specify them. I'm not sure how that works from his explanation, but I'm certain that if we want languages that admit more parallelism, this is
Continue reading {John McCarthy on the Elephant Programming Language}


Unit Testing in Scheme

I put together a mini-lecture on unit testing in Scheme for my CS330 class. It's not a complete introduction, just a tutorial on getting started. If you have suggestions on using SchemeUnit, I'd love to hear them. Students in CS330 submit their assignments to an autograder. They sometimes try to use the autograder as a test harness with bad results. I think there are some distinct advantages to students using unit testing in preparing their assignments: Unit tests separate tests from the code. It's cleaner and easier to manage. They can write tests before they code. This forces them
Continue reading {Unit Testing in Scheme}


Arc Is Released

Paul Graham has released Arc, his new language. Arc is still a work in progress. We've done little more than take a snapshot of the code and put it online. I spent a fews days cleaning up inconsistencies, but it's still in the semi-finished state most software is, full of hacks and note-to-self comments about fixing them. From Arc's OutReferenced Wed Jan 30 2008 16:21:31 GMT-0700 (MST) Paul mentions Arc in a number of his essays: The Hundred-Year Language http://www.paulgraham.com/noop.html http://www.paulgraham.com/progbot.html Some Work on Arc Arc Paul wrote HackerNews in Arc as a "big project" to shake out the
Continue reading {Arc Is Released}


Scheme and Ruby

Duane Johnson pointed me to a very interesting discussion on Y Combinator about the differences between Scheme and Ruby. This is an excellent discussion--not a flame war--that I found enlightening. The summary, if you don't want to read the discussion thread: Ruby closures are more complex Macros, macros, macros... Can't say enough about macros. Every language besides Lisp and it's close relatives trade macros for complex syntax. Maybe that's a good trade-off, maybe not. Nevertheless, it is a trade-off. You can't have the full power of macros without simple (abstract) syntax that's exposed to the programmer. Now, that I've
Continue reading {Scheme and Ruby}


The IO Programming Language

One of my students, Duane Johnson, asked me this morning if I'd heard of the IO programming language. I hadn't. Looking around, it looks like a fun little language. IO is a "pure" object oriented programming language with a simple syntax. IO is a prototype-based OO language. Consequently, Javascript programmers will find the sample code pretty easy to follow. IO's reflective capabilities are very impressive. IO isn't, as far as I can tell, ready for your next programming project--yet. It's still experimental. Still, it's good to see new languages spring up. There are good ideas to be had and
Continue reading {The IO Programming Language}


Is Intuitive Always Good?

Here's a good, short artcile from Raganwald on the trade-off between intuitiveness and programming languagge expressiveness. Most of the article is a few quotes. The meat is at the bottom. Is Ruby's for loop an improvement over Java? By how much? Ruby's big win over Java in that regard is the ease with which you can use Enumerable's collect, select, detect, and inject methods. Which, of course, are not familiar to the programmer with a grounding in for loops. They require study to understand. But once understood, they make code easier to read thereafter. When you're building a new
Continue reading {Is Intuitive Always Good?}


HQ9+

Here is proof positive that the utility of a domain specific language depends on the domain.
Continue reading {HQ9+}


The Most Important Language in 2006: JavaScript

You gotta love Steve Yegge's blog. One of his latest posts is called Dreaming in a Browser Swamp. Steve's style is to write infrequent, long posts, but they are always worth the wait and the read. "Browser Swamp" makes the outrageous claim that JavaScript is the most important language in the world today. A claim that surely going to get some argument (language wars are so much fun) but one which is grounded in some solid rationale. Note that Steve didn't say that it's the best language, only that it's the most important.
Continue reading {The Most Important Language in 2006: JavaScript}


On The Virtues of Functional Abstraction

Joel Spolsky, who I interviewed for IT Conversations last year is talking about virtues of first-class functions and their positive impact on functional abstraction. Ok. I hope you're convinced, by now, that programming languages with first-class functions let you find more opportunities for abstraction, which means your code is smaller, tighter, more reusable, and more scalable. Lots of Google applications use MapReduce and they all benefit whenever someone optimizes it or fixes bugs. From Joel on SoftwareReferenced Mon Aug 07 2006 14:36:35 GMT-0600 (MDT) When I make students learn Scheme in CS330, it's often the first language they've used
Continue reading {On The Virtues of Functional Abstraction}