11 ms·

I feel like "industry" doesn't really want functional style programming to take over. Languages like OCaml provide really great speed while having also utilizin

by cheepin 12y ago

I feel like "industry" doesn't really want functional style programming to take over. Languages like OCaml provide really great speed while having also utilizing a relatively high abstraction level, while Lisp may not have as much speed but it takes your brain on a journey to another dimension. However, in practice, people seem to just want "C with Lambdas" languages like Go.

aortega 12y ago
You know when toddlers try to put a round peg in a square hole? that's how it feels using functional programming in a turing-machine-like CPU. It just don't fit.
- nnq 12y ago
  If you are far away from the peg and the hole, you use a robotic arm with high strength and poor sensors, and you have blurry vision (this would be the equivalent of the mindset of a high level programmer that lives far away from actual hardware, and I "ashamefully" include myself here), all pegs are pegs, all holes are holes, and the trusty robotic arm dutifully forces any peg into any hole, regardless of their shape :) When you eyes and mind swim in weird Javascript architectures all day, with 70% of stuff happening in the browser and the other half in a high level server-side language VM, monads in Haskell don't feel any less natural than anything else. That's why you see a lot of things like 'lisp to javascript' or 'haskell to javascript' compilers, because at this level, so far away from the actual hardware, the shapes of the pegs and holes don't matter that much (because trusty VMs fit anything into anything) and they are too blurred to distinguish anyway...
  - pekk 12y ago
    They do matter because they affect your control of resource use. We can't just hand-wave away memory issues in Haskell
- deleted 12y ago
  [deleted]
- antimagic 12y ago
  "Monads: fitting square pegs in round holes since 1991"
nnq 12y ago
Yeah, this is why I'd bet a lot on Go's success. The nice thing is that once you get "C with lambdas" most of the FP abstractions can be brought in. ...what "industry" doesn't like is "deep thinking" in general and anything else that can make programmers less replaceable and interchangeable. The fun thing will be when they'll realize that this is exactly what FP can bring :) ...less side-effects means less time for a programmer to "load a codebase-part into his working memory" and start working productively on a new project he's never seen before. And as a programmer too I tend to like languages that make me replaceable: it's always fun to be able to jump from one project to another and be able to quickly "load it in your mind". Paradoxically, both "retarded OOP" languages like Java, "retarded dynamic" languages like Javascript and "fundamentalist" languages like Haskell give you this. Anything in between, like Ruby or Lisp, forces you to first to load someone else's pseudo-DSL into your mind before being able to start doing productive work on a new project. Dunno about "hybrids" like Scala though... maybe they are a solution, maybe not. EDIT: 'more' -> 'less' in first sentence, sorry... dunno who upvoted before the edit as the message gets kind of reversed :)
emsy 12y ago
This is probably going to be unpopular: My main problem with most functional languages is that they encourage cryptic code. From the tutorials I've read Lisp seemed somewhat readable, but the tutorials encouraged me to use list comprehension all over the place because it's so convenient. I need to decrypt all the map zip range calls in order to grasp what's happening. Disclaimer: I don't know if Lisp is used like this in a productive environment. Haskell is often described as "elegant" (Here for instance: http://www.haskell.org/haskellwiki/Why_Haskell_matters#Elegance http://www.haskell.org/haskellwiki/Why_Haskell_matters#Elega...). To me, the examples are far from elegant. They just prove how much functionality one can cramp into an operator. But if I have to decrypt code in order to understand it then the language does it wrong. Math works like that and I never understood why they called variables "x" instead of "potatoes" or "time". It's simply non-descriptive. I don't know if you can write code that is as descriptive as code from an imperative language, but the FP community doesn't encourage it either.
- throwaway8972d9 12y ago
  User-defined, powerful operators are the most important feature that make programming in Haskell feel so foreign. Yet, since they often require the programmer to sort of grasp a model of the thing the program is trying to accomplish, once you understand the operators (e.g. parser combinators) you have a rather deep understanding of the foundation for this particular program and the rest of the code is expressed very concisely and (sometimes) reasoned about easily. Regarding the short variable names in math: They are supposed to be written and, more importantly, manipulated by hand and so short notation is very important.
  - emsy 12y ago
    This reply goes to axman6 as well: I for one, write code under the assumption that the reader will have to decrypt it in order to understand it. Therefore I postpone implementation details until the very end. This leads to code that outlines the logic in a fairly readable manner. Of course the implementation details are still code, but at that point there is so little code that you will understand it in no time. The Haskell examples of elegance I've seen so far seem to cramp so much responsibilities in so little code, yet nobody seems to bother about the Single Responsibility Principle. I like operator overloading, but I use them for implementation details, not to keep the number of lines small. The downside is that I have a deeply nested programming structure, which can be unfamiliar for people who churn out 500 lines of bare implementation details in one function. My criticism towards math goes further than variable naming. The language of math is non-descriptive and anyone accepts it with the reasons that: a) That's how it's always been. b) It's short and once you get used to it it's easy. But this just keeps people who struggle with the language of math to embrace and love mathematics. I don't say I have a better solution, but I say that we can get in programming right what's wrong in math: a descriptive language with a low entrance barrier.
pjmlp 12y ago
> However, in practice, people seem to just want "C with Lambdas" languages like Go. Most likely because that is what is desired by companies that see developers as replaceable cogs, that they can change at will and off-shore to far away galaxies. Languages with better expressive power require people with skillets they aren't willing to pay for and harder to replace.
CmonDev 12y ago
The "industry" took OCaml and built F# to make it possible to leverage more of existing libraries and frameworks and make it more approachable - the thing still did not take off. Unfortunately the tools are still missing (e.g. automated refactoring). The academics who are fond of functional languages unfortunately don't like real-world messy things, such as proper IDE support. I personally would have chosen F# over C# had ReSharper for it been available. But not even Roslyn is...
- pjmlp 12y ago
  > the thing still did not take off. Just look around in the finance and insurance sector for data modeling. Although developers aren't writing full stack applications in OCaml and F#, they surely are writing kernel modules of the applications.
  - CmonDev 12y ago
    "Just look around in the finance and insurance sector for data modeling." That is a very narrow niche.
    - pjmlp 12y ago
      So what?! It is a very profitable one where the languages are currently being used in the industry. I bet they get more used and generate more revenue, than typical Go startup projects that get upvoted here all the time.

by cheepin 12y ago

aortega 12y ago

You know when toddlers try to put a round peg in a square hole? that's how it feels using functional programming in a turing-machine-like CPU. It just don't fit.

nnq 12y ago
If you are far away from the peg and the hole, you use a robotic arm with high strength and poor sensors, and you have blurry vision (this would be the equivalent of the mindset of a high level programmer that lives far away from actual hardware, and I "ashamefully" include myself here), all pegs are pegs, all holes are holes, and the trusty robotic arm dutifully forces any peg into any hole, regardless of their shape :) When you eyes and mind swim in weird Javascript architectures all day, with 70% of stuff happening in the browser and the other half in a high level server-side language VM, monads in Haskell don't feel any less natural than anything else. That's why you see a lot of things like 'lisp to javascript' or 'haskell to javascript' compilers, because at this level, so far away from the actual hardware, the shapes of the pegs and holes don't matter that much (because trusty VMs fit anything into anything) and they are too blurred to distinguish anyway...
- pekk 12y ago
  They do matter because they affect your control of resource use. We can't just hand-wave away memory issues in Haskell
deleted 12y ago
[deleted]
antimagic 12y ago
"Monads: fitting square pegs in round holes since 1991"

nnq 12y ago

Yeah, this is why I'd bet a lot on Go's success. The nice thing is that once you get "C with lambdas" most of the FP abstractions can be brought in. ...what "industry" doesn't like is "deep thinking" in general and anything else that can make programmers less replaceable and interchangeable. The fun thing will be when they'll realize that this is exactly what FP can bring :) ...less side-effects means less time for a programmer to "load a codebase-part into his working memory" and start working productively on a new project he's never seen before. And as a programmer too I tend to like languages that make me replaceable: it's always fun to be able to jump from one project to another and be able to quickly "load it in your mind". Paradoxically, both "retarded OOP" languages like Java, "retarded dynamic" languages like Javascript and "fundamentalist" languages like Haskell give you this. Anything in between, like Ruby or Lisp, forces you to first to load someone else's pseudo-DSL into your mind before being able to start doing productive work on a new project. Dunno about "hybrids" like Scala though... maybe they are a solution, maybe not. EDIT: 'more' -> 'less' in first sentence, sorry... dunno who upvoted before the edit as the message gets kind of reversed :)

emsy 12y ago

This is probably going to be unpopular: My main problem with most functional languages is that they encourage cryptic code. From the tutorials I've read Lisp seemed somewhat readable, but the tutorials encouraged me to use list comprehension all over the place because it's so convenient. I need to decrypt all the map zip range calls in order to grasp what's happening. Disclaimer: I don't know if Lisp is used like this in a productive environment. Haskell is often described as "elegant" (Here for instance: http://www.haskell.org/haskellwiki/Why_Haskell_matters#Elegance http://www.haskell.org/haskellwiki/Why_Haskell_matters#Elega...). To me, the examples are far from elegant. They just prove how much functionality one can cramp into an operator. But if I have to decrypt code in order to understand it then the language does it wrong. Math works like that and I never understood why they called variables "x" instead of "potatoes" or "time". It's simply non-descriptive. I don't know if you can write code that is as descriptive as code from an imperative language, but the FP community doesn't encourage it either.

throwaway8972d9 12y ago
User-defined, powerful operators are the most important feature that make programming in Haskell feel so foreign. Yet, since they often require the programmer to sort of grasp a model of the thing the program is trying to accomplish, once you understand the operators (e.g. parser combinators) you have a rather deep understanding of the foundation for this particular program and the rest of the code is expressed very concisely and (sometimes) reasoned about easily. Regarding the short variable names in math: They are supposed to be written and, more importantly, manipulated by hand and so short notation is very important.
- emsy 12y ago
  This reply goes to axman6 as well: I for one, write code under the assumption that the reader will have to decrypt it in order to understand it. Therefore I postpone implementation details until the very end. This leads to code that outlines the logic in a fairly readable manner. Of course the implementation details are still code, but at that point there is so little code that you will understand it in no time. The Haskell examples of elegance I've seen so far seem to cramp so much responsibilities in so little code, yet nobody seems to bother about the Single Responsibility Principle. I like operator overloading, but I use them for implementation details, not to keep the number of lines small. The downside is that I have a deeply nested programming structure, which can be unfamiliar for people who churn out 500 lines of bare implementation details in one function. My criticism towards math goes further than variable naming. The language of math is non-descriptive and anyone accepts it with the reasons that: a) That's how it's always been. b) It's short and once you get used to it it's easy. But this just keeps people who struggle with the language of math to embrace and love mathematics. I don't say I have a better solution, but I say that we can get in programming right what's wrong in math: a descriptive language with a low entrance barrier.

pjmlp 12y ago

> However, in practice, people seem to just want "C with Lambdas" languages like Go. Most likely because that is what is desired by companies that see developers as replaceable cogs, that they can change at will and off-shore to far away galaxies. Languages with better expressive power require people with skillets they aren't willing to pay for and harder to replace.

CmonDev 12y ago

The "industry" took OCaml and built F# to make it possible to leverage more of existing libraries and frameworks and make it more approachable - the thing still did not take off. Unfortunately the tools are still missing (e.g. automated refactoring). The academics who are fond of functional languages unfortunately don't like real-world messy things, such as proper IDE support. I personally would have chosen F# over C# had ReSharper for it been available. But not even Roslyn is...

pjmlp 12y ago
> the thing still did not take off. Just look around in the finance and insurance sector for data modeling. Although developers aren't writing full stack applications in OCaml and F#, they surely are writing kernel modules of the applications.
- CmonDev 12y ago
  "Just look around in the finance and insurance sector for data modeling." That is a very narrow niche.
  - pjmlp 12y ago
    So what?! It is a very profitable one where the languages are currently being used in the industry. I bet they get more used and generate more revenue, than typical Go startup projects that get upvoted here all the time.