Re: [Haskell-cafe] Teaching Haskell @ MOOCs like Coursera or Udacity

[Gregg Lebovitz]

  
  
I would love to see an awesome online learning experience for
Haskell too.

We really need to make it easier for people to learn Haskell.

Thank you for pointing this out to the community.

On 10/18/2012 2:19 PM, niket wrote:

I am a novice in Haskell but I would love to see the
  gurus out here teaching Haskell on MOOCs like Coursera or Udacity.
  
  
  Dr Martin Odersky is doing it for Scala here: https://www.coursera.org/course/progfun
  
  
  I would love to see Haskell growing on such new platforms!
  
  
  Regards,
  Niket
  
  
  
  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



  


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Teaching Haskell @ MOOCs like Coursera or Udacity

[Gregg Lebovitz]

  
  
I am trying to get a learning center started in the Haskell
community. As pointed out below, MOOCs are hard to put together,
however training and videos straight forward. There is a lot of
teaching material available in the community. It is a matter of
finding, organizing and curating it.

I wrote a blog on an initiative we are trying to start within the
community. I have already gotten some course material contributions,
but we need a lot more.

The blog is on my personal site http://www.lebovitz.net/?p=30.

If anyone wants to help, please let me know.

Gregg

On 10/25/2012 9:26 AM, niket wrote:

The closest available is:
  
  
  http://www.youtube.com/playlist?list=PL386777DEA831CB75&feature=playlist-comment
  
  
  http://www.inf.ed.ac.uk/teaching/courses/inf1/fp/
  
  
  Thanks,
  Niket

On Thu, Oct 25, 2012 at 2:07 AM, David
  McBride 
  wrote:
  I'm taking
it primarily because it is taught by the guy who made the
language.  I mean how cool is that?  He is very smart and
certainly blows any other lecturer I've ever had out of the
water.  If SPJ were doing a haskell course I'd sign up for
that too in a heart beat.

There's also a slim possibility that coursera will become
something industry people can look at to find people with
skills they need.  A nice perk if it works out, for
something I'm doing for fun anyways.

  

On Wed, Oct 24, 2012 at 4:06
  PM, Eric Rasmussen 
  wrote:
  
I can see that the required effort would be
prohibitive, but after thinking about this some more
I do think there are a couple of nice advantages:

1) Quizzes and graded assignments offer some
structure to self study, and having some form of
feedback/validation when you first get started is
helpful. I learned a lot of Haskell by making up my
own assignments, but not everyone is willing to put
that kind of time into it.

2) I know several developers with great engineering
skills who are taking the Scala course because it
gives them a structured way to get into it and have
something to show for the time on their resume.
They're busy professionals whose skills and
expertise in large projects could really benefit the
Haskell community, but I've had no luck convincing
them that it's worth the time spent researching and
learning on their own.

Scala already has some appeal for them if they have
to work with java code or have spent years with
object oriented programming, so I think the more the
Haskell community can do to bring them here, the
better. 

Whether or not it's feasible to create the course is
another issue. I don't have an academic background
or any academic affiliations to get the ball
rolling, but if anyone wants to make a course I'll
volunteer to help proof materials, test quizzes and
assignments, and work on utilities to submit and
grade assignments.

  

On Tue, Oct 23, 2012 at
  7:02 AM, Brent Yorgey 
  wrote:
  

  On Thu, Oct 18, 2012 at 11:49:08PM
+0530, niket wrote:
> I am a novice in Haskell but I
would love to see the gurus out here
> teaching Haskell on MOOCs like
Coursera or Udacity.
>
> Dr Martin Odersky is doing it for
Scala here:
> https://www.coursera.org/course/progfun
>
> I would love to see Haskell growing
on such new platforms!

  
  

Re: [Haskell-cafe] Correspondence between libraries and modules

[Gregg Lebovitz]

  
  
Rustom,

I am drafting a document that captures some of the social norms from
the comments on this list, mostly from Brandon and Wren. I have
captured the discussion about module namespace and am sorting out
the comments on the relationship between libraries and packages.

My initial question to the list was to try an identify where Haskell
is different from other open source distributions. From what I can
tell, the issues are very similar. The module name space seems to
have characteristics very similar to the include file hierarchy of
linux distributions.

If you have some spare cycles and would like to contribute, I think
everyone would appreciate your help and effort

Gregg

On 5/23/2012 4:24 AM, Rustom Mody wrote:

  On Tue, Apr 24, 2012 at 7:29 PM, Gregg
Lebovitz <glebov...@gmail.com>
wrote:

  
 
  
  On 4/23/2012 10:17 PM, Brandon Allbery wrote:
  

  On Mon, Apr 23, 2012 at
17:16, Gregg Lebovitz <glebov...@gmail.com>
wrote:

  

  On 4/23/2012 3:39 PM, Brandon Allbery
wrote:

  

  
The other dirty little secret
  that is carefully being avoided
  here is the battle between the
  folks for whom Haskell is a
  language research platform and
  those who use it to get work done.
   It's not entirely inaccurate to
  say the former group would regard
  a fragmented module namespace as a
  good thing, specifically because
  it discourages people from
  considering it to be stable
  

  

  
  Brandon, I find that a little hard to
  believe.  If the issues are similar to other
  systems and languages, then  I think it is
  more likely that no one has volunteered to
  work on it.  You volunteering to help?
  
  
  
  

  

  

  

  
  Does haskell/hackage have something like debian's lintian?
  
  Debian has a detailed policy document that keeps evolving: http://www.debian.org/doc/debian-policy/
  Lintian tries hard to automate (as much as possible)
  policy-compliance http://lintian.debian.org/manual/index.html
  
  Eg how packages should use the file system
   http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/
  Even 'boring' legal stuff like license-checking is somewhat
  automated http://dep.debian.net/deps/dep5/
  
  And most important is the dos and donts for package dependency
  making possible nice pics http://collab-maint.alioth.debian.org/debtree/
  
  Of course as Wren pointed out, the Linux communities have enough
  manpower to police their distributions which haskell perhaps
  cannot.
  
  My question is really: Would not something like a haskell-lintian
  make such sanity checking easier and more useful for everyone?

  


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Can Haskell outperform C++?

[Gregg Lebovitz]

Isaac,

I understand. Thank you. I will be more careful about my wording in the 
future. I really do appreciate your taking the time to point this out to 
me. I am here to learn and help where I can.


Gregg

On 5/17/2012 11:25 AM, Isaac Gouy wrote:

From: Gregg Lebovitz
Sent: Thursday, May 17, 2012 5:50 AMI look forward to
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?

Isaac,

I see your point. Probably I shouldn't have made that assertion given my
limited understanding of the benchmarks. I want to thank you for your
kind and gentle way of pointing this out to me. I feel very welcomed and
encourage.

I still plan to work on the performance paper with the help of others on
this list. I look forward to your support and constructive feedback.

Gregg



Gregg,

You wrote that you were looking at the benchmarks and then made a definite 
assertion about what was shown on the website. Unsuspecting readers would 
assume that you were truthfully reporting what you saw on the website.

I cannot explain to them why you made an assertion which could be seen not to 
be true, simply by looking at the benchmarks game website.

best wishes, Isaac


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Can Haskell outperform C++?

[Gregg Lebovitz]

Isaac,

I see your point. Probably I shouldn't have made that assertion given my 
limited understanding of the benchmarks. I want to thank you for your 
kind and gentle way of pointing this out to me. I feel very welcomed and 
encourage.


I still plan to work on the performance paper with the help of others on 
this list. I look forward to your support and constructive feedback.


Gregg


On 5/16/2012 6:59 PM, Isaac Gouy wrote:

-snip-

Interesting that you would focus on this one comment in my post and not comment
on one on countering the benchmarks with a new criteria for comparing languages.

Too obvious to be interesting.

Interesting that you haven't said how you know they are "designed to favor 
imperative languages" ;-)



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Can Haskell outperform C++?

[Gregg Lebovitz]

Roman,

I think this question is for Richard. I haven't had a chance to play 
with these methods. I will try to do that today.


Gregg

On 5/17/2012 6:07 AM, Roman Werpachowski wrote:

From: "Richard O'Keefe"
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
To: Haskell Cafe
Message-ID:<5f6605a2-dfe0-4aea-9987-3b07def34...@cs.otago.ac.nz>
Content-Type: text/plain; charset=us-ascii

On 17/05/2012, at 2:04 PM, Gregg Lebovitz wrote:


Richard,

Thank you. This is an example of what I had in mind when I talked about 
changing the playing field. Do you have a slide deck for this lecture that you 
would be willing to share with me? I am very interested in learning more.


No slide deck required.  The task is "generating alternating permutations".

Method 1: generate permutations using a backtracking search;
  when a permutation is generated, check if it is alternating.

Method 2: use the same backtracking search, but only allow extensions
  that preserve the property of being an alternating permutation.

Gregg,

what makes Method 2 so much harder than Method 1 to implement in C or C++?

Regards,
RW

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Can Haskell outperform C++?

[Gregg Lebovitz]

Richard,

Thank you. This is an example of what I had in mind when I talked about 
changing the playing field. Do you have a slide deck for this lecture 
that you would be willing to share with me? I am very interested in 
learning more.


Gregg

On 5/16/2012 9:13 PM, Richard O'Keefe wrote:

In a lecture today I presented (for quite other reasons) a simple combinatorial 
enumeration problem where the difference between two algorithms was far larger than any 
plausible difference between programming languages.  If a programming language makes it 
easier to explore high level alternative algorithms, you may very easily end up with 
faster programs in a "slower" language.  (Sorry about the very long line: 
broken return key.)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Can Haskell outperform C++?

[Gregg Lebovitz]

On 5/16/2012 3:57 PM, Bardur Arantsson wrote:
Comparing languages is a highly non-trivial matter involving various 
disciplines (including various squidgy ones) and rarely makes sense 
without a very specific context for comparison. So the short answer 
is: mu. Discovering the long answer requires a lifetime or more of 
research and may not actually result in an answer.

Depends on your goal.

From the discussion on the cafe, it appears that many believe 
performance is not the only criteria for evaluating languages. I agree 
with the comment made by Ertugrul Söylemez. Some people  focus on 
getting the best performance because they don't know any better. If 
given better evaluation criteria they might think differently.


Asserting the other criteria publicly helps others understand the 
benefits of Haskell, otherwise they just see the lower performance 
numbers from places like the debian contest.




___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Can Haskell outperform C++?

[Gregg Lebovitz]

Ben,

This is precisely the kind of problem I am currently thinking about and 
why I asked for pointers to documents on best practices. The current 
model for gaining the necessary experience to use Haskell effectively 
does not scale well.


Here are some ideas on how to address the knowledge issue:

1) Outstanding best practices documents that capture this knowledge and 
provides useful answers. Organizing this information in an online 
document that can be searched by keyword or index would be really 
helpful. The hard part will be maintaining it. As someone already 
pointed out the wiki entry on performance is already dated.


2) Training presentations derived from #1 that provides lots of examples.

3) Online Training Videos based on #2 above

4) Profiling tools that uses the captured knowledge above, highlights 
problem areas, and provides guidance on correcting them.


As I mentioned in a previous email. I am willing to take on organization 
#1, but I will need help from people on this list. I can start with the 
performance wiki, but we will still need examples of where people get 
into trouble and the ways around them.


Gregg


On 5/16/2012 4:00 PM, Ben Gamari wrote:

Kevin Charter  writes:

snip

For example, imagine you're new to the language, and as an exercise decide
to write a program that counts the characters on standard input and writes
the count to standard output. A naive program in, say, Python will probably
use constant space and be fairly fast. A naive program in Haskell stands a
good chance of having a space leak, building a long chain of thunks that
isn't forced until it needs to write the final answer.  On small inputs,
you won't notice. The nasty surprise comes when your co-worker says "cool,
let's run it on this 100 MB log file!" and your program dies a horrible
death. If your friend is a sceptic, she'll arch an eyebrow and secretly
think your program -- and Haskell -- are a bit lame.


I, for one, can say that my initial impressions of Haskell were quite
scarred by exactly this issue. Being in experimental physics, I often
find myself writing data analysis code doing relatively simple
manipulations on large(ish) data sets. My first attempt at tackling a
problem in Haskell took nearly three days to get running with reasonable
performance. I can only thank the wonderful folks in #haskell profusely
for all of their help getting through that period. That being said, it
was quite frustrating at the time and I often wondered how I could
tackle a reasonably large project if I couldn't solve even a simple
problem with halfway decent performance. If it weren't for #haskell, I
probably would have given up on Haskell right then and there, much to my
deficit.

While things have gotten easier, even now, nearly a year after writing
my first line of Haskell, I still occassionally find a performance
issue^H^H^H^H surprise. I'm honestly not really sure what technical
measures could be taken to ease this learning curve. The amazing
community helps quite a bit but I feel that this may not be a
sustainable approach if Haskell gains greater acceptance. The profiler
is certainly useful (and much better with GHC 7.4), but there are still
cases where the performance hit incurred by the profiling
instrumentation precludes this route of investigation without time
consuming guessing at how to pare down my test case. It's certainly not
an easy problem.

Cheers,

- Ben


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Can Haskell outperform C++?

[Gregg Lebovitz]

  
  
Kevin,

Interesting point.

Over the past few weeks as part of my work, I have interviewed a
large numbers of Haskell developers from many different industries 
and have been hearing the same points you are making. Space leaks
that were address by learning how to use laziness and performance
issues cleared up by using strictness.

Also interesting is that in all my interviews, GHC performance was
never raised. No one said "I have to drop into C to solve that
performance problem." 

Gregg

On 5/16/2012 1:44 PM, Kevin Charter wrote:

  
  On Wed, May 16, 2012 at 8:40 AM, Gregg Lebovitz <glebov...@gmail.com>
  wrote:
  

  1) Does Haskell and its libraries need performance
  improvements?  Probably yes. Some of the performance issues
  seem to be related to the way the language is implemented and
  others by how it is defined. Developers really do run into
  performance issues with Haskell and either learn to work
  around the issue or try to fix the offending implementation.
  The wiki performance page gives insight into some of the
  performance issues and how address them.



I think there is a closely-related issue: that you'll need
  to learn how to debug subtle performance problems early
  in your Haskell programming career. In particular



  
you will have space leaks and related performance
  problems in naively-written programs
you will consequently need to learn how to use
  strictness annotations and other related language
  features, and how to use the profiler to determine where
  they're needed
  
  For example, imagine you're new to the language, and as
an exercise decide to write a program that counts the
characters on standard input and writes the count to
standard output. A naive program in, say, Python will
probably use constant space and be fairly fast. A naive
program in Haskell stands a good chance of having a space
leak, building a long chain of thunks that isn't forced
until it needs to write the final answer.  On small inputs,
you won't notice. The nasty surprise comes when your
co-worker says "cool, let's run it on this 100 MB log file!"
and your program dies a horrible death. If your friend is a
sceptic, she'll arch an eyebrow and secretly think your
program -- and Haskell -- are a bit lame.



The example is contrived, but it's a very common task to
  consume some big stream of input and produce a much smaller
  summary of it. I think it's fair to say that you have to be a
  slightly sophisticated Haskell programmer to do those kinds of
  things correctly, at least compared to more mainstream
  languages.


My experience is that this is perhaps the most important
   'problem' with Haskell performance. Not so much that it's
  typically two or three or ten times slower than language X,
  but that it's easy to have a bad experience early on,
  one that seems inconsistent with the language shoot-out and
  other performance comparisons.


Kevin
-- 
  
  Kevin Charter
  kevin.char...@acm.org

  


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Can Haskell outperform C++?

[Gregg Lebovitz]

Isaac,

I was looking at the debian coding contest benchmarks referenced by 
others in this discussion. All of the benchmarks algorithms, appear to 
be short computationally intensive programs with a fairly low level of 
abstraction.


In almost all examples, the requirement says: you must implement the X 
functions as implemented in Java, or C#, or C++. The k-nucleotide even 
specifies a requirement to use an update a hash-table.


I wonder if someone here could come up with a set of benchmarks that 
would out perform C++.


Interesting that you would focus on this one comment in my post and not 
comment on one on countering the benchmarks with a new criteria for 
comparing languages.


Gregg

On 5/16/2012 12:59 PM, Isaac Gouy wrote:

Wed May 16 16:40:26 CEST 2012, Gregg Lebovitz wrote:

2) ... I think the problem with current comparisons,
is that they are designed to favor imperative languages.


Please be specific:

- Which current comparisons?

- How do you know what they are designed to favor?


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Can Haskell outperform C++?

[Gregg Lebovitz]

Wren,

I see at least three different issues being discussed here. I think it 
is important to delineate them:


1) Does Haskell and its libraries need performance improvements?  
Probably yes. Some of the performance issues seem to be related to the 
way the language is implemented and others by how it is defined. 
Developers really do run into performance issues with Haskell and either 
learn to work around the issue or try to fix the offending 
implementation. The wiki performance page gives insight into some of the 
performance issues and how address them.


2) Are language performance comparisons useful? They can be, if the 
comparison is focusing on what each language does best. They aren't 
useful if they focus on benchmarks that aren't relevant to the target 
domain of each language. I think the problem with current comparisons, 
is that they are designed to favor imperative languages.


3) Are the negative perceptions generated by popular performance 
comparisons important? Only if you care about the broader adoption of 
the language. If you don't care, then the point is moot. If you do care, 
then yes the comparisons are unfair and simple minded, but they do have 
an affect on the percepts of the language. It is not uncommon for 
management to raise roadblocks to the introduction of new technologies 
due to flawed reports that were published in popular magazines.


If Haskell were a product and I  was responsible for its success, then I 
would be using common marketing techniques to combat the negative 
perceptions. One is a technique called "changing the playing field" 
which means producing documents that reset the criteria for the 
evaluations and comparisons. This is not "deception", but merely making 
sure that potential users understand where and how to make the proper 
comparisons, or more importantly that my "champion" was well armed with 
documentation to counter argue popular but flawed comparisons.


On 5/16/2012 6:54 AM, wren ng thornton wrote:
Haskell is just too different, and its in-the-large cost model is too 
poorly understood. I'm not even aware of any helpful generalizations 
over comparing two specific programs. Even when restricting to things 
like parsing or compute-intensive numeric code, the comparison comes 
back with mixed answers.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Can Haskell outperform C++?

[Gregg Lebovitz]

Chris,

Thanks you for indulging me. I will eventually get use to the idea that 
there is a wiki page for almost every topic :-)


Gregg

On 5/12/2012 1:02 AM, Chris Wong wrote:

On Sat, May 12, 2012 at 12:41 AM, Gregg Lebovitz  wrote:

I would find it useful to pull all this information together into a single
document that discusses all the performance issues in one place and shares
the real life experience is dealing with each issue. I see this as a best
practice paper rather than a research document.

Does such a document exist? If not, I am willing try and start one.

http://www.haskell.org/haskellwiki/Performance

;)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Can Haskell outperform C++?

[Gregg Lebovitz]

  
  
This is an outstanding discussion. I am learning a lot from it.

I would find it useful to pull all this information together into a
single document that discusses all the performance issues in one
place and shares the real life experience is dealing with each
issue. I see this as a best practice paper rather than a research
document.

Does such a document exist? If not, I am willing try and start one.


Ryan writes:


  With a few years of Haskell experience in my backpack I know how to
utilize laziness to get amazing performance for code that most people
would feel must be written with destructively updating loop.



I have heard similar comments  from other experienced Haskell users
about how get better performance from their code by understanding
the details of applying laziness. I would like to try and capture
this.

Are there blogs, wiki postings, and list postings that provide
information about particular issues?

Gregg

On 5/10/2012 11:53 PM, Ertugrul Söylemez wrote:

  Ryan Newton  wrote:


  
I think this is a bit of an unfair accusation ("simple-minded").
 Performance is only relevant to certain domains, sure.  But program
performance is an entire *industry*.  And I'd argue it's of massive
importance to the world at large.  Intel has an army of "AE"s
(application engineers) that go out to other companies to make
applications perform better.  There are plenty of compute bound
industries -- i.e. movie companies are limited by what kind of frame
they can render in ~24 hrs; sequencing centers are limited by certain
very slow bioinformatics algorithms; you can look almost anywhere you
like for examples.

  
  
I'm sorry for the rough words.  I didn't mean to overgeneralize.  Of
course in certain domains a reasonable performance is desirable, but the
first question you should ask is whether you want high level or low
level performance.  Haskell performs amazingly at the high level and
suboptimal at the low level.

My point is:  If you need C-like performance at a certain spot there is
really no excuse for writing the entire application in C.  Haskell has a
working, powerful enough FFI.  Also idiomatic Haskell code nowadays
performs close to C.  If your code doesn't, chances are that it's not
even idiomatic.  Sorting a list is easy and beautiful in code.  But it's
far from idiomatic.  Using ST with destructive update is also not
idiomatic.  One of my performance masterpieces is the "instinct" AI
library (see Hackage).  It uses only immutable vectors and performs very
heavy Double calculations, yet performs better than the same code with
mutable arrays did.

With a few years of Haskell experience in my backpack I know how to
utilize laziness to get amazing performance for code that most people
would feel must be written with destructively updating loop.  And the
resulting code is just beautiful to read and watch at work, a great
demonstration of the wonders the GHC developers have created.



  
As a community I think we have to face the fact that writing the hot
inner loop of your application as idiomatic Haskell is not [yet] going
to give you C/Fortran performance off the bat.  Though in some cases
there's not really anything stopping us but more backend/codegen work
(I'm thinking of arithmetically intensive loops with scalars only).
For example, the following Mandel kernel is in many ways the *same* as
the C version:

https://github.com/simonmar/monad-par/blob/662fa05b2839c8a0a6473dc490ead8dd519ddd1b/examples/src/mandel.hs#L24H

We have the types; we've got strictness (for this loop); but the C
version was 6X faster when I tested it.

  
  
Well, if it's "in many ways the same as C", then again it's probably not
idiomatic Haskell.  I don't know what a Mandel kernel is, so I can't
really tell you how I would write the code without further study.
However, I'm doing a lot of number crunching and my code usually gets
really close to C, and especially for Integer-heavy calculations
actually outperforms C.  I have done the comparison.  Using GMP with all
the features it provides in the mpz_* family of functions is in fact
slower than the same in Haskell (GHC 7.4.1 on Intel i5 64 bits here),
and from my C times I have experience using GMP properly including smart
allocation, etc.

If you want high performance Haskell, writing C in Haskell is /not/ the
solution.  It /will/ result in suboptimal code, likely considerably
slower than the same code in C.


Greets,
Ertugrul


  
  
  
  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


  


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Correspondence between libraries and modules

[Gregg Lebovitz]

On 4/24/2012 11:44 PM, wren ng thornton wrote:
To pick another similar namespacing issue, consider the problem of 
Google Code. In Google Code there's a single namespace for projects, 
and the Google team spends a lot of effort on maintaining that 
namespace and resolving conflicts. (I know folks who've worked in the 
lab next door to that team. So, yes, they do spend a lot of work on 
it.) Whereas if you consider BitBucket or GitHub, each user is given a 
separate project namespace, and therefore the only thing that has to 
be maintained is the user namespace--- which has to be done anyways in 
order to deal with logins. The model of Google Code, SourceForge, and 
Java all assume that projects and repositories are scarce resources. 
Back in the day that may have been true (or may not), but today it is 
clearly false. Repos are cheap and everyone has a dozen side projects.


Actually, I like the idea of combining an assigned User name with the 
repo name as the namespace. We already have login names for haskell.org, 
why not use those. I agree that it is not an end all, but it would be a 
start. My top level namespace would be Org.Haskell.Glebovitz. It is 
democratic and it identifies the code by the repoand the user the 
created it. If someone else decided to use their github id then it their 
modules would be org.github.username or org.github.project. Of course 
people can choose to ignore the namespace common practice, but they can 
do that anyway.




If you look at the case of Perl and CPAN, there's the same old story: 
universal authority. Contrary to Java, CPAN does very much actively 
police (or rather, vett) the namespace. However, this extreme level of 
policing requires a great deal of work and serves to drive away a 
great many developers from publishing their code on CPAN.


I'm not as familiar with the innards of how various Linux distros 
manage things, but they're also tasked with the additional burden of 
needing to pull in stuff from places like CPAN, Hackage, etc. Because 
of that, their namespace situation seems quite different from that of 
Hackage or CPAN on their own. I do know that Debian at least (and 
presumably the others as well) devote a great deal of manpower to all 
this.


Yes, but that goes back to my comments about upstream and downstream. 
Hackage can try to solve the problem for itself, but eventually someone 
is going to put together a distribution, whether it be ubuntu, or 
Microsoft and they will have to sort out the name collisions for their 
packages and modules. If we have a good naming scheme to start with, it 
will make the downstream problem a bit easier. Even so, they will 
probably change it anyways. I know that ubuntu and fedora take different 
approaches to packaging. When I try to use a package like Qt on these 
different platforms, I have to figure out which package contains which 
library.




So we have (1) the Java model where there are rules that noone 
follows; (2) the Google Code, CPAN, and Linux distro model of devoting 
a great deal of community resources to maintaining the rules; and (3) 
the BitBucket, GitHub, Hackage model of having few institutionalized 
rules and leaving it to social factors. The first option buys us 
nothing over the last, excepting a false sense of security and the 
ability to alienate private open-source developers.



I think my combo of formalized namespace and social rules would work 
best here.  The problem is that we do have module collisions because the 
namespace is too simple. Right now it is not an issue because the 
community is not huge. Eventually it will be a problem if Haskell 
popularity grows.


There is no technical solution to this problem, at least not any used 
by the communities you cite. The only solutions on offer require a 
great deal of human effort, which is always a 
social/political/economic matter. The only technical avenues I see are 
ways of making the problem less problematic, such as GitHub and 
BitBucket distinguishing the user namespace from each user's project 
namespace, such as the -XPackageImports extension (which is 
essentially the same as GitHub/BitBucket), or such as various ideas 
about using tree-grafting to rearrange the module namespace on a 
per-project basis thereby allowing clients to resolve the conflicts 
rather than requiring a global solution. I'm quite interested in that 
last one, though I don't have any time for it in the foreseeable future.


There probably is a technical solution, but no one is going to discover 
it and build it anytime soon. dI think we all agree that a centralized 
global solution is out. No one would want to manage it. I do think the 
repo.username namespace has potential. The problem is that informal 
social convention works if the community is small. Once it starts to 
grow it has to be codified to some degree.




___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/

Re: [Haskell-cafe] Correspondence between libraries and modules

[Gregg Lebovitz]

On 4/24/2012 11:49 PM, wren ng thornton wrote:

On 4/24/12 9:59 AM, Gregg Lebovitz wrote:

The question of how to support rapid innovation and stable
deployment is not an us versus them problem. It is one of staging 
releases. The
Linux kernel is a really good example. The Linux development team 
innovates
faster than the community can absorb it. The same was true of the GNU 
team.

Distributions addressed the gap by staging releases.


In that case, what you are interested in is not Hackage (the too-fast 
torrent of development) but rather the Haskell Platform (a policed set 
of stable/core libraries with staged releases).


No, that was not what I was thinking because a stable policed set of 
core libraries is at the opposite end of the spectrum from how you 
describe Hackage. What I am suggesting is a way of creating an upstream 
that feeds increasingly stable code into an ever increasing set of 
stable and useful components. Using the current open system model, the 
core compiler team for gcc releases the compiler and a set of libstdc 
and libstdc++ libraries. The GNU folks release more useful libraries, 
and then projects like GNOME build on the other components. Right now we 
have Hackage that moves to fast and the Haskell core that rightfully 
moves more slowly.


Maybe the answer is to add a rating system to Hackage and mark packages 
as experimental, unsupported, and supported, or use a 5 star rating 
system like the app store. Later on when we have appropriate testing 
tools, we can include a rating from the automated tests.




I forget who the best person to contact is these days if you want to 
get involved with helping the HP, but I'm sure someone on the list 
will say shortly :)




___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Correspondence between libraries and modules

[Gregg Lebovitz]

  
  


On 4/23/2012 10:17 PM, Brandon Allbery wrote:

  
On Mon, Apr 23, 2012 at 17:16, Gregg
  Lebovitz <glebov...@gmail.com>
  wrote:
  

  
On 4/23/2012 3:39 PM, Brandon Allbery
  wrote:
  

  

  The other dirty little secret that is
carefully being avoided here is the battle
between the folks for whom Haskell is a
language research platform and those who use
it to get work done.  It's not entirely
inaccurate to say the former group would
regard a fragmented module namespace as a
good thing, specifically because it
discourages people from considering it to be
stable

  

  

Brandon, I find that a little hard to believe.  If the
issues are similar to other systems and languages, then 
I think it is more likely that no one has volunteered to
work on it.  You volunteering to help?



Yes, you do find it hard to believe; so hard that you
  went straight past it and tried to point to the "easy"
  technical solution to the problem you decided to see in
  place of the real one, which doesn't have a technical
  solution.
  

  


Brandon, I am very glad to make your acquaintance. I think you have
given these issue much thought. That is good.

No, I don't think I "went straight past it". I we are trying to
address the same issue, but from different directions. If you take
the time to look at my history, you'll find that I spent my career
bridging the very gap you make so very salient.

Here's where we differ, you see an untenable political issue, and I
see a technical one. The question of how to support rapid innovation
and stable deployment is not an us versus them problem. It is one of
staging releases. The Linux kernel is a really good example. The
Linux development team innovates faster than the community can
absorb it. The same was true of the GNU team. Distributions
addressed the gap by staging releases.

I fought this very battle in the 1980s with the Andrew system. The
technology coming out of the ITC (research community) was evolving
faster than users could absorb. Researchers want to innovate and
push the limits and users want stability. I've spoken with many in
the Haskell research community, and I never heard anyone say "no, we
want to obfuscate Haskell so that we never have to make is stable."
I think both communities want success. The question is how to build
a system that will address both.

From your history, I see you are knowledgeable and well known on the
deployment side of technology. You also understand what Haskell
needs to move forward. So I ask you again, are you volunteering to
help?


  

  


  
  -- 
  brandon s allbery                                      allber...@gmail.com
  wandering unix systems administrator (available)     (412)
  475-9364 vm/sms
  

  

  


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Correspondence between libraries and modules

[Gregg Lebovitz]

  
  


On 4/23/2012 3:39 PM, Brandon Allbery wrote:

  
On Mon, Apr 23, 2012 at 11:39, Gregg
  Lebovitz <glebov...@gmail.com>
  wrote:
  

  Am I missing something that makes this
problem harder than other systems and languages? Is
anyone currently working on the packaging  and
distribution issues? If not, does anyone else want to
work on it?



The other dirty little secret that is carefully being
  avoided here is the battle between the folks for whom
  Haskell is a language research platform and those who use
  it to get work done.  It's not entirely inaccurate to say
  the former group would regard a fragmented module
  namespace as a good thing, specifically because it
  discourages people from considering it to be stable
  

  


Brandon, I find that a little hard to believe.  If the issues are
similar to other systems and languages, then  I think it is more
likely that no one has volunteered to work on it.  You volunteering
to help?


  

  
  
  
  
  -- 
  brandon s allbery                                      allber...@gmail.com
  wandering unix systems administrator (available)     (412)
  475-9364 vm/sms
  

  

  


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Correspondence between libraries and modules

[Gregg Lebovitz]

On 04/23/2012 12:03 AM, wren ng thornton wrote:

However, until better technical support is implemented (not just for
GHC, but also jhc, UHC,...) it's best to follow social practice.


Wren, I am new to Haskell and not aware of all of the conventions. Is 
there a place where I can find information on these social practices? 
Are they documented some place?



However, centralization is prone to bottlenecks and systemic failure.
As such, while it would be nice to ensure that a given module is
provided by only one package, there is no mechanism in place to
enforce this (except at compile time for the code that links the
conflicting modules together).


From someone new to the community, it seems that yes centralization has 
its issues, but it also seems that practices could be put in place that 
minimize the bottlenecks and systemic failures.


Unless I greatly misunderstand the challenges,  there seem to be lot of 
ways to approach this problem and none of them are new. We all use 
systems that are composed of many modules neatly combined into complete 
systems. Linux distributions do this well. So does Java. Maybe should 
borough from their experiences and think about how we put packages 
together and what mechanisms we need to resolve inter-package dependencies.


Am I missing something that makes this problem harder than other systems 
and languages? Is anyone currently working on the packaging  and 
distribution issues? If not, does anyone else want to work on it?


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe