8 ms·

Does anyone know why functional programming languages are so much favored by research teams over other types of PL ? Every time i hear someone doing PL researc

• miga 13y ago
  Elegant structure with simple core, and closeness to mathematical foundations makes complexities more clear and tractable.
• DanWaterworth 13y ago
  Enforced purity makes lots of things much easier, STM is a prime example.
• tomp 13y ago
  It's not about functional programming languages per se, it's just that a lot of core/academic PL research often focuses much more on concepts than on implementation, and languages with strong type systems (all of which are functional, in part also because OO/subtyping is hard to reason about formally) are ideal for encoding these concepts. There is, however, a lot of research about implementation going on using other languages as well. Most GC research, for example, is done using JVM and Java programs. For this particular paper, it would be really hard to choose a different platform, though, because GHC is one of the rare industrial runtimes that offer lightweight threads.
  • pron 13y ago
    Exactly. And low-level concurrency research (snapshot algorithms, n-cas) is usually done in C or Java, and so on. BTW, Java has lightweight threads, too: https://github.com/puniverse/quasar https://github.com/puniverse/quasar (I'm the main author)
    • dubbledidu 13y ago
      Eh... what exactly is "lightweight" about your threads? As far as I see you still use the same, standard JVM threads everyone uses, combined with a thread pool. What am I missing?
      • pron 13y ago
        No, these are true lightweight threads (implemented on top of an OS-thread pool, just as they are in Erlang and, I suppose, Haskell). You can have hundreds of thousands or even millions of these on a single machine. They can block for IO or for any other kind of synchronization (message passing etc.), just like regular threads.
        • dons 13y ago
          Are they preemptive?
          • pron 13y ago
            Absolutely. Currently fibers (lightweight threads) may only be preempted when performing a blocking operation (IO or waiting on some synchronization mechanism). We will implement time-share based preemption if we see a need for that.
        • VladRussian2 13y ago
          whenever i hear "lightweight threads" my PTSD from experience with Java "green threads" comes back. Of course, my rational mind understands that many years have passed and things may in other runtimes be implemented differently and there are many benefits vs. native, yet ...
          • pron 13y ago
            This has little, if any, to do with that. These lightweight threads are implemented pretty much exactly as they're implemented in Erlang or Go.
      • piranha 13y ago
  • James_Duval 13y ago
    Potentially stupid question: Would they not use Clojure or Scala rather than Java?
    • tomp 13y ago
      Doesn't matter really. For the GC research I mentioned, they usually just change one of the JVMs, so what they care about is only bytecode. Then, you need real programs to test on (improvements in throughtput, pause times, fragmentations, etc), which usually means Java programs but really doesn't matter.
  • seanmcdirmid 13y ago
    > all of which are functional, in part also because OO/subtyping is hard to reason about formally OO subtyping is hard to reason about formally in formal systems designed for FP...news at 11! I jest. The reason FP does so well academically is that no one knows how to rigorously evaluate something that isn't theoretical (since FP is close to math anyways) or performance-based (most other PL work). The Haskell crowd is also very creative so they do a lot of cool stuff. However, many of their ideas are transferrable to other languages without the FP ideology. The OO people have something to offer also, but we've been kind of muted lately.
    • octo_t 13y ago
      >> OO subtyping is hard to reason about formally in formal systems designed for FP...news at 11! Well. Even systems like L2 (which are not functional) find subtyping difficult. It becomes difficult in the presence of overloading and overriding.
      • gngeal 13y ago
        I believe there's a nice book called Foundations of Object Oriented Languages which dissects the problem in depth.
        • gtani 13y ago
          Pierce's TAPL, also, and Harper's Practical Foundations. There's also some things i've seen about how scala does it, but I'll have to dig for them http://www.cs.cmu.edu/~rwh/plbook/book.pdf http://www.cs.cmu.edu/~rwh/plbook/book.pdf
          • octo_t 13y ago
            See also the DOT calculus[1] (Dependent Object Types) being the basis for a new foundation for scala's type system [1] - https://github.com/namin/dot https://github.com/namin/dot
    • dubbledidu 13y ago
  • colanderman 13y ago
    > (all of which are functional, in part also because OO/subtyping is hard to reason about formally) OO/subtyping is NOT orthogonal to functional, nor is it inherently at odds with formal reasoning. OCaml has both imperative and functional objects; Haskell, Mercury, and Coq (a formal logic language) all support typeclasses, which subsume most of OO and provide subtyping. Additionally, strong typing has little to do with formal reasoning as well (see: Lisp/Scheme/the lambda calculus). What makes functional languages amenable to formal methods is that they are functional and therefore referentially transparent. Mathematical proofs carry no implicit concept of "state"; hence if you are trying to prove anything about code in, say, C, you need to augment the code with explicit state and remove all non-local effects. (See: the Why language, which attempts to bridge this gap.) Algebraic/generalized-algebraic type constructors used by most functional languages don't hurt either, as they allow programs to construct complex terms without relying on lower-level stateful abstractions such as memory allocation.
    • Locke1689 13y ago
      hence if you are trying to prove anything about code in, say, C, you need to augment the code with explicit state and remove all non-local effects. (See: the Why language, which attempts to bridge this gap.) Actually, you just need to augment your model with notions of state, which is standard in operational semantics. It can just be harder to prove things in a complex model, so theorists prefer simplification when possible.
    • tomp 13y ago
      Not inherently, no, but practically, yes. The type system of, say, Java, isn't even formally sound; overridden functions can be covariant in parameter types, which would not be permissible in a proper subtype-based type system such as OCaml's.
      • colanderman 13y ago
        Ah yes, I forgot about Java's failings in this area.
• helloTree 13y ago
  Because (static) FP is built on a sound and rich theory (type theory and lambda calculus) unless other language paradigms (e.g. OO). There are also different approaches, IMHO: FPL research: Ok, we have this cool way to describe our computation. But how can we efficiently map this to the HW? In essence build a nice language and find an implementation. Imperative PL research: Ok, we have this HW, how can we build an expressive PL on top of it? In essence build an implementation (the HW) and find a language.
  • jjindev 13y ago
    Microprocessors evolved while chasing minicomputer features, which in term were shaped by C/UNIX sorts of ideas, which expanded and fed back. That was a very successful co-evolution. COTS supercomputers beat specialized hardware and specialized forms of parallelism not because they were abstractly better, but because markets and economies of scale drive whatever is popular to be the best performing and cheapest over time. (Down to $30 UNIX systems on a board.) The two language schools you describe seem to be asking whether it is time (whether we have enough capacity) to simply float a new more mathematical world view on top of it all, or whether we should continue to play toward the strengths of the commodity hardware stack. I personally think that something like Go works for my mind, and the hardware. (I will go make coffee now, rather than "define coffee" and wait for it to appear ;-)
  • eli_gottlieb 13y ago
    There are plenty of papers published giving calculi and type-safety proofs for object-oriented languages.
• vidarh 13y ago
  FP is a fertile topic for CS research in part because writing good compilers for FP languages is hard and poses lots of challenging questions for people to try to answer. Most really low level code generation and parsing research etc. will apply across the board or at least cover a wide range of type of languages (e.g. register allocation, instruction selection). But consider type theory - a language like Haskell providers a lot wider scope for research in that area than e.g. C. Or garbage collection - admittedly that's more widely applicable, but many FP languages throw an extra factor into the mix with immutable variables. Etc. But there's certainly other PL research as well. E.g. all the work that's gone into Javascript compilers in the last few years. Trace trees came out of work done on a JVM for example.
• danking00 13y ago
  The HN community is particularly receptive to functional programing. HN itself is written in Arc which is a language implemented in Racket. There's still active research in Fortran i.e. for super computers etc., check out the SIGPLAN Fortran Forum [1]. OOPSLA/SPLASH has lots of non-functional language research [2]. Also check out PLDI, arguably one of the most prestigious PL conferences. Scala, Dart, and LLVM feature in their tutorials section [3]. [1] http://dl.acm.org/citation.cfm?id=J286 http://dl.acm.org/citation.cfm?id=J286 [2] http://splashcon.org/2012/program/oopsla-research-papers http://splashcon.org/2012/program/oopsla-research-papers [3] http://pldi2013.ucombinator.org/tutorials.html http://pldi2013.ucombinator.org/tutorials.html
  • seanmcdirmid 13y ago
    Don't forget SPLASH Onward! [1], which is a fun conference for new PL ideas. [1] http://splashcon.org/2012/program/onward-papers http://splashcon.org/2012/program/onward-papers
  • VintageCool 13y ago
    HN also sits inside a center tag using a table with width="85%", as I recently found out while trying to override its CSS rules. It's bizarre that an organization so forward looking uses deprecated html tags. <body><center><table border=0 cellpadding=0 cellspacing=0 width="85%" bgcolor=#f6f6ef>
• chrisseaton 13y ago
  I know that part of the reason I like FP is that a compiler is usually a pretty perfect pure function - source code -> machine code. So those people researching languages will often find that FP is the best tool for their job and will be most familiar with it. Then when they come to research something new they do it in the context they're most familiar with.
  • seanmcdirmid 13y ago
    Symbol table, multiple passes, iterative processing.... The state is not event-based in nature but does exist.
    • icarus127 13y ago
      Having state does not mean a function/algorithm is not pure.
      • seanmcdirmid 13y ago
        http://en.wikipedia.org/wiki/Pure_function http://en.wikipedia.org/wiki/Pure_function
        • Peaker 13y ago
          Pure functions model state nicely. compile :: Source -> Core optimizer :: Core -> Core nativeCode :: Core -> Assembly
          • seanmcdirmid 13y ago
            Those are just signatures, what is going on inside the boxes? Also, how does one encode iterative computation, like a data-flow analysis, in Haskell? And symbol tables? Is it sufficient that the symbol table is encapsulated within compile even if it involves dictionary read/writes? I'm genuinely curious.
            • 13y ago
• szany 13y ago
  “Programming languages are not arbitrary. They are manifestations of deep invariants of human thought, i.e. they are grounded in logic.” —Bob Harper Logic ~ Type theory ~ Functional programming
• gngeal 13y ago
  Does anyone know why functional programming languages are so much favored by research teams over other types of PL ? That's like asking why algebra is preferred among mathematicians over randomly pushing operators and parentheses around hoping that it will work this time.
• chowells 13y ago
  For this specific example? This isn't really a research project, in the normal sense of the term. This is a report of a very thorough engineering effort to fix the scaling of the IO manager already in GHC. It doesn't invent anything new. It does detail every issue they found and how they dealt with it. One thing I'm surprised no one has mentioned is that they found a race condition in epoll that's existed since version 2.4 of the linux kernel.