4 ms·

Functional programming is inscrutable by most. Berkeley uses LISP as a flunk out class to weed out freshman. I find it odd that given in the physical world peo

by mybrid 10y ago

Functional programming is inscrutable by most. Berkeley uses LISP as a flunk out class to weed out freshman. I find it odd that given in the physical world people require different shoe sizes for different feet that in the intellectual world people believe one size fits all, or that there is ultimately a single style of code that is comprehensible. Do you really believe our brains are all the same? The functional programming crowd will always play a minor roll in human programming and not because as you suggest, you are all superior. But rather it has to do with how brains differ. In fact I think the very real, emotional, visceral reaction people have to functional programming is key. People who love it, love it. Everyone else is completely demotivated by it. Lost in sets of parenthesis as the say. There is little middle ground. The very emotional reaction people have speaks volumes about how the brain views programming. Spoken language changes every day because people use words differently due to brains being different. This vexes those who are compulsive about adhering to fixed definitions and grammar rules because of some imagined ideal. The same is playing out in software. We will always be creating new languages and tweaking them and there are there will be those who believe in an imaginary ideal of what readable code is. Ultimately I think software writing needs to mature to where written language has matured: editors. Code review has some semblance as does paired programming. But editing is far more involved. Editors can reject entire writings. So why do we need editors in the first place? Because in order to have happy consistency a set of rules is not enough. I comes down to style: a word here, a name change there. It may not seem like much but in fact it is. Given a language is Turing complete, meaning it can exercise the full capability of the CPU and computer, then the choice of language and style is about the human condition, a condition which is as varied as the people in it. If one cannot write code that ones finds usable then one needs to keep searching in earnest for a better style. However, once you have a style you can appreciate your own code from years ago then it is a matter of arbitrary standards when interacting with others. You have to draw the line somewhere but lets not pretend for a second that a single writing style is ideal for everyone, or even most. Its arbitrary because without any standards you have an unmanageable chaos.

patrec 10y ago
Functional programming has made huge inroads into mainstream languages over the last 20 years, so I suppose this is because people's brains have suddenly changed?
fauigerzigerk 10y ago
>Do you really believe our brains are all the same? One thing that all brains have in common is that they can learn. One thing that all feet have in common is that they can not learn. That's why your analogy doesn't work here. >Functional programming is inscrutable by most. As is musical notation, maths, foreign languages, CAD drawings and everything else that has to be learned before use. I am not a huge proponent of FP as I'm not entirely convinced that the benefits of immutability always justify the restrictions imposed on algorithm and data structure design, both in terms of simplicity and performance. But one thing I am convinced of is that whatever newbies may find inscrutable is entirely irrelevant unless you plan to cut costs by having interns write all your code for free before replacing them.
- mcherm 10y ago
  > But one thing I am convinced of is that whatever newbies may find inscrutable is entirely irrelevant unless you plan to cut costs by having interns write all your code for free before replacing them. I completely agree. My standard in choosing a design or syntax is whether a reasonably competent (but not brilliant) programmer will understand this well if they are already generally familiar with the codebase (but unfamiliar with this particular module) and are in a particularly big hurry. As a specific example, I was horrified the first time I saw Java's convention for setting fields in a constructor: public class SomeClass { private final int shoeSize; private final String favoriteColor; public SomeClass(int shoeSize, String favoriteColor) { this.shoeSize = shoeSize; this.favoriteColor = favoriteColor; } } The constructor has a local variable with the same name as the instance variable. The syntax works because local variables shadow instance variables but not when explicitly referenced via "this." -- a moderately obscure part of Java syntax. Normally, I would object if a developer created a variable name that shadowed another and expected the reader to keep it straight and not get confused. But when you do this REGULARLY, it becomes just another standard idiom. Most readers today (now that the practice has been standard for over a decade) wouldn't even blink. A complete novice might be confused, but the complete novice isn't my target audience.
ldp01 10y ago
I always thought different paradigms suited different problem domains rather than different people. I'm not a software engineer by trade, but just for example, I've recently been mucking around making my own videogames and the object-oriented paradigm using the components pattern seems like a very natural way to conceptualise a videogame. E.g. Objects in the game (NPCs, environment) start as a basic object and are given specific behaviours by adding components. Alternatively, I sometimes have to write R code for data analysis and in that case the style of using pipe operators to chain lots of functions together is perfect for readability and for reasoning about the code.
- TuringTest 10y ago
  > I always thought different paradigms suited different problem domains rather than different people. This. Any imperative program can be formally encoded as an immutable functional program, and vice-versa. Therefore, which paradigm to choose is a matter of what style fits the problem at hand better, and how comfortable you are with the paradigm. But this is true of any coding convention.
LyndsySimon 10y ago
> Functional programming is inscrutable by most. I really don't think this is the case. FP is difficult for most developers who have experience with the OO/imperative paradigm - i.e., "most of us" - at first. It only takes about a week before the benefits become apparent. Don't get me wrong, I don't think it's the solution to every problem, but spending a couple of months writing Clojure was a major positive experience for me, and it's significantly improved my day-to-day code in Python, Ruby, and Javascript.

by mybrid 10y ago

patrec 10y ago

Functional programming has made huge inroads into mainstream languages over the last 20 years, so I suppose this is because people's brains have suddenly changed?

fauigerzigerk 10y ago

>Do you really believe our brains are all the same? One thing that all brains have in common is that they can learn. One thing that all feet have in common is that they can not learn. That's why your analogy doesn't work here. >Functional programming is inscrutable by most. As is musical notation, maths, foreign languages, CAD drawings and everything else that has to be learned before use. I am not a huge proponent of FP as I'm not entirely convinced that the benefits of immutability always justify the restrictions imposed on algorithm and data structure design, both in terms of simplicity and performance. But one thing I am convinced of is that whatever newbies may find inscrutable is entirely irrelevant unless you plan to cut costs by having interns write all your code for free before replacing them.

mcherm 10y ago
> But one thing I am convinced of is that whatever newbies may find inscrutable is entirely irrelevant unless you plan to cut costs by having interns write all your code for free before replacing them. I completely agree. My standard in choosing a design or syntax is whether a reasonably competent (but not brilliant) programmer will understand this well if they are already generally familiar with the codebase (but unfamiliar with this particular module) and are in a particularly big hurry. As a specific example, I was horrified the first time I saw Java's convention for setting fields in a constructor: public class SomeClass { private final int shoeSize; private final String favoriteColor; public SomeClass(int shoeSize, String favoriteColor) { this.shoeSize = shoeSize; this.favoriteColor = favoriteColor; } } The constructor has a local variable with the same name as the instance variable. The syntax works because local variables shadow instance variables but not when explicitly referenced via "this." -- a moderately obscure part of Java syntax. Normally, I would object if a developer created a variable name that shadowed another and expected the reader to keep it straight and not get confused. But when you do this REGULARLY, it becomes just another standard idiom. Most readers today (now that the practice has been standard for over a decade) wouldn't even blink. A complete novice might be confused, but the complete novice isn't my target audience.

ldp01 10y ago

I always thought different paradigms suited different problem domains rather than different people. I'm not a software engineer by trade, but just for example, I've recently been mucking around making my own videogames and the object-oriented paradigm using the components pattern seems like a very natural way to conceptualise a videogame. E.g. Objects in the game (NPCs, environment) start as a basic object and are given specific behaviours by adding components. Alternatively, I sometimes have to write R code for data analysis and in that case the style of using pipe operators to chain lots of functions together is perfect for readability and for reasoning about the code.

TuringTest 10y ago
> I always thought different paradigms suited different problem domains rather than different people. This. Any imperative program can be formally encoded as an immutable functional program, and vice-versa. Therefore, which paradigm to choose is a matter of what style fits the problem at hand better, and how comfortable you are with the paradigm. But this is true of any coding convention.

LyndsySimon 10y ago

> Functional programming is inscrutable by most. I really don't think this is the case. FP is difficult for most developers who have experience with the OO/imperative paradigm - i.e., "most of us" - at first. It only takes about a week before the benefits become apparent. Don't get me wrong, I don't think it's the solution to every problem, but spending a couple of months writing Clojure was a major positive experience for me, and it's significantly improved my day-to-day code in Python, Ruby, and Javascript.