"By now, Windows and Unix are functionally more similar than different. They both support the same major programming metaphors, from command lines to GUIs to web servers; they are organized around virtually the same panoply of system resources, from nearly identical file systems to memory to sockets and processes and threads. There's not much about the core set of services provided by each operating system to limit the kinds of applications you can create. What's left is cultural differences." Read the article by JoelOnSoftware.
Post a Comment
I implore all *nix users/programmers to read "The Art of Unix Programming" and "The Unix Haters Handbook". You'll get a deep understanding of why *nix users/programmers are anti-GUI, anti-binary formats and anti-closed. On the whole, this is an excellent article.
*Oh, and I still think Unix programming and philosophy is superior above all.* :-D
It seems the purpose of that article is to attack ESR rather than comparing differences. In my opinion Win and UNIX are quite different from technical and cultural view.
Even if any two OSes both support many same mechanisms, it doesn't make them similar. They are only similar if they are similar in _how_ they do it. For example even if BeOS and Win both have same mechanisms commonly used, they are totally different.
Also, the author of the article should realize file systems of UNIX and Win are quite different (UNIX uses global namespace, different locking, devices and other special files, only / and are special characters, and the culture on use of namespace is totally different).
Also, Processes are quite different on unix (see fork()).
The big cultural difference between unix and win is, that win people believe that policies should be same for everyone, but unix people believe that _mechanisms_ should be same for everyone. This is actually a huge difference, and I think it's good that the writer of the article brought it up. It can be seen in practice when two different UNIX OSes do things the different way. They all offer some mechanism for the same job.
"anti-binary formats"
Nah... windows programers are anti binary formats. Just look at all the VB.
And I'm not really sure about the anti GUI thing. I may be new to this (about a couple of years into Linux) but even the most diehard commandline folks use X with a terminal emulator.
Oh and the "The Unix Haters Handbook" is wildly out of date.
It seems the purpose of that article is to attack ESR rather than comparing differences.
ESR is the Rob Enderle of the Free Software world and deserves to be attacked. I haven't read his new diatribe, and probably won't, but what the author says in a roundabout way, is that ESR is represenative of the folks on Usenet who will tell you to "RTFM" instead of venturing to answer your question.
That is...if there is a FM these days, as many programmers have abandoned them altogether, which sort of throws the whole argument out of the water. Sometimes, the only help a package will have is the command-line output. It's fun installing a Debian package and finding that template man page just to satisfy the Debian handbook.
I agree with his overall assessment of programming within frameworks being quite different. Look at qmail! No windows programmer in his right mind would create something that is so ignorant of the tools available on the host platform. (I'm not being critical, really, just pointing it out as a prime example....I use qmail on some of my servers)
That said, there are ways Windows programmers can pretty much be comfortable on Unix platforms nowadays. There's Cocoa on OSX. There's QT/KDE on others.... And you can do things pretty much the same way you would.
It's just personal preference.
"and repeated efforts to make a pretty front end for Unix that Aunt Marge can use have failed"
MacOS X
Ah, perhaps my thoughts were poorly communicated.
"anti-binary formats"
Nah... windows programers are anti binary formats. Just look at all the VB.
By anti-binary formats, I meant Unix coders/users prefer their files (configuration files come to mind) be stored in formats they can read and edit, textual formats. Not the same in other OSes.
And I'm not really sure about the anti GUI thing. I may be new to this (about a couple of years into Linux) but even the most diehard commandline folks use X with a terminal emulator.
Most hardcore Unix users don't believe you need a GUI for every single task. They are great and helpful for basic and straightforward tasks, but ultimately, they prefer the command line interface with a powerful and expressive language like Bash. "Uh, what is a file manager?", type of users.
Oh and the "The Unix Haters Handbook" is wildly out of date.
Yes, but it's still a good read, it mentions various weaknesses or flaws inherent in the design of Unix, most of which I disagree with though.
"ESR is the Rob Enderle of the Free Software world and deserves to be attacked. I haven't read his new diatribe, and probably won't, but what the author says in a roundabout way, is that ESR is represenative of the folks on Usenet who will tell you to "RTFM" instead of venturing to answer your question."
That has nothing to do with Unix. That is just human nature. Do you think all windows "gurus" would go out of their way to answer every question you might have? They are all nice wonderful people who never tell you to go to hell?
"Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers."
That is because UNIX culture has mostly been "by professionals, for professionals" and Windows has been to sell stuff to "consumers". UNIX values peopele who do it themselves and Windows values people who pay other to do it.
That has nothing to do with Unix. That is just human nature. Do you think all windows "gurus" would go out of their way to answer every question you might have? They are all nice wonderful people who never tell you to go to hell?
No, of course not. But that's not the point, either, and you conviently ignore what I said. There's a difference between being unwilling to help, and showing your supeiority by being rude -- and that's something I've seen from holier-than-thou Linux users for years now. And I don't see it elsewhere as much. I don't remember it in the OS/2 community. I certainly don't see it in the Macintosh community. In the Windows community, they're less likely to help gratis.
And there are places where there is good help for people trying to learn in the free software world. My local Unix Users' Group http://www.twuug.org is very good for that. But then there are the people in serious need of an attitude adjustment.
But it goes back to the central theme of the author's article. There are tangible cultural differences between the Windows world and the Unix world. To ignore the positives and negatives of each is to ignore reality.
What I get that he is saying is
Unix: small program | small progam | ... -> result
Windows: large program -> result
I think the difference is as simple as Windows is windows only. Unix is not. Because of an age difference of 20-30 years, technology advancement and because of inertia. You just don't just like that go back and retro fit 20-30 years worth of programs into a windows format.
Technology advancement timeline (1960 ...)
1. punchcards. They are very hard to do any windows with.
2. scrolling text terminals. Also hard to do windows with.
3. IBM 3270 full screen window/page at a time. Now prompts and answers are no longer a serial stream but randomly accessible.
4. Multiple movable windows not necessarily the same size as the physical screen and with scrollable contents. Just like papers on a desktop at tax time. This is the time when Windows came about.
"In the Windows community, they're less likely to help gratis"
And that is why you simply don't SEE all the windows snobs. All the windows power users who would quickly tell you to RTFM. They simply don't show up in the first place. But they exist as much as in Linux. They exist as much as in any hobby. Audiophiles anyone? This has nothing to do w/ *NIX. It's just as it happens to be more open, you see the ugliness more.
I was windows programmer once, working on Fax Server project,
and I still know that UNIX is superior in almost every
way.
DG
I was windows programmer once, working on Fax Server project,
and I still know that UNIX is superior in almost every
way.
No, you don't. You believe UNIX is superior.
if one belives there are only cultural differences between windwos and linux - or even unix and linux, then one havn't got a clue about operating systems.
/stone
I really like most of Joel's articles, and I also liked this one. However, what is not very clear in this article is the (missing) distinction between Unix and GNU/Linux.
It is true that GNU/Linux was developed with Unix in mind but it's on its way to invent it its own culture. Yes, a lot of GNU/Linux tools are still Unix-like and its usage is often command-line driven. But more and more Windows-orientated folks take part, and they are driving GNU/Linux development and culture to a more consumer friendly way.
The diversity of the GNU/Linux tool- and GUI sets steems from the 'cultural' value of freedom. This isn't part of Unix.
And I'm not really sure about the anti GUI thing. I may be new to this (about a couple of years into Linux) but even the most diehard commandline folks use X with a terminal emulator.
And for a significant proportion of unix users, that's it - all X is good for is getting a bunch of xterms on the screen. That's not a GUI, it's just multiple concurrent CLIs. For "hardcore" and "traditional" unix users, any "GUI" more functional than twm is just a waste of resources - even on multi-Ghz machines with gigabytes of RAM.
clausi wrote:
> The diversity of the GNU/Linux tool- and GUI sets steems from the 'cultural' value of freedom. This isn't part of Unix.
No. Freedom _is_ a part of the UNIX culture, and part of the GNU/Linux culture too.
Also, see http://www.opengroup.org/pubs/catalog/n900.htm , even if it is a little bit of joke 
Linux is a free and modern implementation of Unix, just like the *BSDs. Although, it is not entirely correct say it is UNIX, the word Linux, Unix and Unix-like are often used interchangeably.
Oh, and UNIX had always been about freedom before it was hijacked by commercial interests. Umm...hmmm, you know who they are.
Mac OS X shows that this guys just has an axe to grind against unix and linux. It is a horrible article that does not say anything. KDE is also very easy to use.
Hey, if windows is so damn easy, why are there a billion books like "Windows for Dummies" and a billion books about how to use every windows app. Why? Because they are hard to use and the software fails alot.
Unix is about software that works, Windows is about software that sounds great and is easy to sell.
That is the biggest difference.
I have read and own the UNIX haters guide and is totally irrellevent to the state of UNIX and GNU/linux today.
Unix applications developpers care as much about the end user as windows developpers do. The big difference was that all "end users" until recently were using Windows.
What linux is bringing to unix is a new user population which wants mp3 players and jukebox, spreadsheets, word processor, graphics programs, themable frontends, accelerated 3d for futile reasons (as opposed to CAD). And guess what, you now get a large number of applications that cater for this new user population, with applications that are trying to be easier to understand and to use.
But the unix concern about integration meant that most applications use clear protocols to talk to their host desktop environments.
Also, the taste for client server architecture of a lot of unix developpers (take giFT, most cd burning apps, mp3 rippers) also shows that linux developpers want to be able to improve the user interface without breaking the application's logic.
So much about not caring about end users.
C'mon, all you (we) *nix lovers; Joel is not being anti-Unix here. Why do so many of us have to feel threatened by this stuff?
I say this as a complete FreeBSD-lover: Joel has some good points, and not just anti-Unix points. His points are more on the order of "to a man with a hammer, everything looks like a nail."
I would say one large point Jeol misses is that most of us modern *nix lovers have actually cut our teeth on Windows, only to move to Linux or FreeBSD out of *intense* frustration. He fails to answer the question of why someone who was not "raised on the command line", would gravitate toward it. The answer, I think, is one of personality. If you were the sort of kid who preferred playing with Lego and the Mechano set instead of the G.I. Joe Attack Helicopter, then you are a candadate for *nix. In other words, with Lego and Mechanoe, you made your own toys, or could at least take apart the toys made by others, while with the G.I. Joe attack copter, you could buy extra pieces, but you couldn't really make your own, unless you carved extra pieces out of wood or plastic. And yes, I know this is not a complete analogy, and of course you can make many toys in windows, but the cultural differences are there. For example, I make tons of shell scripts in Unix to do little repetitive tasks. I could do the same with Windows batch files or WSH components, but I have hardly ever done so, even during the times when I was mostly a Windows user; the culture just doesn't push you in that direction. Generally, you just accept making a few extra repetitive clicks to get the job done.
Yes, there is a certain pragmatism to the Windows approach; No denying that. The real thing is, what can we as programmers/tech_gurus learn from that? There is also a definite plus to the textual-oriented input-output nature of Unix. When I want a number of things to just "happen" in the background, it is often as easy (and as robust) to script a few shell tools together than to write a complete Perl/Python/whatever application, including 10 different modules for system interaction, etc...
The question of useability is another interesting one. IMHO Windows is more useable (as long as you stay on a certain level) for the semi-techie end-user. Mac is more useable for the non-techie. But once you graduate into Power User, or general tech kind of person, *nix is more useable. That's right...MORE useable. For example, in the whole *nix world, there is no simple standard way of autodetecting hardware and popping up a simple reassuring message that the new webcam has been found and you should now insert the floppy with the drivers. But, by the same token, if Windows somehow fails to properly recognize the webcam, or the drivers don't install for some reason, the Windows user generally either calls tech support or gives up. In *nix, it might take a smidgen of reading to get your webcam recognized, but the process is not opaque; you can dig into your system at any level to understand why something isn't working.
To me the more interesting question (which Joel leaves unanswered) is "where do we go from here?". As an application developer, I treasure the idea of a development platform that allows me to write software on my favorite (FreeBSD), but deploy it anywhere. Mozilla/XUL, for example, allows me that luxury, as well as scripting languages like PHP. To that extent, I personally don't care whether *nix "wins" the desktop, but whether the operating system itself can be made irrelevant to the tasks I want to accomplish.
There are situations where I would definitely spec a FreeBSD/Linux desktop, such as a unified business office network, where one competent administrator can take the place of 4 harried Windows support people. But, I would still hesitate to tell a not-tech friend to just start using Linux, because that person will suddenly have to face the fact that all those neat little programs he/she likes to use, such as the Hallmark gift card creator, etc... are suddenly out of the question. (Yes, all those things can be dealt with, and everything has its alternative, but in the end, I know that it will involve much hand-holding, until my friend is ready for a brave new desktop)
Also, however, there _is_ one interesting Linux challenge to the desktop, in the form of Lindows and the Koobox. At least Michael Robertson understands the useability problem and has attempted to solve it with a subscription service that installs all that crazy open source software FOR you, charging you not for the software but the service. Smart, I have to say.
But really, I think we *nix users have to realize that the answer to the Windows/Mac/*nix question is quite complex. Exactly what IS the desktop, these days. Is the desktop going to become more, or less relevant (I say less), in the next few years? On the desktop side, is there a chance for cross-platform development to actually produce something decent? I say "yes", if we look at Openoffice, Mozilla/XUL, PHP, Python, QT, etc...
This is the part where Joel misses the boat the most. In his mythical comparison of a Unix-vs-Windows developer, he says "The Unix programmer will create a command-line or text-driven core and occasionally, as an afterthought, build a GUI which drives that core". It really depends on the developer. In the end, I think there are GUI programmers and non-GUI programmers. Each has their place, and in the future, they will have to worry less and less about exactly what platform they are deploying on. That is because the non-GUI programmers are working hard behind the scenes at making those things work cross-platform. Hmm...
...it wasn't Apple that rearranged the directory structure before overlaying its gui... this was all done by NeXT in NeXTSTEP.
Apple just sucked it all up and repackaged it (with some changes of course).
And I am glad to see someone mentioned BeOS way up at the top. We have to mention BeOS in every post. 
Mike
It's rather rare to find such bigotry among Windows programmers, who are, on the whole, solution-oriented and non-ideological.
You got me, Joel. I've laughting at this so much. Do you really believe what you wrote here ?
Let me say that, IMO, you have it wrong, for a simple matter: You mixed up Unix and GNU/Linux. As said before, Linux and *BSD are both modern implementation of Unix. They are unfair GUIs (who is still using twm?) and nice usable interfaces (IMO windowmaker and MAC OS X). And the Unix (cultural ?) development model made it all possible.
Two final notes:
- Remember that 10 years ago, no one was speaking about the end-user interface in Linux. Everything was missing. Think how many years was needed to move Microsoft from Dos 1.0 to Windows XP....
- Usability über alles in windows ? You must be kidding again.
When I hear people talk about Unix (Linux inparticular), they talk about free software, security, multiple file systems, bash, etc.
The typical Windows user will say, "Yeah, but can it run app xyz" ? Which leads me to believe that Unix users care more about the power of the OS while Windows users tend to be more 'application-centric.'
The way I see it, I don't really care what OS I'm running just so long as it stays out of my way so I can run the apps I want. Windows (2k/XP), once properly 'hobbled', does that for me. Linux does too, but the latter is still missing about a half-dozen apps that I run almost data, so it's power is of little use to me.
Actually there are tons of books on Windows such as the dummy book and books on just about ever application becuase most people use Windows (desktop) and there are tons more applications on Windows then on Unix/Linux.
Also you have to remember.....these books are mainly targeted at people who can hardly turn on the computer. So don't say this crap Windows is hard to use because you no its not....and if you think so I really question how much of an professional you are.
However Joel needs to realise that there is a right way of constructing a program and a wrong and I am sorry, opening up VS IDE without thinking about the whole picture is a stupid way of writing a program.
The UNIX way, creating a small core then building the interface ontop of it is the correct way of laying up funcationality where as Microsoft and Windows programmers have this addiction that they *MUST* ram every piece of functionality into one big uber executable.
For example, we have gecko which was developed on this. Small core with an interface on top. What is the net result? the net result is that the core can now be re-used in numerous other products. That is how software should be written.
By taking this approach you don't limit your self to the possibilities later on. For example, Microsoft now chants about the merits of CLI tools, but what do they need to do? they have to re-write all the tools again for the CLI when had they started with a CLI version then built up from there, they would have an evenly balanced CLI/GUI operating system.
I use a US goverment informex NASIS data base that has to allow thousands(and growing)of unique data fields open at any one time per data set, allow thousands of data sets access on demand, allow hundreds of users (and growing) to read, write data and execute script on that data as needed all at the same time. The OS has support objects, addition of future modules, data read-write and script running, group and user permissions, individual script writing, script data cross checking and report writing, fuzzy math, GIS, GPS. This OS has to remain up and running 99 percent of the time for the worlds soil scientist and only to be shut down for upgrades. The USDA had to use Nix to run operate the NASIS database itself. To my knowledge Windows could not deliver all that we need and it was droped from consideration in its development early on. We use Windows to access the system on a remote basis. This tells me there IS a difference between Nix and Windows. This tells me Nix IS needed to operate this our database and any GUI friendly OS is fine for us to access this NASIS system from an office. In most offices NASIS itself is not our frustration, its keeping Windows up and running/connected to access the NASIS database.
I'm a user and I care a lot more about useful software than technical expertise. Why would I use an OS that offers technical superiority but few applications that I want to use?
Spolsky is right, as most of the comments here illustrate.
-- and if you think so I really question how much of an professional you are. --
Hmm. "easy" is a subjective thing, is it not?
Does it make less competent an IP network and UNIX guy that I uses no Windows whatsoever in the past 1,5 years?
That is quite shock to me.
Why does this type of debate always end up in insulting each other?
In the beginning there were quite a few good points.
Since I arranged all the buttons and their functionality in my WM, Windows is a hard to use environment to me.
Probably quite a difficult desktop for anyone not used to it.
As to what drives Windows world and UNIX world: Money. All big corporations care ONLY about getting enough money to keep their investors happy.
This statement excludes all GNU and BSD people of course
Somehow I always get more attention for my problems from open source project than I do from commercial support.
For example, we have gecko which was developed on this. Small core with an interface on top. What is the net result? the net result is that the core can now be re-used in numerous other products. That is how software should be written.
You mean like the IE core, which you can use in your own apps? There are far more IE-based browsers than Gecko browsers out there, so what exactly is your point? Not staying that IE is better than Gecko, but it's not like there aren't about a million different kinds of components you can drop into any Windows application and use immediately.
Huge uber-applications are certainly not perfect, but I believe that is a better option than building a GUI 'frontend' over a lot of CLI tools; the end result feeling like a sloppy hack job.
IMHO, the CLI is great for doing system administration tasks and things where very small utils are involved. Past that point though, if you're going to go GUI, then don't do it half-assed.
I'm a user and I care a lot more about useful software than technical expertise. Why would I use an OS that offers technical superiority but few applications that I want to use?
Applications and operating system technical superiority are worlds apart. Why bring up something that has NOTHING TO DO WITH THIS ARTICLE? If the operating system is poorly designed YOU the END USER suffer as a result, either in poor stability, poor security or simply your applications will not run nicely because the programmers from your favourite software supplier spend more time working around problems rather than trying to stablise and perfect their product.
So yes, technical superiority of an operating system IS important. Instead of ranting like a loonie, how about getting out there and talking to programmers and how a crappy operating system can result in a crappy product for the END USER. Yes, thats right, the END USER does actually get affected by a crappy OS, either directly or indirectly.
"However Joel needs to realise that there is a right way of constructing a program and a wrong and I am sorry, opening up VS IDE without thinking about the whole picture is a stupid way of writing a program."
He does realise this. Take a look at the other articles on his site which relate to software design. He'd be the last one to advocate you just opening up VS and beginning to code.
"The UNIX way, creating a small core then building the interface ontop of it is the correct way of laying up funcationality where as Microsoft and Windows programmers have this addiction that they *MUST* ram every piece of functionality into one big uber executable."
That happens in the Unix world as well (e.g. some CLI based programs are like this and probably should be broken down into separate executables which have more specific functionality). Just because you are in one camp or another doesn't automatically mean that you will be able to properly design a program.
"For example, we have gecko which was developed on this. Small core with an interface on top. What is the net result? the net result is that the core can now be re-used in numerous other products. That is how software should be written."
IE is based on a separable core engine as well, which a lot of programs embed these days. Same with the Microsoft Jet DB engine.
It is interesting to me that Windows people do not realize that Windows is a nightmare for a lot of people. I use Linux and KDE almost exclusively ( I only use KDE/Linux at work and I have a MAC & Linux box at home ). Fixing problems in windows is hard because Microsoft assumes that the user is an idiot and should ne be allowed to know what is going on on his system. Windows hides everything, and when something goes wrong, whammy!! The user has no clue.
I have setup a Linux computer for my 70year old mother in law and she has no problems using it. It looks a lot like Windows 98/XP and it allows her to comnnect to the internet and do e-mail. Hey it works and she has no problems. This is what owning a pc is about. I think that KDE provides an very easy interface to learn and work with. All the of the KDE programs do what I want and provide the functionality I need. I think the writer of this article is ignoring all the work in Linux in writing this article. If you only look at UNIX and only UNIX, then his arguement may have some legitimacy. But I have not seen AIX, Solaris or UnixWare lately but they were bad before.
//Since I arranged all the buttons and their functionality in my WM, Windows is a hard to use environment to me.
Probably quite a difficult desktop for anyone not used to it.
//
Yah, it might be difficult for maybe <5% of the world's PC users.
A miniscule and unimportant minority may find it difficult.
It seems that all the people bringing up the Unix Haters Handbook seem to totally misunderstand it. Please, read it again, especially the foreword(s) and the history.
I believe we all use what is most familiar to us. This is why you can use MKS or Cygwin on Windows boxen (I'd be lost without them!).
It is the small, modular, tools based approach that UNIX culture takes to heart. I agree with Joel in that we value the developer audience the most. Since I'm a developer, I prefer UNIX (where regular expression support in many tools is common)... but when I'm just playing or doing "consumer" stuff... I love my Macintosh (I fell in love with Lisa back in 1983.. but couldn't afford her).
There are definately cultural differences between UNIX and Windows programmers. After all, you're talking about a bunch that put up with Hungarian notation for more than a decade. Only god can fathom the mind of people like that.
A Windows programmer is stuck at work until late at night until he can barely see or think straight, trying to remember whether the variable is called "lpszString" or "lspzString." Meanwhile, the *NIX programmer, able to leverage the sheer power of her svelte and simple API, manages to clock out at 3:30 in the afternoon, having plently of time left in the day to go clubbing in the city. The next morning, the Windows programmer drags himself in at 8:30 in the morning only to find that he can't understand any of the code he wrote the day before, and has to scrap it and start over. Meanwhile, the *NIX programmer saunters in around noon, gets herself a coffee, chats up the hunky secretary, and sits down to see what new coding adventures await her today.
So its obvious that *NIX programmers are so much better. *NIX programming is not only fun and easy, but whitens your teeth, improves your love-life, and gets rid of troublesome celluloid! Who wouldn't want to be a *NIX programmer?
"The UNIX way, creating a small core then building the interface ontop of it is the correct way of laying up funcationality where as Microsoft and Windows programmers have this addiction that they *MUST* ram every piece of functionality into one big uber executable."
That tends to be true anytime you start getting into GUI applications. And no, we Windows programmers do not ram everything into a single EXE. That's why we have DLLs.
Of course, with careful C programming and using the API directly rather than going through a toolkit, it's possible to ram everything into one executable. But it will be very small, NOT big. It might even fit on a floppy. And it will even run from that floppy because it doesn't have any dependancies.
One really nice thing about this article... The author actually stated in writing what most of us already know. Eric Raymond doesn't know what he is talking about when he spouts off about Windows. But cultural supperority ideas based on ignorance seem to be common in the GPL and FSF camps.
I really think that his holier-than-thou approach to using a specific OS needs some toning down. The majority of computer users just want to get a job(s) done with the least amount of hassle. Like most people, they consider whatever platform they are familiar using as being the best. However, for a professional to do this indicates not only a high level of ignorance but also a high level of arrogance. Yes each OS has its strengths and weaknesses and I do have a preference for the one I like best. That does not make me or the OS superior to all others.
I do not know any person who is a good 'Generalist', meaning that they are reasonably knowledgeable in all fields of human endeavor. The fact that a user is ignorant (note: different from being stupid) of the inner workings of an OS does not automatically place them in the 'not-so-bright' category.
Can any of you super experts who claim superiority over users who are not interested in the details of an OS take apart your car's transmission and replace a broken band? Or can you buy the really cheap chemicals for proper lawn maintenance or do you rely upon a company to prepare what you need (and pay them well for making that correct mix)?
Yes, a car driver is a better driver if they know something about how the car really functions. It can also dramatically reduce their dependency upon 'experts' to fix even the minor problems and save tons of money. The fact is that a large number of drivers just want to get from point A to point B safely and do not have the desire/time/money to spend understanding how cars function.
We all have a finite amount of time to spend doing and learning things Each individual must decide how to best spend this time. Many people opt to devote most of their time on their respective jobs/profession. Just because that does not include knowing the inner workings of an OS or programming does not make them 'lesser' people.
I enjoy reading comments where a possible problem or flaw is noted but no one is 'put down' because of it. I also like to hear other's opinions on OSs that I do not routinely use. Let's hope that the discussions can reflect tolerance for differences and some human understanding.
It is interesting to me that Windows people do not realize that Windows is a nightmare for a lot of people. I use Linux and KDE almost exclusively ( I only use KDE/Linux at work and I have a MAC & Linux box at home ). Fixing problems in windows is hard because Microsoft assumes that the user is an idiot and should ne be allowed to know what is going on on his system. Windows hides everything, and when something goes wrong, whammy!! The user has no clue.
Windows can be a nightmare for people that don't use it very often. It can also be a nightmare for people that aren't familiar with fixing it's problems. These people happen to overlap in that people that don't use it very often tend also to not be familiar with fixing it's problems. It goes both ways, as an experienced Windows 'power user' or administrator that doesn't spend much time with Mac OS or *nix would find it hard to fix things on those systems for similar reasons. Windows doesn't hide anything any more than any other operating system.
I have setup a Linux computer for my 70year old mother in law and she has no problems using it. It looks a lot like Windows 98/XP and it allows her to comnnect to the internet and do e-mail.
98 and XP look so different that I have problems diagnosing problems on pre-XP systems after 2 years of using XP at home, and occasionally have problems finding particular interfaces in XP because I have so few problems with it and tend to only remember the interface I'm looking for from 2k or 98.
Hey it works and she has no problems. This is what owning a pc is about. I think that KDE provides an very easy interface to learn and work with. All the of the KDE programs do what I want and provide the functionality I need.
It does, for some people, and part of that is taking cues from other GUI systems. In the most basic sense, KDE doesn't work much differently from older GUIs for UNIX (or Linux), but what KDE does well is provide an environment to build on, giving you a series of GUI apps and a toolkit to work with (or for others to work with), essentially doing what Windows and Mac OS had already been doing for years. As for getting common users to use a particular interface, I find that anyone that isn't afraid of computers can pick up any decent interface (even CLI) if someone is willing to help them. My grandparents (when they were alive, especially my grandfather who was older and had more problems with computers than my grandmother) tended to keep notes near the computer that detailed, step-by-step, how to do particular tasks, and they always knew that if something was wrong they could call my father or myself for help, and that because we helped them choose the computer we could do that, over the phone. Overall, when they did call, it usually meant they needed to write out another set of notes to perform a task they hadn't before, or they needed simple advice ('place your hand, flat with palm facing the side of the computer, about the same height as the CD drive, now smack it'). My grandmother was an amazing typist, and rarely needed help with the computer, regardless of which OS it was using (as we went through 5 or 6 different computers over the years, running DOS, GeOS, Win 3.x, and Win9x). I have no doubt that if we wanted to support a Linux system, we could put it on a computer for her and she could have used it.
I think the writer of this article is ignoring all the work in Linux in writing this article. If you only look at UNIX and only UNIX, then his arguement may have some legitimacy. But I have not seen AIX, Solaris or UnixWare lately but they were bad before.
His argument is equally legitimate with Linux, as it still has the same culture. Many forms of Unix have been adopting the various graphical environments common in Linux, including Gnome for Solaris in the near future iirc. The way *nix users handle GUI apps is certainly drifting around the center of the way applications were built before GUIs became popular, but there's still far more focus on developing for developers than developing for users, even from people that claim to be developing for users.
"After all, you're talking about a bunch that put up with Hungarian notation for more than a decade. Only god can fathom the mind of people like that."
We still use Hungarian notation, and the Windows API functions are still documented using Hungarian notation. And once you get used to it, it is great. (It requires a little memorization, but after using it for awhile, it becomes automatic. So no, you do not end up sitting up late at night trying to remember what the variable is called.
The NIX programmer, on the other hand, sits up late at night trying to figure out whether "mystuff" is a char, a wide_char, and int, a long, or a byte, because he doesn't have variable declaration (it's declared one of 28 different header files), and the variable itself gives no clue what type it is.
Hungarian notation greatly reduces type mismatch errors because it is immediately obvious when looking at any variable, what kind of variable it is, even if you don't have the variable declaration handy.
It has been modified somewhat and simplified in recent years, but it is still there.
Example, we don't use szCmdLine anymore to indicate a null terminated string that holds the command line arguments. Now we use lpCmdLine, which indicates a pointer to the command line string.
Even Microsoft realized that Hungarian notation was a stupid idea. The whole "type-mismatch" thing isn't a big deal because the compiler will catch type errors. Anyway, the type of an API variable in UNIX is implicit from the context. If we're talking about a string, its always of type char*, because we use UTF-8. If its a single character, its always an integer. Longs aren't used unless you know you want a 64-bit quantity on 64-bit machines. There is no such thing as a byte. And usually, we don't need to know the type at all, because we don't have to do stupid things like "foo.dwSize = sizeof(DDBLTBATCH);" Face it, you're alone!
I like a quote about HN I saw on the 'Net. "It helps prevent any accidental abstraction from creeping in!"
I don't consider having a computer crash due to a full c: drive from log files, vm, and user files as cultural differences. Neither do I consider having to reboot my OS because I install new applications/patches as cultural differences.
I know you were half being sarcastic..
But come on... "lpszString" or "lspzString"? Even if I have been writing code for 16 hours and can barely see straight, that one is obvious.
lpszString = Long Pointer Null String Zero terminated.
lspzString = Long String Pointer Zero terminated.
Zero terminated pointers and long strings don't make any sense, even I am working on 2 hours of sleep in the last 48 hours.
Tney might make sense to that NIX programmer however. The one that got out of work at 3:30 the previous day and went clubbing all night. :p
Oh, as for 28 header files? Its called modularity! Modularity means something that is *not* like Windows's giant "windows.h" POS. Windows is the only system I've seen that does something that stupid in its API. Oh, and if you're having trouble finding something in the UNIX API, you call "man <symbol>". Way easier than digging around in a single giant header file. If its not a standard UNIX API, just do "fgrep -R <symbol> /usr/include/*" to see where the symbol is declared. This works, because unlike in Windows, 3rd-party libraries have the sense to install their headers in a common directory.
"Zero-terminated pointers and long-strings don't make any sense"
---------------
Neither do long-pointers. What the hell is a long-pointer?
"The whole "type-mismatch" thing isn't a big deal because the compiler will catch type errors."
It will only catch errors if there is a possibility of loss of precision and you didn't perform an explicit cast. Take a look at this code:
#include <stdio.h>
int main()
{
int i = 'j';
printf("%c", i);
rerturn 0;
}
I gurantee that this code will compile and run correctly on any ANSI standard C compiler. So much for the compiler catching logic errors that result from assigning the wrong type of data to the variable.
"There is no such thing as a byte."
There isn't? What C or C++ compiler are you using?
ANSI standard C and ISO standard C++ both define a byte as an 8 bit signed integer.
"Even Microsoft realized that Hungarian notation was a stupid idea. The whole "type-mismatch" thing isn't a big deal because the compiler will catch type errors."
This wasn't the case 20 years ago, when the hungarian notation was invented. C compilers were very permissive about type checking.
"There is no such thing as a byte"
Yes there is. It is the unit for the size of the operator sizeof : http://www.parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.1... In C++, a byte is the size of a char.
"If we're talking about a string, its always of type char*, because we use UTF-8. If its a single character, its always an integer"
Well, on C maybe, but with other languages, it is not. in C++, a string is of type... string. And there a unicode characters.
"Neither do long-pointers. What the hell is a long-pointer?"
They are a relic from the days of 16 bit Windows, when Windows used a segmented memory model instead of a flat memory model. In those days, you had near pointers and far pointers, also sometimes call short pointers and long pointers.
They were a major headache to deal with, and and 32 bit versions of Windows eliminated them by switching to a flat memory model.
But you will still see them show up in documentation sometimes.
You won't be using any Windows API anymore in the future because Microsoft doesn't want you to build systems, instead you will build solutions that are integrated into a product line.
The only developers building systems are the programmers at Microsoft, that point was made in the article, and it focused on source code, however maybe this fact is diluted because even though a Windows programmer has no control over the operating system layer, and therefore his investment (in code) is volatile since he is at the complete mercy of Microsoft (one entity with absolute control of their product), I didn't see that point being established, instead I saw some argument about the source code's accessibility and openness making a difference. This is not a strong argument in my opinion because open source development does not yet gain a strong advantage from the open code, it is lead more by commercial interest.
ESR made a valuable contribution to the open source community, and I thank him for that because I would like to read the book. It saves a person a lot of time to be able to leverage the perspective of a Unix programmer when trying to understand the motivation for Unix. I'm glad that ESR has made this information available to everyone and I expect to gain some key insights.
I agree with those who pointed out that GNU/Linux is not Unix. There are other cultures growing in the free software world and just because it's hard to avoid the "classical Unix culture" when toying with Linux, doesn't mean that there are no other cultures.
This is the typical mistake "analysts" make when talking about Linux or free software in general: They assume that things don't change.
"Oh, as for 28 header files? Its called modularity! Modularity means something that is *not* like Windows's giant "windows.h" POS. Windows is the only system I've seen that does something that stupid in its API."
I didn't say there was anything wrong with including 28 header files. Only that without the variable name indicating its type, it can be hard to find out what type it is if that variable is declared in one of those 28 header files, and you don't know which one.
And fas far as windows.h, you do realize that windows.h is NOT an autonomous file right? It references many other header files. It's a convienence for programmers since it means I don't have to remember the header file that defines every single API function. But most of those functions are not actually prototyped in windows.h. They are prototyped in a different header file that windows.h references.
"You won't be using any Windows API anymore in the future because Microsoft doesn't want you to build systems, instead you will build solutions that are integrated into a product line."
Meaning what? That I can't build "solutions" using the Windows API? Sure I can. I can build anything with the Windows API that I could build using a toolkit like MFC. It might require more work using the API directly, but I can do it.
"Windows programmer has no control over the operating system layer, and therefore his investment (in code) is volatile since he is at the complete mercy of Microsoft (one entity with absolute control of their product), I didn't see that point being established, instead I saw some argument about the source code's accessibility and openness making a difference."
The same is true with Linux if they change the API, your code breaks. Sure, since you have the source code for the API, you can change the API itself so that your code works again. But wouldn't you be better off changing your code to work with the new API? Either way, you have to re-program something.
And as far as the Wndows API and my investment in code being at the mercy of Microsoft. The Windows API has remained incredibly stable thoughout the years. Sure, tons of new functions have been added, but most of the original functions are still there too.
1) I meant that there is no type byte. You were referring to bytes in a list containing other types: char, long, int, etc. byte isn't a type in C, but BYTE is a Win32-ism.
2) When you circumvent the type system, you're going to get type errors. Unfortunately, printf() circumvents the type system, but a *NIX compiler would have caught that because they usually do type-checking for printf(). In the end, its best to make sure your C code typechecks properly in a C++ compiler. That'll get you compiler-enforced type safety without any silly naming conventions.
3) Windows.h is still a monstrously huge header file, and it drags in all its sub-headers at compile-time. The fact that nobody else does something like that should clue you in that its a bad idea.
@David: In UNIX, in any programming language, a string is the moral equivilent of a char*. Even when you've got unicode characters, its still a char*, because the unicode format in *NIX is UTF-8, which uses 8-bit characters.
"1) I meant that there is no type byte. You were referring to bytes in a list containing other types: char, long, int, etc. byte isn't a type in C, but BYTE is a Win32-ism."
What do you mean there isn't a type byte? There most certainly is. And it has been available on every C compiler since K&R C.
"2) When you circumvent the type system, you're going to get type errors. Unfortunately, printf() circumvents the type system, but a *NIX compiler would have caught that because they usually do type-checking for printf()."
It's interesting you should say that, because the compiler I actually tested that with was GCC. No error, no warning, nothing. Compiled just fine. And it will on any other compiler as well.
Basically, there is nothing illegal about assinging a char to an int, and there are cases where there is very good reason to do so.
"3) Windows.h is still a monstrously huge header file, and it drags in all its sub-headers at compile-time. The fact that nobody else does something like that should clue you in that its a bad idea."
The only real drawback is that it increases the possibility that I am going to have a name clash with one of my own functions, because I am importing a lot of Windows function prototypes when I include windows.h.
However, in C you usually define function starting with a lowercase letter, and almost all of the Windows API functions are defined starting with an uppercase letter. So that elminates most of the possibility for a name clash as long as I stick to the convention in C of defining my functions starting with lowercase letters.
"What do you mean there isn't a type byte? There most certainly is. And it has been available on every C compiler since K&R C."
Oops. Nevermind. I take this one back.
I was mixing up C and Java.
Java includes a type byte to make up for the fact that type char is 16 bits instead of 8 bits.
Your right, there's not type byte in C.
Applications and operating system technical superiority are worlds apart. Why bring up something that has NOTHING TO DO WITH THIS ARTICLE?
This has to do with Windows vs. Unix on a cultural level, so I talked about it from that standpoint. As your comments illustrate, Unix users don't emphasize applications nearly as much as the actual OS.
If the operating system is poorly designed YOU the END USER suffer as a result, either in poor stability, poor security or simply your applications will not run nicely because the programmers from your favourite software supplier spend more time working around problems rather than trying to stablise and perfect their product.
So yes, technical superiority of an operating system IS important.
Actually, the technical superiority of an OS is only of secondary importance. Let me explain:
Just for the sake of the dicussion, let me use a simple & dumb analogy to illustrate my point. Let's say there's an app that lets me measure the distance between my ass cheeks that I use on a daily basis. This is my 'killer app' and basically defines the reason why I use computers. Now, the OS I use to run this app is horribly unstable (crashes once an hour, causing me to save my work every 10 minutes) and I have to work for half an hour each day to plug the security holes.
So, my friend tells me about this other OS that has none of the problems that my current OS has. But, upon doing some research, I find that there are no apps for this OS that'll let me do the ass cheek measuring. So, even if the technically superior OS is 10x more stable, 10x more secure, and 10x faster, since it doesn't support the app I require (or has a version of the app with only have the features I need), the benefits of this OS are completely irrevalent.
This is something that a lot of Linux zealots simply do not understand - they think "Well, if only Gnome or KDE were a little more refined or if the package managers were just a little better, Linux will be the ultimate Windows killer!" They failt to understand that most of us on the Win32 platform care about none of that, for the reason which I described above. If Linux had better apps for making music than Windows did, I'd be happy to compile every single one of my apps from source and use TWM as a window manager if I had to.
For this reason, I say it is impossible to have a complete discussin about the merits of an OS without talking about the apps it runs. Now, the technically superior OS might have apps that are much better than the less technically superior OS in certain categories, so the degree to which this is a benefit will differ from person-to-person. If you notice that two OS's have the same level of functionality in their apps in your favorite categories, only then would I look at the technical benefits of one OS over the other. However, I will always choose the OS with the better genre of apps that I use, no matter what technical the disadvantages are.
"3) Windows.h is still a monstrously huge header file, and it drags in all its sub-headers at compile-time. The fact that nobody else does something like that should clue you in that its a bad idea."
Actually, though,. I think a lot of other people do that. Example, if I import GTK.H, I've imported a truely massive number of function prototypes. Same is true with WX.H).
As a general rule, when circumventing the type system, you are only going to get errors when there is the possibility of loss of precision, and you don't perform an explicit cast.
None of the following will produce errors:
int i = 4000;
double d;
d = i;
int i = 'd'
char a = 10;
In all these cases, I do not risk losing precision when doing the assignment, and the compiler automatically promotes the value I am assiging to the type of the variable that I am assigning it to. This won't cause compiler errors, but it can cause logic errors because you can assign the wrong kind of value to a variable (logically) and the compiler will not complain.
This however, will produce an error:
double d = "5.5";
int i;
i = d
I can't do that because I will lose the decimal portion of "d".
So I have to cast it:
i = (int) d;
But that is only time the compiler will complain is if I attempt an assignment that will result in loss of precision. If there won't be any loss of precision, the compiler will silently promote the value to the type of the variable it is being assigned to.
You might be able to use -WALL and change this behavior so that the comiler will warn if it performs an automatic promotion, but it still won't generate an error, as this is not an error. It will just print a warning. But by default, compilers, including GCC, do not even warn about this type of thing.
byte is defined in the C standard, 3.6#1.
5.2.1 has all the definitions that are relevant to bytes and character sets.
6.2.6.1#3 and 6.2.6.1#2, along with note 40, define more precisely the relationship between bytes and C types (essentially, an unsigned char is a byte).
bytes aren't guaranteed to be 8-bit, they are guaranteed to be at least 8-bit. There is at least one embedded RISC CPUs whose compiler defines bytes as being 32-bit (and all other basic types, BTW).
A few comments have been made saying the user doesn't care what operating system is being used as long as work can be accomplished. Well, everyone wants to get their work done without hassle. Programmers, business people, scientist, artist, and all the other people that use a computer would like to get their work done.
It takes stable and efficient applications to get the work done. But those stable and efficient applications won't do you much good if the operating system is unstable and not efficient. So, in some respects, computer users should care about the operating system their computer uses.
Some people think of Unix/Linux/BSD as having to always use some command line text editor to change some configuration file just to use an application to get work done. It is not true. That is like saying you have to first go into the Options menu of a Windows based application to make changes before you can use it. I have found that Notepad works just fine without changing options and the same goes for Unix/Linux/BSD applications. Windows and Unix are the same in that you only have to configure the operating system once, after that you just get your work done. It is just as easy to do word processing on Windows as it is on Unix.
The biggest problem Windows has is it is self centered. Unix seems more friendly to other types of environments.
Unfortunately, computers are not mind readers. Anyone using a computer will have to learn how a computer does things. A computer needs to be told what to do and whether you tell it through a GUI or through CLI doesn't make much difference. But the computer user will have to know the commands the computer uses in order to tell the computer what to know.
If you want to copy files, you have to tell the computer what files, where those files are, where you would like to copy those to, and you have to use what ever coomand the computer uses for copying. This doesn't happen by magic. Some new computer users do not seem to know this.
Win32 has been stable, but I don't know if it is going to be accessible anymore, because MS want's you to program solutions through a new software layer (I'm sure you know which one). You will not be able to implement system, but rather solutions that target a flexible product line.
If Win32 is stable, which I agree, how is X not the same? With Linux I will always have control over the operating system layer, from which I can implement a system. There is no vendor that can close of the system interface and force me to be a solutions developer or a myraid of other things.
The solution on Linux is no more stable than on MS Windows, but that's fine because this is the commercial domain and a vendor has to profit by locking in the customer just the same as they have to do on Linux.
Open source should focus much more of the source code. I admit that it is not a leader yet, because it needs to discover it's competitive advantage through which it can be a leader in a way that a vendor can not compete. The advantage of open source code has hardly been realize. I know right now though that I do not want to be controlled by one entity but I want a decentralized platform which encourages competition through specialization and rewards the innovators rather than consumes their ideas. As a programmer I want to be rewarded for my ideas and I want to have the control in order to realize them.
...is just about the stupidest thing i've ever heard. Why not "everything is a data-stream", much better don't you think?
1) @Anonymous, @JBQ: Byte is most definately not in C. I can't do "byte i = 0;" unless I "typedef char byte;" It might be defined as a concept, but there is no type 'byte' like there is 'int'. Or did I misunderstand the statement?
2) @Anonymous: None of your examples are type errors. That's not a circumvention of the type system, but rather an automatic conversion. Those things are legal in C++ too. The main problem with your original printf() example was that printf() is not type-safe at all. No notation will help you when you're dealing with type-unsafe features.
3) Did you try compiling with -Wall?
t takes stable and efficient applications to get the work done. But those stable and efficient applications won't do you much good if the operating system is unstable and not efficient.
It would be much better than using a more stable OS that does not have the applications you need to get work done. Some people require more/different things than others, so having the mindset (whether using OSX, Windows, Linux, whatever) that since it has everying you need to get work done, then it's also sufficient for everyone else is the wrong kind of assumption to make.
I mean, some peopel are having a discussion about what a byte actually is. Great for programmers, but the rest of us could give a rat's ass.
In order to have more applications for Linux, and more specialization, than Linux has to work on improving the foundational architecture, so that more vendors can base their product line on the Linux platform and we can have a competitive environment.
I think that the byte size is a Java type. And in Java, the byte size is the same size on all platforms for which a JVM is implemented. This is not true for C built in types because it depends on the processor family. It is possible though to use the byte type on Linux (through Java).
On Windows you couldn't give a rats ass even if you wanted to. You could only give a rats ass if Microsoft allowed you to do so.
"2) The main problem with your original printf() example was that printf() is not type-safe at all. No notation will help you when you're dealing with type-unsafe features."
Yes, it will, because it will keep me from inadvertantly doing something like this:
printf( "%d", myVariable);
Suppose tha myVariable holds a char value, and I intended to use a different variable that held an int value. This will still print a numeric value, but will not print what I want. It will print the ASCII value of myVariable.
But now try this one:
printf( "%d", chMyVariable);
Thanks to the hungarian notation, I am more likely to catch the significance of what I am about to do because I know instanty that szMyVaiable is not an integer, but rather a char variable.
"anti-binary formats and anti-closed"
Aren't you mistaking UNIX and Linux ?
"Win32 has been stable, but I don't know if it is going to be accessible anymore, because MS want's you to program solutions through a new software layer (I'm sure you know which one). You will not be able to implement system, but rather solutions that target a flexible product line."
True. But MS is not going to drop the Windows API because that would break millions and millions of lines of existing code, and it would stop people from upgrading WIndows because none of their existing apps would work anymore. And businesses aren't going to spend the millions and millions of dollars it would require to reprogram all of the applications that use the Windows API.
Visual Studio, for example, still allows you to write unmanaged C or C++ code if you want to.
"If Win32 is stable, which I agree, how is X not the same? With Linux I will always have control over the operating system layer, from which I can implement a system. There is no vendor that can close of the system interface and force me to be a solutions developer or a myraid of other things."
I'm not saying that Linux is not stable. I'm saying that realistically, you are in the same boat as Windows programers. You are at the mercy of Linus Torvalds, Red Hat, and other such entities that make decisions about the direction of Linux. For example, suppose, for the sake of argument, that Linux decides to drop the existing Linux API, and completely rewrite it with something that resembles a .NET system. And that customers all upgrade to this new version of Linux that uses the .NET style programming. You are in the same boat as the Windows programmer. You have to re-write all your source code. The only difference is that you have the source code for the Linux API, so if you wanted to, you could re-write the API so that it would support your existing apps. But that would mean your apps would only run on your system. And it would also probably be more work than simply re-writing your application.
So my point is that if something like this happens, having the source code for the API doesn't really do you much good unless you want to re-write the whole thing.
LOL, I'm hoping that you will remember what you just said.
""rerturn 0;
}
I gurantee that this code will compile and run correctly on any ANSI standard C compiler.""
Err...no.
Unfortunately no amount of variable type-checking can eliminate typos :>.
On another note, my opinion on hungarian notation is that it is an okay solution for the domain in which it was intended. The problem is that the hungarian notation will be different in each domain that the aliases are specialized for, because they try to describe the behavior (the functions) and not just the type.
Microsoft wouldn't use Hugarian notation if they had to do it again. They would use objects implemented in an object oriented language. Rather than object based structures and aliases that desribe the objects and the type of the object.
he seems like some sort of troll to me (with his own view BLOG hehehe).
He seems very intent on bashing UNIX (and UNIX like operating systems). Are there command line geeks out there ? yes of course all OSes have them. Are they the majority? In previous times yes, today no. The proliferation of various unices (linux distros, macos x, solaris, IRIX etc) is due to (1) stability and (2) usability. Do you think that people would flock to linux as an alternative to windows if they had to use the command line all the time? absolutely not! The embetterments of GNOME and KDE are good examples of the fact that most mainstread unix users cant go without a good GUI. You can accomplish much with a commandline, but you are dependent on (1) memory and (2) good typing skills ;-). GUIs make things faster and more intuative and unix like OSes have joined in (a long time ago).
What seems to me to be the dividing line between windows and unix IS indeed bi-culturalism. UNIX people want freedom to experiment and tinker if they wish. They want to not be shackled by monopolies such as microsoft, and they want stability which is what is offered by the unices of the world. Windows users on the other hand are comfortable where they are, they are content with having one provider and this lessen the choices that they have to make in order to maintain their system (either for personal use or server use), and when something hits the fan (i.e. viruses or worms) they can blame M$ for not releasing patches fast enough or making vulnerable systems.
Unix...Windows.
Each one is a toolbox.
Unix has it's box filled with a socket set.
The Windows toolbox is filled with wrenches.
So I have a car to put together.
I use both toolboxes.
The other guy down the street only has a Unix ToolBox, so that's what he uses to put his car together.
People seem to bicker no matter what the dividing line is...nations, religions, color, etc. Now the OS is included in there.
Sheesh. Quit trying to defend one against the other as better. They are simply different ways of doing things, each one probably better at some tasks than the other, but both are useful in their own respect. This bickering is getting old and seems very immature.
And I'm sure the bickering will continue
"Win32 has been stable, but I don't know if it is going to be accessible anymore, because MS want's you to program solutions through a new software layer (I'm sure you know which one). You will not be able to implement system, but rather solutions that target a flexible product line."
I think this is sort of like saying that Sun Micrososystems would eliminate the Solaris native API in favor of forcing programmers to use Java. That's obviously not going to happen. And it's not going to happen with Windows and .NET either.
However, I do think that Java and .NET will collectively end-of-life C++ as a general applications language. This won't be because Sun or Microsoft force the issue, but because programmers can be 5 to 10 times more productive in Java and .NET than in C or C++. So I think that the natural course of evolution suggests that programmers will write more and more new applications in Java or .NET, and that eventually, we simply won't see C++ being used as a general applications language anymore.
I rarely agree with Eric Raymond, but I do agree with him when he says that the days where it makes sense to manage your own memory are gone. It's far better to give up a few CPU cycles and save months of far more valuable man hours on programming.
Java has already pulled off an extremely successful coup at displacing C++ as the king of programming languages. Java is more popular and in greater demand than C++ these days. And I think that trend is only going to continue.
As far as .NET, Microsoft may have done too little, too late. I'm not convinced that .NET can break the power hold that Java already has in Windows, as well as other platforms. And Microsoft can't make .NET the only platform that will work on Windows unless they want to end up back in court.
Language developers learned an important lesson from C and C++. And that is that for a programming language to really survive and become dominant, it has to be cross-platform. Java is very cross-platform, and that is one reason it has become so popular. I want to be able to share the same code base between my Linux server, my Windows desktop, and my Palm PDA. Java lets me do that.
.NET, on the other hand, is very NOT cross-platform. The cross-platform capability of .NET is vaporware, and I think it will remain that way for the forseeable future.
So basically, I have my doubts about .NET. History has taught us that programming languages need to be cross platform to survive and prosper. And .NET is about the least cross-platform framework I can think of. That and Java is so firmly entrenched already, having even displaced C++, that I don't know if .NET can break the power hold that Java has.
Windows users on the other hand are comfortable where they are, they are content with having one provider and this lessen the choices that they have to make in order to maintain their system
Dude, how do you say this lessons choice? Sure, I don't have 2,000,000,000 distros in which to choose from, but I see this as a good thing.
As for apps, right now I have 60+ apps installed that I use at least once a week, and perhaps 10% of them are actually MS apps. Need an office suite? Hell, there's gotta be at least three dozen of them, including the precious Open Office. Same with web browsers, email, FTP, whatever.
However, I do think that Java and .NET will collectively end-of-life C++ as a general applications language. This won't be because Sun or Microsoft force the issue, but because programmers can be 5 to 10 times more productive in Java and .NET than in C or C++.
I've been hearing this for the greater part of a decade now (at least in regards to Java) yet we continue to see the majority of code continuing to be written in C++ and C. Certainly there were performance issues for awhile, but now Java and .NET applications no longer run obnoxiously slow. So why do we see them limited primarily to internal programs used by businesses, as opposed to widely consumed retail software? I'm not going to venture a guess myself... but I'd simply like to point out that I don't see C++ in any danger of going extinct any time in the near future.
It's possible for MS or Sun to EOL C++ on their products (Windows and Solaris) however this will not happen on Linux because it is impossible, no one vendor controls it.
Actually though, MS is making a Standard compliant of C++ to run on .Net. At any rate, I myself could care less!
The other theory and the one that I agree with, is that Standard C++ will not be replaced until a language comes along that is more powerful and feature rich. The product line (Java and .Net) is very productive for a certain type of application (solutions) but it is not ideal for systems implementation. The core langauges of these middleware platforms is not as powerful as the C++ core language, but certainly the supporting libraries are far more extensive. I discussed this with Bjarne Stroustrup and he expressed some agreement that the Java goal was to destroy C++ or make it a fringe language, yet comparing Java and C++ will always leave one unsatisfied. Java is tired to a product line strategy, and Standard C++ is a light weight langauge definition which the original author looked at as systems implementation language. Give me a Standard compliant C++ GUI library or middleware system and I'll use it any day over anything, but I want more than just a wrapper even though Stroustrup claimed that there was no evidence that a wrapper degraded performance over the native toolkit being implemented in C++. But I disagree with him, and he doesn't understand Linux.
Anyway it appears that most of the things that you value are more easily accomplished with Linux rather than Windows. Linux needs to make the right promises. Linux could easily tell everyone, okay, if you want an API to base your solutions or even systems on (or one for each) and you don't ever want anyone to take that away, than we can give you an architecture that will make that possible. On the other hand MS Windows can't do that, because they have a product line that they have to push in order to drive sales. Do not look on the past deviances from the vendors ideal, as your foundation. It is not logical.
...in other words, MS does not want you to use their system interface, they want people to use .Net. The reason for this is because .Net is more flexible in it's support of a product line and it allows the vendor to retain control over the factors of production (the source code and derived research and development of the systems). With your .Net solution you can achieve productivity, generic data, an integrated specialization, however you can not become a software vendor outside of the control of the vendor that you rely on (Microsoft).
"So why do we see them limited primarily to internal programs used by businesses, as opposed to widely consumed retail software? I'm not going to venture a guess myself... but I'd simply like to point out that I don't see C++ in any danger of going extinct any time in the near future."
But remember also that the vast amount of programming projects are internal. There is far more internal software out there than retail software.
But part of the reason you don't see a lot of retail softwate being written in Java yet, is because most of that software is in maintenance mode. New versions are based mostly on old code, with changes, additions, etc. Rewriting from scratch is expensive. Old applications will continue to be upgraded in C++ and such, but new applications likely won't be written in C++.
...obviously when the API was still open we had QT, GTK+, Apache, etc, etc, etc, that were ouside of the control of MS. Not any more!
"you are dependent on (1) memory and (2) good typing skills ;-)"
This is absolutely *not* true. In fact, the opposit is true, because if your programs support being called from a commandline, you can write a simple script that calls the application with the settings you usually use.
For example, I'm using a tool named unison ( http://www.cis.upenn.edu/~bcpierce/unison/ ) to sync my laptop and my company's server. If I use the GUI version, I have to manually start the GUI and make at least a few mouse-clicks to get things going.
Since I'm using it to sync different directories, there are a few settings that differ per directory. If I would use the gui, I would have to open a different config file for every directory I would want to sync.
Enter the command-line. I wrote a simple script "sync_server" _once_, where I had to figure out all the command-line options. And yes, that took a few hours.
But now, I can just enter sync_server and off it goes. Once I'm convinced I have all the right options, I can easily automate the process by letting cron syncing my stuff every night.
So, in the end, I don't have to remember anything and I don't have to type anything too, since cron handles that for me. _that_ is the power of the command-line & scripting.
And there we're back to the cultural thing. Unix culture tends to slightly adapt the system to your needs, while Windows culture tends to accept the way the system works and adapt your way of working to match the way the system happens to work.
Both are fine, as long as you get your work done. For me, it is just more effective to use the command-line, so I can automate my tasks to a much further degree then I could do with a GUI.
And yes, I'm the kind of guy that as a child always opened my toys to look how they worked inside. Drove my parents nuts. When I was 14, I was able to just about completely open & rebuild the engine of my Solex ( http://www.gironet.nl/home/jspiertz/historie.htm ).
And yes, I know how to re-install a gearbox in a car. I completely restored the 1970 VW Beetle my wife drives; rebuilt the thing from the ground-up.
And yes, I fix the dish-washer and washing machine myself because it is much cheaper.
I just like to know how the things I use work inside and be able to fix things if I need to. And that`s not just limited to computers.
I always like the example of my fathers ice-cream machine.
My father owned a restaurant, now run by my brother ( http://www.koprensmorre.nl ), and there we had an ice-cream machine. At some point, it broke. Called the supplier. "Sorry, that type is over 5 years old. We don`t service those anymore". And then you`re talking about a machine that costs around 1000 Euro to replace.
So, he just went ahead and opened the thing. It turned out that it only needed a new bearing and the machine happily worked for a few more years, costing no more then 50 Euro and a few days of fiddling. And of course, you now know where to look for if you want to buy a new icecream machine... (i.e. bearings don't like a regular supply of sugar water in the long run)
That's the same thing. Most people would have just bought a new machine. But then again, there would also be a lot of people that would have tried to fix it too.
Both approaches are fine. It just happens to be that the Unix culture seems to fit me better.
On those products (Solaris and Windows), Standard C and Standard C++ will continue to be used to implement the systems (by the R&D teams at Sun and MS), however all of the solutions that are specializations of the Java and .Net libraries are only written in Standard C and Standard C++ by extension (through Java and .Net).
Java will never dominate Linux because it can't. Linux is not a product, it's a platform. The factors of production are decentralized across the community. No one entity can control the direction of a platform, especially with a decoupled product line. On the Windows product however, you can be sure that MS will dominate it and whoever uses it will be dominated.
"It's possible for MS or Sun to EOL C++ on their products (Windows and Solaris) however this will not happen on Linux because it is impossible, no one vendor controls it."
This change will happen in Linux too. It won't be forced on anybody. It will occur as a natural process of evolution because of the amount of time that can be saved using Java, .NET or even Python.
In Linux, for those who have philosophical problems with Java, I expect to see more and more apps written in Python, which is one of the languages often compared to Java.
"The other theory and the one that I agree with, is that Standard C++ will not be replaced until a language comes along that is more powerful and feature rich. The product line (Java and .Net) is very productive for a certain type of application (solutions) but it is not ideal for systems implementation."
For systems level programming, C++ will not be replaced for some time. But for general application development, it is well on its way out.
"The core langauges of these middleware platforms is not as powerful as the C++ core language, but certainly the supporting libraries are far more extensive."
I think that depends on how you define power. The core Java and C# languages handle memory management and garbage collection for me. I don't have to mess around with pointers and such, and Java will automatically take out the trash during periods of relative inactivity. To me, that makes it more powerful than C++ because it can things for me that C++ can't do. And in so doing, it allows me to focus more on the problem domain of my application itself.
"Anyway it appears that most of the things that you value are more easily accomplished with Linux rather than Windows."
To me it doesn't really matter. What I value is being able to solve problems in my specific problem domain. I am not a programmer by trade. I am an ecologist. I develop specific applications within my problem domain of solving ecological problems involving animal behavior, or population biology.
Whether I do that on Windows or Linux isn't really important to me. Both platforms will perform the tasks equally well. But Windows happens to be the dominant platform in my field. Most of the people who will be using my applications are running Windows. So I develop for Windows. If that changes in the future, and Linux becomes popular in my field, then I will start developing for Linux instead of Windows. It doesn't really matter to me. I develop on whatever platform my applications need to run on. And I don't really have a lot of control over what platforms my applications need to run on. So I don't make the decision. I just go with what's popular, and don't have a choice in the matter.
So you said that MS will never undocument the API and effectively close it and force people to upgrade? Are you Bill Gates than? Do you have the authority to make that decision or are you just guessing.
"Java will never dominate Linux because it can't. Linux is not a product, it's a platform. The factors of production are decentralized across the community. No one entity can control the direction of a platform, especially with a decoupled product line"
But you completely fail to take into account that people are going to use the tool that makes them most productive. Yes, a langauge can dominate Linux. And it can do so because it allows programmers to obtain very high levels of productivity.
Unless you just program for a hobby, and productivity and time (which translates into money) is not important to you, than the usefulness of a computer language very much can make it dominate a platform.
"So you said that MS will never undocument the API and effectively close it and force people to upgrade? Are you Bill Gates than? Do you have the authority to make that decision or are you just guessing."
No. I'm saying they won't because they cannot afford to. Microsoft cannot afford to obsolete litterally trillions and trillions of lines of existing code. If they did so, corporations would not buy the upgrade to the next version of Windows because it would break all of their existing applications and they would have to rewrite them. Do you know how expensive that is?
Remember that the average corporation is still using 1970s vintage COBOL code for many applications. Why? Because it costs to much to rewrite complex applications in a new language.
"Microsoft will discontinue the Windows API and not document it anymore." is just open source FUD. Microsoft has not made any statements to the effect that they intend to phase out the existing API. Download the latest Microsoft Platform SDK, and you will find that the API is alive and healthy.
I think C++ will never completely vanish, but it might loose ground on the application level.
However, I think that will only happen if you don't have to throw your perfectly good and debugged code away.
Now I don't know much about jave, .net of even python, but I know that python interfaces quite nicely to C++, given that bindings to, for example wx and Qt exist.
Therefore, I think python has a very attractive advantage.
As I said, I don't know the details of .net, but I do remember that the CLR had some limitations that if I remember correctly make writing templates and multiple inheritance quite difficult, which is why these are not in c#.
That means that the c++ version will also be crippled for the time being, so it probably is not a real alternative for some time to come.
(1) comment about scripting
the comment on scripting is well received. bear in mind though that scripting is something you need to learn in order to use. a GUI is more convenient for the average jow who cares not about the internals of a computer (should users know more? yes, but they dont)
(2) comment about choice (by the dude?)
Choice is more about having your choice of OS, your choice of window manager, your choice of service. My comment was not going towards what apps are available to choose from.
"Now I don't know much about java, .net of even python, but I know that python interfaces quite nicely to C++, given that bindings to, for example wx and Qt exist."
Python has an excellent interface to C and C++. In fact, one can write an application in Python, and then when they find bottlenecks, simply rewrite the specific module that is causing the bottleneck in C or C++, and drop it in. Since Python treats Python modules and C / C++ modules the same, no modifications to the code that calls the module are necessary. The C/C++ modules is basically a drop-in replacement.
But like Java, Python compiles to byte code, so it not an interpreted language in the traditional sense. So often, one finds that the routine written in Python is fast enough, that it does not need to be re-written in C or C++.
The main reason I don't use Python a lot is that I don't like the syntax. Old C and C++ jockey that I am, I need my braces and semicolons. Python used intentation for delimiting code blocks (It does it in a natural way though, unlike the nightmare that was FORTRAN 77.).
There's nothing wrong with Python's indentation for delimiting code blocks. I just don't like change. :p
I happen to like Java, but garbage collection is not part of the core language. I am talking about the features of the Standard C++ (ISO 1987) langauge definition. It is a broader definition than the Java language specification.
One of the largest contrasts is that C++ is multi-paradigm and Java is focused on OOP.
Ofcourse Java is more productive and less error prone for solution implementation than C++ (??? makes no sense though ???). In addition the Vendor solution that you create integrates with the rest of the Vendor product line (for example the services and servers of the Vendor). It appears that one of their goals is to make data generic between your Java solution and mine or the one of the server and the one on the workstation, it's one of the things that will drive web service interoperability.
I see no conflict between Linux and Windows here. I would like to see a thriving competitive environment exist as companies base their product lines on the platform (Linux). It is to a companies advantage to adopt a software layer above the operating system layer to base their product line on because it is more flexible, allows companies to have more control.
Think of the operating sytem layer as the melting pot. This is the conflict between Windows and Linux or else Solaris and Linux or else Unix and Linux. Since Linux is an open source platform rather than a product, than control over the operating sytem layer is decentralized. In other words it will be a foundation for system implementation. A foundation or infrastructure from which ANY company can base a product line. So that the company that innovates will be rewarded for their innovation rather than absorbed by a monopoly that controls the product.
It is important to understand why people defend Linux, we'll most people don't know why, but they feel something, and it's their freedom that they are defending, and that they lost and want back, there is a broader issue. Freedom is the only standard that allows the reward of innovation to be returned to the innovator, because it is out of an idea that the innovator will form a market and become a vendor if it comes to that, but their idea will be a unique system, and not just a collection of specialized vendor objects (inherited class instances) for a product line. That unique idea will be a generalization born out of the architecture that promotes organic development.
"As I said, I don't know the details of .net, but I do remember that the CLR had some limitations that if I remember correctly make writing templates and multiple inheritance quite difficult, which is why these are not in c#."
I don't know much about C#, but Java doesn't allow multiple inheritance at all. But Java has interfaces, which get around this and provide the same funtionality in a way that is type safe and doesn't have all the problems that multiple inheritance has.
You should move your programs to Java because the Win32API is only going to be narrowly accessible in Longhorn. There have been numerous articles on this already here on OSNews. The API will only be about 20% of what it was in XP.
Me neither. That's probably why I never like IDE's, too
I can get my job done perfectly and cross-platform with vim, gmake and gcc. Why change?
Oh, and btw, I do agree with you on the Python syntax.
While it does force a sort of standard look of the code, which makes it easier to grasp, you can't use indentation to clarify your code as much.
For example, I like to write simple error handling and other checks on a single line like this:
if ( !ok() ) { printError( "oops!" ); return; }
This way, it is clear that is just something unimportant for the big picture, but it has to be there.
If you`re forced to use indentation, you can`t do this anymore, which would make the code a bit less readable.
"It appears that one of their goals is to make data generic between your Java solution and mine or the one of the server and the one on the workstation, it's one of the things that will drive web service interoperability."
Well, that's what XML is for, which even Microsoft is adopting. In fact, Microsoft has plans for moving an XML designed user interface system, where you will basically design the user interface to your application by writing XML code. (See www.thinlet.com for how such a system exists for Java).
Of course, if I develop my solutions in Java, then I don't have to worry about a lot of the "will my code still work in the future?" questions. Even if the pendulum in my field does swing towards Linux (which is a very real possibility because UNIX is traditionally strong in scientific environments, and also because many projects operate on tight budgets), then I will have a very easy transition to the new platform since my apps will already run on Linux, and I will be able to continue to develop new apps the way I have always done, without having to learn new APIs and such.
"It is important to understand why people defend Linux, we'll most people don't know why, but they feel something, and it's their freedom that they are defending, and that they lost and want back, there is a broader issue."
I don't have a problem with Linux, or free software. And I understand why people defend Linux.
What I do have a problem with, is the people who think that Linux can meet every single need of every single user, which right now, it simply can't. I also have a problem with the extreme versions of free software philosophy which want to basically make closed source commercial software illegal.
"You should move your programs to Java because the Win32API is only going to be narrowly accessible in Longhorn. There have been numerous articles on this already here on OSNews. The API will only be about 20% of what it was in XP."
I am moving towards Java. It makes more sense for me because I can a lot more done in the same amount of time. It also allows me to be ready to switch platforms if I have to. (Like I said, there's a real possibility that Linux could take root in my field).
The main reason I haven't used Java in the past is because of budget constraints, we often use some pretty antiquated hardware, and Java simply didn't run well on it. But the hardware was so antiquiated, that we have pretty much been forced to upgrade. So Java performance isn't a big issue anymore.
"You should move your programs to Java because the Win32API is only going to be narrowly accessible in Longhorn."
Java is not the only option. wxWindows and Qt are both very nice, cross-platform toolkits that have bindings to several languages. Qt, for example, only needs a limited number of functions from the win32 api and they will do anything they can to make sure their stuff will work on Longhorn.
And there is no way MS would make this impossible, because that would also make 99% of all current software obsolete which would cost them a *lot* of customers.
I am getting more and more convinced that the future is not .net and not java, too. I think the future is cross-platform toolkits written in C++ with bindings to several languages like python, which will make the whole OS issue basically irrelevant.
Oh, as for 28 header files? Its called modularity!
Not really, the C library still globs all the code together that assorted headers provide an interface to. While breaking the headers apart may speed up compile times, they can create a large headache for both programmers and software users. One notable example is all Dan Bernstein software such as qmail 1.03, whose standard distribution doesn't build on modern Linux systems because it fails to include errno.h
Modularity means something that is *not* like Windows's giant "windows.h" POS. Windows is the only system I've seen that does something that stupid in its API.
I now begin to wonder why I'm responding to this post, as clearly you have some very misconceived ideas about programming. The only disadvantage to placing everything in a single header file is the time required for the compiler to parse it every time.
Oh, and if you're having trouble finding something in the UNIX API, you call "man <symbol>". Way easier than digging around in a single giant header file.
Why would Windows programmers dig around windows.h when there's http://msdn.microsoft.com ?
"Qt, for example, only needs a limited number of functions from the win32 api and they will do anything they can to make sure their stuff will work on Longhorn."
Qt isn't really an option because the Windows version is about $2,000 per license. That's way out of my price range.
I've had problems getting wxWindows to work with mingw, which is the compiler I usually use on Windows. It has to do with getting a ton of error messages in the wxWindows header files about attempts to redefine constants and such. I haven't figured out what the problem is.
Some open source people want to eliminate closed source, and some closed source companties want to make non Microsoft products illegal.
I think that vendors should be able to charge money and that Linux is only the platform. The idea of having an open source platform means that no single competitor has control over the entire direction of the platform, because than it wouldn't be a platform, it's a product like (Solaris, Windows, Mac, etc). So I defend Linux because I want to have a platform there because maybe I want to code in C still or maybe I want to implement a system rather than a specialized vendor solution.
Yes, XML is one of the key technologies for generic data, so are the framework objects, but it's curious that the vendors focus on data and not 'the code' :+)
I'd like to see Linux expose the research and development of the core operating sytem libraries, and than build a knowledge base and challenge those systems. I want a more organic platform, kind of like an organism. Maybe a scientist like you can relate. Which is stronger, the plant we like to have or the weeds.
"Why would Windows programmers dig around windows.h when there's http://msdn.microsoft.com ?"
Well, there you have the culture difference again. I, for example, like to grep tough header files and look inside how it really works. Usually, that solves my problems much faster then browsing the web.
On windows, however, this is much more difficult. The api is really coming at age and is full of macro's which are difficult to read and grasp. So, then I also refer to google and the web. I usually need to see an example before I can understand how I should use it.
On the other hand, I use the online Qt documentation also a lot. This has been written using a documentation tool ( like doxygen: http://doxygen.org ) which results in a very nice, cross linked online documentation system.
"I want a more organic platform, kind of like an organism. Maybe a scientist like you can relate. Which is stronger, the plant we like to have or the weeds."
I don't know. An organic platform that behaves like an organism sounds a little to much like we could end with The Matrix becoming a reality. :p
Its not just the fact that the compiler needs to reparse it each time. Its also the fact that anytime any of the sub-headers changes, all files must be relinked and recompiled. Also, its terrible from a code maintainence standpoint --- pretty much every book on programming tells you not to make monolithic files. Headers should be modular, with each one collecting closely related interfaces. Look at the BeOS or Qt APIs for how it should be done. The Windows APIs are just not good examples of interface design, no matter how you slice it.
Why would you go looking around in "28 headers" looking for the type of a variable? My point was in response to Anonymous, you missed the context. Of course, that piques my interest. Why shouldn't programmers dig around in windows.h? Maybe because its nearly unreadable? With all the hungarian notation, weird typedefs, non-standard calling conventions, etc. UNIX programmers have no problem digging around in the standard headers --- after all, they're the definitive reference of the API. Its not just windows.h, either. Windows programming (especially MFC) is just full of opaque code. Have you ever actually tried to read some of the files Visual Studio generates for you?
If you choose Java to write your solutions, than it must have been a stretch going from Win32 to Java.
Someone basing a product line on Linux could implement a software layer (rather than a wrapper) virtual machine that interprets an intermediate language compiled from Standard c++ and a supporting framework. Than Standard c++ would be back in business and it would have similar infrastructure as Java. I'd like to see it happen. It would be interesting to lay out all of the classes that you would want to support in the framework. You could learn from Java and .Net but focus on a slightly different library architecture.
Java/C# people make me laugh. Yes, they can be very productive languages, but only because they basically do everything for you. Most Java/C# programs are a matter of stringing together library components. The languages themselves are nowhere near competitive with C++.
Also, I've seen a number of competitions of coding productivity in alternative languages vs C/C++/Java. Rarely does Java beat C++ in amount of code required.
Check out a study done by a guy at the JPL. It shows that when the language itself (rather than a library) is tested, Java is not only more verbose than C++, but slower than Lisp (hi Roy!)
http://www.flownet.com/gat/papers/lisp-java.pdf
There are languages much more productive than C++, but Java ain't it. Python is probably the most mainstream one that fits the bill.
I just hope that Linux doesn't end like the Matrix. Just from what I heard, I haven't seen revolutions yet.
"Qt isn't really an option because the Windows version is about $2,000 per license."
If you dig a little, you can still download the Qt/free version 2.?? for Windows for free.
Provided you don't distribute your code outside your company or distribute your software with source code, it is still a very nice toolkit and very useable.
With respect to MinGW, you have a little less luck. V3.1 and up compile out of the box with MinGW, but the older versions do not officially support MinGW.
This would mean that you'd have to backport the MinGW makefiles to V2.x, which could easily take you a week or so, _if_ you're more or less familiar with Qt's make system.
Another option would be to develop under cygwin for the time being because that supports the free X version of Qt, _but_ requires an X server to run your program. See: http://kde-cygwin.sourceforge.net/
As you can see, these guys are also working on a native port of the free Qt version, but no one knows when this will be available.
Objective C, while not generally more powerful than C++, is very nice in the specific domain of GUI programming. I hear Cocoa programming on OS X is really fun.
"If you choose Java to write your solutions, than it must have been a stretch going from Win32 to Java."
Well, it involved some relearning. But the speed of development more than makes up for it. For example, it takes about 100 lines of Win32 code using the native API to do what can be done in 5 lines of Java code.
I still envy the performance I can get from C and the Win32 API directly though. Fully funtional GUI applications that can fit on a floppy, use less than 10Mb of RAM, and load so fast, they feel like they were already resident, is pretty cool.
Oh, and as far as the Win32 API, it's being replaced by the WinFX API, which will be more powerful, and also safer.
"Also, I've seen a number of competitions of coding productivity in alternative languages vs C/C++/Java. Rarely does Java beat C++ in amount of code required."
I would love for you to show me some of those competitions and their results.
I have seen plenty of studies that show Java programs are on average, 5 to 10 times shorter than the same program in C++
Can you write a minimally functional Web browser in C++ with less than 50 lines of code? I can in Java
"Can you write a minimally functional Web browser in C++ with less than 50 lines of code? I can in Java"
This has much more to do with the libraries you use then with the langage itself.
I don't know if I could write it in 50 lines using Qt, but I could get very close.
I just pointed you to one! And yes, you can write a minimally functional web-browser in C++ with less than 50 lines of code. Just embed KHTML. There is a tutorial on IBM's DeveloperWorks. But that's comparing the library, not the language!
It takes 100 lines to do in Win32 what it takes 5 lines to do in any other API not designed by people while they were high. It takes screenfulls of code to just create a damn window in Win32!
"It takes 100 lines to do in Win32 what it takes 5 lines to do in any other API not designed by people while they were high. It takes screenfulls of code to just create a damn window in Win32!"
It takes 100 lines because the API is the lowest level of Windows programming (And I suggest you try it in XForms and I think you will find it takes even more code).
It takes 100 lines because scrollbars, for example, don't do anything in the API. You have to program the scrollbar logic.
And embedding KHTTP is cheating. Now do it without embedding an application that handles all of the work for you.
The library is whats important unless you plan on reinventing all the wheels.
"Check out a study done by a guy at the JPL. It shows that when the language itself (rather than a library) is tested, Java is not only more verbose than C++, but slower than Lisp (hi Roy!) http://www.flownet.com/gat/papers/lisp-java.pdf"
By the way... This is what makes me laugh. Because the comparision was done with Java 1.2!
In case you didn't realize Java 1.2 did not use JIT. So this comparision is quite unfair. Compare it with Java 1.3 or 1.4 and you are going to get quite different results.
But this is what most people do when complaining that Java is slow. They compare it with an old and outdated version of the Java runtime engine.
and one who has no real "preferred" development platform, as my projects are developed on Linux, FreeBSD, Solaris, and MacOS X interchangably, I think much of the scorn "POSIX native" programmers feel towards Win32 comes from a lack of experience. I really enjoy the degree of control given by the Win32 API, and the level of cleanliness my code enjoys through having an integrated messaging system. I've developed a number of thread pool-based transactional servers, and no interface on any platform, including kqueues, /dev/poll, and epoll (and let's not even mention atrocious O(n) mechanisms such as poll, or worse, select) rivals the code cleanliness that comes from using completion ports. Sure, the syntax may be ugly, and you may have some bizarre ideological problems with using primarily one header file, but ultimately when it comes down to it Win32 makes a programmer's life (at least, one who isn't doing GUI design from scratch without a nice wrapper) a lot easier than what POSIX has to offer.
Arend (IP: ---.almel1.ov.home.nl)
"Why would Windows programmers dig around windows.h when there's http://msdn.microsoft.com ?"
Well, there you have the culture difference again. I, for example, like to grep tough header files and look inside how it really works. Usually, that solves my problems much faster then browsing the web. On windows, however, this is much more difficult. The api is really coming at age and is full of macro's which are difficult to read and grasp. So, then I also refer to google and the web. I usually need to see an example before I can understand how I should use it.
I find myself doing the same thing on POSIX systems, but my reasons for doing so rarely carry over to Windows. Some of these include problems with the order of headers, or incomplete documentation within the manpages (some C libraries do a particularly bad job of documenting themselves in manpages... glibc, I'm looking in your direction, a lot of us really detest info) On MSDN, this really isn't a problem. As for using a "web page", you can install a local copy of MSDN when you install MSVS. I find MSDN to provide much more extensive documentation than the manpages bundled with most C libraries, and consequently I've never really had a need to dig around inside windows.h itself.
Rayiner Hashem (IP: ---.dc.dc.cox.net)
Its not just the fact that the compiler needs to reparse it each time. Its also the fact that anytime any of the sub-headers changes, all files must be relinked and recompiled.
Are you referring to the headers included by windows.h itself? These don't exactly change often... only when I've upgraded the Platform SDK, which occurs about once every few years. I modify and recompile my code several thousand times a day... this really isn't a problem.
Also, its terrible from a code maintainence standpoint --- pretty much every book on programming tells you not to make monolithic files.
Take a look inside windows.h; it's highly modular. It's really just a meta-include which gives you access to the entire Win32 application layer. Windows maintains a fairly stringent header file -> library mapping... the standard libraries are covered by windows.h, whereas a separate library such as Winsock 2 has its own header, winsock2.h. This really isn't possible on POSIX due to different ways in which different platforms compartmentalize functionality. FreeBSD throws everything including the dynamic linker and threads into libc_r, whereas Linux compartmentalizes the dynamic linker into libdl, and Solaris compartmentalizes sockets and hostname resolution into separate libraries from the standard C library.
Headers should be modular, with each one collecting closely related interfaces.
Again, there's no reason why modular headers must force the programmer to manually include each of them by hand. On all of my cross-platform Win32/POSIX projects, I end up creating a single meta-include header for POSIX as well. The impact on compile time, even on the 500MHz K6-2 which is my primary development machine, is negligable, and meanwhile I've already solved any header ordering problems which I've encountered on a variety of platforms. Someone not taking this approach may find when they try to move their code to another platform that that particular platform does not like both sys/time.h and time.h included, and an appropriate #ifdef for that platform must be placed in every .c file which includes both, if they don't prefer header consolidation.
The real reason why I believe the POSIX side hasn't moved to unified header files has to do with its legacy. On Linux, linking with glibc gives you access to sockets and libresolv. However, on Solaris for example, you must link with separate libraries to provide this functionality. Because the compartmentalization of features on a library level varies from platform to platform, it does make sense to have a header system that accounts for this. On the Windows side, a cross-platform API is not an issue, and consequently the programmer's life may be greatly simplified by providing a single header file which represents the entire API of the standard libraries.
Standard C++ should be used to reinvent the wheels, but it can also be used in the same way that Java is used but somone has to write a new VM, and an intermediate langauge compatible with the instruction set architecture, and the interpreter. I like the idea though of C++ as a low level systems langauge.
I wouldn't mind though designing a middleware framework, just collecting all the ideas into UML and than describing all of the classes. No coding involved. Same with the X protocol and Xfree86. I'd like to expose the ideas behind those systems.
Let me quote two things you said:
"And embedding KHTML (ed.) is cheating. Now do it without embedding an application that handles all of the work for you."
--- and ---
"The library is whats important unless you plan on reinventing all the wheels."
So which is it? Make up your mind!
It takes 100 lines to do in Win32 what it takes 5 lines to do in any other API not designed by people while they were high. It takes screenfulls of code to just create a damn window in Win32!
The Win32 API is extremely low level, primarily due to its legacy. This has many disadvantages in that unless programmers begin from the start by writing a nice wrapper which adds object orientation and centralizing message processing/event handling, the code will become a mess and a complete nightmare to maintain. What it does afford however, is a degree of control not really present on any other platform except MacOS (X) with Carbon. Unlike most GUI APIs, which impose a single layout model, the choice is really left to the programmer as to what layout model they use. Would you prefer to implement a packbox/table style layouts such as Swing, GTK, and Qt provide? This certainly makes internationalization easy, as widgets "know" how to resize themselves and consequently you can throw whatever size text you want into the labels throughout the window and the widgets will react intelligently. Or would you prefer traditional Visual Basic/Cocoa-style pixel-precise layouts which don't require hackish spacer elements to get the look you're trying for. With Win32, it really affords an enormous degree of power to the programmer. Looking at Win32 for the first time without having written a nice C++ wrapper to handle messaging/events, widget resizing/hiding, etc. it really can be intimidating due to its low level nature. However, having written such a wrapper for my own use, I can safely say that I like the interface I have written for myself much better than any other GUI API I have ever tried, and that includes GTK (oh god, object orientation in C is the ugliest thing I've ever seen), Qt (having system native event objects which work in conjunction with the C library is better than signals/slots any day), Swing (I hate the Swing layout model, and inner classes are so ugly compared to callbacks), and a number of others.
I think of Java as a software layer (supported by the VM) that is integrated into a product line and directed by a sales strategy.
The C++ library efforts are dependent on the operating systems native interface(s), rather than the instruction set layer of the processor family.
In part Java is dependent on the native interfaces, for example AWT, and any threading is handed off to the implementation. Yet Java needs to do this only in areas of high complexity.
It appears that middleware is a step in the right direction for a vendor who wants a flexible product line.
What the user wants is fine on Linux, and if he pursues C++ than it will run fine on Linux, but he might have problems in the future running his solutions on Windows. So that's when things will evolve. I just wish that more C++ libraries supported Standard C++ and the Standard Library.
I can't possible understand how anybody would find Win32 *clean*! Its an API where its impossible to do anything useful without filling out structures full of parameters. Where even the simplest functions need two lines to call because they have so many arguments. Where nothing or orthogonal, and you get entire sub-APIs to do what you need a single POSIX call to do. Maybe its just cultural differences, but I learned Win32 before POSIX, and I'd never want to go back.
@Anonymous: Even with a JIT, Java would've been slower, unless, of course, Java code is regularly faster than C++ code? But that's not the point of the article. In the general case, C++ is faster than Lisp is faster than Java. But just look at those develoment times! That's the meat of the article. Peter Norvig, a big AI guy and other of PAIP, wrote in response to the study:
"I did not participate in the study, but after I saw it, I wrote my version in Lisp. It took me about 2 hours (compared to a range of 2 to 8.5 hours for the other Lisp programmers in the study, 3 to 25 for C/C++ and 4 to 63 for Java) and I ended up with 45 non-comment non-blank lines (compared with a range of 51 to 182 for Lisp, and 107 to 614 for the other languages). (That means that some Java programmer was spending 13 lines and 84 minutes to provide the functionality of each line of my Lisp program.)"
There was a C++ programmer, also, who using templates got in the same playing field as Norvig's Lisp program. You're welcome to do a Java version that does the same
Why can't we have BOTH modular, reusable, command-line runnable code AND a well-designed gui as an alternative run interface?
Look, I'm not trying to be a C++/Lisp evangelist here. Just think before trying to spread to gospel of Java...
Yeah but if some company came out with a new OS, that ran on Intel X86, than you could get most of Java's functionality over there even if you had no knowledge of that systems native API, but with C++ you would be dead in the water (even though you already know that C++ has nothing to do with any specific library, i'm just talking about how existing C++ libraries are implemented with wrappers on different platforms...as far as I know anyway). Java can run interpreted from a VM for the Intel instruction set (not the whole library). So that is damn flexible if you ask me.
I can't possible understand how anybody would find Win32 *clean*!
Apparently you misunderstood. I've written my own wrapper for the Win32 API in C++ which I use for developing GUI applications on Windows. Because I designed its API, it suits my tastes much better than any other GUI API I've used. Because the interface exposed by Win32 is so low level, writing such a wrapper is much easier that it would be for a higher level GUI API. Consequently, I have a wonderful programming experience when developing Win32 applications, which is rivaled only by a visual interface builder, but eliminates the ensuing cruft.
I'm curious, how could you program on Win32 without abstracting it with a nice object oriented wrapper. I'm not even asking how you could tolerate it... I'm wondering how it's even possible. Using the Win32 API directly from a traditional structured programming perspective without adding a management layer would result in a massively bloated, overly redundant, and unmaintainable codebase. Writing a wrapper is just sensible design, and Win32 fits nicely into an object oriented paradigm, as all "windows" (which may be read as controls or widgets by those not versed with Microsoft's odd sematnics) have very OOP-esque properties which fit nicely into the canonical OOP inheritance model. Event handling can be done recursively with the parent object propagating all relevant events to its children. With sufficient knowledge of the operation of Win32, it's possible to throw a very nice face on it, one custom tailored to your own personal taste.
The only other choice is MFC, which while more usable than raw Win32 without a wrapper, is horribly ugly...
"Even with a JIT, Java would've been slower, unless, of course, Java code is regularly faster than C++ code?"
On average, JIT code benchmarks as fast as native C++ code.
"I did not participate in the study, but after I saw it, I wrote my version in Lisp. It took me about 2 hours (compared to a range of 2 to 8.5 hours for the other Lisp programmers in the study, 3 to 25 for C/C++ and 4 to 63 for Java) and I ended up with 45 non-comment non-blank lines (compared with a range of 51 to 182 for Lisp, and 107 to 614 for the other languages). (That means that some Java programmer was spending 13 lines and 84 minutes to provide the functionality of each line of my Lisp program.)"
This doesn't really say how long the resulting programs ended up being in Java compared to C. It also doesn't state how well the programmers knew the language in question, so nothing can be said from this study.
I'm also not going to buy the results of one study (that doesn't even state how it was controlled), when many other studies suggest that Java development time is on average, 10 times shorter than C++ development time.
But as far as LISP, there are plenty of reasons why LISP isn't being used for major development projects
"I can't possible understand how anybody would find Win32 *clean*! Its an API where its impossible to do anything useful without filling out structures full of parameters."
It's not. It's old, it's outdated, and MFC only made things worse. (MFC is horribly designed). The only thing the WinAPI has going for it is that it is fast.
But that's one major reason that the Win32 API is being replaced by WinFX, which is completely object oriented. The Win32 API will still be available for support of legacy applications however.
Oh, I see. That makes sense. Sounds like a lot of work, but to each his own.
As for how you can use Win32 without a wrapper: when there is a will, there is a way. There was a time when people wrote raw Xlib-apps, after all. You just have to be really careful and factor things out into reusable functions. In a way, you do create a partial abstraction layer, but I've never considered it a wrapper as such.
Oh, and there is always WTL. Along with DirectX, its one of the few reasonably nice APIs to come out of Redmond.
On average, JIT code benchmarks as fast as native C++ code.
>>>>>>>>>>>>>>
That's what Sun says. On Doug Bagley's Great Language shootout (which uses J2SDK 1.3.1) its in 14th place overall in the speed department. The only "benchmarks' that show Java performing as fast as C++ are numeric microbenchmarks, where the JIT can just compile down to a tight native-code loop, and is never involved in the rest of the test.
This doesn't really say how long the resulting programs ended up being in Java compared to C.
>>>>>>>>>>>>>>>>
Look at the deveopment times. They are seperate for Java and C.
It also doesn't state how well the programmers knew the language in question, so nothing can be said from this study.
>>>>>>>>>>>>>>>>>&g t;>
Read the PDF! On average, the Lisp programmers had something like 6.2 years of experience with the language, the C/C++ programmers 9.6 years with the language, and the Java programmers 7.7.
when many other studies suggest that Java development time is on average, 10 times shorter than C++ development time.
>>>>>>>>>>>>>>>
Only studies that test the libraries rather than the language. This study had a challenging problem that really didn't have canned solutions in the libraries.
But as far as LISP, there are plenty of reasons why LISP isn't being used for major development projects
>>>>>>>>>>>>>>>>>
Eh, not very many people are familiar with it, and it doesn't get a lot of hype. There also aren't pretty GUI tools like Visual Studio, and 3rd party libraries are less widely available.
But it *is* used for some major commercial development.
http://www.franz.com/success/
But the same is true for a number of languages that are more productive than Java: Python (used at Google), Erlang (used at Ericsson, Motorola, and T-Mobile), Ocaml (used at INRIA), etc. These languages are still used rather often in academia, science, and CS research. Also, the Europeans seem to be a bit ahead of the ball-game, they're much more willing to use and teach alternate languages than Americans.
Speed and flexibility are counter productive. The library frameworks that are decouple by a VM are more flexible than wrappers, and there are some new applciation domains being discovered by flexible distributed computing. Those tasks can be handled by a wrapper library, but than they are tied to the platform and they are not as integrated with other software if they are not supported by a major vendor and not part of a product line.
The situation of designing wrappers for Win32 is illogical because you don't own Win32, the vendor Microsoft does, so you just have to use whatever they tell you to use, that's the only way to succeed because they will come along with a bulldozer and plow you over, the Win32 API is cordoned off for construction, you are supposed to be using .Net because the whole thing (Windows) is a product.
On Linux I could benefit from having a fully documented Xlib because it's not the property of a vendor, it's my property. I want to understand the fine details because it's such an important library. Most of my applications, if you generalize them, they end up using Xlib, so I have a situation where 90% of my programs are dependent on this library, I want to know more about it.
Than I might want to do the one thing in Linux that you can't do in MS Windows. I might want to make some changes and recompile my platform.
Every benchmark I have seen in which Java is demostrated to be "as fast or faster" than C++ has been very visibly rigged. Perhaps the most notable was one where a Fast Fourier Transform was implemented in a completely object oriented manner, so values fed into the transform had to be given in the form of objects, and virtual methods were used to access the values inside the container objects, as the transform took values from a pure virtual base class and the actual objects passed to the transform were inherited from that class.
THIS IS NOT HOW C++ WAS MEANT TO BE USED. Please see this interview with Bjarne Stroustrup: http://www.artima.com/intv/goldilocks2.html
Objects in C++ should be used as a state management tool. In the case of values being fed into a Fourier transform, this is clearly a job that can be done efficiently and effectively with arrays. There is no state to manage, no invariant to establish, and absolutely no need to use inheritance.
Even if there were a need to pass different types of objects to some complex portion of code, this is an ideal job for templates. Rather than using a pure virtual base class and inheriting from it, simply write the transformation engine as a template.
In the case of the FFT example, it was obviously the work of Java zealots who chose to implement the code in a manner designed explicitly to take advantage of the only notable optimization feature Java employs which isn't possible on C++, namely automatic inlining of virtual methods.
C++ code can be optimized at run-time through the use of profile guided optimization. While profile guided optimization isn't "automatic" and does require developer intervention, it ensures that any optimizations applied to the code are persistent, whereas with the Java JIT/HotSpot approach all optimizations are done at run-time each time the program is started.
If you continue to insist that a JIT can bring Java's performance on par with native code, I implore you to provide me with a benchmark in which the language features of Java and C++ are properly utilized in a real world manner, and where the C++ code has been optimized through profile guided optimization.
And don't kid yourself, in the majority of cases C++ will be faster. In the small number of cases where Java is exhibiting similar (or better) performance than C++ profile guided optimization can be used to tune the C++ code's resulting executable, and in extreme cases virtual methods may need to be eliminated through the use of templates.
"Look at the deveopment times. They are seperate for Java and C."
Development time and number of code lines aren't the same thing. I can spend 20 hours writing 5 lines of code if I dilly dally a lot, or if I am trying to do something complex that I don't know how to do, so I have to resort to the API documentation a lot.
"Only studies that test the libraries rather than the language. This study had a challenging problem that really didn't have canned solutions in the libraries."
Using the libraries is generally more important for most programming. Example, produce a scrollable JPEG image in a frame in C++ using only 2 lines of code. Can you do it? I can in Java.
"Eh, not very many people are familiar with it (LISP), and it doesn't get a lot of hype".
And it's notation is downright annoying. No thanks, I'd rather not spend all day trying to code my hausdorff metrics in reverse polish notation.
"But the same is true for a number of languages that are more productive than Java: Python (used at Google)"
Python is also slower than Java by quite a bit because it doesn't optimize anything down to native code.
BTW, none of these take into account debugging time.. ie: the time you spend in C++ trying to find that memory leak, or trying to track down the pointer problem that is causing that occasional and ellusive illegal operation error.
You simply don't have problems like this with Java.
"C++ code can be optimized at run-time through the use of profile guided optimization. While profile guided optimization isn't "automatic" and does require developer intervention, it ensures that any optimizations applied to the code are persistent, whereas with the Java JIT/HotSpot approach all optimizations are done at run-time each time the program is started."
Yes. Guided optimization... as I watch that C++ development time get longer and longer because of things like guided optimization...
Now you see where the 10x time savings comes from in Java (that's just one example).
Now tell me. If there are no speed of development advantages to Java and such, than why is it more popular than C++ today? Certainly the cross-platform nature cannot explain all of it.
BTW, none of these take into account debugging time.. ie: the time you spend in C++ trying to find that memory leak, or trying to track down the pointer problem that is causing that occasional and ellusive illegal operation error.
With modern memory debuggers (such as GlowCode on Windows, or valgrind on Linux, an OSS application) solving these problems is as easy as figuring out the cause of a particular segment violation. They can not only point out what memory was leaked but give you a complete backtrace as to how it was allocated, including line numbers. It can also show reads from/writes to unallocated memory, and also the location of the nearest allocated block. Couple this with proper unit and overall system testing and memory problems really aren't an issue.
You simply don't have problems like this with Java.
No, instead your end users have problems like this:
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
www 43642 53.8 16.0 101960 83520 p0 R 5:18PM 0:02.88 /usr/local/jdk1.3.1/bin/i386/green_threads/java -classic -jar -Dcata
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
www 43642 53.8 16.0 101960 83520 p0 R 5:18PM 0:02.88 /usr/local/jdk1.3.1/bin/i386/green_threads/java -classic -jar -Dcata
Your point being what? That it is using 53.8% of the CPU time?
I'd have to see a running list to see if that was bad or not. For all I know, that was taken at a time the app was doing something particularily intensive.
Java byte code that is compiled to the operating system binary level is fast, however the operating sytem layer is a hybrid layer, and metrics probably have to made for each individual operating system. The binary might also be optimized by the compiler for lower layer interpretation so the compiler will make a difference too.
"Java might perform better on Solaris than on Intel."
Java performs quite well on Intel if using a JIT. The JIT generates native machine code.
In fact, my experience has been that Java performs better on Windows than .NET does.
I think I am done with this discussion, since it seems like we aren't going to get any further than we have gotten. And we are just going to be stuck at.
"Java development is faster than C++ development"
"No it's not"
"Yes it is"
"No it's not"
"Yes it is"
"No it's not"
....
That needs to be answered is...
Does unmanaged C++ have any future on Windows? After all, the WinFX API is a managed API.
And if unmanaged C++ does not have any future on Windows, than these discussions are not really relavent, because it's not going to matter whether you use managed C++, C#, VB, or whatever. They are all going to perform equivalently.
You mean like the IE core, which you can use in your own apps? There are far more IE-based browsers than Gecko browsers out there, so what exactly is your point?
I think you hit the nail on the here, I can only assume that a large proportion of the Linux community left Windows as newbies because all of these elitist abilities I keep hearing about are equally available in Windows.
I quite liked the analogy i read earlier about mechano vs toy helicopter? but cant help but feel it's a little blinkered, the way I see(lol great pun but unintended)it Windows users have Mechano & a toy helicopter, linux only the mechano
But a native machine binary is than interpreted. So the JIT compiler has to optimize the binary for the underlying layers to interpret. And it's a question of the compilers knowledge of the architecture.
"But a native machine binary is than interpreted. So the JIT compiler has to optimize the binary for the underlying layers to interpret. And it's a question of the compilers knowledge of the architecture."
True. But the JIT can actually make optimizations that a C or C++ compiler can't even think about making. Why? Because Java profiles code as it is running, and looks for bottlenecks, and looks for the best ways to optimize those bottlenecks. The next time you start the application, the JRE will optimize those portions that are causing slowdowns.
And it's only going to get better. Tiger (Java 1.5) is going to have some major performance improvements over current JREs.
Combine Tiger with the Java Desktop System, and Longhorn has some serious competition on its hands.
I'm sure Microsoft took notice when Sun got a contract to deliver 200 million Java desktop systems to China... Yes, that's 200 million. 200 million desktop systems running Linux. That has to put a subtantial dent in Microsoft's share of the desktop OS market.
Yeah, I guess what I'm saying is that on SPARC, Sun Microsystems has control over the micro architecture and the instruction set architecture, so they can build the low level architecture to support a more sophisticated Java Virtual Machine, but on Intel, they don't have as much control.
China is the fastest growing economy in the world. I think that MS might try to get their hands in on the deal if they buy AMD.
I mean take a hardware JVM chip, it can directly execute JVM binary programs without the need for a layer of software interpetation or JIT compilation.
Here is where speed and cost are at odds in a multiprocessing computer architecture, but feasible for embedded systems. The only difference between hardware and software is that hardware is 'fixed' software, but if cost was not prohibitive, you would never even need a JIT compiler or interpreter to run your Java programs, only the javac compiler to produce the byte code, and the hardware would directly execute it without interpretation.
"China is the fastest growing economy in the world. I think that MS might try to get their hands in on the deal if they buy AMD."
I don't think the government would let Microsoft buy AMD.
As far as hardware based JVMs, yeah, I would love to see something like that on Intel boxes.
"Yes. Guided optimization... as I watch that C++ development time get longer and longer because of things like guided optimization..."
Apparently your time is more important to you than the end user experience. At least you aren't claiming anymore that Java's performance is equivalent to or better than native code...
"Now tell me. If there are no speed of development advantages to Java and such, than why is it more popular than C++ today? Certainly the cross-platform nature cannot explain all of it."
The second case of argument ad populum I've seen on OSnews today! Not only is this a logical fallacy, but there is no method by which popularity of a programming language can be effectively quantified.
"Your point being what? That it is using 53.8% of the CPU time?
I'd have to see a running list to see if that was bad or not. For all I know, that was taken at a time the app was doing something particularily intensive."
My point being that, in general, languages with runtimes consume significantly more system resources, both CPU and memory, than native code applications. Most have event loops which don't block on I/O, and constantly drag down your available CPU.
Again, it's an issue of the best end user experience...
@Anonymous: Those things are more theoretical than practical. In practice, the Java JIT is severely limited in what it can do because it has to generate code quickly to avoid stalling the application. Since a lot of advaned analysis are time-consuming, JIT's don't achieve the kind of performance in real life that they do in theory. Of course, the most advanced compilers in existence are, for Lisp and other functional languages. Basically, the "Lisp is slow" or "ML is slow" stereotype spurred literally decades of compiler optimization research for those languages. For example, in Dylan (Apple's infix version of Lisp) there are no native types. Even integers and floating-point numbers are full classes. Their compiler guys realized that the int primitive vs. Integer class distinction was unnecessary, because the compiler could just figure out itself when an object didn't need to be boxed. Of course, this is a tremendously intensive analysis, and it wouldn't be feasible to do it at runtime.
"Apparently your time is more important to you than the end user experience."
The end user experience is just fine with Java. And my time is more important when we need an app now, and not later.
"At least you aren't claiming anymore that Java's performance is equivalent to or better than native code..."
I am still claiming that JIT code is on a par with native code.
"Not only is this a logical fallacy, but there is no method by which popularity of a programming language can be effectively quantified."
Sure there is. You can do surveys and find out what languages people are using to develop applications. The number of "help wanted" adds that require Java experience comapred to the number that require C++ experience is also useful.
"My point being that, in general, languages with runtimes consume significantly more system resources, both CPU and memory, than native code applications. Most have event loops which don't block on I/O, and constantly drag down your available CPU."
If you'd like, I can post ps output from a C application using 80% of the CPU time and 40Mb of memory. In other words, your ps output paste doesn't prove anything.
"Again, it's an issue of the best end user experience..."
So tell me. Are you one of those people who never got past "Java is only useful for putting animations on Web pages"?
If Java can't handle mainstream programming tasks, why don't you tell that to the people at NASA that are designing a system to manage shuttle payloads in Java, or the people using Java to track global weather patterns, or the people using Java to sequence and analyize human DNA, or the people using Java to study seizmic vibrations in the Earth?
Apparently, they never got the message that Java is too slow for such very computation intensive tasks.
"@Anonymous: Those things are more theoretical than practical. In practice, the Java JIT is severely limited in what it can do because it has to generate code quickly to avoid stalling the application."
Your application spends 95% of its time executing 5% of its code. That's the only part that really needs to be optimized. So no, Java is not limited in what it can do, because it only has to do it to a small part of the code. So yes, Java can make runtime optimizations that C and C++ can't, and it is not strictly theoretical.
"My point being that, in general, languages with runtimes consume significantly more system resources, both CPU and memory"
Image Name: java.exe
CPU: 00
Mem Usage: 2,300 K
See? I can process information too.
Companies have built hardware JVM chips to execute Java binary code directly. This is the case with cell phone technology and other embedded systems where there is not enough memory for compilation and an interpreter is too slow. The telephone user can download an applet or web service that allows him to perform a certain task that his phone was not able to do previously. Java binary code is the native code of this hardware.
If Java can keep up to a network connection data rate, which apparently it can, even while performing computationally intensive tasks, than it doesn't matter if C++ is faster.
Sun has created a successful product in Java and they are not expanding the product line to include Linux as an endpoint.
Linux C++ and C developers would be better off using their knowledge to expose the source code of low level libraries and systems infrastruture. C and C++ are languages used to build systems, they are not appropriate for writing specialized solutions. Start to generalize instead of trying to specialize.
I didn't say it was strictly theoretical. I said it was mostly theoretical. HotSpot doesn't a fraction of the optimizations it could theoretically do because it must operate under a time limitation.
Also, while some (mainly scientific computing) apps might spend most of their time in 5% of their code, that's not true for other types of apps. Being able to do good optimizations on the whole codebase is less important for a low-level language like Java, but it is still a factor.
"Not only is this a logical fallacy, but there is no method by which popularity of a programming language can be effectively quantified."
Sure there is. You can do surveys and find out what languages people are using to develop applications.
Then by all means, do surveys. As soon as your surveys have the same degree of authority that Gartner and IDC surveys do perhaps I'll listen to you. However, thus far you have failed to post any source for your audacious claim. Were you to say, post a survey of programmers for the top 100 software firms in the world asking which language they prefered, that would be acceptable.
The number of "help wanted" adds that require Java experience comapred to the number that require C++ experience is also useful.
This can speak of any number of things, most notably the high rate of turnover in Java related jobs, which is currently dominated by JSP development. Like all web development, JSP jobs are quite tummoltuous compared to the traditional C/C++ applications market.
Your application spends 95% of its time executing 5% of its code.
Most of my applications spend 99.9% of their time blocking on I/O, as compared to Java which is constantly chewing CPU.
That's the only part that really needs to be optimized.
The system calls... good luck getting a JIT to optimize those.
So yes, Java can make runtime optimizations that C and C++ can't, and it is not strictly theoretical.
Like I mentioned earlier, runtime optimizations may be made in C and C++ code through profile guided optimization if performance is an issue.
"Most of my applications spend 99.9% of their time blocking on I/O, as compared to Java which is constantly chewing CPU."
Java does not chew CPU.
Image Name: java.exe
CPU: 00
Mem Usage: 2,225 K
"Like I mentioned earlier, runtime optimizations may be made in C and C++ code through profile guided optimization if performance is an issue."
And like I said, watch that development time get longer... and longer...
BTW, you wouldn't happen to be friends with Gerald Bauer would you? I'm just wondering because you seem to have some kind of major axe to grind with Java.
There used to be a problem with Java threading on Linux because Java would let the implementation handle threading even though the threading API was the same for all Java applications. Linux didn't support the creation of hundreds of threads efficiently and some Java applications used that many threads. That has changed with Linux's new thread implementation which is able to handle hundreds or thousands of threads efficiently, but something like that does give Java a bad reputation. I think that the good outweighs the bad though and C++ developers should concentrate more on systems implementation where many ideas are not being realized.
Sun's Java interpreter 'java' is implemented in C. I imagine that the JVM is as well, but I've only read about the interpreter.
"Linux didn't support the creation of hundreds of threads efficiently and some Java applications used that many threads."
Ah yes. I remember that now too. Linux kernel versions prior to 2.4 did have problems managing large numbers of threads. I think most of that has been fixed with 2.4 though.
"Sun's Java interpreter 'java' is implemented in C. I imagine that the JVM is as well, but I've only read about the interpreter."
The java virtual machine (java) is written in C. The java compiler itself (javac) is written in Java itself.
Why wasn't the the java virtual machine written in Java?
Bascule wrote:
However, having written such a wrapper for my own use, I can safely say that I like the interface I have written for myself much better than any other GUI API I have ever tried, and that includes GTK (oh god, object orientation in C is the ugliest thing I've ever seen), Qt (having system native event objects which work in conjunction with the C library is better than signals/slots any day), Swing (I hate the Swing layout model, and inner classes are so ugly compared to callbacks), and a number of others.
This is really interesting, having that kind of experience would surely have a good type of messaging and event handling system implemented at a fairly clean way. Personally, my preferences closely match a Win32 looper coupled with a BeOS-like message handler. That way, those dreaded macros are eliminated from the equation.
Other than that, it is nice to see posts like these.
Rayiner wrote
When you circumvent the type system, you're going to get type errors. Unfortunately, printf() circumvents the type system, but a *NIX compiler would have caught that because they usually do type-checking for printf(). In the end, its best to make sure your C code typechecks properly in a C++ compiler. That'll get you compiler-enforced type safety without any silly naming conventions.
Doing type checking in *nix C is considered anathema. And I don't know exactly why would anyone use C for that purpose, though. There are other languages out there that can do pretty much most of the hard work better than C.
Personally, I use C to get away with type checking and just use a different language like Java or C++ when I want to go back to a typed-checked environment.
Because that would involve a chiken and the egg problem. You can't run the Java Virtual Machine on a system if it is written in Java since the system can't understand Java yet. It has to have the Java Virtual Machine running before it can understand Java. That's why the compiler can be written in Java, because it can run under the JVM.
The other reason is performance. The JVM is written in a native language and fully optimized, and translates Java API calls into native calls on the platform.
