They are motivated to pick what they believe is most likely to happen. The develope their idea of what is most likely to happen for the news. The reporters use their bets to wrote stories predicting what will happen.
First, you have inside traders. Then, among legitimate bettors, you have smart people using multiple data sources (not just the "news") and doing sophisticated analysis that most journalists cannot do, and are not motivated to do -- again, because their incentives are different.
Smart people cannot predict things by 'research'. "Will the US strike Iran by X date" going from 20% likelihood to 80%+ within hours points simply to insiders.
You can do research to know the US would strike, there's no other point in moving multiple carriers over to somewhere. But exactly WHEN is not researchable. This applies to most other bets. So lets stop pretending there's anything more than 2 cohorts, insiders and degenerate gamblers.
It's an empirical fact that smart people can predict things by doing research. See Tetlock's book Superforecasting.
I've been doing it profitably myself for almost 10 years now. I have zero special inside knowledge, and no access to any other non-public information.
> Will the US strike Iran by X date
Last year I did think the market for a strike on Iran was significantly underpriced given the information and conditions within a specific frame of time.
I don't think every smart person can just pop into prediction markets and print money, but I know many smart people who are long-term winners. I also don't try to knock people as degenerate when they have genuine talent.
You haven't been profitable for 10 years on prediction markets and you being profitable doesn't mean anything in regards to insiders or the rigging of a market.
As a sysadmin, not developer, I hate Java almost as much as Windows. The error messages Java apps produce are like coded messages that you have to decipher.
I.E. Instead of "<DOMAIN> TLS Handshake failed" it will be something like "ERROR: PKIX failed". So now I have to figure out that PKIX is referring to PKI and it would make too much sense to provide the domain that failed. Instead I have to play the guessing game.
Java has proper error messages with a full stack trace that tells the whole story.
Of course individual developers may lazy out on writing useful error messages, but that's hardly a Java issue.
Meanwhile in Go you can be happy to have any error message at all. And then you can hope it's a unique string you can grep in a codebase. Where you only may find a line of code you could have arrived from many different places.
And Java typically does produce both (see Exception "cause" field). So when an exception stack trace is printed it's actually list of stacktraces, for each "cause". You can skip stacktraces and just concatenate causes' messages (like people often do in Go).
So the full message would be like "Cannot add item X to cart Y: Error connecting to warehouse Z: Error establishing TLS connection to example.com 127.0.1.1: PKIX failed".
Exceptions with stack traces are so much more work for the reader. The effort of distilling what's going on is pushed to me at "runtime". Whereas in Go, this effort happens at compile time. The programmer curates the relevant context.
And come on, skipping 5 lines and only reading the two relevant entries is not "much work". It's a feature that even when developers eventually lazied out, you can still find the error, meanwhile you are at the mercy of a dev in go (and due to the repeating noisy error handling, many of the issues will fail to be properly handled - auto bubbling up is the correct default, not swallowing)
The Go errors that I encounter in quality codebases tend to be very well decorated and contain the info I need. Much better than the wall of text I get from a stack trace 24 levels deep.
Quality java code bases also have proper error messages. The difference is that a) you get additional info on how you got to a given point which is an obviously huge win, b) even if it's not a quality code base, which let's be honest, the majority, you still have a good deal of information which may be enough to reconstruct the erroneous code path. Unlike "error", or even worse, swallowing an error case.
This is only useful to the developers who should be fixing the bug. Us sysadmins need to know the immediate issue to remediate while the client is breathing down our neck. Collect all the stack traces, heap dumps, whatever you want for later review. Just please stop writing them to the main log where we are just trying to identify the immediate issue and have no idea what all the packages those paths point to do. It just creates more text for us to sift through.
ExceptionName: Dev-given message
at Class(line number)
at Class(line number)
caused by AnotherCauseException: Dev-given message
at Class(line number)
It's only the dev given message that may or may not be of good quality, the exact same way as it is in go. It's a plus that you can't accidentally ignore error cases, and even if a dev was lazy, you still have a pretty good record for where a given error case could originate from.
Especially when they forget to properly handle an error case among the litany of if err line noise, and you get erroneous code execution with no record of it!
This is why stack traces exist. But I agree Java seems to not really have a culture of “make the error message helpful”, but instead preferring “make the error message minimal and factual”.
For what it’s worth, the rise of helpful error messages seems to be a relatively new phenomenon the last few years.
And that's why you should have multiple appenders. So in code you write "log.error("...", exception)" once, but logging writes it in parallel to:
1. STDOUT for quick and easy look, short format.
2. File as JSON for node-local collectors.
3. Proper logging storage like VictoriaLogs/Traces for distributed logging.
Each appender has its own format, some print only short messages, others full stacktraces for all causes (and with extra context information like trace id, customer id etc). I really think STDOUT-only logging is trying to squeeze different purposes into one unformatted stream. (And Go writing everything to STDERR was a really strange choice).
This is the kind of scenario that is served better by Go/C-style error values than exceptions. Error values facilitate and encourage you to log what you were doing at the precise point when an error occurs. Doing the same with exceptions idiomatically often requires an exception hierarchy or copious amounts of separate try/catches.
The difference really becomes apparent when trying to debug a customer's problem at 3am (IME).
That is great for you as a developer. As a sysadmin supporting other people's crap, stack traces and heap dumps are useless beyond forwarding them to the vendor.
I would believe you, except that it is a problem with every Java app I have supported, and there are people in this very thread defending it.
I do not want a stack trace unless I specifically request it. I am not a Java developer, 10 pages in less showing names of packages I don't even know what they are is not useful. It just muddies the water so that it's much harder to make sense of and spot the relevant line; assuming there is a line that actually states the error. I shouldn't need to know what all those packages are in order to figure out why Confluence crashed again or stopped sending emails.
When you are administrating so many Java applications, you should investigate an hour or ask your favorite AI how to configure the logging library used in your application of interest. They allow you to remove stack traces and lots more.
I think the point is that some start with an advantage when it comes to earning merit because by luck of birth they were born to parents with a lot of wealth.
I don't think you can have a truly meritocratic system unless everyone starts on a level playing field with the same access to resources. That is not a system that exists anywhere on this planet.
only if you twist what you mean by meritocracy to mean equality.
Why don't you apply that exact same argument but to sports and athletics? People born with superior genes do perform better (ala, tall people in basketball).
Merit doesn't mean everyone starts at the same spot. Merit means your outcome is determined by how good you are at it - no matter how you get to become that good.
I have had the opposite experience living in the south. The cars with the most bumper sticks around here are owned by conservatives. Today I saw a truck with a US flag in place of its tailgate, "I back the blue" painted on the rear windshield, a Trump sticker, a sticker that said "Don't steal! The government hates competition." and more.
See the loop?
reply