When explaining monads to beginners (having an imperative background), I
found myself to say that there is *roughly* three groups of monads
(because they're always worried about their cost, i.e. their incidental
complexity):
- Function-oriented monads (e.g. State, Reader, Cont)
- Reductible
The unconditional desire for maximum possible object code
performance is usually very stupid, not to mention impossible to reach
with any high level language and any multi-tasking operating system.
Definitely. I don't know if we have a catchy term for kneejerk
optimization or if it falls
Yves Parès yves.pa...@gmail.com wrote:
When explaining monads to beginners (having an imperative background),
I found myself to say that there is *roughly* three groups of monads
(because they're always worried about their cost, i.e. their
incidental complexity):
My recommendation (as I've
Ryan Newton rrnew...@gmail.com wrote:
I do think we have the opposite problem, however, in much Haskell code
-- people are using the clean, obviously correct, but inefficient code
even in standard library functions that really should be optimized
like crazy!
Not necessarily. For example the
I do think we have the opposite problem, however, in much Haskell code --
people are using the clean, obviously correct, but inefficient code even in
standard library functions that really should be optimized like crazy!
And even before optimizing like crazy, I think the functions that are
more
Not necessarily. For example the 'nub' function from Data.List could be
much faster. Unfortunately this would also change its type. O(n²)
complexity is really the best you can get with the Eq constraint.
Why not in that kind of cases provide a second function (named
differently), together
On Mon, May 21, 2012 at 7:53 AM, Yves Parès yves.pa...@gmail.com wrote:
Not necessarily. For example the 'nub' function from Data.List could be
much faster. Unfortunately this would also change its type. O(n²)
complexity is really the best you can get with the Eq constraint.
Why not in
Yes, this seems to be a separate disease. Not just using low-level langs,
per se,
but using them for *everything*. I have worked at places in industry where
teams
automatically use C++ for everything. For example, they use it for building
all
complete GUI applications, which
From: Richard O'Keefe o...@cs.otago.ac.nz
Sent: Sunday, May 20, 2012 3:41 PM
On 19/05/2012, at 5:51 AM, Isaac Gouy wrote:
In the 'tsort' case, it turns out that the Java and Smalltalk
versions are I/O bound with over 90% of the time spent just
reading the data.
My guess is that they could
If you are writing a program or system that has significant performance
requirements, you might just be better off doing the whole thing in C/C++
and living with the annoyance of doing GUIs
I fail to see how the GUI part would suffer from lack of performance if the
rest of the system is fine. I
On 21 May 2012 17:27, Yves Parès yves.pa...@gmail.com wrote:
I fail to see how the GUI part would suffer from lack of performance if the
rest of the system is fine. I would hate to be bold, but to me this case
sounds a little bit like MVC done wrong if the breaking GUI apart from the
rest of
From: Stephen Tetley stephen.tet...@gmail.com
Sent: Monday, May 21, 2012 10:08 AM
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
On 21 May 2012 17:27, Yves Parès yves.pa...@gmail.com wrote:
I fail to see how the GUI part would suffer from lack of performance if the
rest of
I am pleased to annouce the release of 'reform'. A full tutorial is
available here:
http://www.happstack.com/docs/crashcourse/Reform.html
Reform is an HTML form generation and validation library. It follows
in the footsteps of formlets and digestive-functors = 0.2. In fact,
much of the code in
Benjamin,
- Immutable structure, mutable labels. After initially reading in the
graphs, their shape doesn't change, but information flows around the graph,
changing the labels on nodes and edges.
I have been working on a similar problem for a while now, hence my
interest and
On Mon, May 21, 2012 at 7:18 PM, Jeremy Shaw jer...@n-heptane.com wrote:
I hope to do a full comparison of reform vs digestive-functors 0.3 vs
yesod forms in a few weeks.
That would be awesome! Just sayin' =).
Cheers,
--
Felipe.
___
Haskell-Cafe
On 22/05/2012, at 4:15 AM, Isaac Gouy wrote:
Actually, I/O bound is *good*.
Why would that be good or bad?
The context here is a UNIX-style topological sorting program.
Being I/O bound means that the program is limited by how fast
it can read the data. If 90% of the time goes into reading
On Thu, May 17, 2012 at 03:05:22PM +0100, Chris Dornan wrote:
I have been playing around with the latest cabal-install (0.14.0) and it is
working really nicely. Having unpacked a cabal bundle you can now type
'cabal install' inside the root and it will work everything out as if you
had asked
I can try to use the nodes/specs you provide to give you an estimate
of what my framework can handle. If that works for you, I'll clean up
my code and you can give it a shot. Send me whatever other details you
think are relevant.
Benjamin,
I had a few moments, so I made a sparse graph of
18 matches
Mail list logo
