Hacker News Reader

Comment by userbinator | Hacker News Reader

A lot of these programming fads seem to come and go over the years. I've witnessed the same cycle with OOP, then FP. What a lot of people don't seem to realise is that by trying to split up a system into more smaller pieces in an attempt to decrease complexity, it's often the case that you end up with even more complexity, just hidden in the interactions between the pieces.

View on HN

> What a lot of people don't seem to realise is that by trying to split up a system into more smaller pieces in an attempt to decrease complexity, it's often the case that you end up with even more complexity, just hidden in the interactions between the pieces.

I think that is a good observation that I also made and I want to add to that. Moving from a monolith to microservices, is moving the complexity from inside the monolithic system to the interactions between microservices. This means that the job of developers becomes easier since a developer only has to think in terms of the microservice he/she is developing and ensuring that that 'simple' system externally behaves according to spec. But it also means that the job of the architect becomes more difficult because he/she has to get a grasp on all communication (synchronously/asynchronously) between the different microservices.

So, even though there might be more complexity overall, I do believe that from the point of view of a developer, the complexity is lower.

Read the last paragraph of "Fallacy #4".

Not all of these are the same. Since when is FP a fad? Would you say that structured programming is a fad? Is garbage collection?

2015 was the year of FP. Haskell was all the rage, elm was hot, large scale dismissal of OOP was in the air. To be clear I don’t think FP or OOP are really fads but their popularity waxes and wanes. I’ll see y’all in 2027 when static typing is whack and everyone is going back to dynamic typing.

Employed practices change in response to pain points. As an example, the microservices movement corresponds pretty well to an era of (overly) rapid organizational growth during a tech boom where a technical response to org chart problems became necessary.

In contrast, static versus dynamic typing doesn't seem likely to be so cyclical given the significant improvements in usability for gradually typed systems. Dynamic typing became most recently fashionable when the experience of using statically typed languages was sometimes unpleasant. Static typing has improved to the point where even retrofits onto other systems are very very good.

In areas where a reasonably complete gradual typing solution has emerged for a major dynamically typed language, it's rapidly become or becoming standard practice--Python and TypeScript being the two most obvious ones, but not the only ones. (Ruby may not get there. Its core implementation doesn't seem great. I wish they went with Sorbet.)

I don't see a reason that would unwind to the point where it's a serious conversation again.

I think the most recent popular use of dynamic typing is Elixir, and IMO that's because Phoenix (especially with LiveView) is the most interesting server-side web framework to come along in a while. Yes, you can add type checking with Dialyzer, but that's optional and AFAIK not a widespread default in Phoenix projects. I wish something like Phoenix and LiveView was available in a strongly statically typed language, but for now I just make do with the dynamic typing.

Elixir projects not using Dialyzer is a major reason why I don't use it much; I use it in my code, but not enough others do to make it comfortable. At the same time, my understanding is that Elixir has some pretty interesting gradual typing stuff in the works right now.

I could make more or less your exact statement, but substituting 2015 for 2004

Maybe pure FP was a fad around 2014, but practical FP, say, as embodied in React, is very much entrenched and is not going anywhere.

(To say nothing of Excel as the most widespread functional reactive programming tool, but few count it as a "real" programming environment.)

as a whole, interest in it comes in waves, but it never seems to make it to the mainstream.

Many mainstream ideas are incubated in the fp world, and wind up in the mainstream. for exmaple: GC, closures, higher order functions. but not any of the "functional programming languages" themselves.

What you're describing is literally FP ideas and abstractions going mainstream

uhh...yeah, i thought i was clear on that?

Sounded like you were disagreeing with me on that when you said

> but it never seems to make it to the mainstream

I actually think that’s the key to building a system that everyone can reason about.

The goal is to have these isolated “modules” where stuff is heavily interconnected, and the connections between modules are well-defined protocols. Then people know the common denominator of what’s possible and build with that. Meanwhile, you can prove things about the behavior of a module and uss the isolation between modules to prove various properties about the whole system.

> it's often the case that you end up with even more complexity, just hidden in the interactions between the pieces

That complexity is not "hidden in the interactions." It is exposed by explicit interactions.

The original ball-of-mud system likely had lots of actual hidden complexity, but it wasn't exposed so you couldn't see it, test it, or reason about it.

The added complexity of microservices is not from its breaking things into pieces, but by all of the tools needed to manage those separate pieces and their interactions. With that complexity comes new superpowers that weren't there before like blue-green deploys. Whether or how you use those powers is up to you.

OOP is still here and microservices(especially since aws lambda) is just getting stronger and stronger every year

Curious as to what constitutes MS on lambda? Because whether you have a dozen lambda functions where each function translates to one function vs one function with multiple features, the outcome is exactly the same.

API Gateway also muddies the water, it no longer makes sense for each lambda function to maintain stuff like services endpoint like in Kubernetes.

In fact, if you take away containers, you can completely achieve orchestration without Kubernetes. Simply use Step Functions to coordinate lambda functions or even better, avoid it altogether and have one lambda function coordinate the orchestration procedurally.

My bet is that as time goes on and companies realize the overhead from kubernetes and "cloud independence mandate", they will drive more business towards AWS, in particular Fargate is rapidly progressing, as well as ECS Anywhere allows you to run hybrid setups with complete ease and without the headache from Kubernetes.

Just realizing these things as I learn kubernetes and I keep thinking "wait I can just X from AWS and this bypasses the need for kubernetes altgoether" but seems like companies are already knee deep.

Yes and so is FP; but you don't have the same level of dogmatism for OOP that was prevalent in the mid 90s up to early 2000s.

As for microservices, the fact that it's great for cloud services nickel-and-diming you probably makes them likely to remain popular as long as the cloud computing propaganda continues to have effect.

This.

Instead of a simple method call, you now have the joys of distributed systems to deal with instead.

I'm a fan of right size architecture. Monoliths have their place. Microservices have their place. Neither are necessarily better than the other. Different tools for potentially different jobs.

Reply on news.ycombinator.com