And if you're less concerned about portability, ISO C# will make it possible to do some really powerful, native things on other platforms, such as Linux or Mac OS X (Cocoa).
It is superb technology: a combination of many of the best features of Java, Delphi, C++, and Perl. It doesn't "reek" of anything. (Well, maybe of Java, if you think Java reeks.) Mono will make it possible to use the excellent ISO C# language, the excellent ASP.Net, and the excellent.Net class libraries, without ever leaving the excellent Linux platform or having to use any product from MS.
On the other hand, if you are less of an ideologue and more practical about technology, Mono makes it "safe" to use MS technologies when they are the best choice, because you don't have to make everything MS. You can order a la carte.
I think they're both going to lose in a sense, but MS will fare better.
Sun's control over Java will make Java less able to compete with ISO C#, which MS *won't* be able to control.
MS may be able to prevent others from doing a complete clone of the entire.Net framework, but they can't stop people from doing their own ISO C# implementation. Such an implementation will be both free of royalties and free of license restrictions (such as Java's) that restrict the vendor from being able to customize the libraries for their own needs.
Once it becomes clear how little control MS has over it, this should be irresistible to both commercial vendors and to OSS developers. MS ought to still do well, though, by having the most complete libraries, the best dev tools, the reputation as "the real thing", etc., so they'll do well.
By releasing C# and at least some portion of.Net into the wild, MS has almost guaranteed that it will evolve into a formidable competitor to the domesticated Java.
Interesting. I don't have any experience with Python, but having used many, many other platforms over the years, I know how much one's opinion about a tool can change after a year or so of intense effort. I'm always interested to hear from those who have gone through it, especially when the whole team eventually reached the same conclusion (as usually happens, in my experience).
I'm not one of those who feels that software companies are evil for selling software and insisting that customers actually pay. I think they have the right to do so if they create the software.
Even so, from a user's perspective, there are risks to running software with "we'll sue you unless you follow our rules" licenses, such as all commercial software and, to a lesser extent, GPL'ed software.
I'd like to minimize (GPL) or eliminate (genuinely free "university style" licenses) the licensing risks and encumbrances, so I can do whatever I want with the software as I go along, especially as conditions change.
There are other risks to using sometimes amateurish "free" software, but those are diminishing over time in the major categories, while the licensing risks do not seem to be diminishing.
I already find OSS products to be the best overall solution in certain categories, and I anticipate that the number of such categories will continue to grow as the risks of OSS gradually fall below those of commercial products and the usefulness catches up.
A lot of us who are pretty hard core about programming pay more attention to the theory and practice of programming than we do to tinkering with hardware and drivers.
For Windows, ordering a power machine from a major vendor works wonderfully. Even with Linux, I like having a mainstream hardware setup (not too cutting edge) to increase the chances that my distro installer can do the grunt work of making all the hardware pieces work together without intervention from me.
The sooner I can get my dev tools installed and get down to programming -- and put the hardware and system config out of my mind -- the more I like it.
(Ironically, all my relatives think that since I'm a programmer, I'm naturally the perfect person to resolve all the driver conflicts they have in that hacked together pile of PC parts they just saved so much money on, so that's how I get to spend my holidays....)
Sorry about my delay in replying, but maybe you'll see this anyway.
Since I pretty much agree with everything you said in this posting, our opinions may not differ significantly.
One nit I would pick is that while most Japanese teams have a copy of the "JIS manual" you mention, that doesn't mean that they have any deep understanding of the *issues*. US teams have CP1252 charts and MacRoman charts and Latin-1 charts and yet few have much understanding of the Euro sign "issue".
It's a "nit" because who can be said to have a "deep understanding" is a pretty fuzzy question, but the normal complaints I hear about Unicode in Japan make it clear that their (fading) aversion to Unicode comes about mainly due to misunderstanding and urban legend.
I've had so many conversations with Japanese who tell me that Shift-JIS fonts are better for Japanese than Unicode fonts, then they're surprised when I point out that "Shift-JIS fonts" *are* Unicode fonts (well, almost always).
Or those who rail against "han unification" without realizing it was invented in Japan to solve Japanese text processing problems...
Or those who talk about Unicode not having the characters needed for Japanese, but when I ask which official Japanese character sets, the characters chosen by the Japanese for themselves, are not either already in Unicode or scheduled for inclusion, the best I've ever heard them come up with has been either a massive glyph list one guy is working on or the Morohashi dictionary, both of which have been rejected by Japan's own standards agency.
I just don't think that the frequency with which you hear Japanese spouting off about the inadequacy of Unicode should be taken too seriously.
Just ask any Japanese engineer worth his weight in rice and they will tell you that Unicode does not satisfy the needs of Japanese text processing.
And they'll be wrong, unless they mean every need, in which case nothing does.
Most of what you're hearing is uninformed urban legend, because most Japanese engineers are no better informed about Japanese text issues than most Western engineers are about Western text issues.
There are numerous issues with Unicode not providing fair ground for Japanese specific Kanji.
None of much importance compared to the issues in legacy Japanese encodings. Unicode is a dramatic improvement over any common Japanese alternative, which is why it has so much support from Japan's own national representatives on international standards committees.
.Net will be as portable as Java within a few years. Wherever MS doesn't take.Net, the OSS community will.
With or without a full equivalent of.Net, I expect to see a lot of ISO C# implementations, optimized for various interesting tasks and platforms. Nothing about the ECMA C# spec requires IL (.Net's "bytecode"). Apple could certainly create an ISO C# implementation, call it Apple C# (MS released the name with the standard), have it natively compiled to PPC instructions, and have it use some combination of.Net APIs and Cocoa APIs.
Other platforms could do likewise, if MS doesn't do it for them. I think C#, if not all of.Net, is going to be less "pure" than Java (more variants) and ultimately far more broadly used.
What makes C/C++ so great is the relationship between your char arrays and pointers
No, one thing that makes it great is the relationship between byte arrays and pointers. Those are not characters. They are bytes. They may be the encoding of any type of data: text, numbers, audio, video....
A C-type way of dealing with bytes is needed, of course. That's separate from the need to deal with text. Things inside quotation marks ("hello, world") should be text, and treated as an abstraction one layer above raw bytes.
And why are you complaining about a string class? Write your own, and use it in your programs.
And everyone does, because it was so badly fumbled by C's built-in "string" design. The fact that anyone who needs to go beyond 7-bit ASCII has to reinvent such a fundamental language feature is a dead giveaway that C's built-in approach is deficient.
If you use C/C++ in the way it was meant to, you'll find it very powerful and very "just the way you would like it to be".
I've done so for years, and my long experience with it and a wide range of other languages makes it abundantly clear that while the need for a bit- and byte-manipulation level language is still very real (C), and the need to be able to build up from that low level to rather high levels of abstraction is also very important (C++), the design of C/C++ is absurdly far from "just the way you would like it to be".
One of the benefits of C++ is that you can drill down from a level of objects sending messages to each other to void* shuffling bytes and operators that twiddle bits when necessary.
C++ is a great idea, but it's a monstrosity of an implementation for historical reasons.
Working in layers is the only sensible way to go, but I don't think you need to call out of one language and into another to do so.
Both C++ and Lisp are models of building in layers within the same language.
It's not needed in the sense that development can't be done without it, of course, but it's needed in the sense of convenience and usefulness.
Having a single language that spans high- to low-level abstraction allows you to choose the appropriate level in a fine-grained way. In other words, you may decide to drop down to "C-level" only inside the innermost loop of one compound loop within a single method. Having to pop out and call an external C routine or whatever is very clumsy in comparison.
C developers are very reluctant to give up their byte-level fine-grained control, but as an initially small and simple project becomes successful and needs to grow, they almost always begin to create higher levels of abstraction. The small functions get called by larger functions that later get called by even larger functions (assuming development is kept clean and refactored.)
I've seen a lot of C projects that eventually evolved their own homegrown varieties of OOP, generic programming, and all sorts of things.
C++ has become very popular because a lot of the C programmers knew that they would eventually reinvent parts of it anyway, and not as well, but they weren't willing to give up the low-level control of C.
Replacing C++ with a suite of languages, each with a different string type, different programming approaches, etc., is not a very attractive option for making life easier for C++ programmers. They'd rather have a "cleaner" C++.
That's not to say that you can escape multiple languages. We'll still be using Java in the server to generate JavaScript for browsers, while talking to the database in SQL, etc., while doing system admin chores in Perl.
I'm not proposing a single language that will do it all. I'm really looking for a better C, to be used in the problem space where C is the best choice today (drivers, high-performance video, database engines, OSes, etc.)
But a better C really needs to be able to reach up to high-level abstraction easily, without requiring each app to reinvent things like OOP, which is one big reason for the usefulness of C++. For that reason the "modern C" I'm looking for really ought to replace C++ as well.
If you have a single language that can be used for both high and low level stuff then it will either be crippled at one or both of these tasks by the demands placed on it by the other(s).
I don't believe that's true, but I'd have to design and implement the language to prove it.;-)
Or it will be so fragmented that you might as well be learning more than one language anyway.
No, I think you could have a single string type, a unified set of tools for manipulating byte sequences, a single regex syntax, etc. and cover most of the range covered by C++, and that would be much less fragmented than writing in multiple languages.
A single language designed from the start to do things at a high level by default, but that let's you drill down to C-level where needed -- but not to actual C -- to a replacement for C. Something intended to be compiled down to highly optimized machine code, not to a higher-level bytecode. Something cleanly designed from the start to span the range of high-level to low, rather than evolved to be that way, like C++. Something that you really *can* develop device drivers and operating systems and embedded apps as well as big GUI client apps with.
C was quite elegant for its time, but it is no longer even close to the best we could do at that level of abstraction.
And C++ was built by taking one good idea at a time and finding a way to shoehorn it into an existing framework that never anticipated the new stuff, resulting in the monstrosity of a design we have today, with more exceptions and gotchas than the US Federal Tax Code.
For example, the utter confusion of arrays of bytes and strings of text characters is a fundamental flaw (today).
C++ can't correct the flaw and remain a superset of C, so it just added a single-byte string class and then a wide char string class, which gives us byte arrays and char* and const char* and string and wstring, all with different APIs and rules and gotchas and no consistent conversion between any given pair...all in the same language.
But wait! there's more. Since C's approach to strings (modern text data) is so poor, and C++ did something about it so late, every OS, class library, home-grown "portability layer", etc. in the world also invented its own string class, string APIs, etc. Something so utterly fundamental to almost every program is an utter mass of confusion in C/C++.
Compare that to the purity of strings in Java or C#. Yet, unfortunately, you can't compile either of those down to the sort of nugget of machine code you can compile C++ into.
Or consider something as fundamental as numerical types. How many bugs are caused by C's (and therefore C++'s) use of different definitions of char, int, wchar_t, etc., on every platform? I know why it was done, but I think fixed data types is the right choice for a general purpose language for today. Again, you can do this in Java, and have an even better selection of types in.Net, but those platforms aren't suitable for low-level coding.
Something like ECMA-334 (that's ECMA and soon to be ISO C#), which the spec allows to be compiled straight to machine code, could get pretty close to this. A small runtime to provide GC (even C and C++ have runtimes these days) could still be used, but could be overridden to do full byte-by-byte manual memory handling where needed. Bounds-checked arrays by default that let you turn off the bounds checking where you're sure you ought to, etc.
If ISO C# can't be modified to allow this, then it could be forked into a language that could. You would have the high-level constructs combined with low-level byte manipulation of memory, files, and streams, capable of being compiled down to roughly what you would get if you wrote in C, but much more reliable and easy to maintain.
A language that was designed from the start to span a range from high-level to low-level with a single string type, fixed numeric types, byte array manipulation primitives, regular expressions, gc that could be overridden, a syntax that is already widely known (C#/Java-ish)etc., would be a great replacement for C & C++.
...and you can help support it. The complaints I keep reading are all about how tough it will be for those poor XML tools makers. As an XML tool maker, I assure you that this upgrade is no sweat. No one with the technical skill to create a serious XML tool is going to be challenged by this. The universality goals of Unicode and XML mesh very nicely and it's worth continuing to incorporate the lessons learned by each into the other.
If you build sites that need to scale multilingually, you'll find CFMX dramatically better than PHP or Perl because it's based on Java (therefore Unicode) strings.
It gives you the convenience of tag-based scripting, like PHP, with the internationalization power of Java.
This isn't likely to matter if your client is a local shoe store, but for larger clients it does, even if the client doesn't realize it.
A database that can only handle one subset of our customers per database instance is too amateurish to consider for much beyond managing a Christmas card list. And, come to think of it, without Unicode it couldn't even handle my Christmas card list.
I can imagine some niche uses, but I would never consider it for a general-purpose database platform for a company with international aspirations.
It's not the mouse, it's the apps. It's the UI. Because the dumbed down mouse is the standard, the apps tend to be designed for it, instead of being designed for a 2-button mouse, as all Windows apps are. That design approach is the problem.
I could easily afford to upgrade the mouse for my "multi-thousand-dollar" computer, but that wouldn't help if the apps aren't built for it. Apps like the Finder, iTunes, etc. don't have context menus for most things, because Apple thinks using only one button is better, and buying a 2-button mouse for my own machine won't change the way Apple designs their apps.
If only we could convince Apple to Think Different....
The two button mouse, where the second button is restricted to doing just one thing: bringing up a context menu -- is a huge improvement in usability over a single mouse button.
The scroll wheel on the mouse, eliminating the need to ever hunt down and manipulate a scroll bar in well-written apps, is the greatest thing since the mouse itself.
The Mac has neither. The Mac UI seems to be ruled by religious precepts that were finalized in the 1980's and no longer open for discussion.
Yes, you can buy a 3rd-party mouse with the extra button and wheel, or use both hands and type/click (ctrl-click) and it may work with 3rd-party Windows apps ported to the Mac, but not (or very little) with Apple's own software. Try finding context menus in the Finder or iTunes, etc. On Windows, every visual item would expose the useful operations that could be performed on it via a context menu. You want to know "how do I do...?" for some item? Try right-clicking it. But that's a Windows idea that Apple didn't invent, so they don't believe in it.
The standard Mac has a single-button mouse, so Mac developers have a lot less incentive than Windows developers to create context menus. Apple doesn't tell developers not to do it, but they never recommend a good, thorough set of context menus as part of their UI guidelines.
Apple's early studies of mouse buttons compared single mouse buttons with complex functionality vs. multiple mouse buttons, each with complex functionality, and tested them on an audience that had never used a mouse or a GUI before.
They looked at lots of different placements of scroll bars, never considering the idea of a scroll wheel that could make scrollbars unnecessary.
How many ways does a study have to be out of date before Apple will reconsider their "I can operate the mouse wearing an oven mit" religion? Almost all computer buyers today (in major markets) are buying a replacement computer, and 95% have experience using a 2-button Windows mouse. Many of them don't use the second button, but the Windows UI doesn't require them to. It's merely a convenience, albeit a huge one. The Apple studies were looking at 2nd mouse functions that were both complex and required, and decided that they weren't a good idea, and now there's no changing their minds.
Until Apple catches up and starts using a "normal" mouse (or something better), I'll find the process of hunting down scroll bars and selecting followed by menu spelunking too annoying to consider a Mac.
I said it was free, and it is. It costs no more than the JDK, which is to say: nothing. That "if you already paid for Windows" stuff is silly. I already said that when Java was at this stage, I had to buy a whole PC to use it because the Mac version was hopelessly behind Windows (and the Linux version nonexistent.)
And what's this about source? Go ahead. Take that Java source, fork Java and see what happens to you. And where is the source for that darned javac? I can't seem to find it. I need it because I'd like to create a new dialect of the Java language to sell to scientific developers. Hmm.
If you want to customize a Java-like language without getting sued, start with ECMA C#.
Download the SDK from MS. It's just like downloading the Java SDK (JDK) from Sun.
It's free. You'll get a C# compiler, a bunch of class libraries, and a runtime, plus other goodies (e.g. other languages, but stick with C# if you're starting new.)
Get a beginning C# book and go to work. It's no different from learning what Java was about in Java's early days.
If your complaint is then, "but I'm not a Windows user", I can relate. One of the main reasons I became a Windows user was because I was having such a hard time learning the "cross-platform" Java language on my Mac back in the early days.
If you're not a Windows user, you should be used to waiting by now, so wait for (or go help) Mono. Since I'm not a Windows user on the server side, I have to wait with you for some things, but I think that there will eventually be an excellent.Net for non-Windows platforms.
What I noticed was just how uncomfortable the author seemed, to be seen saying anything positive about something from MS to this crowd.
Pretty sad when the political orthodoxy is so overwhelming that every sentence has to start with the equivalent of "please don't hate me for saying it, but this wasn't as bad as I naturally assumed..." when discussing a book on programming.
C# is what you get if you take several years of Java real-world experience and ask "if we could do it over again from scratch, with no backward compatibility requirements with existing Java, what would we do?"
C# is what you get if, instead of taking Sun's attitude of "please, you're a programmer, not a language designer -- if what you're asking for were a good idea, we would have done it", you take MS's "mercenary" attitude of "what changes would you make to Java if you could?".
Netscape *was* right, but AWT was not well done. Swing was much better, but wasn't native. And the performance of Java couldn't match VC++. And then their was that albatross of a runtime that had to be dragged along with every instance of every app.
I was trying to build a Windows client-side consumer app in Java back then. It quickly became clear that even if the bugs were cleared up, my app would never look and feel as good as a native app -- that any competitor of ours that rebuilt our app in VC++ would take away our Windows market, leaving us with the remainder of that vast cross-platform client market out there.
No way. We had to go back, hold our noses, and work in VC++, sacrificing the non-Windows market in order not to lose the Windows market. Java just couldn't compete against the native VC++.
Windows controls more than 90% of the (full sized) clients.
MS stated that they were not going to lose control of their own platform by allowing cross-platform Java to become the best way to create Windows apps.
Sun, at the same time, was saying that they were trying to make Windows obsolete, so the last thing they wanted was to let Java become "just a better way to write Windows apps".
The only thing they both seem to have agreed on was that they didn't want Java to be too good at creating Win32 apps. So Sun stood on Java's tail while MS beat it senseless, and they both got their wish.
Yes I have tried, and last time I checked neither PHP nor MySQL supported UTF-8. I'm not saying that you can't simply pass a byte sequence through them unprocessed. You can usually do that with anything. I'm saying that the data processing features that had no trouble processing Latin-1-encoded text could not successfully perform the same processing if the text were encoded as UTF-8.
I'm not claiming I built such a system and it failed. I'm saying I tried designing one with the help of the official docs and the online experts with each technology, and was assured that "sorry, you can't do that."
Contrast that with the other technologies I mentioned where the data is always normalized into some form of Unicode internally before the processing even begins so that all processing is language-independent. All algorithms (features) will work on any sequence of characters, regardless of what language or mix of languages they represent.
I've built many such systems with Java/Oracle, and a few new ones with.Net/SQLServer. Both approaches are terrific. (I now prefer C#/.Net to Java, but I *strongly* prefer Unix to Windows on the server, so I'm still mostly using the Java/Oracle approach for production until I can get a good C# and.Net for Unix platforms. Go Mono!)
I keep saying "the last I checked" because eventually all non-Unicode systems will either add Unicode support or die. These two will eventually retrofit something, probably UTF-8, and maybe it has already happened, but systems like Java and.Net are so far ahead in globalization that it will be a long time before I'd consider PHP/MySQL for any company beyond a local shoe store or bakery (where I admit they have a pretty good niche).
Slashdot Mirror
And if you're less concerned about portability, ISO C# will make it possible to do some really powerful, native things on other platforms, such as Linux or Mac OS X (Cocoa).
It is superb technology: a combination of many of the best features of Java, Delphi, C++, and Perl. It doesn't "reek" of anything. (Well, maybe of Java, if you think Java reeks.) Mono will make it possible to use the excellent ISO C# language, the excellent ASP.Net, and the excellent .Net class libraries, without ever leaving the excellent Linux platform or having to use any product from MS.
On the other hand, if you are less of an ideologue and more practical about technology, Mono makes it "safe" to use MS technologies when they are the best choice, because you don't have to make everything MS. You can order a la carte.
I think they're both going to lose in a sense, but MS will fare better.
.Net framework, but they can't stop people from doing their own ISO C# implementation. Such an implementation will be both free of royalties and free of license restrictions (such as Java's) that restrict the vendor from being able to customize the libraries for their own needs.
.Net into the wild, MS has almost guaranteed that it will evolve into a formidable competitor to the domesticated Java.
Sun's control over Java will make Java less able to compete with ISO C#, which MS *won't* be able to control.
MS may be able to prevent others from doing a complete clone of the entire
Once it becomes clear how little control MS has over it, this should be irresistible to both commercial vendors and to OSS developers. MS ought to still do well, though, by having the most complete libraries, the best dev tools, the reputation as "the real thing", etc., so they'll do well.
By releasing C# and at least some portion of
Interesting. I don't have any experience with Python, but having used many, many other platforms over the years, I know how much one's opinion about a tool can change after a year or so of intense effort. I'm always interested to hear from those who have gone through it, especially when the whole team eventually reached the same conclusion (as usually happens, in my experience).
I'm not one of those who feels that software companies are evil for selling software and insisting that customers actually pay. I think they have the right to do so if they create the software.
Even so, from a user's perspective, there are risks to running software with "we'll sue you unless you follow our rules" licenses, such as all commercial software and, to a lesser extent, GPL'ed software.
I'd like to minimize (GPL) or eliminate (genuinely free "university style" licenses) the licensing risks and encumbrances, so I can do whatever I want with the software as I go along, especially as conditions change.
There are other risks to using sometimes amateurish "free" software, but those are diminishing over time in the major categories, while the licensing risks do not seem to be diminishing.
I already find OSS products to be the best overall solution in certain categories, and I anticipate that the number of such categories will continue to grow as the risks of OSS gradually fall below those of commercial products and the usefulness catches up.
A lot of us who are pretty hard core about programming pay more attention to the theory and practice of programming than we do to tinkering with hardware and drivers.
For Windows, ordering a power machine from a major vendor works wonderfully. Even with Linux, I like having a mainstream hardware setup (not too cutting edge) to increase the chances that my distro installer can do the grunt work of making all the hardware pieces work together without intervention from me.
The sooner I can get my dev tools installed and get down to programming -- and put the hardware and system config out of my mind -- the more I like it.
(Ironically, all my relatives think that since I'm a programmer, I'm naturally the perfect person to resolve all the driver conflicts they have in that hacked together pile of PC parts they just saved so much money on, so that's how I get to spend my holidays....)
Sorry about my delay in replying, but maybe you'll see this anyway.
Since I pretty much agree with everything you said in this posting, our opinions may not differ significantly.
One nit I would pick is that while most Japanese teams have a copy of the "JIS manual" you mention, that doesn't mean that they have any deep understanding of the *issues*. US teams have CP1252 charts and MacRoman charts and Latin-1 charts and yet few have much understanding of the Euro sign "issue".
It's a "nit" because who can be said to have a "deep understanding" is a pretty fuzzy question, but the normal complaints I hear about Unicode in Japan make it clear that their (fading) aversion to Unicode comes about mainly due to misunderstanding and urban legend.
I've had so many conversations with Japanese who tell me that Shift-JIS fonts are better for Japanese than Unicode fonts, then they're surprised when I point out that "Shift-JIS fonts" *are* Unicode fonts (well, almost always).
Or those who rail against "han unification" without realizing it was invented in Japan to solve Japanese text processing problems...
Or those who talk about Unicode not having the characters needed for Japanese, but when I ask which official Japanese character sets, the characters chosen by the Japanese for themselves, are not either already in Unicode or scheduled for inclusion, the best I've ever heard them come up with has been either a massive glyph list one guy is working on or the Morohashi dictionary, both of which have been rejected by Japan's own standards agency.
I just don't think that the frequency with which you hear Japanese spouting off about the inadequacy of Unicode should be taken too seriously.
Just ask any Japanese engineer worth his weight in rice and they will tell you that Unicode does not satisfy the needs of Japanese text processing.
And they'll be wrong, unless they mean every need, in which case nothing does.
Most of what you're hearing is uninformed urban legend, because most Japanese engineers are no better informed about Japanese text issues than most Western engineers are about Western text issues.
There are numerous issues with Unicode not providing fair ground for Japanese specific Kanji.
None of much importance compared to the issues in legacy Japanese encodings. Unicode is a dramatic improvement over any common Japanese alternative, which is why it has so much support from Japan's own national representatives on international standards committees.
.Net will be as portable as Java within a few years. Wherever MS doesn't take .Net, the OSS community will.
.Net, I expect to see a lot of ISO C# implementations, optimized for various interesting tasks and platforms. Nothing about the ECMA C# spec requires IL (.Net's "bytecode"). Apple could certainly create an ISO C# implementation, call it Apple C# (MS released the name with the standard), have it natively compiled to PPC instructions, and have it use some combination of .Net APIs and Cocoa APIs.
.Net, is going to be less "pure" than Java (more variants) and ultimately far more broadly used.
With or without a full equivalent of
Other platforms could do likewise, if MS doesn't do it for them. I think C#, if not all of
The preferred pronunciation is "urinous", class. "Urinous". So, see, there's really nothing to snicker about. Class? That's enough now.
What makes C/C++ so great is the relationship between your char arrays and pointers
No, one thing that makes it great is the relationship between byte arrays and pointers. Those are not characters. They are bytes. They may be the encoding of any type of data: text, numbers, audio, video....
A C-type way of dealing with bytes is needed, of course. That's separate from the need to deal with text. Things inside quotation marks ("hello, world") should be text, and treated as an abstraction one layer above raw bytes.
And why are you complaining about a string class? Write your own, and use it in your programs.
And everyone does, because it was so badly fumbled by C's built-in "string" design. The fact that anyone who needs to go beyond 7-bit ASCII has to reinvent such a fundamental language feature is a dead giveaway that C's built-in approach is deficient.
If you use C/C++ in the way it was meant to, you'll find it very powerful and very "just the way you would like it to be".
I've done so for years, and my long experience with it and a wide range of other languages makes it abundantly clear that while the need for a bit- and byte-manipulation level language is still very real (C), and the need to be able to build up from that low level to rather high levels of abstraction is also very important (C++), the design of C/C++ is absurdly far from "just the way you would like it to be".
One of the benefits of C++ is that you can drill down from a level of objects sending messages to each other to void* shuffling bytes and operators that twiddle bits when necessary.
C++ is a great idea, but it's a monstrosity of an implementation for historical reasons.
Working in layers is the only sensible way to go, but I don't think you need to call out of one language and into another to do so.
Both C++ and Lisp are models of building in layers within the same language.
Why do we need a single language to do this?
;-)
It's not needed in the sense that development can't be done without it, of course, but it's needed in the sense of convenience and usefulness.
Having a single language that spans high- to low-level abstraction allows you to choose the appropriate level in a fine-grained way. In other words, you may decide to drop down to "C-level" only inside the innermost loop of one compound loop within a single method. Having to pop out and call an external C routine or whatever is very clumsy in comparison.
C developers are very reluctant to give up their byte-level fine-grained control, but as an initially small and simple project becomes successful and needs to grow, they almost always begin to create higher levels of abstraction. The small functions get called by larger functions that later get called by even larger functions (assuming development is kept clean and refactored.)
I've seen a lot of C projects that eventually evolved their own homegrown varieties of OOP, generic programming, and all sorts of things.
C++ has become very popular because a lot of the C programmers knew that they would eventually reinvent parts of it anyway, and not as well, but they weren't willing to give up the low-level control of C.
Replacing C++ with a suite of languages, each with a different string type, different programming approaches, etc., is not a very attractive option for making life easier for C++ programmers. They'd rather have a "cleaner" C++.
That's not to say that you can escape multiple languages. We'll still be using Java in the server to generate JavaScript for browsers, while talking to the database in SQL, etc., while doing system admin chores in Perl.
I'm not proposing a single language that will do it all. I'm really looking for a better C, to be used in the problem space where C is the best choice today (drivers, high-performance video, database engines, OSes, etc.)
But a better C really needs to be able to reach up to high-level abstraction easily, without requiring each app to reinvent things like OOP, which is one big reason for the usefulness of C++. For that reason the "modern C" I'm looking for really ought to replace C++ as well.
If you have a single language that can be used for both high and low level stuff then it will either be crippled at one or both of these tasks by the demands placed on it by the other(s).
I don't believe that's true, but I'd have to design and implement the language to prove it.
Or it will be so fragmented that you might as well be learning more than one language anyway.
No, I think you could have a single string type, a unified set of tools for manipulating byte sequences, a single regex syntax, etc. and cover most of the range covered by C++, and that would be much less fragmented than writing in multiple languages.
A single language designed from the start to do things at a high level by default, but that let's you drill down to C-level where needed -- but not to actual C -- to a replacement for C. Something intended to be compiled down to highly optimized machine code, not to a higher-level bytecode. Something cleanly designed from the start to span the range of high-level to low, rather than evolved to be that way, like C++. Something that you really *can* develop device drivers and operating systems and embedded apps as well as big GUI client apps with.
.Net, but those platforms aren't suitable for low-level coding.
C was quite elegant for its time, but it is no longer even close to the best we could do at that level of abstraction.
And C++ was built by taking one good idea at a time and finding a way to shoehorn it into an existing framework that never anticipated the new stuff, resulting in the monstrosity of a design we have today, with more exceptions and gotchas than the US Federal Tax Code.
For example, the utter confusion of arrays of bytes and strings of text characters is a fundamental flaw (today).
C++ can't correct the flaw and remain a superset of C, so it just added a single-byte string class and then a wide char string class, which gives us byte arrays and char* and const char* and string and wstring, all with different APIs and rules and gotchas and no consistent conversion between any given pair...all in the same language.
But wait! there's more. Since C's approach to strings (modern text data) is so poor, and C++ did something about it so late, every OS, class library, home-grown "portability layer", etc. in the world also invented its own string class, string APIs, etc. Something so utterly fundamental to almost every program is an utter mass of confusion in C/C++.
Compare that to the purity of strings in Java or C#. Yet, unfortunately, you can't compile either of those down to the sort of nugget of machine code you can compile C++ into.
Or consider something as fundamental as numerical types. How many bugs are caused by C's (and therefore C++'s) use of different definitions of char, int, wchar_t, etc., on every platform? I know why it was done, but I think fixed data types is the right choice for a general purpose language for today. Again, you can do this in Java, and have an even better selection of types in
Something like ECMA-334 (that's ECMA and soon to be ISO C#), which the spec allows to be compiled straight to machine code, could get pretty close to this. A small runtime to provide GC (even C and C++ have runtimes these days) could still be used, but could be overridden to do full byte-by-byte manual memory handling where needed. Bounds-checked arrays by default that let you turn off the bounds checking where you're sure you ought to, etc.
If ISO C# can't be modified to allow this, then it could be forked into a language that could. You would have the high-level constructs combined with low-level byte manipulation of memory, files, and streams, capable of being compiled down to roughly what you would get if you wrote in C, but much more reliable and easy to maintain.
A language that was designed from the start to span a range from high-level to low-level with a single string type, fixed numeric types, byte array manipulation primitives, regular expressions, gc that could be overridden, a syntax that is already widely known (C#/Java-ish)etc., would be a great replacement for C & C++.
...and you can help support it. The complaints I keep reading are all about how tough it will be for those poor XML tools makers. As an XML tool maker, I assure you that this upgrade is no sweat. No one with the technical skill to create a serious XML tool is going to be challenged by this. The universality goals of Unicode and XML mesh very nicely and it's worth continuing to incorporate the lessons learned by each into the other.
If you build sites that need to scale multilingually, you'll find CFMX dramatically better than PHP or Perl because it's based on Java (therefore Unicode) strings.
It gives you the convenience of tag-based scripting, like PHP, with the internationalization power of Java.
This isn't likely to matter if your client is a local shoe store, but for larger clients it does, even if the client doesn't realize it.
A database that can only handle one subset of our customers per database instance is too amateurish to consider for much beyond managing a Christmas card list. And, come to think of it, without Unicode it couldn't even handle my Christmas card list.
I can imagine some niche uses, but I would never consider it for a general-purpose database platform for a company with international aspirations.
Wow, someone who completely missed the point.
It's not the mouse, it's the apps. It's the UI. Because the dumbed down mouse is the standard, the apps tend to be designed for it, instead of being designed for a 2-button mouse, as all Windows apps are. That design approach is the problem.
I could easily afford to upgrade the mouse for my "multi-thousand-dollar" computer, but that wouldn't help if the apps aren't built for it. Apps like the Finder, iTunes, etc. don't have context menus for most things, because Apple thinks using only one button is better, and buying a 2-button mouse for my own machine won't change the way Apple designs their apps.
If only we could convince Apple to Think Different....
The two button mouse, where the second button is restricted to doing just one thing: bringing up a context menu -- is a huge improvement in usability over a single mouse button.
The scroll wheel on the mouse, eliminating the need to ever hunt down and manipulate a scroll bar in well-written apps, is the greatest thing since the mouse itself.
The Mac has neither. The Mac UI seems to be ruled by religious precepts that were finalized in the 1980's and no longer open for discussion.
Yes, you can buy a 3rd-party mouse with the extra button and wheel, or use both hands and type/click (ctrl-click) and it may work with 3rd-party Windows apps ported to the Mac, but not (or very little) with Apple's own software. Try finding context menus in the Finder or iTunes, etc. On Windows, every visual item would expose the useful operations that could be performed on it via a context menu. You want to know "how do I do...?" for some item? Try right-clicking it. But that's a Windows idea that Apple didn't invent, so they don't believe in it.
The standard Mac has a single-button mouse, so Mac developers have a lot less incentive than Windows developers to create context menus. Apple doesn't tell developers not to do it, but they never recommend a good, thorough set of context menus as part of their UI guidelines.
Apple's early studies of mouse buttons compared single mouse buttons with complex functionality vs. multiple mouse buttons, each with complex functionality, and tested them on an audience that had never used a mouse or a GUI before.
They looked at lots of different placements of scroll bars, never considering the idea of a scroll wheel that could make scrollbars unnecessary.
How many ways does a study have to be out of date before Apple will reconsider their "I can operate the mouse wearing an oven mit" religion? Almost all computer buyers today (in major markets) are buying a replacement computer, and 95% have experience using a 2-button Windows mouse. Many of them don't use the second button, but the Windows UI doesn't require them to. It's merely a convenience, albeit a huge one. The Apple studies were looking at 2nd mouse functions that were both complex and required, and decided that they weren't a good idea, and now there's no changing their minds.
Until Apple catches up and starts using a "normal" mouse (or something better), I'll find the process of hunting down scroll bars and selecting followed by menu spelunking too annoying to consider a Mac.
I said it was free, and it is. It costs no more than the JDK, which is to say: nothing. That "if you already paid for Windows" stuff is silly. I already said that when Java was at this stage, I had to buy a whole PC to use it because the Mac version was hopelessly behind Windows (and the Linux version nonexistent.)
And what's this about source? Go ahead. Take that Java source, fork Java and see what happens to you. And where is the source for that darned javac? I can't seem to find it. I need it because I'd like to create a new dialect of the Java language to sell to scientific developers. Hmm.
If you want to customize a Java-like language without getting sued, start with ECMA C#.
Download the SDK from MS. It's just like downloading the Java SDK (JDK) from Sun.
.Net for non-Windows platforms.
It's free. You'll get a C# compiler, a bunch of class libraries, and a runtime, plus other goodies (e.g. other languages, but stick with C# if you're starting new.)
Get a beginning C# book and go to work. It's no different from learning what Java was about in Java's early days.
If your complaint is then, "but I'm not a Windows user", I can relate. One of the main reasons I became a Windows user was because I was having such a hard time learning the "cross-platform" Java language on my Mac back in the early days.
If you're not a Windows user, you should be used to waiting by now, so wait for (or go help) Mono. Since I'm not a Windows user on the server side, I have to wait with you for some things, but I think that there will eventually be an excellent
What I noticed was just how uncomfortable the author seemed, to be seen saying anything positive about something from MS to this crowd.
Pretty sad when the political orthodoxy is so overwhelming that every sentence has to start with the equivalent of "please don't hate me for saying it, but this wasn't as bad as I naturally assumed..." when discussing a book on programming.
C# is what you get if you take several years of Java real-world experience and ask "if we could do it over again from scratch, with no backward compatibility requirements with existing Java, what would we do?"
C# is what you get if, instead of taking Sun's attitude of "please, you're a programmer, not a language designer -- if what you're asking for were a good idea, we would have done it", you take MS's "mercenary" attitude of "what changes would you make to Java if you could?".
Netscape *was* right, but AWT was not well done. Swing was much better, but wasn't native. And the performance of Java couldn't match VC++. And then their was that albatross of a runtime that had to be dragged along with every instance of every app.
I was trying to build a Windows client-side consumer app in Java back then. It quickly became clear that even if the bugs were cleared up, my app would never look and feel as good as a native app -- that any competitor of ours that rebuilt our app in VC++ would take away our Windows market, leaving us with the remainder of that vast cross-platform client market out there.
No way. We had to go back, hold our noses, and work in VC++, sacrificing the non-Windows market in order not to lose the Windows market. Java just couldn't compete against the native VC++.
Windows controls more than 90% of the (full sized) clients.
MS stated that they were not going to lose control of their own platform by allowing cross-platform Java to become the best way to create Windows apps.
Sun, at the same time, was saying that they were trying to make Windows obsolete, so the last thing they wanted was to let Java become "just a better way to write Windows apps".
The only thing they both seem to have agreed on was that they didn't want Java to be too good at creating Win32 apps. So Sun stood on Java's tail while MS beat it senseless, and they both got their wish.
Yes I have tried, and last time I checked neither PHP nor MySQL supported UTF-8. I'm not saying that you can't simply pass a byte sequence through them unprocessed. You can usually do that with anything. I'm saying that the data processing features that had no trouble processing Latin-1-encoded text could not successfully perform the same processing if the text were encoded as UTF-8.
.Net/SQLServer. Both approaches are terrific. (I now prefer C#/.Net to Java, but I *strongly* prefer Unix to Windows on the server, so I'm still mostly using the Java/Oracle approach for production until I can get a good C# and .Net for Unix platforms. Go Mono!)
.Net are so far ahead in globalization that it will be a long time before I'd consider PHP/MySQL for any company beyond a local shoe store or bakery (where I admit they have a pretty good niche).
I'm not claiming I built such a system and it failed. I'm saying I tried designing one with the help of the official docs and the online experts with each technology, and was assured that "sorry, you can't do that."
Contrast that with the other technologies I mentioned where the data is always normalized into some form of Unicode internally before the processing even begins so that all processing is language-independent. All algorithms (features) will work on any sequence of characters, regardless of what language or mix of languages they represent.
I've built many such systems with Java/Oracle, and a few new ones with
I keep saying "the last I checked" because eventually all non-Unicode systems will either add Unicode support or die. These two will eventually retrofit something, probably UTF-8, and maybe it has already happened, but systems like Java and