6 ms·

Always, when read about "functional language usage in simulation", I check if OpenGL binding used. Other important things are physics engine and collision engin

by simne 1y ago

Always, when read about "functional language usage in simulation", I check if OpenGL binding used. Other important things are physics engine and collision engine, because these are more than 90% of all code. Unfortunately, just as I suspected, this project use OpenGL (nearly all implementations are C++), and C++ collision/physics engine. So, looks like, in this project, Clojure is used just as high level script to orchestrate all C++ parts, may be later we hear about some game scripting, but for simulators they are not as need as for example for RPGs. I agree, Clojure is better than C++ for orchestrate, but I have seen so tiny number of art persons familiar with functional paradigm, so this looks like beautiful dead end. Again, this is really beautiful and respectful achievement for author, but people I seen working in gamedev will not accept such approach.

beepbooptheory 1y ago
What would have been an alternative way to go here that would have been more acceptable to gamedevs?
- simne 1y ago
  I don't know such way now. From what I see, looking promising, to discontinue UNIX systems (based on C, and yes, Windows is also favor of UNIX, as NT was made directly on foundations of VMS from Digital), and switch to something more high-level, like OpenStep (with high usage of SmallTalk), or at least BeOS (based on C++). Sure, would be better to use Prolog based OS, when one will appear, or may somebody will create OS based on OcaML (Haskell, Rust). What I see problem for gamedev, in many cases they need very high performance, and when nearly all target (current) OSs are just C-machines, it is very much like discover epic huge wall, when need to switch from OcaML level to C to get additional few FPS. So most people choose easy way, they learn just primitive subset of C++ and work with it. https://en.wikipedia.org/wiki/Comparison_of_operating_systems https://en.wikipedia.org/wiki/Comparison_of_operating_system...
  - simne 1y ago
    BTW I have an idea - for gamedev could be beneficial to make some VM engine (multiplatform), for example like BEAM, why not, but probably something much faster (like LLVM), but including rich library of structures and algorithms for structured data and optimized for GD, and with good debugging tools for high level structures. This may become gamechanger, as it could be very fast, but high level abstraction, so people don't need to dive into machine level, and could work on high level.
- simne 1y ago
  I worked with IBM PC clones and DOS for a long time. What I seen - just hexadecimal dumps, sometimes picture patterns and nearly nothing else. Once one boy said me "this is Mac, on it things look different" and shown me just ordinary MS Office (for Mac) files in just standard utility. And I seen really other world - even on old MacOS (7..something), Office files was not just hexadecimal, but I easily see structure. Unfortunately, that's time I have not enough education in CS to understand how structures work, but some things was obvious. These was just some things partially implemented on ObjectiveC (too small objective part and too large C part), but any way it become significant shake of my world. Unfortunately, in Linux I constantly see the same as in DOS - mostly just hexadecimal dumps, no structure, so developers don't have motivation to use structured data, as it will not help them on build and maintenance.
- tliltocatl 1y ago
  There is an (IMHO quite underexplored) alternative of using HLL as a metalanguage for generating low-level code. Like Chisel/Spinal does for Verilog RTL, but with C or LLVM IR instead of RTL. I. e. terra-lang did this with Lua (afair didn't took off because of unfixably bad design choices from the start). Why this matters: compile-time metaprogramming is the way to provide zero-cost abstractions. HLLs tends to avoid metaprogramming because it's hard, instead relying on rich runtime (i. e. late binding and dynamic dispatch). Sometimes (i. e. in game engine code) that's not really an option. And metaprogramming is best done is something lisp-like, rather than C-like or C++-templates like. As to why this is underexplored, I think there are multiple reasons: - The most important one: those who care about the language tends to spend so much time on the language that they never get to the actual product, - We already have C++ templates which can do anything (they are also an unholy ureadable mess because they were invented for a completely different purpose) and C macros (which are also unholy unreadable mess because K&R hated macroprocessors passionately and curbed cpp to a bare unusable minimum). And people exposed to those conclude that any compile-time metaprogramming must necessarily be an unholy unreadable mess not worth exploring. - Most library bindings are in C, so any such system should include a C parser. At which point you wonder why bother at all?
  - simne 1y ago
    > using HLL as a metalanguage for generating low-level code Unfortunately, this is very long known dead-end, because very few programs written evidence-based, but most just begin their life with first production release, and on some platforms (JVM), more than 90% of developer time spend to refactoring and maintenance of existing code, and many people don't know anything else. So, templates are not enough to break through this wall, need infrastructure of libraries and debuggers, and may be macros, etc, designed specifically for fp and be at least on par with their imperative counterparts.
- simne 1y ago
  From second view, looks like good way using ECMA-6 (for example) with Babel and some things added into browser debugger. So, technically, high-level ECMA-6 language transpiled (more traditional word translated) to ordinary Javascript, and supplied file with structures, similar ideologically to C symbols tables, and within browser debugger (Chrome work) you could see not target JS but sources and debug on high level. And when your code become mature, you just remove symbols tables and as usual, target optimized code become very much like obfuscated, and you could provide it as closed source. So, as summary - must have all from list: 1. high-level language translator (may be into assembler, may be into some lover level language, as with ECMA-6 and JS) 2. some sort of debug support (as mentioned symbols tables) 3. good enough debugger, as much close to client platform as possible (Chrome is good example).
yogthos 1y ago
That's literally the whole point of using a high level functional language though. You use it to express the business logic of your app, the code that you care about. The fact that the underlying details of how rendering and physics are done is written in an imperative language doesn't really matter here. What I care about is maintaining the logic of my application, and that's what a language like Clojure makes easier to do.
- simne 1y ago
  Why not use some simpler, like old good UNIX Make? Or for business logic existing for a long time Lua, which is much easier to learn/use than Clojure. I love functional paradigm, but sometimes fp lovers, looks like evangelists of Blockchain or LLMs - not bad things, but all have their limits, and not very useful without powerful support of large library of fp structures and debugging programs. So, trying to use fp, you dive into abyss, writing with fp, but debugging with low level C debugger. BTW, as I know, OcaML, flagship of fp, just don't have graphics debugger, so people used to write on Haskell using old classic REPL technology, than, thanks to syntax similarity, most code just compile on OcaML without additional moves.
  - johnisgood 1y ago
    OCaml supports imperative, functional, and OOP just fine, and you use whichever makes more sense, and it has a REPL, too, most popular one is called "utop", but "ocaml" works. As for graphics debuggers, I have no idea if OCaml has a graphical one (if that is what you meant), but there is ocamldebug[1][2]. That said, I agree, why not just use Lua? Seems like the perfect language when you only care about the game itself and not the underlying stuff. There are many other alternatives that are better than Clojure anyways. I might be pessimistic, but I doubt Clojure is going to catch on. [1] https://ocaml.org/docs/debugging https://ocaml.org/docs/debugging [2] https://caml.inria.fr/resources/doc/guides/debug.en.html https://caml.inria.fr/resources/doc/guides/debug.en.html (contains section "Using the debugger under (X)Emacs")
    - simne 1y ago
sethev 1y ago
Computers are stateful and imperative, so any functional language that runs on real computers has a stateful and imperative base. OpenGL vs not seems like an odd place to draw the line on what you would consider functional vs not.
- simne 1y ago
  > Computers are stateful and imperative This is semi-Truth. Modern off the shelf Microcomputers nearly all imperative, because marketing won, but when world was under Mainframes (nearly up to 1980), existed many examples FP-optimized architectures or high-level architectures, even some of them was commercially successful (Lisp computers and some high-level mainframes). Also, most developers don't deal with naked hardware, but working with libraries of structures and libraries of high level algorithms, this named abstraction layer. Just some existing abstraction layers are less abstract and other are more abstract. As example, in Windows (and in most UNIXes) file abstraction is very simple and just imperative, but in MacOS it is OOP (derived from NEXTStep as I hear, based on ObjectiveC), and also exist some other OSes based on OOP languages, like BeOS, even when MacOS/BeOS are now running on same x86 hardware. So possible just run inside higher level VM. And mathematics is not prohibiting FP-machine, they could have very effective implementations with modern math. What really problem, except of Prolog, I don't hear about high-level debuggers for fp languages, so writing on for example Ocaml, you once end up looking on fp structures with old C debugger, which sure don't see fp structures.
  - sethev 1y ago
    A Lisp machine is no counterexample - they had assembly language instructions that were tailored for Lisp, but were still very much imperative. In fact, Clojure is significantly more functional than other Lisps, which used mutable cons cells extensively. Object oriented languages are also stateful and imperative, so I'm not sure why those are relevant here. I'm not saying these things are bad - it's possible to imagine a computer architecture that makes functional programming easier, but it's really hard to imagine a useful computer that is not stateful and imperative! What would it do, in that case? OpenGL vs not-OpenGL still seems like a very arbitrary way to classify simulations.
wedesoft 1y ago
In the past I have done some rigid body physics in GNU Guile (see https://www.youtube.com/watch?v=zBq3kW2jVxs https://www.youtube.com/watch?v=zBq3kW2jVxs for example). Of course if you need to simulate many objects, you will hit performance problems sooner if you don't use C/C++/Rust. Also the developer of Jolt has solved quite difficult problems, so I was quite happy to use it instead of rolling my own.

by simne 1y ago

beepbooptheory 1y ago

What would have been an alternative way to go here that would have been more acceptable to gamedevs?

simne 1y ago
I don't know such way now. From what I see, looking promising, to discontinue UNIX systems (based on C, and yes, Windows is also favor of UNIX, as NT was made directly on foundations of VMS from Digital), and switch to something more high-level, like OpenStep (with high usage of SmallTalk), or at least BeOS (based on C++). Sure, would be better to use Prolog based OS, when one will appear, or may somebody will create OS based on OcaML (Haskell, Rust). What I see problem for gamedev, in many cases they need very high performance, and when nearly all target (current) OSs are just C-machines, it is very much like discover epic huge wall, when need to switch from OcaML level to C to get additional few FPS. So most people choose easy way, they learn just primitive subset of C++ and work with it. https://en.wikipedia.org/wiki/Comparison_of_operating_systems https://en.wikipedia.org/wiki/Comparison_of_operating_system...
- simne 1y ago
  BTW I have an idea - for gamedev could be beneficial to make some VM engine (multiplatform), for example like BEAM, why not, but probably something much faster (like LLVM), but including rich library of structures and algorithms for structured data and optimized for GD, and with good debugging tools for high level structures. This may become gamechanger, as it could be very fast, but high level abstraction, so people don't need to dive into machine level, and could work on high level.
simne 1y ago
I worked with IBM PC clones and DOS for a long time. What I seen - just hexadecimal dumps, sometimes picture patterns and nearly nothing else. Once one boy said me "this is Mac, on it things look different" and shown me just ordinary MS Office (for Mac) files in just standard utility. And I seen really other world - even on old MacOS (7..something), Office files was not just hexadecimal, but I easily see structure. Unfortunately, that's time I have not enough education in CS to understand how structures work, but some things was obvious. These was just some things partially implemented on ObjectiveC (too small objective part and too large C part), but any way it become significant shake of my world. Unfortunately, in Linux I constantly see the same as in DOS - mostly just hexadecimal dumps, no structure, so developers don't have motivation to use structured data, as it will not help them on build and maintenance.
tliltocatl 1y ago
There is an (IMHO quite underexplored) alternative of using HLL as a metalanguage for generating low-level code. Like Chisel/Spinal does for Verilog RTL, but with C or LLVM IR instead of RTL. I. e. terra-lang did this with Lua (afair didn't took off because of unfixably bad design choices from the start). Why this matters: compile-time metaprogramming is the way to provide zero-cost abstractions. HLLs tends to avoid metaprogramming because it's hard, instead relying on rich runtime (i. e. late binding and dynamic dispatch). Sometimes (i. e. in game engine code) that's not really an option. And metaprogramming is best done is something lisp-like, rather than C-like or C++-templates like. As to why this is underexplored, I think there are multiple reasons: - The most important one: those who care about the language tends to spend so much time on the language that they never get to the actual product, - We already have C++ templates which can do anything (they are also an unholy ureadable mess because they were invented for a completely different purpose) and C macros (which are also unholy unreadable mess because K&R hated macroprocessors passionately and curbed cpp to a bare unusable minimum). And people exposed to those conclude that any compile-time metaprogramming must necessarily be an unholy unreadable mess not worth exploring. - Most library bindings are in C, so any such system should include a C parser. At which point you wonder why bother at all?
- simne 1y ago
  > using HLL as a metalanguage for generating low-level code Unfortunately, this is very long known dead-end, because very few programs written evidence-based, but most just begin their life with first production release, and on some platforms (JVM), more than 90% of developer time spend to refactoring and maintenance of existing code, and many people don't know anything else. So, templates are not enough to break through this wall, need infrastructure of libraries and debuggers, and may be macros, etc, designed specifically for fp and be at least on par with their imperative counterparts.
simne 1y ago
From second view, looks like good way using ECMA-6 (for example) with Babel and some things added into browser debugger. So, technically, high-level ECMA-6 language transpiled (more traditional word translated) to ordinary Javascript, and supplied file with structures, similar ideologically to C symbols tables, and within browser debugger (Chrome work) you could see not target JS but sources and debug on high level. And when your code become mature, you just remove symbols tables and as usual, target optimized code become very much like obfuscated, and you could provide it as closed source. So, as summary - must have all from list: 1. high-level language translator (may be into assembler, may be into some lover level language, as with ECMA-6 and JS) 2. some sort of debug support (as mentioned symbols tables) 3. good enough debugger, as much close to client platform as possible (Chrome is good example).

yogthos 1y ago

That's literally the whole point of using a high level functional language though. You use it to express the business logic of your app, the code that you care about. The fact that the underlying details of how rendering and physics are done is written in an imperative language doesn't really matter here. What I care about is maintaining the logic of my application, and that's what a language like Clojure makes easier to do.

simne 1y ago
Why not use some simpler, like old good UNIX Make? Or for business logic existing for a long time Lua, which is much easier to learn/use than Clojure. I love functional paradigm, but sometimes fp lovers, looks like evangelists of Blockchain or LLMs - not bad things, but all have their limits, and not very useful without powerful support of large library of fp structures and debugging programs. So, trying to use fp, you dive into abyss, writing with fp, but debugging with low level C debugger. BTW, as I know, OcaML, flagship of fp, just don't have graphics debugger, so people used to write on Haskell using old classic REPL technology, than, thanks to syntax similarity, most code just compile on OcaML without additional moves.
- johnisgood 1y ago
  OCaml supports imperative, functional, and OOP just fine, and you use whichever makes more sense, and it has a REPL, too, most popular one is called "utop", but "ocaml" works. As for graphics debuggers, I have no idea if OCaml has a graphical one (if that is what you meant), but there is ocamldebug[1][2]. That said, I agree, why not just use Lua? Seems like the perfect language when you only care about the game itself and not the underlying stuff. There are many other alternatives that are better than Clojure anyways. I might be pessimistic, but I doubt Clojure is going to catch on. [1] https://ocaml.org/docs/debugging https://ocaml.org/docs/debugging [2] https://caml.inria.fr/resources/doc/guides/debug.en.html https://caml.inria.fr/resources/doc/guides/debug.en.html (contains section "Using the debugger under (X)Emacs")
  - simne 1y ago

sethev 1y ago

Computers are stateful and imperative, so any functional language that runs on real computers has a stateful and imperative base. OpenGL vs not seems like an odd place to draw the line on what you would consider functional vs not.

simne 1y ago
> Computers are stateful and imperative This is semi-Truth. Modern off the shelf Microcomputers nearly all imperative, because marketing won, but when world was under Mainframes (nearly up to 1980), existed many examples FP-optimized architectures or high-level architectures, even some of them was commercially successful (Lisp computers and some high-level mainframes). Also, most developers don't deal with naked hardware, but working with libraries of structures and libraries of high level algorithms, this named abstraction layer. Just some existing abstraction layers are less abstract and other are more abstract. As example, in Windows (and in most UNIXes) file abstraction is very simple and just imperative, but in MacOS it is OOP (derived from NEXTStep as I hear, based on ObjectiveC), and also exist some other OSes based on OOP languages, like BeOS, even when MacOS/BeOS are now running on same x86 hardware. So possible just run inside higher level VM. And mathematics is not prohibiting FP-machine, they could have very effective implementations with modern math. What really problem, except of Prolog, I don't hear about high-level debuggers for fp languages, so writing on for example Ocaml, you once end up looking on fp structures with old C debugger, which sure don't see fp structures.
- sethev 1y ago
  A Lisp machine is no counterexample - they had assembly language instructions that were tailored for Lisp, but were still very much imperative. In fact, Clojure is significantly more functional than other Lisps, which used mutable cons cells extensively. Object oriented languages are also stateful and imperative, so I'm not sure why those are relevant here. I'm not saying these things are bad - it's possible to imagine a computer architecture that makes functional programming easier, but it's really hard to imagine a useful computer that is not stateful and imperative! What would it do, in that case? OpenGL vs not-OpenGL still seems like a very arbitrary way to classify simulations.

wedesoft 1y ago

In the past I have done some rigid body physics in GNU Guile (see https://www.youtube.com/watch?v=zBq3kW2jVxs https://www.youtube.com/watch?v=zBq3kW2jVxs for example). Of course if you need to simulate many objects, you will hit performance problems sooner if you don't use C/C++/Rust. Also the developer of Jolt has solved quite difficult problems, so I was quite happy to use it instead of rolling my own.