- an existing solution exists which does the job and you know you're not going to patch the source ( eg OpenOffice or Linux kernel, or simple build scripts. There is already make etc )

Don't you find yourself looking at the documentation each time you want to write a loop in a Makefile ? Cause I do, and each time I think : "what can't I script this in haskell or caml ?". If anyone here is looking for a graph search / GHC API / Unix filesystem / parsec exercise, and has got the time to glue all this together : DO IT ! Cheers, PE

On Wed, 16 Jun 2010, Marc Weber wrote:

Hi Aditya Siram,

- maybe shell scripting: running ghci takes longer than starting bash. Compiling is not always an option because executables are bigger than shell scripts or C executables

Is Hugs better in this respect?

On Jun 17, 2010, at 10:17 , David Virebayre wrote:

On Thu, Jun 17, 2010 at 3:38 PM, Henning Thielemann wrote:

...

On Wed, 16 Jun 2010, Marc Weber wrote:

...

Hi Aditya Siram, - maybe shell scripting: running ghci takes longer than starting bash. Compiling is not always an option because executables are bigger than shell scripts or C executables

...

Is Hugs better in this respect?

Or JHC ? JHC's executables are small.

Get shared libraries working, and this becomes a non-issue; you're not buying anything disk-wise if the file is smaller than the block size (does any production fs use fragments any more? I know Linux filesystems don't). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

deliverable:

At this very moment I'm struggling with fitting a huge graph of Twitter communications into a Haskell program. Apparently it gets into a loop freeing memory. As I suspected, JVM garbage collector got more testing than Haskell at this scale; since not many people load it up as much, it may be less tested.

Did you talk to Simon Marlow yet? Unlike the JVM, we provide direct access to the GC developers when you run into trouble. :) -- Don

(Looks like my previous reply didn't go through yet) -- yes, we're working on it! :) Cheers, Alexy

On Sat, 2010-06-19 at 03:12 +0200, Henning Thielemann wrote:

Maciej Piechotka schrieb:

...

1. Glueing a few highier level, object-oriented libraries if it is just glueing.

2. (Currently) AFAIK real-time applications although it is rather property of GHC GC then the language itself

In my experience the garbage collector was not the problem in real-time applications, but memory leaks that make the garbage collector slow.

The problem is that: - GHC GC can run at any moment - It is stop-the-world GC - There is no upper limit on how long GHC GC will run I have no experience with real-time applications however. Regards

On 2010-06-19 16:43 +0100 (Sat), Max Bolingbroke wrote:

Curt Sampson had an experience report at ICFP last year about his experience with Haskell for a real time application (http://www.starling-software.com/blogimg/tsac/s5/2009-09-01-icfp.html). He reported no issues with GC speed in practice.

As it turned out, there were issues in the end. I'm no longer with that project, so I don't know how things are at this point, but the issues weren't anything terrible that you wouldn't see on other platforms, and GHC was at the time just bringing in some new and great facilities (such as the tracing used by Threadscope) for starting to profile this sort of thing. I didn't feel as if I faced any horrible hurdles. braver's note, "As I suspected, JVM garbage collector got more testing than Haskell at this scale; since not many people load it up as much, it may be less tested," strikes me as much more likely an issue with improper control of lazy evaluation than a GC issue: the GC of a Haskell implementation is generally much harder worked than a JVM GC due to the heavy use of immutable variables that's part of the nature of Haskell itself. While I'd say the Sun JVM's GC is more mature than GHC's, it's not anywhere near a night-and-day difference, and it's mostly visible in things like the greater number of strategies Sun's GC offers, such as concurrent GC. GHC is making excellent progress. If there's one key thing I took away from my whole experience, it's that to make effective use of Haskell in a time- and performance-critical application, you need to understand and control (lazy) evaluation. This isn't really any more sophisticated a type of knowledge than you need to move from, say, a non-GC to a GC language, but it is new, and you have to be prepared to learn a bunch of new stuff. Note that I'm not reading this list regularly due to the enormous volume, so be sure to cc me on replies to this if you want to make sure that I see them. I'd be happy to chat further with anybody contemplating a serious project in Haskell that has worries about this, and I'd even be available for some consulting if it comes to that. (Oh, and the trading system is running in production and making money these days. There's no question in my mind that the project was a success, and I'd do it in GHC again. Thanks to the Simons and many others for the fantastic job they've done with that.) cjs -- Curt Sampson +81 90 7737 2974 http://www.starling-software.com/ "There's a war between the ones who say there is a war and the ones who say there isn't." --Leonard Cohen

Haskell's FFI [1] is really nice, so you could still write your performance-critical parts in C. -deech [1] http://book.realworldhaskell.org/read/interfacing-with-c-the-ffi.html On Wed, Jul 7, 2010 at 1:54 PM, Zura_ wrote:

It is ironic, but after reading your paper - "Experience Report: Haskell in the Real World", I doubt I'll use Haskell for a performance critical systems. Laziness (and understanding it) is one factor, but there is also GC, which is a real hassle, especially in embedded/mobile systems for a near real-time applications. In short, when milliseconds matter I'd prefer to stick with GC-less language and with native binaries.

Regards, Zura

Curt Sampson-2 wrote:

...

(Oh, and the trading system is running in production and making money these days. There's no question in my mind that the project was a success, and I'd do it in GHC again. Thanks to the Simons and many others for the fantastic job they've done with that.)

-- View this message in context: http://old.nabble.com/What-is-Haskell-unsuitable-for--tp28897715p29099864.ht... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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

On 16 June 2010 15:45, Roman Cheplyaka wrote:

* aditya siram [2010-06-15 19:47:37-0400]

...

Hi all, Haskell is a great language and in a lot of ways it still hasn't found a niche, but that's part of what is great about it.

But I wanted to ask people are more experienced with Haskell - what kinds of problems is it unsuited for? Have you ever regretted using it for something? Meaning if you could write the program over you would do it in another language.

This topic was already discussed on this list, you might want to search the archives.

Spoilsport! :p Next you'll say there's no need for anyone to ask whether they prefer vi or emacs... ;-) -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On 16 June 2010 16:00, Michael Snoyman wrote:

On Wed, Jun 16, 2010 at 8:51 AM, Ivan Miljenovic wrote:

...

Next you'll say there's no need for anyone to ask whether they prefer vi or emacs... ;-)

Of course *real* programmers use ed. It is the standard editor[1]. Michael [1] http://www.gnu.org/fun/jokes/ed.msg.html

Except that due to Haskell's pervading influence we've all become lazy... -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

David Virebayre writes:

On Wed, Jun 16, 2010 at 8:00 AM, Michael Snoyman wrote:

...

...

Next you'll say there's no need for anyone to ask whether they prefer vi or emacs... ;-)

...

Of course *real* programmers use ed. It is the standard editor[1].

*Real* programmers use butterfiles [1].

If your files are composed of butter, I"d hate to see how you store them in an efficient manner... -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On Wed, 2010-06-16 at 10:34 +0200, David Virebayre wrote:

On Wed, Jun 16, 2010 at 8:00 AM, Michael Snoyman wrote:

...

...

Next you'll say there's no need for anyone to ask whether they prefer vi or emacs... ;-)

...

Of course *real* programmers use ed. It is the standard editor[1].

*Real* programmers use butterfiles [1].

[1] http://xkcd.com/378/

David.

Emacs is also accepted IIRC - M-x butterfly Regards

No argument there - I'm even afraid to stick it on my resume. At least Clojure can be snuck into the JVM without people noticing - Haskell, unfortunately, is not that shy. -deech On Thu, Jun 17, 2010 at 1:11 PM, Andrew Coppin wrote:

aditya siram wrote:

...

But I wanted to ask people are more experienced with Haskell - what kinds of problems is it unsuited for?

Judging by the other thread, "getting hired" might be a valid answer here...

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

Andrew Coppin wrote:

aditya siram wrote:

...

No argument there - I'm even afraid to stick it on my resume. At least Clojure can be snuck into the JVM without people noticing - Haskell, unfortunately, is not that shy.

Oh, I don't know... Few companies will want you to *use* Haskell, but lots of people seemed to be impressed if you say you know how to use it. (Those that know WTF is actually is, anyway...)

"Pascal? Yeah, I used to program in that about 30 years ago". I actually got that response from someone. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

On Jun 17, 2010, at 9:44 PM, Michael Snoyman wrote:

While we're on the topic, does anyone else get funny looks when they say "monads"?

Yes, almost every time. They seem to catch on if I say "monadic" when I mean "able to syntactically transformed so as to be put in a sequence".

On Fri, Jun 18, 2010 at 12:44 AM, Michael Snoyman wrote:

On Fri, Jun 18, 2010 at 5:03 AM, Erik de Castro Lopo

...

wrote:

...

"Pascal? Yeah, I used to program in that about 30 years ago". I actually got that response from someone.

You only got it once? *Every single person* I say Haskell to hears Pascal. Maybe I have a speech impediment or somethings.

I must have the same impediment. We should start a support group, that, or give in and write a compiler. To add insult to injury, I think it should be called "Turbo Haskell". While we're on the topic, does anyone else get funny looks when they say

"monads"?

Sadly, yes. ;) -Edward Kmett

On Tue, Jul 6, 2010 at 9:23 PM, Yves Parès wrote:

...

I must have the same impediment. We should start a support group, that, or give in and write a compiler. To add insult to injury, I think it should be called "Turbo Haskell".

That's true... I never noticed, because in French the two words get pronounced very differently.

Indeed. Sadly, I almost never get to speak about Haskell in French... Except when I'm advocating it to my friends. There's a majority of words I learned with haskell I have no idea what their translation is in French. For others, the direct translation sounds horrible "Haskell est un language fainéant". I'm lucky I like English. David.

On Thu, Jun 17, 2010 at 01:38:23PM -0500, aditya siram wrote:

...

Judging by the other thread, "getting hired" might be a valid answer here...

No argument there - I'm even afraid to stick it on my resume. At least Clojure can be snuck into the JVM without people noticing - Haskell, unfortunately, is not that shy.

"I am sad that I can't use cool languages in the boring, mainstream corporate jobs that are easy to find." If you want to use cool languages, you may have to get a cool job. I know: it's easy to say and harder to accomplish. -- Darrin Chandler | Phoenix BSD User Group | MetaBUG dwchandler@stilyagin.com | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation

On Thu, Jun 17, 2010 at 12:01:53PM -0700, David Leimbach wrote:

On Thu, Jun 17, 2010 at 11:57 AM, Darrin Chandler wrote:

...

On Thu, Jun 17, 2010 at 01:38:23PM -0500, aditya siram wrote:

...

...

Judging by the other thread, "getting hired" might be a valid answer here...

No argument there - I'm even afraid to stick it on my resume. At least Clojure can be snuck into the JVM without people noticing - Haskell, unfortunately, is not that shy.

"I am sad that I can't use cool languages in the boring, mainstream corporate jobs that are easy to find."

If you want to use cool languages, you may have to get a cool job. I know: it's easy to say and harder to accomplish.

I would never look at a resume when reviewing people to hire, see an exotic programming language, and draw negative conclusions about that candidate. In fact, I've found that learning to solve problems from different solution spaces in general is a worthwhile mental exercise, and helps one to come up with possibly better solutions in the mainstream languages.

Sometimes breadth of experience is a good thing.

I agree. On the (employee) flip side, I'd rather go work for someone who has views like you mention, regardless of language in use. -- Darrin Chandler | Phoenix BSD User Group | MetaBUG dwchandler@stilyagin.com | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation