HN user
My question was why is a proper MAC better than appending a checksum to the plain text and then encrypting. With an appended and encrypted checksum, the system could easily reject corrupted messages, that's the whole point of a checksum in the first place.
So why is a proper MAC better than appending a checksum or hash to the plaintext and then encrypting? Or maybe I am misunderstanding something?
But if someone chooses a ciphertext (without knowing the key), how could they get the checksum right (which is also encrypted)? If the checksum was wrong, the system would refuse to decrypt the corrupted message.
Why is a proper MAC preferred over simply encrypting the plaintext after appending a checksum or hash.
His reasoning is actually quite flawed. Even if you believe there is somehow a black and white $7.7 trillion value difference between candidates, betting on such long odds still isn't rational.
If we assume (using numbers from the article) that a vote costs $20 (an hour of our time), the odds are 1 to 10 million, and the payoff is $7.7 trillion (even though it's the country getting the benefit, not the voter) then the Kelly criterion* implies that it's only rational to vote if your net worth is more than $200 million. Somebody making $20 an hour probably isn't worth $200 million, and so even if voting did have a positive expected value, it's not a rational strategy.
TL,DR: There is more to betting strategy than expected valve, and no rational gambler takes a bet with 1/10 million odds for $20.
Not sure if I am understanding this correctly. By bootstrapping, do you mean C does only the most basic syntax parsing, and then a fexl script (written in a basic fexl subset) does the more complete parsing?
All this stuff is really neat. Your C code interface looks quite nice and clean. I hope you release some source code soon.
And thanks for taking the time to write all this. Even though a lot of it is over my head, it's quite interesting. I'm really looking forward to playing around with it a bit and learning.
It sounds like you're having a lot of fun with it.
I think a C implementation would be better anyway. C is the common denominator between almost every language. Have you already done the foreign function interface to C?
When do you think we might see either source code or a live web demo to play with?
For a web demo, couldn't you just add a quick CGI interface to your C program?
I'm not trying to rush you or anything. Just want to let you know that at least one person is still looking forward to seeing it.
Great! I'll be looking forward to it. I kind of have a thing for small languages.
This is probably a stupid question. If you have Fexl written in Perl now, what are the chances of just throwing a sand-boxed interpreter online for people to play with? I'm thinking just a form with an input field and a submit button which runs the script and displays any printed values.
Is Fexl open-source, or even available for download? It looks pretty neat.