They make many useful websites unusable though. And when you whitelist you're then vulnerable, because there's no way to know some Javascript doesn't contain an exploit (do you run anti-virus on the web pages you visit?)
Any downloaded executable might contain a virus. That does not mean that I'm not going to download anything from the Internet. But also I'm not going to run every executable that happened to load in my browser.
Good websites take a great care to protect their users from malicious scripts. So you should use your own judgement to decide whether you trust that website or not.
I definitely don't trust some random website that I've opened by following some links. So I'll browse it without JS and if it does not work, I'll think twice whether I want to risk opening it. But if I'm opening something like stackoverflow, probably I'm safe and they won't run side channel attacks on my computer.
Your examples are garbage logic because array overruns are so harmful that they should be hard errors. Of course, this requires a runtime cost, that can be elided in most cases by the compiler's optimizer. But even low level languages nowadays can be safe by default (see Rust) - the unsafe behavior should always be a conscious, well studied decision by the developer.
Sometimes it's not worth to optimize too farther from the current local optimum. UI designers have a "budget" for weirdness and unfamiliar conventions and must spend it wisely
Also, if you rely on a third party to do identification for you, you simply don't need a blockchain.
Blockchain is heavily constrained by the vital requirement of not trusting any third party whatsoever. If you relax this, you can build much simpler systems that are equally secure regarding non-repudiation and other properties but doesn't need proof of work.
Blockchain has one genuine purpose: value transactions where you can't rely on societal legal framework, nor do counterparties trust each other. "Silk Road".
In some sense it's the contrary.. the typeclass hierarchy has a lot of idealism that won't fly in Haskell's comparatively pragmatic Prelude (DivisionRing? Really?)
They even backtracked their version of IO, that used row types to track effects - because it just wasn't worth it.
For me personally using something heavyweight and bolted-on like GHCJS for Purescript's typical JS-replacement use-case's seems to be a far worse option. Even if Haskell is more mature and refined as a language. Particularly the real world production examples of GHCJS-backed apps I've seen people post on /r/haskell have all been bloated, slow, non-web standard, and obviously designed by backend programmers not designers/web developers... so I may be biased. Although that stuff has as much to do with community as it does technology.
But you have to admit there is some utility in designing a language from the ground up to target browsers.
I’ve never understood the OCaml and Haskell people’s obsession with creating half baked JS generators that produce less than great web apps. And I completely get the backend guys desire for a proper language when they are forced by their companies to do web stuff. But that cross platform stuff has repeatedly been an unfulfilled pipe dream. Not only JS to mobile but systems/server languages to web.
I’ve been looking for a proper functional and typed replacement to JS for years and Purescript is the only one I’ve seen that is close to being as good as the Vue/React apps I get paid good money to develop for a living. https://lumi.com is a good example of a modern web app being built by the main PS creator.
I’m hoping one of you smart Haskell people solves this problem before I get old having to use JS.
> Purescript is the only one I’ve seen that is close to being as good as the Vue/React apps I get paid good money to develop for a living.
Purescript is a language, are you saying that the language itself allows for creating View/React apps without need of a framework? Or do you mean that there are native (in the ecosystem sense) Purescript UI frameworks that allow one to create View/React apps without depending directly on JS ecosystem to handle the UI?
Wonder how PS compares to OCaml/BuckleScript wrt to generated code size (the latter is absurdly tiny somehow, just incredibly efficient on that front).
