Nice article. Minor gripe about the static vs dynamic memory section. The requirement that the data sizes be known at compile-time for static memory (with the example of an array allocated to a user-inputted size), seems to be based on a past restriction of the C language. C has since remove the requirement that stack-based arrays are sized with a compile-time constant; there is nothing at the hardware/assembly level which prevents such arrays. So these stack-based non-compile-time-sized arrays don't fit into either the static or dynamic memory categories presented here.
Hmm, I'm maybe missing something in this example. In the two slit experiment, a single photon can appear to go through two slits simultaneously. You appear to be suggesting that there are multiple particles going throw the slits which creates the interference, but I understand it that one particle interferes with itself, when you do not detect which slit it goes through.
I think the distinction is that observation can affect a system. In order to look at a particle, you need to bounce a photon off of it, which affects it. The particle/wave still exists and is still "doing calculation", its just that measuring the system literally and obviously affects it. Some people attach far too much significance to this.
Interesting concept. The article mentioned that other languages determine blocking automatically based on usage of the variables. So in your example, it could be determined that x and y must be calculated first before pyth_distance is called with x and y. Would you incorporate this kind of automatic detection into your language? Why or why not, and to what level? Would it perhaps be safer for the language to determine blocks for you?
Thanks! That's an interesting fact about Feynman diagrams. If we had a hypothetical machine which could perform these calculations with infinite precision, would the "virtual particles" disappear from the diagram, or is it impossible to know this?
Thanks! That's a really nice explanation. I keep forgetting that particles don't really exist so much as a wave function does in the Copenhagen interpretation, so that gives me a new way to think about virtual particles, and helps tie it in with the article. Also a lot of other nice tidbits in this explanation for me to mull over...
Can you give me some hints on what virtual particles actually are if its not too complicated? I keep reading that they are not actually real particles, only useful for calculations/as a simple way to understand what is going on. How does something like Hawking radiation work if they are not real particles?
That's not quite accurate. Local hidden variable theories have been proven wrong, but pilot wave theory is a nonlocal hidden variable theory. Bell himself was a proponent of pilot wave theory.
"lambdas that aren't as powerful as proper function defs" I don't really follow this. I think we should use the right tool for the job. I don't need something that is "more powerful" but comes with extra verbosity and requires me to jump around the source code if I'm not using the extra power.
"In fact, in some ways it may be advantageous e.g. static analysis." Curious why static analysis can't handle closures? Also, I want to use expressive constructs as a programmer, not be arbitrarily limited by what some static analyzer can handle. There may be cases where you are tied to a certain language and analyzer, but in the general case, I don't follow this argument.
"I'd need a use-case for the anonymous closure." I don't want to delve too much into the usefulness of closures, but they definitely exist for a reason. They are useful as parameters to metafunctions for example, which are used extensively in certain programming styles (ie, more functional styles). Closures are basically syntactic sugar. You don't need them, but they can really make things cleaner/simpler in some cases, and are natural constructs to use in certain paradigms. They can also be used in factory functions as a more succinct way to create an object (point might be lost if you are not familiar with this style).
"I know how in js there is a degree of 'binding' scope and hiding functionality in closures." I'm not really talking about this, or JS in particular. I'm really just talking about the concept of a closure which you can find in many languages. Python already has closures (lambda), but why they can only be one expression instead of multiple lines seems somewhat arbitrary, besides maybe ease of implementing the language/problems specific to Python implementation (can you explain this one?). From a purely programming perspective, I shouldn't care about what a language has trouble with, I care about using high level and expressive constructs, I don't want to limit my expressiveness because of some technical issue in a language. Many languages implement closures efficiently.
"As an aside, would you say js scope/closure approach is a bit similar to the approach in R?" Haven't really used R, but in the languages I have used with closures, they all are basically the same. Really the wikipedia article on closures captures this.
I think this is the point. You can do all these things, but they are all extra hoops you have to jump through when all you want/need is an anonymous on-the-spot closure.
Closures are functions that can capture values/references visible in the scope where the function is defined/instantiated. They are basically a short hand way of creating function objects, functions which have data members.
Sorry, I edited my comment and you may have missed it. How would you emulate multi-line closures in Python? A free function which you can pass to a higher order function is not a closure. I think you would need to create a functor, and that becomes even more verbose.
Sure, but I think that is the point. You can do that, but its not as convenient and becomes harder to read. And besides, those are free functions you speak of, not closures. To emulate multi-line closures becomes even more obtuse.
Good point about robustness, it makes sense in the general case, but if I have a container of integers, I think the chance that I replace int with a more expensive type while not having to modify the rest of the loop is pretty unlikely. Chances are the more expensive type would no longer behave like an int. I think there are cases where the robustness approach shines, and cases where it's pretty safe to just use a const copy and a reference would just add noise. Imagine a simple function where I initialize an array of integers, then iterate over them. const auto or just const int makes sense, const auto& requires more explanation and invoking what if's that are unlikely to ever surface.
I use const auto on occasion, when the element type is inexpensive to copy. If I'm iterating over a vector if int's, why would I prefer const auto& over const auto? Assuming the compiler does not try to optimize the const auto&, const auto should be faster than accessing a value through a reference.