Monday, April 17, 2017

Alan Kay on Computer Science

Alan Kay is a computer scientist and pioneer who was part of the Xerox PARC team of about 30 researchers that developed many of the key concepts of today's hardware and software technologies.
This post contains some famous keynotes and other talks by Alan Kay including quotes and comments.

See also: Alan Kay on Object-Oriented Programming

Normal Considered Harmful

  • 05:00 We must know about the past (the pioneers of computing) to invent the future.
  • 13:53 We cannot invent the future by using vendor computer hardware and software.
  • 34:29 Knowledge almost always trumps IQ. A change in perspective is worth a lot of IQ points.
  • 36:31 Clever hacks don't scale well and worse keep broken things around for too long.
  • 39:45 Learning a new idea requires almost as much creativity as the original invention.
  • 49:27 Wayne Gretzsky theory of hockey: Why are you a so much better hockey player than everybody else? Everybody else just goes where the puck is, I go where it is going to be.
  • 1:01:08 All understanding begins with our not accepting the world as it appears (Susan Sontag).
  • 1:02:17 Brains were designed for survival and coping, not for great inventions. Science is a way to get around that limitation.

Programming and Scaling

  • 06:50 The biggest problem we have as human beings is that we confuse our beliefs with reality.
  • 08:21 Make-and-fix paradigm: Nowadays, computing is mostly tinkering and not engineering.
  • 18:03 The internet is one of the few human artifacts that behaves like a living organism.
  • 25:11 Smalltalk (OO) mistake: Objects are too small! The scale jump from molecules to a living organism is incredible compared the scale jump when trying to make objects. Idea: Make much more capable universal objects and try to build things out of that.
  • 33:11 Most people can only experience the present in terms of the past. (Marshall McLuhan)
  • 30:05 Our strain of humanity is on the planet for about 192.000 years (tracing mother's mitochondrial DNA) and we only invented science 400 years ago. That's why IQ does not count that much.
  • 37:00 Past, Present, Future: The past is enormous!
  • 42:43 Computing is mostly tinkering at this time, there's not much engineering, math, or science.

Is it really "Complex"? Or did we just make it "Complicated"?

  • 1:13:10 Next generation publish/subscribe systems in UI/UX design: Widgets communicating by a publish/subscribe methodology to announcements of events.
  • 1:38:00 Computer science is the science of processes. It is about thinking, reasoning, and talking of processes as well as representing, constructing and debugging them both in hardware and software.

@ SAP

  • 12:47 Our perception of the future is mostly just a little increment on the present.
  • 13:01 Innovation is just taking an idea or invention that already exists into the marketplace.
  • 19:19 Problem finding is much harder than problem solving in order to make progress.
  • 21:14 You are doing research only so long as you can change your mind. Making decisions consolidates one's mind.
  • 21:53 Most software in the world is absolutely not designed!
  • 25:01 Thinking is not remembering!
  • 37:50 Big data: What we need is not big data but big meaning (including descriptions for processes, relationships and constraints).
  • 40:33 Building with gears does not scale (< 1000 gears)! Biology scales!
  • 42:58 The internet is one of the few human artifacts that behaves like a living organism.
  • 44:19 Learning how to code is like the last thing you wonna learn about computing. Computing is about systems, not about algorithms, not about if-statements; it is about powerful ideas that are made into descriptions computers can interpret.
  • 56:55 How do you learn how to bike? Using a low bike without pedals. Bicycle training wheels are actually anti-learning! Lessons learned: Software called "user-friendly" very often isn't.

Power of Simplicity

  • 10:01 You get simplicity by finding a slightly more sophisticated building block to build your theories out of. The inability to fix the existing building blocks is one of the largest problems that computing has today. The building blocks (abstractions) help in putting stuff into the right context.
  • 14:33 WYSIATI: What you see is all there is.
  • 23:53 You need to solve the context, not just a problem!
  • 24:14 Finding out about the real problem is the big deal and it may be much harder than solving the problem itself.
  • 32:39 What is your company's 10 year plan? Umm...
  • 49:27 Wayne Gretzsky: A good hockey player is going to where the puck is, and a great hockey player is going to where the puck is going to be.
  • 50:11 "Better" and "Perfect" are the two enemies of "What Is Actually Needed".

The Future Doesn't Have to Be Incremental

  • 21:55 Human universals by anthropologist Donald Brown (e.g. coping, social, language, culture, fantasies, stories, news, art, etc.). Most popular software products work as technological amplifiers for at least one such human universal.
  • 28:15 Linux is a budget of bad ideas.
  • 29:12 Real inventions: E.g. writing and reading, abstract math, model-based science, democracy, equal rights, slow deep thinking, etc.
  • 30:48 Isaac Newton changed the way of how people think.
  • 35:23 Wayne Gretzsky: You miss 100% of the shots you don't take.

The computer revolution hasn't happened yet

  • 16:45 OOP architecture: As complexity starts becoming more and more important architecture is always going to dominate material.
  • 24:11 It only takes about 50 cell divisions (iterations) to make a baby.
  • 35:11 In contrast to biology computers are slow, small and stupid.
  • 37:01 Cell membrane acts like a pattern matcher and it keeps most of the things out as much as it keeps certain things in.

The Best Way to Predict the Future is to Invent It

  • 11:39 We all have a duty to the next generation, whether or not we have children!
  • 13:26 Our brain is mostly set up for reacting (System 1) and it tries to avoid real thinking (System 2).
  • 27:31 "We must ensure that human wisdom exceeds human power" (Vi Hart)

Sunday, April 16, 2017

Operating System 101

From Andrew S. Tanenbaum's "Tanenbaum-Torvalds Debate - Part II".
No flame wars, just operating system and distributed system architecture.

My view is that you want to avoid shared data structures as much as possible. Systems should be composed of smallish modules that completely hide their internal data structures from everyone else. They should have well-defined ‘thin’ interfaces that other modules can call to get work done. That’s what object-oriented programming is all about – hiding information – not sharing it. I think that hiding information (a la Dave Parnas) is a good idea. It means you can change the data structures, algorithms, and design of any module at will without affecting system correctness, as long as you keep the interface unchanged. Every course on software engineering teaches this. In effect, Linus is saying the past 20 years of work on object-oriented programming is misguided. I don’t buy that.

Once you have decided to have each module keep its grubby little paws off other modules' data structures, the next logical step is to put each one in a different address space to have the MMU hardware enforce this rule. When applied to an operating system, you get a microkernel and a collection of user-mode processes communicating using messages and well-defined interfaces and protocols. Makes for a much cleaner and more maintainable design. Naturally, Linus reasons from his experience with a monolithic kernel and has arguably been less involved in microkernels or distributed systems. My own experience is based on designing, implementing, and releasing multiple such operating systems myself. This gives us different perspectives about what is hard and what is not.

See also: Microkernels are slow and Elvis didn’t do no drugs

Friday, April 7, 2017

On Building Reliable Automotive Software Systems

During the last years me and my team built various automotive software systems in the connected car domain as well as in the body domain.
Before that, we built Android-based infotainment systems, mobile internet routers and some kind of wireless display like Miracast.
Over time, our work became highly inspired by two software platforms and their characteristics: Erlang and Android.
Erlang's influence came mostly from its reliability characteristics and its shared-nothing methodology. Android provides a modular, component-based application framework including a software development kit and documentation which we wanted to have for all kinds of automotive software systems as well.
This led to the developement of the Mindroid application frameworks.

What is Mindroid?

In short, Mindroid is a component-based application framework similar to Google's Android, including a software development kit and documentation. It builds upon the Actor model as core system architecture building block and provides an event-based programming paradigm.
Currently, there are three variants of Mindroid.
  • Mindroid.java targets the Java platform
  • Mindroid.cpp targets native platforms, like Linux or QNX Neutrino RTOS
  • Mindroid.ecpp targets deeply embedded systems without dynamic memory management, like AUTOSAR OS, CMSIS RTOS or even bare metal
One of Mindroid's main goals is to provide a slim platform to develop highly reliable (distributed) software systems. Other goals and their prerequisites are:
  • Modularity: Components with clear interfaces, threading and dependencies
  • Reuse: Set of reusable components across projects and platforms
  • SDK: Sustainable, public APIs crafted by an API first design approach (Finding good abstractions and truly care about naming things)
  • Reliability, testability and refactorings: No shared state between components
  • Software quality highly benefits from Actor model design approach
    • No complex critical sections
    • Callbacks run in right thread contexts
    • Low energy, CPU time and memory requirements
  • Logging (No long-lasting debugging sessions)
  • Slim platform: Simplicity is prerequisite for reliability
  • Scalability: Distributed systems running multiple Mindroid instances on different nodes
Mindroid relies on the Erlang-style actor process model to achieve that goals. The core Actor model is mainly based on the Android Thread, Looper, Message, MessageQueue, Handler and Binder classes. Together with the Process class Mindroid implements deployable components and component isolation comparable to Erlang-style process isolation. The component isolation assures that there is no shared state across component boundaries. This is done by exchanging only POD types a.k.a. plain old data structures and component interfaces (actor endpoints) on component interface level. Using such component interfaces one can access further components. Furthermore, each component clearly defines its own threading behavior within the hosting process to achieve true component isolation regarding data (no shared state) and the runtime environment (process and actor).

Slide 5 below illustrates the Erlang-style actor process model using a CarFinder component that relies on a LocationManager for location updates.


For future, we plan to implement Erlang-style distribution transparency for services and service discovery. And we would love to have a Rust variant of Mindroid.

See also: