As you note, the team developed the typechecker in OCaml, as that's what the founding engineers were familiar with. Many of ML's cousin languages happen to be well suited to this kind of work.
1,351 karma · joined July 16, 2009
One of the reasons that PHP has been such a success is that you can simply save a source file and reload a web page to see what's going on.
The server-based typechecker that runs instantaneously is what makes it possible for Hack to replicate this experience: you save a file and reload a web page, but you have the safety net of a typechecker that told you about your type errors as soon as you saved the file.
I can't overstate how important this instant feedback is: it's really the thing that distinguishes Hack from working in a more traditional compile-based static language.
The biggest learning step for our engineering teams was to treat type errors from Hack as actual logic errors. We have a collection of "linters" that provide advice on code style and other nice-to-have factors. Some people (quite reasonably) initially thought of Hack errors as lint-like stuff that it was safe to ignore, when in fact they indicate real logical inconsistencies in code.
Obviously switching to a syntactically incompatible programming language would be at odds with that goal.
In the mean time, the open source release of Hack includes integration with both Emacs and Vim.
I'll explain in a bit, but before I do, let me first address your question about "can I bang on bits?". Yes, you can allocate memory and do all the low-level hacking you please in Haskell. It's not really any harder than in C, although the notation is different and that throws people. But because this is a very imperative way of programming, it's also not going to be any faster than C (typically it'll be a bit slower).
There are even MPI bindings for Haskell, and they look pretty much the same as for other languages (i.e. very low level).
If you're just foontling around imperatively in big homogeneous arrays and sending messages, then the type system really won't do you any good, and you'll rightly find yourself wishing for the notational convenience and speed of Fortran 95.
You could use immutable arrays (the Vector type is your friend) and higher order functions instead, and thereby benefit from Haskell's rather nice parallel evaluation support with only a little effort. This is quite practical, and can lead to pretty code that runs quickly.
Where all the fancy type-related machinery comes into play for numeric code is still largely a matter of research. There are interesting projects underway for parallel programming (both on CPUs and GPUs) that rely heavily on the type system. They're not obviously useful for real work yet, and since they rely on advanced type system features, neither are they something you just pick up and use as a newbie. Nevertheless, I think they're pretty cool projects, and I have been watching them for a few years.
So while there's a lot of interesting stuff going on, the current state of affairs is somewhat mixed. You might enjoy learning your way through it, though; there are many rewards to the path.
What this comes down to is that git uses a lot of essentially O(n) data structures, and when n gets big, that can be painful.
A few examples:
* There's no secondary index from file or path name to commit hash. This is what slows down operations like "git blame": they have to search every commit to see if it touched a file.
* Since git uses lstat to see if files have been changed, the sheer number of system calls on a large filesystem becomes an issue. If the dentry and inode caches aren't warm, you spend a ton of time waiting on disk I/O.
An inotify daemon could help, but it's not perfect: it needs a long time to warm up in the case of a reboot or crash. Also, inotify is an incredibly tricky interface to use efficiently and reliably. (I wrote the inotify support in Mercurial, FWIW.)
* The index is also a performance problem. On a big repo, it's 100MB+ in size (hence expensive to read), and the whole thing is rewritten from scratch any time it needs to be touched (e.g. a single file's stat entry goes stale).
None of these problems is insurmountable, but neither is any of them amenable to an easy solution. (And no, "split up the tree" is not an easy solution.)
The client-side code is written in C# because the .net APIs for Office are the easiest to deal with.
That's actually not true. You can use QuickCheck with "normal" code that has side effects, too, and it's every bit as useful there.