Sound off!
I like clean code ’cause it cannot lie.
Technobabble makes me cry.
But with a clear interface
The domain’s in your face
Intentions fall into place
You get stunned
Like getting slapped with a map
Anything less is just crap
(with apologies to Sir Mix-a-Lot)
Talking about Three Rules for Domain-Driven Design at O’Reilly Software Architecture Conference Wednesday, April 5 at 1:15pm Eastern Time in NYC.
Sound off!
Did you ever ask yourself a question that was so interesting that finding the answer sort of turned into a mini-obsession?
For me, that question was “What does software look like?”
Not what can it look like, because obviously software has no predetermined visual form, but what would it look like if it had a natural, organic, 3D structure? A structure that was the same regardless of scale, from a simple Hello World to a multi-million line production system?
And what could we learn from such visualizations?
Drawing on data science as well as more traditional software analysis techniques, I began to explore this interesting visual world. The initial intent was to simply find ways of looking at software systems where anomalies would be easily spotted, as easily as you might notice a broken branch on a tree in a forest.
Slowly, connections between software visualization, software archaeology, latent semantic analysis, software refactoring, and domain-driven design began to form… along with some hints at Much Larger Problems, and study of Deep Learning.
This research is ongoing.
Update:
Sound off!
“LIFE IS REALLY SIMPLE, BUT WE INSIST ON MAKING IT COMPLICATED.”
— CONFUCIUS
Object-oriented programming evolved from the combination of a few simple yet powerful concepts. This overview explains them succinctly.
Reading this document out loud takes me about 90 seconds, hence the title.
Lines of code are collected into procedures and used to perform actions such as:
Sometimes, some of the data elements are related to some of the other data elements, and it is convenient to group them together into a data structure, which can then be manipulated and addressed as a single unit.
Now our procedure can take a data structure as its input. The procedure may alter the data in the structure and/or produce another data structure as it output.
Occasionally, we notice that some procedures are only concerned with a certain kind of data structure. It is convenient to group these procedures together with their data structure, and call it an object. This allows us to refer to a data structure and all of its associated procedures as a single unit.
The procedures associated with an object are called methods.
The elements of the data structure for an object are called properties.
We may find that we need a lot of objects that behave the same but have different values for their data elements. A template for creating objects is called a class. An object is said to be an instance of its class.
If we politely request an object to do something, instead of rudely executing its procedures directly, this is called message passing – even if no actual “message” is transmitted.
The joy here is that many different kinds of objects may respond to the same message in different ways; this is called polymorphism.
For example, we can ask many different kinds of machines to Start, and each responds appropriately. We see this every day: many different machines around us have some kind of a Start button, but exactly how they go about starting themselves is entirely up to the particular machine to accomplish.
We may notice that one class is very much like another, sharing a lot of the same data elements and procedures. So, instead of copying and pasting code we let one class inherit from another: the subclass inherits from the superclass or “base class”.
In this way the subclass has access to all of the data structures and procedures of the superclass, and can augment or override them as necessary to define the differences between the base class and the subclass.
This process is often called differential programming; it is a very powerful and convenient way to reuse code.
That’s it! These are the basic concepts of object-oriented programming (OOP) – simple, subtle, and very powerful!
Of course, they can be misused and misapplied. This is where experience and practical advice becomes extraordinarily valuable. It’s easy to learn the definitions. It’s more difficult to know how to apply them. It’s far more difficult to recognize and fix it when you have misapplied them!
Click here to download Object-Oriented Programming Explained in 90 Seconds in PDF format.
Sound off!
It’s difficult to prank anyone these days, especially on April 1st. We gave it a shot on this blog yesterday with Steven Lowe’s article on the imaginary programming language and platform called Unicorn. Click here in case you missed it.
My school background is in I.T., not Computer Science. Steven on the other hand has been programming long before the ubiquitous computer in our homes connected to telephone jacks. So when I was quizzing Steven about software and why some program couldn’t do something, he replied, “Because that would make it magical software.”
From there I had the idea of magical software called Unicorn. When I was creating an editorial calendar for blog posts a few weeks later, I wrote down “Unicorn: The magical software that never has bugs and adds features before you know you need them” as an article topic.
One of our primary services at Innovator is custom software development. The premise of the article was to explain why that magical software will never(?) exist and consequently, why there is a need for custom software development.
It was Steven’s idea to turn the topic into an April Fools Day post. But Steven, having a highly creative and imaginative mind, as well as writing Sci-Fi stories on the side, took it further.
Instead of the usual blah blah blog post, he imagined Unicorn as the centerpiece of a Sci-Fi story. Then that funny thing happened that happens to writers when they create fiction; the characters go off-script of the original plan, diverting in different directions and spawning new ideas and connections.
Steven’s mini-epiphany was that yeah, you know what? Writing software is like writing Science Fiction. Within that Sci-Fi story are places and technologies that don’t currently exist. They have to arrive from the imagination.
You have a problem to solve, say, the need for artificial gravity within a spaceship. You create something that doesn’t exist, give it a name, and then begin to imagine how it might work.
Steven says, “First you have to imagine something that doesn’t exist that solves the problem at hand. Then you have to explain to yourself how it works…then you make it work.”
The people doing this imagining are probably not writers or programmers. But they believe there’s a better, more efficient way to do things. They base their business on this change. They speak up. They pursue projects with a high level of risk. There’s another word for people like this: Heroes.
Steven will be following up on this idea of software creation as Science Fiction in a series of upcoming posts.
Mouse over to our email newsletter subscription box on the right, enter your email address, and we’ll let you know when the next article in the series is published.
P.S. No hard feelings?
P.S.S. No one noticed that the first letter in each heading spells “April Fools.”
Sound off!
Author’s note: It has taken much longer to get my notes and thoughts together (and have this article vetted by a horde of lawyers) than expected. Apologies for the delay in publishing, and thanks for your patience!)
Any time a new language is announced, it is touted as the “End of Programming as We Know It.” Last week it was Hack, this week it’s Unicorn, next week it’s something else. Silver bullets covered in ninja sauce seem to pop up with alarming frequency in this industry. So I was naturally skeptical when I was invited to preview the new cloud-based programming language and context-aware environment, Unicorn.
When Ayel Labs extended an invitation, I was both baffled and intrigued. Intrigued, because Unicorn sounds like something straight out of Star Trek™, and baffled, because I had no idea why they included me in their press event. As it turns out, I was the press event, and am still not entirely sure that everything I saw was real.
Upon arrival, I had to sign a stack of NDAs like I’ve never seen before, which limits what I can say about the rest of the day. No pictures were permitted, and I wasn’t allowed to get screenshots – but I was assured that everything would be made publicly available once the product was out of Beta.
The day started by interviewing the inventor and company founder, Steven Ayel.
When I asked about his background and inspiration for Unicorn, Mr. Ayel seemed shy, and would only say:
My background is ordinary; not the kind of guy you’d expect to invent something like this. I went to college on an academic scholarship, but got bored and dropped out. I worked with technology for a few decades, read everything I could find, and just started tinkering, like everyone else. But this is supposed to be about Unicorn, not about me. The past is not important; the future is. The future is Unicorn.
He refused to answer any other “past” questions, so I asked the question I wanted to know: why pick me for this interview? Why not someone better connected like Robert Scoble, or someone with more writing experience, like Dan Tynan?
The answer was surprising: Mr. Ayel said that he didn’t pick me; Unicorn did.
Give me the elevator pitch – what exactly is Unicorn?
Unicorn is a new programming paradigm, language, and platform, intended for use by everyone, every day. Through a combination of biometrics, natural-language understanding, and sophisticated proprietary audio- and image-processing algorithms, Unicorn understands you – gestures, words, deeds, and needs™.
Unicorn takes the notions of context-awareness, the Internet of Things, user-observation, and voice-control to a whole new level of integration, then augments that with cognition as a service (CaaS), software analysis and development patterns, and a common-sense knowledgebase to elevate the user-experience to an almost magical interaction.
Unicorn understands what you mean even if it’s not what you said, knows what you need, often before you do, and has the intelligence and programming skill to get it done for you.
Is Unicorn just some kind of souped-up personal assistant?
Well, yes, but not exactly, though it does perform those functions. It’s more like a technological genie. You see, we’ve included a vast programming knowledgebase into the core, along with novel problem-solving algorithms, which allows Unicorn to not only figure things out on its own, but also to create patterns of software to make things happen. It can link things together, take things apart, even create new things, wholly in software.
That sounds sort of like IFTTT?
No, but Unicorn can use IFTTT to do simple things for you. It can also write Assembly language at 100,000 lines per minute! Think of Unicorn as your own Personal Internet Sherpa™ – like a personal assistant that’s also a kick-ass programmer. Unicorn has access to any programming systems and tools on the Internet. But you don’t do any programming, Unicorn does.
Can you give me an example?
Hundreds, but here’s a simple one to start with: When I first started using Unicorn, I had to tell it what I wanted it to do – reply to this email, save that document here, move this download to there, that sort of thing. But only for a very short while, and I never had to tell it twice. And pretty soon I didn’t have to tell it at all.
One day I replied to an email with “OK I’ll do that as soon as I can”, and when I looked at my calendar a couple of days later I noticed an entry for it had been created – two hours blocked out on the next work day afternoon. I didn’t have to tell Unicorn to do that, it figured out – from observation and experience – the next available work time and about how long the task would take. It even understood that I couldn’t start the task without some supplies, so Unicorn purchased them for me on Amazon and had them shipped to arrive that morning. That’s when I knew this was really going to work, and work well.
So there is a training period? How long does it take for Unicorn to get to know you?
[Laughing] That’s the beauty of Unicorn. Unicorn learns from everyone, continuously. So you’ll never have to walk Unicorn through a step-by-step process like we did, because Unicorn already learned how to do that stuff from us and the Alpha Blessing. While there is a getting-acquainted period of a few hours to a few days, that process gets shorter all the time. It really depends on how much Unicorn can learn about you from observation, from the Internet, and the files on your devices, and from your interactions.
The Alpha Blessing?
A herd of Unicorns is called a Blessing. The Alpha Blessing is what we call our alpha-release users.
Let’s go back to the automatic programming for a moment – programming is not all logic, domain knowledge, experience, and wisdom matter greatly. What happens if Unicorn makes a mistake, runs into a bug, or just gets stuck?
Well that doesn’t happen very often, not since the Alpha version stabilized a few years ago. But when it does, Unicorn uses the same resources any other programmer would – it searches Google, reads e-books, it even asks questions on stackoverflow. In extreme cases, it puts in help tickets with our support staff.
I thought he was teasing me, but I did not get the chance to ask because a Domino’s Pizza delivery guy walked in with a pepperoni pizza for me – courtesy of Unicorn. I hadn’t even noticed that I was hungry, but I was. Mr. Ayel just grinned, said “That’s how Unicorn works,” and took the biggest slice.
So, Unicorn buys things for you with without asking? Is that wise?
Yes, um, no, well, yes, but no, you’re missing the point. The point is that Unicorn understood, anticipated my needs, and provided for them. All on it’s own. We back-traced Unicorn’s logic for that task in detail, to make sure it wasn’t a fluke. It wasn’t. Unicorn even sent a copy of the receipt for the supplies and shipping to the Accounting department and made an entry in my expense account for that customer. Ever since then, I just work, and I let Unicorn take care of the rest.
Personally, I am leery of trusting any piece of software with that much control over my life, not to mention access to my credit cards. When I mentioned this concern, Mr. Ayel took me to see Eric Patterson, the Director of Ethical Integrity.
We found Mr. Patterson in what I took to be the server room – racks upon racks of computers and drives in a medium-sized room with only a tiny desk and lamp. It turns out that this was his office, and that all of the computers in the room are his “personal cloud”. He uses them to run an independent copy of Unicorn that watches the main one.
Mr. Patterson, why does a software company need a Director of Ethical Integrity?
I’m not the director of ethical integrity for the company; I’m the director of ethical integrity for Unicorn.
Not the answer I expected at all. I asked him to explain.
In Unicorn’s early days, we were all amazed at how quickly it learned, how efficiently it created software to solve our problems, and were gearing up for the first release with full steam ahead. That was, oh, about eight years ago. Then one of the developers joking told Unicorn to ‘go win the state lottery for me’. Well, Unicorn not only bought several hundred tickets via Craigslist ads, but also tried to hack into the lottery servers to fix the winning numbers. We had to shut it all down for weeks.
What was the problem?
The problem was, of course, a lack of a conscience. So we gave it one [he pointed at the server racks], along with several more ethical patterns in the common-sense knowledgebase, mostly variations of the Golden Rule.
I spent the first year literally being Unicorn’s conscience, but now it’s matured enough that I don’t have to watch it so closely. Any grey areas are noticed by the ethical watchdogs, and only brought to my attention if there was no rule to resolve them. Unicorn has also learned to resolve conflicts amicably on its own, so I don’t really have to do much anymore.
By now, as you can imagine, my head was spinning. If Unicorn can crowdsource a lottery ticket buying spree and hack servers, what couldn’t it do? To answer that question, I was taken to see the development and support labs.
The development and support labs are tucked away in the basement of the facility, behind security doors straight out Get Smart. Here, I imagined, a horde of programmers worked day and night to augment Unicorn’s functionality and troubleshoot the occasional bug. I talked with the Alpha Shift Leader, David Chelette, about his role.
I oversee the Alpha Shift, which is 8am to 4pm. I manage 25 programmers, most of which are interns from the local community college. Whenever Unicorn encounters issues that it cannot handle itself, it issues a work ticket and the interns handle it. If they can’t handle it, I do.
What kinds of things can Unicorn not handle?
Most work tickets these days are to investigate minor bugs in something that Unicorn is building. The problem is almost always some kind of documentation error, not flaws in Unicorn’s logic. For example, Unicorn built an automatic payment system for one of the Alpha Blessing using a secure FTP class library, but the class had an unexpected and undocumented limit in it that prevented it from working with the bank’s server. Once one of the interns – I think it was #22 on Gamma Shift – figured out the problem and told Unicorn, then Unicorn was able to reverse-engineer the class and fix the bug on its own. So mostly we just find out things for Unicorn, or do things that it physically cannot do yet, like bringing Mr. Ayel a Dr. Pepper. Though I think we’re is building a Segway robot to take care of the latter. Frankly, we haven’t written a line of code in about three years, and we’re getting kind of bored.
Do you foresee Unicorn putting programmers out of work, eventually?
There’s no “eventually” to it; it has and it will. We’re idle most of the time; there’s very little that a programmer can do that Unicorn can’t do.
I’m not going to believe that without a fight. How, exactly, does Unicorn eliminate programmers?
When Unicorn recognizes a problem statement – whether explicitly, as in “interface the payroll system with our bank’s ACH server”, or implicitly, as in “I wish I didn’t have to write so many payroll checks every month” – when Unicorn recognizes a problem, it starts a problem-solving process we’ve developed over the past decade, based on automatic planners, genetic solution generators, software patterns, and so on. Unicorn spawns a new Blessing, which is basically a society of artificially intelligent agents. The agents initially pursue independent paths towards a solution, using a variety of competing methods. As discoveries and connections are made, the society aligns into factions favoring the most promising paths, debates the relative merits, and then collectively pursues a few of the best alternatives.
Debates? Unicorns have debates?
Yes, quite literally, sort of an ontological firestorm, to coin a phrase, hundreds of thousands of semi-intelligent agents all arguing at once. Unicorn is a knowledge-based system. And it learns. One of the ways that it learns is by internal debate. That was one of the breakthroughs that Mr. Ayel achieved – there have been AI planning systems for decades, but they tend to be narrow and brittle. Unicorn uses a bunch of different ones, starts an argument among them, and bets on the winner, so to speak.
So you throw a lot of specialized agents at the problem and see who wins?
That’s the second twist in Unicorn – we let them “stampede in the wild” for a while, independently proposing partial solutions, decompositions, gathering evidence, and so on. Everything learned individually also contributes to the group knowledge. Gradually the independent solutions begin to converge on a few frontrunners.
A subsumption architecture, adapted from robotics research, helps coordinate the convergence into factions. The factions may fight for logical dominance, they may split into separate herds, and they may merge back into the same herd, bringing partial or complete solutions with them.
Successful solutions are analyzed for meta-patterns, the specialized agents are enhanced, the convergence mechanics tweaked, and so on – so not only does the problem get solved, but also every component of Unicorn gets better at solving that kind of problem.
It sounds like Unicorn requires extraordinary computing power.
That was relatively true when we started – a room full of servers just to figure out what kind of pizza to order for the team lunch – but now with hardware and communications advances the requisite computing power is easily available. Unicorn runs in the public cloud, of course, but it also runs on a peer-to-peer cloud on participating devices. The power of Unicorn grows exponentially.
I must admit I was a little freaked out at this point; the phrase “grows exponentially” frankly sounds a bit ominous. So I asked for a small application to demonstrate Unicorn’s programming prowess, perhaps something to help manage my blog and social media channels?
[Laughing] Unicorn said your social-media presence is…suboptimal, so it wrote a mobile app to help – about an hour ago. Let me show it to you.
OMG. I can’t show screenshots, not yet, but I can tell you what I saw:
At this point, obviously, I’m impressed. But there was more; a cloud-based background process was:
The app was beautiful, included my company logo, and I’m told it took Unicorn about ten minutes to design and build it.
I think I’m out of a job. Better dust off my saxophone, and buy a hat!
Whether you want to join the herd now or the stampede later, sign up at the Unicorn Language website. Then come back and tell me: if you had Unicorn, what would you ask it to do for you?