Hacker News Reader

Comment by locallost | Hacker News Reader

> They're all about this idea, which most programmers have that's wrong, is that you're going to write the program the right way. Nothing's going to be wrong. The whole idea is to make a fucking mess.

I think he's great and I've learned a lot from him, but this is where I immediately disagreed. But it got me thinking and I realized it's because the stuff I work on is mostly a solved problem. So I think people that reimplement stuff that already exists have this schtick about making it correctly, clean and efficient. He was mostly working on things really new so it had to be a mess. I just hate that the stuff I work on is a mess anyway even though it's nothing special at all.

View on HN

Oh I very strongly resonated with that! This was one of the two quotes I wrote down from the interview. One thing I notice when I see artists works or when I'm working on an artistic project of my own is that the project is absolutely ugly for 80% of the process. It takes a lot of changing, tweaking, adjustments, and sometimes also an unreasonable amount of fine detail work to get something that looks good; and then a ton more work to get something that looks great. That's what he means by "mess" I think; all projects should start as a mess, and develop/grow/iterate into something more beautiful.

I find programmers tend to operate less iteratively, and more like engineering, where you need to come up with a good solution before implementing it, because in engineering you can't undo, and costs are high to make changes after a certain point. The analogy I like is: programming is often compared to engineering/construction, but is perhaps better represented by gardening; it's got a much more organic nature and flexibility.

It happens that you don't get the insight into how to do something right until after you've made a few messes. I think Kay takes the view that the act of generating that insight is ultimately more valuable than the act of producing any one particular software artefact.

Because for the PARC folks from back in the day, the true vision for personal computing was to enable lots of people to do new things. That’s why Kay laments that the personal computing revolution is yet to happen.

Now let's apply that insight to the subproblems of your problem. And then to the subproblems of those subproblems.

The way I see it, the tools we use to program - all the way from IDEs through programming languages to the very way we code in plaintext - make the process too damn slow, the feedback loop way too long. Messing around, trying and modifying and retrying until you get something good, it all takes too long, so we hardly do it.

steve yeggie's politican axis of software development comes hard to mind. https://gist.github.com/cornchz/3313150

at work yeah, we all naturally want a very defensive, safe, territory. we dont want volatility & risk in our running, cash making systems.

it might be helpful to reflect on thr lifecycles of software development. Pioneers, settlers, & town planners comes to mind as a useful model, of the changing approaches as software established itself over time.

https://mobile.twitter.com/swardley/status/10875115450918993...

i'm really really warmed to hear that you were able to put yourself in the shoes of those who came before, those who were charged with building something out of nothing. most of us join fairly established entities, and we do not see the drive-to-make through the strong, powerful point of view of those trying to get create, those trying to get started.

when Alan Kay &all talk about personal computing, to me, it is much more a domain of will & creation & whimsy than the controlled, regularized, predictable processes we aim for when we professionals are building & elaborating our paid, industrial computing work.

An interesting dynamic here is that, having read Yeggie's article years back, I regarded Smalltalk as being somewhere towards the conservative end of the axis (at least, in comparison to other dynamic languages.) E.g.: variables declared before use, no truthiness, very few automatic type conversions. It results in a system with a high degree of internal consistency.

And yet, the goal of the language is to enable activity at the liberal end of the axis.

So maybe there's a more subtle goal: you have to enable someone to make a mess, but also equip them to get out of that mess into something more structured, as and when that becomes useful.

As a counter example, spreadsheets are wonderful for making a messy solution to certain kinds of problems - but how do you then it them into a spreadsheet that isn't a mess? I don't know that I've ever seen that happen - it seems like the right means of abstraction and combination to enable that to happen just don't exist in spreadsheet-land.

"LAMBDA: The ultimate Excel worksheet function"

https://www.microsoft.com/en-us/research/blog/lambda-the-ult...

Fun comment! What are some things you think that Smalltalk does have or does do that embody the liberal sides of the axis? I want to agree, but trying to describe the image based environment, or how being more messages helps, is challenging for me to elaborate on.

Personally, I think we grade really hard on the small but visible differences like "do I have to declare 'MyFoo foo' or is there inference typing &c about", but it's much harder to assess from a big picture what behaviors & differences there are, harder to understand how each language & runtime is going to help us make sense of things.

Spreadsheets are an interesting place to turn to next. I'd be interested to see spreadsheets that can also visualize the dependencies of cells, that show how values flow across the sheet. Having that positional sense is interesting, versus, say, a debugger where you can see maybe what lexical scope a value is from, or less interestingly the address on the heap where a value happens to be. There's still, in both spreadsheet & debugging, dependencies, which power the processing that is now underway. I feel like both environments could be much better at helping explore this.

Reply on news.ycombinator.com