3 ms·

Oh it certainly lacks rigour. I was just outlining "an intention to be rigorous" to see what the response would be. There seems to be, so far, quite a lot of in

Oh it certainly lacks rigour. I was just outlining "an intention to be rigorous" to see what the response would be. There seems to be, so far, quite a lot of interest in this kind of project.

brudgers 14y ago
But alas the taxonomy of programming languages is a solved problem. There is Lisp. And there is Blub. Or less t-rolled: McCarthy and Von Neuman. Or more poetic: Dionysian and Saturnial. Rigor comes in many flavors. The starting point for all of them is rigorous thinking. One of the signs that my thinking is not rigorous is that I wind up proving the point I set out to prove. Then again, setting out to prove a point ought to be a warning flag. Even if it is inevitable that I do so. The key to rigor is recognizing that I am doing it. Lisp and Blub was where I wanted to go. My dissatisfaction led me to McCarthy and Von Neuman and that to another metaphorical connection between programming languages and literary criticism. And that fits with my larger interests; those being the ones which dispose me toward writing about software.
- mjburgess 14y ago
  As I said towards the end of the piece the intention is to come up with an abductive process an, "inference to the best representation", a formalized method for deciding between languages. I am aware that there are various taxonomies, and perhaps I shouldnt have made the aristotleian comment because it was rather misleading. My intention was to take an honest (you may say phenomenological) look at programming languages: to have a system by which the idioms of the language, its communal metalogics, etc. are all part of how we assess a language. Not the reductionism of the "procedural-functional", pre-existing landscape. I guess my point in referencing this landscape was to point out how inadequate it is, and how there might be a more complex and useful way of reasoning between languages. My next article on the subject, which I'd imagine will follow soon, will certainly be slightly refocused and clearer. This is very much a just-finished-typing first draft that I put out to see what the response would be, and what the appetite for this kind of analysis in the programming community is.

Oh it certainly lacks rigour. I was just outlining "an intention to be rigorous" to see what the response would be. There seems to be, so far, quite a lot of interest in this kind of project.

brudgers 14y ago

But alas the taxonomy of programming languages is a solved problem. There is Lisp. And there is Blub. Or less t-rolled: McCarthy and Von Neuman. Or more poetic: Dionysian and Saturnial. Rigor comes in many flavors. The starting point for all of them is rigorous thinking. One of the signs that my thinking is not rigorous is that I wind up proving the point I set out to prove. Then again, setting out to prove a point ought to be a warning flag. Even if it is inevitable that I do so. The key to rigor is recognizing that I am doing it. Lisp and Blub was where I wanted to go. My dissatisfaction led me to McCarthy and Von Neuman and that to another metaphorical connection between programming languages and literary criticism. And that fits with my larger interests; those being the ones which dispose me toward writing about software.

mjburgess 14y ago
As I said towards the end of the piece the intention is to come up with an abductive process an, "inference to the best representation", a formalized method for deciding between languages. I am aware that there are various taxonomies, and perhaps I shouldnt have made the aristotleian comment because it was rather misleading. My intention was to take an honest (you may say phenomenological) look at programming languages: to have a system by which the idioms of the language, its communal metalogics, etc. are all part of how we assess a language. Not the reductionism of the "procedural-functional", pre-existing landscape. I guess my point in referencing this landscape was to point out how inadequate it is, and how there might be a more complex and useful way of reasoning between languages. My next article on the subject, which I'd imagine will follow soon, will certainly be slightly refocused and clearer. This is very much a just-finished-typing first draft that I put out to see what the response would be, and what the appetite for this kind of analysis in the programming community is.