What *not* to use Haskell for

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
93 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

What *not* to use Haskell for

Dave Tapley-2
Hi everyone

So I should clarify I'm not a troll and do "see the Haskell light". But
one thing I can never answer when preaching to others is "what does
Haskell not do well?"

Usually I'll avoid then question and explain that it is a 'complete'
language and we do have more than enough libraries to make it useful and
productive. But I'd be keen to know if people have any anecdotes,
ideally ones which can subsequently be twisted into an argument for
Haskell ;)

Cheers,

Dave

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Jules Bean
Dave Tapley wrote:

> Hi everyone
>
> So I should clarify I'm not a troll and do "see the Haskell light". But
> one thing I can never answer when preaching to others is "what does
> Haskell not do well?"
>
> Usually I'll avoid then question and explain that it is a 'complete'
> language and we do have more than enough libraries to make it useful and
> productive. But I'd be keen to know if people have any anecdotes,
> ideally ones which can subsequently be twisted into an argument for
> Haskell ;)

GHC's scheduler lacks any hard timeliness guarantees.

Thus it's quite hard to use haskell in realtime or even soft-realtime
environments.

This is probably not a fundamental problem with haskell. It's a problem
with the compiler/RTS which we happen to be using. It may be true that
it's harder to write an RTS with realtime guarantees but I doubt it's
impossible.

Jules
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Maurí­cio
In reply to this post by Dave Tapley-2
I think Haskell is not nice to write general purpouse libraries
that could be easily and completly wrapped by other languages.
You can wrap gtk, sqlite3, gsl, opengl etc., but you can't write
python bindings for Data.Graph.

But, then, if you claim there's nothing else Haskell can't do,
what do you need those bindings for ? :)

Best,
Maurício

> Hi everyone
>
> So I should clarify I'm not a troll and do "see the Haskell light". But
> one thing I can never answer when preaching to others is "what does
> Haskell not do well?"
>
> Usually I'll avoid then question and explain that it is a 'complete'
> language and we do have more than enough libraries to make it useful and
> productive. But I'd be keen to know if people have any anecdotes,
> ideally ones which can subsequently be twisted into an argument for
> Haskell ;)
>
> Cheers,
>
> Dave

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Arnar Birgisson
In reply to this post by Dave Tapley-2
Hi all,

On Tue, Nov 11, 2008 at 11:38, Dave Tapley <[hidden email]> wrote:
> Usually I'll avoid then question and explain that it is a 'complete'
> language and we do have more than enough libraries to make it useful and
> productive. But I'd be keen to know if people have any anecdotes,
> ideally ones which can subsequently be twisted into an argument for
> Haskell ;)

I would not use Haskell if I were faced with the prospect of producing
a huge system in short time (i.e. meaning I couldn't do it by myself)
and all I had was a pool of "regular" programmers that have been
trained in .NET, Java, C++, Python, <your favorite imperative
language>.

Yes, sad - but true. I'd very much like to see this twisted to an
argument for Haskell :)

cheers,
Arnar
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: What *not* to use Haskell for

Bulat Ziganshin-2
In reply to this post by Maurí­cio
Hello Mauricio,

Tuesday, November 11, 2008, 2:26:21 PM, you wrote:

imho, Haskell isn't worse here than any other compiled language - C++,
ML, Eiffel and beter tnan Java or C#.every language has its own object
model and GC. the only ay is to provide C-typed interfaces between
languages (or use COM, IDL and other API-describing languages)

> I think Haskell is not nice to write general purpouse libraries
> that could be easily and completly wrapped by other languages.
> You can wrap gtk, sqlite3, gsl, opengl etc., but you can't write
> python bindings for Data.Graph.

> But, then, if you claim there's nothing else Haskell can't do,
> what do you need those bindings for ? :)

> Best,
> Mauricio

>> Hi everyone
>>
>> So I should clarify I'm not a troll and do "see the Haskell light". But
>> one thing I can never answer when preaching to others is "what does
>> Haskell not do well?"
>>
>> Usually I'll avoid then question and explain that it is a 'complete'
>> language and we do have more than enough libraries to make it useful and
>> productive. But I'd be keen to know if people have any anecdotes,
>> ideally ones which can subsequently be twisted into an argument for
>> Haskell ;)
>>
>> Cheers,
>>
>> Dave

> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe


--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: What *not* to use Haskell for

Jeff Heard
Actually, one language you mention there *is* worse than the others
for writing wrappable library code: C++.  Admittedly, they've got a
Python interface now via boost, but the main problem with writing
wrappable C++ code is the template system and the inheritence systems
getting in the way.  Symbol names aren't predictable and not
standardized, so it becomes impossible to write a portable system for
finding and binding to functions in a library.  I've not yet found a
good way to do it in FFI code, and I would love to, as one library in
particular I hold near and dear -- OpenSceneGraph -- is entirely
written in C++.

-- Jeff

On Tue, Nov 11, 2008 at 6:35 AM, Bulat Ziganshin
<[hidden email]> wrote:

> Hello Mauricio,
>
> Tuesday, November 11, 2008, 2:26:21 PM, you wrote:
>
> imho, Haskell isn't worse here than any other compiled language - C++,
> ML, Eiffel and beter tnan Java or C#.every language has its own object
> model and GC. the only ay is to provide C-typed interfaces between
> languages (or use COM, IDL and other API-describing languages)
>
>> I think Haskell is not nice to write general purpouse libraries
>> that could be easily and completly wrapped by other languages.
>> You can wrap gtk, sqlite3, gsl, opengl etc., but you can't write
>> python bindings for Data.Graph.
>
>> But, then, if you claim there's nothing else Haskell can't do,
>> what do you need those bindings for ? :)
>
>> Best,
>> Mauricio
>
>>> Hi everyone
>>>
>>> So I should clarify I'm not a troll and do "see the Haskell light". But
>>> one thing I can never answer when preaching to others is "what does
>>> Haskell not do well?"
>>>
>>> Usually I'll avoid then question and explain that it is a 'complete'
>>> language and we do have more than enough libraries to make it useful and
>>> productive. But I'd be keen to know if people have any anecdotes,
>>> ideally ones which can subsequently be twisted into an argument for
>>> Haskell ;)
>>>
>>> Cheers,
>>>
>>> Dave
>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> --
> Best regards,
>  Bulat                            mailto:[hidden email]
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



--
I try to take things like a crow; war and chaos don't always ruin a
picnic, they just mean you have to be careful what you swallow.

-- Jessica Edwards
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Krasimir Angelov-2
In reply to this post by Arnar Birgisson
You can hire one Haskell programmer instead of 1,2,3... programmers in
your favorite imperative language.


On Tue, Nov 11, 2008 at 12:32 PM, Arnar Birgisson <[hidden email]> wrote:

> Hi all,
>
> On Tue, Nov 11, 2008 at 11:38, Dave Tapley <[hidden email]> wrote:
>> Usually I'll avoid then question and explain that it is a 'complete'
>> language and we do have more than enough libraries to make it useful and
>> productive. But I'd be keen to know if people have any anecdotes,
>> ideally ones which can subsequently be twisted into an argument for
>> Haskell ;)
>
> I would not use Haskell if I were faced with the prospect of producing
> a huge system in short time (i.e. meaning I couldn't do it by myself)
> and all I had was a pool of "regular" programmers that have been
> trained in .NET, Java, C++, Python, <your favorite imperative
> language>.
>
> Yes, sad - but true. I'd very much like to see this twisted to an
> argument for Haskell :)
>
> cheers,
> Arnar
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Arnar Birgisson
On Tue, Nov 11, 2008 at 14:37, Krasimir Angelov <[hidden email]> wrote:
> You can hire one Haskell programmer instead of 1,2,3... programmers in
> your favorite imperative language.

That's assuming I can find a Haskell programmer in the first place.
Also, he/she has to be good to replace 10 other programmers.

cheers,
Arnar
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: What *not* to use Haskell for

Henning Thielemann
In reply to this post by Jeff Heard

On Tue, 11 Nov 2008, Jefferson Heard wrote:

> Actually, one language you mention there *is* worse than the others
> for writing wrappable library code: C++.  Admittedly, they've got a
> Python interface now via boost, but the main problem with writing
> wrappable C++ code is the template system and the inheritence systems
> getting in the way.  Symbol names aren't predictable and not
> standardized, so it becomes impossible to write a portable system for
> finding and binding to functions in a library.  I've not yet found a
> good way to do it in FFI code, and I would love to, as one library in
> particular I hold near and dear -- OpenSceneGraph -- is entirely
> written in C++.

SWIG helps wrapping C++ libraries by providing C wrappers to C++
functions. However, as far as I know, templates cannot be wrapped as they
are, but only instances of templates. Thus there is no wrapper to STL.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: What *not* to use Haskell for

Arnar Birgisson
On Tue, Nov 11, 2008 at 14:46, Henning Thielemann
<[hidden email]> wrote:
> SWIG helps wrapping C++ libraries by providing C wrappers to C++ functions.
> However, as far as I know, templates cannot be wrapped as they are, but only
> instances of templates. Thus there is no wrapper to STL.

Maybe my understanding is a bit off, but isn't this to be expected?
There's no way to compile a generic template to machine code, as
template instantiation happens at source level in C++.

cheers,
Arnar
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: Re: What *not* to use Haskell for

Bulat Ziganshin-2
In reply to this post by Jeff Heard
Hello Jefferson,

Tuesday, November 11, 2008, 4:12:40 PM, you wrote:

may be i doesn't understand something but why c#, java, delphi, visual
basic, perl, python, ruby or even ml better than c++?

symbol names in C++ are easily predictable with wrapper using extern
"C". i think that you just not tried to write warppers to code in
other languages - the same problems are everywhere


> Actually, one language you mention there *is* worse than the others
> for writing wrappable library code: C++.  Admittedly, they've got a
> Python interface now via boost, but the main problem with writing
> wrappable C++ code is the template system and the inheritence systems
> getting in the way.  Symbol names aren't predictable and not
> standardized, so it becomes impossible to write a portable system for
> finding and binding to functions in a library.  I've not yet found a
> good way to do it in FFI code, and I would love to, as one library in
> particular I hold near and dear -- OpenSceneGraph -- is entirely
> written in C++.

> -- Jeff

> On Tue, Nov 11, 2008 at 6:35 AM, Bulat Ziganshin
> <[hidden email]> wrote:
>> Hello Mauricio,
>>
>> Tuesday, November 11, 2008, 2:26:21 PM, you wrote:
>>
>> imho, Haskell isn't worse here than any other compiled language - C++,
>> ML, Eiffel and beter tnan Java or C#.every language has its own object
>> model and GC. the only ay is to provide C-typed interfaces between
>> languages (or use COM, IDL and other API-describing languages)
>>
>>> I think Haskell is not nice to write general purpouse libraries
>>> that could be easily and completly wrapped by other languages.
>>> You can wrap gtk, sqlite3, gsl, opengl etc., but you can't write
>>> python bindings for Data.Graph.
>>
>>> But, then, if you claim there's nothing else Haskell can't do,
>>> what do you need those bindings for ? :)
>>
>>> Best,
>>> Mauricio
>>
>>>> Hi everyone
>>>>
>>>> So I should clarify I'm not a troll and do "see the Haskell light". But
>>>> one thing I can never answer when preaching to others is "what does
>>>> Haskell not do well?"
>>>>
>>>> Usually I'll avoid then question and explain that it is a 'complete'
>>>> language and we do have more than enough libraries to make it useful and
>>>> productive. But I'd be keen to know if people have any anecdotes,
>>>> ideally ones which can subsequently be twisted into an argument for
>>>> Haskell ;)
>>>>
>>>> Cheers,
>>>>
>>>> Dave
>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> [hidden email]
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>> --
>> Best regards,
>>  Bulat                            mailto:[hidden email]
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>






--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Robert Greayer
In reply to this post by Dave Tapley-2
--- On Tue, 11/11/08, Dave Tapley <[hidden email]> wrote:
> So I should clarify I'm not a troll and do "see
> the Haskell light". But
> one thing I can never answer when preaching to others is
> "what does
> Haskell not do well?"
>

'Hard' real-time applications?  I don't know that there couldn't be a 'real-time friendly' Haskell, but for some applications, the unpredictability (however slight) of when, for example, garbage collection happens, or how long it takes, is unacceptable. (Even the unpredictability of heap allocation/deallocation a la malloc/free is unacceptable for some real time apps).  Haskell is in the same boat here with lots of other languages, of course.


     
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Malcolm Wallace
In reply to this post by Jules Bean
Jules Bean <[hidden email]> wrote:

> GHC's scheduler lacks any hard timeliness guarantees.
>
> This is probably not a fundamental problem with haskell. It's a
> problem  with the compiler/RTS which we happen to be using.

Actually, I would say it is much worse than that.  It is not merely a
question of implementation.  We do not have _any_ predictable theory of
resource usage (time, memory) for a lazy language.  There is no analysis
(yet) which can look at an arbitrary piece of Haskell code and tell you
how long it will take to execute, or how much heap/stack it will eat.
What is more, it is very hard to do that in a modular way.  The
execution time of lazy code is entirely dependent on its usage/demand
context.  So you can't just apply WCET to single functions, then combine
the results.

It's a question I'd love to be able to solve, but I note that those who
are currently working on predictable execution of functional languages
(e.g. the Hume project) have already ditched laziness in favour of
eager execution.

Regards,
    Malcolm
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Jules Bean
Malcolm Wallace wrote:

> Jules Bean <[hidden email]> wrote:
>
>> GHC's scheduler lacks any hard timeliness guarantees.
>>
>> This is probably not a fundamental problem with haskell. It's a
>> problem  with the compiler/RTS which we happen to be using.
>
> Actually, I would say it is much worse than that.  It is not merely a
> question of implementation.  We do not have _any_ predictable theory of
> resource usage (time, memory) for a lazy language.  There is no analysis
> (yet) which can look at an arbitrary piece of Haskell code and tell you
> how long it will take to execute, or how much heap/stack it will eat.
> What is more, it is very hard to do that in a modular way.  The
> execution time of lazy code is entirely dependent on its usage/demand
> context.  So you can't just apply WCET to single functions, then combine
> the results.

That's true but I'm not sure you need to solve that (hard, interesting)
problem just to get *some* kind of timeliness guarantees.

For example the guarantee that a thread is woken up within 10us of the
MVar it was sleeping on being filled doesn't require you to solve the
whole problem. It requires you to be able to bound GC time, or preempt
the GC, but that's feasible isn't it?

Then there is the possibility of a strict DSL (probably but not
necessarily a Monad) within haskell which has strong timeliness guarantees.

Jules


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Kyle Consalus-2
In reply to this post by Dave Tapley-2
On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley <[hidden email]> wrote:

> Hi everyone
>
> So I should clarify I'm not a troll and do "see the Haskell light". But
> one thing I can never answer when preaching to others is "what does
> Haskell not do well?"
>
> Usually I'll avoid then question and explain that it is a 'complete'
> language and we do have more than enough libraries to make it useful and
> productive. But I'd be keen to know if people have any anecdotes,
> ideally ones which can subsequently be twisted into an argument for
> Haskell ;)
>
> Cheers,
>
> Dave
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

I think some would disagree with me, but I would advise against using
haskell for a task that
necessarily requires a lot of mutable state and IO and for which
serious performance is a big factor.
I'm not talking about stuff that can be approximated by zippers and
whatnot, but rather situations
where IORefs abound and data has identity. Haskell can quite capably
do mutable state and IO, but
if your task is all mutable state and IO, I'd lean toward a language
that makes it easier (OCaml, perhaps).

Also, I think there are some tasks which are more easily coded using
an OO approach, and while
this can be done in Haskell, I tend not to think it is worth the effort.
I've worked multiple projects in which big hierarchies of business
objects were used, and it had to be
easily to add new subclasses with minor variation and to treat any as
their parent. Considered by many in
FP community to be bad style, but I've never seen the equivalent
implemented in any other way effectively.
Haskell's record system gets in the way, as does the (as perceived by
me) esotericism of existential types.

Oh, also, any task that requires a good hash table. :-P

Mind you, Haskell is my first choice for a leisure project and I think
it is an excellent choice for
quite a few tasks and still capable of what I list above, just not in
my opinion the best choice.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Don Stewart-2
consalus:

> On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley <[hidden email]> wrote:
> > Hi everyone
> >
> > So I should clarify I'm not a troll and do "see the Haskell light". But
> > one thing I can never answer when preaching to others is "what does
> > Haskell not do well?"
> >
> > Usually I'll avoid then question and explain that it is a 'complete'
> > language and we do have more than enough libraries to make it useful and
> > productive. But I'd be keen to know if people have any anecdotes,
> > ideally ones which can subsequently be twisted into an argument for
> > Haskell ;)
> >
> > Cheers,
> >
> > Dave
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > [hidden email]
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
> I think some would disagree with me, but I would advise against using
> haskell for a task that necessarily requires a lot of mutable state
> and IO and for which serious performance is a big factor.  I'm not
> talking about stuff that can be approximated by zippers and whatnot,
> but rather situations where IORefs abound and data has identity.
> Haskell can quite capably do mutable state and IO, but if your task is
> all mutable state and IO, I'd lean toward a language that makes it
> easier (OCaml, perhaps).

Do you have an example of a mutable state/ IO bound application, like,
hmm, a window manager or a revision control system or a file system...?

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: What *not* to use Haskell for

Bulat Ziganshin-2
Hello Don,

Wednesday, November 12, 2008, 12:51:10 AM, you wrote:

> Do you have an example of a mutable state/ IO bound application, like,
> hmm, a window manager or a revision control system or a file system...?

not I/O, but IO :)

btw, i use C++ for speed-critical code (compression & encryprion) and
Haskell/GHC for everything else in my FreeArc project (it has 19k
downloads ATM). i also plan to switch to C# for GUI part since gtk2hs
provides less features, less documented, les debugged, doesn't have
IDE and my partner doesnt know Haskell :)

--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Kyle Consalus-2
In reply to this post by Don Stewart-2
On Tue, Nov 11, 2008 at 1:51 PM, Don Stewart <[hidden email]> wrote:

> consalus:
>> On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley <[hidden email]> wrote:
>> > Hi everyone
>> >
>> > So I should clarify I'm not a troll and do "see the Haskell light". But
>> > one thing I can never answer when preaching to others is "what does
>> > Haskell not do well?"
>> >
>> > Usually I'll avoid then question and explain that it is a 'complete'
>> > language and we do have more than enough libraries to make it useful and
>> > productive. But I'd be keen to know if people have any anecdotes,
>> > ideally ones which can subsequently be twisted into an argument for
>> > Haskell ;)
>> >
>> > Cheers,
>> >
>> > Dave
>> >
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > [hidden email]
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>>
>> I think some would disagree with me, but I would advise against using
>> haskell for a task that necessarily requires a lot of mutable state
>> and IO and for which serious performance is a big factor.  I'm not
>> talking about stuff that can be approximated by zippers and whatnot,
>> but rather situations where IORefs abound and data has identity.
>> Haskell can quite capably do mutable state and IO, but if your task is
>> all mutable state and IO, I'd lean toward a language that makes it
>> easier (OCaml, perhaps).
>
> Do you have an example of a mutable state/ IO bound application, like,
> hmm, a window manager or a revision control system or a file system...?
>
> -- Don
>

Of course, with a lot of skill, good design, and a pile of language
extensions state/io-heavy
Haskell code can be clean and flexible. Performance can be pretty
good, and for complex algorithmic
code arguably a better choice than most other languages. Still,
neither of the projects you reference (to my knowledge)
have a mutation-heavy inner computation loop. XMonad does all of its
mutation in a custom monad that is ReaderT StateT IO or something
similar, and it apparently works beautifully. However, my
understanding is that stack of monad transformers tend not to be
particularly efficient, and while that usually isn't an issue, the
case that I'm talking about is that where mutation
performance is a major concern.
Other languages offer similar expressive power, minus the joys of
laziness and referential transparency.
Persistent data structures are great, but if you're not using the
persistence it is less convenient and less efficient.
So again, Haskell _can_ do mutation and IO just fine, but if laziness,
purity, and immutability will be the rare exception
rather than the rule, might be easier to use a language that makes
strictness and impurity easier.
(Unless you're a Haskell guru, in which case I imagine Haskell is
always the most convenient language to use).
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Don Stewart-2
consalus:

> On Tue, Nov 11, 2008 at 1:51 PM, Don Stewart <[hidden email]> wrote:
> > consalus:
> >> On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley <[hidden email]> wrote:
> >> > Hi everyone
> >> >
> >> > So I should clarify I'm not a troll and do "see the Haskell light". But
> >> > one thing I can never answer when preaching to others is "what does
> >> > Haskell not do well?"
> >> >
> >> > Usually I'll avoid then question and explain that it is a 'complete'
> >> > language and we do have more than enough libraries to make it useful and
> >> > productive. But I'd be keen to know if people have any anecdotes,
> >> > ideally ones which can subsequently be twisted into an argument for
> >> > Haskell ;)
> >> >
> >> > Cheers,
> >> >
> >> > Dave
> >> >
> >> > _______________________________________________
> >> > Haskell-Cafe mailing list
> >> > [hidden email]
> >> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >> >
> >>
> >> I think some would disagree with me, but I would advise against using
> >> haskell for a task that necessarily requires a lot of mutable state
> >> and IO and for which serious performance is a big factor.  I'm not
> >> talking about stuff that can be approximated by zippers and whatnot,
> >> but rather situations where IORefs abound and data has identity.
> >> Haskell can quite capably do mutable state and IO, but if your task is
> >> all mutable state and IO, I'd lean toward a language that makes it
> >> easier (OCaml, perhaps).
> >
> > Do you have an example of a mutable state/ IO bound application, like,
> > hmm, a window manager or a revision control system or a file system...?
> >
> > -- Don
> >
>
> Of course, with a lot of skill, good design, and a pile of language
> extensions state/io-heavy Haskell code can be clean and flexible.
> Performance can be pretty good, and for complex algorithmic code
> arguably a better choice than most other languages. Still, neither of
> the projects you reference (to my knowledge) have a mutation-heavy
> inner computation loop.

Data.ByteString is full of mutation-heavy inner loops.
There's nothing magic about it.

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Anatoly Yakovenko
In reply to this post by Don Stewart-2
Has there been any progress in getting ghc set up for porting to non
x86/unix/windows platforms?  Can it generate ropi code?  It would also
be nice to be able to compile to C that rvct/arm tools can compile in
thumb mode.  Its whats stopping me from trying to use it for mobile
development.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12345