For PDF generation, there are other markdown solutions as well. Even within 
pandoc, pandoc recently added a PDF writer that uses `wkhtmltopdf` instead 
which is much faster. If you need LaTeX generated PDF for quality, 
Multimarkdown also does that. (But I doubt the difference in speed between 
MMD and pandoc would be relevant here because LaTeX is the bottleneck.) By 
the way, I personally finding that if LaTeX output is needed, using pandoc 
is much easier and powerful than using MultiMarkdown. In principle 
everything doable on one can be done in other system, but it is very 
difficult to handle the complexity in MMD, especially when multi-output is 
needd.

About the Haskell in Science: I should be more careful in the wordings. 
What I said is all about scientific programming. In fact, Haskell looks 
like as if it remains a CS research language more than a wide-spread 
language for people other that computer scientists. In the very general 
sense of Haskell's presence in science, it is undeniable, but that doesn't 
really mean anything practically.

And regarding programming language of choice, in Sience we almost always 
need to collaborate (expecially if it involves experiments and computing). 
I can guarantee my failure in the field if I write anything in Haskell. You 
will be surprised to know that people in my group even oppose to the idea 
of writing code in C/C++ and prefer everything in Python (or else use 
another library and don't care what language they are actually written). So 
I cheat and write C/C++ using Cython. And viola, I give them "Python code". 
But I hate it when I knew there's some optimzation I can do in C/C++ and 
Cython don't support it (e.g. compiler hints, SIMD vectorization, Intel 
intrinsics, etc.), and Python bool/complex vs. C++ bool/complex is a a bit 
of a problem in Cython too.

I'm not Haskell expert so I can't say for certain. But Haskell's "failure" 
in scientific computing might be intrinsic, because most of the scientific 
computing are numerical, and very procedural (sometimes because of 
optimzation). e.g. the simplest example is matrix multiplication, which 
essentially is 1 line of code in 3 nested loops in terms of the Math. But 
it turns into a huge code base for different properties of the matrix and 
different optimization to be used, etc.

But I don't think we can, and I'm also not to, deny a language's success by 
saying it is not successful in 1 field (scientific computing here). What I 
was saying is that I wish this is not true, because Haskell is such a 
mathematical language. To solve math problem in such language would 
probably be a delightful experience. Or in order words, probably it is just 
a wishful thinking to wish that we don't have to worry about algorithm 
(which Haskell helps you in this regards), but currently compiler are still 
not advanced enough for us to not worry about this. That's why I'm excited 
by the Intel's research compiler because it seems like it is trying to 
optimize functional language in a very general way (Haskell is just 1 
example), and in some cases it can beat hand-tuned C code (although their 
compiler actually generates intermediate C codes).

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/b9d11088-d6ac-432b-8206-03e1962d66a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.