Make Array

Here’s a useful little tool that I whipped up for another project. It takes a binary file and products C code containing the file in an array. Yes, there are other tools for this, but each has some problem or another (such as not making the array const, which is bad for memory usage; or not NUL-terminating the array for when you’re referencing a text file and want to use standard C string utilities for searching it).

The tool is a grand total of 54 lines includes blanks and white-space. Perfect size to just drop into your project’s source tree. No reason for a package or anything like that.

marry.c

Using it is simple. Call the utility with the input filename and the name of the array to generate. The array will be defined as a const char[]. It’ll also define name_len as a const size_t with the length of the input file. The array is NUL-terminated (the NUL is not part of the _len constant). Output is send to stdout, so pipe/redirect it as needed. Useful if you want to put a bunch of such arrays into a single file.

Another version I may end up making for a similar purpose is one that just generates C string constants, one for each line, use the C constant string concatenation feature for making the input. For text files it’s (sometimes) nice to be able to see the text in your generated code, e.g. for debugging purposes.

Syndicated 2008-09-15 21:02:36 from Sean Middleditch

Baggage Check Advertising - I’m a Marketing Genius!

I’m leaving in less than an hour to head to the airport to fly to Seattle for 10 days. One thing I’ve always done when flying ever since the September 11 attacks is to include a nice advertisement for the poor baggage check technicians who rifle around in our checked luggage.

The ad is a joke ad for a job seeking service, such as Monster. Sometimes I use another service like Dice, although only rarely since those are usually more specialized and not as applicable for the kind of people who check baggage.

For your own personal use, I include here the latest such ad I’ve made for this trip. Yes, it’s dumb. Yes, it amuses me (possibly because it’s 4am and I won’t likely be able to sleep until tomorrow night, in Seattle… or possibly just because I’m immature).

baggage-check.pdf

Syndicated 2008-08-27 07:49:43 from Sean Middleditch

Python Annoyances: Followup

I’ve gotten a fair bit of response to my list of minor complaints with Python. Many of those have been quite helpful, and I’ve learned some good tricks that have definitely made things easier on me. Thank you.

I’ve also gotten a lot of “you need help with switching to dynamic language” responses, however, and those frankly are pissing me off.

To be clear: I’ve been using dynamic languages for more years than I can count with my shoes on. I switched to Python BECAUSE it is a dynamic language, I knew what that meant, and that is what I wanted. The vast majority of the work I do for a living — and have done for a living for a decade now — has been in languages like Perl, PHP, Ruby, JavaScript, and an assortment of other very-much-not-static languages. My issues regarding the type system with Python are not “it uses dynamic typing,” but that it does not offer any optional facility to help with type checking when I do actually need it, which is something that quite a few other dynamic languages manage to offer just fine, thank you.

Let’s take the duck typing example that some dynamic language designers love to use as “proof” that dynamic typing is so awesome in all cases ever. Sure, “if it walks like a duck and quacks like a duck, I’d call it a duck.” That’s fine and dandy. But how the hell do you actually find out of if it quacks like a duck before you try to make it quack? Well, you just try it and then watch exceptions start flying when you try to tell a toaster to quack, apparently. Fun.

I don’t want rigid typing everywhere. I don’t need rigid typing everywhere. I do have some code that simply isn’t going to work if you pass a string, or a number, or None, or a list,
I think the problem here is that there are very, very few languages that have any kind of support for type checking based on arbitrary constraints instead of on rigid types. Java makes you use interfaces. Python just makes you hope and pray. Where the hell is the middle line?

C++0x has a pretty neat feature called Concepts. A Concept is a list of constraints for a type. For example, you might have a Duck Concept that requires that the type have a walk method and a quack method. You can then state that a generic method (which is C++’s way of doing sorta-dynamic typing) parameter must adhere to a particular Concept (or multiple Concepts). So — just like Python — you can pass ANY type you want to such a method without having to inherit from any base class; you never have to tell C++ that the type adheres to the Duck protocol. The language does the Concept tests and figures it out for you. That’s damn handy.

Imagine if in Python you could define a small set of Concepts for your module, or use built-in ones. You can say that method foo takes a “mutable container.” You could pass in a hash, a list, or an object that behaves like a container, just like you already can. If you pass in a string, an int, None, or something else, you get a nice, clear exception that tells you right up front that you passed in the wrong type (and what the right type is) instead of getting some cryptic message about attempting an array operation on some value passed to an inner function called by another function that was called by the actual public API function you originally called in the module. Oh, that would be ever so nice. And, of course, it would be optional.

I mentioned Boo before, and I think it has the right idea for variables. It’s a statically typed language that offers optional dynamic facilities. The static typing stays out of your face so you don’t have to type out huge type specifiers all over the place over and over again. Plus it has a Python-like syntax. If it wasn’t for the political troubles Mono faces with getting into various distributions, I’d probably be using that instead of Boo already.

The general idea with Boo is that, once you define a variable, that variable’s type is also static. So the following code would fail:

foo = 42
foo = “answer”

Once you declare var as an int (implicitly), var is statically typed to int. Seriously, most of the time this just isn’t an issue, because very little code is going to change a variable’s type in a single block. There are exceptions, sure, but they’re pretty darn rare in comparison.

Boo also has a duck typing facility, which allows you to declare a variable as duck (it would have been a little less goofy to call it “mixed” or “var” or something, IMO), which then allows that variable to behave just like you’d expect of any other dynamic language. You can even set Boo to use duck typing by default for variables instead of using type inference, if you so wish.

ECMAScript 4 has the opposite, in which a variable is dynamic by default but can be optionally constrained. (Without type inference, unfortunately.) So you can do:

var foo = “banjo”; // duck typing
var foo as int = 64; // static typing

So, the Python apologists can see that there are plenty of options for dynamic languages to offer static type checking facilities for those cases where it’s just plain useful, while still allowing dynamic behavior elsewhere. To put down my issues with Python purely as “problems adjusting to using a dynamic language” are bunk. Wanting the language to help me enforce the rules I know my software needs is not in any way at odds with dynamic typing. To hear Python folks say that wanting any kind of type checking is “not the Python way” is just as silly to my ears as hearing the PHP folks say that having named function parameters is “not the PHP way.” Yeah. Old versions of the language didn’t have it as the language simply hadn’t matured enough yet, so now you will decide to continue to not have the feature in perpetuity due to some indefinable criteria about “the way” code should be written in the language. If I have to hack around a language’s feature set in order to save myself time or make my code more maintainable, the proper response is not to stammer out apologies or sling accusations about me “doin’ it rong.”

That out of the way, I am again thankful for the help I’ve received. It’s been years since I’ve last used Python for anything substantial and trying to relearn some of the Python peculiarities or the new features that didn’t exist all those years ago has been slower going than I’d have hoped. Thank you!

Syndicated 2008-08-03 18:39:23 from Sean Middleditch

Python Annoyances

Forewarning: It’s been years since I last used Python, so I’m very much a “Python n00b” right now. I’m well aware that some of these complaints might entirely just me being an idiot. I would appreciate any comments pointing out said idiocy so I can stop being needlessly annoyed.

Having decided to write Source MUD in Python, I’ve come up with a list of things I find pretty annoying about the language. In no particular order:

1. Horrendous Documentation

   The Python online manual is just atrocious. The modules are not very well documented, there are far too few examples, and functions don’t actually declare their intended parameters or behavior all too often. Trying to find the proper function to get a job done is hard, and trying to figure out how a particular function is used is even harder. Classes in the standard library are a nightmare to figure out.

   I particularly love the parts of the documentation that include verbiage such as “I can’t be bothered right now to describe…”

2. Files as Modules

   The Python module system makes organizing code hard. Let’s say I have a dozen or so classes that are all grouped together. I have two choices: I either put them all into one file (e.g. module), or each class goes into a sub-module which somewhat bloats all the code that uses those classes (since I have to type out app.module.submodule.Class instad of app.module.Class).

   Contrast this to Java, which forces one class per file. In that setup, the directories are the module names, and the individual files just mirror the class names. So I can split up a large set of classes into a single module without having unnecessary sub-modules.

   I don’t particularly care for Java’s setup, either, but I find it infinitely better than Python’s. I’d personally prefer something like C++’s, where I the programmer get to explicitly declare modules/namespaces and can freely organize my code however I like.

   This one is really getting on my nerves. The few “too clever” tricks I’ve tried to work around it sadly don’t work. I’m pretty much ready to give up and just start putting all my code into singular huge multi-thousand line files so I don’t have to use stupidly.long.module.names.for.everything.

3. Classes Are Weak

   Python classes act a lot more like JavaScript’s prototypes, except that they’re not as flexible. I can’t, for example, declare a set of class member variables and default values in the class definition (including documentation). No, instead I have to make a constructor and set all the class members explicitly from that.

   The really annoying part about that is that I can’t make my classes actually mean anything. Since you can just set any member on any class, or freely add or remove methods on any class, and the language can’t do a damn thing to check for simple mistakes (assigning to a misspelled class member name), my code feels really fragile.

   If a variable is set in a class, that actually defines a class variable, not a member. This works out fine for numbers, booleans, and strings, but not so well for hashes, arrays, objects.

   The Python gurus recommend unit testing to make sure code is solid. That’s great. If I wanted to write dozens of lines of boilerplate code in order to make sure stuff worked, I’d have stuck with C++. I want to write less code and be confident in the belief that that code is correct and error free.

   I might be better off with Boo for this particular complaint. I may just end up switching.

   I think to be honest what bothers me most is that the Python way of doing this is not self documenting. I can’t just look at a class and see, at the top, a list of all class members and their default values. I have to look at the __init__ method, which is a bit less clear cut. It moves all the member definitions to the same indentation level as regular method bodies, which makes them stand out less. It also means that member definitions have to have all the extra boilerplate, like the self. in front of the member name. it mixes the member definitions up with any actual initialization logic that __init__ requires. It’s just messy, and makes a class harder to read and understand.

4. Declarator Inconsistency

   The Python declarator feature is pretty cool. Unfortunately, it’s pointlessly inconsistent. If you want a declarator that has no parameters, you define a simple function. If you want a declarator that takes parameters, however, you must define a function that returns another function. The side effect of this inconsistency is that you end up with two different syntaxes for actually using declarators in the case that you want to call one without any parameters.

   # declarator that takes no parameters
   def dec1(func):
     return func
   
   # declarator that CAN take parameters, but doesn't require them
   def dec2(param=None):
     def actual(func):
       return func
   
   # correct
   @dec1
   def func(): pass
   
   # correct
   @dec2()
   def func(): pass
   
   # correct
   @dec2(param='Test')
   def func(): pass
   
   # incorrect
   @dec1()
   def func(): pass
   
   # incorrect
   @dec2
   def func(): pass
   

   There’s no good reason for that. Both types of declarator should just work the same way.

5. Variables Aren’t Declared

   I’m not all that interested in static typing of variables (although there are plenty of cases where it’s damn handy). What I am interested in is the need to declare that a variable exists before it can be used.

   Python already kicks up an error when you try to access a variable that hasn’t been defined yet (at runtime, unfortunately), but it will happily let you accidentally create a new variable instead of assigned to the one you intended.

   It’s a really minor complaint, and one that I’m sure a lot of people will disagree about, but I’d really prefer it if I had to declare every variable with a simple “var name = foo” syntax. Likewise, a “const name = foo” would be equally nice.

6. Unstructured Docstrings

   Alright, sure, I could just decide to do this myself. I do just find it irritating that docstrings don’t enforce any kind of structure, though. It’s really very similar to the idea of Python’s code block structuring requiring indentation: you get better code if you require the code to be well structured. In languages like JavaScript, C, PHP, or Java, it’s not at all uncommon to see novice (or not-so-novice) developers write code with seemingly random indentation. I don’t have a clue how they manage to do that, but they do.

   The same goes with Python’s docstrings. Since they don’t require any kind of special format, they are all too often just worthless bits of text. About as worthless as most code comments (which I’m just as guilty of). I mean, you have to appreciate the silliness of things like:

   def getResults():
     """ Gets the results. """
     return ...
   
   # test if foo is valid
   if foo:
     ...
   

   Really glad that code is documented! It helps so much in understanding what is going on.

   So, I’m sitting here staring at my (quite useless) docstrings, and wondering what I should do with them. Unlike Java, which just uses special comments to document stuff, there isn’t even a standard package for generating good documentation. There’s pydoc, but I can’t for the life of me figure out what the use of that thing is. I think that’s what the official Python documentation is generated with, and you already know my thoughts on that crap.

   I don’t need anything particularly fancy. The bare bones javadoc syntax would be all I really need. Just a way to add a useful description of a function or class, and a way to list out what each parameter is for and what the return value should represent. And a tool to take that and turn it into something pretty to slap up on a website or in README for new developers on the project.

I have a few other complaints, but as those all are being tackled already for Python 3000, I’m not going to bring them up here. No sense complaining about things that are already being fixed,.

Syndicated 2008-07-31 19:40:38 from Sean Middleditch

Tag Renewal

License plate tag renewal fee: $54

Late license plate tag renewal fee: $108

Ticket for having expired tags on my plate in East Lansing: $130

Total savings if I hadn’t been a moron and forgotten to renew my tags: $184

Ability to set reminders in Evolution for next year’s renewal date: priceless.

Syndicated 2008-07-03 16:55:55 from Sean Middleditch