Thanks for stating it more clearly than I did! You've nailed it. It's always bothered me when people dismiss their ability to learn a thing, because they think some part will be difficult. They really have no idea. Yes, the task as a whole will have difficult parts, but we as individual human beings are far more capable than we give ourselves credit for.
Agree about debugging. To my thinking, though, there are two types of "programming": professional (for day jobs, where debugging, testing, and maintainability matter), and recreational (where the point is to just explore new things and try crazy stuff that no one in their right mind would ever "really" do). This "def" stuff falls into the latter category.
Honestly, I wish there were more people doing posts about recreational programming topics. WhyTheLuckyStiff was one of the last great recreational Rubyists. I miss that kind of no-holds-barred exploration.
Thanks! I'm not the first to talk about using IRB for interactive fiction, but I think I might be the first to do so using nested defs. :) IRB-based Zork would be awesome! I hope someone does that.
The article links to my github repository for a wordsearch utility I wrote (here: https://github.com/jamis/wordsearch) and it includes a description of a technique for embedding a message in the unused letters of a wordsearch puzzle.
Backtracking works well to try and fit words in tightly, but (especially in cases where the words just BARELY fit) it can take a long time to generate the puzzles. I'm sure that judicious use of heuristics could prune unprofitable branches more quickly and speed things up, but I've not explored those optimizations at all.
Good point. I was relying mostly on the words being sufficiently complex that the odds of them appearing by chance would be small, but enforcing that assumption would be a good exercise.
Absolutely. Which is all the more reason why holding those ideas close is silly. Get some practice making those ideas real, and learn how to execute on something well.
I love the idea of constrained mazes like this. Another related idea is that of "plank puzzles" (http://www.clickmazes.com/planks/ixplanks.htm), which constrain available moves based on which planks you currently have access to.
Our problem here is the overloaded nature of the word "play". I do not disagree that children learn through play. But I'm using the word differently in my presentation: I'm using it to refer to activities that you (as an adult) pursue casually, as a way to relax or enjoy yourself. If you play the guitar very well, for instance, you might take an hour in the evening to just "play", singing along, etc. This serves many purposes, and is definitely valuable, well-spent time, but it does not serve to improve your guitar playing. To accomplish that, you'd need to spend some time working on guitar techniques that you are less accomplished at.
You can see my problem, hopefully. Ambiguity in language has been the downfall of more than one well-intentioned presenter!
I definitely was not recommending constant practice--I agree that doing so will hurt you more than it helps you! I was recommending consistently regular practice.
My intent was definitely not to portray learning as painful. Learning is a joyful thing. But it's not something you can acquire by passively staring at the world. You need to exert yourself if you want to do more than gain a passing acquaintance with things.
For me, it is interesting because fairly simple means can produce complex (and to me, beautiful) results. It's intrigues me to explore this and see what can be done with it.
It is also particularly interesting to me as a way to explore the features and syntax of a programming language. Maze algorithms are handy (and entertaining), but any algorithm would do. The idea is to implement the algorithm in the language of your choice (preferably one you are are not experienced in) and see how the language lends itself to the implementation.
Naturally, not everyone will share either of these interests with me. But I'm okay with that. :)
Nearly all of the algorithms I described extend well into multiple dimensions. I'm not sure how Eller's would work in 3D, but there is probably a way. And the Binary Tree and Sidewinder algorithms seem like they ought to be possible to adapt to 3D, but I don't immediately see how. The others, though, are all trivially expandable to n-dimensions (just add "up", "down" and any other directions you like to the list of possible moves).
You're absolutely right. Both this one and Aldous-Broder both have a worst-case where the algorithm never terminates. As for whether the algorithm is "unacceptable", that depends on the application. For games? Yeah, this is probably far from your best option for generating mazes. But for cases where you absolutely must have a uniform spanning tree, your options are limited. Wilson's is much better than Aldous-Broder, but still not perfect. Robin Houston has described a variant that combines both Aldous-Broder and Wilson (doing AB until about 30% of the field is filled, and then switching to Wilson's) which empirically improves the odds quite a bit, but as long as you're doing a blind random walk, you're pretty much never guaranteed to finish.
I don't believe Test::Unit does this intentionally; it's just a side-effect of the implementation (load all tests into an array, and iterate over the array).
Aside from me simply wanting to be able to quickly run my tests locally, you mean? :) Mostly it's just an issue of configuring that so it works for all the programmers. Each would need their own remote, and each would need to be hooked into CI. Definitely possible, it just hasn't been a priority.
We do have a CI server, and as you said it works well for catching failing tests. However, it requires that you commit and push your changes in order to test them, which means you are effectively publishing untested changes to your entire team. The same for any kind of distributed testing, unless you are using a shared volume to host your sandbox.
I'm running a Mac Pro with 8 cores, so there is a fair bit of parallelization I can do locally too. Unfortunately, the tests all depend on the database, and while I can certainly use tools like deep-test to spin up separate DB's for each worker, I've found that doing so adds a full 60 seconds to the test run. I fear that until we eliminate the database from (most of) our tests, super-fast runs will continue to elude us.
CI and distributed tests are good things, no question, but I'm still looking for ways to make it possible to run my tests locally in TDD-fashion. I'm far from out of ideas, it's just a matter of making time to experiment.
http://www.astrolog.org/labyrnth/algrithm.htm#perfect says that both the Aldous-Broder and Wilson's algorithms will generate "all possible Mazes of a given size with equal probability". But neither meets your criteria of "efficient", since neither is even guaranteed to finish. I'm curious, too, whether there is an efficient algorithm with the same property (generate any valid maze with equal probability).