2014/09/15 19:20 Dave Thomas, “Simplicity — The Road Not Taken”, PLoP 2014

Plenary address by Dave Thomas http://davethomas.net Bedarra Research, at Pattern Languages of Programs 2014, Allerton Park Retreat Centre, Monticello, Illinois

This digest was created in real-time during the meeting, based on the speaker’s presentation(s) and comments from the audience. The content should not be viewed as an official transcript of the meeting, but only as an interpretation by a single individual. Lapses, grammatical errors, and typing mistakes may not have been corrected. Questions about content should be directed to the originator. The digest has been made available for purposes of scholarship, posted by David Ing.

About 40 participant in the room, laid out classroom style with a large screen projector

---

Arthur Whitney, A+ APL follow-on, then wrote core of interpreter for J in C, then used it in K

• From Crista’s talk in the morning, this is a text editor in K

Simplicity

• All on one screen
• It would be nicer if could read the 1000 lines of Emacs
• Complexity is relative

Biased towards things that are short, even if they’re harder to understand

• How to make things literate?
• If you get into functional programming, or expression languages, could think about polishing it and make it smaller

Immersed in the cloud

• If you want to do any application today, you have to learn a new vocabulary, with some deep semantics (like why the don’t work).
• They’re unstable
• Benchmarks are bogus

Lost on Planet Big data

• Sparql benchmarks are bogus

Web Next Open Force versus Walled Gardens

Alien Languages:  take a lot to learn, accidental complexity

Lush Plants with very thin process atmosphere

• Wonder why normal people can’t write programs
• Most programmers can’t talk to each other

Everything Loosely Connected and Mobile

Jurassic Software?

• Prehistoric SaaS: Mainframes with simple productive 4GLs
• Unix, Client-Server, Relatoinal
• Naive Simplicity:  PC, spreadsheets
• Absurd complexity
• …

What legacy space junk will be out there?

• They keep changing langagues

Phil Lester, HCI:  Complexity of Technology

• Above line, too complex for people
• Then have accidnetal complexity by people who don’t document and implement incorrectly

The darker side of objects:  why people shouldn’t use objects

• (Not enough time to talk about today)

Simplicity, the road not taken?

• We don’t seem to  hit a limit
• We hope we can find a new language, a new expression

The more things change, the more IT stays the same

• Still CRUD Create – Read – Update – Delete
• Why?

Have a business process, make a computer process

• But then people found out a transaction wasn’t as simple as originally thought

IT is still CRUD, Workflow and Data

• Inputs and Outputs
• Workflow
• Event/Actions: Event – state tables
• Rules/Actions: Decision tables (rules engines)
• Complex Calculations:  lots of people run their businesses on spreadsheets, but then get agile programmers who will need to as a product owner to write story cards, maybe write tests that have as much code as the program
• Data and Relationships:  have been in denial to say shouldn’t have data models, only object models, which created bloatware, there are a lot of things that have only data, no state, so don’t need garbage collection

IT 4.0?

• Challenge of IT 3.0

Should ship less code

• The more code you have, the more there is to maintain
• Written by a lot of people, then there’s a lot not understood
• Poor refactoring tools

Either we make magic tools, or try to figure out how to not makes things so complicated

• Get rid of dependencies when we can
• More memory means that we don’t have to fight for resources so much

Abstraction bloat:

• Framework is a promise that you won’t maintain

Use less objects and less code

• Table-driven programming:  rules as decision table; calculation as spreadsheet; data validation as domain and range table; mapping as lookup table; flow as data – work flow – message; events and matches as state table; processes and reports as input-output tables; acceptance criteria as BDD; domain models as entity-attribute dictionary
• Enable customer self-service:  atom feeds vs. APIs; query vs. custom; expose scriptable services; self-described data (not JSON)

The legacy of JSON will be worse than the legacy of XML

Table Driven Programming is a lost art

• Years of use, but not taught anywhere
• Might show you a state machine, but not a complicated one

Reduce integration time and dollars

• Avoid slow and complex APIs
• Should just federate from the data, rather than objectifying everything
• Most stable thing is physical disk pages, can just get them off Oracle drive
• Make read-only SQL replicas for fast reporting
• Put Atom/RSS feeds on legacy / partner system for journal files and events (rather than having a team write Java queries)
• REST and JSONify your service
• Use ODBC as a simple interface to complex server systems, so anyone call pull data out of legacy systems

Script to save time and money

Loose coupling:

• Data Flow
• Structured Analysis and Design SADT used to be sequential
• J. Paul Morrison convinced Japanese banks that could build a system with flow base programming, spinning up processes and have things flow between them, so the process model and the flow are the same
• Hewitt Actors
• Spreadsheets
• Erlang
• Messaging

Enabling loose coupling

• All APIs are value based and where possible stateless
• Keep data, and don’t mutate
• Occasionally disconnected with replication and sync
• Simple implementations using coroutines
• Functional Programming thinking encourages value orientation and composition, instead of working with pointers and mutating states

The future of programming is query?

• Historical views of programs
• Program as procedures + data structures
• Program as process + data flows
• Program as expressions + constraints
• Program as logic + control
• Program as messages + object/actors
• Program as pure functions + actions
• Programs will be query + action (SQL plus functions)

Collection oriented programming

• Instead of building a new abstraction, working with old collections
• Most object programs don’t have naked collections, they’re enclosed inside something else
• May be easier to run on multiple cores
• Favourites J and Clojure

Let the hardware do the work!

• Hardware is faster
• Programmers are slower
• When you have all of the data in memory, things are easier (which isn’t possible in Java, because of limited heap size)
• Could work with 6TB of RAM
• Next few years, will to go 20 to 30TB of RAM, easier to keep a small program in cache to manage resources
• Data conversion and translation is cheap
• Data compression and encryption is free on multicore, because they’re sitting there doing nothing
• Haswell and Ivy Bridge find it faster to send messages between cores
• Problem isn’t multiprocessing, it’s what’s in the cache
• Latest Intel chips have 5 levels of cache, tricky for people to use them
• Can execute Excel spreadsheets rapidly
• Have your program live in the data for an accelerated experience

Enable self-service

Business app development

• Some pioneering:  IBM QEDWiki, Yahoo Pipes, Google Mashup Editor, Dabble DB
• If could kill off programmers who hate anything visual

Live programming in a browser

Could use Scratch to do functional vector programming, so know working on right shape

If we could find ways to express in smaller amounts of code (e.g. visual), we could comprehend it, or at least introspect and look at it

• Days of making complicated data structures over
• Freedom, people can do things on a 1TB box with a thousand cores
• Can build things that end users can live in
• Can write queries visually

Advertisement

#plop2014, #programming, #simplicity