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.
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.
It occurred to me that, with currying, there could be a language where operations always take just one argument. That would solve a challenge for a mathematical expression language I have in mind.
19 Sunday Apr 2020
Tags
code clarity, computer programming, operator precedence, order of operations, parentheses, readable code, software design
Enough stories, time for a new rule. Which is to always use parentheses in all except the simplest of math expressions. Languages have a precedence protocol, so the compiler can figure it out, but human readers may be confused.
As always, the underlying motivation involves code clarity for other humans reading the source code — the most important rule of all.
23 Sunday Jun 2019
Tags
There’s a fairly simple puzzle, called The Eight Queens, that I’ve long favored as a project for first semester CS students. The problem is simple enough for a beginner to tackle, yet also interesting enough to be engaging. (And just tricky enough to be a nice beginner challenge.)
Due to a discussion on my other blog, I dug out an old Python implementation I had, and, after looking at it, I thought it might be worth writing a post about. If nothing else, as I said, the problem is interesting enough to be engaging.
14 Tuesday May 2019
Posted in CS101
I’m returning to the full-adder logic circuit modeling to present the code for a version that tries to capture the timing of the signals.
The goal is to take a closer look at the intermediate states of the adder as signals trickle through it.
08 Wednesday May 2019
Posted in CS101
This is the third post in the Full Adder series. The first post explored ways to code the abstract model of a full-adder. The second post explored one way to code a simulation of a physical system (where the models are of the components of the system).
This post explores another gate-based model, but one with only one type of gate. This simulation is close to being transistor-level.
07 Tuesday May 2019
Posted in CS101
In the last post, I explored different ways to model the logic of a full-adder. In this post I’ll explore a model of a physical instance of a full-adder — a model that simulates physical reality.
Because a full-adder is, at root, a mathematical expression, various software models can accomplish the same results. Models are abstractions, so the only thing a model can simulate perfectly is another model.
05 Sunday May 2019
Posted in CS101
Tags
finite state machine, FSA, FSM, full adder, half adder, Python code, state engine, state table, truth table
I was involved in a debate recently about whether a full adder logic circuit is a computer. The computer science answer is: “No, not as we define a computer.”
I plan to address that answer in detail on my main blog. Here I wanted to show some of the different ways a full adder can be modeled and implemented.
19 Monday Dec 2016
Posted in CS101
Tags
computer language, computer languages, computer programming, computer science, GOTO statement, iteration, language design, loop statements, programming language, recursion
When it comes to what makes a computer (or any other) language a programming language, there are three characteristics usually required:
This post is just a brief note (for a friend) about the third item and why it allows three distinct options.
16 Tuesday Aug 2016
Posted in CS101
Tags
constants, defined values, global constants, literal values, literals, named constants, named values, numerical constants, P.J. Plauger, string constants
Along with “always use less-than” is another great piece of always advice, except this one is a prohibition, a never rather than an always (same thing, really, from a programmer’s point of view).
It has to do with never having literal values embedded in your code.
The Hard-Core Coder 