34yo here, got called a cheater constantly, even by "top" players. Despite using a slow sensitivity myself, i would say that slow/fast sensitivity or wrist/arm aiming doesn't matter; I have seen plenty of people being very efficient with each technique. Just use what you are the most comfortable with. Something specific that tremendously helped me is putting fingers on each side of the mouse to lift it a little, the mouse is no more touching the mousepad, only your fingers, that way i can stop moving much more precisely. You no more think about aiming with the mouse but with your hand. When i need a slower sensitivity, i just lift the mouse higher. In the past i was playing with a CRT monitor at 160hz, now i am playing with a IPS monitor at 144hz (LG 27gl850-b); i have seen no difference in performing at KovaaK aim trainer[1]. Something that actually made a difference is where the sensor is located under the mouse. More the sensor was toward the back of the mouse (toward the wrist), more my aim was degrading. I also once tried a vertical mouse (Trust GXT 144) and did my best score ever in tracking, it was like holding a pen.
Is it really? If we go back to the roots, lisp is made of what John McCarthy calls the Primary S-Functions which are atom, cons, car, cdr, and eq (a.k.a =).
Of these five, clojure only has two (atom and eq)
When executing on Java we are dependent on hotspot to support it in the native bytecode interpreter. In truffle interpreters we made some successful experiments with tail calls emulated using exceptions. It's pretty slow in the interpreter but as soon as graal optimizes it, it just turns into a tailcall loop.
Here is some more info:
http://epub.jku.at/obvulihs/content/pageview/508465
You may find some blog posts about truffle and tailcalls as well.
Naive interpretation of the bytecode (not even pre-decoded, just a switch statement).
And almost everything is resolved in the dynamic environment. for example,
This is a bit misleading. You suggest that local variables are looked up by name in a dictionary, which is not the case. They are looked up by indexing into a C array, with the index being a constant in the bytecode. That's quite a lot simpler. Here is the corresponding code (look above for the definition of the GETLOCAL macro): https://github.com/python/cpython/blob/fc1ce810f1da593648b4d...
But this isn't a very good rendering of the thing because it doesn't show the many redundant reference count increment/decrement pairs every time you touch a variable.
(Also, interpreter dispatch uses computed GOTOs instead of the plain switch on C compilers that support it.)
LOAD_FAST is the normal case for locals inside a function. Not sure off the top of my head where LOAD_NAME would be generated in normal usage (i.e. where you don't evaluate code from a string).
Edit: Also, I'm talking about Python 3. Maybe you aren't.
Interesting experiences beyond the command line are game development tools; Each iteration try to make the barrier between artists/content creators and programmers thinner.
Indeed. Also interesting is a look at games themselves, especially those that show a long trajectory from beginner to experienced player with significantly different interaction patterns between the two groups.
It would seem that practically no programmer's tool has ever received the attention to interface detail that is common in the best games.
Iconic yachts: On board Steve Jobs's Feadship superyacht Venus
https://www.boatinternational.com/yachts/editorial-features/...
Jobs died before it was finished.