How to write a promotional article about functional programming and not talking about Ocaml. Strange.
Functional programming is finally going mainstream
101–110 of 171 posts
Re: Functional programming is finally going mainstream
#102Earlier quoted context omitted.
Functional programming doesn't actually compete with imperative programming. In practice, functional programming is a way of organizing imperative programs. Kind of like how OO is a way of organizing imperative programs. Almost all applications written in Haskell use the IO monad quite a bit, for example. Large Haskell projects generally use a lot of C libraries, and sometimes even directly include C code for perform…
I think part of the problem is no implementation has an exciting story about writing the "shell" part in a different language. I love love love writing purely functional code. Probably my favorite thing to do. But what a lot people who also like functional programming are missing is writing imperative code in functional languages almost invariably sucks. At the end of the day we all have to write the "shell" part of…
> writing imperative code in functional languages almost invariably sucks.
I don't agree at all!
Haskell is extremely pleasant for imperative programming. There's a learning curve for sure, but you get a lot in return. (STM is one small example). I would much rather write imperative Haskell than Python.
It does gets messy when you start writing really low level code (direct pointer manipulation, etc). And it sucks for small scripts (too much project boilerplate, small standard library). But those are the only real pain-points.
Re: Functional programming is finally going mainstream
#103Earlier quoted context omitted.
> hidden O(n) situations How are these faster in imperative code?
They are usually not hidden, so they are at least easier to identify.
This is the crux of the matter. Every paradigm is argued about using small program examples, but the real-world issues come as the codebases become large (1M LOC or so). Then the cracks become worriesome.
Imperative non-OO codebases become swamps of maybe (hopefully?) layered code, where each layer contains its own sinkholes and completely bizarre structure (or lack thereof). It's basically a bunch of mini-codebases that meet in an ad-hoc manner, making it very difficult to understand what the hell is going on.
OO codebases encapsulate a LOT better, but working around its straitjacket design becomes harder and harder as you go through rituals like dependency injection, interfaces, adapters, facades, class clusters, and byzantine inheritance hierarchies. Now, rather than a swamp of despair, you have pebbles of functionality. And while these were great when your codebase was 50k LOC, it's now a gravel pile where you can't figure out where anything starts or ends.
FP codebases like to push the details out of the way, making it easier to see at a high level what's going on. But as the codebase grows, you now have multiple iceberg problems, where the devils in the details begin to derail your code in production, and suddenly you find yourself needing to delve down rabbit hole after rabbit hole, chasing issues that weave and bob in utterly chaotic ways due to the lazy evaluation. Reasoning about what it will actually do in what time becomes more and more difficult (putting it in vulgar terms: You're basically exchanging topical complexity for temporal complexity).
TANSTAAFL
Re: Functional programming is finally going mainstream
#104Earlier quoted context omitted.
Sorry, I don't get what how that's harder. newData = f(oldData) VS newObject = oldObject.f()
Right that's one object. Often you need to change the state of a bunch of related objects in a transactional way. The way redux works for example. It's somewhat analogous to database transactions.
I’m not a functional programmer by trade, but I think you’re alluding to (and should reframe your argument to discuss) concurrent reads and the implications of immutable data in a multithreaded scenario. It’s about simplifying your programs state machine. If I have some object A in an OO world, some N threads may act on said object concurrently resulting in some degree of non-determinism for any function of A. In FP, as I understand it, this is mitigated as you’re not dealing with mutable data structures but immutable objects whose data is consistent over the lifetime of any logical operation. Effectively, you just need to deal with conflicts on writes which you can design for.
This is just a side effect of functional programming but such behavior can be embedded into and made a fundamental part of your foundational data structures in an OO program.
Re: Functional programming is finally going mainstream
#105Earlier quoted context omitted.
Just to steel man the "Functions and Data" side of the equation in a lot of FP languages that'd be something like newData = oldData |> f |> g |> h |> i |> j |> k
And to straw man the OO way a little... newData = oldData.f().g().h().i().j().k() wont work by default unless you also happen to return the object after every method (builder style) which looks weird and is not standard
I don't know what you mean. You can return a different type, the only constraint is that the methods don't return void and the subsequent method exists. This has nothing to do with the builder pattern.
Re: Functional programming is finally going mainstream
#106Earlier quoted context omitted.
I do not think it is reasonable to call JS a Functional programming language.
No but it popularized practical functional programming through react.
React functional components have nothing to do with functional programming. Hooks are stored in global variables.
Re: Functional programming is finally going mainstream
#107Earlier quoted context omitted.
I like very much how Wirth puts it, Programs = Algorithms + Data Structures. Everything else is syntactic sugar.
If that were true, the past 30 years of progress in programming languages would be meaningless. But it is not: a more powerful language enables expressing what a weaker language does not. A language meant for use by professionals should get powerful features, without regard to any spurious notions of "purity".
Understanding what that equation means in practice is the difference between having a degree and a six month bootcamp as X Developer.
Re: Functional programming is finally going mainstream
#108Earlier quoted context omitted.
> At some level of software complexity, programmers MUST start to organize data into composite objects. I don't understand this point. All functional programming languages have algebraic data types and records, which are composite types. If this is not a "composite object", you'll have to clarify what you mean. > Copying memory around to enable to facilitate these immutable structures is SLOW. Slower than what and in…
> I don't understand this point. All functional programming languages have algebraic data types and records, which are composite types. If this is not a "composite object", you'll have to clarify what you mean. I think they meant data structures, not data types. Things like lists of records that each contain further records.
You and the other person don't understand.
All data structures have types. EVEN lists of records that each contain further records. A type or a data structure is an orthogonal concept to FP, because types exist in imperative programming and data structures also exist in FP.
Re: Functional programming is finally going mainstream
#109Earlier quoted context omitted.
“Everything is Turing complete” isn’t true. You can get quite interesting languages by making sure it isn’t. See strong functional programming for examples. https://en.m.wikipedia.org/wiki/Total_functional_programming
That you can code certain solutions in a non-Turing-complete language is of identically null benefit.
Aside from being able to prove that the solution halts, you mean? You get a lot of side benefits as well with a halting program, such as provable limits in time and space for the totality of the program instead of just the functional core bits.
Re: Functional programming is finally going mainstream
#110Functional programming with immutable state cannot possibly win in the general case. There are two truths that ensure the dominance of imperative software: 1. At some level of software complexity, programmers MUST start to organize data into composite objects. They have to do this because working outside of well-defined problem domains is a recipe for buggy software and spaghetti code. 2. Copying memory around to ena…
This is a really uninformed opinion. I'm disappointed that it's currently the top comment. You really think functional programmers don't build composite types?
It's like listening to a flat earth advocate.