• 0 Posts
  • 17 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle

  • This is true, but…

    Moore’s Law can be thought of as an observation about the exponential growth of technology power per $ over time. So yeah, not Moore’s Law, but something like it that ordinary people can see evolving right in front of their eyes.

    So a $40 Raspberry Pi today runs benchmarks 4.76 times faster than a multimillion dollar Cray supercomputer from 1978. Is that Moore’s Law? No, but the bang/$ curve probably looks similar to it over those 30 years.

    You can see a similar curve when you look at data transmission speed and volume per $ over the same time span.

    And then for storage. Going from 5 1/4" floppy disks, or effing cassette drives, back on the earliest home computers. Or the round tapes we used to cart around when I started working in the 80’s which had a capacity of around 64KB. To micro SD cards with multi-terabyte capacity today.

    Same curve.

    Does anybody care whether the storage is a tape, or a platter, or 8 platters, or circuitry? Not for this purpose.

    The implication of, “That’s not Moore’s Law”, is that the observation isn’t valid. Which is BS. Everyone understands that that the true wonderment is how your Bang/$ goes up exponentially over time.

    Even if you’re technical you have to understand that this factor drives the applications.

    Why aren’t we all still walking around with Sony Walkmans? Because small, cheap hard drives enabled the iPod. Why aren’t we all still walking around with iPods? Because cheap data volume and speed enabled streaming services.

    While none of this involves counting transistors per inch on a chip, it’s actually more important/interesting than Moore’s Law. Because it speaks to how to the power of the technology available for everyday uses is exploding over time.


  • Back in the 70’s and 80’s there were “Travesty Generators”. You pushed some text into them and they developed linguistic rules based on probabilities determined by the text. Then you could have them generate brand new text randomly created by applying the linguistic rules developed from the source text.

    Surprisingly, they would generate “brand new” words that weren’t in the original text, but were real words. And the output matched stylistically to the input text. So you put in Shakespeare and you got out something that sounded like Shakespeare. You get the idea.

    I built one and tried running some TS Eliot through it, because stuff is, IMHO, close to gibberish to begin with. The results were disappointing. Basically because it couldn’t get any more gibberishy that the source.

    I strongly suspect that the same would happen with Trump’s gibberish. There used to be a bunch of Travesty Generators online, and you could probably try one out to see.



  • It goes really well with YAGNI. Also DRY without YAGNI is a recipe for premature over-architecting.

    This is also one of the main benefits of TDD. There was a really good video that I can’t find again of a demonstration of how TDD leads you to different solutions than you thought you use when you started. Because you code exclusively for one single requirement at a time, adding or changing just enough code to meet each new requirement without breaking the earlier tests. The design then evolves.



  • Many, many years ago I used to have two Wyse50 terminals, running split screens each with two parts. I did a lot of support on remote systems (via modem!) and I would have a session on a customer system, source code and running on our test system and internal stuff. I didn’t have space for a third terminal.

    At another job I had an office with a “U” shaped desk. I would spread printouts across half the “U” and swivel around between the computer and the printouts.



  • As a boomer (at the tail end, admittedly), I too have lived through all of these things. Plus the other thirty years of shit that happened before it.

    The world threat that was the USSR and Mutually Assured Destruction. The Vietnam War, two Gulf Wars, and 9/11.

    The “Troubles” in Ireland and IRA bombings in London. The Munich Olympics Massacre. The rise of global terrorism. The FLQ crisis. Kent State. Watergate.

    Acid rain. Leaded gas and smog.

    15%+ mortgage rates. The oil crisis. Wage and price controls. Multiple recessions. The Dot Com bubble.

    Police raids on gay clubs. Racial slurs in everyday language. Massive gender inequality.

    24" black and white TVs. It took a week to find out how your photos came out. Watching f@#$ing “Tiny Talent Time” on a Sunday afternoon because there wasn’t any else better on the other 5 channels (if that doesn’t traumatize you, nothing will).

    You had to go to a library if you wanted to look something up in an encyclopedia.

    Cars without seatbelts, crumple zones, anti-lock brakes, traction control or airbags.

    F*CK me. “No experience”. Maybe just enough to know how much better things generally are today.

    Kids always think that they know more than their parents…until they don’t.




  • Well, there are specific hardware configurations that are designed to be servers. They probably don’t have graphics cards but do have multiple CPUs, and are often configured to run many active processes at the same time.

    But for the most part, “server” is more related to the OS configuration. No GUI, strip out all the software you don’t need, like browsers, and leave just the software you need to do the job that the server is going to do.

    As to updates, this also becomes much simpler since you don’t have a lot of the crap that has vulnerabilities. I helped manage comuter department with about 30 servers, many of which were running Windows (gag!). One of the jobs was to go through the huge list of Microsoft patches every few months. The vast majority of which, “require a user to browse to a certain website” in order to activate. Since we simply didn’t have anyone using browsers on them, we could ignore those patches until we did a big “catch up” patch once a year or so.

    Our Unix servers, HP-UX or AIX, simply didn’t have the same kind of patches coming out. Some of them ran for years without a reboot.




  • I’m not sure that what developers really, really need is faster programming cycles. Most teams could benefit more by controlling the process - from idea to deployed. How much technical debt is incurred because users/customers can’t prioritize features or give accurate requirements, there’s way too much WIP, features are huge, releases are huge and infrequent and the feedback cycles are far too long.

    So yeah, as programmers it’s always cool to look at ways to program faster, but what’s the point in programming stuff nobody needs faster? Or programming the wrong things faster?

    I’d be willing to be that if you asked any team, “What are the biggest impediments to delivering value to your users faster?”, the answer would be that you can’t cut code fast enough.