python/CreatedFunctionsProblem written at 18:17:58; Add Comment
Created functions and exception stack backtraces
There's a problem with functions that make functions: they obscure information in exception stack backtraces, because all of the created functions have the same name. If you have a lot of auto-created functions, just which one is blowing up and how do you tell them apart?
(I noted a similar effect with lambdas back here.)
A function's name is part of its
A similar effect happens with functions that create classes (don't look
at me like that; sometimes it can look like the
right thing to do). Fortunately, you can rename classes by writing to
(I think changing
tech/MicrosoftProblemII written at 16:34:03; Add Comment
Microsoft has another problem
As sort of a successor of a previous entry, here is a thesis:
(There's various reasons they have to: they're forced to by their employer, they need to use programs that only run on Windows, such as IE or Microsoft Office or various computer games, or even because the alternative costs too much.)
This is a problem for Microsoft, because customers that are only using you because they don't have a choice are extremely fickle customers; they are not a good source of long term success. It is much better to offer your customers something they find intrinsically valuable and actively like, instead of just being something they have to tolerate on the way to their real interest.
Now, this is only a thesis; I don't have enough exposure to the Windows world to know if it is actually true. But it is certainly my perception, and definitely my perception that it is not true of the Apple world, that Mac users are using Macs because they want to and like it.
(It is certainly not true of my own Unix usage; I use Unix on my desktops because I actively like the environment. This makes me rather peculiar, all things considered.)
links/WhatYouCode written at 16:27:28; Add Comment
Link: you are what you code
From Robert Brewer comes You are what you code, which has given me something to think about. I'll quote the opening:
(From Planet Python, where his blog is aggregated.)
Update: I apologize to my readers for putting a link here that doesn't work without an extra, annoying step (see the comment).
Update2: the situation has now been fixed.
programming/SimpleDebuggerFeature written at 01:39:35; Add Comment
A simple debugger feature that I would really like
Following up on my earlier thoughts about print based debugging, here's an easy debugger feature that would make my life much better (and make me more inclined to actually use debuggers):
I'm not actually interested in reading the things that I print out, not right away; I'm just collecting the information so that I can look back in time at the program's state once the bug strikes. The only reason I'm printing things out is that this is the only decent way debuggers give me to dump information for later perusal.
Thus, hiding the stuff that I want to record until I actually ask for it is a big net win, because it avoids drowning me in output that I'm just going to ignore until later anyways. As a bonus the debugger would probably run faster because it doesn't have to display and scroll all that text.
This more or less requires a graphical debugger with some sort of scrollback buffer, but it should be an easy feature to implement. Pretty much everything has a 'print something at a breakpoint' feature, and once you have a scrollback buffer it ought to be relatively trivial to insert content into the scrollback area without actually putting it on the screen.
A debugger would get bonus points for making the record searchable, and more bonus points for being able to directly snapshot the state of variables and the like rather than just saving text output. (This might also make the data take up less memory. You do want to provide for journaling text, since sometimes that's the best way summarizing some bit of state.)
* * *
Atom feeds are available; see the bottom of most pages.