↑ comment by Viliam ·
2015-04-03T13:04:36.139Z · LW(p) · GW(p)
I do not have much experience with functional programming, but I'll try to answer anyway:
There is a huge difference between programming as an academical discipline, and programming as in "what 99% of programmers in private sector do". The former is like painting portraits that will survive centuries, the latter is like painting walls. Both kinds of "painters" use colors, although the wall painters are usually okay with using only white color and the most experienced of them are really proud to use a paint roller with the great skill that only comes from years of experience. The portait painters usually have extremely low square-meters-per-hour productivity.
Programming as a science is about writing effective and provably correct algorithms, and designing abstract tools to make writing and proving of the algorithms easier. There is often a lot of math involved. Here are some random keywords: Turing completeness, Computational complexity, Formal languages, Lambda calculus...
Programming as a craft is about using existing tools (programming languages and libraries) and solving real-life problems with them. Also about developing practical skills that make cooperation and maintenance of larger projects easier.
in my experience 95% of bugs come from not of those types, but from misunderstanding requirements or requirements themselves being sloppy and chaotic
Yes, this is because in real life, most people are idiots. Of course when people who are paid for writing requirements can't do it well, most problems will be related to the requirements. But if you manage to fix this problem (for example, if you would cooperate with smart people, or write the requirements for yourself), then most of the remaining bugs will come from somewhere else.
There is a kind of improvements that comes strictly in a form of limitations. Such as "thou shalt not use GOTO". Or think about declaring variables and functions as "public" and "private"; all this does is forbidding you to do something what you would be able to do in a different language. And yet somehow these limitations make programming easier. Programs without GOTO commands are on average much easier to read, although there are specific situations where the specific algorithm could have been easier with some GOTO. (Also we have the "break" and "continue" commands to create so-called one-and-half loops that some purists frown upon.) Declaring a variable or method private allows you to change it without having to read the rest of the program. And these limitations work much better when supported by the IDE. You want your IDE to declare an edit-time error when a private variable is used from a different class, because then you have an immediate feedback.
Functional programming, as I understand it (and I am not an expert), seems like two related concepts: First, you can use functions as values. (You could simulate it in Java by various anynomous Runnable classes and adapters, but that would be a lot of boilerplate code, at least before Java 8.) Second, you have immutable objects, and functions without side-effects. The first thing is a syntactic sugar, but the second thing is the limitation that can make programming easier. Yes, you can have immutable objects in Java, but the compiler will not check this property for you. (There is no such thing as telling your standard Java IDE: "this class is supposed to be immutable; if there is some way I didn't notice that could actually mutate its values, please underline the code using red color".) So it is like a language that allows you to create your own convention about which variables and methods can be used only within the class that declared them, but does not provide any edit-time support for the "private" keyword.
Checking the immutability of an object in compile time is important, because when you decide you use this trait heavily (analogically to when you decide to use object-oriented programming heavily, as opposed to only having a class or two in an otherwise procedural code), and you make a mistake and one of those classes actually happens to be mutable, the whole concept falls apart. What is the advantage of using almost exclusively immutable objects? It makes multi-threaded development and caching values much easier. If you are going to develop an application that heavily uses multiple processors, or even multiple computers, for doing one computation, you will want to use immutable objects. Otherwise you will have to do a lot of thread-related micromanagement, and most likely you will produce a lot of bugs. On the other hand, if you add a few exceptions from the immutability rule (called monads) to otherwise functional code, you can still write the usual kind of applications. So, functional programming seems superior, because it expands your abilities.
Unfortunately, the more powerful programming concepts require better abstract thinking, and most people, including most professional programmers, are not good at it. They have to be dragged screaming to using new concepts, and even there they will stubbornly try to write the old code using the new syntax. (Just like many people write C++ code with Java syntax and call it "Java programming"; which usually means they treat interfaces as some inferior form of abstract classes, and complain about Java not having multiple inheritance. Also, their methods have hundreds of lines.) And because the worse programmers are more frequent in the job market, it actually makes sense for companies to use inferior technologies. (For example, this is why PHP still exists despite having no advantage over Python.)
Replies from: None
↑ comment by [deleted] ·
2015-04-03T14:40:58.948Z · LW(p) · GW(p)
My point is simply that it is not really just stupidity. It is not needing to go out on the edge. It is about not needing to build a query language into one that was totally not meant to because not needing to massage an XHTML document into a GUI because they use documents for documents and GUIs for GUIs.
But you are right, programming science is great. Just... don't expect to use it if you work for people who don't need to do almost-impossible things :)
Replies from: Viliam
↑ comment by Viliam ·
2015-04-07T08:46:53.443Z · LW(p) · GW(p)