skatenerd

Can't he just send you a Kolmogorov-random file? The definition of randomness (in Kolmogorov sense) basically corresponds directly to his challenge.

Also, Kolmogorov-random sequences vastly outnumber non-random sequences in general, so with a long-enough file, I wonder how certain he can be that he has generated such a file.

http://en.wikipedia.org/wiki/Kolmogorov_complexity#Kolmogoro...

Parsing declaratively (by e.g. declaring EBNF) is really interesting.

It sort of mushes together the two steps ("lexing" and "parsing"), which, as far as I can tell, are traditionally distinguished from one another.

I guess that the "token" definitions really just reside within the EBNF rules..

I really enjoyed this post. It's more on how to design libraries, rather than on why libraries are better

http://tomasp.net/blog/2015/library-layers/index.html

Eat...365 times...per day

I always thought this was a weird nod to typeclasses

Multiple inheritance often makes it extremely difficult to tell where my code is coming from.

When you don't use inheritance, you often get to refer to another module by name. E.g.

`my_dependency.fetch_data(123523)`

With multiple inheritance, however, that other module has become your own "self"!

Suddenly you're stuck with:

`self.fetch_data(123523)`.

And if you want to find the source of `fetch_data()`, you basically have to grep / look through all seven of your base classes.

If you're lucky, the definition you were looking for calls `self.flush()`, where `flush` isn't defined on this class. It's actually intended to be defined on another base class, which is imported by the multiple-inherited subclass.

So, you effectively have a "DSL" whose "statements" consist of your choice of base classes. It's impossible to determine what's a legal "program" in this "DSL" until you run the thing and get method-missing errors.

I didn't see that he wrote "as well". lol.

Composition...isn't the same as inheritance?

Some of the giant underpasses fill up at night with people, who I assume are migrant workers. I imagine these underpasses provide a sensible place to go when the flooding happens.

Also, the more official-looking temporary housing for construction workers has windows, but it's pretty dense. All those dudes can fit their whole lives into a single duffle.

I've had this happen with Clojurescript. If I recall correctly, runtime errors refer to the generated code, rather than to the source. So it can be hard to diagnose what exactly is going wrong.

This may have changed since I was last working with Clojurescript.

Interesting. In practice, I have started following a pattern where I have two Serializer classes - a "serializer" and a "deserializer".

The "deserializer"'s job is to perform validation and type coercion of incoming requests. It returns a "native" dictionary, which the application code then saves to ORM.

The "serializer" is basically a presentation layer. It calls out to other nested serializers [this is awesome!], and it throws in convenience-fields that make the API response easier to consume.

This pattern makes it a little bit less "magical", and it's easier to distinguish between the API's "incoming" behavior and its "outgoing" behavior.

out of curiosity, how often do you find yourself reading the DRF source code to figure out whats happening?

I really have a problem with the concept of the Serializer in DRF. It handles so much that has nothing to do with serialization. It performs something like de-serialization, where it takes an incoming dictionary and turns it into an ORM object. The docs even recommend using its ".save()" method. Save? on a Serializer?

I think it's a really cool concept if you think of it as more of a Lens. The so-called serializer lets you declare properties of "fields", and these properties will influence both the native-to-ORM conversion, as well as the ORM-to-native conversion.

Is this some extension / perversion of the original XP principles? I feel like XP Explained talks a lot about office layout and how it can foster communication and teamwork.

Interesting - I can read from the variable but I can't assign to it.

Isn't there an issue in Python where closures don't work as expected? The following code will blow up:

https://gist.github.com/skatenerd/72281cadd2ae3e44d6cf

For some reason, stashing the variable inside of a list will fix the variable resolution..?

http://stackoverflow.com/questions/4851463/python-closure-wr...

Ugh thank you.

I got hung up for like ten minutes, before I realized it could also be written as "foldr f z = go", or "foldr f z elements = go elements"

The great firewall is not "rather easy" to get around. It can be a giant pain in the ass. Source: I live in Beijing

Who's gonna be the first person to hook this into method_missing()

kudos

I was momentarily very excited because I thought this was the source of the music video

When I test at the REPL, I feel like I spend lots of time trying to re-enter updated code. This means I do a lot of:

A: Pasting changed code into repl

B: Re-typing code

C: Hitting "previous command" and "return"

The overhead of automating this process (by making a test suite) seems high, but I haven't ever regretted it.

"def function(...)"

output arguments are a special case of side effects?

"Even the typo's" :-)

Looks like precog.com doesn't have much interest in load testing either.

anyone notice the particularly narrow content pane?

i found an article that might be relevant

en.wikipedia.org/wiki/Marxism

Not knowing much C, I was confused about why malloc() wouldn't get called for the RString structure. This is elucidating:

http://www.cs.usfca.edu/~wolber/SoftwareDev/C/CStructs.htm

Particularly this part: "// automatic allocation, all fields placed on stack"