4 ms·

“He summarises by saying the only good reason to design a programming language (I assume he means a radically novel language) is to shape your understanding of

“He summarises by saying the only good reason to design a programming language (I assume he means a radically novel language) is to shape your understanding of the problem. No regrets of being the only user of his first language, Datalist, because the point is that it shaped all his later thought in his research.” I don’t design languages but I speak and write (iterating between different forms) for much the same reason. Thoughts made concrete in some way are much easier to manipulate. Programming can be much the same.

eequah9L 8y ago
For every new project idea, I open a file and start writing everything that comes to mind. A design document if you will. Writing stuff down like this makes things obvious and tangible, easy to juxtapose, as you say, easy to manipulate. I can't count how often that document is the last thing that I do on a project, because I just can't make it work even on the paper, where ideas are cheap to sketch out.
Klathmon 8y ago
This is also why I'll often not ask important questions in meetings and will instead ask them in a chat message or email. Not only does the act of writing it out make me ask a better question (and there are times I answer the question myself before sending it!), but the answers are often much better when written down. (Not to mention the additional benefits like easier searchability)
- lugg 8y ago
  Discussion is cheap. If it is on topic, saying something stupid quickly and then rolling back the conversation is a far more efficient use of your time. You do need to pick your audience. Some people really struggle with this style of conversation. The rapid depreciation/substitution of facts can be a tad tiring. But for those that can take it, this is essentially the same as writing things down but it's faster and has the added benefit of at least one other person "checking your math" as you go.
  - Klathmon 8y ago
    Don't get me wrong, a realtime discussion is extremely important in many cases. When brainstorming or talking through bugs or building something collaboratively, it doesn't get any better than an in-person or video meeting. But when it comes to more complicated details, one-off questions, important decisions, or bringing the "results" of an investigation to a group, text is just better a lot of the time. I can't count the number of times that a decision was made verbally in a meeting only to find that half the meeting misunderstood the decision or can't remember details about it the next day. Or going to discuss a complex bug/problem and having to spend a significant amount of time talking about the "setup" to the problem rather than the problem itself. It's those cases where spending 5 minutes writing the question up and letting people read and understand it before jumping into a meeting, or even something as simple as following up a meeting with a written summary of the important points made can be very powerful.
    - joshmarlow 8y ago
      > I can't count the number of times that a decision was made verbally in a meeting only to find that half the meeting misunderstood the decision or can't remember details about it the next day. I've had the same experience, but I tend to follow a hybrid approach; bring up everything you can think of in the meeting, then immediately following up with an emailed recap of what was agreed upon. It helps make the verbal decisions explicit and iron out additional details.
    - ska 8y ago
      I think what you are saying has a lot to do with particular meeting culture(s) and dynamics, rather than anything specific about the medium. Many people would be stunned by the idea that a written followup (e.g. minutes) would represent a novelty - or for that matter circulating context beforehand (e.g. an agenda) with time to ask clarifying questions offline would be, either.
stcredzero 8y ago
He summarises by saying the only good reason to design a programming language (I assume he means a radically novel language) is to shape your understanding of the problem What of "meta-languages" like Lisp and Smalltalk? You can write your own control structures in Smalltalk, and they'll hew to the same 1st class meta-syntax as all of the "built in" control structures. Want a control structure for database transactions? Just write it as a function that takes code block arguments. Want control structures to handle optional values? Just write it!

eequah9L 8y ago

For every new project idea, I open a file and start writing everything that comes to mind. A design document if you will. Writing stuff down like this makes things obvious and tangible, easy to juxtapose, as you say, easy to manipulate. I can't count how often that document is the last thing that I do on a project, because I just can't make it work even on the paper, where ideas are cheap to sketch out.

Klathmon 8y ago

This is also why I'll often not ask important questions in meetings and will instead ask them in a chat message or email. Not only does the act of writing it out make me ask a better question (and there are times I answer the question myself before sending it!), but the answers are often much better when written down. (Not to mention the additional benefits like easier searchability)

lugg 8y ago
Discussion is cheap. If it is on topic, saying something stupid quickly and then rolling back the conversation is a far more efficient use of your time. You do need to pick your audience. Some people really struggle with this style of conversation. The rapid depreciation/substitution of facts can be a tad tiring. But for those that can take it, this is essentially the same as writing things down but it's faster and has the added benefit of at least one other person "checking your math" as you go.
- Klathmon 8y ago
  Don't get me wrong, a realtime discussion is extremely important in many cases. When brainstorming or talking through bugs or building something collaboratively, it doesn't get any better than an in-person or video meeting. But when it comes to more complicated details, one-off questions, important decisions, or bringing the "results" of an investigation to a group, text is just better a lot of the time. I can't count the number of times that a decision was made verbally in a meeting only to find that half the meeting misunderstood the decision or can't remember details about it the next day. Or going to discuss a complex bug/problem and having to spend a significant amount of time talking about the "setup" to the problem rather than the problem itself. It's those cases where spending 5 minutes writing the question up and letting people read and understand it before jumping into a meeting, or even something as simple as following up a meeting with a written summary of the important points made can be very powerful.
  - joshmarlow 8y ago
    > I can't count the number of times that a decision was made verbally in a meeting only to find that half the meeting misunderstood the decision or can't remember details about it the next day. I've had the same experience, but I tend to follow a hybrid approach; bring up everything you can think of in the meeting, then immediately following up with an emailed recap of what was agreed upon. It helps make the verbal decisions explicit and iron out additional details.
  - ska 8y ago
    I think what you are saying has a lot to do with particular meeting culture(s) and dynamics, rather than anything specific about the medium. Many people would be stunned by the idea that a written followup (e.g. minutes) would represent a novelty - or for that matter circulating context beforehand (e.g. an agenda) with time to ask clarifying questions offline would be, either.

stcredzero 8y ago

He summarises by saying the only good reason to design a programming language (I assume he means a radically novel language) is to shape your understanding of the problem What of "meta-languages" like Lisp and Smalltalk? You can write your own control structures in Smalltalk, and they'll hew to the same 1st class meta-syntax as all of the "built in" control structures. Want a control structure for database transactions? Just write it as a function that takes code block arguments. Want control structures to handle optional values? Just write it!