Comment by rubiquity | Hacker News Reader

Comment by rubiquity | Hacker News Reader

I find that the reason there is so much discussion about microservices and scaling object oriented applications is due to the limitations of object orientation in the first place. These same limitations are the reasons why distribution and network/local transparency, something Martin Fowler states he doesn't believe works, do work in functional programming languages but don't work in OO languages.

It all boils down to OO programmers want their applications to be scalable and maintainable. They have decided the way to do that is through modularity. But we suck at enforcing modularity in a single code base. This has been proven time and time again. Microservices are just a sneaky way of forcing that modularity on ourselves. Instead of designing your system as a single ball of mud (monolith), you'll design your system as a puddle of mud (microservices).

It is just entirely too hard to write good, modular OO programs. This is why we hang onto every book, blog post and word the Object-Oriented Gods send down to us. OO could be a great and amazing thing for certain domains of programming. By all means, create monoliths and use Martin Fowler's Cookie Cutter Scalability solution because it is simple. But if you find yourself needing microservices, you're better off picking up a functional language where modularity comes naturally.

I disagree wholeheartedly.

If you read that post again you'll see that Fowler's admonition about "not distributing objects" is really about "not distributing method calls", and method calls aren't that different from function calls so far as his argument is concerned in that (1) the latency of distributed function calls is 10^3-10^6 greater than local function calls, and (2) distributed function calls often fail for reasons inherit to the network and not the application itself.

I'll agree that functional programming languages have many virtues, in that you can compose pure functions, run them in parallel and so forth, but functional programming does not make the issues Fowler talks about go away.

> If you read that post again you'll see that Fowler's admonition about "not distributing objects" is really about "not distributing method calls", and method calls aren't that different from function calls so far as his argument is concerned in that (1) the latency of distributed function calls is 10^3-10^6 greater than local function calls, and (2) distributed function calls often fail for reasons inherit to the network and not the application itself.

The expense of distributed method calls comes from the fact that you are dealing with objects -- that is, containers of mutable state -- where you either need to synchronize copies across the network (expensive in terms of traffic/latency) or run all method calls on the place where the object lives (likewise expensive in terms of latency).

Pure function calls don't depend on mutable state, and so don't have those issues (further, to the extent that you do set up a system that requires a remote call to execute them, once you've executed a given pure function with a given set of arguments, you don't need to do it again, as the result is cacheable and guaranteed good forever.) You still have to distribute the calls that actually depend on mutable state, but if your language starts out with a clean distinction between pure functions and operations whose result might depend on mutable state, you start out miles ahead when it comes to dealing with distribution compared to working with a language which provides no language level distinction between pure and impure code, requiring either manual segregation or treat-everything-as-state-dependent-and-pay-the-cost approaches.

> The expense of distributed method calls comes from the [need to] run all method calls on the place where the object lives

Which is exactly the same in functional as OO languages. If service A has some data, and service B needs to make use of that data, then service B needs to make a call to service A.

The OO/functional axis is orthogonal to the monolithic/distributed axis.

What's expensive is shared mutable state. Isolated mutable state is fine - it can live in the place where it's used. Shared immutable state is also fine, as it can be distributed once and then reused as much as you like, and there's no need to worry about keeping all the copies in sync.

Functional programming is all about avoiding shared mutable state, so it does have an advantage here.

Practically speaking, function calls over a network are by definition impure.

Any function that is capable of returning varying results for the same arguments is impure. And a function call across the network could return anything - a correct response, a corrupt response, no response - depending on what the network's having for lunch at that moment. We do have clever tools like the I/O monad, yes. But the I/O monad doesn't take I/O and make it pure; it takes I/O and wraps it up in a clever facade that (usually) lets you pretend that it's pure.

Whether a function is logically pure or not precedes the decision to implement via a network call and, in the event that a pure function is for some reason implemented via a network call, shapes how you implement it as a network call (as it affects cacheability, etc.)

Obviously, the medium of a network call is inherently impure -- but in the same way that anything implemented in an any physical device is (including internal computations in an electronic computer without network communication.)

Technically, yes, you can follow that reductio all the way down the rabbit hole. Practically speaking, though, it's not generally considered problematic that there's no way to set a timeout before issuing the CALL instruction.

There are ways to set a timeout before issuing (a particular) CALL instruction. Occasionally these are important.

They might even make it worse. Imagine filtering a list using a predicate that hits a remote service on every call. What is correct behavior for higher-order functions which accept function arguments that may time out?

The official answer is probably that you'd use some sort of monad to sweep that mess under the carpet. At which point you've just proposed a very close functional analogue to some of the worst shenanigans that used to happen with distributed objects back in the '90s.

A better answer would be to say that you use something like Erlang's actor model. At which point you've proposed something very similar to - perhaps indistinguishable from - microservices.

> The official answer is probably that you'd use some sort of monad to sweep that mess under the carpet. At which point you've just proposed a very close functional analogue to some of the worst shenanigans that used to happen with distributed objects back in the '90s.

I don't think it is the same, because the distinction is visible. Monadic code looks almost but not quite the same as pure code; it's not a lot of syntactic overhead, but it's enough to make it clear that something's going on. You can see right there in the type that this is invoking a remote call, and if you try to pretend that a distributed function is a regular function then the compiler will catch you and stop you. I don't think this is at all the same as CORBA, where there was literally no visible difference.

> Imagine filtering a list using a predicate that hits a remote service on every call.

If its not a pure function of the type of the lists elements, its not really a predicate. (Though, in a language which doesn't distinguish pure from impure code, it might look like one.) So the question is somewhat incoherent from the start, though the problem is a real issue.

> What is correct behavior for higher-order functions which accept function arguments that may time out?

No different from any other operation that can timeout (or otherwise fail).

> The official answer is probably that you'd use some sort of monad to sweep that mess under the carpet.

Monads don't sweep mess under the carpet, they expose it. And they aren't really an answer to "what is the correct behavior...", they are an answer to "once you've determined the correct behavior, what language featuers do you use to implement it in a pure functional language."

But, yes, in Haskell or a similar language, the question of "how do you deal with this external interaction that can fail" does likely involve the use of monads.

> At which point you've just proposed a very close functional analogue to some of the worst shenanigans that used to happen with distributed objects back in the '90s.

That's quite a leap, since invoking monads doesn't specify anything about functionality.

> A better answer would be to say that you use something like Erlang's actor model.

That's actually an orthogonal (non-)answer, since (1) the Actor model isn't an alternative which excludes monads, they operate in different conceptual domains, and (2) it still doesn't answer the "What is the correct behavior...?" question.

> At which point you've proposed something very similar to - perhaps indistinguishable from - microservices.

Yes, microservices are closely related to the actor model. Yes, monads are part of how you'd implement either in Haskell or a similar language. One isn't "better" than the other.

I think there's something quite exciting there in the functional habit of separating out pure from impure. Done well[0], it ought to actually make the difference between local and remote much more obvious.

[0] Facebook's Haxl library comes to mind

I'm interested to hear you back up that point about modularity coming naturally in functional languages. Not because I don't believe you -- I've worked with both Haskell and Scala and found both quite refreshing. But I've also encountered codebases on functional languages that are just as muddy and rigid as some of their OO counterparts... So I wonder how much of that modularity is actually a result of the language.

I should have said "more modular" but I definitely don't mean that modularity comes for free in FP languages. Programmers are capable of writing rigid programs in any language but I do feel in my little experience of using FP languages it is harder to do so, or more obvious when you are doing so. I'll give it a try anyway.

I think the modularity comes from most FP languages having fewer building blocks to work with than most OO languages. It's the same reason why users of OO languages with a ton of different building blocks (Java, C#, etc.) find more "minimalist" OO languages like Ruby refreshing. FP languages tend to take this simplicity even further. You essentially have just functions and modules (a place to group related functions). FP languages also usually don't have state, unless you want to emulate that in your program somehow.

To me it is about ditching the OO way of creating some representation of the circle of life or Kingdom of Classes hierarchy in your applications for just treating your program as data that goes through a sequence of transformations. Linear programs are always easier for me to understand than hierarchies.

Rich Hickey's Simple Made Easy[0] talk is a great overview of the subject. Now his talk isn't about modularity per se, but I think modularity is one of the many things that fall out of simplicity.

0 - http://www.infoq.com/presentations/Simple-Made-Easy

I think also the real complaint people have against mainstream OO languages, particularly Java, aren't around "inflexibility" but rather around total ecosystem complexity.

For instance, in PHP there are JSON serialization and de-serialization tools built into the language and people just use those.

In Java on the other hand you have to pick a third-party library, find it in maven central, cut and paste it into the POM file which is a gawdawful mess because it is all cut-and-pasted so every edit involves a tab war so it hard to view the diffs, etc.

Then you find out that the other guys working on the system already imported five different JSON libraries, but worse than that, some of the sub-projects depend on different versions of the same JSON libraries which occasionally causes strange failures to happen at run-time, etc...

Ironically these problems are caused by the success of the Java ecosystem. When you've got access to hundreds of thousands of well-packaged software that is (generally) worth reusuing, you can get in a lot more trouble than you can in the dialogue of FORTH you invented yourself.

This is a great point. Just look at the logging situation in Java.

I've built FP systems in a few languages, and I don't see them as a step change in ease of writing "good, modular" programs.

If you could tell me which aspect of FP you think does provide this big change, or link me to a discussion, I'd be very grateful!

Ok, exist a sample where the contrast between both is clear (related to this area)?

Reply on news.ycombinator.com