Alan Kay Quotes.

[paulca]

I love this guy.

https://www.brainyquote.com/authors/alan-kay-quotes

The bane of my existence right now is summarised beautifully by this:

Social thinking requires very exacting thresholds to be powerful. For example, we've had social thinking for 200,000 years, and hardly anything happened that could be considered progress over most of that time. This is because what is most pervasive about social thinking is 'how to get along and mutually cope.'

Alan Kay

Another favourite, when you feel failure.

If you don't fail at least 90 percent of the time, you're not aiming high enough.

Alan Kay

[tggzzz]

Alan Kay is one of the few computing visionaries, as were many people at Xerox PARC at that time. His quote about failing 90% of the time should be seen in that context. Striving for frequent failures in the hope of being like Kay is doomed to failure

In the context of recent GUIs and crap backend systems, I rather like...
"In the old days, you would chastise people for reinventing the wheel. Now we beg, 'Oh, please, please reinvent the wheel.' "

It is hard to argue with...
"It's hard to change information in books, but if we have everything online, then a somewhat untrustworthy group of people controlling the thing - which I think is what we have - gives us '1984.' "

He was at HPLabs while Princess Fiorina was there, so this makes me think he met her (and Apotheker, Hurd...)...
"Scratch the surface in a typical boardroom and we're all just cavemen with briefcases, hungry for a wise person to tell us stories."

You're unlikely to find this accurate sentiment on quotes pages aimed at the general public...
"I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging"."

Chortle...
"I made up the term "object-oriented," and I can tell you I did not have C++ in mind."

Haven't seen this before, but I like it...
"When the Mac first came out, Newsweek asked me what I [thought] of it. I said: Well, it's the first personal computer worth criticizing. So at the end of the presentation, Steve came up to me and said: Is the iPhone worth criticizing? And I said: Make the screen five inches by eight inches, and you'll rule the world."

And the widely known...
"The best way to predict the future is to invent it. "
"Technology is anything invented after you were born, everything else is just stuff." (The second clause is rarely quoted)

[ebastler]

"Technology is anything invented after you were born, everything else is just stuff." (The second clause is rarely quoted)

Douglas Adams has elaborated on that one:

Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
Anything invented after you're thirty-five is against the natural order of things.

[brucehoult]

"Technology is anything invented after you were born, everything else is just stuff." (The second clause is rarely quoted)

Douglas Adams has elaborated on that one:

Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
Anything invented after you're thirty-five is against the natural order of things.

I'm sure there must be many people like that, but I feel that at almost 62 by the calendar I'm still in the 15-35 phase!

Things invented after I was 35 that I've jumped on, moved to companies doing them, done my own projects etc:

- SIMD in commodity CPUs (mostly Altivec in PPC G4, MMX didn't compare)

- Linux displacing Solaris & HP/UX in telcos

- iPhone!! early jailbreaking and writing apps before Apple gave an SDK or had the app store

- Arduino, democratisation of microcontrollers

- RISC-V, ditto ISAs

Can't wait for what's next. Just hope it's not really LLMs. Definitely against the natural order, dammit!

[paulca]

You're unlikely to find this accurate sentiment on quotes pages aimed at the general public...
"I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging"."

Something I studied at Uni, Xerox PARC and Small Talk, was the academic to practical OOP paradigm, and then I became an enterprise Java programmer at some point.


Enterprise Java is "said to be" Object Orientated and it is often used as a ultimate "Ivory tower" of OOP.

Reality is there is very, very little of the original intents, nor principles of OOP remaining in Java.

So that quote from Alan Kay...  I'm not sure if it explains those or makes the confusion worse.

What I see in Enterprise Java, at the code face and design face, is not OOP.  Well maybe 20%.  It's often, these days, 20% or so "Functional Orientated", but mostly it's Data driven procedural exactly like it was in 1983 in C.

Structs for your "Data dictionary"
Functions for your state transitions.
No encapsulation.

In Java, we define "Value objects", often these days generated from model descriptors in YAML.  A "value object" in Java is often, not always, a "Java Bean" or other "introspectable class" which follows conventions such that it may expose all of it's data.  No functionality is to be contained in said Java Bean.  Aka, a complete violation of OOP.  We are separating our state from our behaviour.  In DIRECT violation of the number 1 rule of "Encapsulation".

I can't work out if Alan would be in support of "Value Objects" as "Messages" sent between classes, but...  I still feel confused.  Should ALL state be in the messages or just enough for the receiver to work with?  Should the receivers and senders be stateful?  If so, who "owns" the state?  The message or the receiver or both?

Regardless of Alan Kay, I am firmly in the OOP = "Emperors new clothes" camp.  As it is applied in reality outside of direct manipulations user interfaces.

[tggzzz]

"Enterprise Java" is to "Java" as "book" is to "English" or "QT" is to "C++" .

In other words, don't confuse things implemented in or containing a language with the language.

There's a PoV that applications written in enterprise Java frameworks are component oriented, not object oriented in the Smallltalk sense.

BTW, it is Smalltalk, not SmallTalk, not Small Talk.

[brucehoult]

Reality is there is very, very little of the original intents, nor principles of OOP remaining in Java.

"Agile" has been completely perverted to mean "Scrum". And much development that is done using the trappings of Scrum is in fact old fashioned waterfall development, just in a pressure cooker slave-driver environment.

[paulca]

Reality is there is very, very little of the original intents, nor principles of OOP remaining in Java.

"Agile" has been completely perverted to mean "Scrum". And much development that is done using the trappings of Scrum is in fact old fashioned waterfall development, just in a pressure cooker slave-driver environment.

Yea and the latest word on the street is that "Big companies" have decided that "Agile" is a failure and ... it's the developers fault.

Even though I can bet you a month salary that 90% of them did about 20% of Agile, cheery picked and ignored, overruled or completely contradicted the remainder.

[SiliconWizard]

Reality is there is very, very little of the original intents, nor principles of OOP remaining in Java.

"Agile" has been completely perverted to mean "Scrum". And much development that is done using the trappings of Scrum is in fact old fashioned waterfall development, just in a pressure cooker slave-driver environment.

True. I've seen that. It's a big pile of doublespeak - they'll be claiming all the time to oppose "waterfall" with a passion, but in the end, it closely resembles it, just with very short cycles, a ton of micro-management and surveillance.
Scrum is a management tool - certainly not one for the actual engineers doing the work.

[paulca]

Dead simple test for these methodologies.

"Do you plan fixed requirements, fixed time?"

"Yes."

"You are doing waterfall or you are doing nothing.  It's 100% not agile or scrum and it's 100% not DSDM.  You are denying the wealth of experience and knowledge over the past 70+ years on how bad software estimates are and how fast requirements change"

The main reality governing modern methodologies is that in today's world the requirements change faster than they can be developed.

This literally destroyed waterfall.  Projects ended up in endless cycles of refinement to meet changing requirements and over ran by years and millions.

When the customer finally gets their solution, regardless of how well you did the UAT and requirements verification, they WILL have changes they will still want.  So if you stop there, you leave the customer with only 60% of what they wanted and 40% of stuff they didn't.

Most of the methodologies stood up and manicured to address this went straight to those problems.

Most look at "iterative" models.  Basically taking the "problem" from waterfall - too many costly re-cycles - and made it a feature - short rapid iterations of the process, time boxed so that a complete loss of an iteration is not a massive impact to the project overall.

Agile more specifically then addresses a few other problems from "waterfall".

"Ivory Towers".  In waterfall there was a tendency that silo'ed "high level" "departments" and teams handle all the "clean" paper work in isolation.  This paperwork is then handed to the engineers to do the lower level, 'down in the dirty' design.  Eventually that output goes to teams of programmers and testers to develop.  By that time the path back to "Knock on the wizards door" is guarded by the dogs of management.  That or the person left the company or simply is too busy to answer clarifications.  In large private or government sector projects there can be over a YEAR between the commencing meetings and the developers seeing the project for the first time.... after all the requirements are set in stone (really in sand) and the deadlines and deliverables have all been written in stone and blood.

Agile's approach to solving this is to incorporate a "role" for each step in that cycle in the "iteration", including the customer.  Note:  Not the customer's manager or business leader, but the person who will actually USE the solution.

"Who knows best?"

Agile also tries to address this.  The answer, whether business or management agree is irrelevant, is "the end user and the developer".  The end-user knows what they need, what works and the role/process/system in question well.  The developer knows well what "can" be delivered with the current up to date tools, techniques, frameworks, platforms etc.  The developer is also in his/her most ideal position to give an accurate estimate of "What can be delivered within the next iteration and shown directly to the customer first hand."

Develop -> Demo -> Discuss -> LOOP

There are no managers involved in this process.  None.  That is a specific part of the methodology.  None should be needed and thus having any will slow things down.  It is literally like having the restaurant manager getting in the face of the Chef and a diner while they are discussing the dish on the table.

Now, there has to be "oversight" of course.  It's just that in Agile it is applied "out of band" from the dev stream.  The interface to the dev team is via "roles" like "Product Owner", "Scrum master" (from scrum).  (Should be noted that Agile is not a single monolithic methodology, instead is is a modular collection of tools, techniques and principles, most already available off-the-shelf of academic papers (like Scrum, Kan-ban, Lean et.al), , others "borrowed" and mutated, like DSDM.  Not all are from software or even tech.  "Lean" comes from production lines.

There is no point continuing, the point was made at the "Fixed time and requirements" boxing.  This is the failure point for Agile as we know it.  This is  done in 90% of the teams I have been in that claim to be agile.  They all have at VERY least fixed deadlines with fixed functionality contained at the "Epic" level.  Totally failing to accept the academic research which clearly shows "Software estimation on the large scale is so bad, you might as well roll a dice."  If you stand up a static plan, you stand up for failure.    It's not even like it's 20% of projects it's 99%.  99% of software projects overrun time and budget and under deliver on functionality.

The other papers show that acceptance and embracing of this fact can actually result not only in better "estimation" and thus better target dates, but can significantly increase the amount of "use" and "quality" delivered to the customer.

Management do not study, nor are they required to study these kinds of materials.  It's not their job.  "We" do.  The Software Engineering capability.

Today most companies see "Scrum master" or "Product owner", they see "Manager", they lift the "cookie cutter manager" job description and the practically BEG people to take it.  ZERO requirements for understanding software engineering or it's methodologoes.  It is assumed that "Projects are projects are projects" and "Managers are manager are managers".  "Any manager can manage a complex software project, it's just management right?", "What do you do?  Send a few emails?  Fill out a few strawmen in Excel?  Ask the team to produce a slide of your PP deck each?  Easy right?"

It's literally like being cast back in time to the 1980s before we learnt how to engineer software.  The quality and timely-ness of deliverables is also headed retrograde fast.

On the degradation of the role, "Software Engineer" I remind my employer that "I" bear the civil and legal responsibilities and ethics of my profession to the people and the state.  Because of education, qualifications and so many years in the role, I can be held accountable for it in court.  The British law considers me a "Qualified practising engineer" and so am held to that regard.  I can be summoned as an expert witness and can receive charges of negligence that the company I work for cannot protect me from.

Managers don't.  Because they are not "professionals" and have no voluntary, self-regulated, or chartered responsibilities or body of.