Project 'O' - (my machine programming project)

Okay, so a while back in Feb 2020 (that seems sooooo long ago now) I did a post about what I was going to do in my "week off".... as you can imagine, a lot of it didn't happen.  In fact, I think I just ended up spending the week working on my custom car.

However, there was mention within the post of an "OLD" project that I'd been kicking around for a year or so named Project 'O'.  Here's the description that I gave then:

https://tonyisageek.blogspot.com/2020/02/a-week-off-worksort-ofproject-o.html

--------------------------------------------------------------------------------------------

3) I can finally get my mindset back into Project 'O'.  Now that IBM and Red Hat have finally blurred into one, I can get to grips with what that actually means.  The big push is all about OpenShift...."what's that?", yep, that's what I wanted to figure out so off to YouTube I went...and then received mixed messages depending upon how 'old' the videos were.
My take on it is that OpenShift is just a nice / simpler / easier management tool for managing Kubernetes Clusters (that contain your Docker Containers, that within them contain your application execution runtime code).  Lovely.  The K8s part means you can now run your containers anywhere you want to, on whatever Cloud platform you want, or even OnPremise, (y'know like we used to do before all the Cloud hype kicked in).

Wouldn't it be great if you had a really easy, simple way to design and build applications and then deploy them to wherever you need them to be deployed to, without having to faff about learning what and where to stick values inside .yaml files?

Well, that was a tiny part of the original Project 'O' scope.  (I have the specs drawn out on bits of paper someplace in the garage, I think....probably covered in gearbox oil by now).  I was ambitious, as I always am in my vision and scope, but I could see Project 'O' becoming a really useful tool.

I have issues with coding.  I am frustrated by the fact you have to type lines of code.  You can only go as fast as your little fingers can move and press switches on a keyboard.  You also have a lot of typos.  You forget a ; or an incorrectly placed <tab> and kaboom! the code won't run.  This is silly.  Yes, I know you can get umpteen plugins for VS-Code that'll re-type your code as you code, so it's all laid out nice and consistent and there are no silly mistakes, but that still involves typing.  (btw - why do you think M$oft loves you having all that code nice and consistently laid out?  Would it be great if you owned the worlds largest code repository, you could use ML algorithms to learn and extract code from the largest data set on the planet....I digress....but think about it....I know I have, I even found quite a few whitepapers on the subject from M$osft research, interesting ideas)

I originally had a starter demo for Project 'O', where I used a chat-bot to interact with you (think of yourself as a pre-sales engineer or even, shock-horror, a sales person), you go through a conversation of what you want to build as an application (that was quite an extensive conversation design that I had to build out, in the end I hit limitations as I could only have 1 design and I wanted 4+ and that "was still in R&D and not available yet" (sigh) ), and from the information gathered, I would then use my small but efficient repository of templated JavaScript code to output the code that was needed.  I would then wrap it up into a Docker container, then auto-deploy into a K8s cluster and push it out onto a Cloud Platform.  (I chose IBM Cloud as default, for obvious reasons).

This skeleton seemed to work rather well.  It was basic, but from a sales person defining what they wanted via conversation (either typing the requests, or even via Speech...yes, wow! now we're being all very 21st century Star Trek style), you could define what you wanted and within 10 minutes you would have a basic database connected web application up and running and functioning.

I was then looking into adding to the conversation design the concept of 'add an API integration', where you could request to connect out to web based REST APIs and gather data from other sources to add into the web application.

....and sadly, that is where Project 'O' stopped....and started to gather dust.... maybe I should discuss it with more people to see if I can get it kick-started again, I'm sure there is a bigger need for something like this and who knows, it might start to get it into the current IT population that we need LESS COMPLEXITY to achieve great things, NOT MORE.   (nice loopback to OpenShift thinking there)

--------------------------------------------------------------------------------------------

Now, since then I've learnt a hell of a lot more about OpenShift.  It wasn't what it was touted as by all the various marketing schpeel and mis-information over the internet.  Its basically a JVM for SaaS apps.

It's not what Project 'O' was about.

I was reading this article today: https://www.theregister.com/2020/12/04/intel_labs_day/

and I got to the section titled: Mankind versus the machine

OMG! What they are describing there IS Project 'O'....this was my vision from back in 2018, this is what I started building in 2019, this is what I put down and got distracted by the day job!

Okay, I'm going to be BAD and cut&paste the text from the article and quote what the Intel people were saying - I don't usually do this sort of thing... but I feel I have to....  This resonates so much with recent posts I've been making, my observations about the IT industry, skillsets, etc..etc...

"Rather than trying to push machines to do more, it's focused on making people do less.

"If we're successful with machine programming, the entire space of debugging will no longer exist," explained Justin Gottschlich, principal scientist and the director and founder of machine programming research at Intel Labs.

Gottschlich goes on to describe Intel's "blue sky" vision for the project as one in which few people actually do what we now think of as programming. In most cases, he suggests, people will just describe an idea to a machine, engage in a bit of back-and-forth to fill in the blanks, and then wait for this AI-driven system to generate the requested application.

"The core principle of machine programming is that once a human expresses his or her intention to the machine, the machine then automatically handles the creation of all the software that's required to fulfill that intent," said Gottschlich.

Machine programming is a part of the ongoing effort to develop low-code or no-code tools, generally through some form of automation. There are a variety of reasons for doing so, mainly having to do with supply and demand.

Companies like to talk about democratizing coding, as if they should be applauded for civic altruism. They tend to be less vocal about the fact that more coders means more competition for programming jobs and the ability to pay lower salaries.

Gottschlich's spin on the supply problem is that industry trends have made the talent shortage worse.

"There are two emerging trends we observed that work against each other," he explained. "First, compute resources are becoming more and more heterogeneous as we specialize for certain types of workloads. And that requires expert programmers, what you might call ninja programmers, [who] deeply understand the hardware and how to get the most out of it."

"But at the same time, software developers increasingly favor languages that provide higher levels of abstraction, to support higher productivity and that in turn makes it hard to obtain the performance that the hardware is inherently capable of," he added. "And this gap is widening."

In other words, people's passion for Python is why tech companies can't find enough C++ experts who know about GPUs, FPGAs, and other technical specialties.

Gottschlich pointed out that only 1 per cent of the world's 7.8bn people can code. "Our research in machine programming is looking to change that 1 per cent to 100 per cent," he said.

But the kind of programming he expects people will do is not what they currently do.

Imagine a painter having to first create the paintbrush, the canvas, the easel, the frame, and the paint itself before creating any actual work of art, Gottschlich suggested. "How many painters, realistically, do we think can do all of that?" he asked.

"I would argue that that number is somewhere between very few and zero. But this analogy is similar to what's required for how a lot of software is developed today."

At the same time, people are the problem. They make mistakes and that has a productivity cost. Gottschlich cited a 2013 Cambridge University study that found US programmers on average spent half their time debugging.

"Debugging is slowing our programmers down," Gottschlich said. "There's a loss of productivity. And debugging by nature means that the quality of the software isn't acceptable, otherwise we wouldn't be debugging. So in some sense this is exactly what we want to fix.""

Right, I have 2 weeks off work over XMAS/New Year - this time I AM GOING TO WORK ON PROJECT 'O'..... I'm way too late to the game now, I am kicking myself for not pushing through with this back in 2019 when it could have had more FOAK impact.... but, I already have a LOT of the foundation work knocking around, it's a bit like I have 1/2 a kit-car still mocked up in the garage, I just need to update a few things and get the car built.

Challenge accepted Intel. challenge accepted.  It's time I got Project 'O' back out of the cupboard and slapped a few senior exec's at IBM with it to get some funding and build an offering that can utilise all of the IBM AI services and also run on OpenShift :-)

....

also, there's a whitepaper that I can use as justification reference (cheers Intel!):

https://arxiv.org/pdf/1803.07244.pdf

...extra ref about a min-rant I had about 4GLs back in July: https://tonyisageek.blogspot.com/2020/07/will-ai-kill-of-coders-i-doubt-it.html

The "Machine Programming" concept needs to not fall into that pitfall of vipers.