headers
Bulat Ziganshin | 1 Jun 2009 10:18
Picon

The speed, size and dependability of programming languages

Hello haskell,

Interesting blog post comparing speed and expressiveness of many
languages: http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html

--

-- 
Best regards,
 Bulat                          mailto:Bulat.Ziganshin <at> gmail.com
Permalink | Reply | 8 comments |
headers
Simon Marlow | 1 Jun 2009 12:54
Picon

Reminder: Haskell Implementers' Workshop CFT deadline in 2 weeks

Please consider submitting a talk proposal for the Haskell Implementers' 
Workshop.  I'm pretty excited about this meeting - it promises to be a 
lively and enjoyable day.  The deadline for submissions is a couple of 
weeks away, all you have to do is write an abstract:

                         Call for Talks
             ACM SIGPLAN Haskell Implementers' Workshop

       http://haskell.org/haskellwiki/HaskellImplementorsWorkshop
              Edinburgh, Scotland, September 5, 2009
        The workshop will be held in conjunction with ICFP 2009
               http://www.cs.nott.ac.uk/~gmh/icfp09.html

Important dates

Proposal Deadline: 15 June 2009
Notification:       3 July 2009

The Haskell Implementers Workshop is a new workshop to be held
alongside ICFP 2009 this year in Edinburgh, Scotland.  There will be
no proceedings; it is an informal gathering of people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure.

This new workshop reflects the growth of the user community: there is
a clear need for a well-supported tool chain for the development,
distribution, deployment, and configuration of Haskell software.  The
aim is for this workshop to give the people involved with building the
infrastructure behind this ecosystem an opportunity to bat around
ideas, share experiences, and ask for feedback from fellow experts.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lyle Kopnicky | 1 Jun 2009 19:58

Re: The speed, size and dependability of programming languages

Thanks for the link. I find the expressiveness results odd. How can SML/NJ be among the least expressive languages, while MLTON and OCAML are among the most expressive? How is Smalltalk less expressive than Java? Why are Prolog and Mercury among the least expressive?

I think it's a combination of 1) the expressiveness measure is too simplistic, measuring number of lines alone, or counting comments, and 2) the problem set is skewed toward number-crunching, which is not (say) Prolog's strong suit.

On Mon, Jun 1, 2009 at 1:18 AM, Bulat Ziganshin <bulat.ziganshin <at> gmail.com> wrote:
Hello haskell,

Interesting blog post comparing speed and expressiveness of many
languages: http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html

--
Best regards,
 Bulat                          mailto:Bulat.Ziganshin <at> gmail.com


_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Permalink | Reply | 7 comments |
headers
Don Stewart | 1 Jun 2009 19:59
Favicon
Gravatar

Re: The speed, size and dependability of programming languages

lists:
> I think it's a combination of 1) the expressiveness measure is too simplistic,
> measuring number of lines alone, or counting comments

It isn't measuring lines of code, it is measuring the Gzip compression

Also, there's a few bogons in the data (it was graphed against 2005-6
results, and includes programs that produce the wrong output, and
programs where the are duplicate entires per language).

-- Don
Permalink | Reply | 0 comments |
headers
Gwern Branwen | 1 Jun 2009 20:16
Picon
Gravatar

Re: The speed, size and dependability of programming languages

On Mon, Jun 1, 2009 at 1:58 PM, Lyle Kopnicky <lists <at> qseep.net> wrote:
> Why are Prolog and Mercury among the least expressive?
>

Well, I don't know about SML/NJ, since I don't see anything obviously
wrong at http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=smlnj&lang2=ghc&box=1

But as for Prolog - I can't help but think of a quote I saw in a
recent paper in LtU, which went something like 'Our first prototype
was written in Prolog, but when we realized that we were using none of
the logic programming features, we decided to rewrite in Haskell.'

--

-- 
gwern
Permalink | Reply | 2 comments |
headers
Bulat Ziganshin | 1 Jun 2009 20:09
Picon

Re[2]: The speed, size and dependability of programming languages

Hello Lyle,

Monday, June 1, 2009, 9:58:14 PM, you wrote:

> Thanks for the link. I find the expressiveness results odd. How can
> SML/NJ be among the least expressive languages, while MLTON and
> OCAML are among the most expressive?

optimization tricks?

> How is Smalltalk less
> expressive than Java?

libraries?

> Why are Prolog and Mercury among the least expressive?

programming style?

--

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin <at> gmail.com
Permalink | Reply | 0 comments |
headers
Don Stewart | 1 Jun 2009 20:17
Favicon
Gravatar

Re: The speed, size and dependability of programming languages

gwern0:
> On Mon, Jun 1, 2009 at 1:58 PM, Lyle Kopnicky <lists <at> qseep.net> wrote:
> > Why are Prolog and Mercury among the least expressive?
> >
> 
> Well, I don't know about SML/NJ, since I don't see anything obviously
> wrong at http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=smlnj&lang2=ghc&box=1

There's one thing wrong:

    Last Updated: Tue Mar 20 18:02:38 PDT 2007

Don't use the gp4 results: they're obsolete. Use the u32, u64, u32q or
u64q results.

-- Don
Permalink | Reply | 1 comment |
headers
David Fox | 1 Jun 2009 20:20
Favicon

Data.Generics.gzip3 anyone?

Is there a Scrap Your Boilerplate guru out there who could whip up a three argument version of gzip for me?

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Permalink | Reply | 18 comments |
headers
Casey Hawthorne | 1 Jun 2009 20:40
Picon

Re: The speed, size and dependability of programming languages

Instead of GZip metrics for code size, maybe a good measure of
imperative language code size would be the "cyclomatic complexity"
metric.

It would also be interesting to see results for Fortran, Java, C++,
etc. across a range of old and newer compilers.

Can one measure "cyclomatic complexity" for functional languages?

However:

From: http://en.wikipedia.org/wiki/Software_metric

Modern software development practitioners are likely to point out that
naive and simplistic metrics can cause more harm than good.

ALSO: one is often more interested in "Software Quality" factors

    * 4.1.1 Understandability
    * 4.1.2 Completeness
    * 4.1.3 Conciseness
    * 4.1.4 Portability
    * 4.1.5 Consistency
    * 4.1.6 Maintainability
    * 4.1.7 Testability
    * 4.1.8 Usability
    * 4.1.9 Reliability
    * 4.1.10 Structuredness
    * 4.1.11 Efficiency
    * 4.1.12 Security

Which seem only to be qualitatively "metricable" and not
quantitatively "metricable".

Benchmarks of any type only seem to be applicable to your program if
your program is fairly similar to the benchmark.

--
Regards,
Casey
Permalink | Reply | 0 comments |
headers
Ralf Laemmel | 1 Jun 2009 21:20
Picon

Re: Data.Generics.gzip3 anyone?

On Mon, Jun 1, 2009 at 8:20 PM, David Fox <david <at> seereason.com> wrote:
> Is there a Scrap Your Boilerplate guru out there who could whip up a three
> argument version of gzip for me?

This can be done of course (untested but type-checked code follows).
Left wondering what the scenario might be :-)

Ralf

import Prelude hiding (GT)
import Data.Generics

-- As originally defined: Twin map for transformation
gzipWithT2 :: GenericQ (GenericT) -> GenericQ (GenericT)
gzipWithT2 f x y = case gmapAccumT perkid funs y of
                    ([], c) -> c
                    _       -> error "gzipWithT2"
 where
  perkid a d = (tail a, unGT (head a) d)
  funs = gmapQ (\k -> GT (f k)) x

-- For three args now
gzipWithT3 :: GenericQ (GenericQ (GenericT)) -> GenericQ (GenericQ (GenericT))
gzipWithT3 f x y z = case gmapAccumT perkid funs' z of
                    ([], c) -> c
                    _       -> error "gzipWithT3"
 where
  perkid a d = (tail a, unGT (head a) d)
  funs' = case gmapAccumQ perkid' funs y of
           ([], q) -> q
           _       -> error "gzipWithT3"
   where
    perkid' a d = (tail a, unGQ (head a) d)
  funs = gmapQ (\k -> (GQ (\k' -> GT (f k k')))) x
Permalink | Reply | 17 comments |

Gmane