Anti Creation

A programmer does not need to have babies each time he needs to get something done. Stop having children, daughters, sons.. just command your computer to do something. This obsession with becoming pregnant with instances who inherit from their parents has gone too far. Programs are not people. --MopMind?

AntiCreation is an idea that humans do not think as in "creating objects" in life and in programming. In fact we hate the very thought of creating yet another child who will just be a maintenance nightmare with all sorts of inherited diseases and bad behavior problems.

When a man creates a vehicle in a factory, this is hard work. When a human has a baby, this is hard work. We should dread creating life forms. In fact the vehicle or baby is not created in actuality, but just merged with other existing materials on this planet. There is no creation exactly.

Man does not want to create anything if he doesn't have to - he'd rather just grab it and use it (or command that it be done). Especially if it is a FreeLunch.

  grabLunch() 
  eatLunch()

Creating the lunch would be silly - that's for the maid to do - and even the maid doesn't make the lunch, they just getTheLunchIngredients() from the store or the fridge. Making lunch is more work - disposing of the lunch and its wrappers and garbage is even more hard work. Disposing and creating lunches causes more hassles than if the lunch was just there.. as a command. giveMeLunch() and eatLunch().

With computer systems, we should reduce any creation work. We should just be able to command the computer in a SlaveOrientedProgramming manner.

This means that programmers should not create their objects (unless absolutely necessary, such as if the sandwich just isn't good enough in the FreeLunch and we have to initialize it with some mustard - but even initializing it doesn't mean creating and freeing it.).

Computers are Slaves

We should be able to command anything we want out of our computer without creating anything or disposing of anything (but in some cases we will dispose if it means getting to the store faster.. for example disposing of the person that is in your way blocking you from leaving the house). In some cases creation and disposable is useful, but in most cases we just should be able to commandHim to doThatNow. For example if we really want to do hard labour and work in a factory and create cars.. then we can do so.. but if possible it would be better just to getCar() and driveCar(). Even buyCar() is not required in SlaveOrientedProgramming because I can just stealCar().

This comes from a ModularWeenie? and ProceduralWeenie?. I use objects when I have to, and I use the heap when I have to.. but the stack is also great and some simple "commands without instances" at times are also great.

Jokingly, it also means that most life on earth was really not created... someone just commanded sh*t to happen and it did. Okay, only in some cases where absolutely necessary might have there been an instance - such as an atom. But maybe this atom was composed of other things and just commanded together, possibly.

Imagine, that you actually had to make breakfast as an instance?

  stealIngredients() 
  if makeMeBreakfast == false then cookBreakfastMyself() 
  eatIt() 

There is no creation of the breakfast.... there is no freeing of the breakfast. Even stealing the ingredients isn't necessary since we already have all of them (stored in a fridge module, and they never run out.. they only contain bugs and diseases at times). BreakFast contains the word "fast" in it and is a command itself. BreakFast isn't even a noun. It's an action. Break Fast. Break Now.

When you tell someone in real life to make you break fast, do you first have to create that person? No. A computer should make you breakfast without any hassles such as first the comptuer becoming pregnant and having a child in order to make breakfast for you. That's complex.

Creating Code

The only thing I'd argue we need to create.. is the code itself (but even that is just thoughts commanded on to paper). We have enough creating and hard work to do so stop requiring so many instance creations and freeings please. We spend enough time creating code, so why create instances if we don't need them?

Garbage Collection

Garbage collection helps half of the time.. but even better is something that doesn't require freeing or creating.. just declare and use. As a bonus, in many cases these declare and use (stack items or reference counted items) are faster than any other type out there. Wait, I get a FreeLunch that is also better? How can a FreeLunch be better than one that I have to make myself? In some aspects, the one you have to make yourself can offer more customization.. but half the time I just need to eat the good FreeLunch since it is GoodEnough and. For super customization of your own instancee.. many times YouArentGonnaNeedIt.

Consider this situation where we just need a fricking list of strings:

  program mylist;

var s: StackStringList?;

begin s.add('item1'); s.add('item2'); s.add('item3'); for i:= low(s.items) to high(s.items) do writeln(s.items[i]); end;

Compare the above simple code to this nonsense:

  program mylist;

var s: TStringListObject;

begin s:= TStringListObject.Create; // dangling pointer! Dangerous s.add('item1'); s.add('item2'); s.add('item3'); for i:= low(s.items) to high(s.items) do writeln(s.items[i]); s.free; // how does this help us? the instance does what for us? s:= nil; // how does this help us? the instance does what for us? end;

Thread programmers will argue the instance helps! it does! which is nonsense. Put the item in a command. Garbage collection programmers will argue that there is no dangling pointer so garbage collection solves the worlds problems. True to an extent except that the above solution doesn't even require the garbage collection and doesn't require any instance. JustDoIt for crying out loud. Put the item in a command:

  procedure threadSafe_SoThere;
  var 
    s: StackStringList?; // or reference counted
  begin
    s.add('item1');
    s.add('item2');
    s.add('item3');
    for i:= low(s.items) to high(s.items) do writeln(s.items[i]);
  end;

Encapsulation? Need to initialize something within the list of strings? Fine. Do so. Say so. You don't have to shove that code into a Create() constructor.. you can put it in a more descriptive Init() procedure. Encapsulation doesn't just exist in OOP.

Inheritance? Some times you just need the damn stringlist. Sometimes you need an integer list with sort capabilities (as opposed to an Array which is just too simple). But a stringlist doesn't have to have babies and children all the time. If it does, you can wrap it and extend it.... either by reusing the existing one and adding more to it (using an object without an instance on the stack, which some argue isn't a real object.. so let's call it a good useful structure that can be extended).

Memory Creation

We do have to allocate memory sometimes, but it can be wrapped and abstracted. We shouldn't be creating it over and over and over again. Machines and tools are reused.. not recreated over and over again. Databases are reused.. not recreated from scratch over and over again. Memory allocation can be wrapped into modules and commands (and reference counted types).

Creating and freeing memory in production code is NeedlessRepetition and can cause bugs. Better instead wrap it into safe commands and modules. Garbage collection isn't always even needed if the stack is used or if the memory allocation is wrapped into a command that one can use over and over again, or if reference counting is used.

Bad Influences

Java has bastardized programming by obsessing over instances of this and instances of that, without any stack, nor VAR (by reference) or OUT params, and no simple reference counted types. The joke in Java is that one can do functional programming if he just creates more object instances.. which defeats the purpose of functional programming just being there. The other joke in Java is that one can do imperative programming if he just creates more object instances.. which defeats the purpose of imperative programming which is to have commands that are just there ready to use.

See also

Database

Thankfully, each time we connect to our databases we do not need to create instances and childrens of the databases. The database is just there.


Another way of looking at it: when you do need to allocate memory, it isn't creating any memory. It is just getting some available memory. We cannot create memory chips inside our computers. If we could, though, that would be interesting.


Another thought: a database table is created once.. and reused over and over again... querying it through relations. Not everything needs an instance which is continually recreated and freed over and over again. For example if you have a database to access, just access it.. skip the nonsense of instantiating stuff first to access something that already exists! Creating tables is fine, when you need them.. but instantiating an object to access the database is ridiculous, considering the database is already there.


The whole creation idea is abstract.. and has been taken too far. It's become a hyped buzz to now "have an instance" of pretty much anything and everything.


Functional programming makes use of tricks so there is less New() Create() Dispose().

See FunctionalInImperative for some tricks on functional programming using imperative languages.


Should we have abortions before our objects are born (created)?

Objects (structures) should be initialized. A baby is initialized by mixing a few existing ingredients but you can't literally create one from thin air.

Babies live, and then they die... are structures destroyed?

They are just moved elsewhere.. and forgotten about. Someone I know lives in a coffin, for example, whom no one visits any more. Matter is not destroyed.


See also: TableOrientedProgramming, ModularProgramming, MopMind?


EditText of this page (last edited June 2, 2008) or FindPage with title or text search