This time I’ll show you an object-oriented version (a Life class) along with some other tweaks to make things look nicer.
You may have heard that mathematician John Conway died last April. To his everlasting dismay, most people only know him for his “game” of Life (which he considered trivial and inferior to his real mathematical work). Unfortunately for Conway, his Life game is fascinating.
To honor his passing, I whipped up a Python version that I thought I’d share. Python is about the only language I’ve used a lot in which I’ve never implemented Life, so high time I did, right?
I saw a video recently about function currying, and it triggered the realization that currying might solve a problem I’ve been pondering in the context of language parsing. The problem involves knowing how many arguments an operator expects, what’s called the arity of an operation or function. It can vary from zero to many.
But it occurred to me that, with currying, there could be a language where operations always take just one argument. And that would solve a challenge for a mathematical expression language I have in mind.
This is another note for a friend: a followup to a discussion about how some programmers really hate Object-Oriented Programming (OOP) languages.
Most of those who hate OOP hold up Imperative Programming (IP) as the One True Way to write code. The key difference is the IP is function (or verb) oriented whereas OOP is object (or noun) oriented.
I’ve never really understood that active dislike. It’s just another way to organize the same code you’d write anyway.
There’s a fairly simple puzzle, called The Eight Queens, that I’ve long favored as a project for first semester CS students. The problem is simple enough for a beginner to tackle, yet also interesting enough to be engaging. (And just tricky enough to be a nice beginner challenge.)
Due to a discussion on my other blog, I dug out an old Python implementation I had, and, after looking at it, I thought it might be worth writing a post about. If nothing else, as I said, the problem is interesting enough to be engaging.
There’s a general ethic these days — that anyone can code — and like a lot of things, there’s some truth to it, but also some silliness. As usual, it really depends on what we mean by “anyone can code.”
If we mean it in the same way we might say, “anyone can drive,” I think it’s silly. But if we mean in the same way we might say, “anyone can doctor (or lawyer),” well, then I still think it’s silly.
In the first two parts of this series I’ve introduced state engines and taken apart a specific instance of an engine. Now it’s time to tie together the design idea with approaches to building a variety of such engines.
Because the programming logic is in the state table, the engine can be fairly generic. That means it’s possible to create a state engine framework you can reuse for a variety of applications.
Last time I introduced state engines and state tables. I showed parts of a simple implementation of one in Python. It parsed the language introduced in Little Programming Languages. This post continues that, so be sure you’ve read that first article.
I got as far as the state table implementing the process, and that’s where this post picks up. I’ll also get into the
SourceReader class that does the heavy lifting.
At one point in my career, the state engine (SE) was one of my favorite AWK hammers. At the time much of the work involved text processing or, in some cases, serial byte processing (which is not quite the same thing). That sort of thing is right in the wheelhouse for a state engine.
They are a very useful tool and an important part of any programmer’s toolkit.