Hacker News new | past | comments | ask | show | jobs | submit login
Programming as a medium for poorly understood, sloppily-formulated ideas (1967) [pdf] (github.com)
77 points by tosh 33 days ago | hide | past | web | favorite | 12 comments



Engineers and scientists usually don't understand that mathematics (and programming by extension) is ultimately a language, with all that that implies.

Formalism and rationality provide checks that whatever you are saying is coherent, but in the end what is being expressed are the ideas of a human mind, and the ideas expressed will be only as rigorous and thorough as the understanding you have about the problem you're describing.

There will also be a lot of assumptions that are not included in the formal object (the code) but which are essential to the full meaning of the concepts, and are either expressed as axioms or entirely omitted. A computer will blindly execute exactly what is being written in a program, but for the system to be used and evolved in a coherent way, it depends on the users knowing those untold assumptions that separate correct from incorrect interpretations.

There is an unexplored area for a platform to support this kind of exploratory, poorly understood and probably incomplete of wrong programs, with tooling to help the user refine a program iteratively from the first insights to a complete working state. "Live programming" and online notebooks a la Jupyter work in that direction, and spreadsheets directly support it (but are limited to a specific programming model).


Not disagreeing, but just to add on the other side of the coin: language can be a driver for thought and ideas. This might feel wishywashy without an example, but I usually feel that I need to reinterpret algebraic manipulation that I have done to understand what significance they have.

So in a way, I allowed myself to be a mechanical executer through the rules of algebra/calculus I've used, and then I re-engaged my intuition to understand what is happening.

It might even be my unwillingness to accept the mechanical approach purely that poses a big hindrance to fast tracking a lot of learning in this domain I have to do. Maybe I should just shut up and calculate as they say, but it's hard.

This just makes it all the more true that learning "languages" is the best way to become smarter. "Smarter" is a weird personal word here, but I'm at a loss for a better way to put it. What am going for is: languages can be an abstract lever that allows our limited cognitive potential to build culturally, which is distinct and will definitely interact with the knowledge ladder, but in a distinct way. "Languages" here are more general than just the textual/oral/syntactic, and am not talking about Russian/Arabic/French either.


> I usually feel that I need to reinterpret algebraic manipulation that I have done to understand what significance they have. So in a way, I allowed myself to be a mechanical executer through the rules of algebra/calculus I've used, and then I re-engaged my intuition to understand what is happening.

That's a sensible approach, but it works because you're executing mechanical in a well-defined problem domain, so there's an intuition attached to each term used, and you can build an overall intuition. You might as well use random mechanical transformations over an algebra and they wouldn't make any sense, just like if you attached random dictionary words forming grammatically correct sentences.

I see usage of formal languages as mathematicians and philosophers making "very precise sentences", i.e. being extremely precise with the meaning attached to each term so that it remains consistent among all the transformations of discourse (in fact, there's a formal theory of meaning which does exactly that).

But the main value of such exercise is in knowing what you want to express, not in the fact that you're being extremely precise while doing it; the latter can help you convince others of what you're saying, but they need to agree to the original axioms of your theory, otherwise they'll just be able to point very precisely where they think you are wrong.


I think the title here should be changed to the original: "why programming is a good medium for..." It changes the thesis quite a bit.


I have to agree. The current title implies that it's a negative thing. I'm not sure why it was changed when posting here, since it completely changes the meaning as well.


>implying implications

I see no need to assign a value judgement to it, and somewhat resent doing so.

Might be good for juicing clicks by confirmation bias, but the idea is nevertheless that programming is a medium through which incomplete understanding can be refined, and eventually expressed.

Good or bad should be left to the reader to judge.

I like the idea, if only because I've philosophically approached software in terms of chewing what a program is from what it isn't.


> programming is a medium through which incomplete understanding can be refined, and eventually expressed.

Which, by all forms of understanding I possess, is a benefit or beneficial to the users of programming. Ergo, a good medium.

If the title were "Programming as a potential medium for expressing/refining not yet well-formed ideas", then there'd be no value judgment at all (and we probably wouldn't be having this conversation). But as it is, the title uses "poorly understood, sloppily-formulated ideas" which automatically puts a negative spin, which is in a way counter-acted in the original paper by "good medium", implying that the paper isn't actually about bad ideas and how they're propagated through code.


This was my thought as well. I don't understand the objection to value judgements above.


Working with Haskell has made me realize how much undefined behavior I'm implicitly including in my programs.


Interesting. Which kinds of things in particular?

I think of undefined behaviour as a matter of knowing the many dark corners of C and C++. How did Haskell help?


This paper is from Marvin Minsky at MIT. He was an expert on AI, and co-founded the MIT AI lab, among many other things. He also invented the first heads-up display (HUD) in 1963 [0].

Such an interesting character.

[0]: https://en.wikipedia.org/wiki/Marvin_Minsky


This is what first order logic is for




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

Search: