Hacker News new | past | comments | ask | show | jobs | submit | wbl's comments login

Oh no. What the article describes ends up with a real mess. If you set out to support a certain language you'll have a global view of how things should fit together, and what the implementation should do.

It's not enough to have a nicish abstraction, how did it work in practice and eek out performance? I've heard Bryan Cantrell say there wasn't much there and would be curious to really know what the truth is and more explanation on both sides.

The completion is a click away. If you can't deliver enough value for people to change the defaults or go to your site are you really doing a better job?

This is Soviet propaganda. The real number from Nagasaki and Hiroshima was about half of the casualties were instant. Furthermore fallout is much more understood: after a few short days of hiding inside, the radiation levels will have fallen to where normal life can largely resume without fear, reducing the number of slow casualties.

Do you have any sources to back these claims? Also, what specifically do you mean by "half the casualties were instant"--is it that "of those who died, half of them died instantly" or "of those killed and injured, half of them received their injuries instantly". Or is it some other thing?

I think you're falling into exactly the sort of trap I was talking about, that the enormity of the devastation is so unimaginably great that it's difficult to imagine what it would actually be like, and to (somewhat lazily) conclude "well, it'd probably be instantaneous". But, for example, this analysis doesn't support that idea at all: https://thebulletin.org/2020/08/counting-the-dead-at-hiroshi...


Your source says "most died on the day of the attacks, and all within a few months". Your source also says that cancer rates are not as high as commonly believed.

Right, so not instantaneous? Or is this also "soviet propaganda"?

As instantaneous as arial bombing generally.

In Scandinavia we're still sending samples of hunted wild boars to check for cesium. Large parts of Belarus are quite contaminated and the local tyrant is the reason we know very little about how it affects the population in those regions.

In order to say Apple is a monopoly you need to define a very narrow market. The search market is obviously relevant and very dominated by Google.

Google claims their in the ad market. Not the search market.

At 48 volts arcing shorts aren't the concern.

The same government that is prohibiting construction of the transmission lines to move that power to where it would be used?

I have a little experience on this aspect. There are tons of local governments who weigh in on the location of these lines and that can be a contentious process to get buy-in from them.

50 requests/sec? Did you forget a few zeros?

Little’s law is a bitch, and you can get away with a little throttling but not much.

Also, that’s a bit dismissive for HN.


Almost none: ANSI was over 30 years ago and enough of an improvement people switched. If you mean C89 then yes, loads of it.

It helps there are automated tools for converting old style K&R function declarations to the new ANSI/ISO style, like protoize.

But K&R C is now so dated, protoize was removed from GCC 4.5 and onwards. When (in a bout of idiosyncrasy) I wanted to convert some ancient K&R C to new style a couple of years back, I ended up putting GCC 4.4 in a Docker container to make it easier: https://github.com/skissane/protoize


T_PAAMAYIM_NEKUDOTIM, mysql_real_es ape2, parse_str, etc.

> mysql_real_escape2

Blame MySQL for that name, not PHP.

https://dev.mysql.com/doc/c-api/8.4/en/mysql-real-escape-str...

(And, if you're doing modern PHP, it's just PDO->quote().)


I'm not certain about OP's objection but for me it's less the function name and more the terrible history of how PHP tried to automatically fix SQL injection and instead made everything a thousand times worse. If you're not using bound parameters for user data you're taking a huge risk and making your life multitudes more difficult. PHP's PDO is by far the better option at this point but it suffers from poor enough usability that I've built my own wrapper for it at two different companies.

> the terrible history of how PHP tried to automatically fix SQL injection and instead made everything a thousand times worse

Are you thinking of stuff like magic quotes? mysql_real_escape is not part of an automatic anything. You manually use it to quote each value.


Writing a wrapper for PDO is standard operating procedure for various good reasons.

Why should I blame MySQL? It's the PHP developers that decided to introduce it and not change the name, plus have several functions that don't do the right thing as well.

This hasn't been an issue for like fifteen years or whatever.

In hindsight I think it's a good thing, it's a pea that keeps princesses at a distance from the language.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: