No, only broken when used out of specification. RNGs have a lot of uses, not all of them related to cryptography. Generators suited for cryptography could be extremely unsuitable for other uses. Take for example the ISO-C random function. It is specified for reproducibility. There is even a non-mandatory recommendation to because they saw a use for a generator that behaved the same way on a variety of systems, for example when implementing sprite behavior in games.

If you implement cryptography and uses a RNG that isn't specified for it then it is your code that is broken. It's like using a CRC designed for sequential data when communicating over a framed protocol like RS485. It isn't the one implementing the CRC that is to blame, it is the one who applied it incorrectly.

We are using JavaScript for performance critical code and I can confirm that it is the most buggiest, immature technology by far that I have ever seen in my 30 years old carrier. Every second month there is a new browser version for each browser, each with a different set of new critical bugs. We even find JIT compiler bugs regularly!

I simply do not understand why they do not take the free, open source, mature, very fast Java virtual machine, and let the browsers run Java bytecode directly, and let software engineers chose any programming language which best suits their task.

Do you have some realistic examples?

Also, approach-ability by "random" developers sometimes trumps something that's more flexible but requires more experience or a learning curve. Staff changes such that we often have to target "middle brow" abstractions.

In my line work, the coder maintenance effort is usually more of a factor than client-side-browser speed/memory, or even server side for that matter. Whether (good) OOP is inherently more resource intensive than anonymous function prototypes remains to be solidly proven. It may depend on coding style.

As far "simpler to parse", if that were the main factor, we'd all be using Lisp. Being human-friendly and being machine-friendly are not necessarily the same thing. Machines are generally cheaper than humans (code maintainers) such that economics often favors being human-friendly over machine-friendly (speed/memory). What I personally like is another matter; I'm paid to make my employer's org more efficient. (The database is usually the bottleneck, not the application, I would note.)

In short, I question how you are weighing the factors being compared. I agree that different niches emphasize different factors, but in general an application language (or usage) should favor humans over machines when you look at the total economics involved. Unfortunately, JavaScript is often being used for application development AND systems software (OS-like services and low-level libraries). One-language-fits-all is a tall order, and probably in impossible order if we want to optimize the language design for its actual usage patterns.

The 'crimes' in TX are bullshit the ones in WA were not (though the stop may have been bullshit). You knew you weren't supposed to be driving. WA has good public transportation in a lot of places and many areas are walker or biker friendly. Getting rid of a car will save you a lot of money. I didn't get one until I was 30. I wish you luck in your lawsuit against the Municipal Services Bureau and TX and thank you for reaffirming my desire to never move to TX.

Let them start with the double jeopardy they call the "Texas driver responsibility program". Pay a ticket, then also an exorbitant surcharge to the "Municipal Services Bureau" which is a private company. If you don't pay the surcharge, the private company suspends your license until you do... You pay the surcharge just for getting the ticket, whether the ticket was dismissed or not.

Like I said double jeopardy.