You can mock the RNG. You don’t need to test/prove it’s random, you need to test your code which is not random.

unit tests are notoriously bad about testing n>2. I just ran into a problem with sorting recently that was caused by buggy comparators, but it didn't bubble up to the tests until the runtime switched to a different sort implementation. Most of the tests were doing n=2 so it was not visible under the old runtime version but was under the new one. This has been broken in production for months if not years. If the test had used n=5 I'm pretty sure the old tests would fail as well.

I don't understand what's so hard about this problem - if you have a platform that's impacted by bots and scalpers, and if you want to do the right thing, or give the appearance of doing the right thing with almost no cost to yourself or your business, you should release your product in a fair lottery with reasonable purchase limits.

You have plenty of time before the product is released to register and verify everyone. You completely avoid traffic issues. Accounting is easy - you'll sell out when you run the lottery. You'll build a reputation for releasing inventory fairly and without causing undue stress on your customers, and avoid the suspicion that you're in cahoots with the scalpers (looking at you, Ticketmaster).

I'm accustomed to stressing out over concert tickets and struggling to get gaming consoles, and have a deep hatred of scalpers and the platforms that enable them, but I had no idea that scalpers were ruining the educational/hobby markets too. That seems really low.

What about stuffing the lottery box with countless bot-created accounts entering the lottery?

You'd have a lot more time to find and boot them prior to running the lottery. Assuming you didn't/couldn't detect them, at least you spare your users the anxiety and inconvenience of the on-sale while they get screwed.

You can build very fast reloading yourself, easily. If I'm smart with persisting state on the client, I find I don't really miss "hot" reloading.

Management often already got a deal or has worked their tech choice into a financial projection.

Sometimes, they are even right. And "I told you so" rolls downhill.

I can't even begin to imagine the bubble you must live in to ascribe words like suspicion and cowardice to someone clicking a button on a forum even most software developers in the world have never even heard of.

You could try. I'd assume it was downvoted by folks who perpetuate said double-talk. If there was a defense, they'd have articulated it. But, since anonymous downvoting is easier and less risky, that's what happens. Silencing the discussion about downvotes is a meta downvote that we shouldn't accept just because it's in the guidelines.

That's only because you broke the guidelines and commented to create a generic tangent.

My edit to ask about why I was being downvoted is based on curiosity - a key pillar of this site. If people have a divergent opinion strong enough to downvote, then I would like to read it to understand more. Furthermore, my comment was not about comment voting, but about identifying and understanding that opposing position.

I out, since it seems you're just trolling on a tangent instead of commenting on the pertainate topic.

I'm trying to improve discourse by fighting against the downvote. It's my opinion it harms discourse significantly. It's low signal, and not constructive. It has an obvious chilling effect on dissent. Nothing upholds echo chambers more than the downvote.

Just to add on to this - remember the first time you saw syntax highlighting? And before that, the code was all in one color? You didn't know you needed it before, but you didn't go back, did you?

Yes, yes I did. As fast as humanly possible.

Syntax highlighting seems to help most people but I find it a horrible impediment to reading code.

I think you're in a tiny minority but I'd love to hear more about how it impedes you.

It's very easy to get wrong. Often, the syntax categorization itself is wrong because of parser issues (it's hard to get right in C IDEs. Java should be fine here).

Then, it's a question of what should be emphasized. Many syntax highlighters emphasize syntactic structure too much, making it hard for the programmer to concentrate on the content. I use Visual Studio for example, which is relatively unobtrusive (pastel colors) compared to e.g. the typical VIM color schemes. Visual Studio will color macro names, function names, variable names all in different colors - roughly purple, bronze, black. I just noticed it even colors function argument variables different from global variables/functions and member names. I don't think that's helpful for reading code. It's a distraction.

I certainly often find it distracting - it's notable that e.g. elvis' default highlighting, which mostly just slightly bolds {} and () and similar, doesn't bother me at all, though I get most of the same advantage out of 'showmatch' in vi.

(see my sibling comment for the fully verbose version)

So, most highlighting stuff frankly comes across to me as more like https://kassandry.net/misc/english_syntax.jpg than anything else - highlighting trivially inferrable structure at the expense of overall comprehension (note this entire comment is written under the assumption whatever the highlighting is doing it does perfectly, "bugs exist sometimes" is of course both trivially true and not the point).

Gentler colour schemes and things like e.g. rust highlighters that use a colour per lifetime are interesting and certainly I'm less likely to go out of my way to disable those.

The big problem I have though is that they are, by nature, highlighting at a specific granularity, and I'm generally not reading that way. My conceptualisation of code as I'm reding it jumps between the symbol, expression, statement, block, function, class levels all the time and it's very easy for the discontinuity when my granularity just changed and the colourisation didn't to snap me completely out of flow. Which is clearly an oddity of my brain, and unfixable absent focus-follows-mind, so oh well.

An interesting thing I've noticed is that having the code visually be a single artifact rather than heavily distinguished individual syntax artifacts means that I can often skim a file of code, have a "wait, that looked odd" moment, and find a bug that was completely unrelated to anything I was currently doing but had been hiding in there for quite some time - so, I mean, yes I'm weird, but there advantages to having one of this sort of weird around for review and debugging.

I agree I'm very much in a minority though I've encountered rather more (albeit still relatively very few) people who've found that synhi is helpful when -learning- a language, then when they're familiar they prefer turning it off at least some of the time to take advantage of the gestalt effects I was talking about.

This leads me to suspect that there might be people who'd enjoy this approach some of the time, later on, but never find out because it does absolutely take a while to get used to so "always use synhi" is a local maximum they don't escape - though even if my suspicion is correct, I'm making no claim there'd be that many people in that category either, just 'some'.

Certainly I've suggested to a few people over the years to try going without for a few weeks if they're curious, and of the ones who've tried a non-zero percentage have ended up either 'sometimes synhi' and at least one joining me in 'basically never synhi' - but they were all already experienced devs and weird enough to be willing to try it in the first place, so there's obviously going to be selection effects there.

It would be absolutely fascinating to run studies on a bunch of this - especially the "which bugs are easier to spot in which situation" part - but for the moment all I can really say is "yes, I'm definitely an outlier, but anecdotally sometimes usefully so".

(excuse the wall of text but hopefully it's enough to give you some idea)

You should ask that question in the Go and Plan 9 forums.

Hmm come to think of it cigarettes are actually a social network of sorts. At least in the beginning :)

they create the need for breaks from anything from work to recreational activites, and provide opportunities for interaction with like-minded humans. I'd say that qualifies, and although I never liked smoking and am grateful to have dodged that bullet, I always envied the natural icebreakers that smokers had when stepping outside of a place to smoke with random others.

I started smoking for this reason and considered it a benefit at the time. But after quitting you come to realize that the camaraderie is covering up the fact that you're all out there killing yourselves instead of doing something better with your time; and you need to find other smokers because everyone else can't stand the way you smell.

Replace that spot where you go to smoke with a foursquare court and dare your boss to tell you you can't take as many foursquare breaks as the smokers get. Foursquare is fun and you and your group will invent your own rules and it'll turn into your own game that's way more fun than smoking cigarettes. Most places now, you can smoke a joint or a weed pen if you really need the physical act.

There's this idea that if you smoke you get extra breaks - bring it up in a reasonable way with any manager and you can have those breaks, too. And thank the few folks sacrificing themselves so that the rest of us can say we get as many breaks as they do.

Edit: a benefit I miss is excusing myself from an uncomfortable situation because I "need" a cigarette. But, without that crutch, I developed better GTFO strategies.

Don't forget the police playing copyrighted music while they abuse you to stop you from filming them. When the police are ahead of the tech, you know the People are f'd.

And at least when they're playing a popular song with easy to obtain MP3s, you can use gnuradio to cancel that out of the audiotrack.

Yeah, they're being shitty piggies, but we have tech we can use too.