Not your everyday blog

I recently attended a class on the problems facing internationalization within software engineering. It brought up a lot of good points that I had never even considered as internationalization problems. Having two internships and having to deal with internationalization problems I had kind of thought that I already knew my way around it and how to effectively deal with the problems. Most of the things I didn’t consider were little logic errors, not larger scale problems. Most notable being that in other languages, what is considered alphabetical, changes. One cannot always assume that if one is looking at a list, that the A’s will necessarily be in a row since the normalization of Á would turn into A but may not be locally recognized as the same.

Many of the problems discussed in the class focused around things that I would consider ‘learnable behavior’. Things such as making sure you are using Unicode encoding, being aware that an icon that has obvious meaning in America may have no meaning at all in another country. GUI design was another hot topic in the class. You have to consider that some language will read right to left rather than left to right. Many languages have words much longer than their English counterpart and could either be cut off in a label or possibly cause a line wrap. All of these things are true and should be the focus of any software engineer that wants to do well with internationalization. However, I believe that this isn’t truly the root cause of the problem. An engineer should be able to pick up simple concepts such as externalizing strings, swapping out icons when necessary, and using a new style of GUI design. I believe that the true problem lies in the environment in which the engineer is developed and kept.

The first true stumbling block of internationalization is the educational system. While in school engineers are only really forced to create programs for themselves that have a very narrow scope of operation. They are never expected to create a program that is to be consumed by any other end user other than themselves, their instructor, and perhaps a grader. The educational system should really take on some responsibility in how they teach students to create deliverables. This wouldn’t necessarily require any sort of major overhaul in the systems. I know that many schools require a sort of capstone class that has a student create a product that, in theory, could be operated by an end user. Since we now live in a world market it would not be outside the scope of a class such as this to incorporate ideas involved in internationalizing software. Some of this burden would be taken off of the educational system though if perhaps development books were written in a new way.

Development books are a cornerstone for the growth and education of any software engineer. The problem in these books however is that more often than not they focus on almost entirely over simplified examples. In introductions to languages this is to be expected and I don’t think that “Hello World” needs to be internationalized in an effort to expose new engineers to internationalization. Exposure should, however, be given soon after the basic concepts of programming are taught. I can’t entirely blame the book manufactures for producing code in this manner though because most current languages are only written in an English readable format.

An English readable format is perhaps one of the largest stumbling blocks that an engineer has to face when creating software that is to be internationalized. If a native English speaker is creating a program, more often than not, that language will read almost like English and will have a sort of familiar flow to it. It really distracts the engineer from the fact that it needs to be internationalized because in the mind of the developer it seems to flow so well. Languages are written in stone and there isn’t really any logical way, or reason, to go back and write C++ and Java so that it is absolutely unreadable to anyone. This does though allow a good metric on which to judge a software engineer and his dedication towards internationalization. If an engineer is able to distance himself enough from his own native language then he is a software engineer who is not only able to create programs that will conform to internationalization but also an engineer that should be seen as willing to push himself and constantly grow. Not all of these problems lie on the educational system and the engineer themselves. A good majority of this responsibility falls on the industry as well.

While an engineer may be put on a one way track through his education, and perhaps books if they study on their own time, industry is often guilty of endorsing such behavior. Once an engineer has finished school and heads into industry, there is usually a short time dedicated to educating that engineer. Most of this education focuses on business-centric education. More and more businesses are moving towards including internationalization education in their training and that is a major first step. Sadly it is only a baby step because once the engineer is in his position, education ceases and practice begins. In many engineering environments, engineers are expected to produce, produce, produce. While I am sure many engineers expected this, and industry loves it, I am pretty confident that it is not what is best for industry. While the industry is expecting engineers to produce they are unintentionally culturally isolating the engineer and, despite what they may think, actually lessening the expectations on engineers. While the expectation of work may have increased, the expectation of continuing education decreases. Many businesses offer incentives to continue education which sounds very appealing. However, when your work expectations are so high, it leaves little time to dedicate to continuing one’s education. If a company wants to see their engineers succeed in an international environment they need to dedicate their time to putting engineers on the front line and truly showing them the problems that are faced on an international stage. Many examples given involve how a GUI interface may mess up, but this is only the beginning of the problems seen in the international space. If an engineer is able to see how his work affects another individual from poor internationalization, it would allow them to have a more real understanding of how what they do directly impacts the global stage.

While many of these problems seem large and insurmountable, they aren’t. All it takes is a shift in the way people think and develop software. Luckily this isn’t a large shift in thinking and only minimal effort on the side of input to see a large change in the output produced by engineers. Until these small problems are addressed though, I feel that the problems seen in internationalization will continue to be an ongoing uphill battle.

I have learned in the past couple weeks that I will become a Java developer. I have always had a disliking towards Java for various reasons. Since attempting to learn it though in a corporate environment I have found that it does have an awful lot to offer the business world. With that said there are a few features it lacks that I feel should really be a mainstay of any major programming language.

The biggest advantage I have found with Java is probably how easily it is ported across systems. In previous internships I worked with Visual C++ and the idea of it working on a possible Mac client were pretty much out of the question. Moving to Java though allows developers to focus less on cross compatibility and more on the true function and desired outcome of the program. While it is more flexible in cross compatibility it is also more flexible when looking at things such as internationalization. C/C++ were made ages ago and there wasn’t really much of a character encoding standard at the time. ASCII was really just about it and that really didn’t give companies any advantage when it came to foreign markets. Libraries and workarounds exist for this in C/C++ I know but since Java was made much more recently these standards are inbred into the language a little more making it a lot more accessible and easier to use. I also like the ease the transition from C/C++ to Java has been.

I have heard for some time now that people who have a background in C/C++ don’t have much of a problem transitioning to Java. I always though that this may have been people just trying to lure me over to the ‘dark side’. For the most part it has really been true, the syntax is almost identical, it is some of the logic that is throwing me off more than anything else. Even though it is causing me some trouble I must say that I am not coming at it from the other direction like a couple of my coworkers are. People who originally knew Java and are trying to move into the C++ realm are seeming to have a much harder time transitioning. A lot of it is stuff that I would consider trivial for the most part. When I stop and look at the differences in the two languages though it isn’t too shocking that someone who only knows Java is completely lost in a language like C++. The idea or using pointers or passing arguments as references is completely lost on some of these people. There have been several situations where someone has passed a class into a function, tries to change something, and it comes out completely untouched. I ask if they are passing by reference and they don’t even know what I am talking about. Something else surprising is some of the inheritance structures that these people are creating in C++. I guess I have taken for granted that C++ has multiple inheritance, something that Java ironically doesn’t have, I’ll get to that later. Some people have created classes that inherit through this giant tree of extends. This wouldn’t necessarily be bad but when you try to force something like this some of the relationships can become sketch at best.

Not having multiple inheritance may not seem like such a big deal but when you break down the foundations on which Java was built it truly seems to make pretty much no sense to me. It truly is ironic that a language built so heavily on the idea of OOP has no way to inherit multiple objects. While this may not be the death of the language it truly is something that I would expect from such a widely accepted and powerful language. Something else I find that Java is missing is a wide variety of primitive types. While Java has the basics: int, float, double, byte, char, boolean, and long, it doesn’t really have a way to expand on any of this. Java has eliminated SOME of this by creating the BigInteger() and BigDouble(). I don’t really find this to be a solution to my problem though because I am still awfully restricted. Initially looking at this list it may not seem too restricting, wait, there is more. Combining types or modifying types does not exist, that is to say I can’t made a long long, a long double, or anything of the sort. The one that really got me today was that there is no way to make a number unsigned inside of Java. This seems like a major oversight for any language that wants to gain any sort of major use and respectability. Sure I will probably not have a use for a number that goes all the way to 18,446,744,073,709,551,615 anytime soon but it still does take a huge chunk out of possible markets.

Despite the gripes about Java it truly is a pretty strong language. While its range of uses may not be as far reaching as some of the older lower level languages it really does pick up the slack in the ability to get something together and ship it out quickly among varying platforms. While efficiency may be lost there is a definite profit gain accomplished by using a language like Java over some of the other big names out there.