 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If all you're trying to do is sum all the elements in a list, neither
> approach has a really compelling advantage or disadvantage. I used it as
> an example of a simple task that anybody can easily understand, and used
> it to illustrate the difference in mentallity between the two approaches.
I guess the difference would be in more complex examples then, when both the
human C++ coder and the Haskell compiler have to work harder to get
efficient code.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> > I still like the definition of "connected" in the New Zealand go rules:
> >
> > "Two stones of the same colour are connected if they are on adjacent
> > intersections or if they are both connected to a third stone."
> >
> > Even most functional programmers have hard time understanding that
> > correctly the first time they see it.
> Makes perfect sense to me - but then, I'm a maths nerd... ;-)
Does it? Can you give me several varied examples of connected stones,
as well as examples where two stones are *not* connected according
to this definition?-)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> If all you're trying to do is sum all the elements in a list, neither
>> approach has a really compelling advantage or disadvantage. I used it
>> as an example of a simple task that anybody can easily understand, and
>> used it to illustrate the difference in mentallity between the two
>> approaches.
>
> I guess the difference would be in more complex examples then, when both
> the human C++ coder and the Haskell compiler have to work harder to get
> efficient code.
If all you're after is the ultimate machine efficiency, C can probably
still do that better than almost any other language, given enough skill.
But what about factors such as code size, readability, maintainability,
code reuse, polymorphism, etc etc etc?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> sum [] = 0
> sum (x:xs) = x + sum xs
Don't you love it how complicated something like this looks in C++:
template<typename Iterator>
typename std::iterator_traits<Iterator>::value_type
sum(Iterator begin, Iterator end)
{
typedef typename std::iterator_traits<Iterator>::value_type t;
t result = t();
while(begin != end) result += *begin++;
return result;
}
Its advantage, though, is that it works with *any* container type
as long as it has sequential iterators, and *any* value type, as long
as it supports the + operator. So you can do for example like this:
int table[] = { 1, 2, 3, 4, 5, 6, 7, 8 };
int result = sum(table, table+8);
or like this:
std::string table[] = { "a", "b", "cde", "f" };
std::string result = sum(table, table+8);
or like this:
std::vector<double> table(100);
// init the vector
double result = sum(table.begin(), table.end());
or like this:
std::list<std::complex<double> > l;
// init the list
std::complex<double> result = sum(l.begin(), l.end());
or like this:
std::set<std::string> s;
// init the set
std::string result = sum(s.begin(), s.end());
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> If all you're after is the ultimate machine efficiency, C can probably
> still do that better than almost any other language, given enough skill.
... on a machine whose architecture is well-matched to C. And given
enough skill.
A COBOL interpreter in C isn't going to be nearly as fast as a COBOL
interpreter in microcode. (Yes, btdt. :-) It's going to be hard to beat
one clock cycle per byte for an "edit byte string" (similar to "print
using" in BASIC) using a C function.
A FORTH chip is going to run FORTH way faster than it'll run the same
algorithm written in a way that looks like reasonable C, I expect.
Put 128 cores on a chip connected in a hypernet, and you're going to
have a heck of a time writing an efficient sort algorithm in C for that.
Put a big pile of SIMD processors together, and you're not going to be
able to program it in C at all. APL maybe, but not C.
C makes a whole pile of assumptions about processor architecture that
most people don't notice because most processors they use have evolved
to account for what C does. But the assumptions are there.
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If all you're after is the ultimate machine efficiency, C can probably
> still do that better than almost any other language, given enough skill.
>
> But what about factors such as code size, readability, maintainability,
> code reuse, polymorphism, etc etc etc?
Yeh you're right, maybe MS wrote Vista in Haskell ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> sum [] = 0
>> sum (x:xs) = x + sum xs
>
> Don't you love it how complicated something like this looks in C++:
>
> template<typename Iterator>
> typename std::iterator_traits<Iterator>::value_type
> sum(Iterator begin, Iterator end)
> {
> typedef typename std::iterator_traits<Iterator>::value_type t;
> t result = t();
> while(begin != end) result += *begin++;
> return result;
> }
>
> Its advantage, though, is that it works with *any* container type
> as long as it has sequential iterators, and *any* value type, as long
> as it supports the + operator.
Mine works for *any* type that supports the + operator too. ;-)
As for other collection types... Well you could construct something in
Haskell, but curiosly nobody bothers. The general method seems to be to
write functions for transforming your collection into or out of a list,
and then using the existing list processing functions.
That used to seem like a pretty strange idea to me. Now I realise that
with function inlining + constructor specialisation + unboxing + stream
fusion + assorted other stuff, the resulting machine code is more or
less the same as if the list functions operated directly on the
collection anyway.
In a sense, a list really *is* a loop in Haskell. When you turn
something into a list, you're not so much creating a list object as
performing a loop over the data.
The big problem of course is that all list functions are inherantly
single-threaded (since linked lists are sequential access only). I hear
they're working on a new library of parallel array manipulation
functions. [Apparently some guy is even targetting it to nVidia's CUDA
architecture for his PhD thesis!] But none of that stuff actually works
yet...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> If all you're after is the ultimate machine efficiency, C can probably
>> still do that better than almost any other language, given enough skill.
>>
>> But what about factors such as code size, readability,
>> maintainability, code reuse, polymorphism, etc etc etc?
>
> Yeh you're right, maybe MS wrote Vista in Haskell ;-)
Maybe if they *had* written it in Haskell it would have come to market
much faster, cheaper, and it would have actually *worked* properly. :-P
OK, joking aside, I present the following seriously weird fact:
Half the developers working on Haskell are Micro$oft employees.
I can't begin to imagine in what universe that even makes sense - M$ is
pushing F#, not Haskell. So why...? WTF...? Besides, M$ is renowned to
promoting low-quality badly-written software. Why would they care about
a high-quality language like Haskell? It all makes no sense...
I present a second fact, which only seems weird considering the first one:
The majority of non-trivial Haskell code doesn't work properly on
Windoze. Only Linux. Or maybe Mac OS. But not Windoze.
So M$ are paying people to develop stuff that doesn't even propperly
support M$'s own flagship product...? OK, I'm completely lost now!
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Half the developers working on Haskell are Micro$oft employees.
Who's the other one working for then? ;-)
> I can't begin to imagine in what universe that even makes sense - M$ is
> pushing F#, not Haskell. So why...? WTF...?
MS is a big company, they don't just write OSs.
http://research.microsoft.com/research/default.aspx
> The majority of non-trivial Haskell code doesn't work properly on
> Windoze. Only Linux. Or maybe Mac OS. But not Windoze.
Why is that? Is it a problem with the Windows compiler?
> So M$ are paying people to develop stuff that doesn't even propperly
> support M$'s own flagship product...? OK, I'm completely lost now!
Who knows, maybe parts of the next MS OS will be written using a functional
language? I'm sure they are investigating such possibilities, they can't
afford not to.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Mine works for *any* type that supports the + operator too. ;-)
Does it work for things like balanced binary trees, double-ended queues,
arrays and strings (ie. sum the ascii values of the characters in a string)?
In other words, does it work for all possible containers which items you
can iterate over?
No, I'm not saying that with the proper language it wouldn't be possible
to make such a function as a short one-liner. I'm just curious to know if
Haskell is such a language.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
