esmooov

What next? Crosswords in the paper?

I don't understand why designers refuse to pay attention to typographic guidelines. 95 characters per line is not very readable. To be fair, Wikipedia already suffers from this problem. Between 100-character lines and sans-serif body copy, Wikipedia's current typography is abysmal.

Otherwise this concept is fine. I'd love to see Wikipedia reset in Meta Serif or Tisa at 66-72 characters-per-line.

Well, if you ever wanna chat about core.async or PourOver or jobs or life, I'm more than happy to do so: [email protected] Nolen's also a great guy and really serious about helping folks out with stuff like core.async. I'm sure he wouldn't mind jumping in an IRC chat to guide you along!

Alright, this is a great point. It would be trivial for me to add addPossibilities. I think I'll do that! Thanks. This will really help for using PourOver to power tagging selection fields where you can ... add possibilities!

I totally wouldn't be intimidated. We all just love what we do. The best way to get a job is often to get to know the folks on the team, hack with them on projects. I'd really hate to work at a place that I felt was exclusive.

I think I'm a little confused. Why wouldn't you have just added the "roman" possibility from the get go? Could you provide an example of a situation when you don't know the universe of possibilities in advance?

I would absolutely like to add a Crossfilter Filter type. I'd even accept a pull request ... ;)

This looks really cool. I wouldn't say PourOver is focuses on speed as much as focused on being fast enough to get 60fps for 100k items. Cheers!

There are some benchmarks against the base underscore filter methods in the tests. These are what Backbone uses by default. However, the real utility of PourOver is less in its raw speed -- I'm sure that it could be improved by smarter folks than I -- but in the patterns it abstracts. I hope you find it useful.

Hi, all.

A lot of folks are asking for a demo and, you're right. I should have included one. My apologies. I'll get to working on one as soon as I can.

In the meantime, I encourage readers to check out the source for http://www.nytimes.com/interactive/2014/02/02/fashion/red-ca... That's probably the clearest "demo" of PourOver at the moment.

More to come!

Crossfilter was absolutely the inspiration. I just wanted to make a Crossfilter that worked with the arbitrary boolean composition, could be dynamically added to and updated, and supported some of the less numerical patterns I was encountering.

Oh this is great! I really should port something like this to the docs.

This is exactly what PourOver offers. You can chain filter results to any boolean complexity, as well extend the default filter types to optimize indexing and caching. Indeed, PourOver was trivial to make, an outgrowth of the very pattern you define above. PourOver is just an attempt to scrap that boilerplate, allow for the queries to be indexed, combined with sorts, and automatically rebuild when the collection changes.

"If you are not paying, then you are the product" is not logically equivalent to "if you are paying, then you are not the product". !A -> B != A -> !B Denying the antecedent.

Just want to point out that you could implement similar behavior in Haskell:

{-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-}

class Concatable a b where concat' :: a -> b -> a

instance Concatable [a] a where concat' l xs = l ++ [xs]

instance Concatable [a] [a] where concat' l xs = l ++ xs

a :: [Int] a = [1,2,3]

b :: Int b = 4

c :: [Int] c = [4]

-- Main> concat' a b

-- [1,2,3,4]

-- Main> concat' a c

-- [1,2,3,4]

That's really excellent. It's funny, although not entirely surprising, but we have also been using parts of Khan and Bret Victor. The students seemed to really enjoy the sandbox of Khan as a starter to what is possible with code. Repl.it was a big help as well. The hard/fun part is transitioning between the experimenting and learning with these out-of-the-box tools to experimenting and learning by actually making your own stuff. I - and I'm sure the other ScriptEd folks - would love to hear more about your experience ([email protected]).

Haha. I'm happy someone saw that. I wish I could say that it had something to do with my theory of Social Catamorphism, folding our disparate talents into a better future, or something. Unfortunately, no such theory exists, and I just picked a piece of code that I enjoy and looks attractive.

Ah, yes. You are absolutely right that I pooched the Android memory example. Laymen might not care and it might not help them. I think a better example might be someone copying information off a website. I've seen this happen a lot. Someone will have to print off name tags for an event but there's only 10 people per page. Copy. Next page. Etc. If they understood, say, the idea of scraping, they'd see a simple batch scrape and save hours if not days.

As you your other point though, about general problem solving, I think I was unclear. When I said you miss the loops and divide-and-conquers of everyday life, I was just trying -- perhaps too lyrically for my own good -- that you are unable to categorize the world into categories you do not know and cannot recognize. You can't see that the operation you do for every page could be abstracted into a loop, exectuable by a computer. You don't see that you don't need to compare all of your friends to arrange them by height, say for a sweet picture, but you can quicksort them. (Ok this is about as contrived as you can get but programmers have a hard time thinking of places most people don't see programming but we do. Because we see it everywhere).

Finally, sure we should focus on illiteracy, debt, oppression etc. We are working, though, on a lot of these problems programmatically.

Right, and this is a barrier to learning digital domains. There is no physicalization of many digital ideas but, precisely by being digital, they do not map onto physical things. I can't run into a lambda on the street or have to fix a leaky loop in my roof. Sure, everyday things touch code but there's a reason why our instinct is to "blow on the cartridge" and not "fire up the debugger"

I like this point. It is an important distinction and a good comparison to a related area, physics. Two thoughts, though, that I'd like to hear your thoughts on:

1. Don't we all learn physics? At least basically in school we learn about inertia and atoms and velocity. Sure we don't learn the hard stuff and our understanding is woefully incomplete. But the analogy would be "the physics we learn in school" and "things like conditionals, sets, graphs, types". 2. The utility curve of physics is a little different than that of programming. Both contextualize the world and give you richer understandings of it in a similar fashion. However, physics stops solving everyday problems sooner than programming does. I have never whipped out alternative spacetime topologies to solve an everyday problem. I have written tons of bots and things to automate my life.

Dunno, just some thoughts.

Haha, that's awesome.

I wanted to add this to my original post because I think it sums up my point nicely:

"That which interests us in a given situation, that which we are likely to grasp in it first, is the side by which it can respond to a tendency or a need. But a need goes straight to the resemblance or quality; it cares little for individual differences. To this discernment of the useful we may surmise that the perception of animals is, in most cases, confined." - Bergson from Matter and Memory

Constraints on what we broadly know and understand are constraints on our contact and perception of the world. We can't live in a digital world and be blind to the recursions and graphs in the furniture.

I'm not sure that this conclusion follows nor am I sure that discussions like this accomplish anything. CoffeeScript makes it easier to write "correct" JS and patches an institutional bug: Javascript's development crawls along. Even if it didn't the browser-as-environment handcuffs developers from taking advantage of new language features. (Have you used JS array comprehensions? No, because browser support is spotty, unreliable). And even in the best of development climates -- a thousand genius hackers ardently updating the code base -- these environmental restrictions would persist, drawn over the frame of IE-Mozilla-Google conflict and competition.

So we have languages that compile to JS that let the language evolve. I use CoffeeScript sometimes and JS sometimes. I'm not going to waste the time in the write-compile CoffeeScript loop for 100 lines of JS that I can write correctly. However, I no longer have to work on a 2k LOC, complex JS app without all the niceties of CoffeeScript. Furthermore, if I'm doing something that benefits from the special expressivity of a Lisp, I'll use clojurescript. If I'm very adventurous (and I need to write, say, an H.264 decoder), I'll use emscripten after any language that compiles to LLVM first.

But these are all for different uses, often things you would never have used POJS for anyway. It's not a discussion of plain ol' JS versions of H.264 encoders vs those made originally with Emscripten. It's a discussion of them not existing at all before, and now having the ability to express them and compile to JS. It's not a question of the old enormous apps we built in JS to the new, simpler ones we express in CoffeeScript. It's a question of not being able to build/maintain 5k LOC in POJS across many developers (whereas this task is less substantial in CoffeeScript). Live and let live and everyone benefits.

I think Jeremy's real point is that Javascript is an entirely different beast than Haskell or Java or Ruby. Why? Javascript depends on a free and open code environment to get around the fact that the actual language's development moves glacially, you have no control of the deploy environment (unless you are a browser developer or are working in node) and it is not easy to manage large projects (inclusion and namespacing features are lacking or limited in JS). In fact, the only feature that allows JS to keep up at all with these other languages is that it tells its developers "Look, I don't have a lot of fancy features and I haven't really changed in about a decade, but I'm entirely open. Hack and abuse me at your pleasure, codify me if you must, I'll take it. I always do."

None of the proposed object-lockdown would prevent anything. You could use decorators, you could use an adapter, hell you could rewrite or fork the useful library and take out the object-locks. But all of those introduce the very overhead that JS benefits from avoiding. I mean compare the size of "Javascript Pattern" to the GOF book. What's more, languages like Java are written with a sensitivity toward design patterning, Haskell has robust types/interfaces. Javascript just has a big empty box, prototypes and closures. (This is an exaggeration but if you declaim it loudly enough you will get a chuckle.)