tibbe

The core set of packages (e.g. those in the platform) tend to not break backwards compatibility, but you're right that there are still packages that move fast and do.

Note that this isn't the "official" Haskell style guide. We don't have one (although we probably shouldn't). This is one of the competing guides out there.

There are cases you cannot really exclude by testing. For example, guaranteeing that certain function never receives a null value.

You can connect to the run-time system e.g. using the ekg package.

Aren't they complimentary? You can have a side-by-side diff without the extra context this change introduces.

That said, I also want side-by-side diffs. They're necessary for more complex diffs.

More likely Go's build system is influenced by Google's build system, which came first.

Until recently I don't think any major hash table implementation (e.g. not Java, STL, Python, Ruby, etc) used a cryptographically secure hashing algorithm. They're just too slow. Slow enough that you might as well use a tree-based data structure, which doesn't suffer from hash-collision based attacks.

This is changing a bit now when SipHash is available. Unfortunately SipHash still is a bit too slow and forces an uncomfortable trade-off.

The original question asked for

> Example (good) uses include hash dictionaries.

which I interpret as meaning hash tables or similar. If so hash function performance matters a lot, especially for short strings.

If someone could run smhasher for the hash functions in the original article (and perhaps also MurmurHash 2/3) and summarize the result for the small key sizes I will give them a cookie.

Driving really hurts standard of living, at least for me.

Can we have side-by-side diffs of code first, please?

We tried this hash function for a while as the standard hash function for `Int`s in Haskell and real world performance was worse than when using the identity function. I'd like the author to back up the statement that the better distribution actually helps on real examples.

They are pretty rare. Very few functions actually want to use nullable-arguments. Another reason why nullable by default is a bad idea.

Haskell Prime is not like Python 3 in the sense that there are very few (and no in practice) breaking changes to the language. Haskell Prime standardizes stuff that's already there.

According to Bryan O'Sullivan (bos) he will use Haskell at Facebook.

http://www.reddit.com/r/haskell/comments/13m8eu/haskell_leav...

This excuse is as old as programming languages.

* Programmers who need a higher level language (e.g. C instead of assembly) are just bad programmers.

* Programmers who can't manage manual memory allocation are just bad programmers.

* etc

I would say `unsafePerformIO` exist for calling C code. Since the Haskell type system can't prove that the C function you're calling is pure, the programmer needs to assert this fact by using `unsafePerformIO` at the call site. There are other possible uses of course, but I'd say this is the main one.

The GHC Commentary contains a wealth of information: http://hackage.haskell.org/trac/ghc/wiki/Commentary

Dynamic languages typically also have to pay a price for carrying around type tags and having everything be heap allocated.

Using JavaScript as object code is particularly efficient though.

I usually use `trace` like so:

    f _ _ _ | trace "print something profound" False = undefined
    f normal arguments here = ...

That way the trace output will be printed whenever the function is evaluated, which typically mimics a lexical call stack unless you use laziness in some particularly interesting way.

HN most likely uses a combination of votes and time in scoring, similar to the reddit ranking algorithm: http://amix.dk/blog/post/19588

The "Maybe" monad solves exactly this problem.

The problem it introduces is that you could have gotten rid of nulls from the language if you use sum types for errors.

Reading the same code I also cringed, but for a different reason: the validity of `paths` is tied to the validity of `err`; you should never look at at `paths` without first checking `err`. We can solve this much better using sum types (also known as discriminate unions):

    // Pseudo Go:
    maybe_paths := filepath.Glob(dir + "/*.png")
    case maybe_paths of {
      Some paths: {
        // Do things with paths
      }
      None: {
        // Handle error case
      }
    }

This makes it impossible to use `paths` if `Glob` returns an error, as `paths` won't be in scope!

Furthermore, not having sum types forces us to include a distinguish value `null` for reference (pointer) types, as a way to communicate "no value". This is bad as now we cannot distinguish references that should never be `null` from those than can be `null`.

This allows you to serve more clients simultaneously, but not to serve any given client faster i.e. you get higher throughput but not lower latency.

There are natural limitations to how much people will save:

* When you're dead all your savings are worthless (to you), so your likely to spend most of them before then.

* Some consumption cannot be postponed: you need food, a roof over your head, transportation, etc.

* Time has value. For example, if you wait another 6 months the same amount of money (bitcoin or not) will buy you a better computer. This is likely to hold true in the foreseeable future. Still people do but computers (and phones, etc).

* There's opportunity cost: even if your savings increase in value over time, investing them in something could increase them even more.

Requests per minute!

It depends on what you compare to. Bryan aimed for speed got to 56% of the speed of the C parser he used as a benchmark, using 54 lines of code. The C parser is a 1,672 lines hand-rolled parser that's only does HTTP, while attoparsec is a general purpose library. Bryan wrote about it here: http://www.serpentine.com/blog/2010/03/03/whats-in-a-parser-...

Haskell (or rather GHC) offers a blocking programming model (e.g. spawn a thread per connection and make blocking reads/writes on the socket) but uses asynchronous I/O in its implementation (one thread uses epoll/kqueue/poll to do the I/O and the CPU bound threads are scheduled on a thread pool).