Discussion:
LISP vs HASKELL vs PROLOG
(too old to reply)
fft1976
2009-07-10 08:10:49 UTC
Permalink
So what do you want from a programming language?
Excellent question. I've never really tried to enumerate it before...
(snip)

This "being functional" is an unhealthy obsession. 3/4 of the time
imperative idioms are more convenient, and 1/4 of the time functional
ones are more convenient.

But because most popular languages are imperative, people are whining
about those 1/4 cases and some disturbed individuals even think
languages should be pure-functional.

What I want is a safe (or has an option to be safe), fast mostly
imperative language that doesn't suck.

C++ (if you are very good and very careful), Java and OCaml are
decent, but not quite what I want. Maybe D and Ada, although I don't
know about those.
Frank Buss
2009-07-10 08:23:46 UTC
Permalink
Post by fft1976
What I want is a safe (or has an option to be safe), fast mostly
imperative language that doesn't suck.
C++ (if you are very good and very careful), Java and OCaml are
decent, but not quite what I want. Maybe D and Ada, although I don't
know about those.
You could try Common Lisp: It is nice for imperative code and doesn't suck
as much as C++ for functional code :-)
--
Frank Buss, ***@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
fft1976
2009-07-10 08:34:49 UTC
Permalink
Post by Frank Buss
Post by fft1976
What I want is a safe (or has an option to be safe), fast mostly
imperative language that doesn't suck.
C++ (if you are very good and very careful), Java and OCaml are
decent, but not quite what I want. Maybe D and Ada, although I don't
know about those.
You could try Common Lisp: It is nice for imperative code and doesn't suck
as much as C++ for functional code :-)
It's probably inconceivable to you, but I, like 99.9% of other
programmers, respectfully disagree.
Alessio Stalla
2009-07-10 09:19:45 UTC
Permalink
Post by fft1976
Post by Frank Buss
Post by fft1976
What I want is a safe (or has an option to be safe), fast mostly
imperative language that doesn't suck.
C++ (if you are very good and very careful), Java and OCaml are
decent, but not quite what I want. Maybe D and Ada, although I don't
know about those.
You could try Common Lisp: It is nice for imperative code and doesn't suck
as much as C++ for functional code :-)
It's probably inconceivable to you, but I, like 99.9% of other
programmers, respectfully disagree.
I hope you don't disagree about C++ sucking at functional
programming... so you must disagree about Lisp being nice at
imperative code. While for heavily imperative algorithms, C-like
languages are likely to be more compact than Lisp (whether this
implies "more readable" depends on the reader), I find in my
experience with Java, and C++ shouldn't be much different, that in
practice heavily imperative code tends to be scarcer than what people
commonly think. Most of my Java methods are less than 20 lines long,
many are shorter. And of those lines, half or so at least are calls to
other methods, not loops or assignments or increments etc.

Maybe your experience is different. But for me, Lisp is more than fine
for occasional imperative code. Of course, if you try to write C in
Lisp it will come out pretty horrible, just like if you try to write
Lisp in Java (sigh...).

Cheers,
Alessio
George Neuner
2009-07-10 17:25:40 UTC
Permalink
On Fri, 10 Jul 2009 02:19:45 -0700 (PDT), Alessio Stalla
Post by Alessio Stalla
Post by fft1976
Post by Frank Buss
Post by fft1976
What I want is a safe (or has an option to be safe), fast mostly
imperative language that doesn't suck.
C++ (if you are very good and very careful), Java and OCaml are
decent, but not quite what I want. Maybe D and Ada, although I don't
know about those.
You could try Common Lisp: It is nice for imperative code and doesn't suck
as much as C++ for functional code :-)
It's probably inconceivable to you, but I, like 99.9% of other
programmers, respectfully disagree.
I hope you don't disagree about C++ sucking at functional
programming... so you must disagree about Lisp being nice at
imperative code. While for heavily imperative algorithms, C-like
languages are likely to be more compact than Lisp (whether this
implies "more readable" depends on the reader), I find in my
experience with Java, and C++ shouldn't be much different, that in
practice heavily imperative code tends to be scarcer than what people
commonly think. Most of my Java methods are less than 20 lines long,
many are shorter. And of those lines, half or so at least are calls to
other methods, not loops or assignments or increments etc.
Lots of little functions != functional programming

C++ and Java make functional programming possible, but neither makes
it particularly easy. It might get better in C++0X with the addition
of standard closures, but I doubt it ... the proposed syntax is too
messy and too similar to what Boost does now (which is horrible if
you've ever used a real FPL). Java's closures are no better ... far
too messy to use anonymously.

C++ at least has a simple function object syntax which doesn't
distract the programmer when using higher level functions - Java can't
even get that right. But the lack of multiple runtime dispatch in
both language forces unnatural, imperative "pattern" coding (C++ has
multiple compile time dispatch, but it's not the same).
Post by Alessio Stalla
Maybe your experience is different. But for me, Lisp is more than fine
for occasional imperative code. Of course, if you try to write C in
Lisp it will come out pretty horrible, just like if you try to write
Lisp in Java (sigh...).
A lot of Lisp programmers write what is essentially imperative code.
The only real difference is that they typically use binding more than
assignment. Personally I hate LOOP ... I learned it so I can read
other people's code, but I never use it myself.

George
George Neuner
2009-07-10 17:04:37 UTC
Permalink
Post by fft1976
Post by Frank Buss
You could try Common Lisp: It is nice for imperative code and doesn't suck
as much as C++ for functional code :-)
It's probably inconceivable to you, but I, like 99.9% of other
programmers, respectfully disagree.
You mean the 99.9% who have never tried Lisp?

Common Lisp (_not_ Scheme) offers assignment and imperative control
constructs - a variety of standard loops, case and typecase (like C
switch), labeled gotos, lexical block structures with named exit, etc.
Using named blocks, labels and gotos, you can define your own control
structures if you don't like the standard ones.

Although most programmers prefer to write in a more functional style,
Lisp's imperative constructs are used extensively for DSL code
generators and foreign code translators (C->Lisp, Pascal->Lisp,
SQL->Lisp, etc.).

That said, Lisp isn't for everyone ... if you don't like it - fine.
Just don't knock it without trying it.

George
Jon Harrop
2009-07-10 19:36:55 UTC
Permalink
Post by George Neuner
Post by fft1976
Post by Frank Buss
You could try Common Lisp: It is nice for imperative code and doesn't
suck as much as C++ for functional code :-)
It's probably inconceivable to you, but I, like 99.9% of other
programmers, respectfully disagree.
You mean the 99.9% who have never tried Lisp?
You say that as if Lisp had not been taught to millions of computer science
students, 99.9% of whom really do choose not to use Lisp.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
!!!@!!!
2009-07-10 18:46:45 UTC
Permalink
You guys really are amazing!!! You're so good at starting flame
wars!!! I don't understand why you make such useless debates about
which programming languages is the best ?!?! Haven't you yet realised
that you'll never come to a mutual opinion because you have different
preferences and jobs that require different tools!?!?! You make
robotic arguments of these languages features, sometimes without even
have trying programming in these languages and you sound like you are
reading a definition from an encyclopedia with a comunist like voice
protecting his beloved mother language!!!
Frank Buss
2009-07-10 18:54:04 UTC
Permalink
Post by !!!@!!!
You guys really are amazing!!! You're so good at starting flame
wars!!! I don't understand why you make such useless debates about
which programming languages is the best ?!?! Haven't you yet realised
that you'll never come to a mutual opinion because you have different
preferences and jobs that require different tools!?!?! You make
robotic arguments of these languages features, sometimes without even
have trying programming in these languages and you sound like you are
reading a definition from an encyclopedia with a comunist like voice
protecting his beloved mother language!!!
Hello !!!@!!!,

I know that many people discussing in this thread have much experience in
multiple languages and in the languages they are talking about. Maybe you
are talking to yourself regarding lack of experience?
--
Frank Buss, ***@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
!!!@!!!
2009-07-10 19:07:52 UTC
Permalink
Post by Frank Buss
I know that many people discussing in this thread have much experience in
multiple languages and in the languages they are talking about. Maybe you
are talking to yourself regarding lack of experience?
See???
This is what I was talking about.
These arguments are useless and a waste of time.
I am very thankful to you Frank that troubled yourself to post here
and answer the questions of an 'lacked-experience' guy like me but if
you don't have any other piece of wisdom to share with us I suggest
you to not waste your time and tire your fingers to write here.
But I supose you don't take suggestions from guys like me, do you?
Ertugrul Söylemez
2009-07-10 19:32:39 UTC
Permalink
Post by !!!@!!!
Post by Frank Buss
I know that many people discussing in this thread have much
experience in multiple languages and in the languages they are
talking about. Maybe you are talking to yourself regarding lack of
experience?
See???
This is what I was talking about.
These arguments are useless and a waste of time.
I am very thankful to you Frank that troubled yourself to post here
and answer the questions of an 'lacked-experience' guy like me but if
you don't have any other piece of wisdom to share with us I suggest
you to not waste your time and tire your fingers to write here. But I
supose you don't take suggestions from guys like me, do you?
http://xkcd.com/114/

=)


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
!!!@!!!
2009-07-10 19:47:24 UTC
Permalink
Post by Ertugrul Söylemez
http://xkcd.com/114/
=)
Greets,
Ertugrul.
Completely appropriate with the case here.
Nice one :D
Rob Warnock
2009-07-10 23:02:08 UTC
Permalink
Ertugrul Söylemez <***@ertes.de> wrote:
+---------------
| "!!!@!!!" <***@gmail.com> wrote:
| > if you don't have any other piece of wisdom to share with us I suggest
| > you to not waste your time and tire your fingers to write here. But I
| > supose you don't take suggestions from guys like me, do you?
|
| http://xkcd.com/114/
+---------------

Or more generally, <http://xkcd.com/386/>.


-Rob

-----
Rob Warnock <***@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Jon Harrop
2009-07-11 00:45:32 UTC
Permalink
Post by !!!@!!!
You guys really are amazing!!! You're so good at starting flame
wars!!! I don't understand why you make such useless debates about
which programming languages is the best ?!?! Haven't you yet realised
that you'll never come to a mutual opinion because you have different
preferences and jobs that require different tools!?!?! You make
robotic arguments of these languages features, sometimes without even
have trying programming in these languages and you sound like you are
reading a definition from an encyclopedia with a comunist like voice
protecting his beloved mother language!!!
I am implementing a VM and language. I appreciate peer review of my ideas.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
George Neuner
2009-07-10 23:57:26 UTC
Permalink
Post by Jon Harrop
Post by George Neuner
Post by fft1976
Post by Frank Buss
You could try Common Lisp: It is nice for imperative code and doesn't
suck as much as C++ for functional code :-)
It's probably inconceivable to you, but I, like 99.9% of other
programmers, respectfully disagree.
You mean the 99.9% who have never tried Lisp?
You say that as if Lisp had not been taught to millions of computer science
students, 99.9% of whom really do choose not to use Lisp.
I'd wager there haven't been even 1 million CS students total in the
60+ years since electronic computers were invented. And Lisp wasn't
TAUGHT to the vast majority of them ... most received a simplistic 3
lecture introduction to the language, wrote a handful of recursive
functions and maybe did a semester project. That hardly qualifies as
"being taught" the language.

Beside which, for the last 30 years, most CS programs based on Lisp
have actually used Scheme rather than Lisp.

George
Jon Harrop
2009-07-11 02:03:30 UTC
Permalink
Post by George Neuner
Post by Jon Harrop
Post by George Neuner
Post by fft1976
Post by Frank Buss
You could try Common Lisp: It is nice for imperative code and doesn't
suck as much as C++ for functional code :-)
It's probably inconceivable to you, but I, like 99.9% of other
programmers, respectfully disagree.
You mean the 99.9% who have never tried Lisp?
You say that as if Lisp had not been taught to millions of computer
science students, 99.9% of whom really do choose not to use Lisp.
I'd wager there haven't been even 1 million CS students total in the
60+ years since electronic computers were invented.
According to this:

http://www.cra.org/taulbee/CRATaulbeeReport-StudentEnrollment-07-08.pdf

The US enrolls ~300 CS students in ~200 institutions every year. So the US
alone teaches 600,000 CS students every decade and the US is only 5% of the
world's population.

According to this:

http://www.forbes.com/2007/08/05/india-higher-education-oped-cx_prg_0813education.html

China produces more than twice as many CS PhD as the US. So the US and China
alone have probably produced over a million CS graduates in the last decade
alone.
Post by George Neuner
And Lisp wasn't
TAUGHT to the vast majority of them ... most received a simplistic 3
lecture introduction to the language, wrote a handful of recursive
functions and maybe did a semester project. That hardly qualifies as
"being taught" the language.
Beside which, for the last 30 years, most CS programs based on Lisp
have actually used Scheme rather than Lisp.
Excuses excuses. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Vassil Nikolov
2009-07-11 21:26:02 UTC
Permalink
Post by Jon Harrop
Post by George Neuner
Post by Jon Harrop
...
You say that as if Lisp had not been taught to millions of computer
science students, 99.9% of whom really do choose not to use Lisp.
I'd wager there haven't been even 1 million CS students total in the
60+ years since electronic computers were invented.
http://www.cra.org/taulbee/CRATaulbeeReport-StudentEnrollment-07-08.pdf
The US enrolls ~300 CS students in ~200 institutions every year. So the US
alone teaches 600,000 CS students every decade and the US is only 5% of the
world's population.
http://www.forbes.com/2007/08/05/india-higher-education-oped-cx_prg_0813education.html
China produces more than twice as many CS PhD as the US. So the US and China
alone have probably produced over a million CS graduates in the last decade
alone.
It is rather more difficult to produce even merely decent
statistics. For one, not all computer science graduates write
programs after graduation, in any programming languages; and then
many of those who do write programs are not computer science
graduates (so less likely, if at all, to have been taught Lisp by
the above argument). Then even the numbers above need adjustment,
because enrolling 3e2 (students/institution)/year in 2e2
institutions does not make 6e5 _distinct_ students each decade
(probably somewhere between 1e5 and 2e5). Note that I do not claim
to know what the numbers are, merely that some more information must
be supplied for a good argument.

By the way, the choice of programming language is in many cases not
the choice of the individual programmer, and those who make or
influence such decisions are not necessarily a representative sample
of all computer science graduates.

---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
toby
2009-07-12 00:45:06 UTC
Permalink
Post by Jon Harrop
Post by George Neuner
Post by fft1976
Post by Frank Buss
You could try Common Lisp: It is nice for imperative code and doesn't
suck as much as C++ for functional code :-)
It's probably inconceivable to you, but I, like 99.9% of other
programmers, respectfully disagree.
You mean the 99.9% who have never tried Lisp?
You say that as if Lisp had not been taught to millions of computer science
students, 99.9% of whom really do choose not to use Lisp.
It's just as ludicrous to say that 97% of PC users "really do choose"
to use Windows. You know perfectly well that these are not free
choices. They are governed by policy, fashion, "what you are exposed
to" (99.9% of programmers certainly have not been exposed to Lisp in a
way that they could make an informed choice*) - and in my example, of
course, a deeply entrenched monopoly.

* - besides, as far as I can tell, people rarely make choices or argue
based on first hand knowledge. Really, 99.9% of computer scientists
were properly taught Lisp? What % of those were also given the
impression that it was an academic exercise of no use in the real
world? By their teachers? Or my the received wisdom of the crowd? Or
both?
Post by Jon Harrop
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u
Jon Harrop
2009-07-12 05:28:43 UTC
Permalink
Post by toby
Post by Jon Harrop
Post by George Neuner
Post by fft1976
Post by Frank Buss
You could try Common Lisp: It is nice for imperative code and doesn't
suck as much as C++ for functional code :-)
It's probably inconceivable to you, but I, like 99.9% of other
programmers, respectfully disagree.
You mean the 99.9% who have never tried Lisp?
You say that as if Lisp had not been taught to millions of computer
science students, 99.9% of whom really do choose not to use Lisp.
It's just as ludicrous to say that 97% of PC users "really do choose"
to use Windows. You know perfectly well that these are not free
choices. They are governed by policy, fashion, "what you are exposed
to" (99.9% of programmers certainly have not been exposed to Lisp in a
way that they could make an informed choice*) - and in my example, of
course, a deeply entrenched monopoly.
* - besides, as far as I can tell, people rarely make choices or argue
based on first hand knowledge. Really, 99.9% of computer scientists
were properly taught Lisp? What % of those were also given the
impression that it was an academic exercise of no use in the real
world? By their teachers? Or my the received wisdom of the crowd? Or
both?
You're just trying to change the definition of "choice".

Those users have tasks to complete. If a Linux-based solution starts
with "recreate all data in Linux-compatible formats" then they rule out
that choice. Similarly, programmers don't choose Lisp because it would
start them off on the wrong foot.

Either way, it is the suckiness of the OS/language that rules it out as a
viable option. The user still has complete freedom over their choice. They
just recognise that Linux/Lisp is not a viable choice because of
practicalities.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
David Formosa (aka ? the Platypus)
2009-07-12 11:02:34 UTC
Permalink
On Sun, 12 Jul 2009 06:28:43 +0100, Jon Harrop <***@ffconsultancy.com> wrote:
[...]
Post by Jon Harrop
Those users have tasks to complete. If a Linux-based solution starts
with "recreate all data in Linux-compatible formats"
What is a linux-compatible format, what is a linux-incomptable format?
Jon Harrop
2009-07-12 18:07:13 UTC
Permalink
Post by David Formosa (aka ? the Platypus)
[...]
Post by Jon Harrop
Those users have tasks to complete. If a Linux-based solution starts
with "recreate all data in Linux-compatible formats"
What is a linux-compatible format, what is a linux-incomptable format?
Say you have data in a proprietary format and the only software that can
read it is Windows only: your data is not in a Linux-compatible format.

For example, we have a fantastic new digital camera and I am buying a
replacement netbook after my wife's Asus Eee PC died. I choose a another
Windows-based one because it will be able to read the data.

Note that I had the choice and I chose Windows but my choice was dictated by
practical requirements and not the theoretical properties of the language.
Contrary to Toby's description, I really did choose.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Scott Burson
2009-07-12 18:16:29 UTC
Permalink
Post by Jon Harrop
For example, we have a fantastic new digital camera and I am buying a
replacement netbook after my wife's Asus Eee PC died. I choose a another
Windows-based one because it will be able to read the data.
A digital camera that doesn't use an industry-standard method of
transferring data (such as one of the various formats of flash card,
or showing up on USB as a generic mass storage device)? Please tell
me what brand it is so I can be sure not to buy one.

-- Scott
Jon Harrop
2009-07-13 00:31:44 UTC
Permalink
Post by Scott Burson
Post by Jon Harrop
For example, we have a fantastic new digital camera and I am buying a
replacement netbook after my wife's Asus Eee PC died. I choose a another
Windows-based one because it will be able to read the data.
A digital camera that doesn't use an industry-standard method of
transferring data (such as one of the various formats of flash card,
or showing up on USB as a generic mass storage device)? Please tell
me what brand it is so I can be sure not to buy one.
Canon.

For another example, part of my work entails writing articles about F#. I
could try to run F# on Mono under Linux but it is a nightmare compared
to .NET on Windows. So I chose a Windows netbook for myself.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Scott Burson
2009-07-13 05:20:13 UTC
Permalink
Post by Jon Harrop
Post by Scott Burson
A digital camera that doesn't use an industry-standard method of
transferring data (such as one of the various formats of flash card,
or showing up on USB as a generic mass storage device)?  Please tell
me what brand it is so I can be sure not to buy one.
Canon.
Hmm, okay, I see that some claim that the open-source Linux driver
works okay; and failing that, one could use a CF card reader. I think
I could live with that.
Post by Jon Harrop
For another example, part of my work entails writing articles about F#. I
could try to run F# on Mono under Linux but it is a nightmare compared
to .NET on Windows. So I chose a Windows netbook for myself.
I'm not questioning your choice of OS. You have your requirements; I
have mine.

-- Scott
toby
2009-07-12 18:33:23 UTC
Permalink
Post by Jon Harrop
Post by David Formosa (aka ? the Platypus)
[...]
Post by Jon Harrop
Those users have tasks to complete. If a Linux-based solution starts
with "recreate all data in Linux-compatible formats"
What is a linux-compatible format, what is a linux-incomptable format?
Say you have data in a proprietary format and the only software that can
read it is Windows only: your data is not in a Linux-compatible format.
For example, we have a fantastic new digital camera and I am buying a
replacement netbook after my wife's Asus Eee PC died. I choose a another
Windows-based one because it will be able to read the data.
Note that I had the choice and I chose Windows but my choice was dictated by
practical requirements and not the theoretical properties of the language.
Contrary to Toby's description, I really did choose.
No, you're *forced* to "choose" Windows. You can buy a computer with
Windows or OS X pre-installed, or you can buy Windows, wipe it and
install a free operating system. Only the computer with Windows is
compatible with your digital camera. That's not a choice*, is it?

Your refrigerator is empty but for a jar of pickled onions. Are you
going to "really choose" pickled onions for dinner? What if you'd
really rather eat something else?

* - "choice": According to my English dictionary: an act of selecting
or making a decision when faced with TWO OR MORE possibilities.

[ The fact that few ISVs bother porting their software beyond Windows
is an *effect* of the monopoly. Making it *impossible* to port beyond
Windows is the plain raison d'être of F# and all MS-proprietary
technologies. ]
Post by Jon Harrop
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u
Jon Harrop
2009-07-13 00:31:19 UTC
Permalink
Post by toby
No, you're *forced* to "choose" Windows.
Nonsense. Nothing forced me to start using Windows. I did so entirely of my
own free will. In fact, I now regret not having chosen Windows earlier.
Post by toby
You can buy a computer with
Windows or OS X pre-installed,
Or Linux. I am writing this on a Dell that came with Linux installed.
Post by toby
or you can buy Windows, wipe it and
install a free operating system.
Or you can wipe Linux and install Windows, as I did on my old laptop.
Post by toby
Only the computer with Windows is compatible with your digital camera.
That's not a choice*, is it?
Yes, it is a choice. Incompatibility with a camera does not prevent me from
choosing to install Linux. Moreover, I have more choices: I might choose to
battle with existing buggy Linux drivers or I might choose try to write my
own.
Post by toby
Your refrigerator is empty but for a jar of pickled onions. Are you
going to "really choose" pickled onions for dinner? What if you'd
really rather eat something else?
You're trying to say that taking a choice means that choice never existed,
which is nonsensical.
Post by toby
* - "choice": According to my English dictionary: an act of selecting
or making a decision when faced with TWO OR MORE possibilities.
[ The fact that few ISVs bother porting their software beyond Windows
is an *effect* of the monopoly. Making it *impossible* to port beyond
Windows is the plain raison d'être of F# and all MS-proprietary
technologies. ]
Simply untrue. I port software from F# to OCaml all the time.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
toby
2009-07-13 00:08:50 UTC
Permalink
Post by Jon Harrop
Post by toby
No, you're *forced* to "choose" Windows.
Nonsense. Nothing forced me to start using Windows. I did so entirely of my
own free will. In fact, I now regret not having chosen Windows earlier.
So why did you use the example of the camera, which I argue was a non-
choice?
Post by Jon Harrop
Post by toby
You can buy a computer with
Windows or OS X pre-installed,
Or Linux. I am writing this on a Dell that came with Linux installed.
That's good news, I didn't think Dell did that any more.
Post by Jon Harrop
Post by toby
or you can buy Windows, wipe it and
install a free operating system.
Or you can wipe Linux and install Windows, as I did on my old laptop.
Post by toby
Only the computer with Windows is compatible with your digital camera.
That's not a choice*, is it?
Yes, it is a choice. Incompatibility with a camera does not prevent me from
choosing to install Linux. Moreover, I have more choices: I might choose to
battle with existing buggy Linux drivers or I might choose try to write my
own.
Yes, that's a real choice, but not the one you said you made.
Post by Jon Harrop
Post by toby
Your refrigerator is empty but for a jar of pickled onions. Are you
going to "really choose" pickled onions for dinner? What if you'd
really rather eat something else?
You're trying to say that taking a choice means that choice never existed,
which is nonsensical.
Post by toby
* - "choice": According to my English dictionary: an act of selecting
or making a decision when faced with TWO OR MORE possibilities.
[ The fact that few ISVs bother porting their software beyond Windows
is an *effect* of the monopoly. Making it *impossible* to port beyond
Windows is the plain raison d'être of F# and all MS-proprietary
technologies. ]
Simply untrue. I port software from F# to OCaml all the time.
One single personal exception cancels all other cases, and the whole
issue, eh? Now port the other 1,500,000 apps built on Microsoft
("freely chosen" by the developers from all alternatives, mind you!)
which could have been built on portable systems to begin with.

--Toby
Post by Jon Harrop
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u
Jon Harrop
2009-07-13 17:39:31 UTC
Permalink
Post by toby
Post by Jon Harrop
Post by toby
No, you're *forced* to "choose" Windows.
Nonsense. Nothing forced me to start using Windows. I did so entirely of
my own free will. In fact, I now regret not having chosen Windows
earlier.
So why did you use the example of the camera, which I argue was a non-
choice?
The camera example is not a "non-choice".
Post by toby
Post by Jon Harrop
Post by toby
[ The fact that few ISVs bother porting their software beyond Windows
is an *effect* of the monopoly. Making it *impossible* to port beyond
Windows is the plain raison d'être of F# and all MS-proprietary
technologies. ]
Simply untrue. I port software from F# to OCaml all the time.
One single personal exception cancels all other cases, and the whole
issue, eh?
Yes. Indeed, that is the sole purpose of a counter example.
Post by toby
Now port the other 1,500,000 apps built on Microsoft
("freely chosen" by the developers from all alternatives, mind you!)
which could have been built on portable systems to begin with.
No, there is no such thing as a "portable system".
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
fft1976
2009-07-10 23:09:37 UTC
Permalink
Post by George Neuner
Common Lisp (_not_ Scheme) offers assignment and imperative control
constructs
Scheme has SET!, VECTOR-SET!, SET-CDR! (in <=R5RS), etc.

Why would someone pretend to know something when they don't?
George Neuner
2009-07-11 00:03:08 UTC
Permalink
Post by fft1976
Post by George Neuner
Common Lisp (_not_ Scheme) offers assignment and imperative control
constructs
Scheme has SET!, VECTOR-SET!, SET-CDR! (in <=R5RS), etc.
Scheme does not have imperative control structures.
Post by fft1976
Why would someone pretend to know something when they don't?
You quoted a complete thought and took issue with only half of it. Why
don't you take the time to read and understand the thought before you
jump blindly into a discussion?

George
fft1976
2009-07-11 00:43:59 UTC
Permalink
Post by George Neuner
Post by fft1976
Post by George Neuner
Common Lisp (_not_ Scheme) offers assignment and imperative control
constructs
Scheme has SET!, VECTOR-SET!, SET-CDR! (in <=R5RS), etc.
Scheme does not have imperative control structures.
You take back what you said about assignment, then?

By the way, BEGIN is strictly an imperative control structure. IF and
others subsume imperative control structures, if their arguments are
imperative.
Post by George Neuner
Post by fft1976
Why would someone pretend to know something when they don't?
You quoted a complete thought and took issue with only half of it.
Huh? Most people don't like selective quoting, and you are asking for
it?! I hope Schemers will explain the error of your ways to you. My
patience ran out here.
Ertugrul Söylemez
2009-07-10 16:40:49 UTC
Permalink
Post by fft1976
So what do you want from a programming language?
Excellent question. I've never really tried to enumerate it
before...
(snip)
This "being functional" is an unhealthy obsession. 3/4 of the time
imperative idioms are more convenient, and 1/4 of the time functional
ones are more convenient.
Fortunately that's just your opinion and not the reality. Even
Microsoft has found the value in functional programming. See F#. It's
scheduled to be packaged with Visual Studio in 2010, AFAIK. Also many
imperative languages are employing more and more functional concepts.
Post by fft1976
But because most popular languages are imperative, people are whining
about those 1/4 cases and some disturbed individuals even think
languages should be pure-functional.
What's wrong with purely functional languages?
Post by fft1976
What I want is a safe (or has an option to be safe), fast mostly
imperative language that doesn't suck.
If you want safety, go for functional programming. About speed, most
decent functional languages aren't considerably slower than C, but given
that you save a lot of development time, you'll get your result much
faster.

Also purely functional languages (e.g. Haskell, Clean) and languages
with immutable data (e.g. F#) allow clean and concise algorithm
implementations, which are still just as fast as imperative variants
with explicit reference/memory handling. Finally with these two classes
of languages and additionally Erlang you get concurrency and parallelity
almost for free. Multithreaded programming is a PITA in all imperative
languages.
Post by fft1976
C++ (if you are very good and very careful), Java and OCaml are
decent, but not quite what I want. Maybe D and Ada, although I don't
know about those.
Just in case you didn't notice, OCaml is a functional language.
However, nobody is "very good" and "very careful". C++ leaves too many
spots open for making mistakes. D is much better at that, if you insist
on imperative programming.

All in all you're just showing that you don't have a clue about
functional programming. Before making such unfounded claims, you'd
better try a functional language for more than 15 minutes. If you still
think that functional programming sucks, you should provide reasons to
support your claims.


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
Jon Harrop
2009-07-10 18:29:54 UTC
Permalink
Post by Ertugrul Söylemez
Post by fft1976
But because most popular languages are imperative, people are whining
about those 1/4 cases and some disturbed individuals even think
languages should be pure-functional.
What's wrong with purely functional languages?
. Unpredictable performance.

. Unreliable.

. Uninteroperable.
Post by Ertugrul Söylemez
Post by fft1976
What I want is a safe (or has an option to be safe), fast mostly
imperative language that doesn't suck.
If you want safety, go for functional programming.
If you want to interoperate with code written in other languages then
functional languages like OCaml and Haskell are *less* safe than the JVM
and CLR because their FFIs are comparatively poorly designed and poorly
implemented.
Post by Ertugrul Söylemez
About speed, most decent functional languages aren't considerably slower
than C,
That assertion is uselessly subjective. What are "decent" functional
languages? How much is "considerably" slower? Why are you comparing with C?
Are you assuming GCC and not Intel C++ (which often generates code that is
several times faster)?

The fastest BWT implementation written in Haskell, after weeks of
optimization by several experts, remained over 200x slower than C++:

http://www.mail-archive.com/haskell-cafe%40haskell.org/msg25645.html

So either Haskell is not "decent" or 200x slower is "not considerably
slower".
Post by Ertugrul Söylemez
but given that you save a lot of development time, you'll get your result
much faster.
Not if your "result" is efficient code, which is often the case for
professional developers because their end users demand speed.
Post by Ertugrul Söylemez
Also purely functional languages (e.g. Haskell, Clean) and languages
with immutable data (e.g. F#) allow clean and concise algorithm
implementations, which are still just as fast as imperative variants
with explicit reference/memory handling. Finally with these two classes
of languages and additionally Erlang you get concurrency and parallelity
almost for free.
GHC's stop-the-world GC does not scale so Haskell programmers obviously do
not get "parallelism almost for free".
Post by Ertugrul Söylemez
Multithreaded programming is a PITA in all imperative languages.
Cilk makes parallelism easy.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Ertugrul Söylemez
2009-07-10 19:28:40 UTC
Permalink
Post by Jon Harrop
Post by Ertugrul Söylemez
What's wrong with purely functional languages?
. Unpredictable performance.
Wrong.
Post by Jon Harrop
. Unreliable.
Wrong (although right to some extent on PPC).
Post by Jon Harrop
. Uninteroperable.
Right. That's something that could use some improvement.
Post by Jon Harrop
Post by Ertugrul Söylemez
About speed, most decent functional languages aren't considerably
slower than C,
That assertion is uselessly subjective. What are "decent" functional
languages? How much is "considerably" slower? Why are you comparing
with C? Are you assuming GCC and not Intel C++ (which often generates
code that is several times faster)?
The fastest BWT implementation written in Haskell, after weeks of
http://www.mail-archive.com/haskell-cafe%40haskell.org/msg25645.html
So either Haskell is not "decent" or 200x slower is "not considerably
slower".
Hmm. This one took me about 10 minutes:

bwt :: B.ByteString -> B.ByteString
bwt str =
let sorted = map fst . sortBy (compare `on` snd) $ zip [0, 1..] (B.unpack str)
slen = B.length str
in B.pack . map (\i -> B.index str ((i-1) `mod` slen)) $ sorted

It's not optimal, because it uses list sorting. Replace it by an
in-place sort and you're set.
Post by Jon Harrop
GHC's stop-the-world GC does not scale so Haskell programmers
obviously do not get "parallelism almost for free".
Right. It's not that it makes such a big difference anyway, but it
could be improved a lot. When using explicit threading in Haskell I
usually get c*n*100% of the performance of a single thread, where c is
some constant between 0.8 and 0.9 and n is the number of CPUs and
threads. Unfortunately this is not true for implicit parallelism using
strategies, but I don't believe that this can be improved a lot.


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
Jon Harrop
2009-07-10 22:05:21 UTC
Permalink
Post by Ertugrul Söylemez
Post by Jon Harrop
Post by Ertugrul Söylemez
What's wrong with purely functional languages?
. Unpredictable performance.
Wrong.
There is overwhelming evidence to the contrary. Indeed, you provide more
below...
Post by Ertugrul Söylemez
Post by Jon Harrop
So either Haskell is not "decent" or 200x slower is "not considerably
slower".
bwt :: B.ByteString -> B.ByteString
bwt str =
let sorted = map fst . sortBy (compare `on` snd) $ zip [0, 1..] (B.unpack str)
slen = B.length str
in B.pack . map (\i -> B.index str ((i-1) `mod` slen)) $ sorted
Your incomplete implementation is over 100x slower than bzip2. Moreover,
your Haskell runs out of memory when trying to compress only 8Mb.

The poor performance of your Haskell code is a direct consequence of
Haskell's unpredictability. Obviously you failed to predict how bad your
code was or you would not have posted an example that contradicts your own
assertions.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
ACL
2009-07-11 00:49:10 UTC
Permalink
A quick analysis so that we can better understand the question 'what
is trolling?'
Post by Jon Harrop
Post by Ertugrul Söylemez
Post by Jon Harrop
Post by Ertugrul Söylemez
What's wrong with purely functional languages?
. Unpredictable performance.
Wrong.
There is overwhelming evidence to the contrary. Indeed, you provide more
below...
Post by Ertugrul Söylemez
Post by Jon Harrop
So either Haskell is not "decent" or 200x slower is "not considerably
slower".
You see here, the wiley troll makes a claim of comparison as if it is
fact. 'Haskell is 200x slower' than ...? he doesn't specify what it is
200x slower than.
Post by Jon Harrop
Post by Ertugrul Söylemez
  bwt :: B.ByteString -> B.ByteString
  bwt str =
    let sorted = map fst . sortBy (compare `on` snd) $ zip [0, 1..]
    (B.unpack str)
        slen   = B.length str
    in B.pack . map (\i -> B.index str ((i-1) `mod` slen)) $ sorted
The trolled posts something to prove that his language is productive.
Post by Jon Harrop
Your incomplete implementation is over 100x slower than bzip2. Moreover,
your Haskell runs out of memory when trying to compress only 8Mb.
The troll cleverly compares the 6 line haskell implementation to an
industry quality implementation of zip compression, specifically well
known for its speed.
The source of which being nearly 1 megabyte of information compressed.
We should note that it is only 100x slower than the high quality
implementation, while the claim was that haskell would be 200x
slower...
Post by Jon Harrop
The poor performance of your Haskell code is a direct consequence of
Haskell's unpredictability. Obviously you failed to predict how bad your
code was or you would not have posted an example that contradicts your own
assertions.
He omits the fact that the poor performance is a result of not
comparing apples to apples in any sort of reasonable manner. He also
omits the fact that the author admited that it wasn't the highest
quality implementation of zip compression.

Here's to you Doctor Harrop, a fine specimen of the Trollish race, now
please get back under your bridge.
Jon Harrop
2009-07-11 02:19:19 UTC
Permalink
Post by ACL
Post by Jon Harrop
Post by Ertugrul Söylemez
Post by Jon Harrop
So either Haskell is not "decent" or 200x slower is "not considerably
slower".
You see here, the wiley troll makes a claim of comparison as if it is
fact.
Err, it is fact and I cited the source.
Post by ACL
'Haskell is 200x slower' than ...? he doesn't specify what it is
200x slower than.
I explicitly wrote "200x slower than C++".
Post by ACL
Post by Jon Harrop
Post by Ertugrul Söylemez
bwt :: B.ByteString -> B.ByteString
bwt str =
let sorted = map fst . sortBy (compare `on` snd) $ zip [0, 1..] (B.unpack str)
slen   = B.length str
in B.pack . map (\i -> B.index str ((i-1) `mod` slen)) $ sorted
The trolled posts something to prove that his language is productive.
Post by Jon Harrop
Your incomplete implementation is over 100x slower than bzip2. Moreover,
your Haskell runs out of memory when trying to compress only 8Mb.
The troll cleverly compares the 6 line haskell implementation to an
industry quality implementation of zip compression,
Bzip2, not zip.
Post by ACL
specifically well known for its speed.
Did you want to compare Haskell with badly written inefficient C?
Post by ACL
The source of which being nearly 1 megabyte of information compressed.
No, the source code to bzip2 is 170kB in under 9kLOC. The "blocksort.c" file
that contains the equivalent of this code (and a lot more) and is only 729
LOC.
Post by ACL
We should note that it is only 100x slower than the high quality
implementation, while the claim was that haskell would be 200x
slower...
No, the partially-implemented Haskell is already 100x slower that the
complete C implementation so a full Haskell implementation based upon it
must be over 100x slower.
Post by ACL
Post by Jon Harrop
The poor performance of your Haskell code is a direct consequence of
Haskell's unpredictability. Obviously you failed to predict how bad your
code was or you would not have posted an example that contradicts your
own assertions.
He omits the fact that the poor performance is a result of not
comparing apples to apples in any sort of reasonable manner.
You misunderstood the comparison.
Post by ACL
He also omits the fact that the author admited that it wasn't the highest
quality implementation of zip compression.
Ertugrul claimed he could write performant Haskell and then didn't.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Ertugrul Söylemez
2009-07-11 13:58:37 UTC
Permalink
Post by Jon Harrop
Post by ACL
He also omits the fact that the author admited that it wasn't the
highest quality implementation of zip compression.
Ertugrul claimed he could write performant Haskell and then didn't.
Or maybe you should learn to use the compiler properly. The code works
well for me. High memory usage comes from the sorting algorithm
(because it uses lists), which I said can be improved.


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
Jon Harrop
2009-07-11 18:43:42 UTC
Permalink
Post by Ertugrul Söylemez
Post by Jon Harrop
Post by ACL
He also omits the fact that the author admited that it wasn't the
highest quality implementation of zip compression.
Ertugrul claimed he could write performant Haskell and then didn't.
Or maybe you should learn to use the compiler properly.
You claimed "most decent functional languages aren't considerably slower
than C" and then provided Haskell that is over 100x slower than C.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
ACL
2009-07-12 03:16:27 UTC
Permalink
Post by Jon Harrop
Post by ACL
Post by Jon Harrop
Post by Ertugrul Söylemez
Post by Jon Harrop
So either Haskell is not "decent" or 200x slower is "not considerably
slower".
You see here, the wiley troll makes a claim of comparison as if it is
fact.
Err, it is fact and I cited the source.
No you didn't. I just scrolled up. I see no study cited.
Post by Jon Harrop
Post by ACL
'Haskell is 200x slower' than ...? he doesn't specify what it is
200x slower than.
I explicitly wrote "200x slower than C++".
Who cares about C++?

It seems that any language you defame has to go up against 3 or 4
different languages of your choosing depending on the test. I thought
you were the F#/OCaml schill?

Besides the haskell was *according to you* only 100x slower than C
code, (not C++ code). you claimed 200x
Post by Jon Harrop
Post by ACL
Post by Jon Harrop
Post by Ertugrul Söylemez
bwt :: B.ByteString -> B.ByteString
bwt str =
let sorted = map fst . sortBy (compare `on` snd) $ zip [0, 1..] (B.unpack str)
slen   = B.length str
in B.pack . map (\i -> B.index str ((i-1) `mod` slen)) $ sorted
The trolled posts something to prove that his language is productive.
Post by Jon Harrop
Your incomplete implementation is over 100x slower than bzip2. Moreover,
your Haskell runs out of memory when trying to compress only 8Mb.
The troll cleverly compares the 6 line haskell implementation to an
industry quality implementation of zip compression,
Bzip2, not zip.
nitpicking doesn't make you more right.
Post by Jon Harrop
Post by ACL
specifically well known for its speed.
Did you want to compare Haskell with badly written inefficient C?
if it is badly written and inefficient haskell... then yes.
Post by Jon Harrop
Post by ACL
The source of which being nearly 1 megabyte of information compressed.
No, the source code to bzip2 is 170kB in under 9kLOC. The "blocksort.c" file
that contains the equivalent of this code (and a lot more) and is only 729
LOC.
That's weird i just downloaded the source and zipped it came in at
~800kb.

Even if what you say is right, you are still comparing 100x more LOC.
Only 730 loc? Seriously?
Post by Jon Harrop
Post by ACL
We should note that it is only 100x slower than the high quality
implementation, while the claim was that haskell would be 200x
slower...
No, the partially-implemented Haskell is already 100x slower that the
complete C implementation so a full Haskell implementation based upon it
must be over 100x slower.
That doesn't make sense. Adding code is not equal to adding extra run
time. Sometimes adding code makes things faster, you know.
Post by Jon Harrop
Post by ACL
Post by Jon Harrop
The poor performance of your Haskell code is a direct consequence of
Haskell's unpredictability. Obviously you failed to predict how bad your
code was or you would not have posted an example that contradicts your
own assertions.
He omits the fact that the poor performance is a result of not
comparing apples to apples in any sort of reasonable manner.
You misunderstood the comparison.
It seems it is a bad comparison....
Post by Jon Harrop
Post by ACL
He also omits the fact that the author admited that it wasn't the highest
quality implementation of zip compression.
Ertugrul claimed he could write performant Haskell and then didn't.
I think he claimed it could be written, not that he was writing it.
Jon Harrop
2009-07-12 07:20:28 UTC
Permalink
Post by ACL
Post by Jon Harrop
Post by ACL
Post by Jon Harrop
Post by Jon Harrop
So either Haskell is not "decent" or 200x slower is "not
considerably slower".
You see here, the wiley troll makes a claim of comparison as if it is
fact.
Err, it is fact and I cited the source.
No you didn't. I just scrolled up. I see no study cited.
Here's that citation again:

http://www.mail-archive.com/haskell-cafe%40haskell.org/msg25645.html
Post by ACL
Post by Jon Harrop
Post by ACL
'Haskell is 200x slower' than ...? he doesn't specify what it is
200x slower than.
I explicitly wrote "200x slower than C++".
Who cares about C++?
It seems that any language you defame has to go up against 3 or 4
different languages of your choosing depending on the test. I thought
you were the F#/OCaml schill?
Besides the haskell was *according to you* only 100x slower than C
code, (not C++ code). you claimed 200x
The post I cited claimed 200.
Post by ACL
Post by Jon Harrop
Post by ACL
specifically well known for its speed.
Did you want to compare Haskell with badly written inefficient C?
if it is badly written and inefficient haskell... then yes.
We are trying to determine whether or not Haskell code can be efficient.
Post by ACL
Post by Jon Harrop
Post by ACL
The source of which being nearly 1 megabyte of information compressed.
No, the source code to bzip2 is 170kB in under 9kLOC. The "blocksort.c"
file that contains the equivalent of this code (and a lot more) and is
only 729 LOC.
That's weird i just downloaded the source and zipped it came in at
~800kb.
The BZip2 distro includes the manual in several different formats, e.g. a
1Mb PostScript file.
Post by ACL
Even if what you say is right, you are still comparing 100x more LOC.
Only 730 loc? Seriously?
Sure. I won't contest that the C is far more verbose but this discussion was
solely about performance.
Post by ACL
Post by Jon Harrop
Post by ACL
We should note that it is only 100x slower than the high quality
implementation, while the claim was that haskell would be 200x
slower...
No, the partially-implemented Haskell is already 100x slower that the
complete C implementation so a full Haskell implementation based upon it
must be over 100x slower.
That doesn't make sense. Adding code is not equal to adding extra run
time. Sometimes adding code makes things faster, you know.
How could adding code that implements the subsequent phases of the
compression algorithm possibly decrease the total running time?
Post by ACL
Post by Jon Harrop
Post by ACL
Post by Jon Harrop
The poor performance of your Haskell code is a direct consequence of
Haskell's unpredictability. Obviously you failed to predict how bad
your code was or you would not have posted an example that contradicts
your own assertions.
He omits the fact that the poor performance is a result of not
comparing apples to apples in any sort of reasonable manner.
You misunderstood the comparison.
It seems it is a bad comparison....
Indeed, it turns out that Ertugrul's Haskell implementation is actually
broken.
Post by ACL
Post by Jon Harrop
Post by ACL
He also omits the fact that the author admited that it wasn't the
highest quality implementation of zip compression.
Ertugrul claimed he could write performant Haskell and then didn't.
I think he claimed it could be written, not that he was writing it.
Indeed, this is the second time he has made a claim about Haskell only to
prove himself wrong.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Richard Heathfield
2009-07-12 07:27:15 UTC
Permalink
Post by ACL
Post by Jon Harrop
Post by ACL
Post by Jon Harrop
So either Haskell is not "decent" or 200x slower is "not
considerably slower".
You see here, the wiley troll makes a claim of comparison as
if it is fact.
Err, it is fact and I cited the source.
No you didn't. I just scrolled up. I see no study cited.
http://www.mail-archive.com/haskell-cafe%40haskell.org/msg25645.html

Hardly a "study" - just a single data point. Note that I don't doubt
the claim. It is obvious to me that C++, being a bit of a
cart-horse, is not going to manage to be much more than 200x faster
than Haskell (which is more of a barge-horse, with a missing leg).
Nevertheless, that single data point is only the tiniest indicator
that this is so, and most certainly does not deserve to be
dignified by the name of "study". To extrapolate an argument from a
single datum is rarely wise.

<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
Ertugrul Söylemez
2009-07-13 19:12:33 UTC
Permalink
Post by Jon Harrop
Post by ACL
Post by Jon Harrop
Post by ACL
Post by Jon Harrop
The poor performance of your Haskell code is a direct consequence
of Haskell's unpredictability. Obviously you failed to predict
how bad your code was or you would not have posted an example
that contradicts your own assertions.
He omits the fact that the poor performance is a result of not
comparing apples to apples in any sort of reasonable manner.
You misunderstood the comparison.
It seems it is a bad comparison....
Indeed, it turns out that Ertugrul's Haskell implementation is
actually broken.
Its output is shifted compared to the original BWT transform. You can
correct that without adding extra code, although there is no reason to
do that. And I say it again: Replace the list sorting by an in-place
sort and you get orders of magnitude better performance. I was just too
lazy to implement it.
Post by Jon Harrop
Post by ACL
Post by Jon Harrop
Post by ACL
He also omits the fact that the author admited that it wasn't the
highest quality implementation of zip compression.
Ertugrul claimed he could write performant Haskell and then didn't.
I think he claimed it could be written, not that he was writing it.
Indeed, this is the second time he has made a claim about Haskell only
to prove himself wrong.
This is about the hundredth time you claim that I have proven myself
wrong. You said that the best Haskell implementation some people from
the ML could come up with was 200 times slower than equivalent C code.
I wrote in a matter of 10 minutes a (nowhere near optimal) variant,
which is, according to you, only 100 times slower. I disregard the fact
that you have repeatedly shown that you're unable to use the compiler
properly. Anyway, the bad performance comes from the fact that I have
used list sorting. See above for how to fix this.


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
Paul Rubin
2009-07-13 19:28:12 UTC
Permalink
Replace the list sorting by an in-place sort and you get orders of
magnitude better performance. I was just too lazy to implement it.
I wonder if the sorting code in uvector could handle it.

http://hackage.haskell.org/package/uvector-algorithms
Jon Harrop
2009-07-13 21:28:41 UTC
Permalink
Post by Ertugrul Söylemez
Its output is shifted compared to the original BWT transform. You can
correct that without adding extra code, although there is no reason to
do that. And I say it again: Replace the list sorting by an in-place
sort and you get orders of magnitude better performance. I was just too
lazy to implement it.
Put up or shut up, Ertugrul. Its as simple as that. Show us the Haskell
implementation that gives the correct answer and is "not considerably
slower" than the C or retract your claim. Your choice.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Ertugrul Söylemez
2009-07-13 20:44:33 UTC
Permalink
Post by Jon Harrop
Post by Ertugrul Söylemez
Its output is shifted compared to the original BWT transform. You
can correct that without adding extra code, although there is no
reason to do that. And I say it again: Replace the list sorting by
an in-place sort and you get orders of magnitude better performance.
I was just too lazy to implement it.
Put up or shut up, Ertugrul. Its as simple as that. Show us the
Haskell implementation that gives the correct answer and is "not
considerably slower" than the C or retract your claim. Your choice.
Unfortunately I don't have the time to prove my claims all the time,
just because some hair splitter like you insists on it. But as said in
another subthread, I'll consider it.

If you're impatient, you may want to pay me for doing it.


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
fft1976
2009-07-11 02:03:30 UTC
Permalink
Post by Jon Harrop
Are you assuming GCC and not Intel C++ (which often generates code that is
several times faster)?
[citation_needed]

IME they are neck to neck. Same for C++ vs Fortran (IFC and G77). ICC
gave me more problems, so I dumped it.
Vend
2009-07-10 17:26:15 UTC
Permalink
Fortunately that's just your opinion and not the reality.  Even
Microsoft has found the value in functional programming.  See F#.  It's
scheduled to be packaged with Visual Studio in 2010, AFAIK.  Also many
imperative languages are employing more and more functional concepts.
F# is not purely functional.
Post by fft1976
But because most popular languages are imperative, people are whining
about those 1/4 cases and some disturbed individuals even think
languages should be pure-functional.
What's wrong with purely functional languages?
Post by fft1976
What I want is a safe (or has an option to be safe), fast mostly
imperative language that doesn't suck.
If you want safety, go for functional programming.
Why?
Type safety is orthogonal to the functional/imperative distinction.
 About speed, most
decent functional languages aren't considerably slower than C, but given
that you save a lot of development time, you'll get your result much
faster.
However, if I understand correctly, purely functional languages
typically have performance problems.
Also purely functional languages (e.g. Haskell, Clean) and languages
with immutable data (e.g. F#) allow clean and concise algorithm
implementations, which are still just as fast as imperative variants
with explicit reference/memory handling.
This makes no sense, since you can always use mutable variables as if
they were immutable.

What makes functional languages more coincise is the availability of
first-class procedures.
Lazy evaluation can also improve expressivity, at the cost of
performance problems.
 Finally with these two classes
of languages and additionally Erlang you get concurrency and parallelity
almost for free.  Multithreaded programming is a PITA in all imperative
languages.
Again, these issues are orthogonal. Erlang's message passing model of
concurrency can be also used in imperative languages.
Post by fft1976
C++ (if you are very good and very careful), Java and OCaml are
decent, but not quite what I want. Maybe D and Ada, although I don't
know about those.
Just in case you didn't notice, OCaml is a functional language.
But it is not pure.
However, nobody is "very good" and "very careful".  C++ leaves too many
spots open for making mistakes.  D is much better at that, if you insist
on imperative programming.
All in all you're just showing that you don't have a clue about
functional programming.  Before making such unfounded claims, you'd
better try a functional language for more than 15 minutes.  If you still
think that functional programming sucks, you should provide reasons to
support your claims.
He didn't say that functional programming sucks, he said that the
functional paradigm is useful 25% of times.
Jon Harrop
2009-07-10 19:35:06 UTC
Permalink
Post by Vend
Why?
Type safety is orthogonal to the functional/imperative distinction.
Only in theory. In practice, functional languages (OCaml, Haskell) offer far
more expressive type systems than any available safe imperative language
implementation (Java, C#).
Post by Vend
Post by Ertugrul Söylemez
Also purely functional languages (e.g. Haskell, Clean) and languages
with immutable data (e.g. F#) allow clean and concise algorithm
implementations, which are still just as fast as imperative variants
with explicit reference/memory handling.
This makes no sense, since you can always use mutable variables as if
they were immutable.
That does not recover the properties of purely functional data structures.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Vend
2009-07-11 08:50:07 UTC
Permalink
Post by Jon Harrop
Post by Vend
Why?
Type safety is orthogonal to the functional/imperative distinction.
Only in theory. In practice, functional languages (OCaml, Haskell) offer far
more expressive type systems than any available safe imperative language
implementation (Java, C#).
The issue under discussion was type safety, not type expressiveness.
And anyway, while modern functional languages do have expressive type
systems, this isn't necessarily a property of functional languages.

Algebraic types and type inference could be used in the definition of
an imperative language.
On the other hand, early lisps were largely functional languages, yet
they had poor type systems.
Post by Jon Harrop
Post by Vend
Post by Ertugrul Söylemez
Also purely functional languages (e.g. Haskell, Clean) and languages
with immutable data (e.g. F#) allow clean and concise algorithm
implementations, which are still just as fast as imperative variants
with explicit reference/memory handling.
This makes no sense, since you can always use mutable variables as if
they were immutable.
That does not recover the properties of purely functional data structures.
What properties?
If by convention you assign to each variable only once per lifetime,
you get the same properties of immutable variables.

Having a way to specify immutability in the language can be useful to
detect bugs, but it doesn't change the base semantics of the programs:
if you take a correct program written using immutable variables and
replace them with mutable variables, it stays correct.
Andreas Rossberg
2009-07-11 10:38:30 UTC
Permalink
Post by Vend
The issue under discussion was type safety, not type expressiveness.
These are interdependent. A more expressive type system requires fewer
work-arounds with unsafe operations such as downcasts, and allows
encoding domain-specific safety and correctness properties in types,
making the notion of type safety stronger.
Post by Vend
And anyway, while modern functional languages do have expressive type
systems, this isn't necessarily a property of functional languages.
Algebraic types and type inference could be used in the definition of
an imperative language.
Hindley/Milner style polymorphic type inference - which is what all
those functional languages are based on - does not work for imperative
features. For an imperative language you are forced to use more ad-hoc
and less complete approaches.
Post by Vend
Post by Jon Harrop
Post by Vend
This makes no sense, since you can always use mutable variables as if
they were immutable.
That does not recover the properties of purely functional data structures.
What properties?
If by convention you assign to each variable only once per lifetime,
you get the same properties of immutable variables.
When you build an abstraction you cannot simply assume that client
code behaves well. Ensuring (never mind proving) abstraction safety is
orders of magnitude harder in the presence of mutable state. The whole
cottage industry around ownership types is one attempt to tame mutable
state in this respect.
Post by Vend
Having a way to specify immutability in the language can be useful to
if you take a correct program written using immutable variables and
replace them with mutable variables, it stays correct.
That is patently false (unless you only consider whole programs, which
is not very useful). The presence of mutable state fundamentally
changes the semantic notion of program equivalence. In a language with
state, if you put your program P into the context C of another program
(ie. your "program" is a module or class that is used in a larger
program), C can generally distinguish more possible behaviours of P
than in a language with immutable variables - which is a technical way
of saying that it has more ways to mess with it. The flipside is that
you have to work harder to write P such that no C can break its
intended semantics. The most obvious (but by no means sufficient) rule
is that P should never pass out parts of its internal representation,
but always has to copy it first. That is no concern with immutable
data structures.

- Andreas
Vend
2009-07-11 11:02:25 UTC
Permalink
Post by Andreas Rossberg
Post by Vend
The issue under discussion was type safety, not type expressiveness.
These are interdependent. A more expressive type system requires fewer
work-arounds with unsafe operations such as downcasts, and allows
encoding domain-specific safety and correctness properties in types,
making the notion of type safety stronger.
Ok, I meant the property of the language not to fall into unspecified
behavior when a type error occours, like C and C++ can do.
Post by Andreas Rossberg
Hindley/Milner style polymorphic type inference - which is what all
those functional languages are based on - does not work for imperative
features. For an imperative language you are forced to use more ad-hoc
and less complete approaches.
Can you provide an example, please?
Post by Andreas Rossberg
Post by Vend
What properties?
If by convention you assign to each variable only once per lifetime,
you get the same properties of immutable variables.
When you build an abstraction you cannot simply assume that client
code behaves well. Ensuring (never mind proving) abstraction safety is
orders of magnitude harder in the presence of mutable state. The whole
cottage industry around ownership types is one attempt to tame mutable
state in this respect.
As I said, immutable variables can be useful for program verification.
You can write in the documentation of your modules "don't mutate these
objects", and hope that the client complies, but if the language
allows you to express that contract in the type system then it is
useful to do so and avoid errors.

However, I see no point in making all variables immutable, or even in
making variables immutable by default.
Post by Andreas Rossberg
Post by Vend
Having a way to specify immutability in the language can be useful to
if you take a correct program written using immutable variables and
replace them with mutable variables, it stays correct.
That is patently false (unless you only consider whole programs, which
is not very useful). The presence of mutable state fundamentally
changes the semantic notion of program equivalence. In a language with
state, if you put your program P into the context C of another program
(ie. your "program" is a module or class that is used in a larger
program), C can generally distinguish more possible behaviours of P
than in a language with immutable variables - which is a technical way
of saying that it has more ways to mess with it.
No, since you can represent state with input and output values.
Post by Andreas Rossberg
The flipside is that
you have to work harder to write P such that no C can break its
intended semantics. The most obvious (but by no means sufficient) rule
is that P should never pass out parts of its internal representation,
but always has to copy it first. That is no concern with immutable
data structures.
- Andreas
Andreas Rossberg
2009-07-11 12:39:37 UTC
Permalink
Post by Vend
Post by Andreas Rossberg
Hindley/Milner style polymorphic type inference - which is what all
those functional languages are based on - does not work for imperative
features. For an imperative language you are forced to use more ad-hoc
and less complete approaches.
Can you provide an example, please?
The simplest possible example: when you declare

val x = nil

where nil denotes the empty list, then in case x is immutable,
inference can assign the polymorphic type

x : List[A]

If x is mutable, it cannot, because that would be unsound. Similar
problems occur with subtyping polymorphism, essentially because
mutable variables always have to be invariant.
Post by Vend
However, I see no point in making all variables immutable, or even in
making variables immutable by default.
The idea is that the language (and its type system) should cleanly
separate the notions of variable and mutable state. That makes the
intent clear, allows for more flexible typing, and most importantly,
avoids accident. That is what functional languages do (all of which
allow mutable state in one form or the other).
Post by Vend
Post by Andreas Rossberg
Post by Vend
Having a way to specify immutability in the language can be useful to
if you take a correct program written using immutable variables and
replace them with mutable variables, it stays correct.
That is patently false (unless you only consider whole programs, which
is not very useful). The presence of mutable state fundamentally
changes the semantic notion of program equivalence. In a language with
state, if you put your program P into the context C of another program
(ie. your "program" is a module or class that is used in a larger
program), C can generally distinguish more possible behaviours of P
than in a language with immutable variables - which is a technical way
of saying that it has more ways to mess with it.
No, since you can represent state with input and output values.
Not sure what you are saying. If your language has higher-order state
- i.e. pointers or closures - then you cannot do that (except as a
whole program transformation).

- Andreas
Ertugrul Söylemez
2009-07-10 18:42:52 UTC
Permalink
Post by Vend
Fortunately that's just your opinion and not the reality.  Even
Microsoft has found the value in functional programming.  See
F#.  It's scheduled to be packaged with Visual Studio in 2010,
AFAIK.  Also many imperative languages are employing more and more
functional concepts.
F# is not purely functional.
So...?
Post by Vend
Post by fft1976
What I want is a safe (or has an option to be safe), fast mostly
imperative language that doesn't suck.
If you want safety, go for functional programming.
Why?
Type safety is orthogonal to the functional/imperative distinction.
Type safety is one kind of safety. The functional paradigm gives you
other types of safety, too, which doesn't require additional language
constructs like 'foreach'.
Post by Vend
 About speed, most decent functional languages aren't considerably
slower than C, but given that you save a lot of development time,
you'll get your result much faster.
However, if I understand correctly, purely functional languages
typically have performance problems.
That statement wasn't restricted to purely functional languages, but
despite Dr. Harrop's usual noise purely functional languages perform
quite well.
Post by Vend
Also purely functional languages (e.g. Haskell, Clean) and languages
with immutable data (e.g. F#) allow clean and concise algorithm
implementations, which are still just as fast as imperative variants
with explicit reference/memory handling.
This makes no sense, since you can always use mutable variables as if
they were immutable.
You cannot in the same convenient way. With immutable data you can make
a function take a tree and return a slightly modified tree without much
programming effort.
Post by Vend
What makes functional languages more coincise is the availability of
first-class procedures.
Modern imperative languages have that as well. Functional programming
is a paradigm, not a tool.
Post by Vend
Lazy evaluation can also improve expressivity, at the cost of
performance problems.
Lazy evaluation is a semantic property. What it compiles to is a
different question. Particularly Haskell as the outrider in non-strict
semantics does quite well at that (with GHC).
Post by Vend
 Finally with these two classes of languages and additionally Erlang
you get concurrency and parallelity almost for free.  Multithreaded
programming is a PITA in all imperative languages.
Again, these issues are orthogonal. Erlang's message passing model of
concurrency can be also used in imperative languages.
Erlang is inherently thread-safe. The other languages I mentioned get
that property partly through immutable data and partly through excellent
synchronization constructs.
Post by Vend
Post by fft1976
C++ (if you are very good and very careful), Java and OCaml are
decent, but not quite what I want. Maybe D and Ada, although I
don't know about those.
Just in case you didn't notice, OCaml is a functional language.
But it is not pure.
So...? The OP obviously doesn't like functional programming. That's my
point.
Post by Vend
However, nobody is "very good" and "very careful".  C++ leaves too
many spots open for making mistakes.  D is much better at that, if
you insist on imperative programming.
All in all you're just showing that you don't have a clue about
functional programming.  Before making such unfounded claims, you'd
better try a functional language for more than 15 minutes.  If you
still think that functional programming sucks, you should provide
reasons to support your claims.
He didn't say that functional programming sucks, he said that the
functional paradigm is useful 25% of times.
Yes, and he didn't support that statement by anything.


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
Vend
2009-07-11 09:28:40 UTC
Permalink
Post by Ertugrul Söylemez
Post by Vend
F# is not purely functional.
So...?
I think we were discussing purely functional languages.
Post by Ertugrul Söylemez
Post by Vend
Type safety is orthogonal to the functional/imperative distinction.
Type safety is one kind of safety.  The functional paradigm gives you
other types of safety, too, which doesn't require additional language
constructs like 'foreach'.
What kind of safety?
Post by Ertugrul Söylemez
That statement wasn't restricted to purely functional languages, but
despite Dr. Harrop's usual noise purely functional languages perform
quite well.
Do they?
Functional update of a data structure has both asymptotic and constant
performance penality over destructive update.
Post by Ertugrul Söylemez
Post by Vend
Post by Ertugrul Söylemez
Also purely functional languages (e.g. Haskell, Clean) and languages
with immutable data (e.g. F#) allow clean and concise algorithm
implementations, which are still just as fast as imperative variants
with explicit reference/memory handling.
This makes no sense, since you can always use mutable variables as if
they were immutable.
You cannot in the same convenient way.
Why not? You just have to assign each variable only once.
Language-level immutability can be useful as an optional constraint
for automatic program verification, but I don't see the point of
forcing it on all variables like purely functiona program do.
Post by Ertugrul Söylemez
 With immutable data you can make
a function take a tree and return a slightly modified tree without much
programming effort.
Yes, but it doesn't have to be whole-program language-enforced
immutability.
The Java 'final' keyword sufficies for that task.
Post by Ertugrul Söylemez
Post by Vend
What makes functional languages more coincise is the availability of
first-class procedures.
Modern imperative languages have that as well.  Functional programming
is a paradigm, not a tool.
Right. As a paradigm, functional programming can be useful.
As a language constraint, like in Haskell and Clean, it is not.
Post by Ertugrul Söylemez
Post by Vend
Lazy evaluation can also improve expressivity, at the cost of
performance problems.
Lazy evaluation is a semantic property.  What it compiles to is a
different question.
Time and particularly space complexity are also sematic properties,
and they are affected by lazy evaluation.
Post by Ertugrul Söylemez
 Particularly Haskell as the outrider in non-strict
semantics does quite well at that (with GHC).
I've read that Haskell has unpredictable space complexity, which
depends on the inner workings of the compiler.
Post by Ertugrul Söylemez
Post by Vend
Post by Ertugrul Söylemez
Just in case you didn't notice, OCaml is a functional language.
But it is not pure.
So...?  The OP obviously doesn't like functional programming.  That's my
point.
No.
Jon Harrop
2009-07-11 19:00:01 UTC
Permalink
Post by Vend
Post by Ertugrul Söylemez
Post by Vend
F# is not purely functional.
That statement wasn't restricted to purely functional languages, but
despite Dr. Harrop's usual noise purely functional languages perform
quite well.
Do they?
Functional update of a data structure has both asymptotic and constant
performance penality over destructive update.
In theory, you can always fall back on monads to let you write imperative
code in a purely functional language.

In practice, the infrastructure is not there. Hence filling a hash table in
Haskell is 30x slower than in F#.
Post by Vend
Post by Ertugrul Söylemez
Particularly Haskell as the outrider in non-strict
semantics does quite well at that (with GHC).
I've read that Haskell has unpredictable space complexity, which
depends on the inner workings of the compiler.
Look at Ertugrul's Haskell implementation of BWT in this thread. Aside from
being slow, it consumes asymptotically more memory than expected.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop
2009-07-11 18:53:12 UTC
Permalink
Post by Ertugrul Söylemez
Post by Vend
However, if I understand correctly, purely functional languages
typically have performance problems.
That statement wasn't restricted to purely functional languages, but
despite Dr. Harrop's usual noise purely functional languages perform
quite well.
Your fastest BWT in Haskell is still over 100x slower than C.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Raffael Cavallaro
2009-07-10 18:03:29 UTC
Permalink
Post by Ertugrul Söylemez
What's wrong with purely functional languages?
The "purely" part. Some solutions are naturally expressed in a pure
functional manner. Others are not. The programmer should have a choice.

Moreover, there's abundant linguistic and cognitive scientific evidence
that human beings naturally conceptualize the world in terms of
stateful entities and their mutation, not functionally, so imperative
languages fit our natural cognitive models better. This suggests that
DSLs will often include an imperative component in their surface syntax
at the very least.
--
Raffael Cavallaro
Ertugrul Söylemez
2009-07-10 18:51:38 UTC
Permalink
Post by Raffael Cavallaro
Post by Ertugrul Söylemez
What's wrong with purely functional languages?
The "purely" part. Some solutions are naturally expressed in a pure
functional manner. Others are not. The programmer should have a choice.
They have a choice. A purely functional language has a theoretical
property, which is very useful. That doesn't mean you can't use the
things you're used to. You just don't -- usually.
Post by Raffael Cavallaro
Moreover, there's abundant linguistic and cognitive scientific
evidence that human beings naturally conceptualize the world in terms
of stateful entities and their mutation, not functionally, so
imperative languages fit our natural cognitive models better. This
suggests that DSLs will often include an imperative component in their
surface syntax at the very least.
And we all know that humans are far from perfect. They make mistakes
all the time just because of that cognitive property. Safety is all
about restricting this or finding alternatives.


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
Raffael Cavallaro
2009-07-10 20:12:52 UTC
Permalink
Post by Ertugrul Söylemez
And we all know that humans are far from perfect. They make mistakes
all the time just because of that cognitive property. Safety is all
about restricting this or finding alternatives.
And expressiveness is all about *not* restricting the ability to write
the solution in the language of the problem domain just because of some
misplaced notion of "safety."
--
Raffael Cavallaro
Ertugrul Söylemez
2009-07-11 14:13:52 UTC
Permalink
Post by Raffael Cavallaro
Post by Ertugrul Söylemez
And we all know that humans are far from perfect. They make
mistakes all the time just because of that cognitive property.
Safety is all about restricting this or finding alternatives.
And expressiveness is all about *not* restricting the ability to write
the solution in the language of the problem domain just because of
some misplaced notion of "safety."
You may want to show me something that couldn't be implemented in
Haskell, or where the additional safety gets in your way.


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
Raffael Cavallaro
2009-07-11 15:21:55 UTC
Permalink
Post by Ertugrul Söylemez
You may want to show me something that couldn't be implemented in
Haskell, or where the additional safety gets in your way.
"couldn't be implemented" is a turing tarpit red herring. For "gets in
your way," upthread we've just been discussing the pointless need to
use monads just to get simple mutable state.
--
Raffael Cavallaro
Ertugrul Söylemez
2009-07-13 20:13:45 UTC
Permalink
Post by Raffael Cavallaro
Post by Ertugrul Söylemez
You may want to show me something that couldn't be implemented in
Haskell, or where the additional safety gets in your way.
"couldn't be implemented" is a turing tarpit red herring. For "gets in
your way," upthread we've just been discussing the pointless need to
use monads just to get simple mutable state.
You still failed to show how this is "pointless". It's not even a
"need", as there are many other ways to handle side effects in a purely
functional language.


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
Jon Harrop
2009-07-11 19:10:20 UTC
Permalink
Post by Ertugrul Söylemez
Post by Raffael Cavallaro
Post by Ertugrul Söylemez
And we all know that humans are far from perfect. They make
mistakes all the time just because of that cognitive property.
Safety is all about restricting this or finding alternatives.
And expressiveness is all about *not* restricting the ability to write
the solution in the language of the problem domain just because of
some misplaced notion of "safety."
You may want to show me something that couldn't be implemented in
Haskell, or where the additional safety gets in your way.
A Haskell implementation of the BWT sort that gets within 2x the performance
of C.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Ertugrul Söylemez
2009-07-13 20:14:58 UTC
Permalink
Post by Jon Harrop
Post by Ertugrul Söylemez
You may want to show me something that couldn't be implemented in
Haskell, or where the additional safety gets in your way.
A Haskell implementation of the BWT sort that gets within 2x the
performance of C.
I'll consider it when I have some time. =)


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
Jon Harrop
2009-07-13 21:30:51 UTC
Permalink
Post by Ertugrul Söylemez
Post by Jon Harrop
Post by Ertugrul Söylemez
You may want to show me something that couldn't be implemented in
Haskell, or where the additional safety gets in your way.
A Haskell implementation of the BWT sort that gets within 2x the
performance of C.
I'll consider it when I have some time. =)
So decent functional languages are only competitively performant after
infinite development time?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Jon Harrop
2009-07-10 22:09:50 UTC
Permalink
Post by Ertugrul Söylemez
Post by Raffael Cavallaro
Post by Ertugrul Söylemez
What's wrong with purely functional languages?
The "purely" part. Some solutions are naturally expressed in a pure
functional manner. Others are not. The programmer should have a choice.
They have a choice. A purely functional language has a theoretical
property, which is very useful. That doesn't mean you can't use the
things you're used to.
Here is a trivial counter example: mutate an element in an array in O(1).
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Larry D'Anna
2009-07-10 21:13:24 UTC
Permalink
["Followup-To:" header set to comp.lang.lisp.]
Post by Jon Harrop
Here is a trivial counter example: mutate an element in an array in O(1).
easy.

http://cvs.haskell.org/Hugs/pages/libraries/base/Data-Array-ST.html


--larry
Larry D'Anna
2009-07-13 20:58:07 UTC
Permalink
Post by Larry D'Anna
["Followup-To:" header set to comp.lang.lisp.]
Post by Jon Harrop
Here is a trivial counter example: mutate an element in an array in O(1).
easy.
http://cvs.haskell.org/Hugs/pages/libraries/base/Data-Array-ST.html
That is O(n) with GHC.
It is O(1) for unboxed arrays.
I thought it was O(1) for boxed arrays too, but I tested it and defiantly
is not. Any idea why boxed vs. unboxed should make a difference?
The write barrier incurred when mutating a boxed element in an array dirties
the whole array and that causes the GC to traverse the whole array at every
minor/gen0 GC, which is periodic (separated by constant amounts of time for
the purposes of this description). That dirtying is not necessary for
unboxed elements so you do not see the asymptotic performance degradation
with them, e.g. the STUArray of Int in your example.
Why in the world does it have to dirty the whole array? Is there any sane
reason for that or is this just an unfortunate deficiency of GHC? I just can't
believe that an array update is O(n). But but my tests updating a STArray
really is O(n) in GHC. I'm a bit shocked.

--larry

Larry D'Anna
2009-07-10 18:55:48 UTC
Permalink
Post by Raffael Cavallaro
Post by Ertugrul Söylemez
What's wrong with purely functional languages?
The "purely" part. Some solutions are naturally expressed in a pure
functional manner. Others are not. The programmer should have a choice.
Uh, in Haskell you absolutely do have a choice. Haskell gives the programmer
access to all the non-functional things you want: mutable cells, mutable arrays,
foreign functions, IO, etc. You just have to use monads to get to it all. You
can take any imperative algorithm you like and translate it into Haskell in a
totally straightforward way.


--larry
Raffael Cavallaro
2009-07-10 20:12:08 UTC
Permalink
Post by Larry D'Anna
You just have to use monads to get to it all. You
can take any imperative algorithm you like and translate it into Haskell in a
totally straightforward way.
monads. straightforward. <= contradiction in terms
--
Raffael Cavallaro
Larry D'Anna
2009-07-10 21:09:41 UTC
Permalink
Post by Raffael Cavallaro
Post by Larry D'Anna
You just have to use monads to get to it all. You
can take any imperative algorithm you like and translate it into Haskell in a
totally straightforward way.
monads. straightforward. <= contradiction in terms
They're a bit difficult to learn, but once you understand them they're not hard
to use.


--larry
Raffael Cavallaro
2009-07-10 22:43:10 UTC
Permalink
Post by Larry D'Anna
They're a bit difficult to learn, but once you understand them they're not hard
to use.
The point here is that it is completely unnecessary cognitive overhead.
If, semantically, I mean to do mutation of state, I should be able to
just mutate state in a direct fashion, not have to use a state monad.

Having said that, it may (or may not) be a desireable to *implement* a
syntax for mutation in terms of monads, but at the level of surface
syntax, it should just look like ordinary mutation.
--
Raffael Cavallaro
Jon Harrop
2009-07-11 00:05:50 UTC
Permalink
Post by Raffael Cavallaro
Post by Larry D'Anna
They're a bit difficult to learn, but once you understand them they're
not hard to use.
The point here is that it is completely unnecessary cognitive overhead.
All HLL features are "unnecessary cognitive overhead".
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Raffael Cavallaro
2009-07-11 04:11:53 UTC
Permalink
Post by Jon Harrop
Post by Raffael Cavallaro
Post by Larry D'Anna
They're a bit difficult to learn, but once you understand them they're
not hard to use.
The point here is that it is completely unnecessary cognitive overhead.
All HLL features are "unnecessary cognitive overhead".
A feature is unnecessary when it gets in the way of a direct mapping to
the problem domain. High or low level has nothing to do with it. It's a
matter of appropriateness to the the domain. When the domain is about
mutating state, then monads are inappropriate, not because they are
"high level" but because they get in the way of a direct mapping from
the problem domain to code.
--
Raffael Cavallaro
Ertugrul Söylemez
2009-07-11 14:08:11 UTC
Permalink
Post by Raffael Cavallaro
Post by Jon Harrop
Post by Raffael Cavallaro
Post by Larry D'Anna
They're a bit difficult to learn, but once you understand them
they're not hard to use.
The point here is that it is completely unnecessary cognitive overhead.
All HLL features are "unnecessary cognitive overhead".
A feature is unnecessary when it gets in the way of a direct mapping
to the problem domain. High or low level has nothing to do with
it. It's a matter of appropriateness to the the domain. When the
domain is about mutating state, then monads are inappropriate, not
because they are "high level" but because they get in the way of a
direct mapping from the problem domain to code.
State monads _are_ a direct mapping. Monads allow you to create small
problem-specific languages. The problem in this case is state and state
monads encode it in a concise and elegant way, particularly because you
don't lose referential transparency along the way.


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
Raffael Cavallaro
2009-07-11 15:25:25 UTC
Permalink
Post by Ertugrul Söylemez
State monads _are_ a direct mapping.
Introducing some intermediation, such as monads, is, by definition, not
*direct*.
--
Raffael Cavallaro
Paul Rubin
2009-07-11 17:27:38 UTC
Permalink
Post by Raffael Cavallaro
Introducing some intermediation, such as monads, is, by definition,
not *direct*.
That sentence would be equally true if you replaced the word "monads"
with "keystrokes".
Raffael Cavallaro
2009-07-12 03:47:27 UTC
Permalink
Post by Paul Rubin
Post by Raffael Cavallaro
Introducing some intermediation, such as monads, is, by definition,
not *direct*.
That sentence would be equally true if you replaced the word "monads"
with "keystrokes".
Only in a world where programs can be conveyed to the machine
telepathically. But then I'm sure you'd chime in about replacing
"keystrokes" with "thoughts."

It's kind of sad when people jump on the phrasing rather than trying to
make actual sense. We're clearly talking about *unncessary* additional
means to accomplish a task, not the need to use keystrokes to type text.

I'll just say: "Introducing some *unnecessary* intermediation, such as
monads, is, by definition, not *direct*." Is your inner pedant happy
now?
--
Raffael Cavallaro
Paul Rubin
2009-07-12 04:32:01 UTC
Permalink
Post by Raffael Cavallaro
I'll just say: "Introducing some *unnecessary* intermediation, such as
monads, is, by definition, not *direct*." Is your inner pedant happy now?
I could say that traditional effectful computation, in whatever
language, is already done in a monad. Haskell just makes this
explicit.
Raffael Cavallaro
2009-07-13 04:48:49 UTC
Permalink
Post by Paul Rubin
I could say that traditional effectful computation, in whatever
language, is already done in a monad.
You could certainly say it, but it wouldn't be true. Your claim is
rather like saying that everyone who has a traditional Thanksgiving
dinner really craves Tofurky. Haskell is forced to make "effectful
computation" an explicit monad because, having denied itself side
effects, it had to add them back to the language so it could do useful
things. In a "tradtional effectful" language, these obviously useful
features were never eschewed in the first place, so there was no need
to jump through category theory hoops to get them back.


That pure functional languages conceptualize side effects as monads is
just reflection of their narrow view of computation, not a reflection
of the inherent nature of side effects. It is perfectly legitimate (in
fact, it is the human cognitive norm) to conceptualize the world as
inherently stateful and constantly mutating. You only reach for monads
when you insist that the world (or all computation) is a set of
functions returning values.
--
Raffael Cavallaro
Andreas Rossberg
2009-07-13 07:21:37 UTC
Permalink
Post by Raffael Cavallaro
That pure functional languages conceptualize side effects as monads is
just reflection of their narrow view of computation, not a reflection
of the inherent nature of side effects. It is perfectly legitimate (in
fact, it is the human cognitive norm) to conceptualize the world as
inherently stateful and constantly mutating.
People used to conceptualize numbers by using their fingers. Do you
think modern math would have evolved that way? Is set theory or are
the Peano axioms a narrow view of numbers because they eschew fingers?
Post by Raffael Cavallaro
You only reach for monads
when you insist that the world (or all computation) is a set of
functions returning values.
Try talking to a quantum physicist about the world not being a set of
functions. ;-)
Raffael Cavallaro
2009-07-13 13:04:40 UTC
Permalink
Post by Andreas Rossberg
People used to conceptualize numbers by using their fingers.
This is false. Many higher animals have an innate sense of number,
including some who don't even have digits. You're simply repeating a
folk fallacy here.
Post by Andreas Rossberg
Do you
think modern math would have evolved that way? Is set theory or are
the Peano axioms a narrow view of numbers because they eschew fingers?
Post by Raffael Cavallaro
You only reach for monads
when you insist that the world (or all computation) is a set of
functions returning values.
Try talking to a quantum physicist about the world not being a set of
functions. ;-)
Which is tantamount to saying that to be a programmer, one must fully
understand quantum physics. Thank you for providing the reductio ad
absurdum of your own argument for me.

The issue isn't whether the universe is "really" functional or not. The
issue is that programming languages are *not* an interface between
hardware and the intrinsic nature of the universe. Programming
languages are an interface between hardware and human cognitive
abilities. As such they should leverage native human cognitive
abilities, not physicists' most recent, and ever-changing estimate of
the intrinsic nature of the universe, nor any other paradigm that is at
odds with the way people most easily conceptualize a particular problem
domain.

IOW, don't force people to change the way they think best in order to
program; mold programming languages to fit the way people think best.
--
Raffael Cavallaro
Andreas Rossberg
2009-07-13 14:07:53 UTC
Permalink
On Jul 13, 3:04 pm, Raffael Cavallaro
Post by Raffael Cavallaro
Post by Andreas Rossberg
People used to conceptualize numbers by using their fingers.
This is false. Many higher animals have an innate sense of number,
including some who don't even have digits.
I don't see how that falsifies what I said. But anyway, the point was:
hardware and software are highly complex artefacts -- with a degree of
complexity far beyond what people usually cope with. Appealing to how
these people "normally" "conceptualize" things, or worse, summoning
the mythical "Real World", is useless when it comes to finding the
best ways of dealing with this complexity.
Post by Raffael Cavallaro
Post by Andreas Rossberg
Post by Raffael Cavallaro
You only reach for monads
when you insist that the world (or all computation) is a set of
functions returning values.
Try talking to a quantum physicist about the world not being a set of
functions. ;-)
Which is tantamount to saying that to be a programmer, one must fully
understand quantum physics. Thank you for providing the reductio ad
absurdum of your own argument for me.
It is just saying that you should be careful with drawing conclusions
from what you percept as "reality". And you didn't quite notice the
smiley.

- Andreas
Raffael Cavallaro
2009-07-13 15:18:25 UTC
Permalink
Post by Andreas Rossberg
On Jul 13, 3:04 pm, Raffael Cavallaro
Post by Raffael Cavallaro
Post by Andreas Rossberg
People used to conceptualize numbers by using their fingers.
This is false. Many higher animals have an innate sense of number,
including some who don't even have digits.
I don't see how that falsifies what I said.
Because fingers are a mnemonic device, not how numbers are
conceptualized. Does using a laptop mean that I conceptualize numbers
as backlit liquid crystals? Does using arabic numerals mean that I
conceptualize the number three as two stacked semi-circles open on the
left? Hardly.
Post by Andreas Rossberg
hardware and software are highly complex artefacts -- with a degree of
complexity far beyond what people usually cope with. Appealing to how
these people "normally" "conceptualize" things, or worse, summoning
the mythical "Real World", is useless when it comes to finding the
best ways of dealing with this complexity.
Again, I'm not the one appealing to notions of the "real world," you
are. I'm appealing to notions of native cognitive skills. Whether or
not our native cognitive abilites ultimately correspond to "reality" is
a question for philosophers[1], and ultimately largely irrelevant to
leveraging the tools we've been handed by evolution and millenia of
cultural development.

We shouldn't discard native cognitive abilities merely because one
paradigm (functional) has proven extremely useful in a particular
domain (mathematics) and attempt to shoehorn all computation into that
functional model. *Pure* functional programming falls into the trap of
thinking that because a paradigm is useful in many circumstances, it
should be universal. In doing so we discard cognitive abilities that
human beings are excellent at, and which we've been honing for at least
tens of thousands of years. Specifically, the ability to keep track of
the intersecting timelines of numerous, constantly mutating, stateful
entities.
Post by Andreas Rossberg
Post by Raffael Cavallaro
Post by Andreas Rossberg
Post by Raffael Cavallaro
You only reach for monads
when you insist that the world (or all computation) is a set of
functions returning values.
Try talking to a quantum physicist about the world not being a set of
functions. ;-)
Which is tantamount to saying that to be a programmer, one must fully
understand quantum physics. Thank you for providing the reductio ad
absurdum of your own argument for me.
It is just saying that you should be careful with drawing conclusions
from what you percept as "reality". And you didn't quite notice the
smiley.
Again I'm not the one appealing to some ultimate "reality," you are. I
make no claims that native human cognitive abilities correspond to some
ultimate "reality." I merely claim that they are powerful tools that we
discard to our loss.



[1] Yes, philosophers, not physicists. The claim that our current best
physical model of the universe corresponds to some underlying ultimate
reality is a metaphysical claim, not a scientific one. Science itself
is mute on this point.
--
Raffael Cavallaro
Jon Harrop
2009-07-13 17:17:07 UTC
Permalink
Post by Andreas Rossberg
Post by Raffael Cavallaro
That pure functional languages conceptualize side effects as monads is
just reflection of their narrow view of computation, not a reflection
of the inherent nature of side effects. It is perfectly legitimate (in
fact, it is the human cognitive norm) to conceptualize the world as
inherently stateful and constantly mutating.
People used to conceptualize numbers by using their fingers. Do you
think modern math would have evolved that way? Is set theory or are
the Peano axioms a narrow view of numbers because they eschew fingers?
Side effects are essential in programming but fingers are not in
mathematics. So how is that analogous?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Nobody
2009-07-13 18:35:08 UTC
Permalink
Post by Raffael Cavallaro
That pure functional languages conceptualize side effects as monads is
just reflection of their narrow view of computation,
You have it backwards. The fact that imperative languages assume
statefulness as a given is a reflection of their narrow view of
computation.

IMHO, imperative programmers don't like Haskell's Monad class because it
takes what is fundamental to imperative languages and turns it into a
"thing". And such a small thing at that.

I can't think of any other reason why this subject seems to provoke such
hostility from people with an imperative mind-set.
Post by Raffael Cavallaro
not a reflection
of the inherent nature of side effects. It is perfectly legitimate (in
fact, it is the human cognitive norm) to conceptualize the world as
inherently stateful and constantly mutating.
You have a choice in how you conceptualise the world. I don't think the
Church-Turing thesis is news to anyone here.

The question isn't about which model is "legitimate", but which is a good
idea.

As for "human cognitive norms", there's often a big difference between
perception and reality, and you generally get better results if you deal
with the latter.
Ertugrul Söylemez
2009-07-13 20:12:10 UTC
Permalink
Post by Raffael Cavallaro
Post by Paul Rubin
I could say that traditional effectful computation, in whatever
language, is already done in a monad.
You could certainly say it, but it wouldn't be true. Your claim is
rather like saying that everyone who has a traditional Thanksgiving
dinner really craves Tofurky. Haskell is forced to make "effectful
computation" an explicit monad because, having denied itself side
effects, it had to add them back to the language so it could do useful
things. In a "tradtional effectful" language, these obviously useful
features were never eschewed in the first place, so there was no need
to jump through category theory hoops to get them back.
That pure functional languages conceptualize side effects as monads is
just reflection of their narrow view of computation, not a reflection
of the inherent nature of side effects. It is perfectly legitimate (in
fact, it is the human cognitive norm) to conceptualize the world as
inherently stateful and constantly mutating. You only reach for monads
when you insist that the world (or all computation) is a set of
functions returning values.
People love to use metaphors in such discussions. I doubt that it's
useful in any way. Let's discuss facts instead.

Firstly monads are not an indirection. Expressing side effects or state
monadically could hardly be any more direct. You have state, you can
'get' it, use it, 'modify' it and/or 'put' it back. The same with IO,
just that you have no 'get' function, because the state of the universe
has no distinct value in memory. Instead you have a bunch of functions
like 'putStr', 'hGetLine', 'connect', etc., which modify the universe
state.

What's wrong with this? It's not more to type than in C, in fact it's
less to type in most cases and even more intuitive to read. What could
be more intuitive than

forever (putStrLn "Hello world!")

for an endless loop printing a line repeatedly? It's just that people
who don't like monads either never used them (properly) or never made
efforts to understand them. Evidence for this comes from the frequent
but wrong claim that monads are there to "bring back" effectful
computation. Monads are universal tools for many things and show their
true power, as soon as you start combining them through monad
transformers.

However, this post is probably pointless anyway. Most people on Usenet
are totally obstinate. I recommend you to try out Haskell for more than
an hour. After all I was a convinced C programmer a few years ago, so
it's not that I'm so fond of Haskell because it's the only thing I know.
And that's about all I can say at this point.


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
David Formosa (aka ? the Platypus)
2009-07-12 10:59:56 UTC
Permalink
On Fri, 10 Jul 2009 16:12:08 -0400, Raffael Cavallaro
Post by Raffael Cavallaro
Post by Larry D'Anna
You just have to use monads to get to it all. You
can take any imperative algorithm you like and translate it into Haskell in a
totally straightforward way.
monads. straightforward. <= contradiction in terms
The thing is you don't have to understand monads to use them. If you
just use the do-syntax you can use the monad model as an abstraction
and not worry about the model itself.
Jon Harrop
2009-07-12 18:08:45 UTC
Permalink
Post by David Formosa (aka ? the Platypus)
On Fri, 10 Jul 2009 16:12:08 -0400, Raffael Cavallaro
Post by Raffael Cavallaro
Post by Larry D'Anna
You just have to use monads to get to it all. You
can take any imperative algorithm you like and translate it into Haskell
in a totally straightforward way.
monads. straightforward. <= contradiction in terms
The thing is you don't have to understand monads to use them. If you
just use the do-syntax you can use the monad model as an abstraction
and not worry about the model itself.
You cannot answer the questions I asked about the array benchmark code in
Haskell without explaining monads. So a programmer who does not understand
monads cannot even hope to accomplish the simplest of tasks.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Florian Kreidler
2009-07-12 17:14:39 UTC
Permalink
... a programmer who does not understand
monads cannot even hope to accomplish the simplest of tasks.
You're absolutely right.
Slobodan Blazeski
2009-07-10 19:47:41 UTC
Permalink
Post by Ertugrul Söylemez
Post by fft1976
But because most popular languages are imperative, people are whining
about those 1/4 cases and some disturbed individuals even think
languages should be pure-functional.
What's wrong with purely functional languages?
They suck when the problem is not purely functional.

Slobodan
George Neuner
2009-07-10 17:09:20 UTC
Permalink
Post by fft1976
So what do you want from a programming language?
Excellent question. I've never really tried to enumerate it before...
(snip)
This "being functional" is an unhealthy obsession. 3/4 of the time
imperative idioms are more convenient, and 1/4 of the time functional
ones are more convenient.
Only because that's what you are used to.
Post by fft1976
But because most popular languages are imperative, people are whining
about those 1/4 cases and some disturbed individuals even think
languages should be pure-functional.
And they are wrong. Strict, impure functional languages are easier to
use and easier to reason about. Laziness is occasionally a good thing
to have, but it doesn't need to be built in - it can be implemented
reasonably on top of any language with closures.
Post by fft1976
What I want is a safe (or has an option to be safe), fast mostly
imperative language that doesn't suck.
Then why are you posting in groups that promote functional languages?
Post by fft1976
C++ (if you are very good and very careful), Java and OCaml are
decent, but not quite what I want. Maybe D and Ada, although I don't
know about those.
I've always liked Modula-3. Ada is great if you are working on bare
hardware but IMO it is not a great general application language.

George
fft1976
2009-07-10 22:17:45 UTC
Permalink
Post by George Neuner
Then why are you posting in groups that promote functional languages?
To help you see the light.
George Neuner
2009-07-11 00:12:55 UTC
Permalink
Post by fft1976
Post by George Neuner
Then why are you posting in groups that promote functional languages?
To help you see the light.
That is a moronic statement given that you know nothing of my
background. I'd wager I've programmed in more languages than you've
even heard of.

George
Jon Harrop
2009-07-10 23:53:38 UTC
Permalink
Post by George Neuner
Post by fft1976
But because most popular languages are imperative, people are whining
about those 1/4 cases and some disturbed individuals even think
languages should be pure-functional.
And they are wrong. Strict, impure functional languages are easier to
use and easier to reason about. Laziness is occasionally a good thing
to have, but it doesn't need to be built in - it can be implemented
reasonably on top of any language with closures.
But at what cost? F# is certainly better than OCaml but it can still be a
long way from the clarify of Haskell.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
George Neuner
2009-07-11 00:10:10 UTC
Permalink
Post by Jon Harrop
Post by George Neuner
Post by fft1976
But because most popular languages are imperative, people are whining
about those 1/4 cases and some disturbed individuals even think
languages should be pure-functional.
And they are wrong. Strict, impure functional languages are easier to
use and easier to reason about. Laziness is occasionally a good thing
to have, but it doesn't need to be built in - it can be implemented
reasonably on top of any language with closures.
But at what cost? F# is certainly better than OCaml but it can still be a
long way from the clarify of Haskell.
Agreed. But, apart from streams, how often are lazy constructs really
used? Lazy data structures definitely have utility, but I think the
majority of general programming tasks does not need them. Making lazy
evaluation the default, as in Haskell, has been a continual source of
problems. Lazy data is just a closure to compute a value and so it
can be implemented on any language with closures. Perhaps it does
need to be a primitive for performance ... but not a default mode.

George
Jon Harrop
2009-07-11 01:54:43 UTC
Permalink
Post by George Neuner
Agreed. But, apart from streams, how often are lazy constructs really
used? Lazy data structures definitely have utility, but I think the
majority of general programming tasks does not need them. Making lazy
evaluation the default, as in Haskell, has been a continual source of
problems.
Yes.
Post by George Neuner
Lazy data is just a closure to compute a value and so it
can be implemented on any language with closures.
You need to overwrite the closure with the value it computed as well, of
course.
Post by George Neuner
Perhaps it does need to be a primitive for performance ... but not a
default mode.
Actually there is no decent implementation of thunks from a performance
perspective because they can be forced from threads simultaneously so they,
essentially, require locking. Obviously every subexpression in a non-strict
language is potentially a thunk so the overhead of all those locks is
enormous. GHC has adopted some elaborate workarounds for its "sparks" but
they are fragile, e.g. seemingly-innocuous tweaks can make the GC leak
indefinitely.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Paul Rubin
2009-07-11 00:48:56 UTC
Permalink
Post by George Neuner
Lazy data is just a closure to compute a value and so it
can be implemented on any language with closures.
It's more complicated than that since it's usually implemented as
graph reduction. Coding it directly as closures (call-by-name) can
cause exponential slowdown.
Ertugrul Söylemez
2009-07-11 14:03:08 UTC
Permalink
Post by George Neuner
Post by fft1976
But because most popular languages are imperative, people are
whining about those 1/4 cases and some disturbed individuals even
think languages should be pure-functional.
And they are wrong. Strict, impure functional languages are easier to
use and easier to reason about. Laziness is occasionally a good thing
to have, but it doesn't need to be built in - it can be implemented
reasonably on top of any language with closures.
No, it cannot, because lazy code needs to be aware of the laziness. In
other words, you couldn't feed a lazy value to a strict function. You
would need to specifically write a non-strict variant of it. Laziness
is not a language feature, but a semantic property.


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
Continue reading on narkive:
Loading...