The biggest loop hole for not being allowed to hire non citizens or permanent residents is not the H-1B. It's actually B2B contracts that have absolutely no restrictions what so ever.
I just picked up a $200 oneplus just for work accounts. It's completely fine. No lag. No issues. Zero bugs so far. 10 years ago were using what? Android 4 and iOS 6?
In a typical ORM when you do say $Model->DateTime = 1732046457; the __set is actually checking the value and seeing oh it's an integer. Treat this as a unix timestamp. But when you run save() the query is actually converting that to a Y-m-d H:i:s (for MySQL/MariaDB). This doesn't actually happen until you run save() when it makes the query and runs the network call. Most of that time it's actually storing everything in memory.
But you might want to support string date times and the PHP object DateTime as well. So a typical well designed ORM converts multiple PHP types into a SQL string for saving. That's what the historical __set and __get are all about. This is called "mapping" by most ORMs and a very well designed modern one like Doctrine will actually have mappings for different SQL storage engines available.
Some light weight ORMs do not require you to define all the properties ahead of time. They pull the field names from the table and generate the model record on the fly for you. This generally lets you prototype really fast. Laravel's Eloquent is known to do this. It's also useful for derived SQL fields when you use custom queries or join from other tables. Also kinda fun to do it for properties backed by a method. As in $record->isDirty will run isDirty() under the hood for you. All these things can be documented with PHPDoc and static analyzers handle it just fine.
A method is supposed to be an action and a property is supposed to be data. So I don't see the desire to disguise setting data as a "setting method" rather than using the syntax of assignment.
> A method is supposed to be an action and a property is supposed to be data.
I agree! That's why it's wild to allow a setter to do literally anything.
You aren't just setting a property, there is a conversion happening under the hood.
And the reason I hate it is that code that appears to be infallible, isn't. It can have arbitrary side effects, raise exceptions, have unbounded runtime, etc.
There are many ways to make code misleading. You can write a method called plus and have it do multiplication. You can write a method that sounds safe but looks dangerous. Every language relies on programmers exercising judgement when writing the program.
In a lot of contexts you have something that requires a bit of code but really does behave like a property access, where it's more misleading to make it look like a method call than to make it look like a data access. E.g. using an ORM hooked up to SQLite embedded in the program. Or accessing properties of objects that you're using an EAV system or array-of-structs layout to store efficiently in memory. Or a wrapped datastructure from a C library that you're binding.
Of course if you make something look like a property that doesn't behave like a property then that's confusing. Programmers have to exercise judgement and only make things look like properties when they behave like properties. But that's not really any different from needing to name methods/objects/operators in ways that reflect what they do.
It's abstraction. Your not supposed to care that the setter is doing anything. The class is providing you an interface -- what it does with that interface is not your concern. I hate to quote Alan Kay but all objects should just respond to messages. Whether that message corresponds to a method or a property is pure semantics.
I sometimes use getters and setters to provide backwards compatibility. What was just maybe a simple data field a decade ago doesn't even exist anymore because some major system has changed and we aren't rewriting every single application when we can provide the values that they need easily enough.
If you know that setters exist then you already know that the code can do more. It's not a huge mental leap from property setting to method calls. You should never assume anything is infallible. I don't think classes should even expose raw fields.
It's 60 minutes to any point on the planet. 100 people fitting comfortably with a lot more room than a current airliner. The G forces are meant for humans. Very different considerations. No need to bring food or have bathrooms when the flight is that quick.
The G forces are meant for astronauts, not for regular people rich enough to buy this flight. And the whole point of first class is that you pay for luxury. The duration of the flight barely matters, the luxury is the point, and a rocket just can't offer that. There are very few situations where rich people would be willing to put up with the discomfort for a shorter trip.
Especially given that the total trip time will likely be much longer than the flight itself. Consider that you can't take off or land Starship anywhere near a densely populated area, it has to be at least a few hours away by car from anywhere that people actually live.
So you can take a chauffeur to the airport, go trough priority and special luxuries as a first class passenger until your flight for say 1h total, board your 15h flight spent in luxury, and then a limo waits to take you to your destination 30m away from the landing airport.
Or, you can get driven for 3 hours out to the Starship launch site, board the rocket, probably in a special life support suit, wait some hours on the ship for it to be filled (humans are never allowed to approach an already full rocket), fly for one hour in an extremely bare bones flight that literally feels like a roller-coaster (so forget any kind of phone access, you'll be lucky not to puke while just holding on). Then you'll arrive at your destination landing area, ready for some limo to take you on another three hour trip back to civilization.
So you've saved maybe 8-10 hours, being extremely generous and only for the longest haul flights possible, but got none of the luxuries you'd expect. And you get to pay much more for the whole deal.
Remember that the Concorde halved or less the Paris-New York trip, and gave all the luxury you could want, and still went out of business.
Concorde stopped flying for lots of reasons, not the least of which is that BA was the only one flying them by the end. In a different world, had there been a robust cargo program (and a reason for one), it would not have been on British Airways to run the program by themselves and the program would have continued. This is hypothetical, of course, but the rockets are flying to deliver cargo (and people) to space anyway, so there's a lot of expertise being built up that doesn't depend on a passenger service.
I don't know if rocket passenger service will ever happen or become routine, but there's just so much to the Concorde story that simplifying it like that isn't a good case study that does the program justice.
According to SpaceX themselves [0], the axial acceleration can reach up to 6g, though they do say it can be throttled, so what can be achieved in practice remains to be seen. Some graph on reddit with no other context is hard for me to trust.
The link I provided sources the data from an actual Starship flight. Just cause it's hosted on Reddit doesn't change the data. The link you provided was put together before flights even started from simulations.
I don't think this is accurate. I am far far far better off than either my grandparents or parents at this age and house ownership percentages in the United States are at the high end of what we had in the 60s and 70s.
I think the real answer is that now people are faced with the choice and many are simply choosing not to.
>I think the real answer is that now people are faced with the choice and many are simply choosing not to.
It's not like they're choosing no in a vacuum. The price of housing bleeds into everything else being expensive too, especially in HCOL areas. Childcare is incredibly expensive, and in many cases it makes more sense for one of the parents to not work than to pay for it. That of course makes the calculus of having a child more complicated, let alone more than one.
Some 30-40 years ago there use to be stores here in the netherlands ran by old people who owned the building and the inventory. They live on the first floor. Almost no bills to pay. On a slow day they would sell 1 puzzle and 2 postcards. This was enough to buy food.
I remember one that had motion detection lamps. If no one was in the store for 3 minutes the lights went off.
In 2024 the new owner pays some 7-9000 per month and atleast 1000 worth of other bills. They also "own" a modest home that costs [say] 1500+600 and have some employees who also live in expensive houses.
Shopping there is unsurprisingly expensive.
Politics is artifically limiting construction and we all became the slaves of the owner class.
Among my extended family, cousins, etc yes. Everyone has more square footage. Even double or triple. Even those that don't make six figures or live in Europe have much larger living spaces.
> I think the real answer is that now people are faced with the choice and many are simply choosing not to.
Moreover... many people are living very interesting engaging lives without kids that would have been impossible before due to the previous centrality of children to the social scene. In the past, not having kids was met with suspicion. Having children opened doors, economically, socially, and professionally, for better or worse.
Today, you are probably going to have more opportunities without kids. Indeed having kids limits you, versus someone who does not.
Our best engineer spent 2 weeks full time updating our codebase from 7 to 8 using rector (the project was already running PHP 7 but still had a lot of deprecated code from the PHP 5 era which didn't work on PHP 8). That would be eternity without Rector.
I've previously used that to do something. Fell flat on its face. But the fact they literally had to create a tool to solve this problem confirms my point.
At least the H-1B lets us keep some tax revenue.
reply