The event-based programming model isn't impossible in Windows either; in fact it's how visual basic is done. It's implemented at a higher level than the message loop however. I think MFC also does event based programming but I'm not sure. The point is that with the correct toolkit you don't need to worry about the low-level design of the OS or API. Let the toolkit makers do it for you. Isn't X just a protocol for transmitting data from a 'server' to a 'client'?
This type of programming is not really a good style. It works, and the calTotalFlowRate() function is nice and small, but it makes it hard to maintain. For example, let's say you know of 10 kinds of pipes. now you want to add a new pipe. with your code, you have to examine each function that operates on a pipe, and add a new case to it. with OO programming, you just add a new class. The new pipe can be totally different from the old pipes, or it can be similar (in which case it might make sense to inherit... round pipe is a special case of oval pipe).
Also, another big advantage of OO programming is that someone else who uses the code (not the original author) can add new kinds of pipes. Let's say you are selling a modelling tool. Your customer might want to model their own, special pipe with your tool. with OO programming it's easy: just add a new object. the modeling tool doesn't need to care. with procedural programming it's hard, since every procedure needs to know how to deal with every type of pipe at compile time.
Another point about OO programming is that you can make an algorithm into an object. This makes it simple to drop in new algorithms, even at runtime. The algorithm itself might not be very OO, but how it fits into the system is OO. The goal of OO isn't to do stuff that is impossible, but rather to make it easier to organize what you're doing. Better organization means better code (and better maintenance).
Of course, it's not a given that OO implies good code, nor that procedural/functional/assembly implies bad code.
Gee... according to Linus the scheduler has never been rewritten, and the scheduler is performing just fine. Some people complain that it could do better on large multi-processor boxes, but then NT doesn't do so well on those boxes either.
Also, NT4 had some major changes in that the video drivers were moved INTO the kernel.
Well, in Windows 98, what I do is:
CLick Start->Find (or window_key-F)
The dialog that pops up has three fields on the first tab. I can enter a shell-like regexp for a name if I want to.
I click to select root of search (or type it in).
I click in the box labeled "Containing text:" and I type 'foo'
Then I click 'Find Now'.
Lots of clicking, yes. But, it is easier to use. My search results appear in a window where I can click once to open the file.
Advantage over the find/grep method:
I can double-click to open a file, or click once to rename it, or whatever. The file is presented to me as an icon, so any icon-manipulations I can perform on a file are available. With find/grep, I can see which files contain the text, but I can't just select one or two and modify them as easily.
I don't need to remember the syntax of two unix commands. Other search options are represented by other tabs on the same dialog box.
I don't need to be in a command prompt window to do this. In Windows, people avoid the shell, so this is a real advantage.
Disadvantages:
This is less scriptable, but that's not because it's impossible, it's because MS just didn't make it scriptable.
It is probably a little slower than the command line, if you compare two experienced users.
The find dialog is really very basic, but that isn't because the GUI makes it impossible; it's because MS assumes most people don't want to do that. But it's not impossible to imagine a nicer find dialog that provides full regexp searching.
The MS find dialog box doesn't actually show you the text that matched your search expression. This means you have to open every file if your expression is not relevant in all contexts. But that's not because of a GUI limitation, it's because MS just didn't do it.
I am a linux user first, and a windows user second. But I think people need to remember that Windows really does have lots of features. And GUIs are not inherently less powerful than CLIs. It's all a matter of the presentation of the information.
Gee, it doesn't sound like you know X very well. You didn't name a single thing that X can't do; with X I can run any application on the machine I connect to; it merely displays on my local system. This means I can run the DB admin client on my DB server if that's where it's installed. And since X servers (remember, the X server is the part that draws X programs, not the box you run the program from) are available on pretty much all OSes, I can run my server's X application on any terminal I have. The only catch is that the other computer needs X on it... which it does, unless it's Windows.
Let's say I want to run a 3D accelerated game... looks like I can do that on my local box. It doesn't make sense to run a hardware accellerated program remotely, so you can't do that. But then, neither can WTS. At best, it would have to be software rendered. Not very snappy.
Let's say my workstation is running an OpenGL program on it (hardware accelerated). Let's say I walk across the room (or go somewhere else with internet access) and I realize I have to run some program on my workstation. I can simply use ssh to connect, and then run the program. Bingo, it just works. The program displays remotely, and I'm happy. In fact, I can use ssh to automatically log in, and launch a program without even showing me a password prompt or a command line. Encryption keys take care of it. Simple, eh? My username/password doesn't even need to be the same on the remote system. Bet that's hard to do in windows.
WTS is a nice product. But let's not forget that all it does is bring to Windows some functionality that Unix has had for years. It doesn't do anything new or exciting... the fact that clients are available for 386s doesn't impress me; There are X terminals that don't do ANYTHING except draw X programs on their screen. They're certainly not more powerfull than a 386. And you can certainly run X on a 386, especially if the clients are remote.
I use X's remoteness often. For example, I have Licq installed on two computers: my local one (it was installed there first), and my server. My server is accessible from the net, so I can use ssh to launch licq no matter where I am. In this case, it means that I don't need to install Licq or share my filesystem to have access to my contact list or my history. Furthermore, if I do file transfer from icq, I usually want it to be to and from my home computer, not whatever terminal I happen to be using.
Also, I have often used X + ssh to run software on the computers at my school, from home. This means I can complete an assignment from the comfort of my home computer, yet I can access the power of the school computers and the software installed on them. I don't have hspice or awaves or matlab installed on my linux box, but the school has it on their solaris boxes. Without X's network transparency, I wouldn't be able to do my 'homework' at home.
Finally, I think it's ironic that just as Windows gets the ability to serve clients like X (Winframe, MetaFrame, Terminal Server), people in the Linux world are talking about how no one needs network transparency. Microsoft wouldn't have 'stolen' Winframe from Citrix if they didn't think it was valuable.
I'm taking CE at University of Toronto, and all our fourth (final) year work is team work. There used to be a 'thesis' which could be done alone or in teams, but now it's a 'design project', and it has to be done in teams. Also, a lot of my lab work in the past years was done in teams of 2-3 people. This year, the teams are 4+ people.
The thing is though, that team work in school is not like team work at work; I've worked for a year on a co-op placement and the teamwork was very different because everyone was always around... we didn't all have different classes to go to or things like that. We were all basically full-time team-mates, where in school we are only part-time team-mates.
Our Engineering Computing Facility was recently upgraded to Linux boxes; we had sparcs and NT boxes before. There are still some NT boxes, but even some of the new NT boxes became Linux boxes.
Slashdot Mirror
The event-based programming model isn't impossible in Windows either; in fact it's how visual basic is done. It's implemented at a higher level than the message loop however. I think MFC also does event based programming but I'm not sure. The point is that with the correct toolkit you don't need to worry about the low-level design of the OS or API. Let the toolkit makers do it for you. Isn't X just a protocol for transmitting data from a 'server' to a 'client'?
Hey, I find the AOL CDs useful. There's one supporting my coffee cup right now :)
This type of programming is not really a good style. It works, and the calTotalFlowRate() function is nice and small, but it makes it hard to maintain. For example, let's say you know of 10 kinds of pipes. now you want to add a new pipe. with your code, you have to examine each function that operates on a pipe, and add a new case to it. with OO programming, you just add a new class. The new pipe can be totally different from the old pipes, or it can be similar (in which case it might make sense to inherit... round pipe is a special case of oval pipe).
Also, another big advantage of OO programming is that someone else who uses the code (not the original author) can add new kinds of pipes. Let's say you are selling a modelling tool. Your customer might want to model their own, special pipe with your tool. with OO programming it's easy: just add a new object. the modeling tool doesn't need to care. with procedural programming it's hard, since every procedure needs to know how to deal with every type of pipe at compile time.
Another point about OO programming is that you can make an algorithm into an object. This makes it simple to drop in new algorithms, even at runtime. The algorithm itself might not be very OO, but how it fits into the system is OO. The goal of OO isn't to do stuff that is impossible, but rather to make it easier to organize what you're doing. Better organization means better code (and better maintenance).
Of course, it's not a given that OO implies good code, nor that procedural/functional/assembly implies bad code.
Gee... according to Linus the scheduler has never been rewritten, and the scheduler is performing just fine. Some people complain that it could do better on large multi-processor boxes, but then NT doesn't do so well on those boxes either.
Also, NT4 had some major changes in that the video drivers were moved INTO the kernel.
I click to select root of search (or type it in). I click in the box labeled "Containing text:" and I type 'foo'
Then I click 'Find Now'.
Lots of clicking, yes. But, it is easier to use. My search results appear in a window where I can click once to open the file.
Advantage over the find/grep method:
- I can double-click to open a file, or click once to rename it, or whatever. The file is presented to me as an icon, so any icon-manipulations I can perform on a file are available. With find/grep, I can see which files contain the text, but I can't just select one or two and modify them as easily.
- I don't need to remember the syntax of two unix commands. Other search options are represented by other tabs on the same dialog box.
- I don't need to be in a command prompt window to do this. In Windows, people avoid the shell, so this is a real advantage.
Disadvantages:I am a linux user first, and a windows user second. But I think people need to remember that Windows really does have lots of features. And GUIs are not inherently less powerful than CLIs. It's all a matter of the presentation of the information.
Gee, it doesn't sound like you know X very well. You didn't name a single thing that X can't do; with X I can run any application on the machine I connect to; it merely displays on my local system. This means I can run the DB admin client on my DB server if that's where it's installed. And since X servers (remember, the X server is the part that draws X programs, not the box you run the program from) are available on pretty much all OSes, I can run my server's X application on any terminal I have. The only catch is that the other computer needs X on it... which it does, unless it's Windows. Let's say I want to run a 3D accelerated game... looks like I can do that on my local box. It doesn't make sense to run a hardware accellerated program remotely, so you can't do that. But then, neither can WTS. At best, it would have to be software rendered. Not very snappy. Let's say my workstation is running an OpenGL program on it (hardware accelerated). Let's say I walk across the room (or go somewhere else with internet access) and I realize I have to run some program on my workstation. I can simply use ssh to connect, and then run the program. Bingo, it just works. The program displays remotely, and I'm happy. In fact, I can use ssh to automatically log in, and launch a program without even showing me a password prompt or a command line. Encryption keys take care of it. Simple, eh? My username/password doesn't even need to be the same on the remote system. Bet that's hard to do in windows. WTS is a nice product. But let's not forget that all it does is bring to Windows some functionality that Unix has had for years. It doesn't do anything new or exciting... the fact that clients are available for 386s doesn't impress me; There are X terminals that don't do ANYTHING except draw X programs on their screen. They're certainly not more powerfull than a 386. And you can certainly run X on a 386, especially if the clients are remote.
I use X's remoteness often. For example, I have Licq installed on two computers: my local one (it was installed there first), and my server. My server is accessible from the net, so I can use ssh to launch licq no matter where I am. In this case, it means that I don't need to install Licq or share my filesystem to have access to my contact list or my history. Furthermore, if I do file transfer from icq, I usually want it to be to and from my home computer, not whatever terminal I happen to be using.
Also, I have often used X + ssh to run software on the computers at my school, from home. This means I can complete an assignment from the comfort of my home computer, yet I can access the power of the school computers and the software installed on them. I don't have hspice or awaves or matlab installed on my linux box, but the school has it on their solaris boxes. Without X's network transparency, I wouldn't be able to do my 'homework' at home.
Finally, I think it's ironic that just as Windows gets the ability to serve clients like X (Winframe, MetaFrame, Terminal Server), people in the Linux world are talking about how no one needs network transparency. Microsoft wouldn't have 'stolen' Winframe from Citrix if they didn't think it was valuable.
I'm taking CE at University of Toronto, and all our fourth (final) year work is team work. There used to be a 'thesis' which could be done alone or in teams, but now it's a 'design project', and it has to be done in teams. Also, a lot of my lab work in the past years was done in teams of 2-3 people. This year, the teams are 4+ people.
The thing is though, that team work in school is not like team work at work; I've worked for a year on a co-op placement and the teamwork was very different because everyone was always around... we didn't all have different classes to go to or things like that. We were all basically full-time team-mates, where in school we are only part-time team-mates.
Our Engineering Computing Facility was recently upgraded to Linux boxes; we had sparcs and NT boxes before. There are still some NT boxes, but even some of the new NT boxes became Linux boxes.