Re: LISP vs HASKELL vs PROLOG
fft1976
> Larry Coleman wrote:
> > 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
> 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, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
fft1976
> fft1976 wrote:
> > 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
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
Ertugrul Söylemez
> > > 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.
> 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?
> 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.
> 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/
George Neuner
wrote:
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
George Neuner
wrote:
>On Jul 9, 4:32�pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>> Larry Coleman wrote:
>> > 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.
>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.
>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?
>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
Jon Harrop
> fft1976 <fft...@gmail.com> wrote:
>> 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.
>> 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.
> 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".
> 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.
> 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".
> 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
George Neuner
<alessi...@gmail.com> wrote:
>On Jul 10, 10:34�am, fft1976 <fft1...@gmail.com> wrote:
>> On Jul 10, 1:23�am, Frank Buss <f...@frank-buss.de> wrote:
>>
>> > fft1976 wrote:
>> > > 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).
>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
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.
> > 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?
>
> > 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.
> > 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.
Raffael Cavallaro
> 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
Jon Harrop
> 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#).
>> 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.
Jon Harrop
> On Fri, 10 Jul 2009 01:34:49 -0700 (PDT), fft1976 <fft...@gmail.com>
> wrote:
>>On Jul 10, 1:23 am, Frank Buss <f...@frank-buss.de> wrote:
>>> 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.
Ertugrul Söylemez
> > 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...?
> > > 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'.
> > 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.
> > 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.
> 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.
> 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).
> > 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.
> > > 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.
> > 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.
!!!@!!!
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!!!
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.
> 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.
Frank Buss
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?
Larry D'Anna
>
> 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
!!!@!!!
>
> 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
> > What's wrong with purely functional languages?
>
> . Unpredictable performance.
Wrong.
> . Unreliable.
Wrong (although right to some extent on PPC).
> . Uninteroperable.
Right. That's something that could use some improvement.
> > 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".
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.
> 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.
Ertugrul Söylemez
!!!@!!!
Completely appropriate with the case here.
Nice one :D
Slobodan Blazeski
> > 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
Raffael Cavallaro
> 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
Raffael Cavallaro
> 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
Jon Harrop
> Jon Harrop <j...@ffconsultancy.com> wrote:
>> > What's wrong with purely functional languages?
>>
>> . Unpredictable performance.
>
> Wrong.
There is overwhelming evidence to the contrary. Indeed, you provide more
below...
>> 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
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.
Jon Harrop
> Raffael Cavallaro <raffaelc...@pas.espam.s.il.vous.plait.mac.com>
> wrote:
>> > 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).
Larry D'Anna
>> 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
Larry D'Anna
On 2009-07-10, Jon Harrop <j...@ffconsultancy.com> wrote:
> 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
fft1976
> Then why are you posting in groups that promote functional languages?
To help you see the light.
Raffael Cavallaro
> 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
> On Fri, 10 Jul 2009 01:10:49 -0700 (PDT), fft1976 <fft...@gmail.com>
> wrote:
>>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.
Jon Harrop
> On 2009-07-10 17:09:41 -0400, Larry D'Anna <la...@elder-gods.org> said:
>> 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".
Rob Warnock
+---------------
| "!!!@!!!" <elto...@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 <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
fft1976
> 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?
Jon Harrop
I am implementing a VM and language. I appreciate peer review of my ideas.
George Neuner
wrote:
>George Neuner wrote:
>> On Fri, 10 Jul 2009 01:34:49 -0700 (PDT), fft1976 <fft...@gmail.com>
>> wrote:
>>>On Jul 10, 1:23�am, Frank Buss <f...@frank-buss.de> wrote:
>>>> 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
George Neuner
wrote:
>On Jul 10, 10:04�am, George Neuner <gneun...@comcast.net> wrote:
>
>> 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.
>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
George Neuner
wrote:
>George Neuner wrote:
>> On Fri, 10 Jul 2009 01:10:49 -0700 (PDT), fft1976 <fft...@gmail.com>
>> wrote:
>>>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
George Neuner
wrote:
>On Jul 10, 10:09�am, George Neuner <gneun...@comcast.net> wrote:
>
>> 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
fft1976
> On Fri, 10 Jul 2009 16:09:37 -0700 (PDT), fft1976 <fft1...@gmail.com>
> wrote:
>
> >On Jul 10, 10:04 am, George Neuner <gneun...@comcast.net> wrote:
>
> >> 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.
> >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.
Jon Harrop
> 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.
> 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.
> 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.
Paul Rubin
> 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.
ACL
is trolling?'
On Jul 10, 6:05 pm, wrote:
> Ertugrul Söylemez wrote:
> > wrote:
> >> > What's wrong with purely functional languages?
>
> >> . Unpredictable performance.
>
> > Wrong.
>
> There is overwhelming evidence to the contrary. Indeed, you provide more
> below...
>
> >> 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.
> > 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
>
The trolled posts something to prove that his language is productive.
> 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...
> 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
> On Fri, 10 Jul 2009 20:36:55 +0100, Jon Harrop <j...@ffconsultancy.com>
> wrote:
>>George Neuner wrote:
>>> On Fri, 10 Jul 2009 01:34:49 -0700 (PDT), fft1976 <fft...@gmail.com>
>>> wrote:
>>>>On Jul 10, 1:23 am, Frank Buss <f...@frank-buss.de> wrote:
>>>>> 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.
> 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. :-)
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.
> 'Haskell is 200x slower' than ...? he doesn't specify what it is
> 200x slower than.
I explicitly wrote "200x slower than C++".
>> > 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
>
> The trolled posts something to prove that his language is productive.
>
>> 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.
> specifically well known for its speed.
Did you want to compare Haskell with badly written inefficient C?
> 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.
> 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.
>> 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.
> 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.
fft1976
> 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.
Raffael Cavallaro
> Raffael Cavallaro wrote:
>> On 2009-07-10 17:09:41 -0400, Larry D'Anna <la...@elder-gods.org> said:
>>> 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
Vend
> Vend wrote:
> > 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.
> >> 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.
Vend
> > F# is not purely functional.
>
> So...?
I think we were discussing purely functional languages.
> > 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?
> 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.
> > > 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.
> 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.
> > 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.
> > 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.
> 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.
> > > 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.
Andreas Rossberg
>
> 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.
> 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.
> > > 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.
> 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.
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
> On Jul 11, 10:50 am, Vend <ven...@virgilio.it> wrote:
>
>
>
> > 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.
> 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?
> > 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.
> > 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.
>
> 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.
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.
> 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).
> > > 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.
>
> > 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
> > 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/
Ertugrul Söylemez
> > 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.
Ertugrul Söylemez
> >>> 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.
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.
Raffael Cavallaro
> 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
Raffael Cavallaro
> State monads _are_ a direct mapping.
Introducing some intermediation, such as monads, is, by definition, not
*direct*.
--
Raffael Cavallaro
Paul Rubin
> 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".
Jon Harrop
> Jon Harrop <j...@ffconsultancy.com> wrote:
>> > 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.
Jon Harrop
> Vend <ven...@virgilio.it> wrote:
>> 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.
Jon Harrop
> On Jul 10, 8:42 pm, Ertugrul Söylemez <e...@ertes.de> wrote:
>> > F# is not purely functional.
>> 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#.
>> 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.
Jon Harrop
> Raffael Cavallaro <raffaelc...@pas.espam.s.il.vous.plait.mac.com>
> wrote:
>> > 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.
Vassil Nikolov
On Sat, 11 Jul 2009 03:03:30 +0100, Jon Harrop <j...@ffconsultancy.com> said:
> George Neuner wrote:
>> On Fri, 10 Jul 2009 20:36:55 +0100, Jon Harrop <j...@ffconsultancy.com>
>> wrote:
>>> ...
>>> 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.
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
> > wrote:
> >>On Jul 10, 1:23 am, Frank Buss <f...@frank-buss.de> wrote:
> >>> 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?
>
> 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?
ACL
> ACL wrote:
> >> >> 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.
> > '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
>
> >> > 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
>
> > The trolled posts something to prove that his language is productive.
>
> >> 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.
> > 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.
> > 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?
> > 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.
> >> 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....
> > 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.
Raffael Cavallaro
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
Jon Harrop
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.
Paul Rubin
> 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.
Jon Harrop
> On Jul 10, 10:19 pm, wrote:
>> ACL wrote:
>> >> >> 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
>> > '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.
>> > 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.
>> > 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.
> 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.
>> > 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?
>> >> 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.
>> > 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.
Richard Heathfield
> ACL wrote:
>> On Jul 10, 10:19 pm, wrote:
>>> ACL wrote:
>>> >> >> 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
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
David Formosa (aka ? the Platypus)
<raffaelc...@pas.espam.s.il.vous.plait.mac.com> wrote:
> On 2009-07-10 14:55:48 -0400, Larry D'Anna <la...@elder-gods.org> said:
>
>> 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.
David Formosa (aka ? the Platypus)
[...]
> 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
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.
Jon Harrop
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.
Florian Kreidler
> ... a programmer who does not understand
> monads cannot even hope to accomplish the simplest of tasks.
You're absolutely right.
Scott Burson
>
> 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
toby
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. ]
Jon Harrop
> 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.
> 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.
> 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.
> 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.
> 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.
> * - "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.
Jon Harrop
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.
toby
> toby wrote:
> > 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?
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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.
>
> > * - "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
Raffael Cavallaro
> 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
Scott Burson
> Scott Burson wrote:
> > 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.
> 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
Andreas Rossberg
>
> 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?
> 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
> 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.
> 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?
>
>> 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
<raffaelcavall...@pas.espam.s.il.vous.plait.mac.com> wrote:
> > 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.
> >> 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
> On Jul 13, 3:04�pm, Raffael Cavallaro
> <raffaelcavall...@pas.espam.s.il.vous.plait.mac.com> wrote:
>>> 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.
> 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.
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.
>
>>>> 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
> On Jul 13, 6:48 am, Raffael Cavallaro wrote:
>>
>> 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?
Jon Harrop
> On Jul 12, 8:31 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>> toby wrote:
>> > 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".
>> > [ 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.
> 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".
Nobody
> 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.
> 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
> >>>> 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.
> >>> 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
> 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.
Ertugrul Söylemez
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.
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.
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. =)
Jon Harrop
> 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.
Jon Harrop
> Jon Harrop <j...@ffconsultancy.com> wrote:
>> > 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?
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.
Larry D'Anna
> Larry D'Anna wrote:
>> On 2009-07-11, Johannes Laire <johanne...@gmail.com> wrote:
>>> Jon Harrop wrote:
>>>> Larry D'Anna wrote:
>>>> > ["Followup-To:" header set to comp.lang.lisp.]
>>>> > On 2009-07-10, Jon Harrop <j...@ffconsultancy.com> wrote:
>>>> >> 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