Re: [Haskell-cafe] 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.
Shelby Moore wrote: > The most accurate question should be, "How do you add some numbers with > minimized instructions?", because it forces them to realize they must > order the set. > > An answer might be, "Zero if empty, else order the set, sum the first > number with the sum of remainder of the set. Repeat for the sum of > remainder." Realize that I did not write "sort" order. I am refering to "queue" order that allows the "first" distinction. Also by "remainder" means "remaining portion of" (you are dividing the queue-ordered set by it's "tail" and thus "head" is the remainder). I just returned from 130 pushups and 1.2 mile run, and it was more difficult since I've not gotten out my thinking-cap chair for past 2 weeks. I wonder if our mental and physical exertion competes for the limited velocity at which our body can convert fuel to glucose and dump the cell waste products through the liver? Many people are already consumed by other exertions, many which are passive and compulsive (e.g. TV, reading same topics over and over again which are presented with superficial differences), which may atrophy their minds in terms of the brain patterns needed for logical induction. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 said: >> Sure. But what is a computer program? then Richard O'Keefe said: > A computer program, in short, is *whatever we want it to be*. > (Within reasonable limits.) I agree with Richard's conclusion. >From where I sit, the critical point is that, unless you're breadboarding, programming is working in the abstract, and we choose our abstractions. There's a strong tradition of sequential imperative programming, but that's as far as it goes. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
On Oct 2, 2009, at 11:14 AM, Richard O'Keefe wrote: Human *verbalisation* is fundamental, human *thinking* is not. Sigh. Accidentally lean on the wrong key and half your text disappears. Human *verbalisation* is fundamentally sequential. Human *thinking* is not. I don't know any sign language myself, but I am aware that since people have faces and two hands, there is a limited amount of concurrency in some sign languages. (E.g., you can give place and manner at the same time.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
On Oct 1, 2009, at 9:26 PM, Andrew Coppin 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... You've never been talking on the phone while stirring a pot with one hand and wiping down a child with the other? You've never read (part of) a book while watching a TV program and been able to summarize both afterwards? You've never played the piano while talking about something else? Human *verbalisation* is fundamental, human *thinking* is not. (It's not unboundedly parallel either.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 wrote: On Thu, Oct 1, 2009 at 3:26 AM, Andrew Coppin 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
On Thu, Oct 1, 2009 at 3:26 AM, Andrew Coppin 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
On Thu, Oct 1, 2009 at 9:53 AM, Andrew Coppin 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
2009/10/1 Curt Sampson > 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
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 +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
2009/10/1 Andrew Coppin : > Eugene Kirpichov wrote: >> >> 2009/10/1 Andrew Coppin : >> >>> >>> 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 > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 wrote: 2009/10/1 Andrew Coppin : 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
2009/10/1 Andrew Coppin : > 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 > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
> 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
On Wed, Sep 30, 2009 at 8:32 AM, Andrew Coppin 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
В сообщении от 30 сентября 2009 15:58:40 Jochem Berndsen написал: > Deniz Dogan wrote: > > 2009/9/30 Andrew Coppin : > >> (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. > > This may or may not be true. It would be interesting to see some > research on this. Without that, I think we cannot decide either way. > Cheers, Jochem > One of my first impressiions with haskell was absence of impendance mismatch between my thoughts and my code. This is not nessesarily true for everyone because people has different ways of thinking I beleive. P.S. And haskell doesn't have tendency to eat brain away like C++ does. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
Am Mittwoch 30 September 2009 09:32:08 schrieb Andrew Coppin: > I might also point out that 90% of all desktop computers run Windows, > and yet every single C library binding on Hackage fails to compile on > Windows. That really needs to be fixed. Contribute your share, switch to Linux or BSD 8-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
Sure, but it doesn't mean that because someone uses an imperative way of counting, that it means people's brains work imperatively all the way. People tend to talk and communicate a lot in a declarative way no? For example ask someone that doesn't know programming how he we would make a paddleball game. I have no idea what that person would say, but I think it would something like: "I tell the computer that the paddle should move along with the mouse; and when the ball bounces against the paddle, the ball reverses direction; if the paddle misses the ball, it's game over". I don't think anybody would say: "each frame, the ball's position moves by a tiny timestep; when the mouse is sampled, copy the mouse position to the paddle; etc..." On Wed, Sep 30, 2009 at 4:43 PM, Andrew Coppin wrote: > 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 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. > > 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 > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
On Wed, Sep 30, 2009 at 12:32 AM, Andrew Coppin wrote: > Casey Hawthorne wrote: > >> 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. >> >> If this is true, it needs to be pushed. >> >> And if by changing a few lines of source code one can develop a whole >> family of similar applications, that needs to be pushed, also. >> >> :) >> >> > > As one C++ expert I know is fond of telling me, "Haskell will only become > popular when obscure mathematics becomes popular". > > You can argue about whether or not this is true. Myself I think we just > need to start documenting things more clearly. (E.g., Mr C++ apparently > spent half an hour trying to figure out why an expression wouldn't parse. > Turns out you have to write negative numbers in brackets. Which isn't hard, > but you have to already know this.) > > It's clear Haskell has become popular, and without the need for the obscure math. (though I have to admit, I find the math highly interesting, yet I'm quite the novice) > I might also point out that 90% of all desktop computers run Windows, and > yet every single C library binding on Hackage fails to compile on Windows. > That really needs to be fixed. (Not to mention some of the standard I/O > functions doing slightly strange things because GHC is calling POSIX > compatibility functions rather than native I/O functions. For example, > doesDirectoryExist "C:\\" = False.) > > YES > The lack of a big shiny whizzy-looking IDE probably stops quite a few > people too. (I gather the Leksah guys are working on that one.) > > I personally have found 2 IDEs to be "worth bothering with" in my entire life. One is Visual Studio. The other is Borland's Turbo C++ 3.0 IDE for DOS. (I even coerced it to run on my 16MHz 286 geeze 16MHz was fast back then :-) ) > Lack of a good way to write native-looking Windows GUI applications - or > indeed any GUI applications without requiring a stack of DLLs - probably > doesn't help either. > > None of these look fundamentally insumountable to me. > > (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...) > I think that's a bunch of garbage :-). People think algorithmically, or we wouldn't design algorithms to deal with complexity. Algorithms very often have steps that are quite imperative, but many of the sub-pieces of a step are clearly pure and functional. Being able to see the difference in a set of instructions, and being able to isolate them, can be quite a powerful way to break a problem down to a manageable set of steps. If it wasn't, Functional Programming would have died long ago, and it clearly hasn't, and is gaining ground. See F#, Erlang, O'Caml, and Haskell. I don't think you can argue with the quantitative data that is the user base. The number of people in #haskell on freenode, or the subscribers on Reddit. People are paying attention and trying it out. Whether haskell will completely fail to "Avoid success at all costs" or not is hard to say :-). In fact, Intel is porting their concurrent collections libraries to Haskell now. How's that for an endorsement? (It *was* just a C++ library). Tell your friend to stick that in their pipe and smoke it... then pass it to me! :-) Dave > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 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 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. 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
I really doubt people tend to think in either way. It's not even sure our thinking can be modeled with computing no? On Wed, Sep 30, 2009 at 1:58 PM, Jochem Berndsen wrote: > Deniz Dogan wrote: > > 2009/9/30 Andrew Coppin : > >> (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. > > This may or may not be true. It would be interesting to see some > research on this. Without that, I think we cannot decide either way. > Cheers, Jochem > > -- > Jochem Berndsen | joc...@functor.nl | > joc...@牛在田里.com > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
Deniz Dogan wrote: > 2009/9/30 Andrew Coppin : >> (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. This may or may not be true. It would be interesting to see some research on this. Without that, I think we cannot decide either way. Cheers, Jochem -- Jochem Berndsen | joc...@functor.nl | joc...@牛在田里.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
On Wed, Sep 30, 2009 at 9:32 AM, Andrew Coppin wrote: > I might also point out that 90% of all desktop computers run Windows, and > yet every single C library binding on Hackage fails to compile on Windows. > That really needs to be fixed. (Not to mention some of the standard I/O > functions doing slightly strange things because GHC is calling POSIX > compatibility functions rather than native I/O functions. For example, > doesDirectoryExist "C:\\" = False.) This is a problem of C / Posix, not a problem of Haskell. Haskell C bindings compile on Windows without issues IF the corrisponding library is available. It is compiling the (usually posix) C library in Windows the real issue. Anyway, on Windows Vista, cmd.exe: GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Prelude> :m System.Directory Prelude System.Directory> doesDirectoryExist "C:\\" True Salvatore ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
Deniz Dogan wrote: 2009/9/30 Andrew Coppin : (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. Entirely plausible, yes. Consider, for a moment, the task of counting how many elements there are in a linked list. The imperative way: "Initialise counter to zero. Start at the beginning of the list. If we have reached the end of the list, return the counter. Otherwise, increase the counter by one and fetch the next list node." The FP way: "The size of an empty list is zero. The size of a nonempty list is one plus the sum of the suffix of the list." It does read kind of like a riddle. It's not even immediately obvious that this is the entire definition. (Unless you already happen to be a maths nerd, like myself.) The first one reads like a list of instructions explaining HOW to count the list size. The second reads more like a definition of WHAT the list size is. It doesn't immediately look like there's even a way to execute this. (They don't call it declarative programming for nothing...) I note in passing that, even in English, the FP version is shorter. ;-) I think if you wanted to count the size of a tree, it seems a lot more natural though: "If this is a leaf node, return one. Otherwise: Initialise counter to zero. Count size of left subtree and add to counter. Count size of right subtree and add to counter. Return counter." "The size of a leaf node is one. The size of a branch node is the sum of the sizes of the two subtrees." Arguably most people are probably more accustomed to thinking in terms of "do this, do that, do the other" (think about, e.g., a cooking recipy or a task list) then they are to defining task goals as self-referential riddles. On the other hand, from what I've experienced, computer programming is already a task that some people "get", and others simply don't. Maybe in another forty years, all programming will be functional programming, and anybody who doesn't "get" recursion just won't become a programmer? Who knows... Ah, the joy of FP. Amen! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
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 wrote:
> 2009/9/30 Andrew Coppin :
> > (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
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
2009/9/30 Andrew Coppin :
> (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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
Casey Hawthorne wrote: 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. If this is true, it needs to be pushed. And if by changing a few lines of source code one can develop a whole family of similar applications, that needs to be pushed, also. :) As one C++ expert I know is fond of telling me, "Haskell will only become popular when obscure mathematics becomes popular". You can argue about whether or not this is true. Myself I think we just need to start documenting things more clearly. (E.g., Mr C++ apparently spent half an hour trying to figure out why an expression wouldn't parse. Turns out you have to write negative numbers in brackets. Which isn't hard, but you have to already know this.) I might also point out that 90% of all desktop computers run Windows, and yet every single C library binding on Hackage fails to compile on Windows. That really needs to be fixed. (Not to mention some of the standard I/O functions doing slightly strange things because GHC is calling POSIX compatibility functions rather than native I/O functions. For example, doesDirectoryExist "C:\\" = False.) The lack of a big shiny whizzy-looking IDE probably stops quite a few people too. (I gather the Leksah guys are working on that one.) Lack of a good way to write native-looking Windows GUI applications - or indeed any GUI applications without requiring a stack of DLLs - probably doesn't help either. None of these look fundamentally insumountable to me. (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...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
We should have GHC 6.12 launch parties like the Windows 7 ones ;) (if you haven't seen it, and are feeling masochistic: http://www.youtube.com/watch?v=1cX4t5-YpHQ) Dan On Tue, Sep 29, 2009 at 9:36 PM, Casey Hawthorne wrote: > On Tue, 29 Sep 2009 18:19:08 -0700, you wrote: > >>On Tue, Sep 29, 2009 at 5:24 PM, Casey Hawthorne wrote: >> >>> 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. >>> >>> If this is true, it needs to be pushed. >>> >>> And if by changing a few lines of source code one can develop a whole >>> family of similar applications, that needs to be pushed, also. >>> >> >>If you look through the archives here and elsewhere on the net, I think >>you'll see that technical superiority isn't the driving force for language >>adoption. It can help, but other factors seem to play a more significant >>role, usually dependent on context in which the languages became popular. >>At times it can seem like luck, but then I'm reminded of what Louis Pasteur >>said about luck and prepared minds. >> >>It is good that you're talking about Haskell though. Continue to discuss it >>with your peers and show them fun and cool things you've written using >>Haskell. I think this is more compelling for the uninitiated than >>statements about perceived technical power of the language. I've heard >>people explain this as, "showing is better than telling." >> >>Cheers, >>Jason > > Hmmm! > > Like those people that are paid to go into coffee houses with some new > technology, and then people see what they're doing and wander over and > ask them questions about it. > >>"showing is better than telling." > > It's even being used by marketers/sellers. > > :) > -- > Regards, > Casey > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
On Tue, 29 Sep 2009 18:19:08 -0700, you wrote: >On Tue, Sep 29, 2009 at 5:24 PM, Casey Hawthorne wrote: > >> 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. >> >> If this is true, it needs to be pushed. >> >> And if by changing a few lines of source code one can develop a whole >> family of similar applications, that needs to be pushed, also. >> > >If you look through the archives here and elsewhere on the net, I think >you'll see that technical superiority isn't the driving force for language >adoption. It can help, but other factors seem to play a more significant >role, usually dependent on context in which the languages became popular. >At times it can seem like luck, but then I'm reminded of what Louis Pasteur >said about luck and prepared minds. > >It is good that you're talking about Haskell though. Continue to discuss it >with your peers and show them fun and cool things you've written using >Haskell. I think this is more compelling for the uninitiated than >statements about perceived technical power of the language. I've heard >people explain this as, "showing is better than telling." > >Cheers, >Jason Hmmm! Like those people that are paid to go into coffee houses with some new technology, and then people see what they're doing and wander over and ask them questions about it. >"showing is better than telling." It's even being used by marketers/sellers. :) -- Regards, Casey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.
On Tue, Sep 29, 2009 at 5:24 PM, Casey Hawthorne wrote: > 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. > > If this is true, it needs to be pushed. > > And if by changing a few lines of source code one can develop a whole > family of similar applications, that needs to be pushed, also. > If you look through the archives here and elsewhere on the net, I think you'll see that technical superiority isn't the driving force for language adoption. It can help, but other factors seem to play a more significant role, usually dependent on context in which the languages became popular. At times it can seem like luck, but then I'm reminded of what Louis Pasteur said about luck and prepared minds. It is good that you're talking about Haskell though. Continue to discuss it with your peers and show them fun and cool things you've written using Haskell. I think this is more compelling for the uninitiated than statements about perceived technical power of the language. I've heard people explain this as, "showing is better than telling." Cheers, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
