Yes. In fact, it is a very simple system in machine language terms.
The key to understanding the system is to look at the physical construction of the part you saw. This is what we would today would call the accumulator. It holds a single mathematical value. You can see it consists primarily of several vertical rods with gears spaced out along them. Each gear holds a digit in it's angle compared to the rod, I can't recall if each disk represented one or two digits?
In a modern machine we would express this as a number of bits, "this processor is a 64-bit design". In the case of the analytical engine, it used decimals, not bits, and had 40 digits. For comparison, it was common on 8-bit machines to perform math in "binary coded decimal", often with two decimal digits stored as 4-bit values in a single byte. Thus, to represent the same numbers as the engine, you would need 10 bytes. Typical BASIC interpreters of the era, like those found in the Commodore line, used 9-byte formats, so pretty close!
The original plan was that this ALU would be connected to a store consisting of another 1,000 such vertical rods, also holding 1 40-digit number each. So in modern terms, this is a 160-bit processor (40 digits / 2 digits per byte * 8 bits per byte), with 1,000 words of main memory.
Along the bottom you can see a number of odd bumpy-shaped disks arranged at right angles to the vertical rods, along a large shaft. These take the place of the clock drivers in a modern processor. As the shaft turns, the arms resting on top of the disks are raised and lowered, which connects and disconnects gearing under the vertical shafts. This is identical in purpose to the diode network that controls the operation of the functional units in early microprocessors.
Note that the shaft is driven by the large gear you can see on the right end. This connects it to the main driveshaft, which connects to most of the parts. The speed of the machine is basically how fast you turn that shaft.
So, for instance, let's say you want to add the value on one of the rods in the store to the value in the accumulator. The Engine did this in steps, it was a "fetch/execute/store" design.
In the first step, a card would be read that had holes that turned off the accumulator, and caused the right memory location to become active. So this is similar to what we would do today with a
LOAD 500, although in a modern processor the memory would be physically copied to a register, whereas in the Engine the store location sort of was a register (early core-based machines worked the same way).
So that card would basically cause that location, 500, to be connected to the main drive shaft, while disconnecting everyone else. It would also cause that shaft to come into contact with a set of gears that were (going to be) connected to the accumulator. It's been over a decade so this is IIRC, but I think the horizontal rods you see in the image are those connections. In any event, there are gears on the bottom of each of the digit disks that connect to the transmission system, and then from that system to each of the digits in the accumulator.
Now you do the execute, in this case an
ADD. This is a card that re-connects the drive shaft to the accumulator, spins that set of disks on the front, and then makes both the store and accumulator shafts start turning. They turn until the store shaft has made one complete spin, but the digits stop turning when they get to zero, so in that complete spin a disk that was originally set to 1, which is 36 degrees, causes the same disk in the accumulator to spin the same amount. But that disk might have already held a value, so presto, you've added.
The brilliance of the design was twofold. One was that it carried out the math in parallel across all the disks. In comparison, if you've seen a typical mechanical calculator using disks you'll note you have to turn each digit's disk individually, so that would be a serial math unit compared to this parallel unit. But the other trick, originally developed on the calculating engine, was what to do about carries...
Consider if the ALU's first digit (the top one IIRC) was 9 and you add 1. This has to make the next digit go up by one as well. This is easy, you have a pin on the bottom of the disk that hits the disk below it and spins it one location. Ahh, but consider what has to happen when the ALU holds 9999999.... that top gear has to spin all the ones under it! The amount of force goes way up, and that is a Bad Thing for a machine with thousands of spinning parts. The design had a way to solve this, I seem to recall it used a separate set of carry bits that were added at the end of the cycle?
The language is very simple, and in modern terms would be considered a RISC design - or more accurately, a load/store design. The punch cards that fed the machine would connect to similar operational rods like the ones on the disks, to form the instructions. These were very simple, they consisted of a load, store, add, sub, mul, div, and in theory, sqrt. So using a bastardized modern assembler, you might do something like...
READ 10, 500 ;put "10" into location 500
READ 5, 501 ;put "5" into 501
LOAD 500 ;load the value in 500 into the accumulator
ADD 501 ;add the value from 501
STORE 502 ;write the result to location 502
And now you've added 10 and 5 to make 15, and then wrote that to the printer.
Connected to the other side of the store was an output system consisting of a printer and a bell. It could be instructed to output the value in any one of the store's vertical shafts. When the program was complete, you told it to ring the bell.
All of these, with the exception of the direct output, map directly onto any simple assembler. It had only one register and 1000 words of memory, making it very similar to many early machines like FERUT.