Jamis Buck

> Not only do they help the student with writing code, the introduce important parts of programming as well as Big-O notation.

Are sorting algos the best methods for helping students write code and learning about Big-O? I don't think so. Learning the fundamental data structures are a lot more useful for that purpose, I think. Of the standard crop, I think the binary search is a good algorithm to teach (though one must note its historical implementation problems in languages with fixed int sizes), and if you're going to do sorting then quicksort + insertion sort when N < 16 wouldn't be awful. At least mention the language's built-in sort so that open source projects like gnu flex don't inherit a DIY sorting function in the code (in their case, the evil bubble sort which should never be taught).

Instead of the cast of characters for sorting algos, I'd rather see something like this cast of maze generation algos: http://weblog.jamisbuck.org/2011/2/7/maze-generation-algorithm-recap I think they would accomplish your goals better, plus they have shininess built-in.

>…"Lets learn Unity3D" course in front of me, I would never ever attend that university.

But you would probably still be doing programming and CS elsewhere. You're already set. This post is about trying to attract people into programming at the HS or college level who otherwise wouldn't be. But from the other comments it seems like I might agree with you specifically on Unity3D; I haven't used it myself but it…

Guess triangular and hexagonal grids are somewhat rare, but not exactly unknown. I remember the Programming Clojure book included a maze-generator that was shown for both square and hex grids (and could probably be easily modified for triangles as well?).

Surprisingly the linked generator does not seem to have any choice of different maze algorithms? I guess it only uses one of the perfect algorithms then, meaning all possible mazes have equal probability. Those tend to be pretty boring. I think the biased algorithms often create more interesting mazes.

(EDIT: I see after reading some other comments here and the Help page that the E and R values can be set to create more biased mazes which sounds useful.)

Jamis Buck's Maze algorithm page is a great resource and the book he wrote about programming mazes is even better. It has nice visualizations of how the biases from different not perfect algorithm creates different patterns of mazes.

https://www.jamisbuck.org/mazes/

Implementing and visualizing different maze algorithms is probably my favorite kind of exercise when trying some new programming language (or things like game frameworks/libraries). Most of the algorithms are very easy, so there are no distractions from trying to get the logic right, but there are still some data-structures to play with and a bit more weight than Hello World.

Well, the big one is GC.

Here are a few others:

- both polymorphic variants and GADTs are extremely powerful mechanisms to let you keep track of invariants, in a manner that cannot be replicated readably in Rust so far;

- OCaml's pattern-matching is a bit more flexible than Rust's ;

- (thanks to the GC) OCaml's closures are much more flexible than Rust closures;

- I guess OCaml's blindingly fast exceptions can be useful for some algorithms, although I haven't really experienced the need for them myself.

Again, that's not to say that Rust doesn't have great stuff for it (affine types 4eva!) or that OCaml doesn't have its own limitations – Rust is currently my main language and I do not regret it.

But there are some algorithms that I really don't want to write in Rust. Recently, for instance, I stumbled upon this: http://weblog.jamisbuck.org/2010/12/29/maze-generation-eller-s-algorithm . Trivial algorithm, trivial to write in OCaml, feasible but much less straightforward in Rust.

I wasn't at RubyConf 2004 (back then I thought Ruby was some weird Perl-ish language from Japan, not worth my attention) but for my RailsConf talk I dug up some old blog posts about what it was like when DDH first spoke about Rails at that conference.

Jamis Buck was there: http://weblog.jamisbuck.org/2004/10/2/rubyconf-day-two

Francis Hwang: http://fhwang.net/2004/10/03/RubyConf-2004-Day-2

It's amazing how few people were there and how marginal Ruby was in 2004.