Better world proposals as admissible heuristics

In CS, and graph searching in particular, the concept of an admissible heuristic is one that never overestimates the true cost of something. (Typically achieving some goal.) Different heuristics may give different estimates, but admissible ones never overestimate.

The goal of utopia is a perfect world, or at least a perfect-as-possible world. Dystopian fiction contains great fictional examples of how some would-be utopias aren't actually all that great. But I contend that a lot of those dystopias are still actually better than the present world, overall, and that reaching the perfect world may require such stepping stones. I worry that dystopias can represent local optima and thus be worse in the sense of cutting off the possibility for improvement, but I'm not sure that's possible on a global scale for all time.

Thus it's important to remember that proposals to make this world better, or ideas and visions of what possible future worlds might be like -- say an ill-defined World Without Suffering -- aren't proposing the ultimate perfect utopia, but merely improvements. And if they are better overall, and don't try to pretend to be perfect and final, then we can consider them admissible... To take the previous example, perhaps a certain amount of suffering is needed for human existence to have meaning. However the world is currently full of much suffering that I think we would be better off without, and once we are without, then perhaps we can reason on a further improvement to introduce the right amount back in, which would be another overall improvement on the path to perfection and thus admissible too.

See Full Post and Comments

Nim project

Finished up this fun little side project introducing myself to Nim (and SDL2 in the process): https://github.com/Jach/dodgeball_nim_pygame_comparison

See Full Post and Comments

In favor of privacy, but not as a right

I don't really believe in "rights". I believe in assurances granted by others, and when those others happen to be governments, whether it's a "right" or a "law" matters little to me. But other conceptions of "rights", don't buy it. If you try to argue some rights are objective, or even self-evident, I don't buy it even harder.

I still think many (though not all) the things I supposedly have rights to are nice to have, though, but not for the circular reason that rights are good.

When it comes to privacy, I generally fall into the "none of your/my damn business". There are many things I or you simply don't need to know, and I'll get ticked if you start trying to learn those things, and I'll understand if you get ticked in the other direction. For instance, say you're visiting my blog, and my blog asks for your browser to share your location (which may be from a phone, and thus very accurate). This is none of my damn business, I'm not trying to serve you software that makes use of mapping, something whose business legitimately is interested in your location.

See Full Post and Comments

Some questions on Star Wars

Warning, spoilers below.

I finally saw the Star Wars movie yesterday. I liked it while watching, and I'd watch it again, though on reflection there are some grievances, or just questions I had while watching or after watching that it'd be nice to have answers for... I'll probably research some after I post this. So break out the pizza rolls, it helps if you read everything below in that voice.

Why are there so many tiny kids in the audience? This is a PG-13 movie. Did their parents not see Episode 3, or are they comfortable with the possibility of their kids seeing on-screen amputation and dead children and flesh-burning? Maybe they just trust Disney is a family friendly company like Nintendo and would never be too violent...

See Full Post and Comments

Some (Updated) Beliefs

Years ago I wrote this, expressing without too much elaboration or reasoning several beliefs of mine in various categories. Needless to say, some have changed, and this gives me an outlet to write a little about what I haven't been writing about. So, following the original categorization (with a few new categories), here are some of my current beliefs. If I don't address an old one, conclude it hasn't really changed. Please keep in mind most of these are "academic level" beliefs and thus I'm not super attached to them, for clarity on that (and maybe some updated beliefs if this post is old) see here.

Religion

I stand by my original belief in 2009. The only thing I might add is that I think the rituals employed by religion can be useful, ritual itself is important -- see these.

See Full Post and Comments

re-frame: A software FPGA

Ever since ClojureScript was announced I've been keeping tabs on it here and there to see what sorts of interesting frameworks people come up with. I'm pretty picky when it comes to UI development (not because I'm particularly good at it, just because I'm picky in general) and something needs to do quite a bit to convince me it's worth using over plain HTML+CSS+JavaScript. (Not a fan of Backbone, but I did like Angular.)

Anyway, re-frame has been on my radar for a while as "the pinnacle alternative to Om". Om is really neat, but I've never tried it enough to feel like I wanted to try more of it. I've known about reagent for a while (that re-frame is built on) and instantly loved its usage of Hiccup to specify markup. Hiccup is so straightforward and simple I still haven't fully read its spec, though I should do so because it's kind of disturbing to me that if I have a "component" (function) that returns something like [:h1 fn-arg] then I can insert that as a child element to something else either with [my-fn fn-arg] or (my-fn fn-arg)...

Anyway again, last weekend I finally sat down and read all the through re-frame's manifesto in its README. And afterwards I thought: wow, this reminds me a lot of FPGA programming. I decided to 'redo' an FPGA assignment I had in college, using re-frame. This evening I cleaned up what I made and wrote this up.

See Full Post and Comments

Still tepid about TDD

I recently did a 2-day TDD workshop for work. It covered the basics which were helpful to review, and we did team and individual exercises to apply. My only real complaint is that these exercises were starting from nothing. In order to be convinced of the merits of TDD, I need to see a case study. I need to see commit logs. I need to see a "holy shit" moment where unit tests really saved someone's butter.

Why don't I just go look up those things myself? I'm not particularly incentivized to learn about TDD on my own. That's because I know of the Linux Kernel, which has no tests, and Clojure, which has tests now but none of them written by the core author and creator of the language. Tests are no substitute for careful programming, and if you have careful programming, I don't think you really need any automated tests, though you may find some useful, especially since careful programming is not rewarded in a corporate setting so that bar is a little high most of the time for your average salaried programmer. In one of the creator of Clojure's famous talks he brings up two interesting facts about bugs: they all passed the test suite, and they all passed the type checker. How much value do those two things really give us then when even in the most powerful static type languages with extensive tests we still find an annoyingly large number of bugs? What other things could we trade off with those two things to get a lower bug count? Could we get anything for free if we looked elsewhere? Incentives for careful programming are always going to be a human problem, but perhaps the language can provide features that make careful programming easier? Hence Clojure is garbage collected and immutable by default. Dynamic typing is a tradeoff.

In the class, the final day's assignment was "somewhat large". No one in our group of 20 finished it entirely, including the instructor. This was sort of glossed over, but what I get out of that is: TDD slows me down. Some will argue that as you do it more and more TDD will eventually speed you up, or at least allow you to continue at a constant velocity and not hit a mountain, but without a case study I can't agree with that. I just know that for a new project from nothing, it's much faster for me, and I assume everyone else in the class, to Just Do It, and write useful/semi-useful tests after if I want. (Often to just prove to oneself the thing works as expected without having to prove it manually all the time if the output is complicated.) The time savings of not doing TDD are banked and you can move on to other things. If a bug shows up (that for the sake of argument we'll say would have been caught by TDD), that's okay, you just take from your banked time to fix it. My argument is that if you do in fact spend all of your banked time, and in fact exceed it (subtlety! I'm talking about Expected Time Savings), you're actually spending the same amount of time in total as you would have with TDD, but you're spreading it out (and hence even if you go over your banked Expected Time, that just means your Expected Time was under the real time if you had done TDD to begin with). By spreading it out, you can move faster. :) At least, ship buggy things that mostly work and get you money and then you fix the bugs later, instead of shipping late with no bugs but losing all that potential money. Most customers for most domains don't care if you're 100% bug-free, they care if you solve their problem.

See Full Post and Comments

Older Posts Newer Posts