I'm sure the security issues with Java have been mostly fixed. But so far I have run into only one website that requires it, and even so, they offer a javascript alternative. (javascript has nothing to do with java)

Besides syntax, one reason I don't like C is that it's not "failsafe", hence why commercial software tends to be buggy and hackable. The ubiquitous "buffer overrun" is a typical example. C does not do bounds checking. If you try to stuff 1000 bytes into an array that's only supposed to have 10, C will not complain, and the extra data overruns the buffer, thus writing over memory. This is how hackers exploit programs. The extra data may actually be executable code that when it writes over memory, actually writes over part of the program itself.

So, a C programmer needs to use compiler tools to help him make failsafe programs or manually add bounds checking to his software. They often forget or can't due to time pressures. Other languages, for example XB, do not have that problem.

Some examples of challenges that I've solved in XB....

When I was running my Earthquake Dartboard, the maps were made by software. I had an image of the base map but wanted to draw transparent dots for the prediction circles. No way to do that natively in XB. I could have written code but I didn't know how to do it. Instead, I found an image editing library and imported it. The library was written in C, but XB can access most C libraries. The library acts as the core to an image editing program. I just used a few of it's functions.

Another program I wrote over a decade ago was for comparing and validating the contents of entire directory trees to see if they were identical. In recent years, with the advent of terabyte hard drives and gigabyte file sizes, I ran into an issue with the length of file command LOF(). It could handle such large files. This was a bug in XB itself. Since the XB source code is written in XB, I studied the source code for that command and found the problem. I copied the code into my own program as a renamed function and modified that code to handle the larger file sizes. It required me to learn about the Windows API since the command actually uses calls to Windows, but in the end I had a function that worked, and I knew new and powerful things. The solution was to use a different data type that could hold such large numbers, XB's "GIANT" 64 bit integer.

And then there's OpenGL. For the 3D quake display program I've dabbled with over the years I wanted smooth clean detailed graphics. Since the video card is designed to do these things, why not let it do all the hard work for me instead of me wasting CPU and programming it by hand? This was indeed a challenge but I've learned how to do at least simple things. The graphics are far better than I could have done on my own, and they are fast and smooth and beautiful looking. It's sort of a mixture of the USGS's new maps and GoogleEarth. I *really* need to finish that program one of these days.

As for FORTRAN, I wish I knew it enough to read some sample code I have so I could translate it to XB.

Again, there are legitimate concerns with XB, namely it's 'age' and documentation. But so far I've managed to overcome these things. XB, being open source, means ANYONE can update it and derive their own version. That's how XBLite got started.

Brian