I'm not sure of the details of these systems (how big is the star?), but is it possible that the system formed as a binary system, only there wasn't enough mass in the smaller "star" for fusion reactions to begin? This seems to be the obvious explanation, but I assume since there's no mention of this that it has been ruled out. Why? Is the mass ratio between the objects too great for them to have formed as a binary system?
This is more FUD. Many, many projects have benefited a great deal from using object oriented design. The most significant benefits come in maintenance. When you consider how much money is spent maintaining typical non-OO programs, it's obvious that there's a HUGE difference. They did metrics on one of the largest C++ projects ever (it was something at IBM IIRC, a few million lines of code anyway), and discovered that the size of the average method was less than 3 lines of code, and there were something like 4 casts used in the entire system and an order of magnitude reduction in the number of if and switch statements. If you know ANYTHING about programming you should be able to understand the mammoth ramifications of these metrics. You simply don't achieve those kind of results using traditional design methods.
I do agree with you that if you're not going to use good OO designs, then you may as well not use OO at all. Kind of like if you're going to write 1000 line functions with goto statements everywhere, you may as well not split your code up into functions at all. Just because it's being misapplied so frequently doesn't mean OO is the wrong tool.
A lot of it is poor management. Companies like to hire these cheap programmers who only know VB, Visual C++ and MFC. Companies like IBM that know what they're doing will hire real, clueful software engineers to be involved with their projects. They know you can't take some typical $50k MFC programmer and give him an important role in designing an OO system. Now, it's unlikely that ANY company will have ONLY experienced object technologists working for them. There just aren't enough good people to go around. But a smart company will have at least one such person working on a particular project as the main architect, overseeing the design.
Therefore, we can state that the OO design hasn't done anything to solve the problem, or any other problem inherent to systems which have complex data structures. That's why I say that OO design is completely overrated. It's a hype, that doesn't deliver on its promises, very simply, because complex data structures are the mainstay of real-world business applications.
You're saying that because an OO design breaks in this situation -- where a non-OO design also breaks -- it's "completely overrated" and "doesn't deliver on it's promises"? What a total non sequitur. OO is designed to be a more accurate way to model large and complex real-world problem domain in software.
large == requires more than one developer complex == multiple mutually exclusive goals
Such software is almost always long lived, and it usually makes sense to emphasis: understandability, flexibility, reusability, extensibility. These are the areas where OO is most powerful. This is why, for such systems, OO works well if used properly, and in my opinion is the best approach to take if you want to be successful.
Wrong. The classes that use this class will be broken too, because the methods Set/GetCustomerAddress() have changed. There is more than one addres now.
If you want to push through the concept of many addresses throughout the system, all the classes that use the member Customer.GetCustomer() (or SetCustomer()) must change the way they handle the addresses of this customer object. You may opt for workarounds, but they won't change the fundamental problem: they will just be that, workarounds.
Get/Set methods? Another symptom of a poor, data-oriented design. In fact, it has sounded throughout this thread like your concept of OO is actually pseudo-OO, ie. data modeling. A mechanism free, policy free pesudo-OO paradigm is probably even worse than the traditional, non-OO approach, because you end up with a lot of classes that aren't actually very useful by themselves resulting in tight coupling and less flexibility. If that's your idea of what true OO is, then it's no wonder you dislike it.
For example, why would the customer have a "GetAddress" method? Would a customer just give their address to anyone who asks? Unlikely. The customer might give it's address to another object if it was purchasing an item. You wouldn't have an item sent to two different addresses though, so objects other than the customer would only need to know about the single address.
Given a fairly standard design which uses the Builder pattern (see Design Patterns), your change to the database might mean changing two classes: the Customer class, and a CustomerReader class. Or something along those lines. The changes would certainly NOT start propagating throughout the system, unless the design was horrendous (in which case there would probably be the aforementioned Get/Set methods all over the place).
OO designs will break even more easily, because in such designs there are simply more places in which you have duplicated the underlying assumptions of your system.
No! Again, that's data modeling. What you are saying is the same as saying that OO systems are not flexible, and that's simply the complete opposite of the truth. A true OO design should be mechanism rich, but more general, more policy free than a non-OO design. A direct consequence of this is fewer dependencies amongst classes, and any assumptions about the underlying system being localized. This results in a very flexible architecture.
Of course it will have to change somewhere. But how is this different from a "normal", non-OO program? You'd still have to make the change. If anything the OO design is advantageous here, because any changes would only have to be made within a single class. In a non-OO design there's no guarantee the change isn't going to have to be reflected in more than once place.
Upon reading your original message again, you seem to be talking about querying the tables, fields, etc. and doing things dynamically based on what's there. I have no idea what exactly you're getting at, but there's no reason you couldn't do these types of things with an OO design. You seem to be saying that an OO design must be rigid and static, and tightly coupled with the data the application is using, but that's no more true than it is for a non OO design.
The second option is to access a relational database. Anybody with anything like half a brain will choose this option.
Of course a relational database is the best option. But there's definitely no reason you can't decouple the framework from the database stuff. The problems you're talking about only happen if you base the design of your application based on the DATA. That's completely the wrong approach. You design your framework based on the application domain. The flexibility to change the way data is accessed should be built into the design. You certainly shouldn't have your database structure duplicatd in your object model. If that's the case, the design isn't even object oriented.
For example, if a customer can suddenly have more addresses instead of one, the customer object will have read its address from a different table: it's, therefore, broken.
See, this is a perfect example of the design being wrong. Does a customer know his address? Yes. Does a customer know how to go into your database and store or retrieve his address from your files? I certainly hope not, and I hope you realize why this is wrong.
Object orientation is another one of these miracle cure-all solutions that almost never work, even though no one will openly admit it. By modeling business apps as objects, you will not only lose a lot of time, but, even worse, make your applications much less maintainable. Why so? Because the complexity of business applications is in their data, and the only thing you will do by modeling business applications as object frameworks, is to replicate this complexity once more in your object classes. And then you will have an extra chunk of code to maintain, when you change your database structures. Next to your database design, your GUIs and your batches that you need to maintain, you will need to maintain the so-called business objects. These business objects "know" your data structure, and, therefore, have to be informed of changes in it. The duplication effort is ridiculous and only pays off in wasted time.
I don't even want to attempt to try and respond in full to your entire messge, because I could easily spend hours writing a huge essay in response. I'll just focus on the part where you discuss OO, since a pet peeve of mine are all the misconceptions I see about OO, particularly on Slashdot (they seem to be less prevalent in the industry).
Now, sorry if this comes off like a flame, but the above sounds like it's coming from someone who doesn't understand the real principles behind object oriented programming, and who does not have experience working on large-scale software projects. In my experience I have found the opposite of almost everything you say to be true. The only problem with object oriented development is that most programmers don't know how to do it properly.
I have seen projects succed and fail, and I am quite convinced that given competent designers, using an object oriented approach is guaranteed to be more successful (in terms of time, money, and risk) in a large project than other methods of design. There is an overwhelming amount of evidence out there that this is the case. Look into some of the research. Read some of the books on software engineering. You are right that an object oriented design will increase the overall complexity of your design. This is a good thing, since it's precisely what gives object oriented designs their inherent flexibility. Flexibility is the most important benefit of an object oriented design. Another consequence of an OO design is that it will drastically decrease the complexibility of the individual and components within your system. Even on the surface this should be obvious if you think about it. Clearly object oriented models better represent their associated real-world systems than other methods like data modelling. I don't see how anyone can argue that. Now, if the inherent complexity of a system is in the overall design, that is where it should stay, is it not? Other techniques only move the complexity elsewhere, which is less natural, and therefore inevitably more expensive to maintain. You have to expend more effort to constantly differentiate between your application domain and your model since they become quite different.
These business objects "know" your data structure, and, therefore, have to be informed of changes in it.
NOT TRUE!!! In a proper OO design, you do not have "data structures". You have data, which is distributed throughout the objects in your system and encapsulated by those objects. But you should never have to think about data structures. I suspect you have a lot of experience with bad OO designs where a lot of data is passed around. This happens a lot in practice, but is simply poor design.
only two reasons for this: a deeply rooted hate for Microsoft, and pure ignorance.
Actually, in my case it simply doesn't provide the flexibility I need to design complex, large-scale software systems. VB has it's place. I think it is a very good tool for prototyping, and in many cases is appropriate for develping the GUI front-end of an application. I don't use it myself, as I prefer other tools for those purposes, but I can see where it would be useful.
You may, for example, ask most classes, in code, what their properties are, what their methods are, and what their parent class is, and so on. C/C++ not only lack self-knowledge
You don't understand; VB is more of a high-level, dynamically typed scripting language. That's why it can do these things. One can debate the merits of static typing vs. dynamic typing, C++ vs. Smalltalk, etc. all day, however with a proper OO design, you should never need to ask a class what it's properties or methods are. There are rare cases where you might want to know if a class supports a certain interface, which is what dynamic_cast is for in C++. But by and large you're doing something wrong if you ever need these capabilities in C++.
If I let my imagination roam, I can think of a few million things that are scarier than WITCHES and magic. If I let my imagination roam, I can also pretend Santa Claus is real, or that Jesus really did walk on water. That doesn't change the fact that this has no basis in reality. They could have at least chosen something less cliche than witches.
Thank you! I've gone through a lot of these responses, and I keep seeing comments from people who loved the movie, and can't understand how anyone could possibly not like it. What really gets me is the theories these people have come up with to explain why some people don't like it. The two most common ones seem to be: young people "just don't get it", or that only people with imagination like it. How about: I SIMPLY THE WHOLE CONCEPT OF "WITCHES" RETARDED. I can see why people who believe in paranormal type stuff would like it. Otherwise, I think a lot of people are just gullible and will go for anything. It's hard for me to enjoy a movie where I'm sitting there the whole time thinking "this is so silly".
they could have broken them. They could have divulged that BW was fake in September(imagine how pissed you'd be!). The way they did it, everybody going to the movie sorta heard some people saying it was real and some people not--not altogether perfect, but a giant aid to suspending disbelief and a huge contributor to the success of the movie.
Puh-leeze! Who in their right mind would believe all this nonsense about witches was real. The average American maybe, but I think the average Slashdot reader is a little more intelligent than that.
I just made the mistake of reading the first 4 chapters online. I just finished the 4th chapter, and was becoming totally immersed -- ready to stay up reading until I either finished the book or was no longer coherent. But now I'm stuck having to wait until August 31st. This sucks! _Ender's Game_ is still one of my favourite novels ever. I liked the sequels, but not as much as the original. It seems that with _Ender's Shadow_ Card has returned to the style that worked so well in the original.
One unfortunate thing is that -- as others have mentioned -- _Game_ seems to be somewhat simplistic, and I'm noticing the same thing about _Shadow_. This doesn't take away my enjoyment of the novels, but it doesn't leave me that much to think about when I stop reading, and gives me a sense of unfulfillment. I hope the rest of the book is a bit more thought-provoking like Speaker and Xenocide (I haven't even read Children yet, I'm ashamed to admit), but as entertaining as EG was. So far it seems to be only the latter, but I'm not going to complain that it's not boring.
One other thing: I have this suspicious feeling that many of the people who don't like EG are likely to be die-hard Star Trek fans. Either that, or not fans of any SciFi. I am not a fan of Star Trek at all -- I just find it incredibly boring. But I can imagine that the people who are nitpicking about the lack of details in EG, or the fact that parts of the plot have "been done before" being Star Trek fans. I don't care about those things because I'm most fascinated by the characters and storytelling in Card's novels (and to some extent the themes), and not the plot or the "war story" that some people seem to think it's supposed to be.
Am I the only one who has a difficult time "getting" this whole theory? The whole concept, at least as I currently understand it, just seems so... silly. It seems like a very amateurish and feeble attempt at explaining something that can't be explained. It reminds me of religion in that way. And in other ways it just seems like new terminology for things that are already very obvious.
It seems like the majority of the comments here are from people who have been able to grok it though. Maybe I just need to read more, as my knowledge on this subject is almost nil.
This is great news. Hopefully they recognize that there's a lot of good talent in Canada, and will do some of their R&D up here. Corel has always hired a lot of University co-ops, and VA could find some great talent by tapping into the Waterloo co-op program. I know a lot of people (like me:) ) would love to work for a Linux company. My idea of a dream workterm used to be working as a programmer at a place like RHAD Labs. My aspirations have changed a little since then -- I'm more interested in large scale OO software design -- but still, it's nice to know that something along those lines might soon be possible. Also, the prospect of full-time employment in the Valley after graduation is very enticing for a lot of people.
I don't think teaching teachers how to program will work. Teachers for the mostpart are just ordinary people -- the same kind of people who have 12:00 flashing on their VCR's. My dad is a teacher, and I constantly have to listen to his stories about the pathetic attempts the administration has made at incorporating computer science into the curriculum at his school (and other schools). It's quite sad, really.
Many good programmers of my generation (late teens and 20's mainly) started out when they were very young, often in elementary school. While you can probably start at any age, there's no doubt that exposing kids to programming at a young age is great in many cases. Had I not been programming for 10+ years prior to University, for all I know I might never have gone into this area. I might have missed out completely on something that I love to do. Also, in the workplace I've definitely noticed a difference in programming talent between people who started programming when they were young kids and those who didn't get into programming until late in high school or in university. That's not to say the people who start late can't end up being great programmers, but it seems to take longer. All of the really good programmers I know started out at a very young age.
I'm 20, and consider myself kind of lucky in some ways that I wasn't born 5 years later. I started getting exposed to computers at age 6 or so on an Apple ][. In those days you had to learn how to do things on your own. Had I started out on a PC with Windows, I don't think I'd be where I am today. Nowadays there are layers and layers of abstraction and people don't interact with the computer the same way they used to.
My user ID is 72. Does that mean I can call myself a hardcore, long-time Slashdot reader? I actually didn't start reading Slashdot until it started to get popular, but happened to be pretty bored at work when Rob implemented user accounts so I got one of the first. But it feels good to know that in 50 years, after we've achieved World Domination(tm), I'll be able to tell my grandchildren "I had user ID #72!":)
Blow it out yer ear, Water-boy. We get taught the same things here at Carleton for half the tuition price.;)
I'm not surprised. Like I said, CS at Waterloo is overrated IMHO. Most of the reputation comes from the co-op program, the fact that so many top students come here, and the math component. But I'm of the opinion that there should be even more required math courses for CS majors though (they cut out Calc III as a core requirement, which I don't understand). The actual CS curriculum however, is probably not much better than most other Canadian universities, and I'm worried the increase in enrollment is going to do a lot of damage to the program.
I'm personally double majoring in CS and Pure Mathematics so as to augment the CS stuff with something more interesting and challenging.
The goal of COMPUTER SCIENCE is not and should not be to give people practice "handing real applications programming". Like the previous poster said, that's the type of thing that you should learn at a technical college, in some employer training program, or the way most of us do - from experience.
Many of the most brilliant Computer Scientists have never done "real applications programming". Computer Science is MATHEMATICS. People need to realize this. You should be going to a technical college if the main thing you want to learn is to code.
Cobol and C programming? Are you sure that's a University, and not some technical college? What kind of a CS program would focus on specific technical skills (like C programming)? That's not Computer Science! And are you saying you didn't learn about data structures and algorithms, operating systems, computational complexity, the theory of computing, compiler design, artificial intelligence, etc.? Wow. This must be why CS at UW has such a good reputation - other schools are so terrible!
When was the last time mainstream music WASN'T crap? I can't remember such a time (I'm 20). Maybe in the 70's, but definitely not in the 80's and 90's. Of course, there is always good music from bands like Rush, U2, etc. that manage to do well without being trendy. I think in the last 20 years at least 95% of the mainstream music has always been terrible. This is to be expected though - the mass public is ignorant, and most people just don't appreciate good music. Very few people who buy CDs are actually serious music listeners.
You shouldn't be discouraged though. There is still a LOT of really good music out there. The Internet has really helped me find some of the really good, non-mainstream music that's out there. I listened to mostly popular, mainstream type stuff for the longest time when I was younger, because it's all I knew about. I really didn't start getting into progressive rock and jazz until around 1994 when the Internet began to get more popular. Now I'm listening to the likes of Spock's Beard, Al DiMeola, etc.
I run a severely hacked up version of RedHat 4.2, and if I were starting from scratch again I think I'd use Slackware. Ever since I started using Linux, I have always found it more "natural" to grab the source tarball and compile myself whenever I want to install a new program. This way it's easy to ensure I'm running the latest (or close to the latest) code, and leaves the source sitting ina convenient location so that I can easily hack around with it should I need to. Whenever I've tried to do stuff with RPM's, I've run into failed dependencies, an outdated RPM database, etc. My system is almost fully glibc2 now, and very little remains from that original RH4.2 installation.
Slashdot Mirror
I'm not sure of the details of these systems (how big is the star?), but is it possible that the system formed as a binary system, only there wasn't enough mass in the smaller "star" for fusion reactions to begin? This seems to be the obvious explanation, but I assume since there's no mention of this that it has been ruled out. Why? Is the mass ratio between the objects too great for them to have formed as a binary system?
I do agree with you that if you're not going to use good OO designs, then you may as well not use OO at all. Kind of like if you're going to write 1000 line functions with goto statements everywhere, you may as well not split your code up into functions at all. Just because it's being misapplied so frequently doesn't mean OO is the wrong tool.
A lot of it is poor management. Companies like to hire these cheap programmers who only know VB, Visual C++ and MFC. Companies like IBM that know what they're doing will hire real, clueful software engineers to be involved with their projects. They know you can't take some typical $50k MFC programmer and give him an important role in designing an OO system. Now, it's unlikely that ANY company will have ONLY experienced object technologists working for them. There just aren't enough good people to go around. But a smart company will have at least one such person working on a particular project as the main architect, overseeing the design.
You're saying that because an OO design breaks in this situation -- where a non-OO design also breaks -- it's "completely overrated" and "doesn't deliver on it's promises"? What a total non sequitur. OO is designed to be a more accurate way to model large and complex real-world problem domain in software.
large == requires more than one developer
complex == multiple mutually exclusive goals
Such software is almost always long lived, and it usually makes sense to emphasis: understandability, flexibility, reusability, extensibility. These are the areas where OO is most powerful. This is why, for such systems, OO works well if used properly, and in my opinion is the best approach to take if you want to be successful.
Wrong. The classes that use this class will be broken too, because the methods Set/GetCustomerAddress() have changed. There is more than one addres now.
If you want to push through the concept of many addresses throughout the system, all the classes that use the member Customer.GetCustomer() (or SetCustomer()) must change the way they handle the addresses of this customer object. You may opt for workarounds, but they won't change the fundamental problem: they will just be that, workarounds.
Get/Set methods? Another symptom of a poor, data-oriented design. In fact, it has sounded throughout this thread like your concept of OO is actually pseudo-OO, ie. data modeling. A mechanism free, policy free pesudo-OO paradigm is probably even worse than the traditional, non-OO approach, because you end up with a lot of classes that aren't actually very useful by themselves resulting in tight coupling and less flexibility. If that's your idea of what true OO is, then it's no wonder you dislike it.
For example, why would the customer have a "GetAddress" method? Would a customer just give their address to anyone who asks? Unlikely. The customer might give it's address to another object if it was purchasing an item. You wouldn't have an item sent to two different addresses though, so objects other than the customer would only need to know about the single address.
Given a fairly standard design which uses the Builder pattern (see Design Patterns), your change to the database might mean changing two classes: the Customer class, and a CustomerReader class. Or something along those lines. The changes would certainly NOT start propagating throughout the system, unless the design was horrendous (in which case there would probably be the aforementioned Get/Set methods all over the place).
OO designs will break even more easily, because in such designs there are simply more places in which you have duplicated the underlying assumptions of your system.
No! Again, that's data modeling. What you are saying is the same as saying that OO systems are not flexible, and that's simply the complete opposite of the truth. A true OO design should be mechanism rich, but more general, more policy free than a non-OO design. A direct consequence of this is fewer dependencies amongst classes, and any assumptions about the underlying system being localized. This results in a very flexible architecture.
Of course it will have to change somewhere. But how is this different from a "normal", non-OO program? You'd still have to make the change. If anything the OO design is advantageous here, because any changes would only have to be made within a single class. In a non-OO design there's no guarantee the change isn't going to have to be reflected in more than once place.
Upon reading your original message again, you seem to be talking about querying the tables, fields, etc. and doing things dynamically based on what's there. I have no idea what exactly you're getting at, but there's no reason you couldn't do these types of things with an OO design. You seem to be saying that an OO design must be rigid and static, and tightly coupled with the data the application is using, but that's no more true than it is for a non OO design.
Of course a relational database is the best option. But there's definitely no reason you can't decouple the framework from the database stuff. The problems you're talking about only happen if you base the design of your application based on the DATA. That's completely the wrong approach. You design your framework based on the application domain. The flexibility to change the way data is accessed should be built into the design. You certainly shouldn't have your database structure duplicatd in your object model. If that's the case, the design isn't even object oriented.
For example, if a customer can suddenly have more addresses instead of one, the customer object will have read its address from a different table: it's, therefore, broken.
See, this is a perfect example of the design being wrong. Does a customer know his address? Yes. Does a customer know how to go into your database and store or retrieve his address from your files? I certainly hope not, and I hope you realize why this is wrong.
I don't even want to attempt to try and respond in full to your entire messge, because I could easily spend hours writing a huge essay in response. I'll just focus on the part where you discuss OO, since a pet peeve of mine are all the misconceptions I see about OO, particularly on Slashdot (they seem to be less prevalent in the industry).
Now, sorry if this comes off like a flame, but the above sounds like it's coming from someone who doesn't understand the real principles behind object oriented programming, and who does not have experience working on large-scale software projects. In my experience I have found the opposite of almost everything you say to be true. The only problem with object oriented development is that most programmers don't know how to do it properly.
I have seen projects succed and fail, and I am quite convinced that given competent designers, using an object oriented approach is guaranteed to be more successful (in terms of time, money, and risk) in a large project than other methods of design. There is an overwhelming amount of evidence out there that this is the case. Look into some of the research. Read some of the books on software engineering. You are right that an object oriented design will increase the overall complexity of your design. This is a good thing, since it's precisely what gives object oriented designs their inherent flexibility. Flexibility is the most important benefit of an object oriented design. Another consequence of an OO design is that it will drastically decrease the complexibility of the individual and components within your system. Even on the surface this should be obvious if you think about it. Clearly object oriented models better represent their associated real-world systems than other methods like data modelling. I don't see how anyone can argue that. Now, if the inherent complexity of a system is in the overall design, that is where it should stay, is it not? Other techniques only move the complexity elsewhere, which is less natural, and therefore inevitably more expensive to maintain. You have to expend more effort to constantly differentiate between your application domain and your model since they become quite different.
These business objects "know" your data structure, and, therefore, have to be informed of changes in it.
NOT TRUE!!! In a proper OO design, you do not have "data structures". You have data, which is distributed throughout the objects in your system and encapsulated by those objects. But you should never have to think about data structures. I suspect you have a lot of experience with bad OO designs where a lot of data is passed around. This happens a lot in practice, but is simply poor design.
only two reasons for this: a deeply rooted hate for Microsoft, and pure ignorance.
Actually, in my case it simply doesn't provide the flexibility I need to design complex, large-scale software systems. VB has it's place. I think it is a very good tool for prototyping, and in many cases is appropriate for develping the GUI front-end of an application. I don't use it myself, as I prefer other tools for those purposes, but I can see where it would be useful.
You may, for example, ask most classes, in code, what their properties are, what their methods are, and what their parent class is, and so on. C/C++ not only lack self-knowledge
You don't understand; VB is more of a high-level, dynamically typed scripting language. That's why it can do these things. One can debate the merits of static typing vs. dynamic typing, C++ vs. Smalltalk, etc. all day, however with a proper OO design, you should never need to ask a class what it's properties or methods are. There are rare cases where you might want to know if a class supports a certain interface, which is what dynamic_cast is for in C++. But by and large you're doing something wrong if you ever need these capabilities in C++.
If I let my imagination roam, I can think of a few million things that are scarier than WITCHES and magic. If I let my imagination roam, I can also pretend Santa Claus is real, or that Jesus really did walk on water. That doesn't change the fact that this has no basis in reality. They could have at least chosen something less cliche than witches.
Thank you! I've gone through a lot of these responses, and I keep seeing comments from people who loved the movie, and can't understand how anyone could possibly not like it. What really gets me is the theories these people have come up with to explain why some people don't like it. The two most common ones seem to be: young people "just don't get it", or that only people with imagination like it. How about: I SIMPLY THE WHOLE CONCEPT OF "WITCHES" RETARDED. I can see why people who believe in paranormal type stuff would like it. Otherwise, I think a lot of people are just gullible and will go for anything. It's hard for me to enjoy a movie where I'm sitting there the whole time thinking "this is so silly".
they could have broken them. They could have divulged that BW was fake in September(imagine
how pissed you'd be!). The way they did it, everybody going to the movie sorta heard some people saying it was real and some people not--not altogether perfect, but a giant aid to suspending disbelief and a huge contributor to the success of the movie.
Puh-leeze! Who in their right mind would believe all this nonsense about witches was real. The average American maybe, but I think the average Slashdot reader is a little more intelligent than that.
I just made the mistake of reading the first 4 chapters online. I just finished the 4th chapter, and was becoming totally immersed -- ready to stay up reading until I either finished the book or was no longer coherent. But now I'm stuck having to wait until August 31st. This sucks! _Ender's Game_ is still one of my favourite novels ever. I liked the sequels, but not as much as the original. It seems that with _Ender's Shadow_ Card has returned to the style that worked so well in the original.
One unfortunate thing is that -- as others have mentioned -- _Game_ seems to be somewhat simplistic, and I'm noticing the same thing about _Shadow_. This doesn't take away my enjoyment of the novels, but it doesn't leave me that much to think about when I stop reading, and gives me a sense of unfulfillment. I hope the rest of the book is a bit more thought-provoking like Speaker and Xenocide (I haven't even read Children yet, I'm ashamed to admit), but as entertaining as EG was. So far it seems to be only the latter, but I'm not going to complain that it's not boring.
One other thing: I have this suspicious feeling that many of the people who don't like EG are likely to be die-hard Star Trek fans. Either that, or not fans of any SciFi. I am not a fan of Star Trek at all -- I just find it incredibly boring. But I can imagine that the people who are nitpicking about the lack of details in EG, or the fact that parts of the plot have "been done before" being Star Trek fans. I don't care about those things because I'm most fascinated by the characters and storytelling in Card's novels (and to some extent the themes), and not the plot or the "war story" that some people seem to think it's supposed to be.
This still is inconsistent though. We should really be measuring time in meters.
Not all rectangles are squares, but all squares are rectangles.
:)
Not if you're an object-oriented programmer.
Am I the only one who has a difficult time "getting" this whole theory? The whole concept, at least as I currently understand it, just seems so ... silly. It seems like a very amateurish and feeble attempt at explaining something that can't be explained. It reminds me of religion in that way. And in other ways it just seems like new terminology for things that are already very obvious.
It seems like the majority of the comments here are from people who have been able to grok it though. Maybe I just need to read more, as my knowledge on this subject is almost nil.
This is great news. Hopefully they recognize that there's a lot of good talent in Canada, and will do some of their R&D up here. Corel has always hired a lot of University co-ops, and VA could find some great talent by tapping into the Waterloo co-op program. I know a lot of people (like me :) ) would love to work for a Linux company. My idea of a dream workterm used to be working as a programmer at a place like RHAD Labs. My aspirations have changed a little since then -- I'm more interested in large scale OO software design -- but still, it's nice to know that something along those lines might soon be possible. Also, the prospect of full-time employment in the Valley after graduation is very enticing for a lot of people.
BASIC?
I don't think teaching teachers how to program will work. Teachers for the mostpart are just ordinary people -- the same kind of people who have 12:00 flashing on their VCR's. My dad is a teacher, and I constantly have to listen to his stories about the pathetic attempts the administration has made at incorporating computer science into the curriculum at his school (and other schools). It's quite sad, really.
Many good programmers of my generation (late teens and 20's mainly) started out when they were very young, often in elementary school. While you can probably start at any age, there's no doubt that exposing kids to programming at a young age is great in many cases. Had I not been programming for 10+ years prior to University, for all I know I might never have gone into this area. I might have missed out completely on something that I love to do. Also, in the workplace I've definitely noticed a difference in programming talent between people who started programming when they were young kids and those who didn't get into programming until late in high school or in university. That's not to say the people who start late can't end up being great programmers, but it seems to take longer. All of the really good programmers I know started out at a very young age.
I'm 20, and consider myself kind of lucky in some ways that I wasn't born 5 years later. I started getting exposed to computers at age 6 or so on an Apple ][. In those days you had to learn how to do things on your own. Had I started out on a PC with Windows, I don't think I'd be where I am today. Nowadays there are layers and layers of abstraction and people don't interact with the computer the same way they used to.
My user ID is 72. Does that mean I can call :)
myself a hardcore, long-time Slashdot reader?
I actually didn't start reading Slashdot until
it started to get popular, but happened to be
pretty bored at work when Rob implemented user
accounts so I got one of the first. But it
feels good to know that in 50 years, after we've
achieved World Domination(tm), I'll be able to
tell my grandchildren "I had user ID #72!"
Wasn't the "Linus joins Microsoft" thing done last year? In any case, I think you could have a LOT more fun with an April Fool's joke involving RMS. :)
Blow it out yer ear, Water-boy. We get taught the same things here at Carleton for half the tuition price. ;)
I'm not surprised. Like I said, CS at Waterloo is overrated IMHO. Most of the reputation comes from the co-op program, the fact that so many top students come here, and the math component. But I'm of the opinion that there should be even more required math courses for CS majors though (they cut out Calc III as a core requirement, which I don't understand). The actual CS curriculum however, is probably not much better than most other Canadian universities, and I'm worried the increase in enrollment is going to do a lot of damage to the program.
I'm personally double majoring in CS and Pure Mathematics so as to augment the CS stuff with something more interesting and challenging.
The goal of COMPUTER SCIENCE is not and should not be to give people practice "handing real applications programming". Like the previous poster said, that's the type of thing that you should learn at a technical college, in some employer training program, or the way most of us do - from experience.
Many of the most brilliant Computer Scientists have never done "real applications programming". Computer Science is MATHEMATICS. People need to realize this. You should be going to a technical college if the main thing you want to learn is to code.
Cobol and C programming? Are you sure that's a University, and not some technical college? What kind of a CS program would focus on specific technical skills (like C programming)? That's not Computer Science! And are you saying you didn't learn about data structures and algorithms, operating systems, computational complexity, the theory of computing, compiler design, artificial intelligence, etc.? Wow. This must be why CS at UW has such a good reputation - other schools are so terrible!
When was the last time mainstream music WASN'T crap? I can't remember such a time (I'm 20). Maybe in the 70's, but definitely not in the 80's and 90's. Of course, there is always good music from bands like Rush, U2, etc. that manage to do well without being trendy. I think in the last 20 years at least 95% of the mainstream music has always been terrible. This is to be expected though - the mass public is ignorant, and most people just don't appreciate good music. Very few people who buy CDs are actually serious music listeners.
You shouldn't be discouraged though. There is still a LOT of really good music out there. The Internet has really helped me find some of the really good, non-mainstream music that's out there. I listened to mostly popular, mainstream type stuff for the longest time when I was younger, because it's all I knew about. I really didn't start getting into progressive rock and jazz until around 1994 when the Internet began to get more popular. Now I'm listening to the likes of Spock's Beard, Al DiMeola, etc.
I run a severely hacked up version of RedHat 4.2, and if I were starting from scratch again I think I'd use Slackware. Ever since I started using Linux, I have always found it more "natural" to grab the source tarball and compile myself whenever I want to install a new program. This way it's easy to ensure I'm running the latest (or close to the latest) code, and leaves the source sitting ina convenient location so that I can easily hack around with it should I need to. Whenever I've tried to do stuff with RPM's, I've run into failed dependencies, an outdated RPM database, etc. My system is almost fully glibc2 now, and very little remains from that original RH4.2 installation.