hn_acc_2's comments

Can anyone translate this for me? This sounds like someone throwing a bunch of big words together to me.

I don't have a Nature subscription but this seems like another non-study, 80 adults in a contrived experiment with flashing images then given a "questionnaire" with which conclusions are drawn...

https://en.wikipedia.org/wiki/Jewel_Voice_Broadcast

Nobody writes performance-critical code in pure python.

Not sure how "tooling" is bad, what would you say is limited there?

Package management, again, what package management problems are unique to Python? Many people say this but it seems the problems they bring up are not unique to pip or the python ecosystem, same problems are found with rubygems, npm, Maven, etc...

Maintainability is a responsibility of developers and not a programming language, and unmaintainable code can easily be written with any language. However I'd argue Python should score positive points for maintainability; one of the languages I feel most comfortable picking up old code from someone else and groking it easily.

But as a general rule, the programmer will have a hard time "outsmarting" the compiler by using different objects or abstractions.

Compiler authors have spent many hundreds of combined hours making C code run as fast as possible, and optimizing the switch statement is something they've most certainly done to death.

I.e. if your control flow is switch-case-like, use a switch-case.

All of the moonshot projects are done at the direction of executive leadership in the hopes to open new profit streams.

In fact some of the more technically promising projects (like Servo) had their whole entire team laid off recently to "refocus" on more of these executive-sourced profit grab moonshots

I still use it with a super oppressive jail time and few retries, with a few whitelisted IPs and it seems to work ok.

1) Costs were not zero for the re-release. The only version of the game data (stats, items, enemy spawns etc.) was in the form of an original database backup (from an old employee's personal stash!). Classic runs on the modern WOW engine, so work was required to shoehorn the old data in and reimplement systems and interfaces which don't exist in the current WOW engine.

2) Before Classic's release, by far the most vocal crowd making demands of Blizzard were shouting their slogan "NO CHANGES". I really don't find it surprising that Blizzard has not made major changes since the majority of the player base requested as such...

So too do students with authority issues enjoy exerting newfound power over the authorities they oppose by complaining to their risk-averse boss.

The best you can hope for after a "hold the eff up" rewrite is for everything to keep working the same "but it's more hardened/scalable/modular/blah blah", and the worst you can hope for is to screw up some critical business process while the kinks are worked out.

Also, there is rarely any incentive for anyone from Joe Developer all the way up to C level to even call for this in the first place.

Of course someone can roll their own crypto, if they've a willingness to study and internalize the concepts, have a commitment to doing it right, and spend time doing things like "Make it bug free. Test, test, test. Prove what you can. Be extra-rigorous".

The whole point of that common advice is that the overwhelming majority of developers have none of those things and it would behoove them to lean on a library instead.

Some valuable pieces of advice I've heard:

1) Owning your work is important.

2) Because few people succeed the very first time, waiting for The Good Idea (TM) to come to you before getting started is foolish. The more effective strategy is to keep trying different things that play to your strengths and learn as much as you can from repeated failure.

3) Try to develop an internal motivation to complete projects and avoid talking to others about your projects for validation. The very act of mentioning your next Thing to your friends can have a powerful demotivating effect, because it tricks your brain into a dopamine response as if you actually already did the Thing [1]

[1] https://berkeleysciencereview.com/2013/04/when-telling-other...

However I am confident based on previous events that BCH prices will trend strongly downward when news of the next successful 51% attack is released.

The potential losses are huge (especially for exchanges etc.) from double spend attacks, and the value of a cryptocurrency is very much dependent on users' confidence in its resistance to attacks.

You could pay $384k to hire miners to 51% attack BTC right now (that is, if NiceHash had the capacity). If you cut the hash rate that much the cost would be only $400 or so.

Does it sound like a secure trustless currency if anyone can pay $400 to gain 51% majority?

EDIT: 51% attack != rewrite blockchain

However there are obviously diminishing returns for such an attack. The alt coin value drops drastically when users find out about the attack and flee to more secure currencies.

For Bitcoin to continue to act as a decentralized currency ledger (with "settlement assurance"), then the network hash rate must remain high.

Nobody is arguing that the code couldn't run on one processor, only that cryptocurrencies conceptually depend on this high hash rate

But it shouldn't be a surprise that it's not the best choice for the most developers. Every moment you're debugging and improving the engine is another moment you could have been working on the game itself, because almost all engine improvements are orthogonal to improving the game experience.

So given a limited amount of time, you will always end up with a better and more complete game if you start with a batteries-included engine than if you roll your own.

Also the fact is most peoples' game ideas are very derivative and it would be overkill to reinvent the wheel by implementing your own engine for, say, a game that'd easily be made in Game Maker Studio