On Sun, 2003-10-26 at 14:26, Wayne Venables wrote:
> >Further: I always read statements like "Microsoft C/C++ is the largest
> >most popular language platform in the world" as foolish sentiment. These
> >people obviously don't know what they're talking about and need a good
> >healthy dose of some reality.
>
> A subtle barb fired in my direction. I think statements like that are even
> more foolish and even more out of touch with reality! Oh sure, TRON is the
> most used OS in the world. Does sqlite even compile on TRON? How many
> developers program for it? Windows is installed on 96% of all desktop
> computers and somewhere around 30% of servers. That's a very large number
> of machines, but you dismiss that pretty easily. And Visual Basic is
> probably still the most popular programming language in the world! (and
> yes, that should make you shudder!)
If you're targeting a large platform- however large- even monopolistic
large, you are NOT WRITING PORTABLE CODE. I can dismiss however large
Windows is simply by stating that it is not portable. SQLite is rather
portable: It builds on many different platforms. It even _works_ on many
different platforms.
I have no idea how you got the idea that "portable code" meant runs on
Windows, but you should drop it.
On your other points:
1. SQLite does compile on TRON with very little help. TRON is nearly
POSIX complete (although not certified, AFAIK).
2. The largest number of developers are presently mobilized for unixish
platforms (POSIX). Windows claims to have a POSIX abstraction layer that
doesn't comply with POSIX.1, but because fewer people know this each
year, my statistics may be skewed by this.
3. The popularity of Visual Basic is greatly exaggerated. Using google:
"Visual Basic" programmer resume: 61,200
"C" programmer resume: 165,000
"C++" programmer resume: 92,500
"Java" programmer resume: 112,000
"Javascript" programmer resume: 48,900
"SQL" programmer resume: 84,000
I have no idea how you got the ideas that you have on this subject, but
it really surprises me whenever someone wants to talk about the
popularity of a language. You can find metrics to support whatever you
like, and I have no idea which ones you are using.
I'd probably believe that more dollars are spent on Visual Basic
Training every year, but I also wouldn't consider that a fair indicator
of how many people are actually using it, or how many commercial
programs (or better quality) are being turned out in a year. I wouldn't
suggest that has anything to do with how long it's been around or how
many people that actually HAVE USED IT and know some other programming
language and yet still use Visual Basic.
> But, for the record, I spend 99% of my time developing for unix in a
> programming language that really knows only ASCII (with some
> exceptions). Here's a hint: this language will, in it's next major
> version, be a very large source of new sqlite users. The other 1% of the
> time is spent developing in a USC-16 platform that isn't Windows. Even if
> I'm not in the Microsoft camp, I can acknowledge that it has some significance.
I have no idea what you're talking about. Do you?
> >Too many rude users talk about how inconvenient their life now is
> >because here is this wonderful and rather free toolkit that decided to
> >make the life of the author easier- and most of it's users or potential
> >users easier, at the expense of their own.
>
> BTW, all I had asked is if anyone had done the work of making sqlite
> unicode-aware (I did ask for UCS16, however). I hadn't seen anything to
> indicate it did anything but straight ASCII. Someone pointed out that it
> did handle UTF-8 w/ the appropriate #define and that is certainly good
> enough for my task. If I hadn't of asked, I wouldn't have known.
No you said:
"Unfortunately that still means there is a performance hit converting
all data in and out of the library from UTF-8 to UCS16. A large number
of operating systems and programming languages store strings natively as
UCS16."
And I happily gave you suggestions that would be useful in minimizing
your "performance hit" as long as you weren't writing portable code.
Knowing how to avoid a "performance hit" - especially one that a user
hasn't bothered to profile yet is a good thing to know- a good thing to
have in the archives, so that when someone DOES end up profiling and
sees "oh boy, I'm spending a lot of time converting this into UTF-8 and
back again!" they'll know what they can do.
In some rather weak backpedaling, you tried to "justify" your large
number of operating systems and languages by listing three- only one of
which was actually correct:
"Win32 is unicode (UCS16). Writing C/C++ w/ Win32 generally involves
using wide char strings. Visual Basic natively stores strings as
unicode. Java natively stores strings as unicode. I'd say that covers
a lot more than 1%. And if you're coding for a non-unicode operating
system, I sure hope you're using unicode anyway or otherwise you're
alienating a large portion of users. I purely ASCII database in this
day and age is terribly backwards."
Java does _not_ natively store strings as UCS16, and neither does Visual
Basic. The Java specification clearly states that Java's characters are
multi-byte BUT NOT NECESSARILY fixed-width.
Even if they DID store it that way, it only matters if they have built
in string-manipulation capabilities- collating features, comparison
features, etc. C doesn't have them. C++ doesn't have them. Java doesn't
have them (but JDK does!), and Visual Basic's aren't locale aware.
Now what am I trying to do? I'm trying to keep other people from getting
confused. If you think I'm attacking you personally, then pay closer
attention to what I am saying. I am attacking your arguments and
pointing out that if you are making a false statement and claiming it to
be a true one (e.g. not feigning ignorance) then I will point out the
correct answer- or someone else will. That's why we have archives like
this to prevent people from becoming confused and to get useful
information.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
