I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Fwd: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Alberto G. Corona

Again, i missed to forward the message to the list:


I experince also the drug effect. Evolutionary psychologists would say that, because it was vital for our survival, since the stone age, we appreciate any tool powerful enough to solve many problems while at the same time remain simple. So whenever the utility versus learning.-using-,maintaining  costs of a tool is low. then the tool is more appreciated and more pleasure we experiencie by using it. That applies either to a sword, a horse, a car or a programming language.

Haskell has an  execution strategy and a type system that cares for himself about code consistency and a reasonable optimization,  It has only a few keywords, and a intuitive syntax , But combining the security that gives the first two factors and the flexibility of the other two, one can reach high levels of abstraction maintaining a high degree of confidence in the generated code, And such code can be applied to a wider variety of problems. 

For that matter I think that while other languages can borrow some features of haskell, they will never have the power that can be achieved by having them all. And most of them are deep in the core.

2009/9/30 Peter Verswyvelen <[hidden email]>

Yep, LINQ makes C# more enjoyable :-)  Scala and haXe also look nice, a bit of a mix between OCaml/F#, C#/Java and Haskell. 

Besides the fact that hacking in Haskell is a great deal of fun, the main reason I see for learning Haskell: it makes you a better programmer.  After a couple of years of playing with Haskell, I can now solve problems that I couldn't before. It's of course hard to tell if Haskell is the reason here, or just experience, but I feel it really is Haskell (actually, functional programming). Haskell made me see the world in a different way (and if I see Oleg's and co's code, I still have an infinitely long road ahead.

The main reason why you should not learn Haskell: it's a bit of a drug; after you learned Haskell, programming in an "industrial strength" language suddenly feels like a waste of time, time better spent learning more Haskell...

On Wed, Sep 30, 2009 at 10:26 AM, Deniz Dogan <[hidden email]> wrote:
2009/9/30 Andrew Coppin <[hidden email]>:
> (Mr C++ argues that homo sapiens fundamentally think in an imperative way,
> and therefore functional programming in general will never be popular.

Sounds more like Mr C++ fundamentally thinks in an imperative way
because that's what he is used to.

I recently started working with C# and struggled for way too long with
for/foreach loops to do things that in Haskell could be expressed
using only folding, mapping and filtering. When I realised that those
ideas actually exist in System.Linq I suddenly started liking the
language a bit more.

txtCommaSeparatedNames.Text.Split(',').Select(x => x.Trim()).Where(x
=> x.Length > 0).Select(x => Convert.ToInt32(x)).ToList();

Ah, the joy of FP.

--
Deniz Dogan
_______________________________________________
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




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

Fwd: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Alberto G. Corona
In reply to this post by Andrew Coppin



I would say that pure knowledge is pure and functional. but human planning and problem solving is imperative because implies sequencing of operations based on this pure knowledge. haskell express both nicely.

2009/9/30 Andrew Coppin <[hidden email]>
Peter Verswyvelen wrote:

I really doubt people tend to think in either way. It's not even sure our thinking can be modeled with computing no?

Well, try this: Go ask a random person how you add up a list of numbers. Most of them will say wsomething about adding the first two together, adding the third to that total, and so forth. In other words, the step by step instructions. Very few of them will answer that the sum of an empty list is defined to be zero, and the sum of a non-empty list is defined to be the first number plus the sum of the list tail.


Then again, few non-programmers will set anything about creating a counter variable and initialising it to zero either; this is a programming "artifact". (Humans don't think like this internally, but most programming languages conceptually require it.) Nobody has much difficulty with this, so maybe the only problem with Haskell is that everybody learns to program "the other way" first, before they get to Haskell...


_______________________________________________
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: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Sebastian Sylvan
In reply to this post by Andrew Coppin


On Wed, Sep 30, 2009 at 8:32 AM, Andrew Coppin <[hidden email]> wrote:

(Mr C++ argues that homo sapiens fundamentally think in an imperative way, and therefore functional programming in general will never be popular. We shall see...)

You could use the same argument against, say, utensils. Being "natural" or "intuitive" is a 100% irrelevant metric for any tool. What matters is if it's effective or not. 

--
Sebastian Sylvan

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

Re: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Felipe Lessa
In reply to this post by Andrew Coppin
On Wed, Sep 30, 2009 at 03:43:12PM +0100, Andrew Coppin wrote:
> Well, try this: Go ask a random person how you add up a list of
> numbers. Most of them will say something about adding the first two
> together, adding the third to that total, and so forth. In other
> words, the step by step instructions. Very few of them will answer
> that the sum of an empty list is defined to be zero, and the sum of
> a non-empty list is defined to be the first number plus the sum of
> the list tail.

Maybe they would say that you have to go adding each number to
the others, i.e. they're thinking with a fold.

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

Re: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

John Dorsey-2
In reply to this post by Andrew Coppin
> Well, try this: Go ask a random person how you add up a list of numbers.  
> Most of them will say something about adding the first two together,  
> adding the third to that total, and so forth. In other words, the step  
> by step instructions.

You word the (hypothetical) question with a bias toward imperative
thinking.  You're asking "How do you do this action?"

Why isn't the question "What is the sum of a list of numbers?", which is
biased toward the declarative?

John
(who's glad he's not a social scientist)

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

Re: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Dominic Espinosa
On Wed, Sep 30, 2009 at 11:10:19PM -0400, John Dorsey wrote:

> > Well, try this: Go ask a random person how you add up a list of numbers.  
> > Most of them will say something about adding the first two together,  
> > adding the third to that total, and so forth. In other words, the step  
> > by step instructions.
>
> You word the (hypothetical) question with a bias toward imperative
> thinking.  You're asking "How do you do this action?"
>
> Why isn't the question "What is the sum of a list of numbers?", which is
> biased toward the declarative?

Indeed! Surely a person asked to "sum a list of numbers" such as
[45,82,78] will do exactly this: 45 + 82 + 78, proceeding to add 82 to
45, noting the intermediate sum, and then adding 78 to that. It's
certainly a fold, though our (non-programmer) subject here probably
wouldn't call it that.  Generalizing this pattern to non-arithmetical
situations is an 'FP trick' (or pattern, or what-have-you).  Also, he or
she would probably not understand what we know as 'foldl' or 'foldr'
immediately because the idea of a 'starting value' is not that clear --
the task statement of 'add a list of numbers' seems to presuppose that
there are numbers to be added, i.e. the list is not empty.

Assuredly the subject would not (mentally) count how many numbers were
in the list, set up a 'counter', and then execute an addition operation
that many times, storing the result in a 'temporary variable'.

In both cases our anonymous non-programmer understands the idea of
recursive/iterative addition, but does not know about the general
pattern of 'fold' or 'for(...) { ... }'. These are learned from
programming books. Most of these books teach some imperative language,
so, many programmers get used to the one and then have some difficulty
re-tooling mentally for the other. I know I did when I first began using
Haskell, but now the lack of folds in, say, C really hurts. :) Whoever
commented earlier in the thread that learning haskell is bad for your
brain because you pine for it when you program in other languages was
right on.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Ketil Malde-5
In reply to this post by Andrew Coppin
Andrew Coppin <[hidden email]> writes:

> Peter Verswyvelen wrote:

>> I really doubt people tend to think in either way. It's not even
>> sure our thinking can be modeled with computing no?

> Well, try this: Go ask a random person how you add up a list of
> numbers.

Although the question of how we "naturally" think often comes up, I'm
not sure it's a very important one.  In my experience, the natural
thing for humans appear rather to be the absence of thinking, and
instead slouching in front of the TV eating unhealthy food.

After all, we give people who program computers several years of
education to learn about unnatural things like counters and temporary
variables, or recursion and folds.  The question shouldn't be what comes
more natural for average Joe, but rather what skills can we teach a
reasonably bright student in three to five years that will make her the
most effective programmer.

(That's what the question should be, of course what the question really
*is* is what curriculum can we present that looks entertaining,
fashionable, and trivial enough that enough high-school kids will apply
for the department not to be starved of funds... )

-k
--
If I haven't seen further, it is by standing in the footprints of giants
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Andrew Coppin
In reply to this post by John Dorsey-2
John Dorsey wrote:

>> Well, try this: Go ask a random person how you add up a list of numbers.  
>> Most of them will say something about adding the first two together,  
>> adding the third to that total, and so forth. In other words, the step  
>> by step instructions.
>>    
>
> You word the (hypothetical) question with a bias toward imperative
> thinking.  You're asking "How do you do this action?"
>
> Why isn't the question "What is the sum of a list of numbers?", which is
> biased toward the declarative?
>  

Sure. But what is a computer program? It's a *list of instructions* that
tells a computer *how to do something*. And yet, the Haskell definition
of sum looks more like a definition of what a sum is rather than an
actual, usable procedure for *computing* that sum. (Of course, we know
that it /is/ in fact executable... it just doesn't look it at first sight.)

Whatever; I'm leaning more and more towards the concept that FP is only
hard for people who already learned some other way...

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

Re: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Andrew Coppin
In reply to this post by Ketil Malde-5
Ketil Malde wrote:

> Although the question of how we "naturally" think often comes up, I'm
> not sure it's a very important one.  In my experience, the natural
> thing for humans appear rather to be the absence of thinking, and
> instead slouching in front of the TV eating unhealthy food.
>
> After all, we give people who program computers several years of
> education to learn about unnatural things like counters and temporary
> variables, or recursion and folds.  The question shouldn't be what comes
> more natural for average Joe, but rather what skills can we teach a
> reasonably bright student in three to five years that will make her the
> most effective programmer.
>  

I'll go along with that.

Although, to all the people who ask "why is Ruby so popular?", I might
suggest "because it's easy to learn"...

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

Re: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Eugene Kirpichov
In reply to this post by Andrew Coppin
2009/10/1 Andrew Coppin <[hidden email]>:

> John Dorsey wrote:
>>>
>>> Well, try this: Go ask a random person how you add up a list of numbers.
>>>  Most of them will say something about adding the first two together,
>>>  adding the third to that total, and so forth. In other words, the step  by
>>> step instructions.
>>>
>>
>> You word the (hypothetical) question with a bias toward imperative
>> thinking.  You're asking "How do you do this action?"
>>
>> Why isn't the question "What is the sum of a list of numbers?", which is
>> biased toward the declarative?
>>
>
> Sure. But what is a computer program? It's a *list of instructions* that
> tells a computer *how to do something*. And yet, the Haskell definition of
> sum looks more like a definition of what a sum is rather than an actual,
> usable procedure for *computing* that sum. (Of course, we know that it /is/
> in fact executable... it just doesn't look it at first sight.)

Well, we are not writing computer programs directly, even in C, that's
what compilers are for.
That's why I find arguments about the sequential essence of computer
programs to be weak.

>
> Whatever; I'm leaning more and more towards the concept that FP is only hard
> for people who already learned some other way...
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



--
Eugene Kirpichov
Web IR developer, market.yandex.ru
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Andrew Coppin
Eugene Kirpichov wrote:

> 2009/10/1 Andrew Coppin <[hidden email]>:
>  
>> Sure. But what is a computer program? It's a *list of instructions* that
>> tells a computer *how to do something*. And yet, the Haskell definition of
>> sum looks more like a definition of what a sum is rather than an actual,
>> usable procedure for *computing* that sum. (Of course, we know that it /is/
>> in fact executable... it just doesn't look it at first sight.)
>>    
>
> Well, we are not writing computer programs directly, even in C, that's
> what compilers are for.
> That's why I find arguments about the sequential essence of computer
> programs to be weak.
>  

It might be a better argument to say that human thinking is
fundamentally sequential; parallel computers have been around for a
little while now...

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

Re: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Eugene Kirpichov
2009/10/1 Andrew Coppin <[hidden email]>:

> Eugene Kirpichov wrote:
>>
>> 2009/10/1 Andrew Coppin <[hidden email]>:
>>
>>>
>>> Sure. But what is a computer program? It's a *list of instructions* that
>>> tells a computer *how to do something*. And yet, the Haskell definition
>>> of
>>> sum looks more like a definition of what a sum is rather than an actual,
>>> usable procedure for *computing* that sum. (Of course, we know that it
>>> /is/
>>> in fact executable... it just doesn't look it at first sight.)
>>>
>>
>> Well, we are not writing computer programs directly, even in C, that's
>> what compilers are for.
>> That's why I find arguments about the sequential essence of computer
>> programs to be weak.
>>
>
> It might be a better argument to say that human thinking is fundamentally
> sequential; parallel computers have been around for a little while now...
>

I don't buy this argument, either; human thinking is far too broad a
concept to say that it is simply "sequential". If it were sequential,
it could barely express non-sequential concepts, and natural languages
would have rather few of them, which we all know is false.

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



--
Eugene Kirpichov
Web IR developer, market.yandex.ru
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Curt Sampson-2
In reply to this post by Andrew Coppin
On 2009-10-01 08:53 +0100 (Thu), Andrew Coppin wrote:

> Sure. But what is a computer program? It's a *list of instructions* that  
> tells a computer *how to do something*.

Some are. Some aren't, as proven by the Haskell definition of sum, which
is certainly a "program."

I like to think of a program as a specification. A list of instructions
can certainly qualify, but so can other things, depending on what's
interpreting and executing that specification.

On 2009-10-01 08:59 +0100 (Thu), Andrew Coppin wrote:

> Although, to all the people who ask "why is Ruby so popular?", I might  
> suggest "because it's easy to learn"...

Actually, Ruby isn't terribly easy to learn. If you have previous
experience in another imperative or OO language, you'll pick up the
parts of Ruby that are similar to that fairly quickly, but you're not
really learning anything so much as just doing a simple translation of a
few concepts you already know. You're still going to run into problems
with a number of standard Ruby constructions, probably not be writing
clean or idiomatic code, and you'll be a long way from writing DSLs. In
particular, you're likely to be writing highly repetitive code which
could easily be refactored into something much smaller and nicer. (I'm
constantly seeing people who have programmed in Ruby for years come up
with six- to ten-line chunks of code that are could be replaced with a
single line if they, e.g., only know that there was such as thing as a
"modulo" function.)

>From reading a lot of the code out there (particularly disasters such
as Rails), I suspect a lot of Ruby programmers don't get much past
this level.

cjs
--
Curt Sampson       <[hidden email]>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Alberto G. Corona

2009/10/1 Curt Sampson <[hidden email]>
On 2009-10-01 08:53 +0100 (Thu), Andrew Coppin wrote:

> Sure. But what is a computer program? It's a *list of instructions* that
> tells a computer *how to do something*.

Some are. Some aren't, as proven by the Haskell definition of sum, which
is certainly a "program."

I like to think of a program as a specification. A list of instructions
can certainly qualify, but so can other things, depending on what's
interpreting and executing that specification.




Lets say that how to do a sum is pure abstract knowledge,  and this translates nicely to a declarative haskell sentence.

But to perform a sum of two concrete numbers is procedural, because either the program or the compiler or yourself have to extract from the available knowledge a  sequence of steps in order to obtain a new knowledge, that is , the  result. 

In imperative languages the sequentiation  is more explicit. in functional languages this is more implicit, because the compiler+ runtime do the sequentiation. 

In fact, a C compiler also perform an automatic sequentiation for this simple operation and generates a sequence of assembler code for either a sum or any mathematical expression, but the haskell compiler is way more powerful for extracting sequences of steps from declarative statements.   moreover, haskell promote a declarative style because laziness avoid to express abstract knowledge as sequences. Referential transparency avoid also dependencies of expressions from other expressions, and thus avoids artificial sequencing.

however every time the program has to interact with the external world, even for printing the result,, sequencing is necessary. That´s why  the compilers and interpreters exist!!!.   

If the program has to interact many times with the external world in a given sequence, the compiler can not guess such sequence if you don't write it explicitly.
 
The perfect declarative  haskell program has no main, no IO monad and no executable.




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

Re: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Peter Verswyvelen-2
In reply to this post by Andrew Coppin


On Thu, Oct 1, 2009 at 9:53 AM, Andrew Coppin <[hidden email]> wrote:
Sure. But what is a computer program? It's a *list of instructions* that tells a computer *how to do something*. And yet, the Haskell definition of sum looks more like a definition of what a sum is rather than an actual, usable procedure for *computing* that sum. (Of course, we know that it /is/ in fact executable... it just doesn't look it at first sight.)

Is it? The list of instruction is just an abstraction layer built on top of purely physical process of electrons and transistors; I'm not sure how much imperativeness remains at this level? Not to mention the quantum mechanical processes that take place... And that are also just mathematical models... I mean, it really depends from which angle and at which detail you look at it, no?


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

Fwd: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Alberto G. Corona
;)

Off topic:

Maybe the entire space time,  the universe and his history, is isomorphic to a mathematical structure. 



2009/10/1 Peter Verswyvelen <[hidden email]>


On Thu, Oct 1, 2009 at 9:53 AM, Andrew Coppin <[hidden email]> wrote:
Sure. But what is a computer program? It's a *list of instructions* that tells a computer *how to do something*. And yet, the Haskell definition of sum looks more like a definition of what a sum is rather than an actual, usable procedure for *computing* that sum. (Of course, we know that it /is/ in fact executable... it just doesn't look it at first sight.)

Is it? The list of instruction is just an abstraction layer built on top of purely physical process of electrons and transistors; I'm not sure how much imperativeness remains at this level? Not to mention the quantum mechanical processes that take place... And that are also just mathematical models... I mean, it really depends from which angle and at which detail you look at it, no?


_______________________________________________
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: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Tom Tobin-2
In reply to this post by Andrew Coppin
On Thu, Oct 1, 2009 at 3:26 AM, Andrew Coppin
<[hidden email]> wrote:
> It might be a better argument to say that human thinking is fundamentally
> sequential; parallel computers have been around for a little while now...

Perhaps *conscious* human thinking is sequential — yet our brains are
massively parallel processors, and have been around for quite a long
time.  ;-)
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Andrew Coppin
Tom Tobin wrote:

> On Thu, Oct 1, 2009 at 3:26 AM, Andrew Coppin
> <[hidden email]> wrote:
>  
>> It might be a better argument to say that human thinking is fundamentally
>> sequential; parallel computers have been around for a little while now...
>>    
>
> Perhaps *conscious* human thinking is sequential — yet our brains are
> massively parallel processors, and have been around for quite a long
> time.  ;-)
>  

This is very true. And it's just as well; I read somewhere that the
maximum firing rate of a neuron gives the human brain an effective
"clock frequency" of about 100 MHz - which isn't terribly fast. But it's
massively parallel, as you say.

Actually, I just had a flash of inspiration: Maybe the reason
programmers tend to think sequentially is because programmers tend to be
*men*. Maybe the way to hardness the multicores is to get more women
into programming? :-D

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

Fwd: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Alberto G. Corona
In reply to this post by Tom Tobin-2
May be because consciousness is relatively new and thus, not optimized. 

Sequentiallity is somehow related with lack of information and lack or resources. There is nothing more sequential than a Turing machine. The Von Newman architecture is designed to make as much as possible with  a few more resources. The older parts of the brain are fast and parallel because they have a long history of optimizations by natural selection., The new cortex still struggles, step by step, to deduce new information from the available internal and external information at the pace they arrive.


2009/10/1 Tom Tobin <[hidden email]>

On Thu, Oct 1, 2009 at 3:26 AM, Andrew Coppin
<[hidden email]> wrote:
> It might be a better argument to say that human thinking is fundamentally
> sequential; parallel computers have been around for a little while now...

Perhaps *conscious* human thinking is sequential — yet our brains are
massively parallel processors, and have been around for quite a long
time.  ;-)
_______________________________________________
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: I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

Richard A. O'Keefe
In reply to this post by Andrew Coppin

On Oct 1, 2009, at 8:53 PM, Andrew Coppin wrote:
>
> Sure. But what is a computer program?

It depends on the computer.  Classical machines do one thing,
data flow machines do another, reduction machines another.
I once saw a tiny machine at a UK university where the hardware
was a combinator reduction gadget.  It wasn't combinators on top
of conventional instructions, the hardware did nothing _but_
combinators.

A computer program, in short, is *whatever we want it to be*.
(Within reasonable limits.)

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