Your first example has to do with the fact that tuples are copied by value, whereas lists are "copied" by reference. This is a special case of an even larger (IMO) misfeature, which is that the language tries very, very hard to hide the concept of a pointer from you. This is a rampant problem in memory-managed languages; Java has similar weirdness (although it's at least a bit more consistent since there are fewer primitives), and Go is doubly odd because it does have a user-controllable value vs. pointer distinction but then hides it in a lot of cases (with the . operator working through pointers, and anything to do with interfaces).
I think the whole thing does a misservice to novice or unwary programmers. It's supposed to be easier to use because you "don't have to worry about it" - but you really, really do. If you're not familiar with most of these details, it's way too easy to wander into code that behaves incorrectly.
> This is a special case of an even larger (IMO) misfeature, which is that the language tries very, very hard to hide the concept of a pointer from you.
When I came to Python from Perl, it only took me about one day of Python programming to realize that Python does not have references the same way that Perl does. This is not flame bait. Example early questions that I had: (1) How do create a reference to a string to pass to a function? (2) How do I create a reference to reference? In the end, I settled on using list of size one to accomplish the same. I use a similar trick in Java, but an array of size one. In hindsight, it is probably much easier for junior programmers to understand the vale and type system in Python compared to Perl. (Don't even get me started about the readability of Perl.) Does anyone still remember the 'bless' keyword in Perl to create a class? That was utterly bizarre to me coming from C++!
> Your first example has to do with the fact that tuples are copied by value, whereas lists are "copied" by reference.
My mental model for Python is that everything is '"copied" by reference', but that some things are immutable and others are mutable.
I believe that's equivalent to immutable objects being 'copied by value' and mutable ones being '"copied" by reference', but "everything is by reference" more accurately reflects the language's implementation.
Yeah, I know that's how it works under the hood - and why you have things like all integers with values in [-5, 256] being assigned to the pre-allocated objects - but I don't think it's a particularly useful model for actually programming. "Pass-by-reference with copy-on-write" is semantically indistinguishable from "pass-by-value".
There is no copy on write and no pass by reference.
Python is "pass by value", according to the original, pedantic sense of the term, but the values themselves have reference semantics (something that was apparently not contemplated by the people coming up with such terminology — even though Lisp also works that way). Every kind of object in Python is passed the same way. But a better term is "pass by assignment": passing a parameter to an argument works the same way as assigning a value to a variable. And the semantic distinctions you describe as nonexistent are in fact easy to demonstrate.
The model is easy to explain, and common in modern programming languages. It is the same as non-primitive types in Java (Java arrays also have these reference semantics, even for primitive element types, but they also have other oddities that arguably put them in a third category), or class instances (as opposed to struct instances, which have value semantics) in C# (although C# also allows both of these things to be passed by reference).
The pre-allocated integer objects are a performance optimization, nothing to do with semantics.
The model is useful for programming, because it's correct. We know that Python does not pass by reference because you cannot affect a caller's local variable, and thus cannot write a "swap" function. We know that Python copies the references around, rather than cloning objects, because you still can modify the object named by a caller's local variable. We know that no copy-on-write occurs because we can trivially set up examples that share objects (including common gotchas like https://stackoverflow.com/questions/240178).
> I don't think it's a particularly useful model for actually programming
I think “everything is by reference” is a better model for programming than “you need to learn which objects are by reference and which are by value”. As you say, the latter is the case in Go, and it’s one of the few ways the language is more complex than Python.
You could argue that in Python you still have to learn which objects are mutable and which are immutable - but if it weren’t for bad design like `+=` that wouldn’t be necessary. A object would be mutable if-and-only-if it supported mutating methods.
> I think “everything is by reference” is a better model for programming than “you need to learn which objects are by reference and which are by value”.
The model is: everything is a reference (more accurately, has reference semantics); and is passed by assignment ("value", in older, cruder terms).
> but if it weren’t for bad design like `+=` that wouldn’t be necessary. A object would be mutable if-and-only-if it supported mutating methods.
SF city and county are actually the same legal entity, not just the same land. It's officially called the City and County of San Francisco, and it's just as unusual as it sounds. The mayor also has the powers of a county executive with both a sheriff's department (county police to run the jails) and police department (city law enforcement) reporting to him; the city government runs elections like other counties; the Board of Supervisors - which is the typical county legislative structure - also serves as city council. (Denver, Colorado works the same way, I think.)
I don't think that's the point. If non-technical people are able to make a product happen by asking a machine to do it for them, that's fine. But they're not engineering. It simply means that engineering is no longer required to make such a product. Engineering is the act of solving problems. If there are no problems to solve, then maybe you've brought about the product, but you haven't "engineered" it.
I don't think that memorizing arcane Linux CLI invocations is "engineering" either, to be clear.
If you hired people to build that product, you never wrote a line of code. No, you didn’t build it. Your team did. You’re not magically a software engineer, you hired someone else to do it.
Is there a product? Yep. Do you own it? Maybe. But again, you’re not suddenly the engineer. A project manager? Maybe.
That's why I used the word create. I would be responsible for the creation of the product, so imo I created it. I'm the creator. It wouldn't exist without my vision, direction, and investment (of time and/or money).
Like a movie Producer: they don't actually "build" the movie. They use their money pay people to manifest a movie, and at the end of it they have created a movie and get a share of the profits (or losses) that come with it.
No, they shouldn't call themselves cinematographers, but they can say that they "produced" the movie and nobody takes issue with that.
> Do you own it? Maybe.
If I paid for it then absolutely I own it. I get to keep the future profits because I took the risk. The people that "built" it get nothing more than what I paid them for their labor (unless I offerred them ownership shares).
i think people are trying to make this difficult when it’s honestly super simple.
yes, you can make a product. no, it does not suddenly magically make you a musician.
you did the equivalent of hiring someone else to do it. you did not do it.
if you claim you wrote the novel, you’re lying. someone else did. if someone takes credit for work someone else did, they’re lying. it’s honestly not complicated. at all.
you're not countering what i'm saying, so i think we agree.
i'm just adding that (as an "engineer") i don't care what you call me, or what i call myself, because nobody cares and it doesn't matter. i'm commodified labor. replacable. with no claim on anything. and nobody will ever agree on the correct title anyway.
yeah, it sounds like we both agree with the original post.
it literally doesn’t make someone an engineer.
its not difficult to understand but for some reason when its said it pisses certain people off.
i suspect many of the people upset want to convince themselves they’re suddenly magically a musician, architect, engineer, novelist, programmer, etc… when it just couldn’t be further from the truth. they’re just doing the equivalent of sending a dm to a coder friend and the friend is the actual programmer.
i think some people don’t appreciate being told the truth.
It's not just time-value. It's also not just tying/advertising (although it is some of that - if I'm getting a ton of "free" points to American, I'm more likely to fly with them). It's both of those, and so much more.
Loyalty points work like gift cards in that huge numbers of them go unredeemed for any value, so selling them is just printing money. And unlike gift cards, which are typically denominated in currency, airline points don't have a fixed exchange rate to USD, so the airline can sell them to Chase or whatever for $0.01, and then if it needs to rebalance the books to shed the outstanding liability it can easily adjust the point costs of flights to make them only worth $0.009 - it's the same as a price hike, but in a way that's less noticeable to most customers most of the time. And that's assuming they don't just sell the points at an outright profit to begin with.
You can find a number of analyses showing that airlines operate at a loss if you set aside the miles-economy revenue streams. United famously got a line of credit secured against their loyalty program in 2020, in which they and their creditors valued the loyalty program at more than the value of the entire company of United Airlines - which would naively imply that the actual airline, the part of the company that owns large expensive machines and actually sells a product to consumers, had negative value.
The tradeoff on short domestic flights is that it encourages more - and larger - carry-ons, which slows down boarding/deplaning and therefore adds to turnaround time. If I don't have to pay for checked bags, I'd often prefer to have mine checked, especially if I have a connection - but since I do, I'll squeeze everything into a carry-on roller bag instead. Personally, it only takes me an extra second or two, but when you have a whole family doing this and only parent who can actually reach the overhead bins, it bogs down the whole aisle.
This is why I love it when airlines charge for carry-on bags, like spirit does. Everyone just has a teeny little backpack. Getting on and off is a breeze.
At least in the remake, I think the dance minigame was randomized, but you could pretty easily play it perfectly. The dance partner does a little hand gesture to show you what to do next, and then you just hit he key in time with the music.
Settlers might have less of a snowball effect than Monopoly, but it's definitely there. Pretty much any resource-gathering game is going to have it. If your resource numbers get rolled early on, you get to be the first one to build a city or a third settlement. Then your income is higher, so you'll get to the 4th point faster. And so on.
Like another commentor said, the intended fix for this in Settlers is social dynamics: the leader is going to be blocked from the best settling spots, isn't going to get favorable trade deals, and is going to get hammered by the robber. The key strategic gameplay in Settlers is not about profit maximization (that's pretty easy to do), it's about minimizing any appearance that you're a threat until it's too late to do anything about it. If players never collaborate to take down the leader, then early gains can definitely beget later gains.
Even with the social fix, there’s usually one person (sometimes two!) in a four-player game who does nothing wrong but is basically out by the second or third time around the board, just hanging around to help the one or two other non-lead players harass the leader but with no viable path to victory short of an insane run of luck with the dice (or, if you’re me, as soon you realize this has happened to you, you help the leader get ahead faster so you can move on to a better game sooner…)
"The ends justify the means" is a horrific way to run a society in any case, but of course it skips over the question of whether the means actually caused the ends, let alone were the only way to do so. Even if torture did save lives, it isn't a great justification - but then pile on top that your only evidence that it actually does work is fiction and it starts to look like the means were what you really wanted in the first place.
> If you really believe your employer's stock will double in value, you can take your cash bonus and buy shares of it.
RSUs aren't quite that deal, because they're "invested" before they vest. Even assuming that the employer would be equally willing to give you either $X/yr in cash or $4X in RSUs over the next 4 years, you can definitely come out ahead if the stock keeps going up. It's effectively a form of leverage through time arbitrage; you get to buy $4X worth of stock at today's prices using money you don't have yet.
Consider a simplified scenario where the stock is flat forever, except that it doubles in a single day when you've been there for a year. If you take the $X in cash and immediately buy your employer's stock with all of it, you only double your money on that first year's paycheck. By the end of the 4 years, you would have $5X (the $4X you earned in salary/bonus, plus one extra X from the doubling). On the other hand, if you take the RSUs, that entire grant, including what hasn't vested yet, benefits from the increase. In this scenario, by the end of the 4 years, you have $8X.
Similar happens with any scenario where the price is monotonically-increasing, but with more arithmetic. If you assume that the stock will go up over time, and that you wouldn't want to be trying to time the market, this starts to look like a pretty good bet. Compound that with the fact that most employers will be willing to offer a much higher number in RSUs than in cash - that is, if they would offer $X in cash bonuses, they'll offer >>$4X over 4 years in RSUs, especially as a starting/signing-bonus offer - for reasons having to do with financial accounting, and it's suddenly a very attractive deal.
The main reason to prefer cash over RSUs is for diversification. But if we're talking about a public company, you can still sell the RSUs as soon as they vest in order to diversify (and the standard advice is to do so). You really only stand to lose if your employer's stock goes down between grant and vest - not just worse than market, but actually down - which, on average, is an easy bet to take. Getting RSUs at a private company is a much dicier prospect, of course, because now you're locked into that lack of diversification in a way that really matters; even after the point where you get the paycheck, you don't get to bail out if the ship starts to sink.
I think the whole thing does a misservice to novice or unwary programmers. It's supposed to be easier to use because you "don't have to worry about it" - but you really, really do. If you're not familiar with most of these details, it's way too easy to wander into code that behaves incorrectly.