3. Return

I’ve entitled this post return because for me it signals a return to normalcy.  My past couple of entries have been a true roller coaster for my emotions, and it’s time to get back to what YOU are here for: A blog about CODE.  This post will be about returning in three ways, you already know the first. I’ll explain the second in the next paragraph.

Thank you for joining me. Here. In the second paragraph. A truly seamless transition. I thought it would be best to discuss my second reason within the second paragraph because the numbers are the same. When you’re coding it’s often REALLY important to check whether your numbers are the same.  My second reason for writing about returning is that a return can often be called a retreat. If we’re lucky, the retreat is strategic, but history tells us that too many retreats are inflicted upon us by outside forces. Perhaps what we call strategy is merely a salve for our sanity, sheltering us from the frigid winds of fate. I wouldn’t be able to tell you.  If you’re looking for those kinds of answers, you’ve come to the wrong place, because this is a blog about code and the lifestyle of coding. This entry is a retreat. We’re falling back upon what it is we know with certainty. Instead of casting about for elusive answers, let’s talk about and appreciate for a while the answers handed to us by a mechanism so simple & elegant we often forget it: The returning of a value from a function.

It turns out that there’s continuity here. A through-line. Maybe even a lifeboat. Since my last post, I think we’ve all felt a little adrift. I’m finding that a life led without promises can be a turbulent one indeed. It is, however, the price we pay for our ideals, and if there’s one thing we can take true solace in, it is that the C++ standard library serves as the strongest of masts. For it supports our lofty ideals, and guides us through our stormy emotions.  I want to shine a beacon tonight on std::async, which has served as a port in my storm as I pivot from promises. In C++17, it’s become quite useful, given that it’s now defined with std::invoke_result_t rather than std::result_of_t.  std::result_of lets arrays degrade to pointers, and prohibits function types, yet allows references to them. Too weird! std::invoke_result fixes this, and looks a little prettier to boot.

std::async returns a future. I know you’re wondering what the future will hold. Buddy, so am I.  For now, I’m holding onto the future tightly.  I’ll tell you something though. The future of this blog is bright. You can hold me to that.

And I will return.

Zak O.

Advertisements

2. Promises

In my last post, I wrote about promises.  Today I realize that promises are worthless.  You can’t sell a promise.  A promise cannot nourish you, and this world is filled with the jagged shards of broken promises. Today I am expelling all promises from my life and from my code base, and i highly advise you do the same. But don’t despair, because i haven’t given up on futures, and i have tremendous faith in the future of futures.

Let me explain.  A promise is inextricably linked with an expectation for future events. A promise divides, it introduces a schism into our paths, it is verbose, unnecessary, and forces us to associate with a state of failure. Granted, a promise is indeed the glue of the highest scale, and given our aspirations to conduct ourselves to our highest ideals, a promise might seem a worthy companion. We’d all like to walk with our promises, hand in hand as equals; but promises are the jelly of asynchronicity. Sticky hands!

I can hear what you’re saying. That you hold your promises with great sincerity and honor. That those who have fulfilled their promises to you have earned your trust, and those who have tragically fallen short have earned your forgiveness.  That promises act as a cultural touchstone, reassuring both in essence and in function. I hear you. But please, for a second, consider a world free from promises.  A world where intentions are conveyed with a single glance, our actions syncopated, anticipated, acknowledged, and appreciated.

A promise is a sentiment which acts not upon the world, but upon our expectations.  Indicative of the central position we hold our minds within the context of our universe. Perhaps this can’t be helped. We live in a world warped by our expectations for it. A twisting, where the progression of state is funneled through beings not of it, but in it.  It was Galileo who first conceived of a world with no center.  His prescient vision was awarded with successors and champions. Perhaps our failure to them is the biggest broken promise of all.

As always, the answer lies not within our minds but within our environment. Trees grow with water and sunshine. Without promises. So do we. If you keep growing, I will too.

I promise.

Zak O.

 

links!

http://en.cppreference.com/w/cpp/thread/promise

Broken promises–C++0x futures

https://hackernoon.com/6-reasons-why-javascripts-async-await-blows-promises-away-tutorial-c7ec10518dd9

 

Smart pointers

I’m writing this today because I think it would be easier to type out my thoughts on smart pointers rather than scribbling them down, like I’ve been doing this afternoon.  I’m realizing that on the highest level of writing, I want to code in a way that’s as clear as possible.  I’m sure that you, the reader, also want this. It’s good to code clearly at all levels, but the clarity of code on the level where control is flowing has a good reason for exhibiting its clarity in a distinct way.  The needs and concerns of a user are different from yours, the programmer.

We all understand that a programmer leads a wonderfully blessed and varied life, full of unexpected detours and delights.  However! From our places of privilege we must not forget the lowly plight of the user! While we are shaping a system, they are plodding through the course we provide for them, obediently completing the tasks we don’t care to complete ourselves. But that is what makes those tasks so important! Because all that the user is doing, is what the user is uniquely capable of doing! Think not of the user as a faceless drone, or as a valueless source of revenue, but rather as a human being, with the neural network of a human beings brain at your disposal!

That brain is precious! please don’t corrupt it with trash along the path it walks!  I know you are now looking at me, wondering how i could make a request so outrageous. After all, how are we to regulate the sanitation of an immaterial construction?  Immaterial even to us: We, who have unique powers to grapple with the concrete ethereal.  For the flow of control is shaped specifically from where it is we aren’t coding.  Builders build walls, after all, never homes.  My response, of course, is that the simple fact that only we can understand the hidden beauty in a walls construction shouldn’t deter us from imagining ourselves living within the walls themselves!

Again, how are we to do this? For we build our walls not of stone, but of something far stronger: Syntax.  For us to imagine a space without words after all is to imagine the void. It is to rappel into the inky depths! To this I must respond that the void, unable to be filled with our voices, must be filled with our love.

I’ve entitled this post smart pointers.  I was planning on talking about smart pointers.  But in the time I’ve been writing, I’ve realized that this blog post is about much more than smart pointers.  It’s about promises.  It’s about promises and futures, which is what you should give to a user. I was going to write about how whenever you create some resource to be shown to the user, you should give that resource some kind of smart pointer. There’s no reason, after all, that a user should be able to access it other than through a pointer. But now I realize that trust needs to be built to treat a user with love, and we build trust through promises. I’m hoping that you’re beginning to realize that too.

All of us are growing, and my advice is to only use smart pointers when pointing to an implementation of some class in another translation unit (pImpl idiom). That is a place where it really makes sense to use it, given that it’s a good way of keeping headers separate, and using a smart pointer directly eliminates the need to write a custom destructor.  In fact, I believe that to give a user a pointer would show “unique”-ly bad taste. A bad joke. It is best to avoid evoking our brutal and materialistic world through instruments as crude as direction.

I love you,

Zak O.