 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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] dev null> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> 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?
The implementation I posted works only for lists. (And this - or
something equivilent to it - is what the standard library actually
contains.)
> 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.
It would be perfectly possible to define a class that allows the
iteration of arbitrary collections. But such a thing is not currently
present in the standard libraries.
As I say, it seems the currently "accepted way" is to define a
transformation from any iteratable structure into a list, and then apply
list-specific operations there. The compiler seems to be rather good at
removing the apparent overhead with this method.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> Half the developers working on Haskell are Micro$oft employees.
>
> Who's the other one working for then? ;-)
>:-[
(This isn't my happy face.)
Actually, they work for various universities.
>> 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.
No, they write flawed software of many kinds. (Or just buy it from other
people.) Still not sure why they'd be interested in software that makes
it easier to write *quality* software - where's the profit in that?
>> 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?
The only "working" Haskell compiler runs off GNU build tools such as
gcc, gas and ld. It also uses automake and Perl. (WTF-overload.)
Most of the things that don't work on Windoze are Haskell bindings to C
libraries. Anything that's 100% Haskell works flawlessly on all
platforms, but linking to C is fiddly. I'm told you need to install a
Unix emulator such as Cygwin to make it work - which obviously I have no
intension of doing.
>> 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.
Heh. I doubt it.
(Not that you care, but there *is* in fact a Haskell OS. But it's a
research project rather than something end-users would be interested in.
I didn't think it was even in active development any more, but
apparently there are people still working on it...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> scott wrote:
>>> Half the developers working on Haskell are Micro$oft employees.
>>
>> Who's the other one working for then? ;-)
>
> >:-[
>
> (This isn't my happy face.)
http://icanhascheezburger.com/2008/03/06/funny-pictures-mah-happi-face/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>
> 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
>
And delivered years later ;). If they had written it in Haskell, they'd
actually had to rewrite it from the scratch (I'm pretty sure they've
reused lots of code from earlier versions). Bye-bye for old bugs, yes.
Welcome for new bugs, also yes.
--
Eero "Aero" Ahonen
http://www.zbxt.net
aer### [at] removethiszbxtnetinvalid
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
>
> And delivered years later ;). If they had written it in Haskell, they'd
> actually had to rewrite it from the scratch (I'm pretty sure they've
> reused lots of code from earlier versions). Bye-bye for old bugs, yes.
> Welcome for new bugs, also yes.
Well, I'm told they rewrote a lot of it already, but yeah, you're
probably right...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
