Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mio: A High-Performance Multicore IO Manager for GHC [pdf]

haskell.cs.yale.edu

Post reply on HN
Print view View original

21–30 of 81 posts

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#21

Post by tomp »

James_Duval wrote: post #19
tomp wrote: post #12

Earlier quoted context omitted.

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 othe…

Potentially stupid question: Would they not use Clojure or Scala rather than Java?

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.

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#22

Post by danking00 »

bsaul wrote: post #9

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 research, it's always on some kind of functional programming language such as Haskell or ML.

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 [2] http://splashcon.org/2012/program/oopsla-research-papers [3] http://pldi2013.ucombinator.org/tutorials.html

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#23

Post by miga »

fauigerzigerk wrote: post #16

I've been wondering about garbage collection in pure functional languages lately. It is often said that statically typed pure functional languages allow the compiler to do a lot more correctness checking. Shouldn't the same formal reasoning features also enable much better garbage collection algorithms? Or would that be asking for a solution to the halting problem?

And also there are interesting approaches to "GC optimizations", but so far unported to Haskell: http://www.it.edu/people/mael/mypapers/tldi03.pdf

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#24

Post by chrisseaton »

bsaul wrote: post #9

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 research, it's always on some kind of functional programming language such as Haskell or ML.

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.

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#25

Post by seanmcdirmid »

tomp wrote: post #12
bsaul wrote: post #9

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 research, it's always on some kind of functional programming language such as Haskell or ML.

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 othe…

> 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.

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#26

Post by seanmcdirmid »

danking00 wrote: post #22
bsaul wrote: post #9

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 research, it's always on some kind of functional programming language such as Haskell or ML.

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…

Don't forget SPLASH Onward! [1], which is a fun conference for new PL ideas.

[1] http://splashcon.org/2012/program/onward-papers

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#27

Post by octo_t »

seanmcdirmid wrote: post #25
tomp wrote: post #12

Earlier quoted context omitted.

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 othe…

> 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…

>> 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.

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#28

Post by szany »

bsaul wrote: post #9

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 research, it's always on some kind of functional programming language such as Haskell or ML.

“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

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#29

Post by petsos »

gnuvince wrote: post #5
quchen wrote: post #2

The file also states that "Mio will be released as part of GHC 7.8.1", which is scheduled around October if I recall correctly. Neat

Painful to hear about such wonderful developments when you are a Debian Stable user :(

Well, you get what you ask for.

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#30

Post by fauigerzigerk »

miga wrote: post #23
fauigerzigerk wrote: post #16

I've been wondering about garbage collection in pure functional languages lately. It is often said that statically typed pure functional languages allow the compiler to do a lot more correctness checking. Shouldn't the same formal reasoning features also enable much better garbage collection algorithms? Or would that be asking for a solution to the halting problem?

And also there are interesting approaches to "GC optimizations", but so far unported to Haskell: http://www.it.edu/people/mael/mypapers/tldi03.pdf

Thanks, unfortunately I'm getting a 404 Not Found when I click on the link...
Post reply on HN