Floating code snippets in LaTeX

Last week I decided to separate “figures” that contain diagrams, graphs and parse trees with “figures” that contained source code snippets. In LaTeX it means the former kind stays in figure environment, while the latter needs to reside within its own. I googled for solution and was quite surprised how the web was full of cluttered random hacks that were done without any understanding of TeX internals. My solution is 9 lines long, and it solves three problems: the environment itself, the list of them and referencing issues.

\usepackage{float}
\usepackage{tocloft}
\newcommand{\listofsnippetname}{List of Listings}
\newlistof{snippet}{lol}{\listofsnippetname}
\floatstyle{boxed}
\newfloat{snippet}{thp}{lol}[chapter]
\floatname{snippet}{Listing}
\newcommand{\snippetautorefname}{Listing}
\renewcommand{\thesnippet}{\thechapter.\arabic{snippet}}

The first two lines connect two packages: one for a mechanism of defining new floating object types, one for toc-ish lists. On the next two lines we define the new list — at this point the new LaTeX counter is already created but not used anywhere. floatstyle can be plain, boxed or ruled — I decided for boxed since I was using boxedminipage inside the old-style figures anyway. Then we define a new float type which fails to define a new counter and has to use the one for the list we already made, just as planned. We finish up by giving the new floating environment some names.

That’s it, we’re done. Just use \begin{snippet}…\end{snippet} and \autoref{…} as you usually would with figures and tables. I see no need to create more counters, to brutally mess with @addtoreset and theHsnippet, etc. Hacks must be simple, effective and beautiful.

Python pains, part 3

Another thing I miss is perfect matching in in and not in operators. And when I say ‘perfect’, I mean prolog. Yes, I’m mad at python because it’s not prolog. Just take a look at this wonderful code:



Neat, eh? So, why can’t I do this, then?



(Yes, I know what the underscore variable in python is for, just pretend you don’t and roll along, ok?)

The nastiest thing about this issue is that it is not universally solvable. Once you’ve implemented a special magic matching function for this particular case, there will be someone who wants to write:



If the whole tuple on the left hand side is defined, one can do the matching perfectly in python. If some parts ain’t, one cannot and has to write an awkward external matching/traversal function. Too bad!

Python pains, part 2

Binary operators are not directly reimplementable, this ain’t Ruby. Some of them can be changed implicitly with a bit of __smth__ magic, others are implemented in the class of one side with a parameter of the other side—and it happens that I often need it the other way around. Suppose the idea of the script is to open the file, read all the lines, stick them together, strip the result, parse it, perform some xpath and create an new element for each element found that way. Easy? Yes. Realistic? Well, the reroot2nonterminals transformation generator is written that way. What do we see there?



And how this would have looked like in my dream python?



Yeah, I know, I know. The problem is inhererent and not really the sole fault of python. However, python already has that nifty self mechanism, which eliminates the difference between a.method() and method(a), and that duality is commonly exploited with string module, for instance. The only thing I need here is two selfs for binary expressions. Or more, for n-ary… Or even…



(The ElementTree is intentionally left out for its side effects, don’t bother). This code actually works, with some magic woven in the Wrapper class. Anyway, if any language ever does this kind of meta-programming naturally, it would be beyond good and evil, I could honestly retire as a language engineer, shave my head, get a peg leg and become a pirate ninja. For now at least it is implementable as meta-hack.

Ten Dying IT Skills

The main problem with the article Ten Dying IT Skills is sloppiness. The author, Linda Leung, is apparently not knowledgeable enough in the areas she writes about, hence the weird choice for list items, hence the complete mess in the explanation.

Take (3), for instance. ‘Microsoft eventually replaced J++ with Microsoft .Net.’ It is plain impossible to replace a language (J++) by a platform (.NET). J++ has been superseded by J#, MS VS 6.0 grew up to be become MS VS .NET, and the underlying infrastructure is CLI instead of JVM (if anyone cares). Even then, why is this a ‘dying skill’? One of the main design goals for J# was to make a language that would allow experienced Java programmers to develop software for .NET. If you possess a good knowledge of J++, it’s not a problem to find a job as a J# programmer.

Now take (6). She maintains that Extreme Programming is a dying skill, which is utter nonsense. From the article it seems that XP is dead since 2003. In reality, Agile Manifesto has been published in 2001 and the methodology only began blooming ever since. ‘Losing ground due to the proliferation of offshore outsourcing of applications development’ also seems unlikely—outsourcing or in-house development, but the software needs to be developed and go through its life-cycle, which is almost never waterfall nowadays. XP is not the only rapid application development/agile software development method, by the way, there’s also Scrum, DSDM, FDD and many others. Even on Twitter, look at @KentBeck, @WardCunningham, @RonJeffries, etc, they are all alive and kicking liek whoa. Look at Ruby on Rails, for crying out loud! If that’s not hot, I don’t know what is. In modern language engineering DSLs also tend to be produced in an iterative fashion.

Skip to (9). I fail to see how the conclusion that HTML is a dying skill is drawn from the fact that ‘good grasp of HTML isn't the only skill required of a Web developer’. Sure, it’s not the only one, but a crucial one. Yes, no-one is writing HTML in text editors anymore like we did ten and fifteen years ago. However, the value of validation and conformance has been understood and appreciated since then, and there are so many HTML embedded languages and technologies—like PHP or ASP—that are simply dangerous to use without HTML knowledge. Bottom line: HTML is not a dying skill, it’s an absolute must. A ‘web programmer’ that states (s)he doesn’t know HTML will never get it to a job interview, (s)he will be scratched out at the first line of HR folks by a big fat red marker. Don’t call us, we’ll call you (or maybe not).

And, finally, (10), the good old Cobol. Leave Cobol alone! Oops, I meant, stop bashing it! A lot of people have been talking for decades about how dead Cobol is, and those are the same people that use hole in the wall machines, ticket booking services and other Cobol applications on a daily basis. Their salary is surely being calculated either in Cobol or in ABAP (which is another step from Cobol to hell). Nobody seems to be aware that most business-critical software is run in Cobol. Why? Because it works. It just works. And I’m not talking about some legacy systems that maintenance programmers are afraid to touch—I’ve been to a couple of Cobol conferences and talked to people from industry (IBM, ABN AMRO, ING Group, Micro Focus, SOGETI, Getronics-PinkRoccade, etc), they are well aware of all pros and cons, and they want to stick to Cobol, at least for backend. SOA is not used to get rid of Cobol, but rather to support it and to introduce new interfaces to the same applications. New applications are being developed in Cobol, too. It takes a lot of time to train a Cobol programmer, and let’s be honest, it is not the most exciting job in the world, but there’s always a market for that, and Cobol programmers and mainframe experts are paid much, much better than Java programmers. Not the least reason for that is the constant lack of new blood.

Python pains, part 1

I’ve been a devoted python hacker for almost a decade, and I don’t plan to back off (at least unless Python 3000 forces out 2.x). I program in dozens of other languages, but whenever I need to hack something up, python’s almost always the choice for me. Still, there are things I miss/dislike about it, and I plan to dedicate a couple of posts to them.

The first thing I don’t like is the semantics of list methods. Those methods always disrupt the fp-ish flow of my script. I want to write:



But I have to write:



And that only if I won’t need the original value of a!

The point is: if I ever want to mutate the original list, I’d be willing to write something like a = a.reverse(). On the other hand, assuming that this is what I always want is far-fetched and limiting to my functional way of thinking.

The universal solution would be to make a library of wrappers like this:



Which is ugly (see for yourself), not integrated (a.append(b) vs append_(a,b)) and involves a lot of copying—more than probably really required. So, for better or worse, I end up each time implementing only wrappers specific to my current app.