The problem is that most programmers today aren't apart of either of those groups but apart of a third, totally separate group: programmers who pick and prod and then glue lines of code together.
I just have one smallish question. Is the need to bench then add an actor the only way you "allow" transfer of children between parent actors?
In similar systems that I have constructed in the past, I have used a number of methods for passing actors in different states.
Pass a fully instantiated actor via a transfer process. Nothing changes for the actor, beyond reassigning parentage.
Pass a cleaned actor via a similar process to the bench and add process. This was used to allow an actor to be reduced to a resting state as it were. In most cases you could think of it as a resurrection method that allowed discarded actors to be reinstated with only specified base properties in place.
Anyway, I don't use Lua at all, but I like these type of actor messaging models. I look forward to reading through the rest of your documentation once it's done.
>Is the need to bench then add an actor the only way you "allow" transfer of children between parent actors?
Currently, yes. Since this is sort of an entity component system and that actors can always create more children anytime they want, I suppose I just always assumed that actors could be "spun-up" with any sort of functionality and then deleted when not used.
Benching/Joining an actor is more for handling errors at runtime or for debugging ("If I temporarily remove this actor will it solve my issue?").
>I'm guessing your comments are based on seeing a lot of poor practices masquerading as OOP which affects what you think OOP actually is
I personally feel that the current OOP model eventually devolves into the bullet points you listed given enough complexity.
One reason why I think this occurs is that there is no concept of a 'message' in OOP, only methods or functions of a class. There's explicit coupling even when calling a method with no arguments because you know the method is valid for that object.
Contrast this with the example of the 'listener' in the room. A speaker broadcasts his message but the independent agents ultimately decide what to do with that message.
The OOP approach calls "object->listen" on each listener. My approach simply broadcasts the message and lets the objects determine how to handle it themselves.
> One reason why I think this occurs is that there is no concept of a 'message' in OOP, only methods or functions of a class. There's explicit coupling even when calling a method with no arguments because you know the method is valid for that object.
This is specific to early-binding languages like C++, Java etc. Look at Smalltalk or Ruby, and this is not true in the general case. E.g. Ruby ORM's tend to dynamically create classes and methods at runtime based on analyzing the database schema of the database you connect to. You literally won't know if a given method exists until you've connected to the database. Even then, there are no guarantees - depending on framework it may e.g. let your call hit "method_missing" first time (or every time) and optionally then define a method (or it may continue to handle it via method_missing, but defining a method can be much faster, depending on situation)
> My approach simply broadcasts the message and lets the objects determine how to handle it themselves.
So OOP the way Alan Kay describes it, in other words.
Not all actor based languages can broadcast messages to e every actor. Example: Erlang sends messages to a given process. To broadcast to many processes you must know the pids of all of them. Or send to a "bus" process that knows the pids of every one else. Performance bonus (maybe) if the bus knows which process will be interested in a given message. Not much different than having a central registry of objects acting as a bus and dispatching method calls. Furthermore you can have tight coupling with message passing too.
>One reason why I think this occurs is that there is no concept of a 'message' in OOP, only methods or functions of a class.
If you mean there is no formal/explicit OOP syntax in C++/C#/Java etc for a "message bus" or "queue" for a decoupled publish/subscribe type thing, you're right. Yes, Golang/Erlang have that concept a little more "baked" into the language.
But that's still orthogonal to the supposed OOP flaws you brought up.
The C++/C#/Java approach to the missing "message" functionality would be either to create a class with a managed buffer to "hold messages" for other classes to write or read from... or use a library that interfaces with an external messaging bus.
His point was that sometimes business owners can get used to applying a template. It's a bookstore so it gets the bookstore template -- 4000 books and a coffee shop, right? Instead of applying this template, an owner with a pulse on the business can see what their customers are doing/buying/wanting and can change accordingly rather than apply a template.
Way to take a quote out of context (literally cutting off part of a word). Here's the surrounding sentence:
"Some of the most original games in recent years have been made by women. Kim Swift was the lead designer for Portal, which one game critic called the first nonphallic first-person shooter."
Oh look, the full quote is appreciating a female game pioneer, and your mangled phrase was from a singular game critic. Also, it makes sense. Instead of shooting bullets, you're shooting portals. Seems pretty non-phallic to me.
> Instead of shooting bullets, you're shooting portals. Seems pretty non-phallic to me.
What's phallic about bullets?
Are women not allowed to be interested in small arms? The Soviet Union deployed women as snipers to great effect in World War II, and the idea that only men could be violent and warlike is itself gender-biased to those who look at history.
I can't tell if you're serious. Do you really not see the distinction between bullets and portals in a phallic vs, non-phallic context? You are literally shooting phallus-shaped objects with the intent to penetrate your target. On the other hand, you are shooting oval openings into which things enter.
This isn't very complicated or contentious from any angle I can imagine. Unless you're coming in with an agenda, and take offense to the idea that certain types of games might be traditionally male-oriented.
> "On the other hand, you are shooting weird milky looking things out of a phallic object, then thrusting your player into a rather vaginal opening."
If bullets are "phallic" (despite rarely even having in-game models) then portals are "vaginal" and the primary game mechanic is to have your player "penetrate" them.
In reality, all of this is just pseudo-intellectual Freudian bullshit.
The phrase isn't wrong, though. The vast majority of FPSes involve you playing a man, shooting other men. Sometimes it'll include a woman, but only if she's very, very scantily clad.
Reducing men to the physical expression of their sex is more sexist than anything else mentioned in the article. I will grant you "masculine," "macho," or even "puerile," but "phallic" is simply offensive.
If his goal was to beat high school kids and he did just that, then yes. If your goal is to pick locks and you successfully pick the locks you want to open, then you're good at picking locks.
Can you be a good programmer without being the best programmer or even a world class programmer?
When you factor in things such as "I'm a skilled programmer, but I don't know Ada." Are you still a skilled programmer? Sure, you're quite good at Ruby and Javascript. But you don't know Ada. Why not? Because your goal was never to learn every programming language.
If you want to pick every lock available to you and you can do so quickly and successfully, you're a skilled lock picker. Buying harder locks just to show you can pick them is an academic feat, not necessarily a real-world skill. Skill is just aptitude in doing something successfully.
> When you factor in things such as "I'm a skilled programmer, but I don't know Ada." Are you still a skilled programmer?
"A programmer" is not necessarily "A person who knows Ada".
You're trying very hard to play semantics and it's not working for you. You don't get to call yourself a skilled swordsman because you sliced up some virtual goblins, simply because the only things you felt like slicing up were virtual goblins. That's not what skill is.
Neither does skill require some asinine qualification of "real-worldness". We can generally agree that many skills are non-transferable or narrowly applicable, such as skill in playing Starcraft or picking "academic" locks. But you're not a skilled carpenter or metalworker if you go out and buy furniture from IKEA. A person who walks casually across the stage doesn't qualify as a skilled dancer unless he actually does some dancing.
"Buying harder locks just to show you can pick them" is akin to "choosing a more difficult project to code up" or "requiring that your algorithm be more performant than it was previously".
Saying that raking locks is skill at lockpicking is like saying you're good at breaking into computers because you have a sledgehammer and a knowledge of where the data center is. Or brute-forcing a password. Yes, it works. That's great. "Doing something successfully" isn't skill.
And you're trying really hard to make things more complicated than they are. A skill is not a complicated thing. Allow me to put the words in your mouth that you are struggling to say: "not a true Scotsman".
No, but you may be a great "Hello world in C" writer. People can be insanely fast at solving Rubik's 3x3x3, but that doesn't imply they are good at puzzles in general or even at a 4x4x4.
Living in a society is about being able to reason with others.
Instead of trying to skirt issues and involve authorities in hopes to solve problems, it usually is better to confront the person themselves.
Your example went straight to an extreme. It doesn't have to be theft, or murder, or an assault that makes you "upset" at them. Maybe you feel wronged because they said something in public that you wanted private.
Authorities have their place, but many problems can be solved by not involving them. I'd also say that many more problems are caused because people didn't want to confront one another.
>Maybe you feel wronged because they said something in public that you wanted private.
You cannot go to authorities with "he called me a butt."
The issues here are a subclass of "crimes and wrongs that authorities would address." My example is not going to an extreme. Have you ever confronted a criminal? How did it go? Do you see where it could have gone worse?
I once confronted the guy that broke into my car and stole my stereo. He gave everything he still had back (he didn't have the CDs anymore).
For what it's worth, I only went to him directly after the police shrugged it off and wouldn't pursue it. I gave them his address, description, other crimes he had been involved in (drug dealer), etc. They didn't care, and when the crime happened couldn't even be bothered to lift a couple of prints.
I was so angry when he said "sorry man, I figured your insurance would cover it, no hard feelings". But, looking back, he was just dumb as hell and stealing from a friend of a friend you met once made sense to him...In this sort of situation, handling the issue directly worked out for me better than going to the police.
Public order offence here; UK. But I don't see how it makes sense to do that over a little tiff, or even how it could be practically enforceable unless the policeman was right there. I mean what are you going to do; film all your life incase someone says a mean word to you?
Well, in my country's case, you could have a witness willing to testify as to what he heard. Happens quite a few times, especially from litigation-trigger-happy people.
I'm saying that there is no reason for to be as noteworthy as it is right now. As Bezos himself says,
“this is early, this is still years away.”[1]
Yes, 30 minute drone delivery would be big news. That Amazon is in the very early stages of an R&D project to look at the feasibility of it is not. In any case, I am staking an early bet that you'll have your Amazon products delivered by a self driving van before you'll have a drone do it - especially if you live anywhere outside of a major metropolitan area.
