[HN Gopher] Functorio
___________________________________________________________________
Functorio
Author : shepherdjerred
Score : 142 points
Date : 2021-11-21 19:55 UTC (3 hours ago)
(HTM) web link (bartoszmilewski.com)
(TXT) w3m dump (bartoszmilewski.com)
| remram wrote:
| I would say Factorio is all about routing & layout. The functions
| are handed to you.
| tikhonj wrote:
| Seems pretty similar to functional programming in that respect.
| When I write code in languages like Haskell, I tend to focus
| the most on two things:
|
| 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.
| FPGAhacker wrote:
| It's about supply chain management Routing and layout are tools
| you use in that management, but don't mistake the tool for the
| problem it solves.
| wdh505 wrote:
| I prefer open-sourced mindustry
| Kiro wrote:
| Very different game. Still great though.
| Zababa wrote:
| I wonder what the OOP version of that would look like. Trivially,
| you can imagine that an assembling machine is an object to which
| you can send a message CopperPlate, and that will reply with
| CopperWire, CopperWire. I've been thinking about factories like
| you see in "How it's made" and how you can imagine the machines
| in terms of functions with an input and an output, object to
| which you pass something and receive something back, or even
| "ingredient flow" where the focus is on the product and the
| different steps and not the transformations.
| Barrin92 wrote:
| The line between functional and object oriented actually gets
| very blurry when you take OO in its traditional sense, i.e. if
| you accept message passing between objects as the defining
| feature.
|
| 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.
| i_hate_pigeons wrote:
| if you take mutation of state out of the object, and we leave
| aside all the category theory part of fp then is more a
| matter of where functions are defined/how they organised
| zz865 wrote:
| Nice blog post, but:
|
| > 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.
| FeepingCreature wrote:
| Pretty much all the domain code I write at work is in a
| functional style. Because D makes this easy and convenient,
| it's just what we end up using. Turns out dataflow is easier to
| follow than control flow.
| RHSeeger wrote:
| > Real Engineering is done in imperative style
|
| 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.
| pjmlp wrote:
| Digital circuits are full of FP, and that is real engineering.
| [deleted]
| carlmr wrote:
| A lot of data engineering (pandas dataframes) is functional.
| GPU/shader programming is very functional. SQL queries are
| often quite functional.
| turminal wrote:
| Is data engineering _real_ engineering?
| _dain_ wrote:
| Pandas dataframes aren't really functional, people mutate in-
| place all the time by adding columns, dropping NaNs,
| reindexing, etc.
| 9wzYQbTYsAIc wrote:
| Including the rest of the paragraph:
|
| > 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.
| klelatti wrote:
| Erlang is a functional language and was originally written to
| power telecoms systems. I think that very much counts as Real
| Engineering.
| wpietri wrote:
| For sure. Right tools for the job.
|
| 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.
| StreamBright wrote:
| I dont think so. Half of the best practices of oop/imperative
| programming is coming from functional programming.
| kqr wrote:
| Lots of "real" engineering is based on algebraic manipulation,
| which has more in common with declarative/functional
| programming than with imperative/procedural programming.
|
| Not to mention that anything that goes through a spreadsheet
| relies on functional programming.
| davesque wrote:
| Very neat article. Since I got into and out of Haskell a while
| back, one of the complaints I always had about breaking into the
| space was that it was too abstract. Some of the core concepts of
| FP seemed really arbitrary when described without useful
| examples. So it's nice that the author has found a great analogy
| in Factorio.
|
| 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 Godel himself eventually abandoned the l-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.
| shaunxcode wrote:
| When I play factorio I am thinking about the conveyer belts as
| CSP channels and the grabber arms and factories as processes.
| Nothing to say the processes aren't functions of course.
| petethepig wrote:
| Factorio is a is queuing systems simulator. Just like your web
| server, those little factories process resources (requests) at
| certain speeds and pass them down to a bunch of other queuing
| systems (databases). I think it's really good at teaching
| intuition about queuing systems.
| pram wrote:
| Yep that's how I see it. The belts are Kafka, factories are
| microservices, etc. You have to manage backpressure,
| throughput, scaling and such just like that kind of
| environment.
| FPGAhacker wrote:
| That's an interesting take and I agree. I thought about it more
| like supply chain management, of which queues are a part.
| Closi wrote:
| Unfortunately it's nothing like supply chain management in
| reality! It's a bit like automated warehouse design but not
| really (Supply chain & logistics consultant here).
| phamilton wrote:
| What are some of the misconceptions that make it so
| different? "I need iron plates but there aren't any
| available" just feels so intuitively like a supply chain
| problem, I'd love to learn how the real world is so much
| more complicated.
| musingsole wrote:
| Are there other data structures that need to be brought in
| for supply chains?
|
| Naively, it seems like it's queues with variable delays all
| the way down.
| schappim wrote:
| From 9 months ago: https://news.ycombinator.com/item?id=26157969
| nodivbyzero wrote:
| Here is the another interesting discussion about `Game Oriented
| Assembly Lisp` https://news.ycombinator.com/item?id=2090554
| [deleted]
___________________________________________________________________
(page generated 2021-11-21 23:00 UTC)