If you have $2bn worth of the same listed stock and go sell half of those, now you have a net worth of $1400m because your gargantuan order drained the order depth, tanked the stock value and triggered a panicked selloff at the stock market which further drove down that stock's price.
You can't take net worth away because it's just an estimate of what someone is worth. It may eventually be possible to turned into dollars and cents without losing too much in the process, but almost universally it can't immediately be exchanged in such a fashion.
Even more so when we're talking shares in a company that is not yet public, e.g. a founder's shares. At that point the valuation is complete speculation, based on what the company may be worth in some hypothetical future IPO. There's no actual price discovery since there's no public trading of such shares.
as I said, if it were unreal you wouldn't mind losing it.
if it is illiquid, you clearly do.
economic illiteracy is not the best foundation for arguing against taxing the wealthy. by pretending the wealth "doesnt really exist" and "isnt there" to tax it highlights the underlying greed motivating the argument.
if you dont agree, perhaps elucidate on a more legitimate reason you might have had for confusing unreal with illiquid?
The lack of reality is mostly from how much net wealth is a guessestimate. The actual realizable wealth is largely unknowable. There isn't enough price information to give a certain answer.
But sure, how do you propose to pay taxes with assets that can't be liquidated and may not even be possible to valuate?
Even if you somehow pay taxes in assets that can't be liquidated, now the government has the same problem instead. What is the government gonna do, pay its employees in unlisted stocks, yachts and famous paintings? How will it even know how much taxes it's gathered?
If the tax isn't isn't just satisfying some sense of petty envy, and the tax is intended to cover some budget deficit, I don't see how this would help.
there is no lack of reality. you confused liquidity and wealth. a third time.
there are plenty of ways to handle the problem of taxing illiquid wealth but I dont think there is much value in discussing it with somebody pretending that means it is "not real".
it would be like discussing the science behind vaccines with somebody who persisted in calling them "poisons".
Yeah it's a real pity what happened to TLJ. Both the first game and Dreamfall were fantastic in different ways. Though Chapters... yeah, could not get into that one at all.
I think this was true, but I'll be damned if I wouldn't say The Drifter has taken the crown. It raises the narrative bar so much it's just mind boggling you can even tell a story with that much momentum and tension in an adventure game.
Overall we've been eating very well the last few years when it comes to new adventure games. In most of the 2010s new adventure games tended to not really be very good, but the stuff we've seen the last few years from the likes of Wadjet Eye and Grundislav are absolutely on par if not better than the highlights of the '90s.
The Drifter is a great narrative, but the puzzles are just OK.
Wadjet Eye developed and published games have quite a few great games. Blackwell series is awesome (I would've wanted a different ending for the series, but the games are great), Resonance, Unavowed, Primordia, Gemini Rue and Technobabylon are all great as well.
Kathy Rain is also good (haven't played the second one).
I doubt, though, that any are better than Curse of Monkey Island, Grim Fandango (which is arguably held back by its 3d graphics and controls) or The Longest Journey.
I don't know if you can call any point&click game objectively 'good': they all suffer from the problem of the player getting occasionally stuck after missing a hint or failing to make a deduction.
Besides, they are heavily story-based which makes liking them a matter of personal taste.
Adventure games are games that are spiritual ancestors to the game Colossal Cave Adventure (often just called Adventure), which includes most point and clicks, but also the likes of Zork and Myst.
It's very often misused though, I think from people confusing the label as referring to games being about an adventure, rather than being like the game Adventure.
I never heard that the Adventure term came from Colossal Cave Adventure, really
?
It's true that it is/was the other term commonly used for this kind of games, anyhow.
Myst was better categorized as a puzzle game, you wouldn't recommend it to someone looking for games similar to Monkey Island
On the magazines I used to read Adventure was a synonymous of Point and Click.
I definitely don't trust Wikipedia on these kind of things, anyhow it could be that the terms were different in different countries or just different magazines
Yeah. Committing crimes via some sort of elaborate rube goldberg machine is not something that has been just invented in the 2020s with unclear legal precedent.
It's if nothing else a staple in the Arthur Conan Doyle tradition of mystery novels, and even then half the plots involved hiding who was culpable by using the machinations to create false alibis, with delayed murders and the illusion of a locked room as not even in the 19th century did anyone believe that the indirection itself would hold up as a defense.
If someone buries an anti-personnel mine in a public park and then argues that it acted on its own accord when it maimed a pedestrian, I doubt you'll find a court on the planet that would spend even a 4 seconds considering the culpability of the land mine itself.
Meta keyword tags have always sucked even without malice. Because they're invisible, authors frequently forget to update them, copying <head> boilerplate between documents.
When designing a standard like this you need to apply systems thinking.
The poor data quality is a problem for anyone who wants to use the tags, which has seen everyone almost universally reaching for other solutions. Search engines have preferred anchor tags, bookmarking solutions have applied user tagging.
With keyword tags it's been a vicious circle of poor data quality and neglect since day one. Even in documents from the early 1990s when people were really trying, the data quality is inconsistent at best.
Language that runs on the explicit design philosophy of letting other languages experiment first and then incorporating their lessons learned once the dust has settled is late to implement a feature.
It's stable to the point of boring, and there's no shortage of people who know the language and can work with it, it's got best in class tooling, decades worth of libraries almost all very mature. Most of the language's issues are from legacy code bases coded in a style that isn't really relevant to a greenfield project.
The ecosystem has (at long last) standardized on JSpecify (https://jspecify.dev) for nullability annotations. JSpecify allows you to annotate a package or module with `@NullMarked` and your IDE and build (via ErrorProne+NullAway, typically) will check for null safety.
If you develop a library in Java and use it from Kotlin, the built-in Kotlin null-safety will recognize the JSpecify annotations on the library.
Congratulations. You've added another build tool and sprinkled your code with ugly annotations and ifs and Optional Optional.of(x).map(y) all over the place to get the same thing you'd get by moving to Kotlin.
I get it why this seems like a less drastic change, but this saddens me. Kotlin solves more issues with the type system (smart casts, reified types, immutability by default), without sacrificing readability. Unless I can see a solution in Java that makes dealing with NPEs as easier for lazy developers as ignoring them, I don't consider it a solved issue.
I don't really think about it too much, it works fine. We don't use Optionals, I'm not sure why you brought that up. I'm not a dogmatic person in this respect, rather pragmatic. I'm sure Kotlin is great, and I'd enjoy writing it, but for now, the vast majority of the finance world runs on Java, so it's what we use. I find it easy to work with, which counts for a lot.
> Congratulations. You've added another build tool and sprinkled your code with ugly annotations and ifs and Optional Optional.of(x).map(y) all over the place to get the same thing you'd get by moving to Kotlin.
You deserve the strawman award of the year.
NullAway and JSpecify encourage making as many types non-nullable as possible, thus they can actually also advice about removing redundant null checks. Nullable types become the painful exception that visibly spreads through the codebase, which discourages writing code that relies on null.
Optional doesn't enter the picture at all. NullAway kills their usecase within ones own code. They are anyway only recommend as return types to force others to check for an emoty case, but I think Optional will become fully optional when the Java platform gets nullable types on its own.
Google Error Prone is a code linting tool that's very useful in its own right, and NullAway is just another plugin.
Not exactly the same solution as JSpecify, since it doesn't rely on annotations, but it's also more ergonomic.
I'm not comparing this to "null-restricted types", since that's a draft JEP that hasn't made it even into a preview feature. Go also had multiple proposals for explicit nilability in types, and while they probably have less prospect of ever seeing the light of day compared to Project Valhalla, as things currently stand, Go is in the same position as Java: They are both extremely prone to NEPs out-of-the-box and they both have external tooling that can help you avoid them.
Java null checkers have more comprehensive coverage potential compared to Go, but Go is the more ergonomic one here. You don't need a single extra annotation on your code.
It's a panic in Go, not an exception. In practice that's usually a whole process crash. You can catch panics and kinda use them like exceptions, but it's not conventional.
Oh, net/http recovers from a panic inside a handler and sends error 500. I don't know if that was always the default. Where I worked before, our own Go servers didn't recover, and it did cause outages.
This is kinda bad practice. Go and Rust panics are similar, they aren't exceptions that you can safely recover from. Say there's a panic in the middle of modifying some global state like a database connection. Hence complaints about the net/http recover like https://github.com/golang/go/issues/25245 . But I guess they decided it's worse to let servers crash from trivial mistakes.
Can I trust code I’ve written myself with no guarantees from the language? Maybe. Can I trust code written by dozens of other developers (and/or agents) working on the same project over multiple years? Definitely not.
Can you explain what the issue is with nullability here? Is the concern that someone's code returns null in normal circumstances but doesn't document that well, so you don't check if null? Cause if it's an error situation, one way or another some exception has to be thrown.
Most engineers do not have the ability to impose rules by fiat on all of their coworkers. It seems like you're misunderstanding the nature of working on a codebase as an IC when other developers contribute to it. If all of my coworkers don't want a lint rule I propose, I don't get to add it. If all of my other coworkers want to write code in a certain way and approve each other's MRs with code written in that way, I don't get to veto it.
Most engineers don't get to decide to use a language either. Usually someone with the clout to pick a language has the clout to set style requirements too.
They do get to decide which jobs they take. And the languages involved are one of the easiest filters. A lot easier than checking whether the code a company actually writes is any good.
Theoretically you don’t need to write AbstractFactoryProvider in Java, but looking at languages mentioned in job offers, I have a pretty good idea of which of them have a high probability of working with such code and which do not, even if all of them say they have the best code ever.
There are plenty of reasons why someone might not have a wide range of job options available and need to prioritize based on other factors than the language they have to use.
For concrete example, it took me a long time to find a job last year due to only fully remote being viable since my wife's autoimmune condition means I'd be risking her health by commuting, and nowadays most places seem to either expect hybrid if you live near an office (I'm within the geographic limits of NYC despite being nowhere near Manhattan), restrict by time zone (there were quite a few jobs I was interested in where they only would accept remote with Pacific or Mountain Time), or have onerous travel requirements (multiple opportunities I interviewed for didn't work out because they expected me to fly to the west coast every couple of months, which between the time there and jet lag would mean I'm not productive close to a quarter of the time).
I was in a fortunate position to be able to hold out for a while and ended up finding a fully job with my preferred language after around eight months, but I had already come up with a timeline for when I should start relaxing certain constraints if it went on longer. Programming language was literally the first constraint that I was going to drop if it lasted a few more months because prioritizing my wife's health is non-negotiable, and I'd rather work in a language I don't like as much on something that I don't feel is actively making the world a worse place than work in my favorite language on adtech or at some cryptocurrency startup. It's not clear to me why it would be a problem for me to care about using my non-favorite programming language well if I happened to be employed to write it.
I don't disagree, but that sounds more like a response to the person asking "what's the argument for picking Java?" than one to the someone who finds "Have you tried not returning null or constructing incomplete objects?" and "Why don't you have any coding standards?" to be poor takes.
If someone's asking "why Java" or is saying nulls make it a hard no, then you'd assume that they have a choice in the first place, which generally means they also have some ability to set coding standards at the same time that they're choosing a language.
Scala technically allows you to use nulls or throw exceptions pretty much wherever (necessary for Java compatibility), but it's not an issue because people simply don't outside of super niche situations (generally some low-level thing, or a shim). Similar to `unsafe` in Rust. Or casts in all sorts of languages.
Just for reference, Scala actually has proper null safety. You can turn it on with a compiler flag and then use union types to denote nullable types, like String | Null
> If someone's asking "why Java" or is saying nulls make it a hard no, then you'd assume that they have a choice in the first place, which generally means they also have some ability to set coding standards at the same time that they're choosing a language.
I don't understand that logic. I sometimes ask people to explain why they think a certain policy should be implemented by the government after they state their support for it, but I don't have the ability to set government policy. I have trouble imagining you genuinely assume that any time someone asks you why something should be the way you say that you think they have the ability to change it if you convince them.
Of course you assume that; if you're talking about what a policy should be, then you work in a hypothetical world where the policy can be chosen. You don't say "but what about some other minor detail! That would require an additional policy choice, and we can't change related policies."
Like if I think my business should open an hour earlier, and you say "but the employees won't be there yet so who will open the doors!" obviously the solution is to also change the work schedule. When you have closely related policies, generally the same person/people are empowered to make both changes.
Yes, a hypothetical world, not necessarily the real one. The first comment you responded to from me was me responding to someone who said "Why don't you have any coding standards?". It sounds like the answer to it that you're proposing is "I do, but they're just all hypothetical", which I guess isn't technically wrong but it's entirely irrelevant to the real-world circumstances that you still haven't addressed in any way from what I can tell.
Precise wording aside, the essential content of the back-and-forth here is:
> When should one use Java on projects?
> One shouldn't consider Java because it lets you use null.
> That's easily solvable by just not using null.
> But you can't just do that. People will use it.
> You can just do that. Tell them not to.
Like I'm not seeing the issue. This is like saying you can't use Rust because people will use `unsafe` because it lets them do C programmer things, and then claiming it is simply impossible to tell them not to do that (and set tool policies to flag anyone attempting to).
In the real world, if you're in a position to even ask "why use Java for a new project?" then you are presumably also in a position to have "don't use nulls" be a satisfying answer to "what about nulls?" If someone is asked what technology to use for a project in the first place, they are almost certainly also asked about how it will be used. The hypothetical here is not "do you have coding standards" but "are you a decision maker," and when the original question is "when should one decide to do X," you have to accept as a premise that you are placing yourself in the role of a decision maker in the first place.
> Like I'm not seeing the issue. This is like saying you can't use Rust because people will use `unsafe` because it lets them do C programmer things, and then claiming it is simply impossible to tell them not to do that (and set tool policies to flag anyone attempting to).
I'm not seeing how you can seriously claim that the amount of unsafe used in Rust over the past 11 years is anywhere close to the amount of null used in Java for the past three decades. The vast majority of Rust projects don't have any unsafe used directly in them. I have trouble believing that the fraction of Java projects that don't ever touch null is anywhere close to as high.
> In the real world, if you're in a position to even ask "why use Java for a new project?" then you are presumably also in a position to have "don't use nulls" be a satisfying answer to "what about nulls?
You keep framing questions as something people only ever ask if they happen to have the power to make decisions, and that still makes no sense to me.
> The hypothetical here is not "do you have coding standards"
That's almost the exact question I responded to initially! You responded to me responding to the question "Why don't you have any coding standards?". I feel like you're trying to argue against me as if I commented several levels above in the thread than I actually did, and then getting confused by me not accepting that premise.
The question was about greenfield projects, not all projects in existence. In a greenfield project, you can set your own standards, be judicious about what libraries you use, etc.
I'm not framing it as a question one only asks if they happen to have the power to actually decide to use it; obviously a curious student might want to know why large successful companies continue to use the JVM even for new projects. I'm saying that the answer can be given from the perspective of someone who does have that power, and that the question is really "if I can choose a language, why would I choose Java." That doesn't imply that the person asking actually has that power, but it prevents silly answers that are addressed by "don't do that."
Everyone has to deal with other code that might not even be from the same org. The "check it in CI" answer isn't an excuse either. You're bolting on so much extra crap that way.
I just don't see why nullability is a problem in the first place.
I don't think I've encountered an external library that returned partially constructed objects returned nulls (at least not without a @Nullable). There are probably cases of this existing, but those types of libraries don't tend to see a lot of users.
I admit I haven't worked in Java for years, but no project I've seen at my current company (the only one I've worked at since agents have been a useful thing) is anywhere close to removing all dependencies. From what I've seen, people want to spend tokens on new things, not things that are already known to exist. Even if you can reinvent the wheel, it's not something that an employer is going to be particularly happy to subsidize.
I’m not sure how long it will take, but please - can we stop saying that annotations like @IHopeThisWontBeNull is a toy for kids and, having so many years of incidents caused by those and having LLMs to write and fix the code, we can rely on language and compiler already?
You're drawing a distinction that doesn't matter in practice. If you encounter a NullPointerException incident then you either didn't annotate your code or you didn't run the tooling. (In fact before even running your CI suite, any serious IDE will tell you immediately that you've mishandled null somewhere.)
I get that some people feel like it ought to be built-in to the language rather than a separate tool... but people's personal feelings are irrelevant to the lived experience of my day-to-day work, where worrying about null is truly a thing of the past.
It is really not a big deal nowadays, the problem of the same scale as having index out of bounds error (no language has good defence against this, yet it is not a catastrophe).
That's expected (the index out of bound). You have an array, and maybe it grows, you read a number from input, you don't check it against the size of the array because you want to torture the language, use it to get the element at that index and... I'm sure that there is a surprisingly number of different designs of what it should happen and a number of designed ways to ensure that it doesn't happen. But a runtime error is expected.
yes, so are the NPEs - both are runtime errors indicating a bug in the code. NPE was a major source of irritation 20 years ago, but what many people do not know is that debugging NPEs in Java is easier now - they carry more information about the source. And the culture has evolved.
> but what many people do not know is that debugging NPEs in Java is easier now - they carry more information about the source
Unfortunately, no, they don't. Not after your application has been running for a while; newer JVMs arbitrarily decide you don't need the stack trace anymore, and all you see in your logs is "NullPointerException" (unless you still have the logs from several weeks ago, just after the last JVM restart, which might still have the full stack trace). Older JVMs were better, since they always had the full stack trace; debugging NPEs was easier with them.
The problem with array out of bounds is that you'd need to reason about arithmetic expressions over natural numbers. However, in general that's a very thorny problem since one runs squarely into [Gödel's incompleteness theorems](https://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_...). Working around it requires painful restrictions or cause uncertainty over whether the compiler will apply certain optimizations.
Unlike C it is trivial to catch a NullPointerException and confine the crash to the unit of work. And unlike C you are not talking about insanely dangerous pointers, you're just talking about an NPE.
I'll admit it's a hassle when something wasn't initialized properly and then you get a null pointer exception at some unrelated code much later. It's not always easy to debug. Catastrophic? No!
There are a lot of third party tools that can check for null safety and a lot of work is being done to make Java's initialization safer but also a little more flexible, there is
and there are all sorts of practical answers. Nulls in Java are low on my list of annoyances, way behind front end programmers who pepper my CSS files with "!important" because they don't know about precedence (though maybe they think my .clazz.clazz.clazz selector is brain dead!)
I was alluding to how people who fall out of favor with Putin have a tendency to have mysterious fatal accidents, more than 10 of them falling out of windows.
So what I'm saying by saying that he fell out a window is that Putin and/or the FSB arranged his death. It's not a statement of the means of his death, but who arranged it.
Embedding the image would have ruined the comedic timing and made it less funny. Comedy is mostly about subverting expectations. If your eyes are drawn to the punchline before you read the set up it doesn't work.
I hope that this is temporally and spatially far away enough. In order to fully appreciate the joke, one should have read https://openai.com/index/navier-stokes-solution/ (I didn't beforehand).
You can't take net worth away because it's just an estimate of what someone is worth. It may eventually be possible to turned into dollars and cents without losing too much in the process, but almost universally it can't immediately be exchanged in such a fashion.
Even more so when we're talking shares in a company that is not yet public, e.g. a founder's shares. At that point the valuation is complete speculation, based on what the company may be worth in some hypothetical future IPO. There's no actual price discovery since there's no public trading of such shares.
reply