JavaScript Constant

As a good programmer, you make everything constant. By doing so, you limit the places that you can make mistakes, and thus reduce number of bugs... at least works most of the time.

I wrote an web page for an assignment. Naturally, I used the const keyword all over the place. I did not even think about the possibility that JavaScript has no constant as VIM highlights the keyword, and the page worked perfectly on Firefox and Opera on my machine.

Therefore, I was very surprised when I found the page bugged out on the tutor's computer with Google Chrome.

The story starts with scoping rule of JavaScript. Variables in JavaScript has either global scope or function scope. Nested functions can access variables of the nesting function. This is called scope chain. Unlike most languages, JavaScript does not have a block scope; the following is valid JavaScript code

function a() {
    if (true) {
        var b = 2;
    }
    alert(b);
}

What about constants? What will happen in this piece of code?

function c() {
    for (var i = 0; i < 4; i++) {
        const j = i;
        alert(j);
    }
}

ECMAScript 5, the base language of the current version of JavaScript, has no constants. Constant is a proposed feature of the next version of ECMAScript, Harmony. There is also block-scoped variable in Harmony, declared using the keyword let.

Firefox 20 treats constant as a block scope variable; Opera 12 does not distinguish between constants and variables (you can reassign a "constant"). My code works in both cases. In Chrome / Chromium 26, however, constants have function scope. You can declare a constant in a loop, the constant will not update its value at all. The above code will alert 0 four times. What makes this worse is Chrome / Chromium will not complain the failure of assignment.

ECMAScript 6, can you standardize a bit faster?

Trouble-shooting: Seg-fault (erroneous memory access) on glDrawElements()

Yesterday, when I was writing basic rendering code for the new ViRe, I keep getting errors of erroneous memory access (in the form of an Ada exception).

With the small code size I currently have, finding the offending line of source code is a matter of minutes. However, knowing that the exception is raised during the call to glDrawElements(), I still don't know the cause of it. My first suspect is the Ada OpenGL binding that I have been writing alongside the renderer.

Today, I wrote a small programme (~100 lines of Ada source text), set up everything that is needed and called glDrawElements(). To my surprise, it worked perfectly. The binding is working fine; it is the code that loads and prepares data that is in fault.

After some time, I found out that if you call glDrawElements on a VAO that is not ready to be rendered, be it a non-existent array object (including the id 0) or an uninitialised one, a segmentation fault will happen. By uninitialised, I mean the vertex buffer or index buffer is not generated, bind, or you forgot to load data into the index buffer, or you failed to enable the corresponding vertex attribute array, or any combination of them.

As long as index data is present, its values does not matter. It may cause an empty screen but not a memory access violation. Absence of vertex data does not affect rendering process.

Note that glDrawArrays() does not generate this error regardless of the circumstances. That makes sense, since it does not rely on index buffer object or index data.

Development environment:

• OS: Linux Mint 13 with kernel 3.2.0-30-generic
• Display Card : NVIDIA GT640M LE
• Display Card driver: Bumblebee with NVIDIA binary driver 3.0.4.51

Something is Coming (Back)...

Anything that can go wrong...

Anything that can go wrong will go wrong, as stated by Murphy's Law.

My father's company has been developing a piece of application software. I do not know how much I can disclose, so I will just say that it is supposed to increase productivity, especially in the insurance industry. Anyway, this is just the background and it should not really matter.

Learnt that a contractor will charge a few hundred thousand dollars (Hong Kong Dollars) for the product, the company decided to develop it in-house. Not previously having a developing department, the company built one from ground up, which had just a handful of programmers. The project manager is an acquaintance of my father. He operated a software firm, which was defunct due to mismanagement.

The company based the department in Shenzhen, Mainland China to cut budget. Consequently, most of the programmers are Mainlanders.

In a few short meetings, my father explained to the project manager the functions and requirements of the application. Every week, the whole team would gather, reflect what they have done in the past week, update the schedule, and plan on what to do in the next. However, most of the meetings were useless: nothing was discussed because nothing is achieved in the previous week. Even if something is discussed, it is mostly complaints from the management level that the application does not conform to the requirements, and complaints from the development team that the company constantly changes requirements.

Two years later, in an expo, when the company was trying to promote the unfinished product and invite investors, they learnt that the application must be on-line. A set of data may even possibly be accessed simultaneously by different users, at different places. While keeping developing the current, single user version, the company started to develop a web-based version.

Soon after that, the single user version is completed, and is shipped to several insurance managers. Not until then did the company find out that the software is incompatible with Windows in Traditional Chinese (and every other language except English and Simplified Chinese). Apart from that, the programme is very buggy: marketed features do not function properly, and crashing is a usual visitor. As a result, the company cancelled it and focused on the on-line version, which was still in its infant stage.

Year after year, the development team worked on a moving target, and they saw no prosperity of either the project or themselves. As the new version slowly grew, developers started to leave. When the software is almost finished, the company lost all developers.

When the company wanted to hire new developers to continue the project, they faced a serious problem: they can hire no one. The web-based version of the software used ASP as their back-end; the company simply cannot find programmers that know ASP. Deemed that ASP is outdated anyway, the company decided to hire new programmers to re-implement everything in a newer language / platform: C# / .Net. Another two years have passed without anything new came out.

To date, few hundred thousand dollars are spent; the application is still remote from alpha stage.

Still holding hope in the product, the company wants to complete it collaboratively with a software firm. Luckily, the company still holds the old source code and the rights of it. Hoping to smooth transition, I went to Shenzhen earlier this month to see what is salvageable. The answer is, unsurprisingly, not much. Maybe most of the code base can be reused, since only the framework is done in the .NET version; however, without any documentation, it is very hard to understand what the code does. We do not even know which part works and which part does not: A month or two might be needed just to figure that out.

What went wrong?

Almost everything went wrong with this project, right from the beginning.

The first thing is totally underestimating the cost of the project. If you consult a professional software firm the cost of developing a piece of software, you should genuinely believe their answer. If you do not trust them, you can always consult another firm.

Once you convince yourself that price offered is reasonable, however, do not think you can lower it, by whatever means. If it takes a professional firm that much to build the system, it will certainly cost you more if you do it yourself. Remember, you find those firms for their professionalism; otherwise you would not find them in the first place. Sadly, many people do not think software development is a serious business and hence a professional field.

Of course, a software firm charge for is not the cost, but a price that will make them, as a company, profit. However, even considering this, you will still spend more money if you do it in-house, because you lack experience, knowledge, personnel, and professionalism.

Compared to paying a software firm, the cost of developing in-house will likely be a double, at least. Again, do not ever think you can lower the cost by any means, inducing but not limited to hiring developers at lower salaries, cutting some “unnecessary” job positions, and neglecting “superfluous” software engineering practices. Actually, all these practices are what make cost surge and are what you need to avoid (although not all that you need to avoid). Incidentally, the company did all three.

You do not want to pay low salaries to developers because they come in different grades: there are good programmers and bad programmers. Technicians and programmers in Mainland China are cheap for a reason. If you pay a high salary, no guarantee can you get to hire a good programmer. However, if you pay a low salary you are guaranteed to have a bad one. A bad programmer does not only lack the productivity of a good one; a bad programmer deprives productivity from others in the same team. Bad programmers might do something you would think to be unthinkable, such as refusing fixing bugs in their code, or introducing (not finding, but introducing) bugs in others' code. If anyone has dependencies on these codes, progress will be hindered.

Now imagine a team comprises just of bad programmers. This team will not only drag productivity of it to a lowest point, but also diminish efforts of future teams that work on this project or other related projects.

By neglecting “unnecessary” personnel and procedures, the company removed everything connected to quality assurance, and consequently everything related to quality. See how the company has her programmers create a programme that is buggy, and ignorant of foreign languages and character encoding, yet no one notice the problem until the product is shipped. When there is no full-time, dedicated quality assurance team, problems will slip through the development process and find their way to the customers.

You cannot rely on programmers to find bugs in their own code. Maybe they will find some, but that will not be comprehensive. When programmers write code, they think they have already considered every possible situation, which has been proved wrong so many times. Furthermore, they are preoccupied by many minor things already, such as requirements of client, constrain of hardware, software, and programming language. If you assign another job that requires attention and dedication to them, they will fail both.

Things do not end here. The development team did not ever use version control system or bug tracking system. Without these, there is no way to figure out when and where did the team introduce feature and bug into the code base. This makes development and maintenance very slow, if not impossible, on any programme beyond a few thousand lines of code.

One time, I was in horror when I saw the programme does not compile and a programmer uncomments a large chunk of code. Compilation was still not successful. The programmer made a dozen of changes and the programme still failed to compile. By that time, the source code was unrecognisable to what it was ten minutes ago. It was not until half an hour later did the programmer finally satisfy the compiler. The code compiled, but no one knew if it functions properly.

No one knew if the programme functions properly, because no one agreed how the programme should behave. The team lack documentation: specification, schedule, code comment, everything. Without a spec, the team will always work against a moving target and disagree on functionality. Without a detail schedule, works are guaranteed to crash through deadlines. Without code comment, it is impossible to maintain code, both for who write the code and who does not.

It is a miracle that the application got its current size.

First (Programming) Language

Using C++ as a teaching language is a very dumb idea.

Programming is about all the programming concepts. Languages implement those concepts. Which language you use doesn't matter, as you are using the same way of thinking^[1], expressing the same concepts.

While this is true for programming, learning programming is whole another thing. When you don't have the concepts, simultaneously learning the specific language syntax will distract you. That's why things like loop and conditional are usually taught without mentioning syntax at first. Learning semantics and syntax at the same time is hard. With C++'s complex and cryptic syntax, the distraction is so big to the point where some students never understand the programming concepts.

Take the for loop for example. In C++, the syntax of a for loop is:
for (initialization; condition; action-to-counter;)
An example is :
for (int = 0; i < 10; i++)
You can omit any one of those. In fact, you can omit all of them. Therefore, the following is a valid statement in C++:
for (;;)
This is a way to achieve an infinite loop in C++. The problem is, this obscure the line between for loop and while loop. Yes, this is a valid command, but it does not convey the concept well. Compare to the usual pseudo-code:
for i in 1 to 10
one can really see the syntax from Python:
for i in range (10)
and the one from Ada:
for i in 1 .. 10
is clearly superior, and the C++ one is really cryptic. C++ is too close to the metal; the high-level programming concepts is behind too many abstractions, or rather, details of the underlying hardware. Some may argue that it is this thing that distinguish brilliant programmers from the mediocre, but I say that this undermines so much brilliance.

Actually, this syntax of for loop comes from C, and I condemn every language that copies it. This includes but is not limit to C++, C#, Java, JavaScript, and PHP. For a programmer, learning a new syntax of a different language is a matter of minutes, if not seconds. But, for a newcomer, learning the concept of for loop from this syntax can be a painful process.

Using C++ to teach programming is a very dumb idea, especially when teaching someone who has never learnt programming before.

Pedantic footnote:

[1] With some variation. due to the characteristics and limitations of different languages, you may or may not convey some ideas or concepts in a language.

Why Now?

"Why do I need to reed the book about programming now? How much will be taught in a lecture session? Less than a chapter? Then I have time. There is no need to hurry."

After hearing this, I felt very in danger as a group-mate.

Programming is not something you can simply read and do. Programming is abstract; there are things that you need to remember, think, and practice. This is more true considering we are learning C++.

When I first learnt pointers (and reference, simultaneously, which is a pretty bad learning plan), I had a really hard time understanding what was going on in the code. It just didn't make sense to me. For the next two years I didn't even touch programming, let alone C++ and pointers. But when I re-learnt pointers later, suddenly I could understand the code.

Even if you're not thinking about it, your brain continuously reorganises things you have learnt. You just have to give your brain some time to digest.

If you think you are going to learn programming sometime in your life, you had better read something about it now.