Editing User:Drostie (section)

= CR Drost =

Hi! My name is Chris. I've got a Master's in physics with a lot of interests in programming language design and software development. Here are some of them:

== Mathematics ==
One of my primary interests in Haskell is phrasing standard mathematics in its syntax so as to make equations unambiguous, which I feel might make physics a little simpler for college students, since they don't have to "decode" what was meant. There was a nice book called "the Structure and Interpretation of Classical Mechanics" in a similar vein.

== In-memory Revision Control ==
I'm also interested in "lifting" Darcs, or something like it, out of the IO monad so that you have a revision control system in memory which just happens to be data-serializable. I think that this is the key to bringing a lot of awesome software closer-to-reach for amateur developers, for example Google-Docs-style collaboration, or a document which has a built-in RCS showing you all of the edits that have been made. 

== Spreadsheets done right ==
The idioms that people use with spreadsheets are vastly more constrained than what those spreadsheets actually are capable of; and when people don't use those idioms you get these corporate Excel monsters which are buggy and hard to fix. A good lazy spreadsheet language would be able to rectify this explicitly. Haskell with applicatives would make a great fit for that; we just need the GUI to be relatively awesome, and we'd need to get copy/paste right.

== Subtyped metadata language ==
I'm reasonably sure that you can use subtyping to do arbitrary metadata (which is close to the way "mixins" work) with a type system. My goal there is to (a) make a programming language which is effortless at expressing metadata; (b) use that language's parse trees as its own data structure, so that every data structure also has metadata associated with it; (c) write the subtype-checker in the language itself; (d) offer a compiler which by default type-checks, but where this can easily be turned off.

If I were really optimistic I would then say that maybe we could support a really generic polymorphism, where technically 1 is ''defined'' as the Church number but there is metadata which tells the compiler that it's ''okay'' to store it as a bignum, or a long, or an int, or a short, or a byte, or a bit. The idea is that the language would entertain the notion of multiple perspectives on the same data, and would be able to lazily autoconvert between them ("You wanted to compute a multiplication? Okay -- switching to a decimal representation. Oh, now you want to repeat a function that many times? I've got a Church numeral for you...").

With a dynamically pluggable syntax, ideally we'd be able to translate the abstract parse trees (which are just data structures) from language to language, saying "here is the Python translation of what you wrote, here is the Haskell translation of what you wrote," etc. Then we tell the Pythonistas that they've secretly been programming in the new language all along, and here's a useful subtype-checker which they can use to make their code better -- oh, and if they want to use our libraries, that's cool too.