I think this is a fair question. In my opinion, if you're developing a larger application then nearly all of your code will either be in the "racket" language. If you're keen on types, substantial fractions of this may be in the "typed/racket" language. It is true that all of the languages share a common substrate, and they can more or less all interoperate, but it's definitely not the case that a programmer would be likely to break their program into five equal pieces and use a different language for each one. You'll probably write your docs with scribble. Using different languages allows you to have a fundamentally different programming model, and while having that as a backdrop made things like the development of Typed Racket feasible, it isn't something that should prevent you from starting.
TL/DR: Just use Racket. If you find that you really wish that you had some other feature or style of programming, you can investigate whether there's a language that already provides that.
Interesting, looks like Ben Greenman started work on a port to Racket, but it does appear that that work is still firmly WIP: https://github.com/bennn/mechanics
I think it's probably more productive to think of this in economic terms; "nonchalance toward optimization" <-> "I can write this code in an hour instead of three hours". And, from a company's perspective: "I can get this code running acceptably at 1/3 the dev cost".
I think the poster is referring to racket-lang.org, which is served through cloudflare. But wait! I have a solution. If you want the web site content locally, the whole thing is built from the public repo at `https://github.com/racket/racket-lang-org`. The readme contains instructions for building it locally. The CSS on the local blog posts probably won't render correctly, but if you're reading the text, that probably won't bother you.
No, it's clear that the researchers are using the term trapdoor in a technical sense. Specifically, one of the key ideas in the swiss system is that it produce a proof that the votes produced as the result of the "shuffle" operation have the same meaning as the votes that are provided as inputs. The easiest "proof" of this would simply be to publish the input votes... but that would defeat the whole purpose of the shuffling. Instead, the Swiss system appears to involve a trapdoor commitment that produces a non-reversible token (hence "trapdoor") that could only be generated if this is a legitimate shuffling. As I read it, this is much like (for instance) a SHA-256 hash of an input message that can be generated to ensure that a document has not been tampered with.
Okay, this is going to sound mean, but this is like the definition of p-hacking. When you look at 30 values, you simply can't be surprised that one of them is lower than the mean, with a p value around 1/20th. Use something like a Bonferroni correction, to get a significance level of 1/600. Does the result still stand up? In fact, there's an xkcd about this very topic. https://www.xkcd.com/882/
No, I think that the socratic method can be much more intensely infuriating because it's clear that the teacher is withholding the answer from you. (FWIW, I use the socratic method a lot... so I'm definitely familiar with students getting mad at me.)
(Mostly just hoisting Noel Welsh's comment to the top level) How will the expected upcoming move of Racket to the use of Chez affect the comparison between Gerbil and Racket? I'm trying not to set my expectations too high. BTW: RacketCon! This weekend!
I'm afraid I literally laughed out loud at your request for a simple standard algorithm for r5rs macro systems. However, it's a sympathetic laugh. Macro Hygiene is still very hard, principally because (I claim) there's not yet a clean and widely accepted model for it. Matthew Flatt's "sets of scopes" model is (IMNSHO) the current leader. Time will tell whether he or anyone else comes up with a simpler and more widely accepted model. But yes: as an implementor, it "feels" very heavy, and you keep thinking that there must be a simpler solution to this problem (aside from just throwing the problem out and giving up on hygiene and language composability).
You're right that the image is just one source of data. But... that's true of any one source of data. This data doesn't prove anything, it just contributes a bit more evidence (to an already enormous pile...).
Ditto, except that I just use postfix's 'virtual' mechanism. Simple additional hack to simplify address creation; all my legal addresses begin with a particular 4-char sequence, and by default, all email addressed to a uid beginning with these 4 chars gets through unless explicitly blocked. This means I can make up addrs on the fly, without having to add them to the back-end on a per-address basis.
One data point to the contrary; I subscribed, and I can now view the site without ads. ObDetails: I use ghostery, and I don't block Google Analytics. All other trackers blocked, according to Ghostery. I do see Ad Council ads.. things like Smokey the Bear. I don't find those problematic.
Wow; I really disagree with this viewpoint. I want clever compilers that produce good code from high-level specifications. I fully accept the lack of predictability.
Also, your comment that "everyone gets what they deserve" suggests that those who write high-level code (e.g. using pow() to square a number) "deserve" to have slow code. That's a strange moral outlook.
Looks like another poster mentions "https://meet.jit.si". Ran a 10-second test, and it looks like it can successfully display my face. Haven't tried it for actual communication.
There are some very helpful folks on Stack Overflow, but the racket-users mailing list is definitely the authoritative resource. Also, Neil Van Dyke (the package's author) is helpful and responsive.
TL/DR: Just use Racket. If you find that you really wish that you had some other feature or style of programming, you can investigate whether there's a language that already provides that.
All of this is my opinion, of course.