Is Programming "epistemologically challenged"
3 comments
That's why we have the concept of values.
You can't tell whether something is good or bad until you hold it against some value like... speed of execution, or intuitiveness, or least code. Once you do, judge away.
That's why postmodernism is especially challenged, it can't decide what about life is valuable.
You can't tell whether something is good or bad until you hold it against some value like... speed of execution, or intuitiveness, or least code. Once you do, judge away.
That's why postmodernism is especially challenged, it can't decide what about life is valuable.
We have values - code is good if (in no particular order):
+ It's clear from its text what it is doing
+ It's easy to modify to enhance it, without damaging its clarity
+ It's concise without being opaque
+ It's corrrect
The problem is creating an objective means of assessing code against these values.
+ It's clear from its text what it is doing
+ It's easy to modify to enhance it, without damaging its clarity
+ It's concise without being opaque
+ It's corrrect
The problem is creating an objective means of assessing code against these values.
Aren't the epistemological challenges of programming merely a reflection of the epistemological challenges of mathematics in general? For example, you can derive numbers (and number theory) from Combinatory Logic or Lambda Calculus or Set Theory. Apparently, you can derive Set Theory from Lambda Calculus and vice versa. Tarksi proved that you can't derive "truth" from inside a given formal theory. So why should we have the ability to decide "good" or "bad" code from inside a programming language?
which refers to this article:
entitled:
I found it an interesting read, although I concede that many would not.
However, I found in it this statement:
That made me think.
In programming we often talk about "Good Code" and "Bad Code". Even code that works can be described as "Bad Code" when it's, well, when it's what, exactly? What is "Bad Code"?
I'm assuming for the moment that we're only talking about working code - code that performs a task and does so correctly. I'm even assuming we're talking about relatively efficient code, so that precludes, for example, the bogosort.
There is code that despite working, and despite being efficient, practising programmers would call "Bad Code". But how do we know?
"Good Code" should be clear as to its purpose, clear as to its operation, clear that it does what it's supposed to, and maintainable. But how do we assess these things? How does a novice gain the expertise to glance at code and either nod approvingly, or shudder.
What is "Good Code".
How can you tell?