6 ms·

Very cool but I am afraid this is geek candy that would not fly for mere mortals. When you say next-gen IDE do you mean for a certain class of developers? The

by Edmond 13y ago

Very cool but I am afraid this is geek candy that would not fly for mere mortals. When you say next-gen IDE do you mean for a certain class of developers? The problem with these type of development tools is that it moves your brain from thinking in terms that of a human to thinking in a very structured way more attuned to machines. This is a problem with functional programming in general, it is fundamentally anti-human, people don't think functionally but rather procedurally. Full disclosure here, IDE maker so I have skin in this game :)

seanmcdirmid 13y ago
What IDE are you working on? I agree with the argument against functional programming, though I would qualify that with pureness (doing everything functionally) rather than just the use of functions in general: functions are sometimes the most natural way to do something. Haskell is good for what it is, an experiment in pure functional programming, which has taught us a lot about programming in general.
- Edmond 13y ago
  I agree, that's why I was asking which class of developers they are targeting... My company is building an IDE that is purely about productivity, specifically for building business web applications. Check my profile for link.
  - seanmcdirmid 13y ago
    Cool. I checked out your page, it seems your tool logo is very similar to ours (MS) :). I'm not sure if it is appropriate to think about specific groups of developers in a general purpose IDE. You really can't guess how they will use your tool, which applies to PL design in general. Personally speaking, there are functional programming enthusiasts who think wildly different from the way I do, and I guess they would sort of select out given my lack of understanding of their psychology as reflected in my design.
    - Edmond 13y ago
      Haha...the logo similarity is pure coincidence... Incidentally some time back I posted about the similarities between Google and Microsoft logos: https://news.ycombinator.com/item?id=6678308 https://news.ycombinator.com/item?id=6678308 :)
      - seanmcdirmid 13y ago
        With four colored boxes...I've seen our logo all over the place even before it was our logo :)
freyrs3 13y ago
> This is a problem with functional programming in general, it is fundamentally anti-human I would argue that the "anything goes" dynamic procedural languages ( like Ruby, Python ) are far more anti-human, in that human ability to reason about large masses of code scales orders of magnitude worse than in languages that provide a strong theoretic framework for reasoning about code.
- Edmond 13y ago
  Sure if it was easy for people to think functionally then functional programming is without a doubt more elegant. But elegance doesn't negate the fact that the reasoning model demanded by functional programming isn't friendly to the way we think. The elegance argument is something proponents always bring up, but it misses the point. While dynamic procedural languages have their problems, I think they work for the most part, hence their success Vis-à-vis functional languages. As far as the issue of scale, that's why modular constructs as added to manage large code bases.
  - freyrs3 13y ago
    I don't know how you're coming to this result, but it /is/ easy for people to think functionally. You can teach intro-CS classes in both functional and imperative styles and generally they pick up both styles at the same rate. I've seen it year after year of teaching these courses. The myth that functional programming doesn't match human thought is just flat out FUD, there's no evidence to support it. The adoption of programming languages is more influenced by economic factors than informed by solid engineering.
    - Edmond 13y ago
      I wont argue about your experience in the class room but both styles of programming have been around for about the same length of time and yet their adoption rates speak volume. We can debate this ad infinitum and probably wont come to an agreement.
      - 13y ago
tikhonj 13y ago
I think that's a broad mischaraterization of functional programming. It is certainly not obvious a priori that people think procedurally. It certainly does not match my experience teaching programming to complete beginners--even concepts like mutable variables and loops are not particularity intuitive. People really like to think by analogy and think based on relations. Functional programming makes this much simpler by giving you simple abstractions and, crucially, letting you not worry about extraneous machine details. In a functional language, even the order your code gets evaluated is below your level of abstraction. Ultimately, functional programming lets you talk about what where imperative languages force you to talk about how. That's pro-human. It's exposing the underlying machine and computation--imperative programming, in a word--that's anti-human!
- seanmcdirmid 13y ago
  > People really like to think by analogy and think based on relations. People really like to think by analogy and metaphor. Go objects!
  - JasonFruit 13y ago
    Go doesn't have objects.
- deleted 13y ago
  [deleted]
- deleted 13y ago
  [deleted]
andrewflnr 13y ago
Actually, machines are attuned to flat, unstructured lists of instructions, the polar opposite of functional programming. But when people wanted to think clearly, they invented math, of which FP is nearly the computational manifestation. You have the human-vs-machine thing exactly backwards. The reason we tend to think in imperative terms is one of familiarity: most of our first programming experiences are in languages that are (sometimes high-level, but still) descendants of assembly, because at first that was the only programming that existed: flat lists of instructions designed for a machine. Granted, if a human wants to describe a physical process, they will use procedural language. But computers are primarily about information, and we think about information in terms of relationships. That's exactly what FP is about: expressing computation in terms of relationships.
- Edmond 13y ago
  I agree that a Turing machine is imperative...when I refer to machines I am generally referring to an inflexible approach to solving problems, not so much how computers execute instructions. As humans I think we need the ability to be messy and imprecise in order to be creative. >The reason we tend to think in imperative terms is one of familiarity That's debatable given that both approaches have been around for about the same length of time with different outcomes in terms of adoption.
  - codygman 13y ago
    > That's debatable given that both approaches have been around for about the same length of time with different outcomes in terms of adoption. If unix had been created in LISP or ML, I believe we might be in the opposite position. Though that hinges on a LISP unix being as successful as the C one.
    - mike_hearn 13y ago
      But before UNIX there was Symbolics, and Symbolics failed in the market whereas UNIX succeeded.
teamonkey 13y ago
> This is a problem with functional programming in general, it is fundamentally anti-human, people don't think functionally but rather procedurally. There was a study a while back[1] that showed non-programmers a series of statements of the sort, int a = 10; int b = 20; a = b; and asked them the value of a. It seemed that some people could not grasp even very basic fundamentals. The thing is, if you'd never programmed before but you HAD basic algebra knowledge, the third line above would have broken your brain. 10 =/= 20. You can't change the value of a, it's against everything you know! The point is, people don't think functionally or procedurally. Both of these programming styles are just learned behaviours, not basic human nature. [1] http://www.codinghorror.com/blog/2006/07/separating-programming-sheep-from-non-programming-goats.html http://www.codinghorror.com/blog/2006/07/separating-programm...

by Edmond 13y ago

seanmcdirmid 13y ago

What IDE are you working on? I agree with the argument against functional programming, though I would qualify that with pureness (doing everything functionally) rather than just the use of functions in general: functions are sometimes the most natural way to do something. Haskell is good for what it is, an experiment in pure functional programming, which has taught us a lot about programming in general.

Edmond 13y ago
I agree, that's why I was asking which class of developers they are targeting... My company is building an IDE that is purely about productivity, specifically for building business web applications. Check my profile for link.
- seanmcdirmid 13y ago
  Cool. I checked out your page, it seems your tool logo is very similar to ours (MS) :). I'm not sure if it is appropriate to think about specific groups of developers in a general purpose IDE. You really can't guess how they will use your tool, which applies to PL design in general. Personally speaking, there are functional programming enthusiasts who think wildly different from the way I do, and I guess they would sort of select out given my lack of understanding of their psychology as reflected in my design.
  - Edmond 13y ago
    Haha...the logo similarity is pure coincidence... Incidentally some time back I posted about the similarities between Google and Microsoft logos: https://news.ycombinator.com/item?id=6678308 https://news.ycombinator.com/item?id=6678308 :)
    - seanmcdirmid 13y ago
      With four colored boxes...I've seen our logo all over the place even before it was our logo :)

freyrs3 13y ago

> This is a problem with functional programming in general, it is fundamentally anti-human I would argue that the "anything goes" dynamic procedural languages ( like Ruby, Python ) are far more anti-human, in that human ability to reason about large masses of code scales orders of magnitude worse than in languages that provide a strong theoretic framework for reasoning about code.

Edmond 13y ago
Sure if it was easy for people to think functionally then functional programming is without a doubt more elegant. But elegance doesn't negate the fact that the reasoning model demanded by functional programming isn't friendly to the way we think. The elegance argument is something proponents always bring up, but it misses the point. While dynamic procedural languages have their problems, I think they work for the most part, hence their success Vis-à-vis functional languages. As far as the issue of scale, that's why modular constructs as added to manage large code bases.
- freyrs3 13y ago
  I don't know how you're coming to this result, but it /is/ easy for people to think functionally. You can teach intro-CS classes in both functional and imperative styles and generally they pick up both styles at the same rate. I've seen it year after year of teaching these courses. The myth that functional programming doesn't match human thought is just flat out FUD, there's no evidence to support it. The adoption of programming languages is more influenced by economic factors than informed by solid engineering.
  - Edmond 13y ago
    I wont argue about your experience in the class room but both styles of programming have been around for about the same length of time and yet their adoption rates speak volume. We can debate this ad infinitum and probably wont come to an agreement.
    - 13y ago

tikhonj 13y ago

I think that's a broad mischaraterization of functional programming. It is certainly not obvious a priori that people think procedurally. It certainly does not match my experience teaching programming to complete beginners--even concepts like mutable variables and loops are not particularity intuitive. People really like to think by analogy and think based on relations. Functional programming makes this much simpler by giving you simple abstractions and, crucially, letting you not worry about extraneous machine details. In a functional language, even the order your code gets evaluated is below your level of abstraction. Ultimately, functional programming lets you talk about what where imperative languages force you to talk about how. That's pro-human. It's exposing the underlying machine and computation--imperative programming, in a word--that's anti-human!

seanmcdirmid 13y ago
> People really like to think by analogy and think based on relations. People really like to think by analogy and metaphor. Go objects!
- JasonFruit 13y ago
  Go doesn't have objects.
deleted 13y ago
[deleted]
deleted 13y ago
[deleted]

andrewflnr 13y ago

Actually, machines are attuned to flat, unstructured lists of instructions, the polar opposite of functional programming. But when people wanted to think clearly, they invented math, of which FP is nearly the computational manifestation. You have the human-vs-machine thing exactly backwards. The reason we tend to think in imperative terms is one of familiarity: most of our first programming experiences are in languages that are (sometimes high-level, but still) descendants of assembly, because at first that was the only programming that existed: flat lists of instructions designed for a machine. Granted, if a human wants to describe a physical process, they will use procedural language. But computers are primarily about information, and we think about information in terms of relationships. That's exactly what FP is about: expressing computation in terms of relationships.

Edmond 13y ago
I agree that a Turing machine is imperative...when I refer to machines I am generally referring to an inflexible approach to solving problems, not so much how computers execute instructions. As humans I think we need the ability to be messy and imprecise in order to be creative. >The reason we tend to think in imperative terms is one of familiarity That's debatable given that both approaches have been around for about the same length of time with different outcomes in terms of adoption.
- codygman 13y ago
  > That's debatable given that both approaches have been around for about the same length of time with different outcomes in terms of adoption. If unix had been created in LISP or ML, I believe we might be in the opposite position. Though that hinges on a LISP unix being as successful as the C one.
  - mike_hearn 13y ago
    But before UNIX there was Symbolics, and Symbolics failed in the market whereas UNIX succeeded.

teamonkey 13y ago

> This is a problem with functional programming in general, it is fundamentally anti-human, people don't think functionally but rather procedurally. There was a study a while back[1] that showed non-programmers a series of statements of the sort, int a = 10; int b = 20; a = b; and asked them the value of a. It seemed that some people could not grasp even very basic fundamentals. The thing is, if you'd never programmed before but you HAD basic algebra knowledge, the third line above would have broken your brain. 10 =/= 20. You can't change the value of a, it's against everything you know! The point is, people don't think functionally or procedurally. Both of these programming styles are just learned behaviours, not basic human nature. [1] http://www.codinghorror.com/blog/2006/07/separating-programming-sheep-from-non-programming-goats.html http://www.codinghorror.com/blog/2006/07/separating-programm...