add raw paper

lujun9972 · lujun9972 · commit 8e0eb0ca8fc8 · 2016-06-08T13:09:14.000+08:00
diff --git a/Python Common/为什么用python重写shell-script.org b/Python Common/为什么用python重写shell-script.org
@@ -0,0 +1,41 @@
+#+TITLE: 为什么用python重写shell-script
+#+URL: http://Fslott-softwarearchitect.blogspot.com%2F2016%2F06%2Fwhy-rewrite-shell-script-in-python.html
+#+AUTHOR: lujun9972
+#+CATEGORY: Python Common
+#+DATE: [2016-06-07 二 19:04]
+#+OPTIONS: ^:{}
+
+Here's the actual quote:
+#+BEGIN_QUOTE
+    Why would you need to rewrite a working script in python ? 
+    Was there any business direction towards this ?
+#+END_QUOTE
+
+This was an unexpected response. And unwelcome. I guess I called their baby ugly.
+
+The short answer is that the shell script language is perhaps one of the worst programming languages ever invented. Okay. I suppose it's better than whitespace. Okay it's better than many others. See https://en.wikipedia.org/wiki/Esoteric_programming_language
+
+The longer answer is this:
+
++ There are (at least) three ksh scripts involved, two of which are over 1,000 lines long. It's not perfectly clear precisely what's involved. It's ksh. Code could come from a variety of places through very obscure paths; e.g. the source command and it's synonym, ..
++ There are no comments other than #!/usr/bin/ksh and a few places where code is commented out. Without explanation.
++ There is no other documentation. The author had sent a email describing the github repo. The repo lacked a README. It took two tries to get them to understand that any email describing a repo should have been the README in the repo. There is barely even a command-line synopsis. (Eventually, I found it in the parser for command-line options.)
++ No tests of any kind.
+
+The last point is the one that I find shocking. And I find it shocking on a regular basis.
+
+Folks are able and willing to write 1,000's of lines of shell script without a single unit test, integration test, system test, performance test, anything test. How do they know if this works? Why am I supposed to trust it?
+
+More importantly, how can I meaningfully wrap this into a RESTful API if I'm not even sure what the command-line interface really is? It's the shell. It could use environment variables that are otherwise undocumented. They would be discovered when they cause a crash at run time. Crashes that become an HTTP 500 status code and a traceback error message in the web log.
+
+The "business direction" sounds like an attempt to trump the technical discussion with a business consideration like "cost" or "benefit". It should be pretty self-evident that 1,000's of lines of shell script code is technical debt.
+
+The minimally viable replacement will probably be a similarly-sized of Python script that mindlessly mirrors the original shell script. It's sometimes quite hard to tell what purpose a shell function really serves. The endless use (and re-use) of global variables can make state change hard to follow. Also, the use of temporary files which are parsed (and reparsed) as a way to set state is a serious problem.
+
+What's important is that the various OS services used by the shell script are mockable. Which means that each of the 100 or so individual functions within the script can be tested in isolation. Once that's out of the way, refactoring becomes plausible.
+
+Let's savor those words for a moment: Tested. In. Isolation.
+
+Ahhh.
+
+The better replacement is (I think) about 250 lines of Python -- perhaps less -- that perform the real 8-step process that we're automating. Getting rid of bash language cruft is challenging, but essential.
diff --git a/Python Common/为何我选择python，python擅长什么，python的特点是什么.org b/Python Common/为何我选择python，python擅长什么，python的特点是什么.org
@@ -0,0 +1,41 @@
+#+TITLE: 为何我选择python，python擅长什么，python的特点是什么
+#+URL: http://slott-softwarearchitect.blogspot.com/2016/05/why-python-whats-it-good-for-how-is-it.html
+#+AUTHOR: lujun9972
+#+CATEGORY: Python Common
+#+DATE: [2016-06-07 二 19:04]
+#+OPTIONS: ^:{}
+
+First. The question is moot. It's a programming language. It's good for programming.
+When I push back, folks try to produce languages which exist only in certain pigeon holes.
+
+"You know. PHP is for web and JavaScript runs in the browser. What's Python for?"
+
+The PHP and JavaScript examples aren't helpful. That doesn't narrow the domain of problems for which Python is appropriate. It only shows that some languages have narrow domains.
+
+"You know. Objective-C and Swift are for iOS. What's the predominant place Python is used?"
+
+Python also runs on iOS. I don't know if it has suitable bindings for building apps. If it does, that doesn't change my answer. It's good for programming.
+
+"Java is used mainly for web apps, right? What about Python?"
+
+Okay. At this point, the question has slipped from moot to ignorant.
+
+Can we just set that aside? Can we move on?
+
+If you want some useful insight, start here:
+
+http://web.eecs.umich.edu/~bchandra/courses/papers/Wirth_Design.pdf
+
+Yes, it's an essay from 1974. Parts of it are a little old-fashioned, but a lot of it is still rock-solid. For example, the idea of strongly-typed pointers is considered more-or-less standard now. It was debatable then. And Wirth's opinion continues to drive language design.
+
+Page 28 has the key points: features of a programming language. Enumerated by the inventor of Pascal, Modula, Oberon, and other languages too numerous to recall.
+
+Some of the list is a little dated. "...different character sets...," for example, has been superseded by Unicode.
+
+Also, the list is focused on compiled languages. Python is a dynamic language. It's interpreted. Yes, there's a compiler, but that's mostly an optimization of the source code. If you replace "compiler" with "run-time", the list stands up as a description of good languages.
+
+I like this list because it helps characterize why Python works out so well. And why many other languages are also pretty good. It points up the reason why quirky languages like JavaScript (or even Ruby) are suspicious. Some of the points about efficiency are important topics for further discussion.
+
+I often have to remind folks who work with Big Data that most of our processing is I/O bound. Python waits for the database somewhat more efficiently than Java. Why does Python wait more efficiently? Because it uses less memory. Sometimes this is a win.
+
+Let's not ask silly questions about a general-purpose language. Instead, let's benchmark solutions, and compare tangible performance numbers using real code.
