- Indeed, even writing this utility in C is trivial and has 0 extra dependency for a pure C/C++ project. Avoiding #embed also removes the dependency to a C++23 capable compiler, which might not be available in uncommon scenarios.
- well I'll be that guy... If you're going to disturb the normal way of righting expressions, RPN or prefix notation (AKA Polish Notation) could be a better option. Both don't need parenthesis because they don't need precedence/priority rules - which are obviously a disadvantage of the infix notation.
The HP 48 famously took the bet of going against the mainstream notation. I wonder to what extent this is one of those "accidents of history".
RPN moreover simplifies parsing, as shown by the Forth language.
Prefix notation, as used by for instance Lisp, doesn't actually need parenthesis either; Lisp uses them because it allows extensions over basic operators and more generally "variadic" operators and functions (e.g. (+ 1 2 3 4)). Without this "fancy" feature, prefix notation is unambiguous as well: / + 1 2 3. [1]
On a side note, Smalltalk is one of the few languages that said "duck it", and require explicit parenthesis instead - which is IMO, not an insane approach when you see that for languages with 17 levels of priority like C, you end up putting parenthesis anyway as soon as the expression is not trivial "just to be sure" (e.g. because it mixes boolean operators, arithmetic operators and relational operators as in a & 0xF < b + 1).
- > Any webpages embedding facebook/twitter/microsoft/google trackers have already deanonymised you
I bet OP has already blocked at least 3 of them. Private browsing is only a partial solution, blocking/unblocking domains, scripts, etc. on a case-by-case basis is a more reliable way to defend your right to privacy against abusive practices (I'm talking about fine grained adblockers such as uMatrix/uBlockOrigin) daily.
I admit it can be a hassle sometimes, in particular if one explores the net every day, but staying away from bad actors (such as some of those 4) is one way to maybe eventually stop them - even if "vote with your clicks" feels as pointless as "vote with your feet" when you're just one in many millions.
- > As a native English speaker, I have learned this watching non-natives try to learn English spelling over the years. It is hell! I studied French in middle school and high school. I remember there being a similar level of ambiguity in their orthography (similar to English).
Yes. I think english is even slightly worth than french wrt spelling/sound mismatches, but you can call me biased. Moreover, William the Conqueror, who brought civilization to England, also brought the inconsistencies of the french spelling with him.
> I wonder: Why not spell check before you send?
Well, some of my coworkers don't either, from french to french. And up to recently in most programs it was a bother to switch back and forth between 2 languages.
But really, that's probably about common laziness; the typos you mention can be caught by proof-reading before sending, which can also catch other mistakes like missing words or inconsistent sentences caused rewrites.
Proof-reading just after writing is not the best tho, as you tend to skip words because it is "too fresh". I try to introduce some time gap between the too (for instance, proof-reading after lunch or the next morning).
- Do you know if the encryption scheme covers metadata? For instance, who sends something to who.
- > Their value is going to stay limited if people don't want to actually use them.
Namely, in the case of PeerTube, content creators. Youtube is convenient because it comes with builtin monetization. You can probably expect loud objections (rightfully so) from some of them if you download their stuff from Youtube to upload it to PeerTube.
If you don't have the content creators, you don't have content consumers and you cannot bootstrap a network effect (some services did bootstrap a network effect with plain and simple piracy, though).
I believe the UX is secondary to available content. People do make the necessary efforts if they think the benefit is worth it.
- Apparently 2 meters is : A 2 meters (6 ft 7 in) high tsunami hit Chiba Prefecture about 2+1⁄2 hours after the quake, causing heavy damage to cities such as Asahi. (Tohoku 2011) [1]
WRT comparison with hurricane waves, I assume they carry a lot less energy than tsunami's, because they are "superficial waves" - caused by the friction of the wind on the water - whereas a tsunami wave is caused by the movement of a huge mass of mater.
[1] https://en.wikipedia.org/wiki/2011_T%C5%8Dhoku_earthquake_an...
- And what does "modern" has to do with it anyway.
- Nope. That's the divine invisible hand of the market.
- On a linux-like system, one could block access using file permissions, e.g chmod a-r /dev/snd/pcmC0D0c for a microphone. Probably less easy to do on Android, though.
- Thanks for your answer. The fact that the legal framework you suggest aimed at preventing abuse doesn't exist already is terrifying, when you think about it.
The situation is also deeply unfair: wealthy students can keep the device provided by the school in a box and use their own instead, while less wealthy students will have to use the school's device and be spied on. "But that's actually a good thing," some might say, "it's always the poor who cause troubles."
IMO, this spyware shouldn't have been there in the first place, even if it means that in some cases it could have prevented yet-another shooting, or suicide, or drug abuse. The school should have the right to inspect the device anytime (when at school, not remotely) to make sure it is not being misused, and nothing more.
More surveillance won't make those problems disappear - actually quite the opposite I believe; because learning that your classmate has been suspended because he said the wrong words when talking to himself but some forgotten microphone caught them nevertheless is really stressing or depressing, depending on your personality.
- I wonder, if the device is equipped with a microphone and/or a webcam, does it mean that the school has the right to remotely activate them for "monitoring" purposes? It not too far from what they did when the monitoring software sent the screenshots of an email that never existed.
And what if he joked about stabbing his girlfriend/boyfriend? Would the school report him to the police? What the police would do in this case?
- I wonder if this minimal cell could be described instead as something between a bacteria and a virus. I am not a biologist, but IIRC viruses penetrate cells then hijack the cell's standard machinery to replicate itself, until the cell explodes; sort of like a DNA/RNA injection exploit.
- > I think the whole message would be more palatable if it weren't written as a decree including the dig on "retro computers"
Yes, and more generally, as far as I am concerned, the antagonizing tone of the message, which is probably partly responsible for this micro-drama, is typical of some Rust zealots who never miss an occasion to remind C/C++ that they are dinosaurs (in their eyes). When you promote your thing by belittling others, you are doing it wrong.
- Summarized translation:
Following the propaganda of the ministry of interior, several articles were published in press about GrapheneOS, which is described as a solution for criminals because it allows to hide things.
La Quadrature du Net [similar to the FSF with regard to defending users' rights] argues that the purpose is of course not cybercrime, but to secure and protect the privacy of its users.
The head of the anticybercrime brigade of Paris threatens of suing the developers of GrapheneOS if connections with organized crime were to be found.
The government has repeatedly tried to extend cyber-surveillance previously. They are trying to use a law designed to fight drug traffickers in order to enforce backdoors in services that use cryptography, such as Signal or WhatsApp, without any success for the moment.
---
So, it's a threat before having a proof. They also mention the arrest of Pavel Durov, who was arrested because Telegram failed to answer legal requests, which was then constructed as complicity with criminals using Telegram, but that's obviously a very different case.
But of course, if they succeed in forcing backdoors, criminals will just use other ways to communicate (doesn't matter if they are legal or not because, well, they are criminals...) or tricks; for instance, back in the day when (analog) phone calls could be wiretapped, they were already using code words. They could use e.g. steganography tomorrow.
But we will be left with backdoors that are an unacceptable compromise on security and privacy. This is a recipe for dystopia considering that far-right parties are getting stronger in Europe, including France.
- TFA shows that most vulnerabilities have a "window of opportunity" smaller than one day. Are you anxious going on week-end because Friday evening a zero-day or a major bug could be made public?
- Yes, I observe a 30-40x slowdown with that method on my interpreter. I was perfectly aware of the cost, Anton Ertl had shown in the 90ies that it wasn't the best on Pentium already [1].
The trick is that you can regain 100% the speed of C (or machine code) by native-coding the critical parts. It's pretty much the same cheating method as JIT or calling native code with an FFI, just manual.
In this regard, a simple, naive subroutine threaded scheme makes it very trivial to do. Think Lua extensions but even more easy because you don't have dynamic types or GC memory. Seriously, when I look hear that language X is "easy to extend" and I look at it... No, it is not.
I have come to the same conclusions as eForth "independently" (I have looked at many Forth systems before making my own, so there could be some influences), except I wasn't interested in compatibility with the standard, so I ditched the counted strings for C's ASCIIZ strings. This makes interfacing with C/C++ libraries as straightforward as you can get.
I quite don't understand why eForth goes for C++; I do see its value to parse more complex languages but Forth? I also don't see the value of multithreading. Cooperative schemes usually work well enough and are easier to handle. If concurrency is needed, multiple programs with RPC, shared memory or pipelines are options usually available (some options are more portable than others, though).
> So, the question is, how to encourage today's world of C programmers to take a look at Forth.
This is a huge mistake. If you make a Forth for others instead of doing it for your own needs, you are doing it wrong. Doing it for yourself, and not being tied by backwards compatibility because you have published your Forth and you don't want to lose your audience, leads to vastly different answers.
- Not really. The article was written 10+ years ago, saying that one cannot use Forth in commercial products, yet Forth Inc. and MPE are still in business.
- > So the question I have for hardcore low level programmers: why don't they invest more on the memory allocators
A partial answer is that part of low-level programmers avoid memory allocation and threads like plague. In some cases they are not even an option (small embedded programming, it's nearly as low-level as you can get before going hardcore for real with assembly programming), but when they can the keywords are efficiency, reliability, predictability, and simplicity : statically allocating in advance is a thing you can do because the product is typically with max specs written on the box (e.g. max number of entries in a phone book, to take a generic dumb example), and you have to meet these requirements even if the customer uses all of the capabilities to the max; no memory overbooking allowed, which is basically what dynamic allocation is, in a sense.
> instead of starting a new programming language
If I were to start a new low-low level programming language, I would basically just fix C's weak typing problem, fix the UB problems that only come from issues with long-gone processors (like C++11 finally did with sign encoding), "backport" some C++ features (templates? constexpr?), add a pinch of syntactic sugar and fix union types to have proper sum types. But probably I've just described D and apparently a significant chunk of C23.
You know the rule, "pick 2 out of 3". For a CPU, converting "123" would be a pain in the arse if it had one. Oh, and hexadecimal is even worse BTW; octal is the most favorable case (among "common" bases).
Flexibility is a bit of a problem too - I think people generally walked back from Postel's law [1], and text-only protocols are big "customers" of it because of its extreme variability. When you end-up using regexps to filter inputs, your solution became a problem [2] [3]
30% more bandwidth is absolutely huge. I think it is representative of certain developers who have been spoiled with grotesquely overpowered machines and have no idea any idea of the value of bytes, bauds and CPU cycles. HTTP3 switched to binary for even less than that.
The argument that you can make up for text's increased size by compressing base64 is erroneous; one saves bandwidth and processing power on both sides if you can do away without compression. Also, with compressed base64 you've already lost the readability on the wire (or out of the wire since comms are usually encrypted anyway).
[1] https://en.wikipedia.org/wiki/Robustness_principle
[2] https://blog.codinghorror.com/regular-expressions-now-you-ha...
[3] https://en.wikipedia.org/wiki/ReDoS