"involves a mistake that any student learns to avoid in his or her first programming class"
You do realize this is the cause of most security vulnerabilities across the board, right? It's hardly a solved problem. Although in a way you are right, most first programming classes are taught using safer languages than C now, so maybe they are teaching the solution.
I've been a happy subscriber to pressplay for the last several months and have mixed feelings about it changing its name to napster due to the obviously negative impression that many (eg. company IT people) have of that name.
Nonetheless, its a great service for the most part: 1. I can download all the music I want for one flat fee of 10 bucks a month. I can only play it on the computer I downloaded it to, but thats the only computer (at home) I listen to music on. 2. I can stream music at work... this means I can go group an artist or genre or group of songs into a playlist and have it streamed to my while I work. I can also listen to their radio stations. 3. Purchasing music -.99 is not that bad considering that you pay 15 bucks for a cd on which you like 4 songs. Plus, you can rip the cd that you burn those songs to to mp3 and use on any device you want. That said, I haven't bought that much music from them.
Downsides: 1. Music selection - lots of good music, but some artists that I like are missing. 2. Pay - its taken me a bit of time to get used to the idea of paying something for music (albeit just 10 bucks a month)
Alot of posts here have said that this is some phoney service thats doomed to fail - a wannabe iTunes. I think that many more features are available than with iTunes and I urge you to give it a shot... even just the free trial if its available when they startup.
> I would have to see a specific example of a > something in OOP that is better at being reused > than a procedural/relational approach.
Although I'm not primarily a java programmer, a nice example that jumps out at me would be Java applets. You can simply inherit the majority of functionality that you do not need to change from code provided in the framework and simply provide your own implementation changes where appropriate. (I was going to use MFC as an example, but it sucks so I might have been disproving my own point). This amounts to creating an entirely new "noun" with fairly complex functionality in very few lines of code. Perhaps the cost here is knowing what does go one behind the scenes.
Certainly the same effect could be achieved by using OO-like practices in a proceedural (or possibly relational?) context, but it would not be nearly as elegant. I believe this is the case with the majority of OOP benefits.
Furthermore, designing using very specific "nouns" has the side affect of predisposing your code to reuse. When you go to program something else and need that same "noun" you already have it. I have found that proceedural programmers tend not design their software in a way that allows it to be immediately applicable to other tasks.
> 1. Some people just seem to think better under > OOP due to their *particular* brain/phsycology.
hmmm.. never gave too much thought to this, but it seems most programming paradigms use some kind of analogy model to help their users. Nonetheless, if what you say is true, you are giving a good arguement FOR OOP.
> 2. Written OO material tends to overemphasize > certain change patterns that OO is particular > good at, at the expense of change patterns that > OOP has a tougher time with. IOW, they present > a non-representative (frequency-wise) list of > change problems, and then conveniently show > OOP "fixing" them.
I'm definitely interested in what you're suggesting. Do you have any references that catalog some of these different problems OO struggles with (and other paradigms do not)?
Most of the opinions that I have are based on either studying or maintaining code written with various approaches. I'm by no means an OO zealot and can appreciate elegance in any form. However, the OO code I've seen *tends* to be more readable/elegant than most proceedural. And the bad OO code is sometimes a result of using alot of proceedural ideas (or in some cases, design problems that could be fixed w/ GoF patterns:)
I found the ideas on your site to be really interesting... Obviously, you are taking exception to the idea of OOP and not patterns. I certainly see the value you in your approach. You appear correct that in some circumstances, a change in overall design could be realized just as quickly using a relational model (in some cases.) (I'm sure you would argue more quickly, but I am not convinced of that)
Where it appears to fall short is in the area of reuse. Your code is written extremely specifically for the task at hand and does not seem like it could be moved over to a new domain. (I haven't had a chance to browse all of your articles so maybe you address this.)
The functional programming models you talk about tend to be more similiar to the OOP approach (heavy use of polymorphism) only using far less "nouns".
Anyways, thanks for the link to your site which seems to be a really interesting resource.
Don't mean for this to be the flame you expected, I'd just like to give the other side of the argument.
> Near as I can tell, design patterns are to > programming what paint-by-numbers is to art.
I can see how this comparison would occur to someone with little experience using Design Patterns. I think a better explanation is this:
Most anyone can, given a programming problem, come up with a solution that works. If you're working on a quick and dirty piece of code for one-time use, then using patterns might not be the answer. However, its very common that people want to add new features... support new file formats, etc. Most quick and dirty designs, even by good programmers start looking really bad when new features are added. If the system grows significantly larger than the original developer expected then the design becomes completely unwieldy and they start to see how it should have been designed in the first place. The next time that developer has to design a similiar piece of software they wont make the same mistakes.
This is where Design Patterns come in. A designer/programmer well versed in these patterns can see the end result of that first scenario before it happens. Learning design patterns helps teach good design faster. The solution to each common design problem is encapsulated in a well documented pattern.
> I haven't met a gifted programmer who made > extensive use of them,
Wow, I've met alot of people who think they are gifted programmers and write really badly designed code that works (at first) who don't use design patterns.
On the other hand, if you judge code and design not by how much of a hack it is, but by how elegant it is, then Design patterns can make a huge difference. There is nothing beautiful about trying to cram a square peg in a round hole, even when it works.
So, instead of "paint-by-numbers", I see design patterns as a "magic eight ball" that can tell you what problems your design will have before you even start programming.:)
> but they seem to be a sort of helpful template > for average coders of the sort hired in legion > strength for "enterprise" projects in Java and > the like.
While I am a fairly technical c++ programmer by trade, there is no reason to belittle java or "enterprise" programmers. There are some HUGE projects out there that simply cannot by done right by a few people hacking away. And I feel sorry for them when it becomes time for V2.
Despite how good this may seem, I still feel uncomfortable whenever there are software patents. Although I prefer something like the BSD license to the GPL for software projects, I can see why people would prefer to prevent people from stealing their code without contributing to it. However, for patents, the GPL seems to go against my very beliefs of freedom. People should be allowed to implement any algorithm and use it for any project (commercial or Open Source). That seems more important to me than anything in the Open Source philosophy. Patenting things under the GPL license violates that freedom.
The stupid lameness filter won't let you use == in a subject... It seems like that should be fixed (at least for a site like this)
This is an introductory course that is likely for nonmajors... Theres nothing wrong with using a gimmick to stimulate interest in students and expand the study of philosophy The matrix is an entertaining movie and likely was many peoples first introduction to some of the philisophical questions. A class that uses that as a jumping point into more advanced discussion is a brilliant way to give people a taste of philosophy in an academic setting.
Times have changed significantly since the days of amiga though. Back then, an operating system was doomed to fail in a market competing with a more popular os.
Several things have come about now that are making that nearly irrelevant. First of all, one of the tenets of the slashdot world, open source, means that there is an entire library of software that can be ported to linux, be, windows, mac, etc... It may be more trouble to port to some of those operating systems than others, but lets face it, every os has people willing to put in the time and effort.
Another reason revolves around the principle use of computers in the late 90s, the internet. Basically, any computer with any os can post and read the same information as any other. It is irrelevant what was used to create it. (admittedly, some operating systems are slower at getting support for new web technologies like java (not that its all that new), but it will come.)
Furthermore, I believe that this trend will continue to the point where applications will run on nearly any platform (like java, although I realize/.'ers aren't big fans)... and even in cases where executables aren't portable, source code will become increasingly portable. (due in many cases to open api's such as opengl beating out closed apis like directx).
The fact is, though, linux and beos are not competing with each other since they are both pushing computing towards a less os-centric picture and towards a situation where all users will have their choice of oses and will not lose much in the way of available content based on their choice. If beos gains popularity it helps linux (and vice versa).
It is, in some ways, unfortunate that beos is not open source, but I respect the need of companies to sell their product. It is very cheap compared with what microsoft sells the non-upgrade versions of its os for.
Sorry for rambling on for so long, but I just feel that everyone benefits from the success of a non-ms-os (not that I don't have a win32 computer myself) and we should realize that, in the new os market, it doesn't have to be 100% ms or 100% linux.
Slashdot Mirror
"involves a mistake that any student learns to avoid in his or her first programming class"
You do realize this is the cause of most security vulnerabilities across the board, right? It's hardly a solved problem. Although in a way you are right, most first programming classes are taught using safer languages than C now, so maybe they are teaching the solution.
I assume its application somehow involves simulation of cows or chicken-feed molecules?
I've been a happy subscriber to pressplay for the last several months and have mixed feelings about it changing its name to napster due to the obviously negative impression that many (eg. company IT people) have of that name.
.99 is not that bad considering that you pay 15 bucks for a cd on which you like 4 songs. Plus, you can rip the cd that you burn those songs to to mp3 and use on any device you want. That said, I haven't bought that much music from them.
Nonetheless, its a great service for the most part:
1. I can download all the music I want for one flat fee of 10 bucks a month. I can only play it on the computer I downloaded it to, but thats the only computer (at home) I listen to music on.
2. I can stream music at work... this means I can go group an artist or genre or group of songs into a playlist and have it streamed to my while I work. I can also listen to their radio stations.
3. Purchasing music -
Downsides:
1. Music selection - lots of good music, but some artists that I like are missing.
2. Pay - its taken me a bit of time to get used to the idea of paying something for music (albeit just 10 bucks a month)
Alot of posts here have said that this is some phoney service thats doomed to fail - a wannabe iTunes. I think that many more features are available than with iTunes and I urge you to give it a shot... even just the free trial if its available when they startup.
I wasn't making any claims about their worth, just that they are a great example of how OO design facilitates code reuse.
Substitute Java servlets if it makes you feel better.. they work the same way.
> I would have to see a specific example of a
:)
> something in OOP that is better at being reused
> than a procedural/relational approach.
Although I'm not primarily a java programmer, a nice example that jumps out at me would be Java applets. You can simply inherit the majority of functionality that you do not need to change from code provided in the framework and simply provide your own implementation changes where appropriate. (I was going to use MFC as an example, but it sucks so I might have been disproving my own point). This amounts to creating an entirely new "noun" with fairly complex functionality in very few lines of code. Perhaps the cost here is knowing what does go one behind the scenes.
Certainly the same effect could be achieved by using OO-like practices in a proceedural (or possibly relational?) context, but it would not be nearly as elegant. I believe this is the case with the majority of OOP benefits.
Furthermore, designing using very specific "nouns" has the side affect of predisposing your code to reuse. When you go to program something else and need that same "noun" you already have it. I have found that proceedural programmers tend not design their software in a way that allows it to be immediately applicable to other tasks.
> 1. Some people just seem to think better under
> OOP due to their *particular* brain/phsycology.
hmmm.. never gave too much thought to this, but it seems most programming paradigms use some kind of analogy model to help their users. Nonetheless, if what you say is true, you are giving a good arguement FOR OOP.
> 2. Written OO material tends to overemphasize
> certain change patterns that OO is particular
> good at, at the expense of change patterns that
> OOP has a tougher time with. IOW, they present
> a non-representative (frequency-wise) list of
> change problems, and then conveniently show
> OOP "fixing" them.
I'm definitely interested in what you're suggesting. Do you have any references that catalog some of these different problems OO struggles with (and other paradigms do not)?
Most of the opinions that I have are based on either studying or maintaining code written with various approaches. I'm by no means an OO zealot and can appreciate elegance in any form. However, the OO code I've seen *tends* to be more readable/elegant than most proceedural. And the bad OO code is sometimes a result of using alot of proceedural ideas (or in some cases, design problems that could be fixed w/ GoF patterns
I found the ideas on your site to be really interesting... Obviously, you are taking exception to the idea of OOP and not patterns. I certainly see the value you in your approach. You appear correct that in some circumstances, a change in overall design could be realized just as quickly using a relational model (in some cases.) (I'm sure you would argue more quickly, but I am not convinced of that)
Where it appears to fall short is in the area of reuse. Your code is written extremely specifically for the task at hand and does not seem like it could be moved over to a new domain. (I haven't had a chance to browse all of your articles so maybe you address this.)
The functional programming models you talk about tend to be more similiar to the OOP approach (heavy use of polymorphism) only using far less "nouns".
Anyways, thanks for the link to your site which seems to be a really interesting resource.
Don't mean for this to be the flame you expected, I'd just like to give the other side of the argument.
:)
> Near as I can tell, design patterns are to
> programming what paint-by-numbers is to art.
I can see how this comparison would occur to someone with little experience using Design Patterns. I think a better explanation is this:
Most anyone can, given a programming problem, come up with a solution that works. If you're working on a quick and dirty piece of code for one-time use, then using patterns might not be the answer. However, its very common that people want to add new features... support new file formats, etc. Most quick and dirty designs, even by good programmers start looking really bad when new features are added. If the system grows significantly larger than the original developer expected then the design becomes completely unwieldy and they start to see how it should have been designed in the first place. The next time that developer has to design a similiar piece of software they wont make the same mistakes.
This is where Design Patterns come in. A designer/programmer well versed in these patterns can see the end result of that first scenario before it happens. Learning design patterns helps teach good design faster. The solution to each common design problem is encapsulated in a well documented pattern.
> I haven't met a gifted programmer who made
> extensive use of them,
Wow, I've met alot of people who think they are gifted programmers and write really badly designed code that works (at first) who don't use design patterns.
On the other hand, if you judge code and design not by how much of a hack it is, but by how elegant it is, then Design patterns can make a huge difference. There is nothing beautiful about trying to cram a square peg in a round hole, even when it works.
So, instead of "paint-by-numbers", I see design patterns as a "magic eight ball" that can tell you what problems your design will have before you even start programming.
> but they seem to be a sort of helpful template
> for average coders of the sort hired in legion
> strength for "enterprise" projects in Java and
> the like.
While I am a fairly technical c++ programmer by trade, there is no reason to belittle java or "enterprise" programmers. There are some HUGE projects out there that simply cannot by done right by a few people hacking away. And I feel sorry for them when it becomes time for V2.
Despite how good this may seem, I still feel uncomfortable whenever there are software patents. Although I prefer something like the BSD license to the GPL for software projects, I can see why people would prefer to prevent people from stealing their code without contributing to it.
However, for patents, the GPL seems to go against my very beliefs of freedom. People should be allowed to implement any algorithm and use it for any project (commercial or Open Source). That seems more important to me than anything in the Open Source philosophy. Patenting things under the GPL license violates that freedom.
The stupid lameness filter won't let you use == in a subject... It seems like that should be fixed (at least for a site like this)
Plus, since he is the original author of the work, he couldn't violate the GPL if he wanted to.
some quick math.... :)
1000kb/s * 600 meg cd 'backup' == 10 Min
it looks like your getting what you want... 600 megs is a lot
This is an introductory course that is likely for nonmajors... Theres nothing wrong with using a gimmick to stimulate interest in students and expand the study of philosophy
The matrix is an entertaining movie and likely was many peoples first introduction to some of the philisophical questions. A class that uses that as a jumping point into more advanced discussion is a brilliant way to give people a taste of philosophy in an academic setting.
Times have changed significantly since the days of amiga though. Back then, an operating system was doomed to fail in a market competing with a more popular os.
Several things have come about now that are making that nearly irrelevant. First of all, one of the tenets of the slashdot world, open source, means that there is an entire library of software that can be ported to linux, be, windows, mac, etc... It may be more trouble to port to some of those operating systems than others, but lets face it, every os has people willing to put in the time and effort.
Another reason revolves around the principle use of computers in the late 90s, the internet. Basically, any computer with any os can post and read the same information as any other. It is irrelevant what was used to create it. (admittedly, some operating systems are slower at getting support for new web technologies like java (not that its all that new), but it will come.)
Furthermore, I believe that this trend will continue to the point where applications will run on nearly any platform (like java, although I realize /.'ers aren't big fans)... and even in cases where executables aren't portable, source code will become increasingly portable. (due in many cases to open api's such as opengl beating out closed apis like directx).
The fact is, though, linux and beos are not competing with each other since they are both pushing computing towards a less os-centric picture and towards a situation where all users will have their choice of oses and will not lose much in the way of available content based on their choice. If beos gains popularity it helps linux (and vice versa).
It is, in some ways, unfortunate that beos is not open source, but I respect the need of companies to sell their product. It is very cheap compared with what microsoft sells the non-upgrade versions of its os for.
Sorry for rambling on for so long, but I just feel that everyone benefits from the success of a non-ms-os (not that I don't have a win32 computer myself) and we should realize that, in the new os market, it doesn't have to be 100% ms or 100% linux.
Chris