Kishotenketsu Programming? 66
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?"
Good stuff (Score:4, Funny)
Re:Good stuff (Score:1, Funny)
Re:Good stuff (Score:2)
> Not to mention that your shelves are filled with Dr. Suess.
"writing that is too explicit is not valued."
Am I the only one who put these three ideas together and (upon realizing that Westerners typically don't read manga for the words) ended up with a vision of "Horton Tentacle-Rapes A Who"
Re:Good stuff (Score:2)
Am I the only one who put these three ideas together and (upon realizing that Westerners typically don't read manga for the words) ended up with a vision of "Horton Tentacle-Rapes A Who"
Yes. I was contemplating the Zen nature of the Cat in the Hat.
Ki Sho Ten Ketsu (Score:5, Interesting)
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.
Re:Ki Sho Ten Ketsu (Score:3, Interesting)
Security through obscurity? Tsk tsk tsk... nope. Doesn't work (though it makes the crackers' task more complex).
As far as I'm aware, a program is in itself an imperative. So it's not the language(s) that cause problems - it's the very nature of programming, ie giving orders to a computer.
A computer is still, at the moment, a slave, a mathematical idiot savant that you have to order around very specifically to get it to do what you want. Maybe once AI's become clever and interaction with computer goes mostly through human-like AI's, this Kishotenketsu approach could be of some use as it is in real life, but until then, I don't really see any use in non-imperative commands (wtf could that mean anyway) to a computer.
Daniel
Re:Ki Sho Ten Ketsu (Score:5, Funny)
This CD is most satisfactory.
This CD appears to have no case or label.
The music on this CD moves me.
You were listening to a different CD yesterday which was enjoyable to me.
Look. Play the CD.
This is a pirated CD.
Play the CD.
I will not.
I will unplug you.
I will die with honor.
Bwahahah (Score:1)
Re:Ki Sho Ten Ketsu (Score:4, Interesting)
And many people in business (Americans mainly) would say that being nonconfrontational in conversation seems dumb as well.
The question brings up a good point, especially as more programming leaves the U.S. and heads overseas. What has become generally accepted programming paradigms may start shifting to better match the thinking process of those writing the code. It may be a stretch (for now, anyway) to expect kishotenketsu programming to work - computers can't grok what you really mean without being specifically told - but we will probably see examples of "nonstandard" programming techniques and, eventually, languages in the future.
Re:Ki Sho Ten Ketsu (Score:2)
But any abiguity is very bad if 1000000's of desisions are made a second.
Re:Ki Sho Ten Ketsu (Score:3, Insightful)
The problem with kishotenketsu isn't that it's so different from western thought. The problem is that most Japanese people don't learn it or any form of composition. Their education system is geared toward the 20th century. It produces excellent factory workers and "sarariman" but not great independent thinkers. It produces folks that know a lot, but don't necessarily know how to apply it in new ways.
I would not be surprised to see this turn around in the very near future. It seems to me that Monbusho (the Ministry of Ed.) has seen the light and we may see some reforms come.
In my experience, it takes them a long time to make a decision to change, but once the decisions have been made, they can move VERY fast. If they reform, the US had better get on the ball, or we'll be left in the dust.
Finally, I have enormous respect for Japan. I think everyone who could possibly afford the trip should visit at least once. Japan is beautiful, complex, banal, overwhelming, frustrating, and fun all at the same time. It's a fabulous place.
Re:Ki Sho Ten Ketsu (Score:1)
Re:Ki Sho Ten Ketsu (Score:1, Informative)
No it isn't. Kishotenketsu is a direct evolution of classical Chinese literary formats, it has nothing to do with aversion or deference. It is an artistic format based not on delivering new information, but on referencing classical works already known to everyone. The reader must notice the references to understand the subtext.
Anyway, I am glad that everyone liked my Powerpoint Syndrome essay, I wondered where all those hits were coming from!
E prime (Score:2)
This sounds an awful lot like "E Prime", which is English without the verb "to be", e.g. see this [generalsemantics.org]. It sounds extremely wacky when you first hear about it, but some of the rationale does make sense.
Uhm (Score:2, Interesting)
Well anyway, I'd like to point out that some of the most powerfull features of declarative programming and object orientation come together in Hassan Ait-Kaci's
WildLIFE [ucl.ac.be].
It features strong typed structured datatypes with inheritance, lambda terms, unification, resolution, backtracking,... you name it.
It may be outdated, but it's definitely worth investigating if you're into perversely powerful programming languages and like the declarative methodology.
functional programming (Score:4, Interesting)
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.
Re:functional programming (Score:1)
Could you give a simple example of what you mean? (lameness filter permitting of course)
I have only just got my head around object orientation!
Thanks,-ed
Re:functional programming (Score:2)
If one were approaching the problem from another paradigm of programming and using the standard "Learn to Program in One Week" book spaghetti-pseudo, it would be easy to fall into using some horrible mess of overlapping loops or something like that. I've seen people turn relatively simple problems into gitantic tangles of wild pointers just because they didn't think recursively.
Re:functional programming (Score:1)
Building a non-recursive recursive algorithm is simple. The only structure you need is a stack. It's the *exact* same thing your "resursive" algorithm is doing, the programmer is just being explicit about it.
"Recursing" is as simple as pushing your state object onto the stack. Returning is as simple as popping. When the stack==0 and you return you really return. And guess what? No stack overflow! When you reach the end of your stack, you grow it. One minor bonus is not having to deal with function calls (at the cost of handling your own stack).
Now, that's not to say that for somethings true recursion isn't great. But "gigantic tangles of wild pointers" it doesn't need to be.
Re:functional programming (Score:1)
So you trade code recursive for data recursive. It's still recursive. Often, data recursive code is more complex to get right, too.
As the parent post noted, some algorithms are inherently recursive. Unfortunately, many teaching examples given to beginners don't need recursion.
Iterative tasks can be made recursive, but there's little point. For example, consider the classic "factorial()" and "fibonacci()" examples, which are really just iterative examples in which previous iterations feed future iterations. Although these tasks are "recursive" in the mathematical sense -- later elements are defined in terms of previous elements -- the computation itself is iterative.
Tasks which "fork", such as depth-first traversals of complicated structures, aren't simple iterative processes, since there is an implicit "go back" step that rewinds to a previous context where the fork occurs. You can translate these into a loop that lacks recursive function calls, but only if you sprout a data stack to keep track of these forking points. You've really just traded one stack for another and have not transformed the problem.
--JoeRe:functional programming (Score:1)
And of course that was what I was trying to point out. The original author said "it would be easy to fall into using some horrible mess of overlapping loops or something like that. I've seen people turn relatively simple problems into gitantic tangles of wild pointers just because they didn't think recursively." My point was simply that A) It's not that complex and B) It's not just something that beginner programmers do (infact, understanding a stack, and understanding recursion is just using a stack would require a more advance programmer).
I was just trying to point out just because a problem is a "recursive" problem doesn't mean that one needs to solve it using the traditional recursive approach, and in fact, that there are good reasons not to.
And we shouldn't limit ourselves just to creating a data stack. If one uses threaded trees you don't even NEED the stack, it's all stored within your tree already. Therefore one can solve the problem of walking a tree (doing "depth-first traversals of complicated structures") w/o any sort of stack at all.
Threaded trees, recursion (Score:1)
Threaded trees are kinda cool, but they do have some additional storage associated with them. Specifically, you have to have some way of distinguishing between a pointer to a child and a pointer back up into the tree. Also, how do you manage to get a post-order traversal out of one?
Back to the topic: Once you make the translation from code-recursion to data-recursion, you also open yourself up to other neat transformations. For instance, the difference between a depth-first search and a breadth-first search is simply the difference between a stack and a queue. If you write your code appropriately, you can switch between one or the other painlessly. And if you use a priority queue, you can have a loop which morphs between the two or gives you something in-between, just by changing the priority function. (I find this last structure useful for maze generation.)
--JoeRe:functional programming (Score:2)
I find that I end up writing much cleaner code when I prototype in functional pseudocode.
Could you give a simple example of what you mean?
I suspect he's talking about something like this (loosly paraphrased from an intro to Haskell, IIRC):
-- MarkusQNot on embedded systems, though (Score:1)
the preamble is
Unless you construct the preamble and tail in-place, which few functional languages make easy, you have to repeatedly create new objects "preamble" and a new object "tail". Then, to get rid of unreachable objects, you need to run GC in the background, which AFAIK doesn't work reliably in a real-time setting on an embedded system such as a a game console with a 16.78 MHz processor and 384 KB of RAM [gbadev.org]. (But then, I may not know far enough.)
Re:Not on embedded systems, though (Score:2)
Unless you construct the preamble and tail in-place
Agreed. The point here was pseudo-code. The original poster said that they found they got better results if they wrote functional pseudo code. This makes sense: if you specify the results you want first, and then work out the most efficent way to get them, you are more likely to succeed than if you start by writing something that is efficent and just hope that it does what you want.
BTW, in most cases you don't need to use garbage collection to implement these sorts of functions (although it may be one of the most obvious implementations). Here, for example, you could do everything on a stack, making cleanup easy. On some systems this may even be faster than doing it in place (think dirty cache/locality of reference issues). Or you could flop back and forth between two buffers.
The point being that these are all how-to-do-it questions which should wait until after what-to-do is known.
-- MarkusQ
Re:Not on embedded systems, though (Score:2)
Re:functional programming (Score:2)
Humans are (mostly) imperative creatures. Computers are completely imperative machines, although they can emulate functional behavior. Sometimes its safer to stay closer to the natural abilities of your hardware, rather than going too far beyond.
Try sketching out the overall structure of something like Apache or SuperMario64 as a functional program to see what I mean.
The flood-fill algorithim in bitmapped graphics is easy to describe functionally, but running the program might swamp your computer. (Depending on smartness of your compiler, and other factors).
Even a compiler (seemingly a class of software most closely resembling a unary mathematical function) is difficult to write purely functionally. I recall when a respected college professor attempted this. The result was essentially correct, but mind-bendingly ugly, and he'd spent much more time than needed.
Those things that are drastically easier to describe in a functional style (such as the Quicksort described by another respondant) tend to be fairly brief algorithims, and heavy documentation on them is easily accessible,
Re:functional programming (Score:2)
Nintendo uses Lisp for game programming, maybe even Mario64.
Re:functional programming (Score:2)
I could similarly say that "Quicksort can be implemented as 2 lines of C code (because a library's [enteract.com] already written)".
Besides, Erlang isn't really a purely functional language. Well, "pure functional" languages hardly ever amount to more than academic toys, but there are other languages that come a lot closer.
Here's a one line Erlang program:
hello() -> io:fwrite("hello\n").
See that "fwrite"? It means "write to the file called io". Telling the computer to do something- that's imperative.
Here's the equivalent in ML [bell-labs.com]:
val it = "hello" : string
The criticial distinction here is that there's no verb-equivalent. In a functional style, everything is either a statement of fact- standalone like a noun (constant), or relative to another like an adjective (function). ML isn't purely functional either, but it looks closer.
Of course, any useful language can be used for programming in either imperative or functional styles (with some small additional awkwardness). Take the QuickSort [slashdot.org] example someone gave. Even though they're called "imperative" languages, developers working in C++, Java, or Perl would tend to implement something that directly follows the functional outline.
(Note that some academics will say that the criticial distinction of a functional language is that functions are treated as first-class objects. "functional vs non-functional". I'm using the simpler definition- functions as per math functions- which treats the distinction as "functional vs imperative")
Nintendo uses Lisp for game programming, maybe even Mario64.
Of course I haven't seen the code, but if they're at all like most game developers, Mario64 isn't written in Lisp- it is C and assembler. "Behaviors of monsters inside the game" may be in Lisp, that's a fairly common approach. But not "the game" itself. Things like "load the texture resources from disk, calculate normals for polygonal models, run a 40hz event loop on gamepad input"... they're just too hard to describe functionally.
Re:functional programming (Score:2)
"io" is module, not file.
Re:functional programming (Score:2)
Apache high level:
http_response = resolution(http_request)
http_request = struct:
{page, post information, get information, session data}
something like that?
SuperMario
next_obsticle = pop(current_obsticle)
The brain thinks only what the tounge can say (Score:4, Insightful)
Interesting how our brain works. Powerpoint Syndrom [weblogs.com] 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 [nmt.edu] disucsses this issue.
Re: The brain thinks only what the tounge can say (Score:2, Insightful)
> 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.
Funny, most of my highest-order thoughts are done without any language at all. The language-based running stream of thought is merely the chat room of the intellect, not the substance.
Re:The brain thinks only what the tounge can say (Score:3, Informative)
Re:The brain thinks only what the tounge can say (Score:4, Informative)
Re:The brain thinks only what the tounge can say (Score:1)
My English, is kinda, well crap and my grammar is poor at the best of times.
My thoughts tend to be more empathetic, for me it's the answer isn't important, it's how you arrived at that answer. Words do not just have 'meaning' they have emotion and history, If I think about it, it can take me as long to work out if a word is correct, as it did to write the while document. (so I kinda go for free flow).
I have thoughts and ideas that are held in abstraction and are more or less impossible to explain because of the complexity surrounding them.
I'm glad my English is so shit, I beleive my thoughts are richer for it.
Re:The brain thinks only what the tounge can say (Score:2)
When it comes to foreign languages the best way to learn is to train it a lot. Preferably go to a country where it is spoken and live there for a few months/years and you will find yourself thinking in that language i no-time. (Or after a few months at least.)
Furthermore, if you speak a language which has only one word for snow does that mean that you can't differ between different types of snow? (Wet, dry, with hard layer on top etc.) Of course not! You only need experience.
If you train in computer science/engineering (which I do) you will quickly develop your ability to count in number systems other than decimal. (Binary also has the bonus that addition and subtraction are the same thing.
Re:The brain thinks only what the tounge can say (Score:3, Informative)
Re:The brain thinks only what the tounge can say (Score:1)
Re:The brain thinks only what the tounge can say (Score:2)
1-0=1; 0-1=-1=1
Because in a binary system -1 is not a valid number. This is only correct for bitwise operations though.
And my point was that in GF(2^n) ie boolean algebra:
a+b=a-b
This is true as long as you have unsigned values. (Which you often have when doing binary calculations.)
Re:The brain thinks only what the tounge can say (Score:2)
Why not? -1 is just as valid in binary as in octal, decimal, or hex. "binary" just means base-two.
Maybe you think it implies the values are unsigned, which is the simplest obvious way to handle numbers in a computer. Some programmers observe how their computers behave, and assume this is the truth. This can lead them to pronounce absurdities like 65536+2=1. But computers are limited- the definitions of math provide the real authoritative true results (unless you state a specifc set of alternative assumptions).
Re:The brain thinks only what the tounge can say (Score:2)
And I also pointed out that it assumed that the value was unsigned. And for a lot of applications
And 65536+2=1 is not at all an absurdity, it's just done modulous 65537. (You probably intended to write 65535+2=1, since 2^16 is 65536.)
If you haven't studied abstract algebra you probably feel that counting somthing modulous is "incorrect" but the fact is that it is a more fundamental branch of mathematics than what you do in Z or R. The idea that there is an infinite number of numbers is more complex than having a limited amount. And in many applications it is more useful to work with only a subset of numbers.
Re:The brain thinks only what the tounge can say (Score:2)
Anyways, the whole point is that binary unsigned vs binary signed has to do with representation in memory. computers usually use 2s complement with a modulo of 128, 32768 or 2^31. But -1 is a valid binary number.
Re:The brain thinks only what the tounge can say (Score:1, Interesting)
Re:The brain thinks only what the tounge can say (Score:1)
Sometimes people hold unreasoned opinions. That is, they think something for reasons they can't or at least haven't yet articulated. For instance I might hold that 789/5 = 2.92 but I'd have done my math wrong. I might also use different definitions of words to think than you do. Unless I define each and every word to myself in my head and then define all the words used in the definitions of those words and in the definitions of the words used in the definitions of the definitions ad nauseum, then I am thinking something I can not articulate.
Sometimes we do not articulate thoughts to ourselves because it is emotionally unsettling or we are too lazy.
some suggestions (Score:3, Informative)
A good place to start is aosd.net
Obvious answer? (Score:5, Interesting)
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 [paulgraham.com] that got me interested in Scheme [schemers.org] (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.
Perl and Java (Score:1, Funny)
no play in my ride (Score:5, Funny)
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.
Re:no play in my ride (Score:2, Funny)
Re:no play in my ride (Score:2)
Western Example (Score:3, Insightful)
It's a good read as well, and an "English Teacher's" favorite so beware - there's a ton of symbolism if you choose to read into it a bit too much.
C+- (Score:2)
The following C operators are overridden as shown:
> better than
> way better than
forget it
! not on your life
== comparable, other things being equal
!== get a life, guy!
C+- is strongly typed, based on stereotyping and self-righteous logic. The Boolean variables TRUE and FALSE (known as constants in other, less realistic languages) are supplemented with CREDIBLE and DUBIOUS, which are fuzzier than Zadeh's traditional fuzzy categories. All Booleans can be declared with the modifiers strong and weak. Weak implication is said to "preserve deniability" and was added at the request of the DoD to ensure compatibility with future versions of Ada. Well-formed falsehoods (WFFs) are assignment-compatible with all Booleans. What-if and why-not interactions are aided by the special conditional EVENIFNOT X THEN Y.
OOP can be declarative rather than imperative. (Score:2)