Functorio
bartoszmilewski.com
bartoszmilewski.com
There is an entire contracts negotiation side to it. Which is really fuzzy and filled with all sorts of intentional inefficiencies (price-wise) brought about by competing interests and incentives.
It’s pretty much the exact opposite of supply chain management because the supply chain behaves perfectly. There is no uncertainty.
I agree that the game is not trying to be a market simulator however.
It's definitely a supply chain problem, but the way it is solved in Factorio (i.e. build a mine and a conveyor belt) is different to the way it is solved in reality (create a spec for the iron plate, a procurement process, contract negotiations, raising purchase orders, organising freight, managing compliance, all of which may be split across different teams). Then the iron plate company probably has the same thing to do for the iron - they probably don't own the mines where the iron ore comes from, so they also have to procure, contract, raise PO's, organise freight e.t.c.
So in reality, SCM is usually more about managing all those relationships and contracts rather than getting involved in end-to-end optimisation (which is sometimes done, but the details are the responsibility of another company - i.e. if a car company needs more bolts, they don't get involved in considering where a mine needs to be opened).
Don't we call that "production systems engineering"?
(e.g. automated production has a bigger focus on cells, robotics and in-line production, while logistics automation is often more about automated storage and retrieval systems, sortation, piece-picking systems etc).
There is a huge crossover though.
Naively, it seems like it's queues with variable delays all the way down.
However, I have to say that I don't think the author succeeded in showing me "that real engineering is functional." During my tour of FP, I would always eventually run into a wall of abstraction as soon as things got more than a little bit complicated. In that sense, Factorio comes across as a bit of a contrived example. As soon as you have an algorithm that lends itself to a few pieces of mutable state in a loop with complex terminating conditions, good luck. Yes, it's theoretically possible to shoehorn things like that into the formalities of FP. However, doing so usually ends up feeling like an academic exercise more than anything else. It doesn't feel like it moves you any closer to your ultimate goals; to implement functionality more quickly, cleanly, and intelligibly.
That being said, I don't regret getting into FP for a while. It's always a useful challenge to re-frame what you think you know with a different set of concepts. FP also works really well for certain kinds of problems. But I think the number of those are relatively few. This may be reaching, but I like to believe there's some historical precedent for this. After all, none other than Kurt Gödel himself eventually abandoned the λ-calculus in favor of Turing's mechanical (imperative) framing of computation. I want to believe there was some similar sentiment behind this decision. But who knows? It was probably more of a technical thing than I realize. But I've always felt on some level that an overabundance of abstraction necessarily means a lack of power.
This isn't my experience trying to read documentation and tutorials with similar libraries in both Scala and Haskell
I would go so far as to say that ZIO is like the Python of the realm. It's practically oriented and beginner friendly first and foremost. Also Scala is easier to understand than Haskell, but that's an opinion.
That's all just to say that the issue isn't FP in general, but the way FP has been implemented in beginner-unfriendly ways.
1. The conceptual organization of the code (≈ layout) 2. The interfaces between components (≈ routing)
Static types and functional programming naturally lean into this: types provide a first-class way to sketch out layout and interfaces in code without needing to implement the code in full detail. I'm drawn to static types less because of correctness or preventing bugs—although I can't complain about that!—and more because they give me a quick, high-level sub-language to sketch out and iterate on the design of my code. Those same types then act as guideposts for how the codebase fits together, making it easier for me to understand projects written by others or revisit code I wrote but don't remember well myself.
In factorio you create bigger functions from smaller ones as explained in the article in great detail. The routing and layout part is about organization, but the more abstract notions of combinations and ratios are "functional" in the sense of the article.
Factorio is the ultimate proof these tools are not any easier than just writing the code yourself.
I think games like these have the advantage that they immediately become a tool to be toyed with, although many still complain that getting into Factorio isn't too easy. Until math or a programming language becomes a tool, you have to invest a bit more into it.
"Every"? Nope:
https://en.wikipedia.org/wiki/Logic_programming
The "building blocks" (actually, the only data structure) of logic programming languages like Prolog, ASP, Mercury, Oz, etc are ... relations. Which map elements of sets without specific inputs and outputs. Put that in Haskell's pipe and smoke it.
OK, but now let's ask the important questions: has anyone implemented SLD(NF)-Resolution in Factorio, yet?
if the object becomes a pure blackbox and all you care about is what it sends and receives then this is hard to distinguish from the functional thinking, because even functions at their core usually have an imperative implementation, they just hide it away.
Erlang has been brought up in the thread and it's a good example of this because people use it as an example of both functional programming and maybe the closest thing to Alan Kay's original ideas about OO.
Pure functions do not have that
According to wikipedia, "a monad is defined as a functor with additional structure". Not unlike an object.
Arrays are a type that admits a monad instance, what do they send and receive?
def x(input):
tmp=input * 5
return str(tmp)
x input = show tmp
where tmp = input * 5
class IntState:
def __init__(self, val):
self.val = val
def x(input):
self.val += input
return str(val)Seems like leveraging our spatial system to communicate locality and purpose while hiding the innards would be very beneficial. I don't think you'd need to go full-on graphical programming language to achieve it either.
I remember playing Age of Empires 2 as a teenager and enjoying the amount of choices I have to win the game. Plus, the game teaches you about efficiency like few other games at the time. Each game, the sheer amount of resources and technologies you had to track in real time is equivalent of small bussines.
Then came Starcraft and logical thinking was replaced with player APM.
Those who never learn it are just stuck writing software in a more complicated and less readable way.
Learning FP and using it where it makes sense can do wonders to the quality of code you write. And over the past years many (even "traditional") languages have recognised and embraced that fact.
> You might have heard people say that functional programming is more academic, and real engineering is done in imperative style.
Real Engineering is done in imperative style. There are very very few projects done in pure functional style. Sure it can be possible, there are always a few FP projects sprinkled around eg Spark has done great. But FP really is a niche specialty. It makes me think it just isn't the right tool for the job.
> I’m going to show you that real engineering is functional, and I’m going to illustrate it using a computer game that is designed by engineers for engineers.
Indeed, I'd say that a lot of the software development I do isn't Real Engineering. And that's fine! I have a lot of respect for the people who make 50-story skyscrapers. But a lot of the time what people need is a modest one-story apartment, a redone kitchen, a backyard doghouse. Or a movie set that just looks like an apartment.
Not to mention that anything that goes through a spreadsheet relies on functional programming.
From my experience, real engineering is done in a multi-paradigm style. Some functional, some oo, some imperative, etc. As a general rule, functional style is easier to reason about (and test) for smaller pieces of code (ie, pure functions, function composition, etc) but can be harder to reason about for the larger code base. As such, it's very common to see as many functions as possible be done in a functional style.. but the overall system include lots of non-fuctional things.