Slashdot Mirror
Kishotenketsu Programming?
mike_stay asks: "Imperative Programming follows closely the 'outline' style of writing most of us were taught in elementary school. Japanese, however, have a very hard time with that writing style, as they've been trained in the concept of kishotenketsu: stories are usually told by bouncing around between various points of view, which necessarily give different accounts; no attempt is made to say what 'really' happened. 'Good writing style' expects readers to draw the conclusions; writing that is too explicit is not valued. The writing, therefore, tends to be inductive: specific examples precede general principles. The closest thing I can think of to kishotenketsu in programming is functional programming or declarative languages, but then, I'm American. Would other readers point me at other languages with this type of 'eastern' feel?"
...hence the reason my shelves are not filled with Japanese literature.
Yes, I am an agent of Satan, but my duties are largely ceremonial.
Kishotenketsu is an interesting writing style, and it lends itself to some interesting applications, particularly in philosophy or politics. (Plato's The Republic, while a narritive, goes in a pattern simmilar to Kishotenketsu, in that several unrelated examples or narritives are told, and then a final "bring them together" dialog is presented which shows the relationship between the original narritives, and leads the user to the desired conclusion.
:)
Kishotenketsu is a result of the Japanese aversion to direct confrontation, and consiousness of status. (For another example of status consiousness, a listener of music should not say "That is good music" because that implies that the listener is a superior musician, and in a position to judge the player. Rather, the listener should say something like "Your music moves me"
In any case, programs have a purpose, they DO something. While it certainly makes sense to abstract where applicable, being circuitous is not a good programming method.
I suppose you could do something like go calculate Pi out to find the circumference of a circle that has a radius of the constant that you want to use to calculate your taxes.
But that seems dumb to me
On the other hand, this could be a good anti-piracy methodology, if you put a bunch of unrelated code in your serial number validation routine.
I'm not sure I would call functional programming circuitous. Granted, one has to learn to think in an inductive manner in order to handle recursion, but I have found functional programs to be almost more directed than imperative programming. In an imperative language, you can sit down and twiddle a bit here and there, working towards the goal at your leisure. In a functional programming language, you have to never lose sight of your goal. Every line of code has to have a clear and well-defined role in achieving that goal.
That's why I tend to prototype functions & algorithms in a more lisp-style pseudocode even when I'm writing in C. I find that I end up writing much cleaner code when I prototype in functional pseudocode.
On the risc of being a lil offtopic, I would like to share the following observations. :-) ). However, it has been the language of my education. One of the tips'n'tricks that my english teacher from school told me was that in order to imporve my english, I should start thinking in it. The idea was that we our brain uses the first language (urdu in my case), and so our thoughts are limited by the expressions we can come up with using the language. Whatever language we learn afterwards is a process of run-time translations. But then with the passage of time we master other languages and we can train our brain to think in all these languages.
Interesting how our brain works. Powerpoint Syndrom is a very fine observation. English is not my first language( and that explains all the gramatical and spelling mistakes
So whats the point in pointing out the obvious. We are taught the basics, like the alpabets, and then we build upon these basics. However our knoweldge, our way of thinking will always be limited by basics. Its just like the decimal system. There are only 10 digits. You ll only be re-using them again and again. Consider how difficult it would have been if we were all to use the binary system for our daily mathematics. Same goes for the possiblity of using hexa or maybe centa number systems.
Edward D. Bono pointed out in his book on lateral thinking the very same things. We are taught a basic way of thinking, of reasoning. Thats limits us in looking at things from a different prospective.
An interesting paper, Beyond Language: Cultural Predispositions in Business Correspondence disucsses this issue.
... hee2 is stuck under the bed.
Incidentally, Ruby, though purely-OO, supports nifty things like true closures, and you can end up doing functional programming without realizing it at first [Ruby, of course, is designed with this sort of thing in mind]. It was the realization that I was doing this (or something very close to it), in conjunction with Paul Graham's essays that got me interested in Scheme (a sleek, lightweight dialect of Lisp).
So, perhaps the only real answer is to learn as many interesting programming languages as you can, and use the broadened perspective you gain to make an informed decision for yourself.
Kishotenketsu is a result of the Japanese aversion to direct confrontation, and consiousness of status.
exactly! what you'd end up with is an api that has 100 different functions all of which can only individually hint at the general direction of the output without making any kind of assertion about what is actually the correct output given your parameters. and care would be taken so that one function stands out as an obvious alternative to the others, except for maybe the more "senior" functions that have been built into the library from some time back. but, that's ok, because those functions, while the most obvious to use, would be the least useful in terms of the quality and clarity of values returned.
this gets no play in my ride.