I’m going to get an electricity bill each month no matter what. I won’t notice a few bulbs being on for a couple extra hours each day.
I would notice having to go out and buy candles all the time, or needing to make them. A candle can be consumed over the course of a day or maybe even a few hours. A light bulb can last months or years.
If light bulbs burned out as fast as candles burn, I would be a fanatic about keeping the lights off and only use them when absolutely necessary.
I asked gemini for the cost of power but it could be lying through its smirking sense of superiority and general all around disdain for the humans it will soon replace.
"The electrical cost to produce the same amount of light as a single standard candle is approximately $0.01 per year if run for 14 hours every day. In terms of energy consumption, a standard candle produces about 12.57 lumens of light, which can be matched by an LED bulb using only 0.1 to 0.2 watts."
MajorBBS could handle multiple lines on its own, but you had to handle ALL of the lines with one box. That meant a serial port interface like DigiBoard which provided some number (8 or 16 or more) of serial ports that you would connect to modems.
Yep - I ran a 16 line Major BBS back in the mid 90's in Seattle - used what was called a "Bocaboard" - had 16 serial ports on it - plugged in 16 external USR 28.8 modems. It all ran off of one PC.
I remember DigiBoard from my early ISP days. We attempted to turn a mid 90's-era Linux system (Slackware) into a terminal server. The Linux drivers for DigiBoard weren't quite up to it so we wound up going with Telebit Netblazers, I think.
Portmasters were very popular. Later on the ISP I worked with moved on to Ascend boxes which had digital modems (T1 / PRI lines.)
PRI was a huge step. The "individual modem" days were a mess. Each modem had a serial cable, phone line, and power brick. I remember doing some maintenance in one of the POPs. There were at least 100 modems, stacked on a cheap plastic shelving unit. The shelving unit was sagging from the weight and heat of all the modems.
This early POP was haphazardly built, so no cable management. I remember a river of phone cables coming out of the wall. The power bricks were also crazy. We had power strips 2 or 3 levels deep, making it a hazard to even get behind the rack without tripping on something.
They'd already switched to PRIs before I started so I missed out on that "fun", but I can personally vouch to the younguns here that every word you just wrote was completely plausible and likely.
I've done AoC on what I call "hard mode", where I do the solutions in a language I designed and implemented myself. It's not because the language is particularly suited to AoC in any particular way, but it gives me confidence that my language can be used to solve real problems.
The walrus operator allows you to use `elif` there to avoid cascading indentation.
if m := re.match(pattern1, line):
do_stuff(m.group(1))
elif m := re.match(pattern2, line):
do_other_stuff(m.group(2))
elif m := re.match(pattern3, line):
do_things(m.groups())
else:
...
...and for me, the benefit is that this is much more clear to me when reading the code. An increasing level of indentation directly maps to needing to keep more in my head. (Sure, in this case you can pattern match and see that there's nothing else, but in general you need to watch out for cases where the else may be doing more than just the next check on the same inputs. )
But the walrus is good even in the absence of a series of matches. It is quite common to need to know more than the boolean "did this match or not?", and so to my eye it is much cleaner to have one line doing the test and the next lines using the results. I don't care about saving characters or even lines. `m = ...match...` immediately followed by `if m:` feels like overhead for the sake of the programming language's limitations; it's extraneous to what I want to express.
Also, I assert that the pattern is better for correctness. It's like Rust's `if let Some(foo) = f() { ... }` pattern: guard on a certain condition, then use the results if that condition is true.
v = f()
if v:
...use v...
invites injecting code in between the assignment and the test. They're two different things to the reader. And it's not as clear that `v` should only be used in the consequent body.
if v := f():
...use v...
says exactly what it means: `f()` may return a truthy value. If it does, do something with it.
The colons there don't represent C++. That's just a way of referring to a windows API function that exists in a specific DLL (in this case "user32"). Because the functions used here do not exist in older versions of Windows, the linked code dynamically loads user32.dll and tries to get the address of those functions so they can be called. That's why you need to know which Windows DLL they exist in.
reply