You know, it is extremely hard to read from one's opponents. It's not that their ideas are so outrageous that you want to crush them under your thumbs like a bug. No, not really. Frankly, during my many many day dreams on many many issues, I have pull together strange ideas. Obviously, once I wake up and re-calibrate my reasoning system, those strange ideas fizzle out like fire under a Reno rain (in case you don't know, Reno does not have light rain; it either sparkles under the sun or storms like there is no tomorrow).
No, reading from your opponent is hard because they have strange assumptions that you just can't understand. Let's be frank here: most people have roughly the same goals (you know, get rich, be happy, make the world more just, etc.) and use roughly the same set of logical reasoning tools. Yes, most people, from far left to far right, do share the goals and the logics. They disagree because they have different starting points, or assumptions. It's like this: two people want dinner outside; they have the same goals (food!) and they drive roughly similar vehicles (cars, let's say, or scooters, or whatever); however, if one person is in New York, and another is in China, you can be pretty sure that they will eat a different places. Same goals, same tools, different assumptions will lead to very different places.
One of the biggest difference between myself (I prefer not to talk about others) and the rough collection of "conservatives" and "libertarians" crowd is this: in my mind, the government and the state are just things; you know, like guns don't kill people, people kill people; in their minds, the government (wait, it's usually like this: THE GOVERNMENT) is Satan, the source of all evils that roam the surface of the earth. I remember Mr. Obama once joked that Republican part seem to have one cure for all woes: more tax cuts. It's funny, and it actually illustrates this difference very well. From my point of view, the government is a thing, dangerous and extensive, but a thing nevertheless; from their point of view, the government is Evil and needs to be purged before anything good can happen.
What is the government? Let's start at the basics. What is, exactly the government. For that matter, what is a state? What does it do? What can it do? Why does it exist? How did it become what it is today?
Let's remind ourselves of this: all humans once lived in small bands. This is undisputed truths. From science to religion, humans started at small bands. So, back in the days, there was no extensive government, no states, no nations, nothing. Back in the days, all humans lived in egalitarian societies where no one ruled anyone else. Eden, a Christian might call it. Equality and freedom reigned supreme.
The question becomes: why would anyone, for the love of freedom and liberty and all of that romantic concepts, abandon Eden and build States? And keep this in mind, the earlier a state, the more brutal it seem to be. This question should especially trouble libertarians. After all, religious Conservatives can answer this simply: God kicked us out, so bye bye Eden. But if you disavow God, you have to find an answer to that dilemma. Why did those bastards build governments that rule us until this day, wreak us countless miseries and pain, spill so much of our blood and rob so much of our money? Why, stupid ancestors, why?
Before we continue: dear ancestor, the words above are purely rhetoric; please pardon my disrespect.
A government, simply put, is the governing body of a society. Usually, people would say things like "it makes laws, builds public works, etc." However, this actually belies an important fact. A government is a mechanism, a institution, an organization. "It" does not do anything. "It" simply obeys whatever its owners want. The government does not make laws. The people make laws through the their representatives in Congress. The government does not print money. The people authorize the money printing through selection of specialists in Federal Reserve system. The government does not make war. The people make wars through their elected officials in two branches of the government. The government is a set of institutions, laws, bureaucracies, regulations, etc. that the owners of a society use to make mutual decisions.
Thus, saying "the government robs your money" is like saying "the safe hoards money." Yes, the safe takes money out of your pocket; yes, the safe prevents you from spending that money. However, the safe does not exactly, you know, spend the money on itself or anything. Last time I checked, the safe still can't go out and buy a luxurious car or go to the bar and woo the girls. And when it can, I am pretty sure the discussion will be very different. Similarly, the government can't exactly use your money to enrich itself. I mean, the poor White House is just a fancy house. It just stands there. Now, the President, the senators, the representatives, etc. can and do use your money to enrich themselves. However, that means they are bad politicians. The government itself, as an institution, can't do that!
Talking about bad politicians: I always feel that Conservatives and Libertarians speak of "the government" and "Washington (D.C., not the state)" a bit strange. Strangest ones? The very politicians who run for office as "outsiders" and put in very bad words about "Washington." I mean, when Ron Paul or whoever (I just pick Ron Paul since I am working very very hard on a book from Libertarianism) claims that, says, "Washington" is this or that, I lost all respect for that person. When you have been in an institution for years, if not decades, when you have been the most esteemed member of that institution, you don't have a right to bash it. If it is corrupted, it is your responsibility. Claiming that you are "maverick" is a sick joke. Who is "Washington"? Why, Ron Paul is. You know, at my workplace, if you have been there for 6 months, people regard you as an old hand. You can no longer say shit like "their way is stupid." It's your way now, so fix it or shut up. Similarly, Ron Paul, Rand Paul, and the whole set of junkies should really be ashame of themselves. I have yet to hear anyone taking responsibility. They all sing the same song: "Washington" is corrupted, elect me to fix it; oh, btw, the fact that I have been there does not count. What?
Same thing, but to a lesser extend, can be said of most Conservatives who complains about "Washington." Let's face it, "Washington" is not an external monster spawned by Satan to rule you. It consist of people who you yourself, along with your fellow citizens, voted in less than 4 years ago (sometimes less than 2 years). I firmly believe that voting is not complaining; it's institution building and decision making. During an election, everyone has the responsibility and right to teach and to communicate with everyone else about the decisions and representation for the next few years. "The government of the people, by the people, for the people" cannot, by itself, corrupt. If it is corrupted, the reason lies in the very citizens who elect the corrupting elements into it.
Enough of ranting. One more important point I want to raise: many of our social goals are, by definition, governmental action. For example, what does "establish Justice" mean? It means fair laws and impartial enforcement. Both making laws and enforcing them lie in the responsibilities of the government. Thus, to establish Justice, We the People have to do it through the government (mostly through election of worthy people to draft laws, discussion and feedback about current laws, as well as vigilant monitoring of the enforcers). Similarly, "provide common defense" generally involves the government, through either militia (feudal modal, or early American model) or professional armies. Both options require central command and coordination, and this command and coordination must obey civil authority. Beside the government, few other options can satisfy this difficult position: very powerful (the army is the most violent aspect of any society) yet cannot be supreme (or dictators will prevail).
Lastly, let's never forget about what the government has allowed us to achieve over the centuries. I mean, I don't want to strip off the credit of any other mechanisms. For example, yes, markets did provide us with abundance in material goods. However, let's not kid ourselves. Even with all of the productivity gains over the centuries, we still have child labor wherever laws either allow or are not properly enforced. Laws and its impartial enforcement end child labor, along with hosts of other issues. In fact, laws allow the market to thrive. Think about it: how natural is "corporations as humans"? Or how natural is "limited liability"? An eye for an eye, blood must be paid with blood. Such were the ancient ethos. It sounds quite fair, but high risk prevents effective investment. Corporations limits both, and the market thrives. Without governmental involvement, how can such unnatural (and frankly, sometimes, unfair) thing exist, let alone thrive? Thus, the government is not pure evil: it can do good; its citizens just need to be vigilant.
Let's end this long ramble with the answer to the question posed above. Why did humans move away from Eden? Jared Diamonds (one of my favorite author) attempted in answer. He observed that efficient societies, much like well-fit species, survived and conquered inefficient ones. This makes quite a bit of sense. In such cases, one can venture this observation: a state is more efficient than egalitarian bands. But how can this be? I mean, if you believe whatever spilling of modern Libertarianism, you would conclude that early humans would simply form markets, become super productive, and never bother to form states and governments. But history proved otherwise. Humans abandoned Eden for states and governments. Why? Because they can be useful. If only their owners know how to use them.
Thus, please, for the love of all that is good, stop blaming the government. It's innocent. Blame the irresponsible politicians, the opportunist law-makers, and the half-asleep voters. In other words, let's take responsibility and blame ourselves for our messes. And let's fix them. Not blaming the evils.
Sunday, April 19, 2015
Saturday, April 18, 2015
Python is a horrible horrible teaching programming language
I have never particularly liked Python. I mean, as a programmer, I consider any coercion into a particular way of doing thing an insult. Thus, the whole there-is-only-one-way-to-do it and benevolent-dictator affairs have never rhyme with my personal philosophy. But I always restrained from criticizing Python. After all, I have never used Python extensively, and my contact with it has never resulted in enough pain for me to hate it.
Well, life changed. I was forced into Python by a class. An algorithm class no less. I love algorithm and theories. Everything there is shiny and flawless, with no wiggle rooms for bugs and the likes. Plus, programming in these situation excites: the problem is well-defined, the graders favor style over pesky optimization, and the solution is polished. This is the exact reverse of profession work, where the result (not the code, but its effect) is everything, and pretty code costs night and weekend (plus lots and lots of fighting).
When I first realized that my class requires Python, excitement actually prevailed briefly. After all, if you ever search for something like "python teaching language," you would see people say all of those glorious things about how python is absolutely beautiful for teaching. I have never liked Python's tyrannical philosophy. However, well, this is a golden chance to learn Python right on its own turf. Maybe I would like it. Maybe my opinion would match that of my friend (apparently Python grew on him after a while). Maybe.
Well, Python crushed my hope with its stupidity (seriously, I have no other names for this), bad design, and generally annoyance to use.
Firstly, let me be very frank: I miss type declaration. I miss it. I mean, production code can sustain lack of type declaration much better than academic code. Why? Because you have tests and documentations and an expectation of proficiency in the language to fill in the blank. Academic code delivers on idea, not execution. So, it should be readable without compiler, without running, without tests, and with minimal documentation. For goodness' sake, the code itself is the documentation of the text (have you read computer science paper? The code explains the English). However, without type declaration, it's impossible to figure out how to use a value without context. Each solution skeleton in my class has 10 lines of comments to to explain the expected type and usage of the input and output. Like 100+ characters which can be easily written in 10 characters in Java or C#. Seriously.
Another thing on type declaration: people keep whining about how much characters they waste. Well, let's ignore my comment on the necessary comments for dynamically typed inputs and outputs, and assume for a moment that you can read the mind of the coder to know how those things should be used. Will dynamic typing save a lot of waste in that case? The answer is no. Remember, we are talking about academic, teaching situation here. The most important virtue here is readability, not efficiency. This generally leads to quite small functions with very few extra variables declaration aside from input of functions, and most of these extra variables are counters (you know, i, j, k, etc.). In most cases, the variables are values passed between functions. You will have to declare them as arguments anyway. Furthermore, because those variables are interfaces between functions, one often wants to document how they should behave, aka write out the types. Thus, the saving here is minimal, if at all. And the readability of dynamic types goes down the drain thanks to the comments.
Talking about variable declaration, since when is declared-when-first-used easy to read? Again, this may be so in production code, where everyone deals with the same set of code days over days. In academic settings, this is bullshit. To determine what the variable should be, one has to look for its first use, usually in the thick of processing. I remember how Pascal was adamant about all variables declared right at the beginning. The requirement stands for a reason: you know, loud and clear, what each variables should behave. No need to read through the code, no need to guess and assume. This helps readability of massive amount of code at once without warming up time. This helps academic code.
Well, let's get over the stupidity of variables and their types. Let's talk about Python inability as a programming language. See, my instructors seem to like something call Numpy a lot. I get it, it's for numerical computation. However, numpy imposes a different set of containers, with vaguely similar syntax but mutually incompatible with Python built-in containers. What does this mean? Either one of two things must be true: Python does not provide a set of interfaces (think List in Java and C#) that is general enough to do things with, or Numpy people are fundamentally stupid and lazy. I pick the first reason. I trust the people. I distrust dictators. This is kinda like Go and APL (never used, only passing insult here; maybe incorrect). Basically, in those languages, all users are bastards who can't do things well. Thus, the only way to actually do anything beside the wills of the language creators is to write fundamentally separated interfaces that resemble the base language. Python is worse: because the variable are dynamically typed, you can't know for sure what the hell is in there. So, if you receive an array, be sure to check where it is from (no type, remember) before doing division and put some numbers in it. Put float in an int array, which is usually OK, may destroy your program.
Oh, this refers me to a third problem: the necessary to run the program to see obvious flaws. I frankly don't understand the whole cheering over runtime error rather than compilation error. It's beyond stupid. In fact, it is an insult to the learners, consider them incapable of reading code. Why? Compilation errors are obvious. Remember, if a computer can pick it up, a reasonably-trained human can. Runtime errors, on the other hands, are subtle and hard to pick out. For example, division of a number over a string can be either a compilation error (since variable must be typed) or run time error. The former case can be picked out easily by human (let's face it, human can read a string variable declaration); the latter cannot (um, what is that variable types again?). When everything is forced to be spelled out, everything is clear. Humans can read them, with or without computers. When everything is, "trust me, it's fine," well, sorry, I don't trust myself to not mistype things.
Btw, I should also point out that this is another difference between production and teaching code. In production, most of the time, you frankly don't know what is supposed to be the solution. At least I don't. So, the usual process involves trying things out, see what happens, then finally code up a final solution based on the evidence (this is especially true for more complicated bugs or novel situations). In class, the reverse is true. The learners start with a class of knowledge to try out, and the code's purpose is to express that knowledge in a more concrete terms. This is true for both theory and more practical classes. Again, each class would have a set of concepts, and the learners should solve the problems by these before coding. Thus, most issues with the code can be picked up by compilation, either by eyes or by machine. Lastly, since teaching code demonstrates a concepts, often it does not need to be run at all. The graders would just compile it in their head, goes through the logics, and give feedback. In such case, runtime errors are terrible. They hide hideous bugs while provide incentives to hack things together. Hacking is not the point of knowledge transfer. Hacking is for production.
Finally, let's talk about indentation. Another big selling points of Python: hear ya hear ya, your code's readability is enforced by your intepreter. Yeah. Let alone the fact that the interpreter fails to detect hosts of issues until runtime, let alone the fact that input values' behaviors are undefined by default, let alone the fact that basic types may be unusable. Python will help your cosmetic to look good! Bow down to pretty code! This sickens me every time. I used to be TA for a Scheme-based class. Every time (and I meant every time), the love of the students to Scheme would jump about 5-fold after I taught them correct indentation, and they would do this without the compiler acting like Hitler. Every programmers with a few months of experience would indent reasonably well for most C-like programming language. Furthermore, given that teaching code is usually short and sweet, this whole concept of coercion of style is generally useless. On the other hand, I have yet to notice any standardization in naming (you know, internalCapitalization vs. underscores_for_spaces). Maybe I am too green, but it seems like people just do what the hell they like here. Again, teaching code is short and sweet, so this kind of styles matter a great deal. But of course, it's impossible to enforce (maybe Python should outlaw underscore in names, or outlaw mid-name capitalization).
Frankly, here is my impression of Python and its cheerleaders: Python is great for very very beginners whose only interest is to show off. It is very fast to punch in something resembling good code. It is very fast if you don't do anything major. It is very fast to get buggy code "running." However, as soon as you put any serious logics in, Python crumbles like worms under someone's shoes. Its code needs serious context (either comments or the usage site) to make sense; its abstraction layer is lacking; its compilation system cares more about cosmetic than sustain. Basically, everything is wrong. On top of that, it lacks any kind of mind-twisting advancements (I am thinking about Lisp and Rust) or pliability for hacking and playing (I am think about Perl, of course, but C is a good example). It's like a dumb dictator: insists on minor styles but lets bigger problems go unchecked. I sincerely hope I won't cross path with it again. Ever.
Well, life changed. I was forced into Python by a class. An algorithm class no less. I love algorithm and theories. Everything there is shiny and flawless, with no wiggle rooms for bugs and the likes. Plus, programming in these situation excites: the problem is well-defined, the graders favor style over pesky optimization, and the solution is polished. This is the exact reverse of profession work, where the result (not the code, but its effect) is everything, and pretty code costs night and weekend (plus lots and lots of fighting).
When I first realized that my class requires Python, excitement actually prevailed briefly. After all, if you ever search for something like "python teaching language," you would see people say all of those glorious things about how python is absolutely beautiful for teaching. I have never liked Python's tyrannical philosophy. However, well, this is a golden chance to learn Python right on its own turf. Maybe I would like it. Maybe my opinion would match that of my friend (apparently Python grew on him after a while). Maybe.
Well, Python crushed my hope with its stupidity (seriously, I have no other names for this), bad design, and generally annoyance to use.
Firstly, let me be very frank: I miss type declaration. I miss it. I mean, production code can sustain lack of type declaration much better than academic code. Why? Because you have tests and documentations and an expectation of proficiency in the language to fill in the blank. Academic code delivers on idea, not execution. So, it should be readable without compiler, without running, without tests, and with minimal documentation. For goodness' sake, the code itself is the documentation of the text (have you read computer science paper? The code explains the English). However, without type declaration, it's impossible to figure out how to use a value without context. Each solution skeleton in my class has 10 lines of comments to to explain the expected type and usage of the input and output. Like 100+ characters which can be easily written in 10 characters in Java or C#. Seriously.
Another thing on type declaration: people keep whining about how much characters they waste. Well, let's ignore my comment on the necessary comments for dynamically typed inputs and outputs, and assume for a moment that you can read the mind of the coder to know how those things should be used. Will dynamic typing save a lot of waste in that case? The answer is no. Remember, we are talking about academic, teaching situation here. The most important virtue here is readability, not efficiency. This generally leads to quite small functions with very few extra variables declaration aside from input of functions, and most of these extra variables are counters (you know, i, j, k, etc.). In most cases, the variables are values passed between functions. You will have to declare them as arguments anyway. Furthermore, because those variables are interfaces between functions, one often wants to document how they should behave, aka write out the types. Thus, the saving here is minimal, if at all. And the readability of dynamic types goes down the drain thanks to the comments.
Talking about variable declaration, since when is declared-when-first-used easy to read? Again, this may be so in production code, where everyone deals with the same set of code days over days. In academic settings, this is bullshit. To determine what the variable should be, one has to look for its first use, usually in the thick of processing. I remember how Pascal was adamant about all variables declared right at the beginning. The requirement stands for a reason: you know, loud and clear, what each variables should behave. No need to read through the code, no need to guess and assume. This helps readability of massive amount of code at once without warming up time. This helps academic code.
Well, let's get over the stupidity of variables and their types. Let's talk about Python inability as a programming language. See, my instructors seem to like something call Numpy a lot. I get it, it's for numerical computation. However, numpy imposes a different set of containers, with vaguely similar syntax but mutually incompatible with Python built-in containers. What does this mean? Either one of two things must be true: Python does not provide a set of interfaces (think List in Java and C#) that is general enough to do things with, or Numpy people are fundamentally stupid and lazy. I pick the first reason. I trust the people. I distrust dictators. This is kinda like Go and APL (never used, only passing insult here; maybe incorrect). Basically, in those languages, all users are bastards who can't do things well. Thus, the only way to actually do anything beside the wills of the language creators is to write fundamentally separated interfaces that resemble the base language. Python is worse: because the variable are dynamically typed, you can't know for sure what the hell is in there. So, if you receive an array, be sure to check where it is from (no type, remember) before doing division and put some numbers in it. Put float in an int array, which is usually OK, may destroy your program.
Oh, this refers me to a third problem: the necessary to run the program to see obvious flaws. I frankly don't understand the whole cheering over runtime error rather than compilation error. It's beyond stupid. In fact, it is an insult to the learners, consider them incapable of reading code. Why? Compilation errors are obvious. Remember, if a computer can pick it up, a reasonably-trained human can. Runtime errors, on the other hands, are subtle and hard to pick out. For example, division of a number over a string can be either a compilation error (since variable must be typed) or run time error. The former case can be picked out easily by human (let's face it, human can read a string variable declaration); the latter cannot (um, what is that variable types again?). When everything is forced to be spelled out, everything is clear. Humans can read them, with or without computers. When everything is, "trust me, it's fine," well, sorry, I don't trust myself to not mistype things.
Btw, I should also point out that this is another difference between production and teaching code. In production, most of the time, you frankly don't know what is supposed to be the solution. At least I don't. So, the usual process involves trying things out, see what happens, then finally code up a final solution based on the evidence (this is especially true for more complicated bugs or novel situations). In class, the reverse is true. The learners start with a class of knowledge to try out, and the code's purpose is to express that knowledge in a more concrete terms. This is true for both theory and more practical classes. Again, each class would have a set of concepts, and the learners should solve the problems by these before coding. Thus, most issues with the code can be picked up by compilation, either by eyes or by machine. Lastly, since teaching code demonstrates a concepts, often it does not need to be run at all. The graders would just compile it in their head, goes through the logics, and give feedback. In such case, runtime errors are terrible. They hide hideous bugs while provide incentives to hack things together. Hacking is not the point of knowledge transfer. Hacking is for production.
Finally, let's talk about indentation. Another big selling points of Python: hear ya hear ya, your code's readability is enforced by your intepreter. Yeah. Let alone the fact that the interpreter fails to detect hosts of issues until runtime, let alone the fact that input values' behaviors are undefined by default, let alone the fact that basic types may be unusable. Python will help your cosmetic to look good! Bow down to pretty code! This sickens me every time. I used to be TA for a Scheme-based class. Every time (and I meant every time), the love of the students to Scheme would jump about 5-fold after I taught them correct indentation, and they would do this without the compiler acting like Hitler. Every programmers with a few months of experience would indent reasonably well for most C-like programming language. Furthermore, given that teaching code is usually short and sweet, this whole concept of coercion of style is generally useless. On the other hand, I have yet to notice any standardization in naming (you know, internalCapitalization vs. underscores_for_spaces). Maybe I am too green, but it seems like people just do what the hell they like here. Again, teaching code is short and sweet, so this kind of styles matter a great deal. But of course, it's impossible to enforce (maybe Python should outlaw underscore in names, or outlaw mid-name capitalization).
Frankly, here is my impression of Python and its cheerleaders: Python is great for very very beginners whose only interest is to show off. It is very fast to punch in something resembling good code. It is very fast if you don't do anything major. It is very fast to get buggy code "running." However, as soon as you put any serious logics in, Python crumbles like worms under someone's shoes. Its code needs serious context (either comments or the usage site) to make sense; its abstraction layer is lacking; its compilation system cares more about cosmetic than sustain. Basically, everything is wrong. On top of that, it lacks any kind of mind-twisting advancements (I am thinking about Lisp and Rust) or pliability for hacking and playing (I am think about Perl, of course, but C is a good example). It's like a dumb dictator: insists on minor styles but lets bigger problems go unchecked. I sincerely hope I won't cross path with it again. Ever.
Subscribe to:
Posts (Atom)