Introduction
As of late, I’ve undergone a variety of pursuits. I’ve continued reading The Code Book by Simon Singh, experimented with JavaScript scroll methods, and completed the first few chapters of PureScript By Example for a potential future collaboration with a programmer friend.
Pursuit #1
I’ve reached the point in The Code Book where ciphers became mechanized through devices like cipher disks (some used during the American Civil War) and of course, Arthur Scherbius’s Enigma machine of WWII fame. I never really understood how the Enigma worked, but conceptually, it’s quite simple. You would type a message on the keyboard, and electrical impulses would be sent down certain paths (page 4 has a great illustration). These would light lightbulbs under different letter, thus enciphering the message.
Inside the Enigma are ‘scramblers,’ or disks with letters of the alphabet written on them. These are set in a certain configuration (broadcast [in code] over the radio, changed daily) that determines the path of the electrical impulse. To further add complexity, the scramblers would rotate after a certain number of inputs (like the minute hand pushing the hour hand on a clock after 60 clicks). Just to see how impossible it was to crack without a configuration:
3 scramblers in 26 orientations → 26 x 26 x26 = 17, 756
Possible scrambler positions in the machine → 6
Ways to swap letters manually while configuring → 100, 391, 791,500
Total → about 10,000,000,000,000,000 potential configurations
The history of the machine is fascinating. While Alan Turing takes the spotlight for cracking the machine, Polish cryptanalyst and mathematician Marian Rejewski played a huge role in paving the way. If you want further reading, this blog goes into great detail about how modern computers would fare against cracking the machine. The author even coded an Enigma simulator in Python, available to view here - it is a great example of Object-Oriented Programming!
Or you can check out this great resource / collection of cryptographic programs!
Pursuit #2
I keep seeing a bunch of marquee layouts on design agency websites. There seems to be a diverging trend. Either your website is full “Web 3.0, ‘React’ gradients, 3-D animations near bubbly-buttons and dark-mode palette” or “fake-file system, pixellated font, deliberately float-ed images, code-like-it’s-1999.” What both share are different variations of the wonderful marquee (which, ironically, is a deprecated html element).
Well, I didn’t want to be left out, so I made one here. I also have an example of an animated scrolling marquee.
Pursuit #3
Ah, to be functional or objective. Functional programming focuses on immutability, input + output, as well as readable, to-the-point code. Object-Oriented-Programming focuses on modularity, reusability, and puts data over logic.
The following will demonstrate two ways to find the area of the circle, the first taking an OOP approach and the second a Functional approach.
OOP
(using JavaScript) involves creating a “circle” object that can be re-used over and over that contains a “radius.” This object stores data and functions in itself like a container. You can extend this class (make an ‘oblong’ circle) that has all the data of the initial “circle” with whatever else you want to add.
class Circle {
constructor(radius) {
this.radius = radius;
}
area() {
return Math.PI * (this.radius ** 2);
}
}
const circle = new Circle(5);
console.log(`The area of the circle is: ${circle.area()}`);
//extend the class
class blueCircle extends Circle {
constructor(radius, color) {
super(radius); // initializes from the previous class
this.color = color;
}
}
const newCircle = new blueCircle('blue');
console.log(`The color of this circle is: ${newCircle.color}`);
Functional
PureSscript lets you define the blueprint for the function. In this case, the “calculateArea” function will take a number and output a number. Then you define the function. Afterwards, you pass the data into the program (main :: Effect Unit) and “show” it (make it a string). This way, we know exactly how it will behave, and if anything is out of sorts, the program won’t even compile (preventing unwanted side effects.
module Main where
import Prelude
import Data.Show (show)
import Effect (Effect)
import Effect.Console (log)
calculateArea :: Number -> Number
calculateArea radius = pi * (radius * radius)
main :: Effect Unit
main = do
let radius = 5.0
log $ "The area of the circle is: " <> show (calculateArea radius)I hope to continue studying both of these methods! I can see the merits of both. Do you opt for a fast and loose method that lets you group data (but can act in unpredictable ways), or do you opt for a meticulous set up, but a flawless execution?