If you are attempting to leak state secrets (as was the case of Edward Snowden) or going up against a powerful state adversary, email may not be the most secure medium for communications. The Internet is generally not anonymous, and if you are breaking Swiss law, a law-abiding company such as ProtonMail can be legally compelled to log your IP address. A powerful state adversary will also be better positioned to launch one of the attacks described above against you, which may negate the privacy protection provided by ProtonMail. While we can offer more protection and security, we cannot guarantee your safety against a powerful adversary."
Another huge plus for source based package managers not elaborated in this article is how easy transformations are [1], so you can rebuild your software with different compilers, dependency versions, source branches, etc. from often a single command.
It seems that these sort of devices are for sensors not generators. Higher QE leads to higher sensitivity according to the article. I would imagine that manufacturing costs would prevent any interest in making solar cells out of such devices.
I don't think multiple exciton generation (which is what you find searching for EQE > 100%) is exactly the same as the photoelectric effect. However, your point more or less stands.
I think this is a great idea for people for people wanting to respect other's sensitivity.
However, I also think that it is even more important for people to respect other languages/cultures by not attributing their own independent negative connotations.
For example when it comes to naming a project, a Swede shouldn't get offended by an English-speaker using "fan" (Swedish swear for devil), and an English speaker shouldn't get offended by a Swede using "slut" (Swedish root for stop/end).
Maybe I'm wrong, but this is a neat service nonetheless.
I'm quite an amateur schemer and have never used Racket, but Christopher Webber's talk [1] gives me the opposite impression and that Racket diverged from the "live system" culture. In my experience Guile is usually pretty good when it comes to updating things on the fly through the REPL, but there are some gotchas.
Funny enough, if you rewrite all of Emacs in Elisp that would superficially seem to make Guile Emacs easier to implement. I wouldn't be surprised if by that time Guile had native compilation and an even better Elisp implementation. Ironically, it would defeat the original intention of Guile extending C programs that was inspired by Emacs, but even the Guile community is starting to lean towards Scheme-only programs with some FFI akin to Tom's ideas.
As a user of both Guile and Emacs this project has always intrigued me, but I think people arguing for speed, multitasking, or configuring Emacs in Scheme or Javascript are missing the point. Guile Emacs represents an ideal where GNU projects share a common library that all benefit from shared improvements. For example, if Guile gets native compilation, Guile Emacs, Guix, and any other Guile project gets native compilation. I would never write my Emacs config in Scheme, but I wouldn't hesitate to call a Scheme library from Emacs, or an Elisp library from a Guile project. Guile Emacs would be a huge step unifying all of these separate GNU projects from both a technical and social point of view.
I love this kind of stuff, but the barrier to entry just seems so huge.
https://ocaml.org/learn/success.html#FFTW