23 Thursday Jun 2022
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).
27 Monday Dec 2021
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.
29 Monday Nov 2021
Posted in CS101
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.
15 Monday Nov 2021
Posted in CS101
Computers process numbers using arithmetic and logic (which amount to the same thing). Processing text, however, requires at least two levels of abstraction. Firstly, a definition of a textual atom — informally a character. Secondly, a definition of a textual unit — typically called a string. A string is an ordered list of characters.
Therein lies a whole field of computer science. From a practical point of view, implementing text has become much easier with Unicode. Different character sets was one of the more awful aspects of dealing with text. (Remember CP-1252?)
02 Tuesday Nov 2021
Posted in CS101
Tags
code clarity, computer code, computer languages, computer programming, Java, Python code, readable code, toString, __str__
Although I’m categorizing this one as really good advice, rather than as a rule, I think it should be viewed as basically a rule. I think it should be a rule in any object-oriented language that supports it natively (Java and Python, for example).
The advice (rule of thumb, say) is to always create a useful implementation of toString when you create a class. It makes your development and maintenance life ever so much better.
19 Tuesday Oct 2021
Tags
code clarity, computer code, computer programmers, readable code, space character, tab character, text file
There are many issues that divide programmers: operating systems and editors being two huge ones. I’ve worked on too many platforms to care much about the first one, but I’m a lifelong gvim user.
One of the lesser dividing issues involves the crucial source coding choice: Tabs or Spaces? The issue is both less and more important these days. Less because editors are very capable; more because Python is popular.
05 Friday Feb 2021
Posted in CS101
I’ve been going through my old Computer Language magazines, and man have things changed since 1984. It’s a fascinating trip through the early days of personal computing.
I was reading an article about using dates in an application and was struck by the prescience of one bit.
25 Saturday Apr 2020
Tags
Aspect-Oriented Programming, computer language, programming language, Python 101, Python code, Python decorator
Last time I began exploring Python decorators, which are a way of having one function “wrap” another function. Because the wrapper has access to both the input parameters and the return value, it can modify these values (unbeknownst to the inner function).
This time I pick up where I left off by exploring decorators modifying return values, decorators that take parameters, and decorators in classes.
24 Friday Apr 2020
I’ve been playing around with what Python calls decorators. They’re a built-in way of implementing Aspect-Oriented Programming techniques in Python. In fact, they’re quite powerful.
Since they aren’t a common language feature, they can be a little confusing at first, so I thought I’d try my hand at laying out how they work.
22 Wednesday Apr 2020
Posted in CS101
Tags
computer code, computer programming, function currying, Python code, software design, software development
I saw a video recently about function currying, and it triggered the realization that currying might solve a problem I’ve been pondering in the context of language parsing. The problem involves knowing how many arguments an operator expects, what’s called the arity of an operation or function. It can vary from zero to many.
But it occurred to me that, with currying, there could be a language where operations always take just one argument. And that would solve a challenge for a mathematical expression language I have in mind.
The Hard-Core Coder 