Programming thread

[Whatevermancer]

Does anyone have any experience implementing their own physics engine?
I need some advice on the broad phase collision detection. The way I do it at the moment is by using a uniform grid and every frame I clean up all cells that had objects inside of them and re-insert the objects, every time an object is added to a cell that already has objects in it, the grid reports potential collisions.
Thing is, by cleaning up all "dirty" cells I'm going against the advice of updating the objects, that is storing the ids of cells they take up and only removing them from the ones they no longer occupy and adding to ones they occupy now. I think it's fine, cause the majority of objects are moving around, but in 1/60 of a second they won't manage to move that far and will mostly occupy the same cells.

So... I dunno. What do you guys think?

 

[PedoSec]

Since we're telling stories about third party libraries throwing, I'll add a spin on it. This was 10+ years ago, no idea if it's still true, but libjpeg used to compile (at least on some platforms) with setjmp/longjmp enabled by default. I was calling into it from a multithreaded C++ program. Took me a while to figure out WTF was happening. All I knew was something was corrupting the stack.

 

[Marvin]

Does anyone have any experience implementing their own physics engine?
I need some advice on the broad phase collision detection. The way I do it at the moment is by using a uniform grid and every frame I clean up all cells that had objects inside of them and re-insert the objects, every time an object is added to a cell that already has objects in it, the grid reports potential collisions.
Thing is, by cleaning up all "dirty" cells I'm going against the advice of updating the objects, that is storing the ids of cells they take up and only removing them from the ones they no longer occupy and adding to ones they occupy now. I think it's fine, cause the majority of objects are moving around, but in 1/60 of a second they won't manage to move that far and will mostly occupy the same cells.

So... I dunno. What do you guys think?

I've never actually completed one, but I have at least started work on a 2d physics engine.

I was going for a quadtree. You fit items in the smallest box they can fit in and as you move them around, they bubble up or down in the tree (as they cross lines).

Quadtree - Wikipedia

en.wikipedia.org

An item can only possibly intersect with other items in its subtree.

 

[Whatevermancer]

I've never actually completed one, but I have at least started work on a 2d physics engine.

I was going for a quadtree. You fit items in the smallest box they can fit in and as you move them around, they bubble up or down in the tree (as they cross lines).

Quadtree - Wikipedia

en.wikipedia.org

An item can only possibly intersect with other items in its subtree.

Yeah, I'm aware of quadtrees. I think I'll build a benchmark to see how different structures perform.

 

[bleepy]

Why do functionalfags use incomprehensible jargon for every concept they make? I was reading Functional Programming in C++ today and turns out "currying" was just a function returning another function and "partial function application" was just a function that wraps around another function with static arguments. Functional programming seems much easier to do in C++ than in Haskell(not to even mention the speed difference lmao).

I don't think Go is necessarily a good comparison to the first two languages but you can draw some reasonable comparisons to Python.

Naw I'd say it's Java done right. Syntactically it's a very elegant evolution of C but a lot of its selling points are very similar to Java, such as being cross-platform(Java's solution is to port the JVM, Go's solution is cross-compilation), easy memory management through a GC, modules done right, and wonderfully easy debugging through pprof. I love Go's super fast compilation times and reasonably performant speed that Java couldn't even dream of without serious optimizations and JVM tweaks, even with those Java will be comically inefficient in terms of memory usage due to the JVM.

That said I'm a C++ and Rust dev and think they're the best tools alongside Go to write a massive web service in(recommended frameworks are userver, Drogon, and Actix-web). For example Yandex's backend is mostly written in C++ with a bit of Go. Sadly Russians seem to universally despise Rust.

 

[byuu]

A better "first language" than Python, by a long shot.

Python is good to play around with and try different concepts. Which I think is important for a first language.
Plus, it's one of the few languages that have builtin turtle graphics (anyone still use Logo for teaching?)

 

[306h4Ge5eJUJ]

Why do functionalfags use incomprehensible jargon for every concept they make? I was reading Functional Programming in C++ today and turns out "currying" was just a function returning another function and "partial function application" was just a function that wraps around another function with static arguments. Functional programming seems much easier to do in C++ than in Haskell(not to even mention the speed difference lmao).

What exactly would you call partial function application? It literally applies the function in part.

 

[bleepy]

What exactly would you call partial function application? It literally applies the function in part.

Functions with default arguments? Im a retard and I don't know any math jargon.

You FPfags act like this cabal of scholars speaking gibberish and pretend to be gods of software. Shit like the >>= operator where you pipe in IO<T> into T like getLine >>= putStrLn was just a fucking UNIX pipe, and could be trivially implemented using operator overloading and templates. All the good parts of functional programming have been incorporated into modern C++ software development and it's just plain retarded that FPfags say "learn Haskell if you want to learn functional programming".

 

[Agent Sandoval]

Functions with default arguments?

There are better ways to achieve default arguments, at least in Scheme, I'd imagine in Haskell too.
I don't think you've quite caught on to what Currying is or what partial calls allow. One literally enables the other, and the concept becomes very useful when you're working with lists, trees and graphs and you're folding or mapping over their contents.

it's just plain retarded that FPfags say "learn Haskell if you want to learn functional programming".

Ah yes, everyone else is a retard for suggesting you use a language designed around functional programming if you want to learn functional programming. C++, famously designed around imperative and object oriented principles, is surely the best environment to use to learn functional ones.

You don't need to learn functional programming. Since it's making you sperg a bit, maybe you shouldn't?

 

[Netizennameless]

So I decided to fuck with ChatGPT today and honestly it might be fairly useful to developers as opposed to replacing them:

I asked ChatGPT what the best method of dependency injection was:

I called it out for not including the Service Locator pattern:

while definitely a canned response, this is all valid information. Very interesting...

 

[YE24]

Why do functionalfags use incomprehensible jargon for every concept they make? I was reading Functional Programming in C++ today and turns out "currying" was just a function returning another function and "partial function application" was just a function that wraps around another function with static arguments. Functional programming seems much easier to do in C++ than in Haskell(not to even mention the speed difference lmao).

Speaking as a Prologfag that finds funcfags irritating, I feel you, bro, but "currying" is something that is quite well-founded in theory. This is why it is has a funny name, so you can recognize that it's something not familiar. Maybe worth learning. But you do you.

But yeah, as a C-nile, if I'm going to do something like currying, I probably want to compile it to get the best optimizations. My assembly sucks.

 

[nah]

Speaking on Go, yesterday morning Russ Cox, a member of the Go development team, created an open discussion on Github about adding telemetry to the Go toolchain (old archive: https://archive.ph/1mlIz; current huge screenshots attached). If anyone were to ask me about Go, I will tell them it was once a decent language to learn (like I did in this very thread on the previous page!), but now it's spyware. Even if the maintainers don't move forward with this, the fact that they thought of this has put a bad taste in my mouth. I imagine that this is something that's already being done by a lot of programming language toolchains of today, but it's still unconscionable.

Oh, this also seems ironic if Ken Thompson is still working on the language.

 

[Fcret]

Why do functionalfags use incomprehensible jargon for every concept they make? I was reading Functional Programming in C++ today and turns out "currying" was just a function returning another function and "partial function application" was just a function that wraps around another function with static arguments. Functional programming seems much easier to do in C++ than in Haskell(not to even mention the speed difference lmao).

C++ doesn't have tail-call optimization which makes it poorly suited for true functional programming.

 

[bleepy]

famously designed around imperative and object oriented principles

lmao, are you stuck in pre-ANSI C++? Even C++98 supports some functional concepts. Modern C++ is all about being multiparadigm and templates. As a result C++ is THE language. It is best suited for anything.

C++ doesn't have tail-call optimization which makes it poorly suited for true functional programming.

Although the standard doesn't specify it any compiler that has managed to implement this monster of a language supports it.
Recursion is a mechanism that lets you implement imperative algorithms in languages without loops, but it's mostly a low-level construct. I've rarely ever seen Haskell code that uses recursion directly in its code outside of tutorials. You use folds or map, which are again, implementable in C++ and are already in the STL as std::accumulate and std::transform.

 

[Fcret]

lmao, are you stuck in pre-ANSI C++? Even C++98 supports some functional concepts. Modern C++ is all about being multiparadigm and templates. As a result C++ is THE language. It is best suited for anything.

Although the standard doesn't specify it any compiler that has managed to implement this monster of a language supports it.
Recursion is a mechanism that lets you implement imperative algorithms in languages without loops, but it's mostly a low-level construct. I've rarely ever seen Haskell code that uses recursion directly in its code outside of tutorials. You use folds or map, which are again, implementable in C++ and are already in the STL as std::accumulate and std::transform.

Wow, it actually does.

what the fuck

 

[Flatline]

Why do functionalfags use incomprehensible jargon for every concept they make?

Functional programming comes from academics, and they like to obfuscate everything the same way they enjoy smelling each other's shit.

 

[Marvin]

Functions with default arguments? Im a retard and I don't know any math jargon.

You FPfags act like this cabal of scholars speaking gibberish and pretend to be gods of software. Shit like the >>= operator where you pipe in IO<T> into T like getLine >>= putStrLn was just a fucking UNIX pipe, and could be trivially implemented using operator overloading and templates.

I don't really say curry very often, and when I do, I really have to squint at its wikipedia page to relate it to the languages I use.

That being said, it's a distinct concept that is justified having a specific jargon term. Pipes are also a unix jargon term.

it's just plain retarded that FPfags say "learn Haskell if you want to learn functional programming".

I wouldn't say that. Haskell has done a good job at marketing itself as "the functional language" because it's closer to the purer mathematical theory, and maybe that's good for writing things like compilers. But I'd say that also strips functional programming of its practical value in most other areas. Your whole program doesn't need to be completely side-effect free to be able to see benefits of using functional programming in parts of it.

With Haskell, as I understand it, you're prone to painting yourself into a corner where you've laid out most of the language, and then realize you don't have the right monad or whatever to get the types to match to hook the whole thing up. So you have to rip everything apart and try again.

With a mostly functional language (but one that still permits imperative operations), you can get to that point, and patch over the issue with a small amount of imperative code. Your program will still be 99% functional, but you got to a working executable far quicker.

Functional programming seems much easier to do in C++ than in Haskell(not to even mention the speed difference lmao).

As a result C++ is THE language. It is best suited for anything.

The bigger problem with functional programming in C++ is its memory model. Without a real garbage collector, it's hard to get the full benefits of functional programming.

Recursion is a mechanism that lets you implement imperative algorithms in languages without loops, but it's mostly a low-level construct. I've rarely ever seen Haskell code that uses recursion directly in its code outside of tutorials.

Again, I wouldn't bother with Haskell itself.

In languages I use (Scheme or Ocaml), I do try to use the recommended library functions like fold or map when I can, but sometimes the way the data is laid out or the kind of algorithm I need to write, it doesn't always fit easily into the library functions. Like arbitrary tree structures rarely fit into those models alone.

 

[Rusty Metal Skull Gun]

You FPfags act like this cabal of scholars speaking gibberish and pretend to be gods of software. Shit like the >>= operator where you pipe in IO<T> into T like getLine >>= putStrLn was just a fucking UNIX pipe, and could be trivially implemented using operator overloading and templates. All the good parts of functional programming have been incorporated into modern C++ software development and it's just plain retarded that FPfags say "learn Haskell if you want to learn functional programming".

Very much agree - all the good bits of Haskell have been stolen by C++. Apart from academic wankery, there's no reason to use Haskell.

IIRC ghc also has abysmal code generation compared to C++ compilers.

 

[306h4Ge5eJUJ]

all the good bits of language X have been stolen by C++

People say this every time a new C++ standard comes out and every time the set of good bits has mysteriously grown even though language X didn't change.

 

[Rusty Metal Skull Gun]

People say this every time a new C++ standard comes out and every time the set of good bits has mysteriously grown even though language X didn't change.

Eh? I'm not saying that C++ didn't steal a lot of pointless shit (e.g. std::accumulate). I am saying that there's not really any advantages to choosing Haskell over modern C++.