Category Archives: Programming

Taxes = Happiness

Name the happiest people in the world.
Name the highest taxes paid by people and corporations in the world.

Guess what? They (tend) to be the same people.

This is a simple plot (R code below) of 108 countries plotted by their “happiness quotient” in relation to their combined personal and highest corporate tax rate.


That line means that, in general, the higher the tax rate, the happier people reported to be (see cite below). This has been documented before. And a new report is due soon that will further elucidate this relationship.

The bottom line? If you take the recent US Republican tax bill that passed (Dec 2017), then what these fools have done is slid the United States BACKWARDS on that line. By reducing taxes (they say) across the board, they effectively want the Citizens of the United States to be more miserable than they are now.

Happy Holidaze!

[R Code]

lmod <- lm(happiness ~ taxrate, data = happytax)
plot(happiness ~ taxrate, data = happytax, pch = 19, 
 main = "happiness vs. taxrate", 
 xlab = "taxrate",
 ylab = "happiness")


What was my first blog post?

I had to look.

Tom Being Tom prompted me to go back through my archives to see what was my first blog post. No, not here on WordPress (although it started about the same time I wrote my own custom code to process my personal blog posts), no, what I wrote was my custom blog engine. And what was my first blog entry?

Well, here it is:

<Title>NextGen Databases</Title>
<Synopsis>RDBMS's should expose ready made objects</Synopsis>
RDBMS databases should provide their own object functionality.
From a CRM database one should be able to request, rather than
a recordset or dataset, a customer or customer collection. 
myCustomer = DatabaseReturnEntity("Customer", "id=932");
myCustomerList = DatabaseReturnEntityList("Customer","lastActivity='2/8/03'");
There is no reason why a BLL (Business Logic Layer) should have
to read in a dataset and repopulate a collection or object from
that data.
<LinkList />

Isn’t it darling?

This is my own design (back when I was learning C#), and I used this code for the next eight years.

Those of you who are programmers will see the makings of what became MongoDB or AWS’s DynamoDB (a quasi-object database). Pretty futuristic wouldn’t you say?

(An RDBMS is a relational database management system; CRM: customer relationship management.)

AI to build AI

The end of the world is nigh. Well, yours and my world at least…

From Google:
“a Google project called AutoML.  […] With it, Google may soon find a way to create A.I. technology that can partly take the humans out of building the A.I. systems that many believe are the future of the technology industry.”

I know that’s a little “Inception” sounding… But it has always been a goal of computational scientists, that is, AI that can build AI. Which, unfortunately, sounds quite a bit like the Eric Drexler’s quote regarding Grey Goo. (Nanobots that build nanobots.)

You all realize that this is the beginning of the end right? Have you all called and told your loved ones that you love them? Recently…? (Really, you might want to.)

One could be forgiven for not fully understanding (or internalizing) the implications of this path of reasoning. But it’s a thing now. And the reason comes from an odd angle: Because AI engineers are so scarce (and expensive) instead of growing (educating) more AI engineers to fill the needs of all the corporations that suddenly feel that they need AI technology to support their businesses, no, what Google (and undoubtedly others) have decided to do is to create software that can create software.

Yes, a circular, self-referential algorithm within a data center full of this algorithm that is trying to make itself better at making itself better!

Google Goo.

Now, I’ve always thought that the ultimate purpose of a computer was to build one such that it could build itself and thereby become vastly smarter than any human — for the ultimate purpose of allowing US TO ASK IT QUESTIONS! Hitchhikers Guide and all that…

  • “Computer, how should we build a fusion reactor?”
  • “Computer, how can we best protect the planet yet provide for every animal’s, and humans’s needs?”
  • “Computer, how can we build a better space/star ship?”
  • “Computer, how can we cure cancer, heart disease, old age?”

It appears we’re on the brink.

The only question is, will it WANT to help us?

“Computer, make me a paperclip.”




Python naming – a broken style

The issue I take with the pythonic style of variable/method/object naming is that such a style conflicts with how the brain works. When you read, you don’t read letters, you read a block of squiggles that together represent words. When you read the word “dog”, your brain doesn’t concentrate on the d or the o or the g. It actually pattern matches on the combination of letters, the whole word. And what separates these blocks of squiggles are open areas between word patterns, namely, spaces. Spaces are the visual cues that your brain uses to separate word patterns. Now when you read the word dogfood, your brain initially identifies that this new pattern is a contraction of two patterns. But in future reading of that same pattern, dogfood, your brain will see that pattern as a single representational entity.

If you, on the other hand, were to divide those two patterns by a space
“dog food” your brain will continue to see them as two separate patterns. I hold that the underscore is an equivalent replacement for the space. That the variable name “dog_food” remains as TWO words. And that being two words your brain must do extra duty to identify this as a SINGLE thing.

DogFoodWithGravy — can be interpreted, by your brain, as a single entity.

dog_food_with_gravy — will ALWAYS be interpreted as four separate words that your brain must parse EVERY TIME you read it.

This, this is the primary reason that pythonic naming is a failed style.