The Death Penalty: Almost as Dumb as Letting Murderers Off Without Consequence

The death penalty is almost as dumb as letting murderers get off without a consequence.

Here’s the reasoning:

The death penalty is a 100% permanent punishment. You cannot take it back. Once a person is executed they are dead.

So, it stands to reason that if a country wants to use the death penalty the judicial process for sentencing people to death in that country should also be 100% — correct, fair and fault free.

This means 100% correct and honest witnesses and evidence. 100% honest and competent police officers, judges, lawyers, and prosecutors.

In case you were unaware; the people listed above are also human beings. They are not gods, so, they are not 100% correct 100% of the time.

So why use a 100% permanent punishment and allow people and systems that aren’t 100% fault free decide when and on who to use it?

Is the reasoning that a few innocent people sentenced to death and executed are an acceptable cost?

If you answer yes to that question, remember the murder victims were also innocent.

Why spend all this money on a justice system, trials, and retrials, lawyers and prosecutors, just to risk sacrificing some more innocent people?

Why not just drop the whole prosecute-murderers-thing and tell the victims families that some innocent people dead is an acceptable cost?

OK. That’s obviously an exaggeration. I am sure in most cases actual murderers are executed.

The problem is that nobody knows who’s innocent and who’s guilty with a faulty justice system (not 100% correct 100% of the time, you know, like, run by imperfect humans).

I think it’s common sense and decency to not dole out 100% permanent punishments in an imperfect world.

How about that temporal programming?

Did you read my article on temporal programming?

Cool, huh?

Did you manage to make temporal programming in Java work?

No?

You need a quantum computer, of course, and Java 15…

Don’t believe me?

Good!

After all, yesterdays was April 1st!*

😛

* Ok. Come to think of it, with time zones and all… I am guessing the post was technically published on mars 31st in, e.g. the Americas… :÷|

Temporal Programming

Have you ever wanted to know information beforehand?

With temporal programming, you can!

For instance, when reading an input stream, you want to show a progress bar for how far along you’ve come. But, in order to know what percentage of the stream has been processed, you need to know how many bytes it contains.

Some streams are based on files so you can use the file to figure out the size. The same goes for some streams from web servers. But then there are other streams where the size isn’t known beforehand.

Temporal programming was invented for them.

Here’s an example:

temporal long streamBytes;
final ProgressBar progressBar =
  new ProgressBar("Reading stream",
  streamBytes);
long totalBytes = 0;

try (final InputStream is = ...) {
  byte[] buffer = new byte[1024];
  int read;

  while ((read = is.read(buffer)) > 0) {
    totalBytes += read;   

    // do something with bytes
    // ...

    // increase progressbar
    progressBar.step(read);
  }

  // set the max of the progressBar
  streamBytes = totalBytes;
}

All the magic is in the temporal keyword… much like the native keyword, it makes “stuff” happen behind the curtain…

At first, the value of the temporal variable streamBytes isn’t known, and in normal cases, this would create a compile error. However, the value of streamBytes is set at the end of the program, and can then be used in the beginning much as if the variable had been set from the start.

Pretty cool!

Of course, this example with a progress bar and a stream is much less exciting than an example with a stock ticker, for instance…

There’s money to make there!


Header image: By fdecomiteTunnels of Time, CC BY 2.0, Link

%d bloggers like this: