jb3's comments

On: Estimate your English vocabulary size

[jb3]

I was about the same. I was surprised when I saw the percentiles and averages at the end.

[eli → jb3]

The numbers appear to be based on people who previously completed the test. It's a pretty easy test to cheat on...

On: Common Lisp, Clojure and Evolution

[jb3]

Christophe Grand pointed out in the comments that a plain map should be used instead of a struct, so your example in Clojure would be: {:height 6.3 :age 63 :weight-in-kg 63}

[mahmud → jb3]

That works in the short term, but beyond that, Clojure will need to resolve that issue.

Records are not the same thing as hash-tables. A record, or struct, is a single unit value, while a hash-table, or map, is an aggregate container. There is an implicit contract in place; a record is guaranteed to have JUST the fields it's defined to have, while a map can grow at run time (are you going to test for the fields you want and ignore the rest? quack quack! you can't add fields to a record at runtime, so the two are NOT interchangeable. Equality is a transitive relation, while duck-typing is not.)

A record is a generalization of the concept of "value" beyond data types immediately representable by machine. While a hash-table is a generalization of arrays, an aggregate of values, addressable by an index (hash-tables remedy the silly assumption that an index must be of an integral value.)

To give an analogy; it's like asking what's the best way to group a bunch of papers (folder, envlope, binder) and then hearing someone suggest "bookshelf!".

Again, OK short-term, but stinks. Fix the structs; even C has dot and arrow notations, making the field names clear.

[jkkramer → mahmud]

Records and structs can grow at runtime (insofar as immutable data structures grow).

    user> (defrecord Foo [x])
    user.Foo
    user> (assoc (Foo. 1) :y 2)
    #:user.Foo{:x 1, :y 2}

    user> (defstruct foo :x)
    #'user/foo
    user> (assoc (struct-map foo :x 1) :y 2)
    {:x 1, :y 2}

[mahmud → jkkramer]

Well, what do you know, Clojure records and hash-tables are equal (strongly.)

I will announce this great news to a few of my closest friends :-)

[jkkramer → mahmud]

Almost. Record types are checked as part of full equality. So record Foo{:x 1} is not equal to Bar{:x 1} or to {:x 1}.

[w01fe → jkkramer]

Almost. Record types are checked as part of Clojure's "=", but not as part of Java's ".equals". See [1] and linked material. This means that Foo{:x 1} and Bar{:x 1} will collide in sets and as map keys (of Clojure or Java varieties). This seems a bit icky to me, but seems to be intentional.

[1] http://dev.clojure.org/jira/browse/CLJ-736

[lukev → mahmud]

Records also provide better performance than hash tables for their defined keys.

You can think of them as a Java class that has certain fields (it's named fields) and also implements the Map interface for additional expandability. Records provide "accessor" methods for their named fields that provide bare-metal JVM performance.

On: Pypy wants you - now's the time to start contributing to Pypy

[jb3]

Of all the things that I dislike about MUMPS, error messages aren't anywhere near the top of the list.

On: Pypy wants you - now's the time to start contributing to Pypy

[jb3]

I'm currently at epic, but I know there are other companies still using the language.

On: No Formats, no Format Wars

[jb3]

Could Native Client be the way forward for this approach?

Link: http://code.google.com/p/nativeclient-sdk/

[Detrus → jb3]

The development team proposed NaCl as a potential solution to many of the format problems. We could make a lot of custom compression formats that would be better than gzip. A multitude of image formats tuned for various categories of images or videos.

Fast JavaScript could go a long way in that direction too https://github.com/antimatter15/weppy With types and WebGL hardware access who knows.

NaCl project has social forces going against it. People want a homogenous platform. Platforms solve a social problem, developers become familiar with the same API, make libraries for it, make development easier, etc.. NaCl would have to play that game and it takes a long time. By the time it's done it won't be a good fit for problems of the day, just like high level VMs today.

[leoc → jb3]

Yes. http://news.ycombinator.com/item?id=1056391 (later update: http://labs.qt.nokia.com/2010/06/25/qt-for-google-native-cli... , transcript of Kay talk: http://blog.moryton.net/2007/12/computer-revolution-hasnt-ha... ) WebGL wouldn't hurt either.