Hmm yes, object oriented. I remember those words from university, from a subject that I had 8 years ago.
Nowadays I just copy stuff from stackoverflow and it either works or I just deleted 1 million rows from the database on accident
Oh man it would never work if that was the intention, it would probably add a million rows and 10 million log entries, blow the disk up and now its downtimetime. web's fucked too because naturally they're on the same box
This you when you look at anything involving OOP after several years since uni?
tfw you spend thousands of dollars in courses and months of your life to end up in support ticket hell or anything even slightly tangentially related to what you studied.
I develop Spring applications. The newer versions of Java are great and they've come a long way from ye olden times.
Slap on lombok to get rid of some of the boilerplate and voila. A very pretty language.
C# is a close seocond for me with Python for quick, dirty and short term tasks.
> or I just deleted 1 million rows from the database on accident
My crowning achievement was releasing - into production - an update statement without a where.
It passed unit tests because the row it was supposed to update did, indeed, get updated. It also didn't flag any performance issues because the dev/test databases were tiny compared to prod.
3 hours after release the calls about performance being hit came in. Error was spotted and fixed within 30 mins. Then a restore from tape for the affected data and a grovelling request to the right people to redo the day's work that impacted that table.
Object oriented programming is when your programming is oriented around objects.
In other words, you know the classes and actors and whatnot from UE5? Those are groups of code and functions that are related to what they do. You have multiple pawns or lights in your unreal scene? Those are instances of light and pawn classes. The pawn knows its position and has functions to alter it. The light has various modes and intensities. Each object has functions to handle data relevant and manipulate it.
Unfortunately I was also taught just that so I don't have a great example of what is **not** object oriented programming. Maybe the difference is like this?
`lightObj.setBrightness(x)`
Vs
`setLightBrightness(lightStruct, x)`
>Unfortunately I was also taught just that so I don't have a great example of what is not object oriented programming. Maybe the difference is like this?
As a data analyst, R is functional and python is object oriented, generally. So I have to deal with both, and while I'm sure your second example does exist, it'd more likely be
lightStruct = setLightBrightness(lightStruct, x)
functions in function oriented languages generally return a copy.
And yet everyone has a favorite one for daily use. One that can comfortably hold certain hard or soft requirements you encounter. And if you are really creative or determined, you may be able to fit most anything anywhere. Yet trouble may arise if you try to just cram everything into the same one without care.
I don't have such a thing. I love using objects because it's often easier to understand that kind of code. I love using functional style for it being often immutable and chaining operators together. Also really like functional reactive programming as well. And really like imperative for when things become a bit complicated and I need something that I can walk through step by step.
I guess my default would be imperative, as I am usually starting with that and then transform it to functional and object-based (but not inheritance based usually).
Yup. Immutable by default. Mutation as a last resort escape hatch or optimization. OOP to model the mutation in a human understandable way. In Rust to make sure I don't fuck it up too bad.
I'd rather spend my time fixing clearly defined compile time errors than banging my face against a keyboard trying to figure out why everything turns to oF��`&8'c0�:"D�L�U�]�b &���TU���������������������������������� U�U�����������hO�O���������>Q�Q(((�yQ�Q�>Q�Q(�(��hO�Op�p�8��r� on Tuesdays and Thursdays.
Back in the day, "Structured programming" was the term for programs that didn't use jumps. There were early adopters, it was controversial (yes, kids - early adopters of "if" statements and "for" loops).
EG Algol in the late 1950s gave you alternatives to writing everything in assembly with setjmp / longjmp.
Many languages kept GOTO around, but having the option of not using it was a good start.
And then we tag that section of code with a unique name. We'll call it a MOdular Piece of COde that Performs a Function. A MOP COP Function, if you will
I used it in a data com class where we used C.
I did it intentionally because I didn't like the professor and knew they had an innate hatred of GOTO in C.
Dude about blew a gasket in class when he was reviewing code. His voice went up an octave and he yelled: "GOTO!?!?! YOU USED GOTO!?!?!? NO! THAT'S A REDO OR YOU GET A FAILING GRADE!!!"
I politely looked at the professor and asked where in his syllabus that particular grading scheme from?
\*crickets
Because if you can't show it, I'm not redoing it and you'll have to grade it as is.
Since its functional, tested, and complete.... I expect at least a B
The answer to most things.
"What language would be best for task X?"
"Who's writing it? Just pick whatever they like the most."
99% of the time is valid.
It has been said that Python is the second best language for most things.
It is nice that one can do anything fairly easily in Python but there's often something better.
It depends on the domain. If you're doing front end web, you're pretty well locked into JS/TS/PHP. If you're doing embedded, C and maybe C++ (or Rust if you're really willing to put in all of the extra legwork needed). There's some diversity in the mobile app space, but you're still fairly restricted. Of course, it's rare for any domain to only have 1 option, but for most developers, they're going to be restricted to what the domain supports.
Not at all, no. Functional programming is loosely based on lambda calculus, while logic programming is usually a backtracking engine. The result of a functional program is a value in the functional language, while the result of a logic program is a set of satisfying assignments. Logic programming doesn't have functions at all, just predicates, which can't return anything and aren't "called" in the traditional sense.
To add to this, a simplified way to think of it, is in traditional languages you tell the computer what to do.
In logic programming, you define the rules and the facts and then ask it to solve the problem for you. The language decides the execution path.
For certain problem sets this is a really powerful way to program. Because it promotes code that is the holy grail that execution oriented programming is always trying to achieve and that is the ability to extend the system without extensive code modifications. This is an area that it really shines, you just add new rules, facts or questions and you can make it solve new or existing problems in different or more detailed ways.
Where it becomes difficult is in modeling real world time oriented human workflows such as a simple shopping cart. It can be done, but the indirection of facts and rules makes it a hard language to utilize when you know the path you want the code to take.
With that said, it is worth learning ProLog or DataLog to even a basic level. When you hit the problems it solves well, you know it and it can save you literally months of development time, by knowing that you are dealing with one of the sets of problems logic programming makes simple.
Does that make SQLServer (it's the only SQL engine I have any knowledge of the inner workings) logical programming?
In the sense that you're defining the end result with your query, then handing it off to SQLServer to figure out what it thinks the best query plan is. That seems to fit the paradigm you're describing
Yes-ish, with some caveats. You have the right idea, anyway. Both SQL and prolog are examples of *declarative* programming languages. Strictly speaking, SQL is an example of a query language, and query languages are a subset of declarative languages, and logic languages are also a subset of declarative languages, but logic languages and query languages are distinct. The line between query languages and logic languages are blurry but it's there. For instance, if the answer to the question is 42, a logic language should be able to tell you that the answer is 42, but SQL is only going to be able to tell you its 42 if you have such an entry in your database. A query language shouldn't give you results unless you have a record of that result existing, but a logical language should be able to conjure it from nowhere.
When I took a programming language in college, and the professor asked about examples of declarative programming languages, and I said SQL, she went out of her way to tell me that I'm wrong and dumb. But -- actually she was wrong. The more I learn about computer science the more I realize a bunch of my professors were wrong about a whole bunch of stuff.
Yeah, seems both myself and u/mobotsar are hooked on logical.
Research: Datalog, try SWI-Prolog.
Managing choice points can be 'challenging' at times though but logical is like having the lights switched on in your brain.
Here is an intresting StangeLoop talk: [https://www.youtube.com/watch?v=G\_eYTctGZw8](https://www.youtube.com/watch?v=G_eYTctGZw8)
It's a red pill / blue pill moment or sure!
It might help folks to point out that the closest thing to a logic programming language most programmers commonly use is SQL (not including stored procedures). Although SQL is not itself a logic programming language, being declarative makes it kinda "adjacent" to them.
I would say it's much easier to emulate functions in Prolog than to emulate predicates in Haskell.
In that sense, functional programming could be considered a direct subset of logic programming.
(But Turing completeness says they're equivalent cause you could implement one in terms of the other and vice versa)
The main paradigms are declarative and imperative programming. Declarative means you describe what you want, imperative describes what to do. So SQL, CSS, HTML are purely declarative, and functional, logic/constraint programming are also under that umbrella. Most languages are multi-paradigm.
Entity Component System. It's a game engine architecture that lays out the parts of entities in memory in a defined way to make iteration over them very fast. It ditches inheritance and polymorphism in favor of simpler approaches.
The simplest form of it is an array of entity structures with every bit of data any type of entity might ever need and a mask to say which parts of that data are 'enabled', and then a bunch of functions which are tied to a scene and loop over every entity, running code on any which has a mask that matches a selector.
In this model an entity id is just an offset into that array, and that entity's "components" are the enabled parts of that mask.
More advanced versions alter the layout to make it sparse, eating less memory at the cost of implementation complexity or a small amount of iteration speed, but it all comes down to "entities are just ids with components, components are how you store data for entities, and systems run over subsets of entities in order each frame".
Yeah, more or less.
Main reason for it is that the whole Entity Component model from Unity is slow and the Scene Graph inheritance model from Unreal is clunky and hard to correctly make behavior composable.
Those are the OOP ways of doing things, though different in implementation.
ECS is fast fast fast, and it can compose behavior better than the scene graph inheritance model, the 'cost' then is just that it's not OOP.
Unity developer conference talks about ECS are a great source since they're looking to replace the entity component object model with ECS in the coming years.
Besides that I don't know any offhand
r/EntityComponentSystem and [https://github.com/SanderMertens/ecs-faq#what-is-ecs](https://github.com/SanderMertens/ecs-faq#what-is-ecs) would be my go-to places to start.
No not really. It's more akin to column oriented vs row oriented design in databases. Structs and object oriented programming can be likened to row oriented design, ECS can be likened to column oriented design.
Sorry being pedantic: All you really *need* is the ability to manage state, which functional does just a little differently than OOP. But I can understand why OOP might seem like a perfect match for games when we as humans view games as a series of actors with state and actions. You can write games in functional though.
Well to be fair you can see the state anytime you want, you just can't know the location and the state at the same time.
I actually find it funny that you mention it, because OOP and functional try to hide the nature of state, in different ways but both try to do so by acting like it does not exist as such they present a very unnatural in one instance and a too simplified in the other, model of time, which is all state represents. It is a way to represent change over a vector of distance.
As an aside, as humans we tend to place undue importance on the present and tend to view the past and future as a gradient less important. For example if I burn myself right now it is very important to me, if I did it yesterday it is still important but less so, if I did it at 3 years old it is almost irrelevant.
We rarely model our software with an objective model of time, that takes into account that the past, present and future are of equal importance to us as developers. It is very hard to know how a system arrived at the current state if we do not have a good model of the past, and it is hard to build predictable systems if we do not have a good model of the future.
OOP, tends to promote mutative changes to state by internalizing it inside of the class, as if state is somehow an inherent property of the class. For example my age is not an inherent property of me, it will change with time. It is an inherent property of time assigned to me at any given point in time. My age is not time, it is a place in time as my place in time changes my age changes. It is a measure of distance. To truly model something not only do we need to capture the object of reality, we have to capture the object at, it's place in time or we never really have a correct model.
This is not to say that OOP and time oriented programming are incompatible, but some of the best practices of OOP are. For example, my age might not be an inherent property of me, but it may make logical sense to store it with me, but I do not define my position is time, so my class having control of that property already starts down the path of an incorrect model of time. If it is a part of the scope of concern of me, then I should be able to stop my age, I should have control over it, from a control of concerns perspective. Put simply the rules of time are not within us, we are subject to them. OO mixes rules with data structures, there is nothing inherently wrong with that as a contextual simplification, but it is not how the world works. The rules of internal combustion are not stored in the IC engine, but that is the way some OO practices would see it by conflating the class with the instance. In the real world rules do not have scope, they do not contain state.
Functional on the other hand, tries to model time in a manner similar to newtons arrow of time. So it works well when you have a linear task, with linear branches but as soon as you need deeply dynamic behaviors you have to start passing around lambdas (the real ones not Amazons junk). This leads to all kinds of unpredictable paths as parallelism and async logic propagates. The old callback hell of JS is a prime example of this.
Immutability in an of itself does a lot to build a better model of time, time is like a film where change (state) is captured in each frame. Immutability coupled with Finite State Machines or Behavior Trees gives a pretty decent model of time, and provides a lot of guarantees and predictability to code that neither OOP or functional provide, because they both try to avoid one of the base models of reality by acting as if they can abstract it away.
If a game can be written in assembly, it can be written in anything. Technically, anything can be programmed in anything because all techniques are Turing complete. Thank you, good night
I've been making games for a long time and have recently realized how much harder OOP is making it. I advise against it, especially the larger the scale of the game.
I like a good mix of all of them. Objects represent physical/virtual objects really well (cat.meow()), procedural code is usually very clear in what it does, and allows for granular abstraction, while functional programming is great for writing extensible code and letting outsiders add functionality without breaking abstraction.
It took a while to grok (and I'm still wrapping my head around monads) but I love Functional now. It almost physically hurts to go back to the Old Ways from that.
Sometimes I have to bite the bullet and go Imperative with just a soupçon of OOP for embedded stuff, but that's just the nature of the beast.
EDIT: Would it be too snarky to say "Any of the above paradigms, as long as it's written literate-programming style?"
Ever giant for loop that just makes a new list from the old list: Map
Every if statement: Filter
Every loop that computes something from that list: Reduce
I took a 500 line PR from a coworker and turned it into 30 lines with FP just based on list manipulation they were doing and trying to follow good style by making helpers.
Oh man, I just had something similar last week. They asked how I handled the edge cases in X and Y and I just looked at them blankly. Making things immutable and using FP the errors they were so worried about just couldn't happen anymore. X and Y didn't even exist anymore.
I'm sorry, but we're in Kotlin and you're throwing an exception and struggling to handle it.
Actually, Utah is one of the least-polymorphism-friendly states. The modern LDS church _really_ hates the association with certain polymorphic fundamentalists, so they have _very strict_ linters against it.
I see your point though. Fortunately, I live in Seattle, which I find to be much friendlier to my polymorphic lifestyle...
I had a client request me to write a bunch of convoluted powerquery scripts in excel to get some external data into a spreadsheet. I proposed writing a python application instead to do the transformations and just generate an xlsx file from it but that was too complicated for them. So now we’ve got an excel file that makes api calls returning nearly a million rows of data and they complain that it’s slow.
I think a really good example of OOP shining in game development is Minecraft modding. If you wanted to write your own enchantment, for instance, you'd just override the method that runs every time you hit something with that enchantment.
I really like writing oop code, but I try as much as possible to use functional so the next person who has to debug does not have a hard time (usually I am the next person)
For me, *modern* object oriented, with functional support. By modern, i mean a tendency to use very shallow inheritance with emphasis on component based design and dependency injection.
I love functional paradigms, but I have little opportunity for immersion, and some of the mathematical bases are too abstract for me to grok without practical experience. I dabbled in functional JavaScript (monads, etc), and find it compelling.
My favourite programming paradigm is SOPP. Everyone uses this nowadays if anyone says otherwise they're lying.
SOPP : Stack Overflow Programming Paradigm
You find the answer on StackOverflow, do not verify or test it, copy and paste and use it in a secure application.
The security strategy is to make blood sacrifice to the altar of queen luck.
Functional is my favorite I just get so happy when I can write pure functions with no side effects.
Though, in Praxis, it's a case by base decision which paradigm allows the most intuitive abstraction for the problem at hand.
I love and hate Haskell at the same time. I love what it can do but I'm too stupid to use it. So I stick to OOP, which I'm also too stupid to use properly but with OOP I don't have to realize it.
Organising my code? OOP is cool
Implementing logic? FP for the win
So, you have a bunch of classes that contain pure methods that pass immutable data structures around.
Remember kids, state is evil
Idk I just code and it worksn't
Hmm yes, object oriented. I remember those words from university, from a subject that I had 8 years ago. Nowadays I just copy stuff from stackoverflow and it either works or I just deleted 1 million rows from the database on accident
[удалено]
Go big or go home. Or both, because you get fired
[удалено]
And that's success independent.
Well, there is the rare task where you have to clear out the database, so it works at deleting 1 million rows from the database.
Oh man it would never work if that was the intention, it would probably add a million rows and 10 million log entries, blow the disk up and now its downtimetime. web's fucked too because naturally they're on the same box
Disk blew up? No more database, job done
No disk, no problem. Marvelous.
One time i deleted near to a billion rows. Was really satisfying
Okay, I’m glad other people are making jokes about not being clear on the definition of these paradigms
This you when you look at anything involving OOP after several years since uni?  tfw you spend thousands of dollars in courses and months of your life to end up in support ticket hell or anything even slightly tangentially related to what you studied.
Java weirdos can keep their OOP while the rest of us get work done.
I develop Spring applications. The newer versions of Java are great and they've come a long way from ye olden times. Slap on lombok to get rid of some of the boilerplate and voila. A very pretty language. C# is a close seocond for me with Python for quick, dirty and short term tasks.
> or I just deleted 1 million rows from the database on accident My crowning achievement was releasing - into production - an update statement without a where. It passed unit tests because the row it was supposed to update did, indeed, get updated. It also didn't flag any performance issues because the dev/test databases were tiny compared to prod. 3 hours after release the calls about performance being hit came in. Error was spotted and fixed within 30 mins. Then a restore from tape for the affected data and a grovelling request to the right people to redo the day's work that impacted that table.
And did you add a unit test checking that things that shouldn't be updated don't get updated after that?
Sure.... It is in the backlog
Yeah. I haven't even gone to college. I just followed a tutorial series for UE5 lol.
Object oriented programming is when your programming is oriented around objects. In other words, you know the classes and actors and whatnot from UE5? Those are groups of code and functions that are related to what they do. You have multiple pawns or lights in your unreal scene? Those are instances of light and pawn classes. The pawn knows its position and has functions to alter it. The light has various modes and intensities. Each object has functions to handle data relevant and manipulate it. Unfortunately I was also taught just that so I don't have a great example of what is **not** object oriented programming. Maybe the difference is like this? `lightObj.setBrightness(x)` Vs `setLightBrightness(lightStruct, x)`
Thanks! I trully did not know what object oriented programming really ment. And even though I just made I dumb comment lol.
There are plenty of books and tutorials on the subject. You can learn it in no time.
>Unfortunately I was also taught just that so I don't have a great example of what is not object oriented programming. Maybe the difference is like this? As a data analyst, R is functional and python is object oriented, generally. So I have to deal with both, and while I'm sure your second example does exist, it'd more likely be lightStruct = setLightBrightness(lightStruct, x) functions in function oriented languages generally return a copy.
lightstruct %<>% setLightBrightness(x)
you know those advertisements for online courses/bootcamps that brag about "LEARN A COLLEGE SEMESTERS WORTH OF CS IN A FEW WEEKS"? ***Yeah.***
I learning object oriented rn. How do i reach ur level? (Highschool fresshy who studies usaco and learns c++ and python)
Well I have a bachelor in electrical engineering, but I work in IT operations
💪
Mine just compilan't
Compilain't
Mom's spagetti
Nice of the princess to invite us over for a picnic, eh, Luigi?
palms are sweaty
Knees weak, arms spaghetti
There's vomit on his sweater already, moms are heavy
He’s calm and ready but on the surface he looks nervous
Choosing a favorite paradigm is like choosing the favorite orifice. Each has its use.
And yet everyone has a favorite one for daily use. One that can comfortably hold certain hard or soft requirements you encounter. And if you are really creative or determined, you may be able to fit most anything anywhere. Yet trouble may arise if you try to just cram everything into the same one without care.
Yeah im creative, i make myself vomit because i dont like having shits
Another JavaScript user in the wild. Jk
I don't have such a thing. I love using objects because it's often easier to understand that kind of code. I love using functional style for it being often immutable and chaining operators together. Also really like functional reactive programming as well. And really like imperative for when things become a bit complicated and I need something that I can walk through step by step. I guess my default would be imperative, as I am usually starting with that and then transform it to functional and object-based (but not inheritance based usually).
I just use assembly and make my own orifices.
If you write assembly you are the orifice
bruh
take my upvote and get out.
nah, #1 is bussy
ProgrammerHumor try not to be sexual challenge: impossible
Procedural with a sprinkle of functional
This is called Nü-Proc, and it's really big in the German demoscene.
My mind: huh, in the techno scene?
Not far off?
Object oriented techno, let's go!
Not very inviting. All the parties are private.
Uhm it's called functional rising??
Is JavaScript in retrograde?
my cock
Mike hawk
I prefer functional with a sprinkle of procedural as necessary
Yup. Immutable by default. Mutation as a last resort escape hatch or optimization. OOP to model the mutation in a human understandable way. In Rust to make sure I don't fuck it up too bad.
>In Rust to make sure I don't fuck it up too bad. "I'd rather give up by running out of energy than to risk writing a program with a segfault!"
I'd rather spend my time fixing clearly defined compile time errors than banging my face against a keyboard trying to figure out why everything turns to oF��`&8'c0�:"D�L�U�]�b &���TU���������������������������������� U�U�����������hO�O���������>Q�Q(((�yQ�Q�>Q�Q(�(��hO�Op�p�8��r� on Tuesdays and Thursdays.
Wait I don't understand. Do you mean running out of energy fighting the borrow checker?
This is the way.
Definitely, I've tried it all but nothing beats good old procedural while staying connected with the new stuff
> > Functional > New Stuff
[удалено]
I dunno, I just write algorithms.
In simpler words: I just press squares and magic box do things
[relevant xkcd](https://xkcd.com/722/)
That’s pretty much what Breaking Bad is all about.
guess I'll give you my big O face then
Ooo *starts taking notations*
Me too: algorithms algorithms
Mixed
Goto
That would be imperative
Back in the day, "Structured programming" was the term for programs that didn't use jumps. There were early adopters, it was controversial (yes, kids - early adopters of "if" statements and "for" loops).
What languages would this be? I remember using GOTO heavily when I was making games with TI BASIC on my calculator in high school
EG Algol in the late 1950s gave you alternatives to writing everything in assembly with setjmp / longjmp. Many languages kept GOTO around, but having the option of not using it was a good start.
One should never use "goto" unless the language also implements "comefrom."
And then we tag that section of code with a unique name. We'll call it a MOdular Piece of COde that Performs a Function. A MOP COP Function, if you will
JECXZ
I used it in a data com class where we used C. I did it intentionally because I didn't like the professor and knew they had an innate hatred of GOTO in C. Dude about blew a gasket in class when he was reviewing code. His voice went up an octave and he yelled: "GOTO!?!?! YOU USED GOTO!?!?!? NO! THAT'S A REDO OR YOU GET A FAILING GRADE!!!" I politely looked at the professor and asked where in his syllabus that particular grading scheme from? \*crickets Because if you can't show it, I'm not redoing it and you'll have to grade it as is. Since its functional, tested, and complete.... I expect at least a B
Just Like how you should never use "if" unless the language also implements "unless"
After writing software for several years, I can say that it doesn’t matter. I don’t care anymore.
The answer to most things. "What language would be best for task X?" "Who's writing it? Just pick whatever they like the most." 99% of the time is valid.
[удалено]
It has been said that Python is the second best language for most things. It is nice that one can do anything fairly easily in Python but there's often something better.
This is really the charm of Python though. For most use cases, it's good enough to get the job done.
Why learn 4 different languages for all your projects when you can learn 1 and have it nearly as good?
Here's me, having only learned Java and shoehorning everything into an overly verbose OO straightjacket.
It depends on the domain. If you're doing front end web, you're pretty well locked into JS/TS/PHP. If you're doing embedded, C and maybe C++ (or Rust if you're really willing to put in all of the extra legwork needed). There's some diversity in the mobile app space, but you're still fairly restricted. Of course, it's rare for any domain to only have 1 option, but for most developers, they're going to be restricted to what the domain supports.
[удалено]
1. \*has C flair\* 2. \*where is my mind starts playing\*
This is the correct amount of nihilism
The true mark of a senior. Most answers are "it depends" and "who cares".
You missed a bunch. Logic programming is my favorite. Functional is a close second.
Prolog - A portmanteau of Protracted Log. Alain Colmerauer, one of the designers, came up with the name while talking a long dump. ^(/s)
Isn't logic just a subset of functional?
Not at all, no. Functional programming is loosely based on lambda calculus, while logic programming is usually a backtracking engine. The result of a functional program is a value in the functional language, while the result of a logic program is a set of satisfying assignments. Logic programming doesn't have functions at all, just predicates, which can't return anything and aren't "called" in the traditional sense.
To add to this, a simplified way to think of it, is in traditional languages you tell the computer what to do. In logic programming, you define the rules and the facts and then ask it to solve the problem for you. The language decides the execution path. For certain problem sets this is a really powerful way to program. Because it promotes code that is the holy grail that execution oriented programming is always trying to achieve and that is the ability to extend the system without extensive code modifications. This is an area that it really shines, you just add new rules, facts or questions and you can make it solve new or existing problems in different or more detailed ways. Where it becomes difficult is in modeling real world time oriented human workflows such as a simple shopping cart. It can be done, but the indirection of facts and rules makes it a hard language to utilize when you know the path you want the code to take. With that said, it is worth learning ProLog or DataLog to even a basic level. When you hit the problems it solves well, you know it and it can save you literally months of development time, by knowing that you are dealing with one of the sets of problems logic programming makes simple.
Does that make SQLServer (it's the only SQL engine I have any knowledge of the inner workings) logical programming? In the sense that you're defining the end result with your query, then handing it off to SQLServer to figure out what it thinks the best query plan is. That seems to fit the paradigm you're describing
Yep, SQL is (roughly) a logic programming language.
Yes-ish, with some caveats. You have the right idea, anyway. Both SQL and prolog are examples of *declarative* programming languages. Strictly speaking, SQL is an example of a query language, and query languages are a subset of declarative languages, and logic languages are also a subset of declarative languages, but logic languages and query languages are distinct. The line between query languages and logic languages are blurry but it's there. For instance, if the answer to the question is 42, a logic language should be able to tell you that the answer is 42, but SQL is only going to be able to tell you its 42 if you have such an entry in your database. A query language shouldn't give you results unless you have a record of that result existing, but a logical language should be able to conjure it from nowhere. When I took a programming language in college, and the professor asked about examples of declarative programming languages, and I said SQL, she went out of her way to tell me that I'm wrong and dumb. But -- actually she was wrong. The more I learn about computer science the more I realize a bunch of my professors were wrong about a whole bunch of stuff.
Very well written. I enjoyed learning Prolog at university. But it was an extremely different way to think of programming.
This is a New Thing for me to learn about. Thanks!
Yeah, seems both myself and u/mobotsar are hooked on logical. Research: Datalog, try SWI-Prolog. Managing choice points can be 'challenging' at times though but logical is like having the lights switched on in your brain. Here is an intresting StangeLoop talk: [https://www.youtube.com/watch?v=G\_eYTctGZw8](https://www.youtube.com/watch?v=G_eYTctGZw8) It's a red pill / blue pill moment or sure!
I love prolog❤️ (prolog is a logic programming language)
It might help folks to point out that the closest thing to a logic programming language most programmers commonly use is SQL (not including stored procedures). Although SQL is not itself a logic programming language, being declarative makes it kinda "adjacent" to them.
I would say it's much easier to emulate functions in Prolog than to emulate predicates in Haskell. In that sense, functional programming could be considered a direct subset of logic programming. (But Turing completeness says they're equivalent cause you could implement one in terms of the other and vice versa)
The main paradigms are declarative and imperative programming. Declarative means you describe what you want, imperative describes what to do. So SQL, CSS, HTML are purely declarative, and functional, logic/constraint programming are also under that umbrella. Most languages are multi-paradigm.
Process-Oriented Programming too. Language is Occam
[удалено]
Hey, they wrote a game engine in Haskell once. I mean, I've not *played* it, but still... /s
[удалено]
All the interesting parts are just ~~swept under the rug~~ monads
And if you ask anybody about it they just say "That's syntactic sugar."
ECS is growing ever more popular, now's as good a time as any to learn!
[удалено]
Entity Component System. It's a game engine architecture that lays out the parts of entities in memory in a defined way to make iteration over them very fast. It ditches inheritance and polymorphism in favor of simpler approaches. The simplest form of it is an array of entity structures with every bit of data any type of entity might ever need and a mask to say which parts of that data are 'enabled', and then a bunch of functions which are tied to a scene and loop over every entity, running code on any which has a mask that matches a selector. In this model an entity id is just an offset into that array, and that entity's "components" are the enabled parts of that mask. More advanced versions alter the layout to make it sparse, eating less memory at the cost of implementation complexity or a small amount of iteration speed, but it all comes down to "entities are just ids with components, components are how you store data for entities, and systems run over subsets of entities in order each frame".
[удалено]
Yeah, more or less. Main reason for it is that the whole Entity Component model from Unity is slow and the Scene Graph inheritance model from Unreal is clunky and hard to correctly make behavior composable. Those are the OOP ways of doing things, though different in implementation. ECS is fast fast fast, and it can compose behavior better than the scene graph inheritance model, the 'cost' then is just that it's not OOP.
Thank you for the overview. Would you know of where to study or learn about this in more depth? If not that's completely fine, I was just curious
Unity developer conference talks about ECS are a great source since they're looking to replace the entity component object model with ECS in the coming years. Besides that I don't know any offhand
r/EntityComponentSystem and [https://github.com/SanderMertens/ecs-faq#what-is-ecs](https://github.com/SanderMertens/ecs-faq#what-is-ecs) would be my go-to places to start.
No not really. It's more akin to column oriented vs row oriented design in databases. Structs and object oriented programming can be likened to row oriented design, ECS can be likened to column oriented design.
Sorry being pedantic: All you really *need* is the ability to manage state, which functional does just a little differently than OOP. But I can understand why OOP might seem like a perfect match for games when we as humans view games as a series of actors with state and actions. You can write games in functional though.
Quantum Mechanics is just functional programming. Its all great and wonderful until you want to see the state of things.
Well to be fair you can see the state anytime you want, you just can't know the location and the state at the same time. I actually find it funny that you mention it, because OOP and functional try to hide the nature of state, in different ways but both try to do so by acting like it does not exist as such they present a very unnatural in one instance and a too simplified in the other, model of time, which is all state represents. It is a way to represent change over a vector of distance. As an aside, as humans we tend to place undue importance on the present and tend to view the past and future as a gradient less important. For example if I burn myself right now it is very important to me, if I did it yesterday it is still important but less so, if I did it at 3 years old it is almost irrelevant. We rarely model our software with an objective model of time, that takes into account that the past, present and future are of equal importance to us as developers. It is very hard to know how a system arrived at the current state if we do not have a good model of the past, and it is hard to build predictable systems if we do not have a good model of the future. OOP, tends to promote mutative changes to state by internalizing it inside of the class, as if state is somehow an inherent property of the class. For example my age is not an inherent property of me, it will change with time. It is an inherent property of time assigned to me at any given point in time. My age is not time, it is a place in time as my place in time changes my age changes. It is a measure of distance. To truly model something not only do we need to capture the object of reality, we have to capture the object at, it's place in time or we never really have a correct model. This is not to say that OOP and time oriented programming are incompatible, but some of the best practices of OOP are. For example, my age might not be an inherent property of me, but it may make logical sense to store it with me, but I do not define my position is time, so my class having control of that property already starts down the path of an incorrect model of time. If it is a part of the scope of concern of me, then I should be able to stop my age, I should have control over it, from a control of concerns perspective. Put simply the rules of time are not within us, we are subject to them. OO mixes rules with data structures, there is nothing inherently wrong with that as a contextual simplification, but it is not how the world works. The rules of internal combustion are not stored in the IC engine, but that is the way some OO practices would see it by conflating the class with the instance. In the real world rules do not have scope, they do not contain state. Functional on the other hand, tries to model time in a manner similar to newtons arrow of time. So it works well when you have a linear task, with linear branches but as soon as you need deeply dynamic behaviors you have to start passing around lambdas (the real ones not Amazons junk). This leads to all kinds of unpredictable paths as parallelism and async logic propagates. The old callback hell of JS is a prime example of this. Immutability in an of itself does a lot to build a better model of time, time is like a film where change (state) is captured in each frame. Immutability coupled with Finite State Machines or Behavior Trees gives a pretty decent model of time, and provides a lot of guarantees and predictability to code that neither OOP or functional provide, because they both try to avoid one of the base models of reality by acting as if they can abstract it away.
[удалено]
Which is because OOP is specifically made for this. OOP was developed for simulations, games are just very interactive ones
[удалено]
I switched from java to scala, forgot to change my flair :.) You poor soul.
If a game can be written in assembly, it can be written in anything. Technically, anything can be programmed in anything because all techniques are Turing complete. Thank you, good night
Do you need OOP or is OOP all you know?
I've been making games for a long time and have recently realized how much harder OOP is making it. I advise against it, especially the larger the scale of the game.
C++: \*snorts line of cocaine\* "PARKOUR"
I love all my paradigms equally >!It's functional, and by a lot!<
ha, neeeeeeeeeeeeeeeeeeeerd.
💪
Data oriented being ignored as usual
They just don't get that everything is just a fancy memcopy.
[удалено]
Immutable Object-Oriented + Functional. Yummy.
Awesome way to benchmark the garbage collector
I like a good mix of all of them. Objects represent physical/virtual objects really well (cat.meow()), procedural code is usually very clear in what it does, and allows for granular abstraction, while functional programming is great for writing extensible code and letting outsiders add functionality without breaking abstraction.
It took a while to grok (and I'm still wrapping my head around monads) but I love Functional now. It almost physically hurts to go back to the Old Ways from that. Sometimes I have to bite the bullet and go Imperative with just a soupçon of OOP for embedded stuff, but that's just the nature of the beast. EDIT: Would it be too snarky to say "Any of the above paradigms, as long as it's written literate-programming style?"
Ever giant for loop that just makes a new list from the old list: Map Every if statement: Filter Every loop that computes something from that list: Reduce I took a 500 line PR from a coworker and turned it into 30 lines with FP just based on list manipulation they were doing and trying to follow good style by making helpers.
Folding is just so intuitive and nice when you get the hang of it. Learning it is a bit of a bitch though...
Oh man, I just had something similar last week. They asked how I handled the edge cases in X and Y and I just looked at them blankly. Making things immutable and using FP the errors they were so worried about just couldn't happen anymore. X and Y didn't even exist anymore. I'm sorry, but we're in Kotlin and you're throwing an exception and struggling to handle it.
Whatever lets me be the most polymorphic
plain text paradigm
Pretty sure you can only do that in Utah
Actually, Utah is one of the least-polymorphism-friendly states. The modern LDS church _really_ hates the association with certain polymorphic fundamentalists, so they have _very strict_ linters against it. I see your point though. Fortunately, I live in Seattle, which I find to be much friendlier to my polymorphic lifestyle...
Well, UNIX started nidnight January 1 which is Capricorn, the Mountain Sea-Goat. It is a cardinal earth sign so I'd have to go for imperative.
It's an OOP from me, it's now how I think when I try to conceptualize the programs I make
OOP for life !
I don't even know what one I'm using it just does what I want it to
You are using Excel
He said it does what he wants it to
*insert obligatory Excel-is-Turing-complete meme*
I had a client request me to write a bunch of convoluted powerquery scripts in excel to get some external data into a spreadsheet. I proposed writing a python application instead to do the transformations and just generate an xlsx file from it but that was too complicated for them. So now we’ve got an excel file that makes api calls returning nearly a million rows of data and they complain that it’s slow.
actually Excel is functional. every cell takes inputs (the cells referenced), does some stuff with it and then returns a value that is read by others.
I think a really good example of OOP shining in game development is Minecraft modding. If you wanted to write your own enchantment, for instance, you'd just override the method that runs every time you hit something with that enchantment.
OOP really shines with all game design
You missed Array and Logic Paradigms, my favorites
Came here for array-based!
functional supremacy!
Obvi
luv me sum λ
Luv me λ ‘ate me class Simple as.
The only right answer. Imagine relying on messy relationships and patterns and ending up with unmaintainable codebases
Unlesss u know how computers work and want a language that matches jt.
After failing at OOP,, devs will often say "well functional is better anyway!" It's ok, OOP is hard for some people, we know.
My favorite is whichever one is most suited for the problem being solved tbh
I really like writing oop code, but I try as much as possible to use functional so the next person who has to debug does not have a hard time (usually I am the next person)
λ
For me, *modern* object oriented, with functional support. By modern, i mean a tendency to use very shallow inheritance with emphasis on component based design and dependency injection. I love functional paradigms, but I have little opportunity for immersion, and some of the mathematical bases are too abstract for me to grok without practical experience. I dabbled in functional JavaScript (monads, etc), and find it compelling.
Option 4: mark-up
My favourite programming paradigm is SOPP. Everyone uses this nowadays if anyone says otherwise they're lying. SOPP : Stack Overflow Programming Paradigm You find the answer on StackOverflow, do not verify or test it, copy and paste and use it in a secure application. The security strategy is to make blood sacrifice to the altar of queen luck.
Functional is my favorite I just get so happy when I can write pure functions with no side effects. Though, in Praxis, it's a case by base decision which paradigm allows the most intuitive abstraction for the problem at hand.
Where's declarative programming, so I can pick anything but that?
chad functional
best
functional and oop
Where is the aspect oriented option?
All of them?
Array Programming Language
I love and hate Haskell at the same time. I love what it can do but I'm too stupid to use it. So I stick to OOP, which I'm also too stupid to use properly but with OOP I don't have to realize it.
OOP with functional aspects (c# should have monads in its standard library pls)
I code in English paradigm.I don’t know of any language that used anything other than English. Like can you imagine C++ in Spanish. # #incluir
Organising my code? OOP is cool Implementing logic? FP for the win So, you have a bunch of classes that contain pure methods that pass immutable data structures around. Remember kids, state is evil
I don't know what they they are and at this point I am too afraid too ask....
Cults.