So the time of military US protection is behind us.
4,496 karma · joined April 1, 2015
So the time of military US protection is behind us.
> However, another brain region saw lower volumes – suggesting the impact cannabis has on the brain is complex and nuanced, requiring further investigation.
This is the problem with any kind of censoring media. The initial intentions of those policies might have been good, but these kind of policies can so easily be abused for malign intentions.
- in a corporate environment, your code is going to be read by many other people than just you. Your team mates, the guy after you left etc.
- also, by making your code more readable, you're making your own life easier as well. You might have thought at first that your code was fine, but by structuring it properly and possibly removing some redundancy, you might find that you were overlooking some things.
yes I agree. In case of APL, if your readers are mathematicians, I guess it could well be the language of choice.
And yes like I already said, self explanatory code is not always possible but more often than not it is. It just takes a little extra care and thought.
I guess that might be true for APL, for other programming languages that's not true at all. The ideal program is clear enough to be self explanatory. Of course there might be some implementation choices that need a comment. Or in some cases the problem is so difficult that this is not possible.
But readability should be the goal and most of the time this is feasible without comments. E.g. by using descriptive variable and function names. And by breaking up your program into logical and cohesive parts, using functions, objects, modules or whatever construct your language is offering.
I had an introduction to APL in university and what I absolutely hated was this terseness. I guess when you're a mathematician APL is more natural but to me, as a programmer, I much prefer to have some extra verbosity to make my code more (human-)readable.
> Yet on Kalshi, a CFTC-regulated prediction market, traders have wagered vast sums on longshot contracts with historical returns as low as 43 cents on the dollar.
On prediction markets traders can bet both sides. E.g. on Polymarket I can currently bet that Greenland will be acquired by USA before 2027 and get 4:1 odds: or I can bet that this doesn't happen, and give 4:1 odds. If these odds are off, doesn't this mean that one side gets a bad return on investment, however the other side gets an equally good return?
On balance the average return on investment by traders should just be 100 cents minus the margin of the prediction market, which tends to be only a few percent.
Is the reliability of Polymarket predictions overhyped? Sure. Is there manipulation of Polymarket odds by some people? Most likely there is. But to say that this is a disaster that America is walking into is nothing else but clickbait.
Well that depends heavily on how you define successful. Successful in life? I would tend to disagree, unless you believe that career is the only thing that counts. But even when career is concerned: the most successful people I know went on from being developer to some high end management role. The skills that brought them there definitely did not come from hanging out with other engineers talking about engineering things.
I'm not sure I agree with that. Right now as a senior my task involves reviewing code from juniors; replace juniors with AI and it means reviewing code from AI. More or less the same thing.
However this is only a small portion of my daily dev work. For most of my work, AI helps me little or not at all. E.g. adding a new feature to a large codebase: forget it. Debugging some production issue: maybe it helps me a little bit to find some code, but that's about it.
And this is what my post was referring to: not that AI doesn't help at all, but to the crazy claims (10x speedup in daily work) that you see all over social media.
The difference with the zillion others who did the same, is that he attached a link to a live stream where he was going to show his 10x speedup on a real life problem. Credits to him for doing that! So I decided to go have a look.
What I then saw was him struggling for one hour with some simple extension to his project. He didn't manage to finish in the hour what he was planning to. And when I had some thought about how much time it would have cost me by hand, I found it would have taken me just as long.
So I answered him in his LinkedIn thread and asked where the 10x speed up was. What followed was complete denial. It had just been a hick up. Or he could have done other things in parallel while waiting 30 seconds for the AI to answer. Etc etc.
I admit I was sceptic at the start but I honestly had been hoping that my scepticism would be proven wrong. But not.
Anyhow, I argue that investors are positive for the the house market. They shouldn't be banned. Investors provide enough liquidity to the market so that the building companies have enough certainty to invest in large housing projects, because they know that their properties will be sold quickly. If investors would be banned they would sell their houses eventually as well but it would take much longer.
Similarly, investors improve mobility and throughput. An individual putting his house for sale will find a buyer much faster when investors are in the buying market, who are willing to buy up a house when nobody else takes it and sell it for a better price later. So: sellers sell faster, so they can move out and buy a new home faster as well: mobility in the house market increases.
In IT terms: investors function as a buffer.
Earlier you were arguing that investors were acting as marketmakers and now you say this. Marketmakers make their profit from the difference between buying and selling some asset. They don't want to hold prices, they want turnover. If investors really are acting as marketmakers it's actually a good thing because marketmakers have the effect of adding liquidity to a market.
It was even already mentioned in the famous Design Patterns book from the GOF in 1994.
It's worse than that. It might not be you who has to debug it, but someone else. Maybe after you left the company already. Maybe at 3AM after a pager alert in production ..
The correlation seems to point to usage ground water that is contaminated with pesticides. So people living close to the golf courses have higher Parkinson risk. Probably golfers and employees less so.
E.g.:
Proximity to golf courses where pesticides are used -> Parkinson: https://news.ycombinator.com/item?id=43933580
Farmers using pesticides have 60% higher Parkinson risk (2019): https://nos.nl/artikel/2302396-landbouwgif-kan-kans-op-parki... (Dutch)
Parkinson should be labeled as profession-linked disease for farmers(Swiss): https://www.srf.ch/news/schweiz/pestizide-als-krankmacher-pa...
And what do you have then? 300 tests that test the behavior that's exposed by the implementations of the api. Are they useful? Probably some are, probably some are not. The ones that are not will just be clutter and maintenance overhead. Plus, there will be lots of use-cases for which you need to look a little deeper than just the api implementation, which are now not covered. And those kind of tests, tests that test real business use cases, are by far the most useful ones if you want to catch regressions.
So if your goal is to display some nice test coverage metrics on SonarQube or whatever, making your CTO happy, yes AI will help you enormously. But if your goal is to speed up development of useful test cases, less so. You will still gain from AI, but nowhere near 90%.
When he finally became head of the government, in 1933, that violence immediately became much more official: the SA was officially deputized as 'Hilfspolizei' and attacks on e.g. communists became legalized. In that same year the first concentration camps were established.