2,865 reputation
1015
bio website jelv.is
location Berkeley, CA
age 21
visits member for 3 years, 7 months
seen 9 hours ago

I am a student interested in programming languages, functional programming, program synthesis, type theory, universal algebra and startups (not necessarily in that order!). In the near future, I want to combine as many of these as possible.

I am currently an undergraduate researcher at the Berkeley ParLab, working on program synthesis. This past summer, I was a tech intern at Jane Street Capital, brazenly using OCaml in the real world. Right now, I'm leading a meetup group about type theory; you can see the slides here or just show up to the next on if you live near SF ;).

I am always happy to chat: my email is tikhon@jelv.is

GitHub: http://github.com/TikhonJelvis

Website: http://jelv.is


Jun
18
comment Why are most functional programming languages also interpreted languages?
@JörgWMittag: Ah, so mixed mode is basically JIT.
Jun
18
comment Why are most functional programming languages also interpreted languages?
@JörgWMittag: Well, you have to compile to the bytecode first. Perhaps I misunderstood what you meant by mixed-mode though. The bytecode compiler is used by camlp4, but that's a bit of a historical accident and makes it slow, so they're not using it for their new "extension point" system. Mostly, the bytecode compiler is useful for portability and simplicity: for example, it's used by js_of_ocaml to compile to JavaScript. I think it's also used for the REPL.
Jun
18
comment Dealing with state problems in functional programming
Except perhaps for the database example, those problems are not inherently stateful. For example, for GUI programming, you're really using mutable state as a poor, implicit model of time; functional reactive programming lets you model time explicitly without relying on state by providing streams of events you can combine.
Jun
18
comment Why are most functional programming languages also interpreted languages?
OCaml has something like two implementations in one: a normal compiler and a bytecode compiler. The first is a normal optimizing compiler while the second is more a mixed-mode system with a bytecode interpreter. They're shipped together, but are separate backends.
Jun
4
awarded  Guru
Jun
4
revised What is the “Free Monad + Interpreter” pattern?
deleted 1 character in body
Jun
3
awarded  Mortarboard
Jun
3
awarded  Good Answer
Jun
3
comment What is the “Free Monad + Interpreter” pattern?
@BenjaminHodgson: Boyd is completely right. I wouldn't worry about it too much unless you're just curious. Dan Piponi gave a great talk about what "free" means at BayHac, which is worth a look. Try following along with his slides because the visual in the video is completely useless.
Jun
3
awarded  Nice Answer
Jun
2
answered What is the “Free Monad + Interpreter” pattern?
Mar
1
awarded  Necromancer
Jan
28
comment Why do dynamic languages make it more difficult to maintain large codebases?
@JörgWMittag: It doesn't seem to have overloaded literals the way Haskell does: it just has a few nested types of numbers. For example, you can't add your own numeric types, especially if they don't fit into the existing hierarchy. I still don't see any way to do this without either having explicit annotations or using typeclasses and inference. Besides numbers, consider things like Read which also relies on typeclases. My real point is that type systems do not just reject illegal programs. With type inference, they can make programs that would be underspecified without types work.
Jan
27
comment Why do dynamic languages make it more difficult to maintain large codebases?
A type system can actually make a language more expressive. Consider Haskell typeclasses--they enable really useful things like overloaded literals that are difficult if not impossible to replicate in other languages.
Jan
27
comment Why do dynamic languages make it more difficult to maintain large codebases?
@ThiagoSilva: Monads are not an example of complexity per se. Many people find them hard to learn, but as abstractions go they are quite simple--the difficulty is that they are also quite abstract. In fact, monads often simplify a design by making it more explicit: they just highlight things which are magical and unacknowledged in other languages. And Norvig's design-pattern article is not relevant to statically typed functional languages at all; it's not a comment about static typing in general but rather about Java-style type systems (which we can all agree are a mess).
Dec
3
awarded  Yearling
Oct
25
comment What are the safety benefits of a type system?
Another great example for what type systems can verify: units of measure. This even includes automatically converting between compatible units like feet and meters!
Jun
15
comment When is it a good time to reason about performance in Haskell?
@MasonWheeler: He's most likely talking about asymptotic complexity. The constant factors are an implementation issue. Moreover, even if both programs terminate, the non-strict one could do significantly less work: consider all even [1..1e10] for both a strict and a lazy version of all. The compiler also has more leeway for choosing the order of evaluation in a language like Haskell with things like loop fusion.
Apr
24
comment Why does Haskell have built-in “if/then/else” instead of defining it as a simple library function?
I don't think the inlining is an actual issue. My understanding is that GHC is already exceptionally good at inlining small functions, because it's just such a common pattern in Haskell.
Apr
15
answered Resources for improving your comprehension of recursion?