7 ms·
He talked about it a bit during his lex friedman interview. He said he spent some time there, IIRC, and found it somewhat intriguing, perhaps interesting, but n
by baby 4y ago
He talked about it a bit during his lex friedman interview. He said he spent some time there, IIRC, and found it somewhat intriguing, perhaps interesting, but needed to get shit done eventually and so stopped his investigation. Very pragmatic.
From what I can see in this article he mostly seemed to like the purity aspect of FP. It seems to me like a number of FP concepts aren’t really “FP things”, as Carmack points out you can use these patterns in imperative languages as well. Making your own DSL seems to also often be an FP thing that doesn’t need to be an FP thing.
I guess the other way is true as well. OCaml has OOP and support for imperative style (with mutation, early returns via exceptions, etc.)
- bmitc 4y ago> but needed to get shit done eventually and so stopped his investigation. Very pragmatic. That's a strange take by him and on pragmatism. There's also almost nothing pragmatic about C++. Many functional languages are actually quite pragmatic.
- forrestthewoods 4y ago> There's also almost nothing pragmatic about C++. Huh? We’re talking about game dev. C or C++ is the primary language for just about every game engine ever. Even Unity is written C++. I can’t say functional languages haven’t ever shipped a game. I’m sure there’s an example or three. But yeah when it comes to shipping games C++ is the definition of pragmatic.
- bmitc 4y agoThe word game appears twice in all the articles, so I took this writing as a broad outlook. And C++ is not C. Just because C++ ships games doesn't make it pragmatic. Aren't many game codebases considered to be absolute hell? And none of that says anything about the pragmatism of functional-first languages.
- FartyMcFarter 4y agoWhat language would you suggest game developers should have used throughout all these years? It needs to be performant and portable, and it needs to have existed for quite a long time.
- JonChesterfield 4y agoC99 with code generators written in python or lua for the engine. Implementing templates in the C preprocessor goes pretty badly, but implementing them as a normal language that writes valid C to #include various places works just fine.
- otabdeveloper4 4y ago> C99 with code generators written in python or lua for the engine. Nice fantasy, but the real-life codebases that do this make even the most hellish C++ code look like future space-age magic technology. You're not speaking from real-world pragmatic (heh) experience here, you're just complaining that C++ is hard and that you'd rather go shopping.
- JonChesterfield 4y agoI've been coding like that since at least 2016[1]. The trick is to make adding code generators as easy as adding source code. Not a game engine in my case, though there's a CppCon talk from 2014 which makes a passing reference to using code generators with C++ instead of templates for one. Assume source is src/foo.c and compiled to obj/foo.o, then introduce a third directory called gen. Change the makefile rule to copy .c from src to gen, and compile from gen to obj. Then add a makefile rule that says gen/foo.c can be built from src/foo.c.py by calling python on the source and redirecting stout. That means a C source file can be turned into a python program that generates the same source by wrapping it in a string literal, calling print and renaming the source file. No build system change. Then change the python as you see fit to work around the limitations of C. Works really well for a solo developer. Repo using this scheme is ~100 generated files (mostly lua, some python) vs ~600 C files. Plus ~20 C++ and one D, just getting started with that language. [1] https://github.com/JonChesterfield/boring-makefile/blob/master/src/makefile https://github.com/JonChesterfield/boring-makefile/blob/mast... $(GEN_PY_SOURCE): $(GEN_ROOT_DIR)%.c: $(SRC_ROOT_DIR)%.c.py $(PYTHON) $^ > $@
- pjmlp 4y agoUnity is partially written in C++, and since HPC# introduction they have been slowly migrating code from C++ into it. Unity is one of the reasons why Microsoft started to take Midori lessons into regular C#. Ultimately if we want to be pedantic, all game engines are written in C and C++, as that is the only way current OSes expose their graphics APIs, no alternative implementation can change that unless they also write an OS in the process.
- andsoitis 4y ago> There's also almost nothing pragmatic about C++. Many functional languages are actually quite pragmatic. a programming language alone doesn’t practicality make or break. factor in programming tools, libraries, community, and of course one’s prior experience.
- simplotek 4y ago> There's also almost nothing pragmatic about C++. That's a heck of a weird take. C++'s main value proposition has always been pragmatism. In all possible and conceivable aspects of a programming language. The fact that is a (mostly) superset of C, support for OO, RAII, outstanding backwards compatibility, time-tested and future-proofed, "you pay for what you use", it targets everything and runs everywhere, it's the language of choice on most mainstream OSes and specially Windows, etc. Why do you think people tolerate footguns and memory shenanigans? Why do you think that C++ is still one of the most popular languages ever devised and continued to hold the crown even after the C++98 cross through the desert? C++ has been the optimal choice with regards to pragmatism at least for the past two decades. What does C++ offer other than pragmatic solutions?
- bmitc 4y agoC++ is not necessarily popular for its merits. Inertia has a lot to do with it. I simply don't consider cans of worms pragmatic.
- simplotek 4y ago> C++ is not necessarily popular for its merits. Inertia has a lot to do with it. This personal assertion says nothing about C++ other than stating you have an irrational dislike for it. There are plenty of reasons that make C++ one of the most successful programming languages in mankind's history, if not the most successful, and inertia is not it.
- inductive_magic 4y ago>He said he spent some time there, IIRC, and found it somewhat intriguing, perhaps interesting, but needed to get shit done eventually and so […] I think this resonates with many. My take is: don’t be dogmatic. Regardless of the language, one should write as beautiful, composable and pure as possible - but no more than that. Where only performance matters, oop wins. When clarity is the only priority, Haskell wins. But in reality, we’re rarely dealing with either scenario. We’re somewhere in the noisy realm between, and ought to code accordingly. Fundamentalists rarely make policy with the nuance reality deserves.
- tmsln 4y ago> Where only performance matters, oop wins If you tell that Mike Acton he will give you an unhappy face. [0] In fact OOP can hurt performance a lot. [0] https://m.youtube.com/watch?v=rX0ItVEVjHc https://m.youtube.com/watch?v=rX0ItVEVjHc
- baby 4y agoNo modern language seems to have oop tho (golang, rust)
- sidlls 4y agoRust supports object oriented programming, and so does golang. In the case of the latter, it’s a fertile ground for all manner of bugs, performance issues, and weird behaviors thanks to the duck typing approach they chose.
- jillesvangurp 4y agoIn the same interview he also mentions using python a lot lately and making the point that for the vast majority of code, performance really doesn't matter and productivity is more important. Reading this article, he's making a great argument for Rust. I assume the article predates rust by quite a bit. But basically Rust is not a pure functional language but still has a lot of elements in the language that add purity and rigidity. It allows you to do low level stuff when you need to but at the same time promotes safety and correctness.
- jstx1 4y agoIn the same interview he also says that he's not fit to pass judgment on Rust even though he's used it.
- HybridCurve 4y ago>Reading this article, he's making a great argument for Rust. I think his points are related to an approach which generally reduces complexity and errors. Parts of that philosophy are embodied by Rust but are not exclusive to it.
- jstx1 4y agoI also don't know if Rust aligns well with the goal of reducing complexity. Programming in Rust gets really bogged down into thinking about programming language abstractions rather solving whatever problem you need to solve.
- Tanjreeve 4y ago>In the same interview he also mentions using python a lot lately and making the point that for the vast majority of code, performance really doesn't matter and productivity is more important. Until it does matter. Then it *really* matters at which point you're normally looking at a bottom up rewrite and likely retooling and rehiring for new skills. Ive been bitten by "oh it's just a prototype" a few too many times now.
- mejutoco 4y ago
- ledauphin 4y agojust because a pattern can be used alongside a different paradigm doesn't make it "not an FP thing." Referential transparency and immutability are fundamental to FP, therefore they are meaningfully described as FP things regardless of who is using them or where.