He rolled the player back, so it wasn't projected into the future, it was just he adjusted the current position backwards. you fall straight down because your velocity is dependent on whether or not you have the key pressed. Jump and let go of the arrow.
i may be out of the loop, but... none of the popular ways of piracy are generally encrypted are they? if all the unencrypted ones were to be shut down, would it be possible to replace them with safe ones?
i mean with public p2p filesharing, you can always "spy" on the sharers. i mean it has the be decryptable for you to download it, right? and youll know who sent it.
and with stuff that hosted somewhere, whether it's some usenet provider or megaupload, you can always shut down the hoster.
people could still pirate by directly sending each other encrypted files, but you'd always have to know someone personally who has what you want. which would make piracy much harder.
Just because it's not the dominant means of exchange today doesn't mean it couldn't be.
Ten years ago, the analogous reasoning would have been 'Well, we can just shut down the Napster server', or shortly after 'Well, we can just shutdown the Gnutella superpeers'.
you ignored the problem i saw with it. if there's no public component to it and people would only share with their friends, the availability of piracy would be severely limited.
and if there is, the content industry could still get their "spies" in.
hmm, what exactly does he mean by data-oriented programming?
iirc that's something where you don't store data chopped up into objects, but have arrays that keep all the data of one "aspect" of all "objects"... or something like that. something game programmers would use, helps avoid cache misses.
is that what he was talking about? if so, what does it have to do with macros?
It is a very grey area. Too much government regulation and how the hell can it be profitable to hire someone. Too little and individuals get borked if they get pregnant/sick/etc.
Personally I would sacrifice less pseudo stability for less regulation. I believe many problems start off with good intentions, especially when it comes to more regulation.
I think you guys didn't quite catch his point... he doesn't hate women and children, he hates that the state forces him to employ a person for 3-6 years! without working. I support maternity leave but that's ridiculous if true.
I don't know how it works exactly in Hungary, but I doubt that the woman on maternity leave would cost him much, if anything. He probably simply has the obligation to hire her back after the leave.
You went off the rails because you replaced (C z) with z. That is not a valid equivalence. (C z) does not equal z. But (C z) applied to anything else does equal z. So in particular, (C z) (C z) equals z.
Here's how the reduction sequence goes:
: S C C z
= (C z) (C z)
= z
If you think about it, that second C can be replace with anything and it still works:
: S C anything z
= (C z) (anything z)
= z
That C there simply "holds on" to its first argument, and then when it encounters any second argument, it ignores it completely and yields up the thing it was holding onto.
Yes, I like that expository technique of using "_".
Often when I develop a Fexl function I actually use "_" as a placeholder for "something I haven't implemented yet". So if I'm doing something with a list, I might say:
list
_
\head\tail _
And then I just go back and replace each "_" with an implementation of that particular case. In doing so, I might create new "_" slots ("holes"), which I then implement, and then I repeat this process until no more holes appear. It's a really good "case analysis" approach to programming.
For example I used this approach to implement an associative key-value map structure which uses nested lists, where a list at level N branches on the Nth character of the key, so it's a radix-style algorithm but without splitting the keys into pieces:
# Helper function.
\map_put == (\map\pos\key\val
map
(item (pair key (pair val end)) map)
\head\tail
head \top_key\top_node
# Do a three-way comparison of key char at pos
# with the top key char at that pos.
long_compare (string_at key pos) (string_at top_key pos)
# key char is less than top key char
(item (pair key (pair val end)) map)
# key char equals top key char
(
top_node \top_val\top_map
\new_head =
(
string_compare key top_key
(pair key (pair val
(map_put top_map (long_add pos 1) top_key top_val)))
(pair key (pair val top_map))
(pair top_key (pair top_val
(map_put top_map (long_add pos 1) key val)))
)
item new_head tail
)
# key char is greater than top key char
(item head (map_put tail pos key val))
)
# The actual function (map_put key val). This just
# calls the helper function with position 0 to start.
# I should probably re-order the helper function so
# pos is the last argument, then I can define this
# function simply as \map_put = (map_put 0).
\map_put = (\map\key\val map_put map 0 key val)
Also, you'd be surprised at how self-application can actually mean something. Consider how a recursive function is defined using the Y combinator, which is governed by this rule:
Y F = F (Y F)
OK now that's not exactly self-application yet, but now let's dig into the Y combinator a bit and see how it can be defined in terms of a Q combinator:
Y = S Q Q
Now what is Q you ask? It can be defined as a lambda expression this way:
\Q = (\x\y x (y y))
Aha! There's a self-application for you. See how y is applied to itself there.
Now let's use the abstraction algorithm to convert Q into combinators step by step, removing the variables:
\Q = (\x\y x (y y))
\Q = (\x S (\y x) (\y y y))
\Q = (\x S (C x) (S (\y y) (\y y)))
\Q = (\x S (C x) (S I I))
\Q = (S (\x S (C x)) (\x S I I))
\Q = (S (S (\x S) (\x C x)) (C (S I I))
\Q = (S (S (C S) C)) (C (S I I))
OK that was kind of fun but all I did was demonstrate that Q can be defined in terms of S and C. That's actually somewhat irrelevant. The main point is to demonstrate that when you apply the Y combinator to an arbitrary function, you can in effect get recursion. So let's follow the reduction sequence:
: Y F
= S Q Q F
= (Q F) (Q F)
= Q F (Q F)
= F ((Q F) (Q F))
= F (S Q Q F)
= F (Y F)
Now let's show how you can actually remove self-reference from a recursive function. Consider this recursive definition of the function which appends two lists:
\append == (\x\y x y \h\t cons h; append t y)
Now as it turns out, the "==" in Fexl is merely a short-hand which does this for you:
\append = (Y \append \x\y x y \h\t cons h; append t y)
That's actually a non-recursive definition of append there. Consider the body of the function by itself:
(Y \append \x\y x y \h\t cons h; append t y)
There are no free variables in that. The inner call to "append" actually refers to the \append when encloses it. So you actually have a fully closed form function there which calls itself.
You can look at it this way, separating that inner function out and calling it F:
\F = (\append \x\y x y \h\t cons h; append t y)
\append = (Y F)
So if we actually apply that function to two lists, it goes like this:
: append x y
= Y F x y
= F (Y F) x y
= F append x y
= (\x\y x y \h\t cons h; append t y) x y
= x y \h\t cons h; append t y
And then it proceeds from there depending on what x is. It's amazing stuff, being able to defined a fully closed-form function which somehow manages to reach out and call itself. :)
Now on another topic which I find interesting, consider how the abstraction algorithm (conversion to combinators) can be simplified with the use of two helper functions L and R:
\L = (\x\y\z (x z) y) # send z to left side only
\R = (\x\y\z x (y z)) # send z to right side only
Of course these can be defined in terms of S and C but I just implement them directly in the interpreter for efficiency.
Now let's abstract the Q definition using L and R in addition to S and C where possible:
\Q = (\x\y x (y y))
\Q = (\x R x (\y y y))
\Q = (\x R x (S I I))
\Q = (L (\x R x) (S I I))
\Q = (L R (S I I))
That's much more compact than just using S and C alone.
also, in the talk the player's path was projected into the future, iirc, not just showing the past