3 ms·

> 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. T

> 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.

radiowave 5y ago
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.
- deleted 5y ago
  [deleted]
- ssivark 5y ago
  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.
- TeMPOraL 5y ago
  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.
rektide 5y ago
steve yeggie's politican axis of software development comes hard to mind. https://gist.github.com/cornchz/3313150 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/1087511545091899392?lang=en 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.
- radiowave 5y ago
  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.
  - igouy 5y ago
    "LAMBDA: The ultimate Excel worksheet function" https://www.microsoft.com/en-us/research/blog/lambda-the-ultimatae-excel-worksheet-function/ https://www.microsoft.com/en-us/research/blog/lambda-the-ult...
cdrini 5y ago
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.

radiowave 5y ago

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.

deleted 5y ago
[deleted]
ssivark 5y ago
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.
TeMPOraL 5y ago
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.

rektide 5y ago

steve yeggie's politican axis of software development comes hard to mind. https://gist.github.com/cornchz/3313150 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/1087511545091899392?lang=en 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.

radiowave 5y ago
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.
- igouy 5y ago
  "LAMBDA: The ultimate Excel worksheet function" https://www.microsoft.com/en-us/research/blog/lambda-the-ultimatae-excel-worksheet-function/ https://www.microsoft.com/en-us/research/blog/lambda-the-ult...

cdrini 5y ago

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.