What do you LISPers think of Haskell?

On 28 Aug., 01:33, Jon Harrop <j...@ffconsultancy.com> wrote:
> parnell wrote:
> >> So we cannot reasonably draw any relevant conclusions from this data, at
> >> least not for Ubuntu where such trend data is not even available (AFAIK).
>
> > Yes we finally agree.
>
> >> Due to the aforementioned problems those data are not an accurate
> >> reflection of anything interesting and the conclusion stands.
>
> > Conclusion stands, I don't think so. Remember what you just said: "we
> > cannot reasonably draw any relevant conclusions from this data".
>
> Note that I was talking about the "recent" data that you analyzed and
> not the "installed" data that was analyzed in the article that I cited.
>
> > If you examine the graph of the old vs the recent you see that they
> > are nearly the inverse of each other and as recent jumps old falls.
>
> Yes.
>
> > It would seem to be that these are caused by people who do not
> > otherwise use the packages updating the package and then as the
> > package remains unused it moves from the recent into the old category.
>
> >http://people.debian.org/~igloo/popc...?packages=unis...
>
> %2Cdarcs&show_installed=on&show_vote=on&show_old=o n&show_recent=on&want_leg end=on&from_date=&to_date=&hlght_date=&date_fmt=%2 5Y-%25m&beenhere=1
>
>
>
> > The voted installs seem to trend right along with the installs,
>
> I disagree. Indeed, over the past year the "voted" has fallen whereas
> the "installs" have risen for Darcs according to the data you just cited.
>
> From the data you cite, large fluctuations correlate between the "old"
> and "recent" data and the "vote" column to a lesser degree but
> the "installed" column (that I analyzed) does not exhibit these
> fluctuations at all.
>
> > so if
> > they are not "an accurate reflection of anything interesting" then
> > neither are the total installs in which case we are in complete
> > agreement.
>
> Had your previous assertion been true then I would agree but I cannot see
> that this is the case. The "installed" data that I analyzed does not trend
> with the "vote" data and does not correlate with the fluctuations in
> the "recent" and "old" data. So this source of error did not affect my
> analysis.
>
>
>
> >> > I agree with the claim:
> >> > FFTW is 10x more successful than any other open source OCaml or
> >> > Haskell software package in the Debian/Unbuntu popcon.
>
> >> You are talking about binary packages. The core of the FFTW source code
> >> is, of course, written in OCaml. Moreover, we can quantify the number of
> >> source code installs, which certainly does explicitly include the OCaml
> >> code. For Debian alone, we find:
>
> >> 847 * fftw3 * * * * * * * * * * * * *15976*2305 *5802 *2180 *5689
>
> >> So the OCaml source code to FFTW is being downloaded 2,180 times per
> >> month by Debian users alone.
>
> > Jon I agree 100% that FFTW is an "OCaml" package I did not mean to
> > imply otherwise. *My point is that it is 10 times more popular than
> > any of the other packages that you included in your data.
>
> Yes.
>
> > The other
> > OCaml and the Haskell packages are in the same ball park as far as
> > total installs or "votes" are concerned.
>
> Unison also has 3x more installs than anything written in Haskell but my
> original point was also that there are many more popular projects written
> in OCaml than Haskell. Indeed, even excluding FFTW, open source OCaml
> software on Debian+Ubuntu still has 7x more users than Haskell and that (to
> me) is a very significant discrepancy. Moreover, it is an underestimate
> because we have not counted several other popular OCaml projects like
> MTASC, ADVI, HaXe and so on.
>
> > So what one can conclude from this is that the language that one chooses
> > to create an open source project in does not seem to matter nearly as much
> > as what that package will do (or really to be more accurate some unknown
> > factor that is not captured in the data).
>
> That is only one of many possible explanations. For example, another
> equally-plausible explanation is that Haskell is inherently incapable of
> solving these problems in a usable way. I suspect the truth is somewhere in
> between.
>

This (popularity of Haskell and OCAML) is completely off-topic in
comp.lang.lisp. Move to comp.lang.functional. You may advertise there.

On Wed, 27 Aug 2008 21:20:51 +0100, Jon Harrop wrote:

> Some do but FFTW certainly does not. FFTW is the result of decades of
> work by the world's foremost experts on the subject who received
> prestigious awards for their ground breaking work. FFTW is such a
> tremendous achievement that many commercial users, including The
> MathWorks for MATLAB, have paid to incorporate FFTW into their
> commercial products under license from MIT.

FFTW is a superb piece of work, but I think that it's important to note
that its use of OCaml is strictly off-line and not performance critical.
The OCaml is used to generate C code, and is not actually run by anyone
but the FFTW developers. Everyone else just compiles and runs the
generated C code.

So the choice of OCaml comes down to familiarity and convenience for the
developers, rather than run-time performance. Given what it's doing (I
haven't looked at the OCaml code since the very first version came out,
so I've essentially forgotten it) I suspect that the pattern matching
functional nature was much more important than the type safety or
compiled performance. I suppose that Frigo and Johnson have written
about their choice of OCaml somewhere. Doesn't seem to be one on the
FFTW web site though. Skimming some of their papers, it's clearly a good
choice, because the expression simplifiers can be expressed quite neatly,
and matching seems to be used extensively. I suspect that Haskell or
Prolog or even one of the modern schemes (with structures and match)
could have been used just about as well, had the authors been so inclined.

Cheers,

--
Andrew

"xahlee@gmail.com" <xahlee@gmail.com> writes:

> hi Jon Harrop,
> [...]
>
> Recently, i answered to a post used your name and your photo in
> group.goople.com's profile. When i answered that post, i thought it
> was from you. Thanks for letting me know otherwise.
>
> (See:
>
> Fake Jon Harrop post
> http://groups.google.com/group/comp....f971ff443e2ce5
>
> Fake Jon Harrop profile
> http://groups.google.com/groups/prof...gpE8SFMrQg3Ptg
> )

Thanks for reminding me. I enjoyed reading those also a second time.

Nicolas

Andrew Reilly wrote:
> On Wed, 27 Aug 2008 21:20:51 +0100, Jon Harrop wrote:
>> Some do but FFTW certainly does not. FFTW is the result of decades of
>> work by the world's foremost experts on the subject who received
>> prestigious awards for their ground breaking work. FFTW is such a
>> tremendous achievement that many commercial users, including The
>> MathWorks for MATLAB, have paid to incorporate FFTW into their
>> commercial products under license from MIT.
>
> FFTW is a superb piece of work, but I think that it's important to note
> that its use of OCaml is strictly off-line

Yes.

> and not performance critical.

No. OCaml's performance is as important here as it is in any other compiler:
compile time performance is important.

> The OCaml is used to generate C code, and is not actually run by anyone
> but the FFTW developers. Everyone else just compiles and runs the
> generated C code.

On the contrary, FFTW's performance stems from its ability to generate
custom codelets for transform lengths that the user values. Users do this
by running the OCaml code to generate more C. Hence the Debian source
package is downloaded more often than the binary package because users need
the OCaml source code.

> So the choice of OCaml comes down to familiarity and convenience for the
> developers, rather than run-time performance.

I do not believe so.

> Given what it's doing (I
> haven't looked at the OCaml code since the very first version came out,
> so I've essentially forgotten it) I suspect that the pattern matching
> functional nature was much more important than the type safety or
> compiled performance.

On the contrary, generating custom codelets is a very time consuming process
that required days of computation when FFTW was first released. Moreover,
the authors of FFTW would have repeated this process countless times to
obtain their results and perform thorough benchmarking of the run-time.

So OCaml's predictable and excellent performance was unquestionably of
critical importance to this high-profile project.

> I suppose that Frigo and Johnson have written
> about their choice of OCaml somewhere. Doesn't seem to be one on the
> FFTW web site though. Skimming some of their papers, it's clearly a good
> choice, because the expression simplifiers can be expressed quite neatly,
> and matching seems to be used extensively.

Yes.

> I suspect that Haskell or
> Prolog or even one of the modern schemes (with structures and match)
> could have been used just about as well, had the authors been so inclined.

Until there is evidence to support your hypothesis, we know only that OCaml
is capable of this.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

> Had your previous assertion been true then I would agree but I cannot see
> that this is the case. The "installed" data that I analyzed does not trend
> with the "vote" data and does not correlate with the fluctuations in
> the "recent" and "old" data. So this source of error did not affect my
> analysis.

http://people.debian.org/~igloo/popc...25m&beenhere=1


The voted category and the installed do not show the wild fluctuations
of the recent or old categories. When you count the installed
category you are counting installs of software that is never used,
completely invalidating your analysis.

On Thu, 28 Aug 2008 05:05:47 -0700, parnell wrote:

> The voted category and the installed do not show the wild fluctuations
> of the recent or old categories. When you count the installed category
> you are counting installs of software that is never used, completely
> invalidating your analysis.

Has is ever occurred to you that you are tirelessly arguing about a
statistic that is quite meaningless when you consider the original
question (popularity of programming languages)? Just asking.

The fact that your opponent can't fill up his day with anything
productive and thus has the time to engage in these inane arguments does
not mean that you should, too.

Tamas

On Thu, 28 Aug 2008 11:39:36 +0100, Jon Harrop wrote:

> On the contrary, FFTW's performance stems from its ability to generate
> custom codelets for transform lengths that the user values. Users do
> this by running the OCaml code to generate more C. Hence the Debian
> source package is downloaded more often than the binary package because
> users need the OCaml source code.

No, all of the codelets are already generated and shipped with the source
distribution. These are tested for performance at run-time (or at least
when the wisdom is generated). The FreeBSD port of fftw3 does not have
ocaml as a compile or run-time dependency. Sure the ocaml source ships
with the distribution too, in case anyone cares to fiddle with it, I
suppose. Indeed, I have fftw3 on my system (it's a dependency of 18
other packages on my system), but I don't have ocaml.

Maybe the Debian maintainers do things differently.

Cheers,

--
Andrew

On 20 Ago, 02:07, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> DeverLite <derby.lit...@gmail.com> writes:
> > [...] Although very flexible, and good at catching errors at compile
> > time, I found the typing system in Haskell sometimes got in the way.
> > Lisp let's you declare types, but if you don't want to you don't have
> > to, and this tends to make it more flexible than Haskell.
>
> Actually, what the lisp type system means is that in lisp we program
> in generic mode by default.
>
> When you write:
>
> int fact(int x){ return (x<=0)?1:x*fact(x-1); }
>
> it's statically typed, but it's also SPECIFICALLY typed.
>
> When you write in lisp:
>
> (defun fact (x) (if (<= x 0) 1 (* x (fact (1- x)))))
>
> it's already a generic function (not a lisp generic function,
> technically, but what other programming languages call a generic
> function):
>
> (mapcar 'fact '(4 4.0 4.0l0 5/2))
> --> (24 24.0 24.0L0 15/8)

But the mathematical factorial function is defined only on natural
numbers, hence this behavior is most likely incorrect.

Moreover, in dynamically typed languages like Lisp there is the risk
of having a statement like this buried deep in your program:

(if (or (long-and-complicated-computation-returned-true) (user-pressed-
ctrl-alt-shift-tab-right-mouse-button))
(setq bomb "goodbye")
(setq bomb 42))

And then somewhere else a (fact bomb) makes your program crash and
your client angry.

> to get the same in C++ you would have to write:
>
> #include <rational.hxx>
> template <typename T> fact (T x){ return (x<=0)?1:x*fact(x-1);}
>
> ... fact(4),fact(4.0),fact(4.0d0),fact(Rational(5,2)) ...
>
> I hope Haskell is able to derive these instances automatically.

Why do you hope so, given that this behavior is likely to be
incorrect?

Anyway, Haskell infers a generic type if you don't provide type
declarations, but it's generally considered a good programming
practice to provide type declarations precisely to avoid such kind of
behaviors.

> But you can easily get even more genericity, either using non CL
> operators that you can easily redefine (eg. as lisp generic
> functions), by shadowing them to the same effect, or by using
> functions passed in argument. CL:SORT is generic because it takes a
> LESSP function, so it can be applied on sequences of any kind of
> object.
>
> So what statically checked type system proponents detract as duck
> typing is actually that lisp works in the Generic Mode gears by
> default.

I'm not sure about Common Lisp, but in Scheme, while arithmetic
operators are overloaded, most library function aren't (there are
different procedures for doing the same operation on lists, vectors,
strings and streams, for instance), hence I wouldn't consider the
language particularly generically typed.

> --
> __Pascal Bourguignon__ http://www.informatimago.com/
> I need a new toy.
> Tail of black dog keeps good time.
> Pounce! Good dog! Good dog!

Andrew Reilly wrote:
> On Thu, 28 Aug 2008 11:39:36 +0100, Jon Harrop wrote:
>> On the contrary, FFTW's performance stems from its ability to generate
>> custom codelets for transform lengths that the user values. Users do
>> this by running the OCaml code to generate more C. Hence the Debian
>> source package is downloaded more often than the binary package because
>> users need the OCaml source code.
>
> No, all of the codelets are already generated and shipped with the source
> distribution.

No, *some* codelets are generated and shipped but by no mean all (infinity)
of them. This is precisely the purpose of the genfft tool: you can use it
to generate new codelets that are not bundled in order to improve
performance for certain lengths of transform.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

Tamas K Papp wrote:
> On Thu, 28 Aug 2008 05:05:47 -0700, parnell wrote:
>> The voted category and the installed do not show the wild fluctuations
>> of the recent or old categories. When you count the installed category
>> you are counting installs of software that is never used, completely
>> invalidating your analysis.
>
> Has is ever occurred to you that you are tirelessly arguing about a
> statistic that is quite meaningless when you consider the original
> question (popularity of programming languages)?

That was not the original question.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u