I don’t know; their comment seemed pretty much the same throughout…
I don’t know; their comment seemed pretty much the same throughout…
So… all that is NOT False either, I presume?
which is NOT False…
You really didn’t need this; I would have just assumed that you were speaking the truth.
Boy does it seem like this author is trying to push something. I wonder if…
To learn more, attend my upcoming CEC course January 27-31: Expert C Techniques to Master Bare-Metal Programming. You’ll discover how to master one of C’s most powerful tools—function pointers—and use them to design flexible, efficient systems. From building cooperative schedulers and command parsers to creating configurable, reusable code, you’ll gain hands-on insights that can transform your approach to embedded programming.
…yep, sounds about right.
That makes sense. I had thought that you were implying that the quantum nature of the randomly generated numbers helped specifically with quantum computer simulations, but based on your reply you clearly just meant that you were using it as a multi-purpose RNG that is free of unwanted correlations between the randomly generated bits.
Out of curiosity, have you found that the card works as well as advertised? I ask because it seems to me that any imprecision in the design and/or manufacture of the card could introduce systematic errors in the quantum measurements that would result in correlations in the sampled bits, so I am curious if you have been able to verify that is not something to be concerned about.
I would not recommend this as an exercise for a beginner, but RPython is a subset of Python with a C backend; it is used as the basis of PyPy (an implementation of Python), so it may be possible to use it to implement the low-level parts which then can be used to bootstrap a full Python virtual machine.
Yes, and that’s basically what the CPython interpreter does when you call a Python script. It sometimes even leaves the machine code laying in your filesystem, with the extension .pyc . This is the byte code (aka machine code) for CPython’s implementation of the Python Virtual Machine (PVM).
This is incorrect; the term “machine code” refers to code that can be run on a real machine, not to code that requires a virtual machine.
The context you are missing is that, for a lot of people, OOP was taught as the be-all and end-all of abstraction. I personally have seen some of my less experienced colleagues start to write code to solve a problem and immediately reach for OOP over and over again, even when this made things a lot messier (which ultimately I had to deal with…), because that is how they were told at one point was the “correct” way to do it, so I can completely sympathize with anti-OOP sentiment. On the other hand, I am not personally vehemently anti-OOP because I think that (as you have correctly observed) OOP is a perfectly fine pattern when it fits, and arguably the root problem that my colleagues had was not so much that they used OOP everywhere but that there was a tendency to not think through the consequences of their design choices.
If you are just measuring the quantum effect to turn it into a classical random number before using it, then how does that help you over a less expensive way of generating a classical random number for quantum computer simulations?
Article written like it’s someone that just discovered types even though a majority of the programming world said to use types for decades…
Yeah, how dare the author discover something that they did not know before and get so excited about it that they wanted to write an article about what they learned! That is a completely inappropriate thing to do with a personal blog.
Edit: Finally figured out how to link the image to the original comic. (I needed to embed the image link inside of another link.)
To clarify: I am saying that it is not “normal” that the type you get back out is not only not necessarily the type that you put in, but may be different depending on the value that you put in. Put another way, sqlite is strongly typed unless you mistakenly thought that type affinities by themselves made it be strictly typed, in which case it becomes neither strictly nor strictly typed.
Strongly typed is orthogonal to strictly typed, so these two properties alone are not contradictory.
However, it is a bit unsettling that, if a column has an INTEGER type affinity, and you try to put a string in it, then the string is implicitly converted to an integer if it represents an integer and just stored silently as-is otherwise.
Hmm, well… I have never murdered anyone, not even once! Is that good enough for their Code of Ethics?
You are making the extremely incorrect presumption that I am unfamiliar with Lisp and how macros work. What is unclear to me is how you specifically think that arbitrarily rewriting code at macro expansion time is exactly equivalent to arbitrarily manipulating the stack at runtime.
Perhaps you could explain exactly what you mean?
In Forth, though, the number of results pushed to the stack after an execution of a word could be a function of the input rather than a single value or even a fixed number of values.
Likewise, the number of arguments that a word pops from the stack could be a function of a value pushed earlier to the stack.
No. Roughly speaking, functional languages implicitly manage the stack for you, whereas Forth requires you to manage it explicitly.
I am not a big fan of the first example. If all that a function is doing is pasting its argument into a template string, then I’d rather see that pattern expressed explicitly in a single line of code than have to mentally infer this pattern myself by reading two separately expressed cases in six lines of code.
(It’s not that big of a deal, but when reading through a lot of code to figure out what is going on, these little extra mental exertions start to really add up.)
Thus demonstrating that when you combine XML and C++, you truly get the best of both worlds!