Sunday, April 27, 2014

Long Absence due to Illness

I'm back, and struggling to get back to form.

In case you're wondering, I've been struck with illness. It started in January. Half January and half February was spent being sick. No work done. But March took it all. The whole month was spent being bedridden. No work done. I got better enough in April to write a quick April Fools joke about BASIC being the best language for beginners to learn. The doctor put me on Metformin for I don't know how long, but it's a big bottle!

Well, it's now at the end of April. I was enrolled in Camp Nanowrimo, too. I've only written about 3000 words of it, out of planned 25,000 words. So, not good.

I've noticed that the directory pages are outdated. I've just finished updating the cooking page, because that was convenient. I suppose I should update it based on popularity. So, Petit Computer directory page is next, followed by Raspberry Pi page.

I'll be reviewing more books to come, and it will follow up from the last book review. I'll also start on the Petit Computer programs, and it, too, will pick up from the last blog post.

I have not been active in Raspberry Pi lately, so I will have to start over. I'd probably start with reviewing Linux commands piece by piece. I don't know. I know that I want to finish that webcam project, and start documenting my Slim Pi project.

As far as Nintendo Journal, it's just for fun, so it's not like it's urgent. I will skip post and start over. I do have some more pictures to share.

An interesting idea is that I will start writing on a manual typewriter. I plan to write 4 double spaced pages on it per day. It should take me about 1-2 hours per day, assuming I did my homework beforehand. We'll see how that will work.

Well, that's it for now. Updating the cooking directory page took one hour because somehow, the pages went missing! I didn't know what to do, but it magically went back up again. Oh, well. I really don't know what happened. But if I have to restart the directory pages again, it will have only dates, and not link. You can always look it up by the dates, albeit inconveniently.

GTG. Take care for now!

Saturday, April 12, 2014

Chess: 3 Weak Squares


This is a game I played with Pure Chess at Scholar level. It's an interesting game, with me totally dominating Black's position. It's the finest game I've played so far. Just don't expect me to repeat this performance anytime soon!

1. e4 c5
2. g3 d5
3. Bg2 dxe4
4. Bxe4 Nf6
5. Bg2 

Oh, dear. 5 moves into the game, and I lost initiative already. There goes my hope for a good game.

5. ... h6
6. Nf3 e6
7. O-O Bd6
8. c3 O-O
9. d4 Nbd7
10. Be3 Ng4
11. Nbd2 Nxe3
12 fxe3 

A natural recapture. I moved a pawn from f file to e file, thus opening up my rook for attack on Black's King.

12. ... Re8?

This is strange. About the only thing I can think of is that Black has no concept of long range planning. By moving his rook there, he's setting up attack on f pawn. Right now, White can't attack that pawn, but after a few exchanges, things will be different!

13. Ne4 Bf8
14. Rf2 f5!

The situation is now clear. Black has no plan to save that pawn for defense after all. Black is using that pawn as an attacker!

15. Ned2 a5
16. Qc2 Ra6
17. Raf1 Qb6
18. Nc4 Qb5
19. Nce5 

A knight here is a very strong position. Notice that no pawn can attack that knight. It's a comfy perch that will make Black's movement difficult. It's also the first attacking piece so far. We are now moving into the middle game.

19. ... Nxe5
20. Nxe5 g5?

You should not voluntarily give up the pawns protecting the King. Just because you don't see anything wrong with the current position, does not mean it won't change in the future!

21. g4?

Ill-advised attack on my part. I failed to calculate the consequences of my gambit of trying to open the f file.

21. ... cxd4
22. exd4 Bg7
23. gxf5 exf5

I look at this position and stared in horror! My King has no pawn protection in view of 3 Black's pawns! About the only salvation is the fact that my pieces are consolidated while Black's pieces are scattered all over the board. If only I can attack on the Queenside while preventing Black to consolidate his pieces over to the King!

24. c4 Qb6
25. Bd5+ Kf8?

An unfortunate move for Black, lining up his King opposing my double Rook!

26. c5 Qf6?

Lining up his Queen to my double Rook?

27. Bxb7 Ra7
28. c6!

Looking at this position, I'm very happy! Black has 3 major problems that he needs to take care of. There are 3 pressure points


  1. The f5 square. Attacked twice, defended twice, defender wins. Attacked 3 times, defended twice, attacker wins.
  2. The d7 square. Possible King-Queen fork by the Knight.
  3. The c5 square. Possible King-Rook fork by the Queen.


Notice that I'm not looking at the position by the pieces. I'm evaluating the position by weak squares. This is not a common view, but I think squares are more important than pieces!

28. ... Rxb7
29. cxb7

Black attempts to solve problem #3 by trading his Rook for my Bishop. This is unfortunate for Black since I now have two attacks: the Bishop, and the b8 square promotion. As we play along, notice how Black's position crumbled rather quickly.

29. ... Be6
30. Rxf5 Bxf5

Black has solved problem #2, but his problem #1 remains.

31. Rxf5 Qxf5
32. Qxf5 Kg8

And now, I see a winning combo. I realize that in order for me to promote the pawn, I need to remove the Rook from the 8th rank. I know just how to do it! We are entering the Endgame phase. Black did not survive for long.

33. Qf7+ Kh7
34. Qg6+ Kh8
35. Qxe8+

And I have the Rook. I wasn't calculating mate, but since all moves are forced, it's a mating combination.

35. ... Kh7
36. Qg6+ Kh8
37. b8=Q+ Bf8
38. Nf7#

Yes! Mated the King in the corner! Notice that Black does not make obvious blunder. About the only inaccuracy that I can see is lack of long-term planning by Black. Overall, a great game that I do not expect to improve any time soon.

Thursday, April 3, 2014

Book Review #30


Book #30 Java for Dummies
Aaron E. Walsh

This book is a blotch in the usually good "For Dummies" series. As I keep reading this book, I keep asking, where's the Java? I don't see any. Pages, after pages, I don't see Java. I keep seeing HTML. Then it hits me. This isn't "Java for Dummies". This book is "Applet for Dummies."

That's right. This is "Java" in the loosest sense of the word. The correct title would have been "Applets" or Java application inside Web browser. So, I reread the book again, and it's rather comprehensive in that regard. There's hardly any Java at all, so you need to learn Java development separately. You know what? Usually, such book will have its own applet development section. So, maybe this book is applet design? This book has a little about everything. I can't help to think that maybe a more focused subject regarding applets design would have been better. As it is, there's not enough meat in there to go deep. Good for survey, but not enough to understand everything.

Who will benefit from this book? If you're a Java Developer who never touched applets before, this may be a good book. But I say, odds are you can do better if you keep looking.

Tuesday, April 1, 2014

BASIC is the Best Language to Learn


BASIC is the Best Programming Language for Beginners

"BASIC causes brain damage!" -Dijkstra

Everytime some non-programmer ask me what programming language they should learn, I always answer "BASIC". Understand that not many computer programmers would answer that way, and some would even think that BASIC is actually harmful. However, from my experience, these are the times it took me to learn various languages:

Applesoft BASIC: 3 hours
HTML: 3 hours
JavaScript: 2 days
Perl: 3 days
Processing: 3 days
VRML: 1 week
C: 40 hours
Pascal: 1 semester
Lisp: 4 weeks
Java: still on-going
Python: Still on-going

There are other smattering languages such as Scratch (instant!) and MS Visual Basic (1 week: 3 days being clueless, 2 days learning). However, you can see that BASIC and HTML occupies the short end of the learning curve. I understand that not everybody can learn things that fast, but still, the argument is that BASIC is very easy to pick up. Not as fast to pick up as Scratch and LOGO, mind you, but extremely easy to pick up without the severe limitations of LOGO and still be a general purpose programming language.

If you consider the fact that not only Applesoft BASIC is my first computer programming language, but also that I learned it simply by reading a book without touching the computer whatsoever, then it's a miraculous event, indeed. However, is it really? I don't think so. If you look at the form, it's basically (command) (parameter1),(parameter2),(parameter 3). There may be odd grammatical markers such as parenthesis and colon, but overall the form is very much like algebra, and just as easy to do.

That is, I learned computer programming in 3 hours. That's all there is to it.

Yet, that's actually not a big accomplishment. Coding, or implementing computer program, is actually rather easy. Design, on the other hand, is extremely difficult to get right. I've mastered coding long time ago. Design? I have spent a lifetime learning it, and I'm just scratching the surface.

That's not what most people would say. Most people would say that coding is hard, and design is easy. Just as they say Math is hard, and Art is easy. Who's right? The general population? Or the lonely me?

I'd say that math/coding is easy because if you blunder, the computer will tell you right away and you can fix it. If you design it wrong, there's no one to tell you so, and the mistake will live forever until one day you realize that you do not get the expected performance. Therefore, coding mistakes are easy and cheap to fix. Design mistakes will cause businesses to fail, and no one is the wiser.

Dijkstra wrote a paper saying "blah blah blah BASIC causes brain damage! blah blah blah Once people learn something, they cannot unlearn it." Most media, being sensationalism hungry, focused on the first sentence, and that sentence becomes famous. I, as an educator, focused on the second sentence. Why can't people unlearn what they learned? I have had to do it several times in learning the various computer languages. Why can't they do it? Why can't they bring themselves to another level? Why must they cling to outdated knowledge? BASIC does not cause brain damage. The damage is already there!

Is BASIC such a bad language? Not at all. The new modern BASIC language is especially sophisticated. Even MS Small Basic, with all the bugs, is still superior to sophisticated programming languages such as Java and Python. Understand that most experienced computer programmers will blanch at that statement. They will impound the greatness of such languages: Object Oriented! Local Variables! Strong Data Typing! No pointers!

However, transitioning from BASIC to Pascal, I remember having to think for quite a long time why local variables are desirable. Even to this day, I really don't see the difference between "point.x, point.y" (object oriented) and "point_x, point_y" (functional language). C language has struct keyword to manage memory, and that I can understand. Computer memory in the old days were really expensive and every little bit helps.

Think about it. Local variables can be easily implemented using stack. That is, every time a function is called, you can push variables into a stack, and every time you leave a function, you pop those variables from the stack.


  1. push (px)
  2. push (py)
  3. ...
  4. pop (py)
  5. pop (px)


When you have long list of variables, then it becomes unwieldy. Then you'd put a special system to make it convenient for you.


  1. setmark (stack)
  2. push ("px",px)
  3. push ("py",py)
  4. ...
  5. poptilmark (stack)


And so on. There are many ways that you can implement this. Array of pointers? Linked list? Preprocessing? There's no one right way. Now think about it. If you go from Pascal to BASIC, these becomes a burden. That will discourage people from learning new computer languages. However, if you go from BASIC to Pascal, then the fact that you don't have to do this "by hand" becomes a pleasure. This will encourage people to seek newer and better languages. Isn't the goal of lifelong learning a worthy one? I think so.

How many people I've seen who would put down BASIC because it doesn't have convenient programming features that sophisticated program have? Well, IMHO, if you can make it work, then it's not a language problem. It's a programmer's problem! Otherwise, may as well remove Scratch and LOGO from viable languages as those are even more primitive than BASIC! You don't put down Scratch language because it's easy to learn and use. Therefore, you don't do it to BASIC, either!

Another example regarding person/computer issue. Take a look at this problem:


  1. if s>90 and s>=100 then g="A"
  2. if s>80 and s>=90 then g="B"
  3. if s>70 and s>=80 then g="C"
  4. if s>60 and s>=70 then g="D"
  5. if s>0 and s>=60 then g="F"


Do you see the problem? What if the score has value of 90.5? What's that? Illegal values because the data is stored internally as integer? Well, then, did you remember to round up the values? Because, if not, people will complain!

Notice that it is irrelevant what computer language to use. Some languages provide if-else statement. It can be done as "else if", "elif", or "elseif". It doesn't matter. It's the thought process that is faulty. Look at this:


  1. g="F"
  2. if s>=60 then g="D"
  3. if s>=70 then g="C"
  4. if s>=80 then g="B"
  5. if s>=90 then g="A"


That way, it's a lot cleaner. So many people are busy learning the language, but not the algorithm. Learning computer language is easy. It's the thinking process that is hard!

And let's talk about GOTO. It encourages "spaghetti code", as people would say. Is that so? If the design is clean, there would be no spaghetti code, regardless of GOTO statements. On the other hand, imagine doing some object oriented work. Let's put a banking system. Imagine Customer, Bank Safe, Teller, ATM, Manager interactions. 5 elements. Draw a line (with arrow denoting direction) for each interaction.

Customer-Teller
Customer-ATM
Bank Safe-Teller
Bank Safe-Manager
Teller-Customer
Teller-Bank Safe
Teller-ATM
Teller-Manager
ATM-Teller
ATM-Manager
Manager-Bank Safe
Manager-Teller
Manager-ATM

As you draw on paper, check your work. Does any line crosses? If so, then it's a bit more complicated, isn't it? Then you need to repositioned the elements to make it clearer. Now, this is just 5 elements, with arrows all over. Imagine it with a dozen or so objects. Can you still see it clearly just because it's "Object-Oriented?" Doubt it. There is a reason why flow-chart fell out of favor. It's great for small systems, but expand it greatly and it becomes tough to follow. Ditto for any visual languages.

Now, take another look at the chart you have. What happens if a customer tries to by pass Teller and go Directly to Manager? Well, you need to take care of that situation, too. Add another line. You may decide to allow it, or you may decide to throw out an error message. What happens to ATM-Customer interaction? Another error message? Keep going until you have five element graph with lines all over the place. Impossible to avoid crossing the lines, doesn't it? That, my friend, is spaghetti code. Object-Orientedness is by no means the deciding factor of confusion. Simple, clean design matters more.

I also don't understand why Java/Python people take is as a point of pride that they do not use pointers. Sure, it can be difficult to get right, but what are you going to do? Learn how to use pointers properly or discard the whole language? What kind of computer programmer, are you?

Even highly skilled, highly experienced programmer, such as Mark Lulz who wrote 2 excellent Python books, Learning Python and Programming Python, had trouble with Cartesian/Polar Coordinate translation. Excuse me? That conversion is something I learned noddling around in BASIC for about half an hour. It's not the language/tool/car/money. It's the person! Which is better? That you do not use pointers and have trouble converting Polar Coordinates, or that you do use pointers and have no trouble converting Polar Coordinates?

Yes, I had trouble using pointers. So much so that every time I used them, I'd draw on paper little arrows pointing here and there. It's not until I realise that pointers are references, that the whole trouble disappear. What are references used for? Variables, functions, strings, data structures. Any time you want to refer to something without actually having a copy is a reference. Which means that Unix command "ln" is a pointer operation. Java's Garbage Collection is also pointer heavy. Python Objects are also pointers heavy. The only difference is that those languages hide the operations away from the user.

And yet, referencing objects (aka pointer) is so useful, that even Excel spreadsheet has that capability. Not that it's in any tutorial, including advanced ones. I wonder why? The skill to reference objects via indirect method is an important one in computer programming skill toolbox. Why won't people learn it? Why hobble themselves voluntarily?

Old style BASIC, which is flat, is rather cumbersome to use. Sure, that's true. But a bad workman blames the tool. So what if the language is hard to use? You can write a programmer's journal to clarify the problem/solution. How many computer programmers today write such journal? If you're talking about Python, then the answer is none. The source code is the document!

But that's not a good thing. You don't want to teach the programmers via the source code. Imagine that program maintainers cannot understand quicksort. Would they replace the highly optimised quicksort code (such as GNU C qsort) with bubble sort? Very likely. Do you really want to teach these people what a quicksort is, right on the source code itself? Of course not! That would be a distraction! So, the way to bring beginner programmers up to date is via external instruction. With quicksort, that's easy enough. Schooling and/or Internet will take care of that.

Now replace the word "quicksort" with "bleeding edge technology (that nobody but you understand) that your company depends on its very own survival so that if it fails, you (along with everybody else) will be out of the job" and see if you're still willing to gamble that replacement coders will be able to understand the issue completely just by reading the source code.

And that's the value of computer programmer's journal. Just as novel writers have source book detailing all the characters, locations, and other tidbits, so should computer programmers. This isn't being done. Why not? It's a necessary component in computer programming.

All the greatest people I know have the ability to admit that they are wrong. Therefore, the more stubborn they are in insisting that they are right, the less I think of them. With computers, there is no ambiguity: If you're wrong, you're wrong. If the computer is wrong (buggy), you have to work around it. Either way, you learn, adapt, and move on.

So many people complain that their language isn't "powerful" enough. I know many programmers who complained that BASIC doesn't do recursion. I was once among them. Not anymore. Not since learning Assembly Language. The difference is before, I didn't know what to do. Now, I do. There are many computer programmers who'd argue that they don't need to know such details because the language takes care of that. Considering that many highly skilled and experienced computer programmer spend their time removing recursion out of quicksort just to get a fractional increase in speed, I'm afraid I can't agree with that sentiment. Yes, you do need to know how to do it!

If you don't care about speed, as none of Java/Python people do, then by all means ignore that. Ignore everything else, too. Programmer's Journal? Program Design? Automated Testing? Whatever for? "It works on my machine" is good enough excuse!

In my opinion, you need to learn how to design your program from the ground up. Once you do, then you need to learn how to implement it efficiently. Then, you need to learn how to test it properly. And finally, you need to learn how to document the process well enough, so that other people can benefit from your work.

So, back to the point. Why BASIC? Why not C/C++/C#, Java/JavaScript, Perl/Python/Ruby, etc? Why not use the tool highly skilled, highly experienced professionals use? Well, because they are highly skilled, highly experienced professionals. They have the skills to learn complicated subjects quickly and effortlessly. Can beginners do that? Some of them can't even count properly and you want them to use highly complicated tools? What were you thinking?

Let me put it this way: Do you want beginners to learn a language that is not only so easy, it can be learned in an afternoon, but also custom made for the job so far as to have the word "Beginner" in the acronym? Or do you want to shove the language that Mark Lulz spent 3000 pages full of dry technical info on the subject?

That 3000 pages is equivalent to 6 months learning. Do you want to spend that much time learning the language? Or do you want to spend the time learning computer programming designs and algorithms? I rest my case.



  • Note that there are good alternatives to BASIC programming language. I mentioned Scratch and LOGO. Processing is a good language as well, one that I recommend over Java.