10 ms·

reads like an ode to Haskell/ML. while haskell/ML is beautiful, and i'd much prefer it if everyone did adopt it - it seems human nature is preferring languages

reads like an ode to Haskell/ML. while haskell/ML is beautiful, and i'd much prefer it if everyone did adopt it - it seems human nature is preferring languages such as C, Python, C# and Java, exactly due to their expressiveness and distance from the pure math side of things. maybe FP will be the future, but right now and considering everything is a stack machine that has ASM/C under the hood, things have to change on the hardware level to enable deep change in both our hardware and our curricula, which often produce "math is hard". it wouldn't hurt if the larger players put out mobile FP sdks. (i know we can program android in SCALA and that many folk wrote Haskell hooks for iOS, but it's not all very supported by the main players) if anything, dabbing into Haskell made me understand math better. our youngsters would benefit greatly from such a change and it'd boost things beyond what we can imagine today if more than 5% of the population could program. a low level FP styled non-gc`ed programming language would be interesting to see rise too. though haskell is making its way through the bushes, it's nooks and crannies leave a bit to be desired, esp. when complex software becomes extremely difficult to read by others, despite it's beauty and conciseness.

amelius 10y ago
> it seems human nature is preferring languages such as C, Python, C# and Java, exactly due to their expressiveness and distance from the pure math side of things I personally think humans prefer imperative languages because they are closer to the metal, and hence more predictable in terms of performance.
- taeric 10y ago
  Also closer to how most of us learn and are taught. Consider, I often tell my kids that they need a cup if they want water. I just as often have to change that to "go get a cup, and I'll get you water." Declarative seems to be natural at a desire level, but at an action level, imperative seems to be more common. I believe this is flipped for topics and actions that are well internalized. When my kids are older, I can just say "cup". If cups aren't in the right drawer, I have to provide imperative to where to check, though. And yes, all of this is anecdotal. YMMV. I'm highly interested if folks know of studies or counter examples.
  - hood_syntax 10y ago
    You're right that it's closer to how people are taught, but there's no reason we can't teach from the FP perspective. Consider the imperative cup_of_water get_water (cup_loc, water_loc) { cup = get_cup(cup_loc); return fill_cup(cup, water_loc); } or something like that, versus getWater :: CupLoc -> WaterLoc -> Cup Water getWater cupLoc waterLoc = fillCup (getCup cupLoc) waterLoc It's just a slightly different way of thinking about things.
    - hyperpape 10y ago
      There's nothing in either example that is intrinsically functional or imperative, they're just different syntax.
    - taeric 10y ago
      This is dodging things by all being symbolic. Which is well after the point my kids are at in these examples. I'm taking about my one year old. It is amazing how they can understand well before they can say words. Or read and write them. Sign language can be taught really early. Not sure what data that adds here. But, I believe that imperative makes sense because so much in life is imperative. Especially directions we give each other. For things that can be done symbolically, declarative can be a big boon. But it does seem to be the minority.
    - pjc50 10y ago
      Now audit each cup-filling in a database. (Easy in an imperative system, painful in a functional one where you have to start passing monads around and caring how many times the cup is constructed rather than how many cups you end up with.)
  - digi_owl 10y ago
    Or it could simply be that your kids have wrapped the imperatives in a object called cup. All this gets me thinking back to the micros and how they booted straight into a BASIC interpreter. In a sense while booting to a mouse (or touch) driven GUI helps with getting now common tasks done out of the box. That no mainstream OS ship with something that allows someone to sit down and instruct a computer similarly to how it was done back then seems to have turned modern personal computers into near appliances.
- godmodus 10y ago
  That's why a hardware change would be a step towards a change. If the metal was less von neumann and more Turing/number theoretical approach, it'd be a deep change. So far the limitation of what's practical were/are the driver of industry. And von neumann did solve a real problem they had back then. These days were facing a software engineering problem which is more high level, and most faculties are triaging the situation - but I can't really blame them. Many unis lack the funding for ground breaking experimental work - and the likes of Turing/von neumann/knuth/dijkstra et Al, only come once a generation.
- godmodus 10y ago
  not to mention they're battle tested. and C is predictable, period. no other language can come close bar ASM. even Rust has a long way to go before it matures to C11 levels - in terms of industry trust, community adoption and backtrack of delivering. but ill have to still admit ignorance to a greater understanding of Rust.
  - ianamartin 10y ago
    > and C is predictable, period. Really?
    - godmodus 10y ago
      If it's written spartan style, yes. If you go nuts with its dark corners things do get wierd. It's why it's a hard labour to write safely - and a contributing reason to JVM success. It's the mother of all, and abusing it in ways that make it unpredictable is more than likely.
      - kahnpro 10y ago
        If you have to add that qualifier, then is it really a predictable like language?
        godmodus 10y ago
        I don't see a problem with proper use of qualifiers. It has to be said that I'm a "right tool for the job" kind of man, and spend less time worrying about the perfect-ness of a language. Can't think of a better language to write crypto/network routing code with. Though a colleague did implement some mDNS craziness with java. Don't shoot me. Heh.
- Buttons840 10y ago
  I think once someone has done enough programming to understand or care about being closer to the metal, they prefer what they already know, which is usually imperative languages. I wonder which paradigm a total beginner would prefer? As a beginner they would not be influenced by "how the metal works" because they don't know or don't care. My guess is that beginners would prefer imperative languages as well, even though it has nothing to do with "the metal".
  - DigitalJack 10y ago
    My experience is that most software engineers don't really understand the hardware at all, so the idea that "how the hardware works" is influencing anything is a red-herring in my opinion. I say this as a hardware designer.
majewsky 10y ago
There is some italic text in there. Did you mean Haskell*/ML ? > a low level FP styled non-gc`ed programming language would be interesting to see rise too Sounds like Rust. If not, what do you think disqualifies it?
- godmodus 10y ago
  Yeah ur right about the asterisk. I'll change it when I get to a desktop. As to Rust, it looks awesome.e, really. I've personally havn't used it but have been watching it rise through the rank with greater momentum (and more serious projects) than haskell. I just don't know enough about it to have made a statement I could back. I've a few future projects that I could use it in.
  - __s 10y ago
    I've been using Rust for the past year. Lack of tail calls kind of hurt the FP side of it Here's 4 esoteric programming language implementations: https://github.com/serprex/oilrs https://github.com/serprex/oilrs https://github.com/serprex/inliners https://github.com/serprex/inliners https://github.com/serprex/NULL https://github.com/serprex/NULL https://github.com/serprex/Kelxquoia https://github.com/serprex/Kelxquoia I wouldn't call their implementations particularly functional. Linked Lists get a bit of a spotlight in FP but in Rust their ill advised. Option<Box<List<T>>> means they can't be shared, Option<Rc<List<T>>> can be overkill. For awhile I had some code which wanted to chain references along the stack, but issue is that in each recursive call the lifetime varies, but one can't put the lifetime of the reference in the type (each level of recursion has to carry an extra lifetime parameter) so I had to instead make a ListTrait<T>, have List<'a> carry an Option<&'a ListTrait>, but now that's a virtual pointer with a virtual table. Commit of replacing the code: https://github.com/serprex/lambdaski/commit/138217d5530b93a6161fe4f361ec895f7e302c2e#diff-40bb2a2af4768c6eb15c9e262b571d29L220 https://github.com/serprex/lambdaski/commit/138217d5530b93a6... . Was done by changing the code to not create copies (which had this russian doll lifetime pattern) but instead all use references to the string being parsed, thus once every reference had the same lifetime they could all be packaged into a single Vec<T>
ruslan_talpa 10y ago
I am not sure on which side of the flame war you are on :) How is being more distant from pure math result in things being more expressive (Java more expressive then Haskell) People will use whatever is more familiar (lazy), no one really wants to (put in the work and) learn something new. All of us have been learning the imperative way since childhood, that's why each new imperative programming language can be picked up in a week, but then we turn and say Haskell is hard and forget to consider that we've invested a lifetime in learning things like C/Java and gave FP a few weeks. Hardware does not need to change at all, Haskell works just fine as is. Complex software in Haskell is hard to read only for ppl that never got beyond "Learn You a Haskell" (i am also not that far along) (but i'll admit there is a tendency among Haskell developers to be more cleaver then it's needed with their code and unnecessarily cryptic). The solution to a complex problem is 100 time easier to read in Haskell then in any other language.
- godmodus 10y ago
  exactly why we need a change on the level of school curricula - and the lazy part of being human can't be avoided. it's that "maximal result/minimum effort YOLO" that's coded into our genes.
- godmodus 10y ago
  I stay away from flame wars and actively attempt to see the whole picture. My experience is my own, viewing students confront different languages and just looking at it all grow. I'm biased towards myself, heh. I certainly agree that haskell is awesome. And I know what you're Trying to say.. We're Sadly educated to prefer a certain syntax, and many programmers are still bad at math, bar a devoted and lucky core.
  - ruslan_talpa 10y ago
    I think it's a pity that whenever someone dives into haskell, in the first few tutorials/pages he immediately is show how this great beauty comes from math and category theory and how it's all connected and they get discouraged very fast (if they were not exposed too much to college level math). If you find the strength to ignore that for a bit in the beginning and find a path laid out by a professional developer, you can do amazing useful stuff without understanding the math behind it that would be quite hard to accomplish in other languages. Anyway, whoever thinks at diving into haskell, ignore everyone that says it's hard, don't look at math staff in the beginning, and don't try to do to much IO like reading/writing from files/db all over the place.
DonaldFisk 10y ago
> maybe FP will be the future Backus designed a functional programming language called FP: https://en.wikipedia.org/wiki/FP_(programming_language) https://en.wikipedia.org/wiki/FP_(programming_language) > a low level FP styled non-gc`ed programming language would be interesting to see rise too There are BitC (https://web.archive.org/web/20130815183427/http://www.bitc-lang.org/docs/bitc/spec.html https://web.archive.org/web/20130815183427/http://www.bitc-l...) and Rust which are reasonably close to what you want.
wangchow 10y ago
I think it's more about the underlying machine as opposed to a particular language implemented on top of Von Neumann architecture. For instance, we are constrained by the underlying machine regardless of which higher-level language we use, functional or otherwise. I started reading this book on functional languages and lambda calculus. It has some interesting notes on how to build language syntax on top of a purely-functional machine architecture (at least conceptually). Pretty interesting stuff: [An Introduction to Functional Programming Through Lambda Calculus](http://store.doverpublications.com/0486478831.html http://store.doverpublications.com/0486478831.html)
- gshubert17 10y ago
  Julian Bigelow, chief engineer of the Institute for Advanced Studies computer project (Von Neumann's first actual computer), stayed at the IAS after Von Neumann left for the AEC (and died in 1957) and believed the architecture was the limiting factor. "The modern high speed computer, impressive as its performance is from the point of view of absolute accomplishment, is from the point of view of getting the available logical equipment adequately engaged in the computation, very inefficient indeed." The individual components, despite being capable of operating continuously at high speed, "are interconnected in such a way that on the average almost all of them are waiting for one (or a very few of their number) to act. The average duty cycle of each cell is scandalously low." Julian Bigelow, quoted in George Dyson, "Turing's Cathedral", pg. 276
  - adwn 10y ago
    That's because they're universal, programmable computers. If you have a very specific, fixed task (e.g., matrix*vector multiplication), then you can build a chip in which a much higher number of transistors does useful work in each cycle. You won't be able to browse the web, watch a video, do your taxes, or program other computers with it, though.
- DigitalJack 10y ago
  I am naive when it comes to computation science, but doesn't the turing completeness of someting essentially mean you are not constrained? Perhaps constrained in efficiency, but not outcome.
lmm 10y ago
I think FP is on the up and up. OCaml and Haskell have seen a lot more interest in the last 5-10 years (despite both being 20+ years old), and I've been working in Scala full time for 6+ years now. There are still gaps and room for improvement to be sure, but I think progress is happening. Idris takes the best parts of Haskell and drops the laziness that was so problematic for performance. At the other end Rust is practically an ML-family language that offers low-level non-GC style. I don't think it's human nature that's kept less-functional languages popular so much as hardware limitations and business effects.
davexunit 10y ago
There is no future in a strict adherence to one programming paradigm. Any sufficiently large program will have parts that are expressed best in different paradigms. One part of a program wants to be functional, another imperative, another object-oriented, etc. We need less languages that make an opinionated statement about the one true way and the one true paradigm. A paradigm is a tool of expression, and we need to be able to use the right one when needed. We need general-purpose, extensible languages.
- nbz118 10y ago
  I completely agree with this. I've been doing professional Scala for about 7 years now and I have long moved past the phase of trying to make all my code "pure" and "functional". While I'd say my code always maintains a more functional feel than Java or C++, many problems are just more elegantly and efficiently solved with OOP and imperative/mutable designs.
- preordained 10y ago
  Yes. This is the software "engineer" answer. Nothing sacred, each choice is simply a trade off. Sometimes an FP lense is the best one to view and tackle the problem with, when it's not you use something else. You don't strain or try to unnaturaly shift the goal posts--you use something else.
  - hermitdev 10y ago
    Wholeheartedly agree with this. Right tool for the problem at hand, and sometimes that means using multiple tools (or paradigms). Incidentally, one of the things I like about Python, in that is so easily lets you mix paradigms such as FP & OOP. Certain use cases just don't naturally fit w/ a pure FP style, nor a pure OOP style, but sometimes a healthy mix of both is in order. One of the areas FP really wins is in ease to introducing parallelism. If all of your parallel functions are pure, introducing parallelism should be a non-issue. Results of a function only depend on the (non-global, immutable arguments and, possibly, immutable global state). Shared mutable state is the bane of all parallel programming. Shared mutable state necessitates locking of some form, and even experts get it wrong (and non-experts get it wrong very frequently) - personal experience, no citations.
max_ 10y ago
I would like to know your opinion on using FP methods on with languages like Python
- godmodus 10y ago
  I do it from time to time - and I like it. Works well for small functions/procedures. But try to use python beyond the pythonic way on a large scale and your in for a design challenge. But Im sure it'll be beautiful and you'll get much hate, as well as praise for it, heh. Usually though, when I write python, I keep it pythonic, mainly for the support and debugging efforts. The community's large code Base is pythonic and is designed to stitch together pythonically. Aslong as the API is pythonic, what lies underneath can be functional.
alimw 10y ago
"When Backus studied and publicized his function-level style of programming, his message was mostly misunderstood, as supporting the traditional functional programming style languages instead of his own FP and its successor FL." You may have fallen into this trap as described on https://en.wikipedia.org/wiki/Function-level_programming https://en.wikipedia.org/wiki/Function-level_programming.
Athas 10y ago
> reads like an ode to Haskell/ML. It may seem like that from the intro, and from how the text is frequently summarised, but a closer reading shows that what Backus proposes is almost as different from modern functional programming as it is from imperative programming. For example, Backus stresses the need for not naming parameters. This is a supported (if not universally liked) coding style in most modern functional languages, but the lambda calculus is fundamentally about naming parameters. The language that Backus proposes, FP, isn't really a lambda calculus-style language. It has more in familiar with APL or stack-based concatenative languages. > maybe FP will be the future, but right now and considering everything is a stack machine that has ASM/C under the hood, things have to change on the hardware level to enable deep change in both our hardware and our curricula You don't really need anything to change at the hardware. The hardware should stick to doing computation as well as physics permit, and then we can always come up with programming models that fit. I myself am working on a functional language (in the lambda calculus tradition) and an optimising compiler that generates pretty efficient GPU code[0]. GPUs are nothing like any reasonable mathematical tradition, but it turns out to be, if not easy, then reasonable to map a subset of functional programming (namely, array programming) to GPUs, and probably other parallel machines. This is because the programming model makes very few requirements of the runtime system, giving the compiler a lot of freedom to bridge the rather large conceptual divide between high-level array programming and massively hardware. Imperative languages don't really grant the compiler this freedom, because they impose very strict ordering requirements on when their component statements are executed. Automatically determining when such ordering can be ignored (to obtain parallelism) is very very hard. At the other extreme, a lazy functional language (like Haskell) requires a lot of flexibility at runtime to deal with thunks and spontaneous allocation, which also inhibits the compiler's ability to bridge the divide and generate efficient code. Related, but not strictly a language issue, is the dirty secret that many of the beloved functional algorithms and data structures are inherently sequential. It has been said (although I sadly don't remember by who) that "the linked list is the GOTO of functional programming". What is meant is that the use of linked lists enforces a strict sequential ordering and fiddling around with cons cells, instead of focusing on the overall structure of the computation. For this reason, parallel functional languages generally do not have linked lists as their primitive type, but use arrays instead, and have map/reduce/scan/etc as language primitives rather than library functions. [0]: https://futhark-lang.org https://futhark-lang.org
coffeemug 10y ago
The problem with ML is that edit distance between two similar programs is much higher than C/Python/Java. You have to change a lot more to go from program A to a similar program A' than you would in an imperative language. Empirically, people really don't like that property.
- Confusion 10y ago
  I find this an intriguing proposition. Is there experimental evidence, both for 'the edit distance is larger' and 'people don't like that property'?
  - SamReidHughes 10y ago
    Here's some. I used to be extremely comfortable with Haskell, but things didn't go well when I tried using it for the first online programming contest I ever did. It was just too slow to write code in, compared to C++, which I hadn't used for years. Being able to plop down variables in front of a for loop, or print statements, or extra conditionals to handle some corner cases or break out of a loop, and to just casually mutate local variables, makes writing out a solution go a lot faster, with a lot less mental overhead from having to janitor variables between maps, folds, and whatnot.
KirinDave 10y ago
> it seems human nature is preferring languages such as C, Python, C# and Java, exactly due to their expressiveness and distance from the pure math side of things. People say this, but... I'm really not sure this is the case. When you teach people these other paradigms they take to them quickly and naturally and find them good for some things and bad for others, just like how we swap around all kinds of language and environment decisions. We keep offering this fiction to ourselves: Environment ______ for programming is special. We do it with editors, we do it with languages, we do it with compilers. In reality, none of them are. They're incrementally better in some ways, perhaps worse in others. We are past the era of mighty breakthroughs and shocking new approaches in the realm of pure expressions. We're now in the era built on those original successes: where programs train themselves from data. Which is the endgame of reusable code, of course. What we're doing now is increasingly mapping back down from very powerful and abstract languages into rather small sub languages. The current crop of successful languages (Clojure, Scala, C#, F#, Kotlin, JavaScript, Python, Ruby, Haskell, OCaml) all have one thing in quietly in common: They have a lot of tools to model domain languages without a lot of syntactic and cognitive overhead.
dispose13432 10y ago
Me question is if there are significant large codebases built in pure functional languages, and if there are statistics as to which ones have fewer bugs - functional or imperative?
- DigitalJack 10y ago
  I think the concern is less about bugs and more about productivity.
sonyandy 10y ago
I'd be very interested in a low level FP without GC (including reference counting), as well. I believe a major difficulty is how do deal with closures. Obvious solutions include region inference and copying the closure, both with obvious downsides. Another difficultly is how to deal with structure sharing, a technique required for the efficiency of almost all functional data structures.
- thomasrynne 10y ago
  I have been thinking about this lately and found this last week http://www.ats-lang.org http://www.ats-lang.org
PopsiclePete 10y ago
For me, my preference for languages like C and Go (work and fun) and Java/C# (work only) has nothing to do with "expressiveness" - in fact, I can't even think of a language less expressive than Java - but with the fundamental truth that computers store state and programming is about modifying that state. And when I play around with Haskell or any other functional language, I love the expressiveness, but I hate how abstracted away the actual state modifications are and how we like to pretend we live in some "pure" mathematical land without state (that sadly doesn't exist). I love the beauty of Haskell but hate having to muck around with monads - I just want to poke that memory address right there and flip that bit thank you very much.

amelius 10y ago

> it seems human nature is preferring languages such as C, Python, C# and Java, exactly due to their expressiveness and distance from the pure math side of things I personally think humans prefer imperative languages because they are closer to the metal, and hence more predictable in terms of performance.

taeric 10y ago
Also closer to how most of us learn and are taught. Consider, I often tell my kids that they need a cup if they want water. I just as often have to change that to "go get a cup, and I'll get you water." Declarative seems to be natural at a desire level, but at an action level, imperative seems to be more common. I believe this is flipped for topics and actions that are well internalized. When my kids are older, I can just say "cup". If cups aren't in the right drawer, I have to provide imperative to where to check, though. And yes, all of this is anecdotal. YMMV. I'm highly interested if folks know of studies or counter examples.
- hood_syntax 10y ago
  You're right that it's closer to how people are taught, but there's no reason we can't teach from the FP perspective. Consider the imperative cup_of_water get_water (cup_loc, water_loc) { cup = get_cup(cup_loc); return fill_cup(cup, water_loc); } or something like that, versus getWater :: CupLoc -> WaterLoc -> Cup Water getWater cupLoc waterLoc = fillCup (getCup cupLoc) waterLoc It's just a slightly different way of thinking about things.
  - hyperpape 10y ago
    There's nothing in either example that is intrinsically functional or imperative, they're just different syntax.
  - taeric 10y ago
    This is dodging things by all being symbolic. Which is well after the point my kids are at in these examples. I'm taking about my one year old. It is amazing how they can understand well before they can say words. Or read and write them. Sign language can be taught really early. Not sure what data that adds here. But, I believe that imperative makes sense because so much in life is imperative. Especially directions we give each other. For things that can be done symbolically, declarative can be a big boon. But it does seem to be the minority.
  - pjc50 10y ago
    Now audit each cup-filling in a database. (Easy in an imperative system, painful in a functional one where you have to start passing monads around and caring how many times the cup is constructed rather than how many cups you end up with.)
- digi_owl 10y ago
  Or it could simply be that your kids have wrapped the imperatives in a object called cup. All this gets me thinking back to the micros and how they booted straight into a BASIC interpreter. In a sense while booting to a mouse (or touch) driven GUI helps with getting now common tasks done out of the box. That no mainstream OS ship with something that allows someone to sit down and instruct a computer similarly to how it was done back then seems to have turned modern personal computers into near appliances.
godmodus 10y ago
That's why a hardware change would be a step towards a change. If the metal was less von neumann and more Turing/number theoretical approach, it'd be a deep change. So far the limitation of what's practical were/are the driver of industry. And von neumann did solve a real problem they had back then. These days were facing a software engineering problem which is more high level, and most faculties are triaging the situation - but I can't really blame them. Many unis lack the funding for ground breaking experimental work - and the likes of Turing/von neumann/knuth/dijkstra et Al, only come once a generation.
godmodus 10y ago
not to mention they're battle tested. and C is predictable, period. no other language can come close bar ASM. even Rust has a long way to go before it matures to C11 levels - in terms of industry trust, community adoption and backtrack of delivering. but ill have to still admit ignorance to a greater understanding of Rust.
- ianamartin 10y ago
  > and C is predictable, period. Really?
  - godmodus 10y ago
    If it's written spartan style, yes. If you go nuts with its dark corners things do get wierd. It's why it's a hard labour to write safely - and a contributing reason to JVM success. It's the mother of all, and abusing it in ways that make it unpredictable is more than likely.
    - kahnpro 10y ago
      If you have to add that qualifier, then is it really a predictable like language?
      - godmodus 10y ago
        I don't see a problem with proper use of qualifiers. It has to be said that I'm a "right tool for the job" kind of man, and spend less time worrying about the perfect-ness of a language. Can't think of a better language to write crypto/network routing code with. Though a colleague did implement some mDNS craziness with java. Don't shoot me. Heh.
Buttons840 10y ago
I think once someone has done enough programming to understand or care about being closer to the metal, they prefer what they already know, which is usually imperative languages. I wonder which paradigm a total beginner would prefer? As a beginner they would not be influenced by "how the metal works" because they don't know or don't care. My guess is that beginners would prefer imperative languages as well, even though it has nothing to do with "the metal".
- DigitalJack 10y ago
  My experience is that most software engineers don't really understand the hardware at all, so the idea that "how the hardware works" is influencing anything is a red-herring in my opinion. I say this as a hardware designer.

majewsky 10y ago

There is some italic text in there. Did you mean Haskell*/ML ? > a low level FP styled non-gc`ed programming language would be interesting to see rise too Sounds like Rust. If not, what do you think disqualifies it?

godmodus 10y ago
Yeah ur right about the asterisk. I'll change it when I get to a desktop. As to Rust, it looks awesome.e, really. I've personally havn't used it but have been watching it rise through the rank with greater momentum (and more serious projects) than haskell. I just don't know enough about it to have made a statement I could back. I've a few future projects that I could use it in.
- __s 10y ago
  I've been using Rust for the past year. Lack of tail calls kind of hurt the FP side of it Here's 4 esoteric programming language implementations: https://github.com/serprex/oilrs https://github.com/serprex/oilrs https://github.com/serprex/inliners https://github.com/serprex/inliners https://github.com/serprex/NULL https://github.com/serprex/NULL https://github.com/serprex/Kelxquoia https://github.com/serprex/Kelxquoia I wouldn't call their implementations particularly functional. Linked Lists get a bit of a spotlight in FP but in Rust their ill advised. Option<Box<List<T>>> means they can't be shared, Option<Rc<List<T>>> can be overkill. For awhile I had some code which wanted to chain references along the stack, but issue is that in each recursive call the lifetime varies, but one can't put the lifetime of the reference in the type (each level of recursion has to carry an extra lifetime parameter) so I had to instead make a ListTrait<T>, have List<'a> carry an Option<&'a ListTrait>, but now that's a virtual pointer with a virtual table. Commit of replacing the code: https://github.com/serprex/lambdaski/commit/138217d5530b93a6161fe4f361ec895f7e302c2e#diff-40bb2a2af4768c6eb15c9e262b571d29L220 https://github.com/serprex/lambdaski/commit/138217d5530b93a6... . Was done by changing the code to not create copies (which had this russian doll lifetime pattern) but instead all use references to the string being parsed, thus once every reference had the same lifetime they could all be packaged into a single Vec<T>

ruslan_talpa 10y ago

I am not sure on which side of the flame war you are on :) How is being more distant from pure math result in things being more expressive (Java more expressive then Haskell) People will use whatever is more familiar (lazy), no one really wants to (put in the work and) learn something new. All of us have been learning the imperative way since childhood, that's why each new imperative programming language can be picked up in a week, but then we turn and say Haskell is hard and forget to consider that we've invested a lifetime in learning things like C/Java and gave FP a few weeks. Hardware does not need to change at all, Haskell works just fine as is. Complex software in Haskell is hard to read only for ppl that never got beyond "Learn You a Haskell" (i am also not that far along) (but i'll admit there is a tendency among Haskell developers to be more cleaver then it's needed with their code and unnecessarily cryptic). The solution to a complex problem is 100 time easier to read in Haskell then in any other language.

godmodus 10y ago
exactly why we need a change on the level of school curricula - and the lazy part of being human can't be avoided. it's that "maximal result/minimum effort YOLO" that's coded into our genes.
godmodus 10y ago
I stay away from flame wars and actively attempt to see the whole picture. My experience is my own, viewing students confront different languages and just looking at it all grow. I'm biased towards myself, heh. I certainly agree that haskell is awesome. And I know what you're Trying to say.. We're Sadly educated to prefer a certain syntax, and many programmers are still bad at math, bar a devoted and lucky core.
- ruslan_talpa 10y ago
  I think it's a pity that whenever someone dives into haskell, in the first few tutorials/pages he immediately is show how this great beauty comes from math and category theory and how it's all connected and they get discouraged very fast (if they were not exposed too much to college level math). If you find the strength to ignore that for a bit in the beginning and find a path laid out by a professional developer, you can do amazing useful stuff without understanding the math behind it that would be quite hard to accomplish in other languages. Anyway, whoever thinks at diving into haskell, ignore everyone that says it's hard, don't look at math staff in the beginning, and don't try to do to much IO like reading/writing from files/db all over the place.

DonaldFisk 10y ago

> maybe FP will be the future Backus designed a functional programming language called FP: https://en.wikipedia.org/wiki/FP_(programming_language) https://en.wikipedia.org/wiki/FP_(programming_language) > a low level FP styled non-gc`ed programming language would be interesting to see rise too There are BitC (https://web.archive.org/web/20130815183427/http://www.bitc-lang.org/docs/bitc/spec.html https://web.archive.org/web/20130815183427/http://www.bitc-l...) and Rust which are reasonably close to what you want.

wangchow 10y ago

I think it's more about the underlying machine as opposed to a particular language implemented on top of Von Neumann architecture. For instance, we are constrained by the underlying machine regardless of which higher-level language we use, functional or otherwise. I started reading this book on functional languages and lambda calculus. It has some interesting notes on how to build language syntax on top of a purely-functional machine architecture (at least conceptually). Pretty interesting stuff: [An Introduction to Functional Programming Through Lambda Calculus](http://store.doverpublications.com/0486478831.html http://store.doverpublications.com/0486478831.html)

gshubert17 10y ago
Julian Bigelow, chief engineer of the Institute for Advanced Studies computer project (Von Neumann's first actual computer), stayed at the IAS after Von Neumann left for the AEC (and died in 1957) and believed the architecture was the limiting factor. "The modern high speed computer, impressive as its performance is from the point of view of absolute accomplishment, is from the point of view of getting the available logical equipment adequately engaged in the computation, very inefficient indeed." The individual components, despite being capable of operating continuously at high speed, "are interconnected in such a way that on the average almost all of them are waiting for one (or a very few of their number) to act. The average duty cycle of each cell is scandalously low." Julian Bigelow, quoted in George Dyson, "Turing's Cathedral", pg. 276
- adwn 10y ago
  That's because they're universal, programmable computers. If you have a very specific, fixed task (e.g., matrix*vector multiplication), then you can build a chip in which a much higher number of transistors does useful work in each cycle. You won't be able to browse the web, watch a video, do your taxes, or program other computers with it, though.
DigitalJack 10y ago
I am naive when it comes to computation science, but doesn't the turing completeness of someting essentially mean you are not constrained? Perhaps constrained in efficiency, but not outcome.

lmm 10y ago

I think FP is on the up and up. OCaml and Haskell have seen a lot more interest in the last 5-10 years (despite both being 20+ years old), and I've been working in Scala full time for 6+ years now. There are still gaps and room for improvement to be sure, but I think progress is happening. Idris takes the best parts of Haskell and drops the laziness that was so problematic for performance. At the other end Rust is practically an ML-family language that offers low-level non-GC style. I don't think it's human nature that's kept less-functional languages popular so much as hardware limitations and business effects.

davexunit 10y ago

There is no future in a strict adherence to one programming paradigm. Any sufficiently large program will have parts that are expressed best in different paradigms. One part of a program wants to be functional, another imperative, another object-oriented, etc. We need less languages that make an opinionated statement about the one true way and the one true paradigm. A paradigm is a tool of expression, and we need to be able to use the right one when needed. We need general-purpose, extensible languages.

nbz118 10y ago
I completely agree with this. I've been doing professional Scala for about 7 years now and I have long moved past the phase of trying to make all my code "pure" and "functional". While I'd say my code always maintains a more functional feel than Java or C++, many problems are just more elegantly and efficiently solved with OOP and imperative/mutable designs.
preordained 10y ago
Yes. This is the software "engineer" answer. Nothing sacred, each choice is simply a trade off. Sometimes an FP lense is the best one to view and tackle the problem with, when it's not you use something else. You don't strain or try to unnaturaly shift the goal posts--you use something else.
- hermitdev 10y ago
  Wholeheartedly agree with this. Right tool for the problem at hand, and sometimes that means using multiple tools (or paradigms). Incidentally, one of the things I like about Python, in that is so easily lets you mix paradigms such as FP & OOP. Certain use cases just don't naturally fit w/ a pure FP style, nor a pure OOP style, but sometimes a healthy mix of both is in order. One of the areas FP really wins is in ease to introducing parallelism. If all of your parallel functions are pure, introducing parallelism should be a non-issue. Results of a function only depend on the (non-global, immutable arguments and, possibly, immutable global state). Shared mutable state is the bane of all parallel programming. Shared mutable state necessitates locking of some form, and even experts get it wrong (and non-experts get it wrong very frequently) - personal experience, no citations.

max_ 10y ago

I would like to know your opinion on using FP methods on with languages like Python

godmodus 10y ago
I do it from time to time - and I like it. Works well for small functions/procedures. But try to use python beyond the pythonic way on a large scale and your in for a design challenge. But Im sure it'll be beautiful and you'll get much hate, as well as praise for it, heh. Usually though, when I write python, I keep it pythonic, mainly for the support and debugging efforts. The community's large code Base is pythonic and is designed to stitch together pythonically. Aslong as the API is pythonic, what lies underneath can be functional.

alimw 10y ago

"When Backus studied and publicized his function-level style of programming, his message was mostly misunderstood, as supporting the traditional functional programming style languages instead of his own FP and its successor FL." You may have fallen into this trap as described on https://en.wikipedia.org/wiki/Function-level_programming https://en.wikipedia.org/wiki/Function-level_programming.

Athas 10y ago

> reads like an ode to Haskell/ML. It may seem like that from the intro, and from how the text is frequently summarised, but a closer reading shows that what Backus proposes is almost as different from modern functional programming as it is from imperative programming. For example, Backus stresses the need for not naming parameters. This is a supported (if not universally liked) coding style in most modern functional languages, but the lambda calculus is fundamentally about naming parameters. The language that Backus proposes, FP, isn't really a lambda calculus-style language. It has more in familiar with APL or stack-based concatenative languages. > maybe FP will be the future, but right now and considering everything is a stack machine that has ASM/C under the hood, things have to change on the hardware level to enable deep change in both our hardware and our curricula You don't really need anything to change at the hardware. The hardware should stick to doing computation as well as physics permit, and then we can always come up with programming models that fit. I myself am working on a functional language (in the lambda calculus tradition) and an optimising compiler that generates pretty efficient GPU code[0]. GPUs are nothing like any reasonable mathematical tradition, but it turns out to be, if not easy, then reasonable to map a subset of functional programming (namely, array programming) to GPUs, and probably other parallel machines. This is because the programming model makes very few requirements of the runtime system, giving the compiler a lot of freedom to bridge the rather large conceptual divide between high-level array programming and massively hardware. Imperative languages don't really grant the compiler this freedom, because they impose very strict ordering requirements on when their component statements are executed. Automatically determining when such ordering can be ignored (to obtain parallelism) is very very hard. At the other extreme, a lazy functional language (like Haskell) requires a lot of flexibility at runtime to deal with thunks and spontaneous allocation, which also inhibits the compiler's ability to bridge the divide and generate efficient code. Related, but not strictly a language issue, is the dirty secret that many of the beloved functional algorithms and data structures are inherently sequential. It has been said (although I sadly don't remember by who) that "the linked list is the GOTO of functional programming". What is meant is that the use of linked lists enforces a strict sequential ordering and fiddling around with cons cells, instead of focusing on the overall structure of the computation. For this reason, parallel functional languages generally do not have linked lists as their primitive type, but use arrays instead, and have map/reduce/scan/etc as language primitives rather than library functions. [0]: https://futhark-lang.org https://futhark-lang.org

coffeemug 10y ago

The problem with ML is that edit distance between two similar programs is much higher than C/Python/Java. You have to change a lot more to go from program A to a similar program A' than you would in an imperative language. Empirically, people really don't like that property.

Confusion 10y ago
I find this an intriguing proposition. Is there experimental evidence, both for 'the edit distance is larger' and 'people don't like that property'?
- SamReidHughes 10y ago
  Here's some. I used to be extremely comfortable with Haskell, but things didn't go well when I tried using it for the first online programming contest I ever did. It was just too slow to write code in, compared to C++, which I hadn't used for years. Being able to plop down variables in front of a for loop, or print statements, or extra conditionals to handle some corner cases or break out of a loop, and to just casually mutate local variables, makes writing out a solution go a lot faster, with a lot less mental overhead from having to janitor variables between maps, folds, and whatnot.

KirinDave 10y ago

> it seems human nature is preferring languages such as C, Python, C# and Java, exactly due to their expressiveness and distance from the pure math side of things. People say this, but... I'm really not sure this is the case. When you teach people these other paradigms they take to them quickly and naturally and find them good for some things and bad for others, just like how we swap around all kinds of language and environment decisions. We keep offering this fiction to ourselves: Environment ______ for programming is special. We do it with editors, we do it with languages, we do it with compilers. In reality, none of them are. They're incrementally better in some ways, perhaps worse in others. We are past the era of mighty breakthroughs and shocking new approaches in the realm of pure expressions. We're now in the era built on those original successes: where programs train themselves from data. Which is the endgame of reusable code, of course. What we're doing now is increasingly mapping back down from very powerful and abstract languages into rather small sub languages. The current crop of successful languages (Clojure, Scala, C#, F#, Kotlin, JavaScript, Python, Ruby, Haskell, OCaml) all have one thing in quietly in common: They have a lot of tools to model domain languages without a lot of syntactic and cognitive overhead.

dispose13432 10y ago

Me question is if there are significant large codebases built in pure functional languages, and if there are statistics as to which ones have fewer bugs - functional or imperative?

DigitalJack 10y ago
I think the concern is less about bugs and more about productivity.

sonyandy 10y ago

I'd be very interested in a low level FP without GC (including reference counting), as well. I believe a major difficulty is how do deal with closures. Obvious solutions include region inference and copying the closure, both with obvious downsides. Another difficultly is how to deal with structure sharing, a technique required for the efficiency of almost all functional data structures.

thomasrynne 10y ago
I have been thinking about this lately and found this last week http://www.ats-lang.org http://www.ats-lang.org

PopsiclePete 10y ago

For me, my preference for languages like C and Go (work and fun) and Java/C# (work only) has nothing to do with "expressiveness" - in fact, I can't even think of a language less expressive than Java - but with the fundamental truth that computers store state and programming is about modifying that state. And when I play around with Haskell or any other functional language, I love the expressiveness, but I hate how abstracted away the actual state modifications are and how we like to pretend we live in some "pure" mathematical land without state (that sadly doesn't exist). I love the beauty of Haskell but hate having to muck around with monads - I just want to poke that memory address right there and flip that bit thank you very much.