Some guy invented a language which he calls "Markdown":

   http://daringfireball.net/projects/markdown/

It's a markup langauge that looks almost like plain text, but he wrote a 
Perl script that can transform it into HTML with pretty formatting. 
(Stuff like lines prefixed with "-" become bullet points, words unclosed 
with "*" become italic, URLs become links, etc.)

That's pretty neat. But then a bunch of Haskell hackers came along and 
developed a program called Pandoc:

   http://johnmacfarlane.net/pandoc/

This translates Markdown into HTML, LaTeX (and therefore PDF), 
Micro$oft's Rich Text format, DocBook XML, OpenDocument XML, OpenOffice 
ODT, Texinfo or groff man, or even MediaWiki markup. It also adds a few 
new syntax constructs [which can be disabled for compatibility], and it 
follows the written Markdown language spec more closely than the Perl 
version does.

This tool is written entirely in Haskell. As we all know, Haskell is 
slower than all other programming languages. This explains how Pandoc 
manages to outperform the Perl Markdown script:

   Perl Markdown: 15 seconds
   Compiled Perl Markdown: 10 seconds
   Pandoc (compiled Haskell): 0.9 seconds

So, in summary:

- Pandoc handles Markdown more correctly than the author's own Perl 
implementation.
- Pandoc handles many more output formats than the author's own Perl 
implementation.
- Pandoc handles more syntax constructs than the author's own Perl 
implementation.
- Pandoc is approximately 10x faster than the author's own Perl 
implementation.

So it's more correct, has more features, and runs faster. I call that a win!

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> So it's more correct, has more features, and runs faster. I call that a win!

  But is it better specifically because it was made in Haskell, or is it
better simply because they made it better?

  If I make a Java version which supports a few more formats and is faster
than the Haskell version, does that mean that Java wins Haskell, or does
it mean I spent more time making it better? And if I make a C++ version
which is even faster, does that mean C++ wins all?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   But is it better specifically because it was made in Haskell, or is it
> better simply because they made it better?

This is the operative question.

First, notice that this application consists entirely of processing text 
strings in a complex way - which is practically what the entire Perl 
language was *designed* for from the very beginning. This is what many 
people consider to be Perl's greatest strength, and what Perl is 
supposedly highly optimised to do efficiently.

And yet, Haskell outperformed it, and matches the spec more exactly.

All of this *suggests* many things - significantly, that Haskell matches 
the spec more closely hints that Haskell makes complex algorithms 
"easier" to express, and so a closer match could be achieved.

But what does it *prove*? Well, strictly, nothing. Maybe the Perl 
implementation just sucks? Maybe the Perl version could easily be 
modified to be faster. Maybe there are bugs that could easily be fixed 
to make it fit the spec better too.

Actually, I take that back. It does prove one thing worth knowing: some 
people used Haskell to build a real-world tool that people who know 
nothing about Haskell actually use to do stuff. That's not an 
earth-shattering result, but it's an important one none the less.

> And if I make a C++ versionwhich is even faster, does that mean C++ wins all?

I was about to say "I'd be interested in seeing something like that", 
but then I realised that in my current state of learning, I wouldn't 
understand a word of it. :-S

Post a reply to this message

Invisible wrote:
> This tool is written entirely in Haskell. As we all know, Haskell is 
> slower than all other programming languages. This explains how Pandoc 
> manages to outperform the Perl Markdown script:

	Eh? Compiled Haskell's not all that slow. It beats scripting languages 
easily. Comparing it with Perl is not very illustrative of much.

-- 
Atheism is a non-prophet organization.


                     /\  /\               /\  /
                    /  \/  \ u e e n     /  \/  a w a z
                        >>>>>>mue### [at] nawazorg<<<<<<
                                    anl

Post a reply to this message

Mueen Nawaz wrote:

>     Eh? Compiled Haskell's not all that slow. It beats scripting 
> languages easily. Comparing it with Perl is not very illustrative of much.

How about compiled Perl then? Cos it beat that too...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> Mueen Nawaz wrote:
>
> >     Eh? Compiled Haskell's not all that slow. It beats scripting
> > languages easily. Comparing it with Perl is not very illustrative of much.
>
> How about compiled Perl then? Cos it beat that too...

Compiled Perl just means stored bytecode loading faster into Perl's VM/AST
/whatever.  Same for Python or Ruby.  The bytecode is still interpreted without
a JIT and those are still highly dynamic languages where code optimizations
through type analysis is very much impossible.

Haskell compiles to native code and is a static typeful language.  The
comparison is unfair.  Haskell also comes complete with a very succint syntax
reminiscent of Perl, except not quite as unreadable.  I think the time of Perl
has gone and suggest people trying Perl6 with Pugs to drop it and go Hugs
instead. :)

That said, there's no language out there to do batch flat file processing with
such ease and grace as Perl.  Not even Haskell or Ruby.  The problem, I guess,
is that it's a structured file format and handling it with regexes alone gets
ugly pretty fast... if they go for std XML processing instead, they have no
real advantage over any other languages doing the same...

Post a reply to this message

nemesis wrote:
> those are still highly dynamic languages where code optimizations
> through type analysis is very much impossible.

It's not impossible. It just hasn't been applied very much to those 
languages yet. You won't get the optimization that Haskell can get, but 
you can get much better than people currently get. The trick is to use 
run-time information to improve your run-time. Build a table at the 
dynamic dispatch sites that run often and cache the lookup results, for 
example. There are a number of recent (last year or two, up to next 
year) techniques that do a significantly good job, but I can't find the 
original article that discussed lots of the recent cutting-edge advances.

One such technique is
http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-06-16.pdf

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > those are still highly dynamic languages where code optimizations
> > through type analysis is very much impossible.
>
> It's not impossible.

Nothing is impossible, just pretty much unlikely. :)

> It just hasn't been applied very much to those
> languages yet.

The best I've ever seen for any dynamically typed language is the Stalin
compiler for the Lisp dialect Scheme.  It creates, from normal, unoptimized
Scheme code, very fast native code roughly approaching that of compiled C.
It's a true little wonder.  OTOH, it compiles a pretty static subset of Scheme:
 no eval, no load, no redefinitions of functions, no metaprogramming with
syntatic extensions and, though not dynamicism related, no arbitrary precision
arithmetic allowed.  Still, mighty impressive.

It does whole program compilation and lots of type inferencing to achieve that.
The code produced is very fast and quite small (though no match to the tiny C
executables), but the compiler itself, having to do all kinds of analysis in
the absence of type declarations, is probably the slowest you've ever seen.
Good thing any error messages are spot-on.

Languages like python and ruby abuse of their dynamic nature by going beyond
just dynamic typing and allowing all kinds of funky and slow runtime
metaprogramming.  A native compiler has no chance here.

> You won't get the optimization that Haskell can get, but
> you can get much better than people currently get. The trick is to use
> run-time information to improve your run-time.

Yes, it's what Hotspot does on the Java runtime and also what goes on on .NET's
CLR.  Not available to the official C runtimes of python, ruby and perl, except
when running on such VMs... still, I think their extreme dynamic nature makes
things difficult and allows for lots of sloppy style programming just for the
sake of it...

Post a reply to this message

>>>     Eh? Compiled Haskell's not all that slow. It beats scripting
>>> languages easily. Comparing it with Perl is not very illustrative of much.
>> How about compiled Perl then? Cos it beat that too...
> 
> Compiled Perl just means stored bytecode loading faster into Perl's VM/AST
> /whatever.  Same for Python or Ruby.  The bytecode is still interpreted without
> a JIT and those are still highly dynamic languages where code optimizations
> through type analysis is very much impossible.

Well OK. But given that the Perl version is presumably just making a 
half dozen calls to the internal regex engine, you'd still expect decent 
performance...

Anyway, whatever. My point is that Haskell isn't nearly as slow as 
everybody thinks it is.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Well OK. But given that the Perl version is presumably just making a
> half dozen calls to the internal regex engine, you'd still expect decent
> performance...

yes.  Something more is getting in the way.

> Anyway, whatever. My point is that Haskell isn't nearly as slow as
> everybody thinks it is.

It's not slow at all.  It's just not nearly as fast as C/C++, but then, few are.
 And fewer are as high level and concise as Haskell. :)

Post a reply to this message

nemesis wrote:

> yes.  Something more is getting in the way.

Like Warp suggested, maybe his Perl coding just sucks for some reason?

>> Anyway, whatever. My point is that Haskell isn't nearly as slow as
>> everybody thinks it is.
> 
> It's not slow at all.  It's just not nearly as fast as C/C++, but then, few are.
> And fewer are as high level and concise as Haskell. :)

Heh. The Haskell bods are currently real excited because Haskell is 
ranked 3rd is the new parallel benchmark table. (But then, most of the 
other languages haven't submitted any parallel code yet.) It's lagging 
behind C++, but just faster than C.

Of course, as somebody pointed out, the C and C++ implementations are 
using OS threads, while Haskell is using lightweight Haskell threads, 
"so it's not a fair comparison". Debate that if you will...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> nemesis wrote:
>
> > yes.  Something more is getting in the way.
>
> Like Warp suggested, maybe his Perl coding just sucks for some reason?

ah, that's it!  The thing between the chair and the keyboard...

> Heh. The Haskell bods are currently real excited because Haskell is
> ranked 3rd is the new parallel benchmark table. (But then, most of the
> other languages haven't submitted any parallel code yet.) It's lagging
> behind C++, but just faster than C.

I read the thread in the Haskell mailing-list.  Checking it out, both g++ and
ghc are behind some newcomer:  ATS.
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all

Yet Another High Level Language with C syntax and performance and functional
programming semantics.  Joining D for candidates for next C/C++.

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Yet Another High Level Language with C syntax and performance and functional
> programming semantics.  Joining D for candidates for next C/C++.

  Like D (and a bunch of others), also probably doomed to failure.

  Many people have attempted in making a "better" C/C++, and many have
failed. Some attempts have good ideas, but they just don't get popular,
no matter how much they are advertised. Basically nobody knows what D is.
Another good example is Objective C, which has a rather small market
(which is growing a bit due to the iPhone, though).

  Not all attempts have failed though. Java and C# are examples of
successful ones. (Although in their cases the changes from C/C++ have
been a bit more radical.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Another good example is Objective C, which has a rather small market
> (which is growing a bit due to the iPhone, though).

I thought all the NeXT and thus Mac OSX stuff was programmed in 
Objective-C? (Which was around even before the NeXT, also.)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Warp wrote:

> Basically nobody knows what D is.

I recall seeing a language floating around (a *long* time ago!) called 
E, and another called F.

IIRC, the language before C was called B, so it's quite possible that 
more than one person has come up with a "better than C" language and 
called it "D" or "E" or whatever... ;-)

>   Not all attempts have failed though. Java and C# are examples of
> successful ones. (Although in their cases the changes from C/C++ have
> been a bit more radical.)

The conspicuous thing is that both of those languages are backed be huge 
well-known corporations...

Post a reply to this message

nemesis wrote:
> Languages like python and ruby abuse of their dynamic nature by going
> beyond just dynamic typing and allowing all kinds of funky and slow
> runtime
> metaprogramming.  A native compiler has no chance here.

But also, languages like python and ruby are often used where performance
doesn't really matter. Last I checked, the de-facto implementation (CPython
interpreter) doesn't even do constant folding.

Post a reply to this message

Darren New wrote:
> Warp wrote:
>> Another good example is Objective C, which has a rather small market
>> (which is growing a bit due to the iPhone, though).
> 
> I thought all the NeXT and thus Mac OSX stuff was programmed in
> Objective-C? (Which was around even before the NeXT, also.)

Yes. All apps on Mac are made in Objective-C. Non-GUI Objective-C code from
a Mac application can probably run unmodified on the iPhone. It's just the
GUI frameworks that changed completely.

Post a reply to this message

Invisible wrote:
> IIRC, the language before C was called B, so it's quite possible that
> more than one person has come up with a "better than C" language and
> called it "D" or "E" or whatever... ;-)

Do you know why C# is called that way?

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Invisible wrote:
> > IIRC, the language before C was called B, so it's quite possible that
> > more than one person has come up with a "better than C" language and
> > called it "D" or "E" or whatever... ;-)

> Do you know why C# is called that way?

  Well, when it was a pretty new thing, I heard that # in the name was
actually four + symbols, so it's C++++, ie. "C# is to C++ what C++ is
to C".

  I don't know if it was just a joke.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Well, when it was a pretty new thing, I heard that # in the name was
> actually four + symbols, so it's C++++, ie. "C# is to C++ what C++ is
> to C".

Given that it's pronounced "C Sharp", I expect it's because it's half a 
note higher than C. Like, on a piano keyboard.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:
> Warp wrote:
>>   Well, when it was a pretty new thing, I heard that # in the name was
>> actually four + symbols, so it's C++++, ie. "C# is to C++ what C++ is
>> to C".
> 
> Given that it's pronounced "C Sharp", I expect it's because it's half a
> note higher than C. Like, on a piano keyboard.

That's the one.

C++ is C postincremented by 1 in C syntax.
C# is C incremented by one semitone in musical syntax.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Well, when it was a pretty new thing, I heard that # in the name was
> > actually four + symbols, so it's C++++, ie. "C# is to C++ what C++ is
> > to C".
>
> Given that it's pronounced "C Sharp", I expect it's because it's half a
> note higher than C. Like, on a piano keyboard.

Yes.  Java decided to diss C/C++ by dropping any mention to it in the name, but
Microsoft in their infinite marketing wisdom felt they should instead try to
get to the hearts of old C/C++ folks.  They also catered for buying managers by
substituting the irrelevant term "bytecode" for "managed code":  you know, if
it's managed, it knows its place. :)

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> But also, languages like python and ruby are often used where performance
> doesn't really matter.

The sad thing is that the places where performance shouldn't really matter is
the place where C/C++/Java/C# are firmly entrenched:  running custom apps in TI
sections of non-software developer firms.  It doesn't matter because such apps
are not usually infrastructure and if more performance is needed, it should
suffice to just throw more hardware.  OTOH, throwing more programmers at late
projects is a bad idea, according to Fred Brooks...

Post a reply to this message

nemesis wrote:
> substituting the irrelevant term "bytecode" for "managed code":  

Bytecode comes from Smalltalk, where each opcode was a byte. "Managed 
code" means your resources are managed by the VM. So they really do mean 
different orthogonal things.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> The sad thing is that the places where performance shouldn't really matter is
> the place where C/C++/Java/C# are firmly entrenched:  running custom apps in TI
> sections of non-software developer firms.

  I think that one reason for that is the vast amount of libraries available
for those languages, as well as the amount of programmers with experience.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   I think that one reason for that is the vast amount of libraries available
> for those languages, as well as the amount of programmers with experience.

I think Haskell won't start really winning big-time until it has at 
least one or other of those things.

Post a reply to this message

Nicolas Alvarez wrote:

> C++ is C postincremented by 1 in C syntax.

Strictly, shouldn't it be ++C? I mean, "C++" would have the same value 
as "C" (yet incrimenting C afterwards).

> C# is C incremented by one semitone in musical syntax.

That's a noteworthy fact.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > substituting the irrelevant term "bytecode" for "managed code":
>
> Bytecode comes from Smalltalk, where each opcode was a byte. "Managed
> code" means your resources are managed by the VM. So they really do mean
> different orthogonal things.

But that's not the point.  The point is that "bytecode" running in a "VM" were
suplanted by "managed code" because that sounds better to manager ears:  if
it's managed, then it's code that know its place and works in schedule. ;)

Microsoft are marketing geniuses.

Post a reply to this message

nemesis wrote:

> Microsoft are marketing geniuses.

Finally, a comment I won't disagree with...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

nemesis wrote:
> Microsoft are marketing geniuses.

I think that goes without saying.  (Yes, I understood what you were 
saying. I was just clarifying where the terms came from, in general, 
showing off my big brain. ;-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Thu, 25 Sep 2008 13:13:17 -0400, nemesis wrote:

> Microsoft are marketing geniuses.

Actually, they're not - their marketing is outsourced. ;-)

Jim

Post a reply to this message

Invisible wrote:
> Strictly, shouldn't it be ++C? I mean, "C++" would have the same value
> as "C" (yet incrimenting C afterwards).

You're not the first pedant to mention that.

Post a reply to this message

>> Strictly, shouldn't it be ++C? I mean, "C++" would have the same value
>> as "C" (yet incrimenting C afterwards).
> 
> You're not the first pedant to mention that.

Yay, me!

Post a reply to this message