> Only in the old "move fast and break things" sense
No, definitely not only in that sense. GC is a boon to productivity no matter how you slice it, for projects of all sizes.
I think the idea that this is not the case, perhaps stems from the fact that Rust specifically has a better type system than Java specifically, so that becomes the default comparison. But not every GC language is Java. They don't all have lax type systems where you have to tiptoe around nulls. Many are quite strict and are definitely not "move fast and break things" type if languages.
> So then what happens if some people's payment method fails once you do charge?
I expect its a pre-auth, like car rental companies do; a pre-auth gives you a code from the card issuer and an expiry. The issuer will reserve the amount on the cardholders account, and only perform the transaction to the merchant once the merchant sends a second message with the pre-auth code.
The article presents a function making use of global variables, declares it bad, and then proposes that the solution is functional programming.
There's nothing wrong with promoting functional programming, but the implication that all non-FP code is hard to test and/or uses global state is naive.
It really isn't. Having worked for several decades on "both sides", this really is my experience. The functional side is better typed and has fewer side effects of this kind. It is more normal, as in more common, to have code work correctly as soon as it compiles. This is my lived experience having worked with Java, Scala, F# and Rust since 1999.
The author doesn't promote functional programming in the strictest sense, he just suggests to use functions that do not have side effects. He argues against changing state.
You can even do it in .NET using dependency injection (which is a kind of an OOP) concept: just supply dependencies as constructor parameters and do not change state in the service/handler.
You can follow the same concepts with ease using Go and no one will argue Go is a functional programming language.
So, the idea is not to do straight functional programming but to apply some lessons from the functional programming.
And I find the article to be very logic and even if I did not apply the same rules as the author, I empirically observed that coding agents shine where they don't have to argue much about state, the more state there is to keep track of, change and reason about, the harder it is for both humans and coding agents to do changes without breaking things.
And since I like the author's ideas I am willing to spend some tokens and put them to the test.
The only things I would add on top of this is modularization, either by using Vertical Slice Architecture or by designing a modular monolith where each module is isolated and has its own contract. Because, the less source code an agent has to reason about, the better are the results.
So my next greenfield experimental project will feature: compound engineering, TDD, SUPER and SPIRALS (as in the article) and modularization.
But it was a severance agreement. She accepted a sum of money for agreeing to not disparage. You don't see anything wrong with someone knowingly accepting these funds, and then turning around and immediately violating the agreement by writing a book (making even more money in the process)?
If it's about whistleblowing and doing the right thing, why not just refuse the money?
There should be a statute of limitations on this stuff. Otherwise we’ll see things like chemical plant employees who signed such an agreement keeping stories of dumping to their deathbeds.
In a better world, disparagement would not legally refer to the dissemination of factual accounts.
In such a world it would only add to penalties for proven libel.
It’s a pretty simple concept: if the truth hurts, you’ve got no one but yourself to blame.
NDAs theoretically should never be able to paper over illegal actions. In a similar vein, non disparagement clauses should not be able to paper over the publication of legitimate insider experience of terrible — even if legal — behavior.
This is (no offense) intellectually dishonest. Nobody wants the risk to be zero. What we want is that, if there is a specific KNOWN flaw in a life-critical system, that the flaw is addressed and the shuttle re-tested before humans are placed in it.
There's no good reason not to do this, except as a lazy cost-cutting measure (and, presumably, under time pressure to perform the eventual moon landing mission within the timeframe of Trump's presidency).
Parent commenter is making a joke about the fact that, in the title "SpaceX Files to Go Public", the word "Files" could be read as either a noun or a verb.
You can have user-defined operators with plain old recursive descent.
Consider if you had functions called parse_user_ops_precedence_1, parse_user_ops_precedence_2, etc. These would simply take a table of user-defined operators as an argument (or reference some shared/global state), and participate in the same recursive callstack as all your other parsing functions.
Well, regardless of technology, the space of things you can accomplish without risking your own troops' lives is very small. (Unless you're willing to go nuclear, which has the pesky downside of ending the world.)
To put it in perspective - in Vietnam, opposition forces lost over a million troops and continued to fight viciously. The US lost around 50,000 and gave up and left.
Democratic countries simply lack the stomach for this kind of thing (which is a good thing, really).
As opposed to democratic countries like the US or UK which would just lay down their arms after a few tens of thousands of their soldiers were killed in the event of a foreign military invasion on their territory?
That’s obvious but you seemed to be putting down foreigners for being able to stomach a million or more of them dying to protect their country from invasion unlike the enlightened democratic countries who couldn’t tolerate so many of their own dying for any reason. I think if tens or hundreds of thousands of soldiers from, say China, attacked the US, Americans would be very willing to fight to the last man to prevent becoming a vassal state of the CCP.
Perhaps the disconnect exists because some Americans have become too used to thinking from the perspective of invaders that they cannot possibly think from the perspective of the invaded?
You're reading something into my comment which isn't there. Hard to say what it is, but it's causing me to not really understand what you're talking about, at this point.
Maybe you thought I was disparaging Vietnam for defending their land? But in your own comment you indicate that you know I'm not talking about defense, that I'm talking about not having the stomach for loss of life as the invading force. So, IDK
I think being the "home team" makes swallowing those casualties easier (as easy as they can be, anyways); it's easy to perceive the situation as a fight for your life.
Obviously, there were other things going on in Vietnam (and Afghanistan and the larger War on Terror) to keep them fighting but it's much easier to muster up the manpower when a war seems existential because it's happening in your neighborhood.
No, definitely not only in that sense. GC is a boon to productivity no matter how you slice it, for projects of all sizes.
I think the idea that this is not the case, perhaps stems from the fact that Rust specifically has a better type system than Java specifically, so that becomes the default comparison. But not every GC language is Java. They don't all have lax type systems where you have to tiptoe around nulls. Many are quite strict and are definitely not "move fast and break things" type if languages.
reply