Notes on Postmodern Programming (2002) [pdf]
mcs.vuw.ac.nz
Notes on Postmodern Programming (2002) [pdf]
1–10 of 12 posts
Re: Notes on Postmodern Programming (2002) [pdf]
#2I admittedly skimmed through, but it seems to be more systems theory, as applied to computer science, than a new form of computer science in and of itself.
Re: Notes on Postmodern Programming (2002) [pdf]
#3This was a big deal in 2002. It got on the front page of Slashdot. I was a student at VUW at the time; someone got a cake with the Slashdot front page printed on icing and Robert Biddle did a magnificent job cutting it up.
Re: Notes on Postmodern Programming (2002) [pdf]
#4This is absolutely horrendous:
> Postmodern computer science holds that no requirements can be both complete and consistent: you have to pick one.
This makes no sense whatsoever. It's up to people to make up their minds about what they want. If they can't, then maybe they don't deserve to be written programs for?
> Formal analysis can be used to show the absence of bugs, but never to show the correctness of the specification.
If the specification is wrong, that's the business analyst's problem. The programmer may work under the assumption that the specification is correct.
> Programs can exhibit “faults in construction” that would be forbidden by a modernist approach.
wat
Re: Notes on Postmodern Programming (2002) [pdf]
#5Appalling. Self-indulgent without being funny; barely relevant – note outdated Devo reference– and absolutely without enlightenment, even considering its publication date. I feel resentful that my time was wasted this way.
Re: Notes on Postmodern Programming (2002) [pdf]
#6this is a poe, right? one of the primary tenets of postmodernism is that nothing can be objectively true or false. while I suspect there may exist certain less-than-serious programming languages which support this and other postmodern features, I don't think that postmodernism has anything useful to add to the field of computer science.
Re: Notes on Postmodern Programming (2002) [pdf]
#7This is absolutely horrendous: > Postmodern computer science holds that no requirements can be both complete and consistent: you have to pick one. This makes no sense whatsoever. It's up to people to make up their minds about what they want. If they can't, then maybe they don't deserve to be written programs for? > Formal analysis can be used to show the absence of bugs, but never to show the correctness of the speci…
> This makes no sense whatsoever. It's up to people to make up their minds about what they want. If they can't, then maybe they don't deserve to be written programs for?
It makes perfect sense. To account for every edge or use case for a requirement you'd have to create many different interfaces/points of contact to suit every need. For example, if I want to create a dating app, the interface and underlying code for a mobile device will break consistency with the interface and underlying code of a web page. You could be consistent with a translation layer, but then the interface or code will be incomplete for that particular use case.
> Formal analysis can be used to show the absence of bugs, but never to show the correctness of the specification.
Working in a horizontally stratified organization where the programmer doesn't learn the business domain is ill advised. Often the programmer has the most context and understanding of both the business processes as they are being formalizaed into code. Additionally your understanding of the specification may be flawed or simply written incorrectly, and this can never be formally analyzed.
> Programs can exhibit “faults in construction” that would be forbidden by a modernist approach.
In other words, a program can have a bug as a feature, or something that is wonky, but tolerated.
Re: Notes on Postmodern Programming (2002) [pdf]
#8This is absolutely horrendous: > Postmodern computer science holds that no requirements can be both complete and consistent: you have to pick one. This makes no sense whatsoever. It's up to people to make up their minds about what they want. If they can't, then maybe they don't deserve to be written programs for? > Formal analysis can be used to show the absence of bugs, but never to show the correctness of the speci…
> This makes no sense whatsoever. It's up to people to make up their minds about what they want. If they can't, then maybe they don't deserve to be written programs for? It makes perfect sense. To account for every edge or use case for a requirement you'd have to create many different interfaces/points of contact to suit every need. For example, if I want to create a dating app, the interface and underlying code for…
> the interface and underlying code for a mobile device will break consistency with the interface and underlying code of a web page.
Are you talking about some notion of “consistency” that has nothing to do with logical consistency?
> Additionally your understanding of the specification may be flawed or simply written incorrectly, and this can never be formally analyzed.
The whole point to making a formal specification is reducing the potential for misunderstanding. In fact, the only way to misunderstand a formal specification is to be mathematically incompetent.
---
Reply:
> Yes, the section is called "On Requirements" and the paper is about building programs, not abstract or theoretical computer science/logic.
Yet requirements are logical artifacts.
> do[sic] to a level of randomness and misunderstanding of our natural world,
There's nothing to understand about the natural world. You only need to know what you want the program to do. In other words, you need to consider every possibility, and make up your mind about how you want it to be handled.
> we simply do not have a finite amount of variables to statically analyze against.
wat
Re: Notes on Postmodern Programming (2002) [pdf]
#9Earlier quoted context omitted.
> This makes no sense whatsoever. It's up to people to make up their minds about what they want. If they can't, then maybe they don't deserve to be written programs for? It makes perfect sense. To account for every edge or use case for a requirement you'd have to create many different interfaces/points of contact to suit every need. For example, if I want to create a dating app, the interface and underlying code for…
> the interface and underlying code for a mobile device will break consistency with the interface and underlying code of a web page. Are you talking about some notion of “consistency” that has nothing to do with logical consistency? > Additionally your understanding of the specification may be flawed or simply written incorrectly, and this can never be formally analyzed. The whole point to making a formal specificati…
> Are you talking about some notion of “consistency” that has nothing to do with logical consistency?
Yes, the section is called "On Requirements" and the paper is about building programs, not abstract or theoretical computer science/logic.
> The whole point to making a formal specification is reducing the potential for misunderstanding. In fact, the only way to misunderstand a formal specification is to be mathematically incompetent.
I suppose we're talking about the semantics of the word formal, as well as the level of granularity one can hope to achieve over a specific problem domain. While I have no doubt that all processes can and will eventually be reduced into an algebraic function, currently, do to a level of randomness and misunderstanding of our natural world, we simply do not have a finite amount of variables to statically analyze against.
Re: Notes on Postmodern Programming (2002) [pdf]
#10Appalling. Self-indulgent without being funny; barely relevant – note outdated Devo reference– and absolutely without enlightenment, even considering its publication date. I feel resentful that my time was wasted this way.
You poor thing