←back to thread

Alan Kay has agreed to do an AMA today

1401 points alankay | 1 comments | 20 Jun 16 18:04 UTC | HN request time: 0.21s | source

This request originated via recent discussions on HN, and the forming of HARC! at YC Research. I'll be around for most of the day today (though the early evening).
Show context
zyxzevn ◴[21 Jun 16 00:53 UTC] No.11942780[source]▶
Hi Alan, Since you may spend another day answering questions.. a got some more for you :-)

What do you think about the different paradigms in programming?

And what do you think about type theory, etc?

Bonus question: I am trying to develop a new general programming system for children. I was inspired by Smalltalk and ELM.

http://www.reddit.com/r/unseen_programming It is a graphical system that uses function blocks connected with flow-logic. So basically it is functional, but much simpler. The function-blocks form a system, very similar to classes/objects in Smalltalk. What do you think about such a system, or what tips do you have about designing a new language?

replies(1): >>11945766 #
alankay1 ◴[21 Jun 16 14:20 UTC] No.11945766[source]▶
A good heuristic for designing programming languages is to try to take the largest most complicated kinds of things you want to do, work them out, and then see if there is a "language lurking".

Most people make the big mistake of lovingly making small neat examples that are easy to learn -- these often don't scale at all well. E.g. "data" in the small "seems natural" but the whole idea scales terribly. And so forth for most of the favorite paradigms around today.

replies(1): >>11947316 #
kkoomi ◴[21 Jun 16 17:07 UTC] No.11947316[source]▶
Could you tell what you mean by data scaling badly?
replies(1): >>11951144 #
1. mmiller ◴[22 Jun 16 02:25 UTC] No.11951144[source]▶
The problem with the idea of procedures acting on data structures is that as a system scales up, it gets more complex in terms of its data structure, and the amount of code that must operate on it, and be dependent on it. As that happens, it gets harder to change, both in terms of the structure, and the procedures that work on it. The dependencies between the structure and procedures grow in number and type. The attempt to understand it creates a cognitive load that makes it difficult and inefficient to keep track of them (if not impossible), and keep consistency in how they operate. Secondly, the amount of code that's required to operate up to spec. becomes so voluminous that it creates a cognitive load that is too much to handle, in terms of finding and fixing bugs.

Part of scaling is understanding the relationship between what is necessary to express to carry out the complete, intended model, and the number of relationships (the best I can express this is "in chunks") that we can keep track of simultaneously. Modern engineering in other fields of endeavor understands this notion of cognitive load and complexity, in terms trying to organize resources such that a constructed structure can carry out its intended function well as a result of principled organization methods.