There are many general skills a programmer should have to be effective and valuable. Some are very general — for instance, the ability to learn and to think abstractly — but some are more specific — various tools and tricks of skilled programming.
Among those tools are several non-programming languages all programmers should know. Those include HTML, XML, SQL, and an old one whose name doesn’t end with “L” — Regular Expressions (aka REs, aka RegEx or RegExp).
It’s been a while since I posted here, many balls in the fire and irons in the air, so I thought I’d dig into my archives for an oldie, albeit one more of tin than of gold.
This one comes from a 1995 email from a co-worker who was forwarding something cute she’d found in a Delphi Forum.
One part of Python I especially appreciate is
lambda functions. While I’ve never pursued functional programming, I do like many things about it, particularly the notion of functions as native data objects. Programming with functional objects opens new vistas. Most languages handle it one way or another, but languages make it natural.
Python’s lambda is such a facility, and I use it often. This week I finally got around to writing a
lambda function I’ve been meaning to for a long time, and it’s my new favorite. I thought I’d share it along with some of my other “one-liners”…
In job interviews they sometimes ask about a time you failed. It’s meant as a probe into your self-image and reactions. How you react when challenged; what do you do about obstacles. I suspect anyone whose career revolves around solving problems has a few stories about “the one that got away.”
A recent online conversation inadvertently reminded me of all three that stand out in my history. I made a note to write a post about them. The new year seems like a good time for a trip down memory lane…
The first article (long, long ago) about naming things only scratched the surface. Even with company and language guidelines (or other rules) to help, with so many things to name it’s easy to lose control. Even now, after 44 years of writing code, I still sometimes find myself staring at the screen trying to think of what to name some object.
It’s understandable; there are a lot of things to think about when it comes to a name.
I’ve been playing with calculating the entropy of a toy system used to illustrate the connection between “disorder” and entropy. (See Entropy 101 and Entropy 102.) I needed to calculate the minimum number of moves required to sort a disordered collection, but that turns out to be an NP problem (no doubt related to Traveling Salesman).
The illustration bridges Boltzmann and Shannon entropy, which got me playing around with the latter, and that led to some practical results. This article describes the code I used mainly as an excuse to try embedding my own colorized source code blocks.
I’m not sure how I got to thinking about Turing Machines (TMs). I was going through some files recently and spent some time looking at busy-beaver.c (from 2017 according to the file date). It contains an implementation of a TM. But something else got me speculating about my own implementation; I just don’t recall what.
I decided to actually write it when it occurred to me that I could use a Python generator to implement the Turing Machine tape. Sadly, I didn’t think of it in time for the trilogy I just published about Python generators (part 1, part 2, part 3).
Recently I thought to myself, “Hey self,… Although I’ve never looked into them, I know Python has tools for parsing Python code. I wonder if they might make generating syntax-highlighted HTML pages of Python scripts pretty easy?”
I found the help page for the
tokenize module, and the introduction says it’s “useful for implementing ‘pretty-printers,’ including colorizers for on-screen displays.” That sounds like a strong yes.
One of the great battles programmers fight involves synchronization between two different parts of the code. The most common example of this is what the comments say versus what the code really does. Another common example is the structure of data stored somewhere (like a database) and the code that manipulates it.
A lot of the programmer’s effort and technique is devoted to managing, if not preventing, synchronization issues. The rules encouraging encapsulation, or against global objects, have a lot to do with this goal.