notdonspaulding

    function bakeCake() {
      return separateFromPan(coolOff(bake(pour(mix(gatherIngredients(), bowl), pan), 350, 45), 30));
    }

    function bakeCake() {
      return gatherIngredients()
        |> mix(%, bowl)
        |> pour(%, pan)
        |> bake(%, 350, 45)
        |> coolOff(%)
        |> separateFromPan(%)
       ;

    function bakeCake() {
      const ingredients = gatherIngredients();
      const batter = mix(ingredients);
      const batterInPan = pour(batter, pan);
      const bakedCake = bake(batterInPan, 350, 45);
      const cooledCake = coolOff(bakedInPan);
      return separateFromPan(cooledCake);
    }

I agree that the the control flow is more clearly elucidated in the pipe operator example, but it tosses away useful information about the state that the named variables contain. It also introduces two new syntactical concepts for your brain to interpret (the pipe operator and the value placeholder). I contend the cognitive load is no greater in the example with names, and the maintainability is greatly improved.

If you have an example where there are dozens of steps to the control flow with no break, I'd be really curious to see it.

> But there are reasons why we encounter deeply nested expressions in each other’s code all the time in the real world, rather than lines of temporary variables.

And the reason it gives is:

> It is often simply too tedious and wordy to write code with a long sequence of temporary, single-use variables.

Sorry, but...that's the job? If naming things is too hard and tedious, you don't have to do it, I guess, but you've chosen a path of programming where you don't care about readability and maintainability of the codebase into the future. I don't think the pipe operator magically rescues the readability of code of this nature.

The tedium of coming up with a name is a forcing function for the author's brain to think about what this thing really represents. It clarifies for future readers what to expect this data to be. It lets your brain forget about the implementation of the logic that came up with the variable, so as you continue reading through the rest of the code your brain has a placeholder for the idea of "the envVar string" and can reason about how to treat it.

The proposal continues:

> If naming is one of the most difficult tasks in programming, then programmers will inevitably avoid naming variables when they perceive their benefit to be relatively small.

Programmers who perceive the benefit of naming variables to be relatively small need to be taught the value of a good name, and the danger of not having a good name, not given a new bit of syntax to help them avoid the naming process altogether.

The aphorism "There are two hard problems in computer science: cache invalidation, and naming things." is not an argument to never cache and never name things. That's mostly what we software folks spend our time doing, in one way or another.

1. People who have an organizational development model and workflow which is equivalent in complexity to the Linux kernel development model and workflow (i.e. thousands of developers loosely coordinating the release of systems or mission-critical software on a regular cadence). For them git fits their needs better than almost anything else, and it makes sense because it was made for exactly that use case.

2. People who learned their first VCS after Github had reached critical mass and if you had to pick one VCS to start with, you picked git by default. For them their brain fits git, and they think "the git way" is synonymous with "the right way".

Many folks in group 2 never stop to realize that they are on a development team of 5 (or 50, or 500)...and they always cut their release from `master`...and all of their branches are always pushed/pulled from the same Gitlab remote...and within 5 minutes they can chat with anyone who's made a commit in the last 2 years.

I don't take issue with group 1 people who understand the git model and love it and adopt it in their workflow because they need its complexity and they're willing to pay the UX tax to get it. I take issue with the folks who don't understand the git model or realize they don't need any of the complexity and aren't aware of the existence of solutions like fossil and mercurial.

Think of your branch as being one long multi-day math problem. If I'm grading your work, I don't want you to show me all the parts you think are neat and tidy and important after you arrive at what you think is the answer. I want to see everything you tried, even the stuff that didn't work.

I'm not opposed to only having merge commits on master, but somewhere, on some branch which is recorded for all of time, I want to be able to see every decision that was made to bring HEAD to what it is right now, on the most granular level possible.

Well...on your car, at least. I'm not sure how comforting that approach is when you're surrounded on the interstate by Tesla "FSD"s.

What are you saying is being condemned in the NT, exactly?

> Paul (who never knew a real Jesus, as he confess by the way).

Where does Paul confess that he never knew a real Jesus?

However, I think you need to consider the overloading of the term "link" in your product. I know it's your name, but the example shows just how confusing the overloading of the term is to your users. Here's the breakdown of what my mind does as it scans the example link page:

- Ah, I'm at a site, "Paid Link dot To"

- "This link costs $15 to access" - OK, the seller page I just left is selling me something called a "link"

- "You are trying to accessed a link" - Skip over typo...OK, what's the link I tried to access? Like, what's even the thing I was trying to do on the last page?

- "Autofill your card with Link" - Huh? The link already has my card?

- "... or create a Link account" - Is link the name of the site I'm on, the site I came from, or the thing I'm buying? Why do I need/want an account from any of them? If any of them, I'm assuming the account I should want to create is with the seller with whom I've just decided to transact business.

- "Link logo Learn More" - Is this the link I need to click on to get the thing I want? Like a "Download Now" button on a link scam website like softpedia?

- "Access Link" - does this button take me to my Link account? A new website called Link? Ah, it's the content I've been after this whole time.

Certainly none of that is insurmountable for the user, but I just wanted to put it out there to give you my impression as someone who's brand new to your site.

If a pilot makes 50 safety-critical decisions over the course of a single flight, at a 99% success rate, I believe the actual chance of completing the flight without incident is given by 0.99^50, or ~60%. So, 2 out of 5 flights would result in an incident.

Of course, the reverse is true, if you know your actual rate of safety-critical incidents to be 1% of your flights, you can calculate how good your decision-making has been by 0.99^(1/50), or said another way: you've made the "safe" decision ~99.97% of the time.

And doesn't the heating load of the cabin increase as the air velocity over all of its metal and glass surfaces increases? Isn't the shell of the car essentially a giant heatsink with a 70mph relative wind moving across it?

Nothing about justice requires that punishment be meted out in strict accordance with the demographic breakdown of a population except insofar as wrong things are done in strict accordance with the same demographic categories.

Maybe you're assuming that to be the case, but I don't think you'll find any evidence to support such a claim.

You currently have an address hierarchy like <AS Number>:<Network Allocation>:<Subnet>:<Host>. That hierarchy is conveniently conveyed in a single 128 bit number. With an alphanumeric address, 128 bits of ASCII would get you `company:office:l` and your net/subnet/host would require more CPU horsepower to compute.

I don't expect I'll be able to do much, but all of the treatments we've undertaken so far seem very dated (not able to resect, one round of radiation, temodar+avastin for the last year, just switched to CCNU+avastin). I'd love to know where the state of the art is at and know how to nudge/prompt his oncologists to be looking at it through that lens.

My email is in my profile, feel free to reach out privately.

> so this can put the breaks on cancer, but it can't fix cancer?

"Putting the brakes on cancer" is basically equivalent to "fixing cancer". For my Dad's GBM, he has an MRI from 13 years before his diagnosis that seems to show the early stages of his tumor. At the time, his neuro noted that it was mildly concerning, but then didn't order any follow-up testing. So the tumor lay "dormant" in my Dad's head for over a decade. Then it started rapidly growing last year, until he was losing his balance at work, started getting scans, and eventually found the brain tumor.

All of the standard of care around this is focused on mechanical or electromagnetic removal of large parts of the tumor, combined with throwing whatever chemotherapies you can at the body to stop the tumor from growing. Eventually, the tumor grows until it squeezes out all normal brain functionality. Anything that can arrest the tumor without killing you is good.

I have no strong opinions yet in the argument over whether or not the USA conspired to sabotage the NS pipelines. I'm just here to point out that secrecy is not a required part of a conspiracy. The literal translation of "conspire" from Latin would be something like "to breathe together", insinuating a synchronization of movements, a plotting together.

But, in our world today, all conspiracies (both confirmed and theoretical conspiracies) seem to get bucketed together. And so in common parlance, as soon as a thing is publicly confirmed as actually happening, in most people's minds it moves out of the "Conspiracy" bucket into the "History" bucket. But that's just a loss of language on our part. As always, my go-to resource in recovering the meanings of English words is Webster's 1828.

https://webstersdictionary1828.com/Dictionary/conspiracy

https://news.yahoo.com/hillary-clinton-maintains-2016-electi...

In 2020, Hillary Clinton was still casting aspersions regarding the outcome of the 2016 election, sowing discontent about the electoral college, preparing Democrat voters to ignore the results until Joe Biden was declared the winner.

Portraying this game as if it's only being played by one team does not help restore any trust in the federal election process.

Step -2 is what you are doing now, OP, getting informed about the best way to go about this.

Step -1 is forming the battle plan of what you're going to change and in what order of importance.

Step 0 is communicating your plan to all stakeholders (owners, managers, devs, whoever) so they have an idea what is coming down the pipe. Here is where you assure them that you see this as a long process of continual improvement. Even though your end goal is to get to full VCS/CI/CD/DB Migrations/Monitoring, you're not trying to get there TODAY.

Step 1 is getting the codebase into a VCS. Get it in VCS with simonw's plan elsewhere in this thread. It doesn't have to be git if the team has another tool they want to put in place, but git is a decent default if you have no other preferences.

Step 2, for me, would be to make sure I had DB backups happening on a nightly basis. And, at least once, I'd want to verify that I could restore a nightly backup to a DB server somewhere (anywhere! Cloud/Laptop/On-prem)

Step 3, again, for me, would be to create an automatically-updated "dev" server. Basically create a complementary cronjob to simonw's auto-committer. This cronjob will simply clone the repo down to a brand new "dev" server. So changes will go: requirement -> developer's head -> production code change -> autocommit to github -> autoclone main branch to dev server.

Chances are nobody has any idea how to spin up the website on a new server. That's fine! Take this opportunity to document, in a `README.md` in your autocommitting codebase on the production server, the steps it takes to get the dev server running. Include as much detail as you can tolerate while still making progress. Don't worry about having a complete ansible playbook or anything. Just create a markdown list of steps you take as you take them. Things like `install PHP version X.Y via apt` or `modify DB firewall to allow dev server IP`.

Now you have 2 servers that are running identical code that can be modified independently of each other. Congratulations, you've reached dev-prod parity[1]!

Note that all of these changes can be done without impacting the production website or feature velocity or anyone's current workflow. This is the best way to introduce a team to the benefits of modern development practices. Don't foist your worldview upon them haphazardly. Start giving them capabilities they didn't have before, or taking away entire categories of problems they currently have, and let the desire build naturally.

There are a number of things you mentioned that I would recommend NOT changing, or at least, not until you're well down the road of having straightened this mess out. From your list:

> it runs on PHP The important part here is that it _runs_ on anything at all.

> it doesn't use any framework This can come much, much later, if it's ever really needed.

> no code has ever been deleted. As you make dev improvements, one day folks will wake up and realize that they're confident to delete code in ways they didn't used to be able to.

> no caching Cache as a solution of last-resort. If the current site is fast enough to do the job without caching, then don't worry about it.

[1]: https://12factor.net/dev-prod-parity

Another way of saying the same thing is that few businesses can see their revenue double by employing even the most skilled plumber. However, many businesses can see there revenue double (or their costs halved) by employing even a mediocre software developer.

So, I would agree it's true that we live in a special time in history where the translation of business needs to computer languages is being demanded at an ever higher and higher rate. But I would disagree with the framing of this phenomenon as a "tech bubble" or a "distortion on commandable salary".

    Employing a software developer IS expensive.  <- agree  
    Employing a software developer is TOO expensive <- disagree

    - Existing problems get solved.  
    - New, more important, problems emerge.  
    - More developers enter the market (bringing down the 
      cost of development).  
    - Consumer demands shift over time.

How many of these companies will be around in 10 years in the same form that they are today? Ford has been making vehicles for over 100 years. What will give Meta, as an arbitrary example, that kind of staying power?

As those companies come and go over the next 10-20 years, I think your concern that "the rest of the economy could really use software developers" will be ameliorated. Maybe everyone's actually working on unimportant problems right now, and the wider economy has more important problems for us to solve, but the best and fastest way we've figured out how to discover that we've misallocated resources (whether human or any other kind) is to let everyone make their own decisions and realize the individual gain or loss of their decisions.

- Brings clarity to your relationship: "If you aren't finding value in the product, or think you can find better value elsewhere, you can leave at any time." - Keeps you honest. Because you can't hide your failure to deliver a valuable product behind contractually-obligated revenue.

I'm not against contracts at all, and the larger your customer or the more involved your customer relationship gets, the more necessary they become, but even in bigger engagements I shoot for the contract to be payment up-front or in regular installments with easy offramps should the customer stop seeing value in the engagement. The important bit is that if a customer wants out, you should let them out, and it should not cause _you to lose any money or any sleep_.

I don't know how widely applicable that is to other businesses, but for mine, it's a helpful way to structure the relationship.

The more people learn to do this, the further we'll get in our discourse.

I'd love to watch a breakdown of current news stories done with charitable interpretations only. Does anyone know of a news source that doesn't drop down into mischaracterizations of every opposing viewpoint?

What you've described from your own experience is the substance of what a professional network is, and has always been. LinkedIn connection requests are trying to create a digital product in the form of the real-world phenomenon that you've experienced and described. If we're going to call one of them a professional network, everyone in this subthread is saying, let's give the real thing the name professional network, and the imitation a different name.

(None of this is intended to disparage LinkedIn. It is what it is, but if it's trying to be a substitute for real relationships between humans, it will always be the shadow, not the substance.)

    - Make it once.  
    - Make it right.  
    - Make it fast.  

I'm curious if you've got a sense of the interplay between prototyping and correctness similar to your sense of the interplay between performance tuning and correctness? Any thoughts?

News from the datacenter and networking world.

https://rumble.com/c/russellbrand

I disagree with almost every policy Russell Brand proposes, but he points out behavior that should be equally alarming to everyone across the political spectrum.

And more generally...

https://rumble.com/

Because none of the videos on there had to be approved by a Google-paid moderator. I'll gladly sift through the 90% crackpot conspiracy theories about why Trump is still the president to find the 10% of actual news or opinion pieces that exist outside the YouTube filter bubble.

And, without a doubt, the one website on the face of the planet that has consistently brought me the most joy is:

https://desiringgod.org/

Specifically the Ask Pastor John series where John Piper takes on literally any question about the Christian faith and seeks to answer it in the most biblically-consistent way.

    filter(lambda x: x < 10, map(lambda x: x * x, [1, 2, 3, 4]))

    def square(x):
        return x * x
    
    def less_than_ten(x):
        return x < 10
    
    filter(less_than_ten, map(square, [1, 2, 3, 4]))

That's probably the most underrated feature of python. Decisions about how the language should function like this which seem "restrictive" from one perspective, and yet force you down the avenue of good decision-making for readability/maintainability. Sure, it's possible to write terrible python, but you're generally cutting against the grain to do it.

Generally speaking, I tend toward the cleanest code being:

    blog = Blog.objects.get(id=1)
    entry = blog.entry_set.filter(entry_number=1).first()
    if entry is None:
        handle_missing_entry()
    handle_entry(entry)

Flipping your question around, why does the banana cost 20 cents and not 5 cents? Where do you think the upward pressure on the price comes from?

> On day 1 of a new hire's employment, I explain what it will look like if and when I come to fire them. I explain that I will be negotiating their severance and here's how it will look...

Does this ring any bells with anyone? I have this article lodged in my brain as being a great conversation to have with someone on day 1, but have since never been able to find the article again.

One of the promises of millimeter-wave radios (radios which operate at frequencies from 18Ghz-100+Ghz) is that they are less prone to interference because they operate at such high frequencies.

Presumably, one of the bigger reasons to use free space optics is that it results in an almost total elimination of interference. No interference means no coordination is necessary between operators. No coordination between operators means no licensing/regulations are necessary for maximizing use of the available spectrum. Non-regulated or lightly-regulated technologies can have much broader adoption in the marketplace.

Lots of good reasons to pursue something like this.