> but Newtonian mechanics AFAIK says nothing to forbid this
In the Wikipedia article on Newton's laws of motion, the first law is stated as "A body remains at rest, or in motion at a constant speed in a straight line, unless acted upon by a force.". Here it would seem that we leave the state of rest not due to a force, but due to some other cause, which the first law would forbid. So I think that the particular interpretation of Newtonian mechanics used by the author is a bit of a strawman.
Non-const globals could be an issue, but it's possible it doesn't matter too much for this particular benchmark. I'm a little worried about taking compilation time (apart from precompilation) into account (would that also be done for C++ code?). But I must confess I maybe posted my comment a bit too soon, partially because of the time of day, partially because of the semicolons at the end of each line in the code, which made me quickly think the benchmark writer was using Julia for the first time. While I have a good amount of experience with Julia, I don't have that much experience with DataFrames.jl itself, so I don't know for sure whether the reported benchmark times are reasonable or not.
Yep. (You know this, but) just as another data point, an incremental pass takes more like 75 microseconds, and a 'lightly' allocating program probably won't trigger a full sweep (no guarantees though).
I actually can't think of a single language that doesn't allow you to multiply an integer and a floating point value, yielding a floating point result.
The fact that these transitions were so painful doesn't mean that all breaking changes have to be so painful. With Meyers' 'magic wand', the transition is eased quite a bit. But another important component of a smooth transition is a 'carrot', a new feature that's so compelling everybody will want to move to the new use the new version. If a C++ with major breaking changes would also halve compilation time for example, most people would switch in a heartbeat.
Exactly. The thing that hasn't been figured out yet is how to combine the energy efficiency and aesthetics of passive walking with the versatility needed to have the robot do useful work, especially in a principled way.
Julia relies heavily on type inference, similar to all variables to be marked auto or auto& by default in C++.
Functions are templated on the argument types by default, in C++ terms. So if you call a function f(x) first with an integer and then with a floating point number, Julia will generate separate machine code optimized for each case. Annotating function arguments with types only serves as a filter for whether the function applies to certain types, and can be used for method overloading (function template specialization in C++). The fact that functions are generic by default lends itself well to forward-mode automatic differentiation using method overloading.
Julia is still a dynamic language though. This means that if a variable is bound to an integer in one branch of an if-statement while a string is assigned to it in another branch depending on the value (not type) of a function input, then the variable's type cannot be inferred and needs to be 'boxed', i.e. the runtime type needs to be stored along with the data. In such cases, function dispatch can no longer be done at compile time, and needs to be done dynamically instead. While this is useful for rapid prototyping, it does result in reduced performance, so it should be avoided in code with high performance requirements. The type elision part of this is somewhat similar to boost::any.
In the Wikipedia article on Newton's laws of motion, the first law is stated as "A body remains at rest, or in motion at a constant speed in a straight line, unless acted upon by a force.". Here it would seem that we leave the state of rest not due to a force, but due to some other cause, which the first law would forbid. So I think that the particular interpretation of Newtonian mechanics used by the author is a bit of a strawman.