Hacker News new | past | comments | ask | show | jobs | submit login

Just randomly came across this Alan Kay talk that I hadn't seen before. Some very interesting points on the challenge of real innovation:

"Normal is the greatest enemy with regard to creating the new. And the way of getting around this, is you have to understand normal, not as reality, but just a construct. And a way to do that, for example, is just travel to a lot of different countries -- and you'll find a thousand different ways of thinking the world is real, all of which is just stories inside of people's heads. That's what we are too. Normal is just a construct -- and to the extent that you can see normal as a construct inside yourself, you've freed yourself from the constraint of thinking this is the way the world is. Because it isn't. This is the way we are."




Love Alan Kay. Went to a series of talks as part of a week of education for an old employer. We had several very highly qualified people speak to us about various challenges in IT. They were all quite "normal". Alan Kay's talk blew me away because it was so left-field. Interesting guy.



The guy is sickening! Not only did he come across as very likeable he also dropped in that as a child he had to decide between going into computer science or becoming a professional jazz musician (I think he played guitar).

Choosing between musician and computer genius is bad enough but to retain being likable with this is frankly too much :-)


I'm curious about system evolution and their tendency to 'normalize'. I too like the diversity and originality, but constant newness, as in 'javascript client framework' is exhausting .. surely there's a balance, and hopefully some kind of theory on where to place the center.


Devs like to solve problems for their own sake. Building a completely new anything is a completely different challenge to solving a problem like "Build a version of existing thing X using language Y and/or running in environment Z."

The second option is well-bounded and safe. It requires technical skill, not creativity. It's a legible, comprehensible challenge.

The first option is unbounded and unsafe. It can't be done without creativity, originality, and technical skill.

I'm becoming convinced there should be a much stronger creative and artistic element in developer training. Invention and innovation are so much more valuable than wheel reinvention that turning out people who are only comfortable with the latter is selling everyone short.


You can't really teach such a thing, not in any profound way. The programmer in question must have an intrinsic or otherwise self-conditioned drive to read computing history, papers and be interested in actually doing research before starting a project.

We have largely crafted a culture where doing research before writing code is considered slow and ineffectual for whatever reason. Instead, we value "moving fast and breaking things" and whipping up the quick hack, which encourages people to propagate their computing biases and never step out of their comfort zone.

This is one of the reasons why I mostly scoff at attempts to make computer programming a compulsory schooling subject. Coding as "the new literacy" devalues computing and is the very embodiment of the programming pop culture that Alan Kay has warned about.


Moving fast is valuable sometimes, as much as going away in a hammock as Hickey would say. Learning how to alternate both scales is missing though. And I often thought smart people had that down, they could think ideals, then get down through the stack to effectively make things, then get back to the abstraction without losing focus or getting lost. Quite often I'm stuck at one level or the other.

> This is one of the reasons why I mostly scoff at attempts to make computer programming a compulsory schooling subject. Coding as "the new literacy" devalues computing and is the very embodiment of the programming pop culture that Alan Kay has warned about.

Especially since the people behind this idea have zero idea about what is programming. Some want people to learn HTML, which is pretty much void.


It's hard to cultivate a good literary culture until you have a large literate and critical audience. Perhaps the same is true for programming culture.

I agree with your other points though.


Kay draws a distinction between news and new. A new JavaScript framework is news...a person can explain the idea in 5 minutes or so because it is a normal incremental change. It's incremental because it's projecting normal as the future. Evaluating JavaScript frameworks is exhausting because the differences are mostly mundane, not world wide web versus gopher.


So the difference between "new" and "news" is the difference in the perceived scope? Is this what you've got from Alan Kay's philosophy?


Its the difference between looking at something from a different angle and looking at it from space. It's much harder to go to space [than] to turn your head (well, was much harder before anyone did it - now its easy).


Yeah, that's what I thought too!


I think it's about inferential distance. "News" is only 1 or 2 inferential steps from common knowledge. "New" is several step removed, and as such look alien, crazy, or pointless.


No and of course not.


Most of those JS libraries are same MVC/MVP/MVVM done over and over again.


That was the point, you want a certain kind of new, not running around in circles at high speed.


Philosophical question: What's when "running around in circles at high speed" becomes normal? Will then "normal" become "new"?


I deeply believe that, as kay said, we are relative and will stop perceive things after a will, forgetting.. anything old will be new, even if it's normal, slow and ~sensical. Cycles. Or orbitals as I like to see them.


> balance

This is a funny word if you think about it. It's the property where several forces on a point are in equilibrium. This definition generalises to very abstract situations, and especially to political ones. Several sides are all pulling (or pushing... the metaphor doesn't really matter) in their own direction and where the final decision falls is where the powers are in equilibrium. It's the point which is as dissatisfactory for every party as that party is powerless. Sometimes, that's what you want.

Often, balance evokes the image of the halfway point. The balance between killing every Jewish baby and no Jewish baby is not killing half of all newborns. It's also not killing exactly zero babies. If you want a balance between killing all Jewish babies and no Jewish babies, the neo-nazis all have a saying and you end up having to kill one of every hundred million or so babies. Which is unacceptable. This example was an extremist straw-man to illustrate the following point: You're not looking for balance, you're looking to maximise a utility function.

The utility function may be maximised by looking for balance between forces, in fact it often is, or we approach something close to the maximum by finding the balance. However, you mustn't mistake the balance for the utility function. You're not maximising balance. You're looking for a solution to a problem. You want less javascript client frameworks? Ok. You still want some javascript client frameworks? Ok. Why.

Because you want to maximise the utility of javascript client frameworks (I assume). This utility might be different for different people, i.e. they may want to do different things with the frameworks, etc. But, I can agree with you that having a constant stream of new ones serves no utility, except the tautological one of "let's have as many frameworks as we can write".

Now we come back to balance. At some rate of new frameworks being made, we balance out the amount of work spent on maintenance of the old ones with the influx of new ideas that make our work and life easier and from time to time we completely overhaul and forget an old technology. Which, in turn, maximises our utility of these frameworks. It does look like balance <=> utility, but not quite. This is a balance in the context of a specific utility function. You've defined the utility function as "I want X and Y with preference weights α and β", which looks very much like a linear programming[1] problem, the solution to which is... weighted balance.

Others would not agree to your utility function. They maybe don't want new ideas so much. Now you're balancing utility functions. But those people still agree that they want to "find the balance". It's just that their equilibrium is not your equilibrium.

So, please don't just throw out "there's balance" like that. Everyone can agree to balance and it's at a different point for different people. It's a word that causes... well, muddled thinking. If you can, avoid using it at all[2]. Get to the root of your problem as much as you can, then say what ails you. "I like seeing new approaches tried, but it's hard to keep up with the influx of largely samey ones that are constantly cropping up. I wish they would slow down." -- or something along these lines, I'm not saying this is what you specifically want.

Sorry for the long rant. I've had to listen to people wanting to balance a lot lately.

[1] https://en.wikipedia.org/wiki/Linear_programming a type of math problem concerned with finding the point where the given variables all satisfy a set of constraints expressed as linear inequalities and a given function achieves a maximum. [2] maybe there is a balance to abusing "balance"...


Well you actually spelled my thoughts, so thank you :) I could have been more precise in what I meant, but I wanted to stay abstract, not specific to some trendy example, but having a general view on what structures and shapes forces in a 'new' context and how evolution goes. Maybe it's just an entropy thing blended with the memory limit of a generation that will have the same energy as its predecessor but without clear understanding of the state of the art, meaning they will walk the same paths thinking it's new instead of recognizing the old.


Great stuff. This immediately made me think of Steve Jobs and the way he approached - I was going to say product design, but really everything he did. It's a very Budhist way of thinking about the world.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: