This worked well in germany with toy manufacturers. They were required to pick up the tab for any packaging that ended up in the municipal waste stream. Within weeks the companies were selling just the Barbie doll and not the giant cardboard box and plastic. What, was the Barbie doll going to spoil sitting there?
What many people don't realize is that a lot of our environmental problems are caused by regulatory environments that allow companies to shove costs off onto the government. When a cost is external, it doesn't affect the company's actions. When the cost is internalized and suddenly it makes economic sense to recycle components and use less packaging, then the environmentally correct action flows naturally. You can't impose environmental requirements that add cost, it doesn't work very well. You CAN make a company pay the real cost of disposing of its waste, and being motivated by profit, get companies to make the right decisions for economic reasons.
The best introduction that shows the importance of scripting languages was written by John K. Ousterhout. He outlined four main advantages of mixed scripting language + compiled language programming in his famous paper Scripting: Higher Level Programming for the 21st Century
He pointed out that scripting languages represent a new type of languages: glue languages....Scripting languages such as Perl and TCL represent a very different style of programming than system programming languages such as C or Java. Scripting languages are designed for "gluing" applications; they use typeless approaches to achieve a higher level of programming and more rapid application development than system programming languages. Increases in computer speed and changes in the application mix are making scripting languages more and more important for applications of the future.
The second main idea is that scripting languages presuppose component programming and component framework can benefit from scripting languages. If you think a little bit, you can even consider Unix shell as the historically first component oriented language;-)....Scripting languages and system programming languages are complementary, and most major computing platforms since the 1960's have provided both kinds of languages. The languages are typically used together in component frameworks, where components are created with system programming languages and glued together with scripting languages. However, several recent trends, such as faster machines, better scripting languages, the increasing importance of graphical user interfaces and component architectures, and the growth of the Internet, have greatly increased the applicability of scripting languages. These trends will continue over the next decade, with more and more new applications written entirely in scripting languages and system programming languages used primarily for creating components....Scripting languages such as Perl, Python, Rexx, Tcl, Visual Basic, and the Unix shells represent a very different style of programming than system programming languages. Scripting languages assume that there already exists a collection of useful components written in other languages. Scripting languages aren't intended for writing applications from scratch; they are intended primarily for plugging together components. For example, Tcl and Visual Basic can be used to arrange collections of user interface controls on the screen, and Unix shell scripts are used to assemble filter programs into pipelines. Scripting languages are often used to extend the features of components but they are rarely used for complex algorithms and data structures; features like these are usually provided by the components. Scripting languages are sometimes referred to as glue languages or system integration languages.
The third important idea is that scripting languages are better used in tandem with compiled languages. The latter should be used for the component building where as scripting languages should be used a s a glue.... A scripting language is not a replacement for a system programming language or vice versa. Each is suited to a different set of tasks. For gluing and system integration, applications can be developed 5-10x faster with a scripting language; system programming languages will require large amounts of boilerplate and conversion code to connect the pieces, whereas this can be done directly with a scripting language. For complex algorithms and data structures, the strong typing of a system programming language makes programs easier to manage. Where execution speed is key, a system programming language can often run 10-20x faster than a scripting language because it makes fewer run-time checks.
Most of the major computing platforms over the last 30 years have provided both system programming and scripting languages
I write ansi sql 99% of the time. it runs fine anywhere - sql server, sybase, oracle, access, whatever.
you are also assuming that a company will EVER change it's database. in my experience, this just DOES NOT ever happen. it would be so prohibitively expensive and error prone, that if you spend ONE SECOND making sure your code can be ported to another database system, you're wasting valuable company time. i've worked at a half dozen different companies. none of them ever changed database systems or OS platforms. 4 of them are out of business at this point, so the choice of an OS platform or database system has a longevity equal to the length of the company - portability to another system is not a feature that adds value. besides, web services and xml allow you to write completely platform agnostic applications while taking full advantage of native OS code. if you don't care whether data is stored in a database or a filesystem, you're throwing out the billions spent refining the capabilities of the database.
have you ever personally worked at a company that switched their mission critical systems to another OS or database? if so.... what the hell did they do it for? i can't imagine how long the time period would be before you'd see s return on investment - which is what drives the business world, not CS idealism.
Re:A lot of people seem to be adamant against Java
on
Head First Java
·
· Score: 1
very good point.
i wouldn't do the above in a procedural language anyway, i'd normally put all the data in rdbms tables and access it with stored procs - sort of the same thing I guess, even if the table structure changes the proc can still have the same inputs and outputs so the interface remains the same. storing the data in a database just seems most natural for the sorts of problems i work on.
Re:most misunderstoof language in the world
on
Head First Java
·
· Score: 1
Private
Private members are made by the constructor. Ordinary vars and parameters of the constructor becomes the private members.
function Container(param) {
this.member = param;
var secret = 3;
var self = this;
}
This constructor makes three private instance variables: param, secret, and self. They are attached to the object, but they are not accessible to the outside, nor are they accessible to the object's own public methods. They are accessible to private methods. Private methods are inner functions of the constructor.
function Container(param) {
function dec() {
if (secret > 0) {
secret -= 1;
return true;
} else {
return false;
}
}
this.member = param;
var secret = 3;
var self = this;
}
The private method dec examines the secret instance variable. If it is greater than zero, it decrements secret and returns true. Otherwise it returns false. It can be used to make this object limited to three uses.
By convention, we make a private self parameter. This is used to make the object available to the private methods. This is a workaround for an error in the ECMAScript Language Specification which causes this to be set incorrectly for inner functions.
Private methods cannot be called by public methods. To make private methods useful, we need to introduce a privileged method.
Re:A lot of people seem to be adamant against Java
on
Head First Java
·
· Score: 1
Odd, I have found time and again that having things stored in the database allows applications on multiple platforms in different languages to work together beautifully. Everyone writes drivers for connecting to the major databases, so all apps that can connect to a database can work on a common set of info. It's probably that when you're good with a tool, whether it's the perfect tool or not, it's often a better tool than the 'perfect tool' you don't know, and I've been doing complex SQL for years so it's just how I think about the problems.
Re:A lot of people seem to be adamant against Java
on
Head First Java
·
· Score: 1
I develop business applications on a small to medium scale with constant refinement of requirements throughout the process. I cannot imagine how I could define interfaces completely before beginning development. Small to medium custom business apps seems to be one problem area where OOP offers little or no advantage.
One other valid criticism of OOP in my book is that it deals too much with data in the programming language rather than stored in a table. I wouldn't solve the above problem with a procedural function in real life, everything would be in tables - the person's income, the tax rate for that income level, conditions that justify exceptions to the rules, additional formulas to be applied, etc and I'd put my logic into the SQL joins between them. So, I see a common underuse of relational databases abilities in the OOP paradigm - just a thought. You pick the right tools/methodologies for the job.
Re:Scripting + component/subs beats OO
on
Head First Java
·
· Score: 1
When I mentioned scripting I was mainly thinking of Tcl acting as the glue for C. Procedural programming in a, to me, nice form where you ignore the contents of the black boxes. Also of course works for VBScript calling COM objects, etc.
I had to work on a site with 43 separate com objects controlling the shopping cart, and each object always called at least 3, and up to 8 different other com objects each time it was called. The problem was all the 'glue' logic being embedded in the black boxes, and it still makes me shiver to think of how bad it was. I essentially don't care what's in a black box - if it's an object, a stored procedure, whatever, I just don't like to see application logic embedded at that level.
Re:A lot of people seem to be adamant against Java
on
Head First Java
·
· Score: 1
//------- Thin Wire Approach -------- module taxPerson_B(income: decimal, _
filing: string, _
dependants: int)// income: gross income// filing: filing status, "w2" or "1099"// dependants: number of dependants
declare taxable: decimal
taxable = income
if filing = "w2"
taxable = taxable * 0.8
else
taxable = taxable * 0.9
end if
taxable = taxable - (2000 * dependants)
return taxable end module
In the first approach, we pass an object of type personClass. (The names are only illustrative, and not meant to demonstrate good nomenclature.) The taxPerson_A module presumes that the passed object will have certain interfaces. In this case these interfaces include "income", "filing", and "dependants". (In some OO languages, responding to these protocol names is sufficient. In others, the inheritance tree is checked to make sure the passed object is of the proper pedigree.) If personClass is changed such that "income" is removed and replaced with "netIncome" (because gross can be calculated rather than explicitly stored), then module taxPerson_A will not work without modification. However, taxPerson_B will continue to work without internal modification. (Perhaps some of the calls to taxPersion_B may need to be altered, but no changes are needed to the module itself.)
taxPerson_B can also be reused in a different application with more ease. If we copied/moved taxPerson_A, we would have to re-create personClass on the new system also. This may not be desirable. For example, the new system may already have it's version of personClass that has different names mapped in different ways. For example, the new system may store/reference the filing type in a completely different class.
Thus, the fat wire approach has coupled two modules together in ways that the skinny wire approach has
... from http://www.geocities.com/SiliconValley/Lab/6888/mi scoop.htm
most misunderstoof language in the world
on
Head First Java
·
· Score: 1
JavaScript's prototyping is great in my opinion.
And the conception that you can't have private members in Javascript is just wrong.
Scripting + component/subs beats OO
on
Head First Java
·
· Score: 1
Clear, readable structure and flow is vital to the maintainability of a body of code, and in my opinion is better expressed with procedural script calling powerful compiled code than with the morass OO too often becomes. You don't write the NOVEL in script, you write the table of contents and the general narrative - the individual chapters and footnotes you write in C, use a C++ dll, use a Java object, whatever the most appropriate technology is. Any other procedural/scripting programmers out there that agree?
Some quotes for all the OOP CS-propagandized out there:
"In other words, the needs of '"infrastructure components" and of business software modeling are sufficiently different that the best techniques for one may not apply to the other. The longer-term patterns of change are just different for each."
The pre-OO thinking was that a system should be a series of black boxes with clearly defined inputs and outputs ("wires"). These wires carried relatively simple signals between the various black boxes of the system. The complexity was in the black boxes, not in the wires.
However, OO thinking tends to complicate the wires. In fact in OO the wires themselves tend to become black boxes. In pre-OO thinking the wires were usually simple data like numbers, strings, and occasionally arrays and tables (or handles/pointers to them).
In OO the inputs and outputs are often complex OO classes which often have complex behavior attached to them. Thus, the wires in OO are actually no different from black boxes themselves.
But why is a bunch of tightly interconnected boxes bad? Mostly because it is tougher to comprehend each black box in isolation. A given black box will often depend on the behavior of one or more of it's inputs and outputs (parameters) in OO thinking.
Although OOP's version of black boxes may still be black to the user of them (programmer), they are essentially gray boxes to *other* boxes, and thus the programmer is forced to consider the *combined* behavior.
You may have to even follow a long chain of classes to sufficiently understand the original module or method. It is perhaps possible that you may have to understand an entire OO system just to fully comprehend the behavior (or results) of a single piece of code. OO may give the illusion of simple, independent pieces; but is actually building one or a few very large, complicated black boxes instead.
"encapsulation", "reusability", "modularity" all features of good coding, whether the coding is procedural or object-oriented.
Probably even more important for good coding is EXTENSIVE comments and self-documenting variable names. If I never see the variables 'x', 'y', 'i', etc. again in my life I'd be a happy man. For god's sake tell me what you're counting and why.
Time and again I've seen how writing easy to maintain code is SO much more important than writing 'optimized' code. You can't pre-optimize for speed to any great extent, you first need numbers showing where the bottlenecks are. You CAN pre-optimize for modularity/extensibility which is much more important IMHO.
HEY!! Possible licensing violation
on
Head First Java
·
· Score: 1
The licensing for Java CLEARLY states that it cannot be used to control nuclear reactors, pacemakers, suborbital rockets, and particle physics experiments.
2 of these are real licensing requirements by the way.
He just needs to deliberately let a password be stolen, and then sue Charter for damages for not responding to his complaint by securing their server. Corporations are only motivated by money, so it only becomes a management concern when it affects their bottom line.
Calling Visa would work great too, but I wouldn't want to go so far as letting my card get stolen just for satisfaction.
it's not a contract if you don't agree. you read the license, you say 'no'. you then proceed to browse the site. it doesn't even have the power of a click through.
Tablizer, you're doing a great job presenting this viewpoint. So often the arguments I hear for object oriented are really just arguments for good procedural practice.
the html tags would be a piss poor example of an object.
a good example of an object would be 'customer', 'order', 'account', 'product', etc.
there's a performance hit to instantiate an object. why do so when simple client or (as a second line of defense) server side scripting can do the validation you're talking about? With Visual Interdev Microsoft tried to do the kind of thing you're talking about, having HTML fields generated by programming code, and it was a complete waste of time. HTML works, just use it directly, no fancy interface needed.
This is anecdotal, not evidence. Most studies of the issue show gains in capability with OO only after several years, it's just become accepted as 'better' as a religious belief. Well documented, modular code is all you need for quick modification of existing code.
Maybe you work at a shop that did a big push for quality, and incorporated modularity and good documentation in with the conversion to OO? Speed of development is definitely the biggest thing in the web, and with my standard include libraries I can crank out pages just as fast as you can with your standard objects, but I think it's a lot easier to develop new libraries than it is to develop new objects.
Why do you feel better getting that piece of data from $someObject->getX() than you do when the data is retrieved from the getX() function in an include file? Functions and includes allow you to have the same modularity as OO programming. Modularity is a design consideration and can be implemented with procedural proframming as well as it can with OO programming.
It all depends on what your needs are what is appropriate. For most sites, putting everything in objects is overkill. I worked on a site that had 42 COM objects to manage the site, about 35 to manage the shopping cart. Complete crap, very confusing. Not the fault of OO, just bad programming. A well designed procedural system is better than a mediocre OO system any day. And, IMHO, a well-designed procedural system is better than a well-designed OO system almost any day too, for the performance if nothing else.
There is always a place for modularity - that's not the same as OO.
Slashdot Mirror
This worked well in germany with toy manufacturers. They were required to pick up the tab for any packaging that ended up in the municipal waste stream. Within weeks the companies were selling just the Barbie doll and not the giant cardboard box and plastic. What, was the Barbie doll going to spoil sitting there?
What many people don't realize is that a lot of our environmental problems are caused by regulatory environments that allow companies to shove costs off onto the government. When a cost is external, it doesn't affect the company's actions. When the cost is internalized and suddenly it makes economic sense to recycle components and use less packaging, then the environmentally correct action flows naturally. You can't impose environmental requirements that add cost, it doesn't work very well. You CAN make a company pay the real cost of disposing of its waste, and being motivated by profit, get companies to make the right decisions for economic reasons.
from: http://www.softpanorama.org/People/scripting_guant s.shtml
...Scripting languages such as Perl and TCL represent a very different style of programming than system programming languages such as C or Java. Scripting languages are designed for "gluing" applications; they use typeless approaches to achieve a higher level of programming and more rapid application development than system programming languages. Increases in computer speed and changes in the application mix are making scripting languages more and more important for applications of the future.
;-). ...Scripting languages and system programming languages are complementary, and most major computing platforms since the 1960's have provided both kinds of languages. The languages are typically used together in component frameworks, where components are created with system programming languages and glued together with scripting languages. However, several recent trends, such as faster machines, better scripting languages, the increasing importance of graphical user interfaces and component architectures, and the growth of the Internet, have greatly increased the applicability of scripting languages. These trends will continue over the next decade, with more and more new applications written entirely in scripting languages and system programming languages used primarily for creating components. ...Scripting languages such as Perl, Python, Rexx, Tcl, Visual Basic, and the Unix shells represent a very different style of programming than system programming languages. Scripting languages assume that there already exists a collection of useful components written in other languages. Scripting languages aren't intended for writing applications from scratch; they are intended primarily for plugging together components. For example, Tcl and Visual Basic can be used to arrange collections of user interface controls on the screen, and Unix shell scripts are used to assemble filter programs into pipelines. Scripting languages are often used to extend the features of components but they are rarely used for complex algorithms and data structures; features like these are usually provided by the components. Scripting languages are sometimes referred to as glue languages or system integration languages.
... A scripting language is not a replacement for a system programming language or vice versa. Each is suited to a different set of tasks. For gluing and system integration, applications can be developed 5-10x faster with a scripting language; system programming languages will require large amounts of boilerplate and conversion code to connect the pieces, whereas this can be done directly with a scripting language. For complex algorithms and data structures, the strong typing of a system programming language makes programs easier to manage. Where execution speed is key, a system programming language can often run 10-20x faster than a scripting language because it makes fewer run-time checks.
The best introduction that shows the importance of scripting languages was written by John K. Ousterhout. He outlined four main advantages of mixed scripting language + compiled language programming in his famous paper Scripting: Higher Level Programming for the 21st Century
He pointed out that scripting languages represent a new type of languages: glue languages.
The second main idea is that scripting languages presuppose component programming and component framework can benefit from scripting languages. If you think a little bit, you can even consider Unix shell as the historically first component oriented language
The third important idea is that scripting languages are better used in tandem with compiled languages. The latter should be used for the component building where as scripting languages should be used a s a glue.
Most of the major computing platforms over the last 30 years have provided both system programming and scripting languages
I write ansi sql 99% of the time. it runs fine anywhere - sql server, sybase, oracle, access, whatever.
you are also assuming that a company will EVER change it's database. in my experience, this just DOES NOT ever happen. it would be so prohibitively expensive and error prone, that if you spend ONE SECOND making sure your code can be ported to another database system, you're wasting valuable company time. i've worked at a half dozen different companies. none of them ever changed database systems or OS platforms. 4 of them are out of business at this point, so the choice of an OS platform or database system has a longevity equal to the length of the company - portability to another system is not a feature that adds value. besides, web services and xml allow you to write completely platform agnostic applications while taking full advantage of native OS code. if you don't care whether data is stored in a database or a filesystem, you're throwing out the billions spent refining the capabilities of the database.
have you ever personally worked at a company that switched their mission critical systems to another OS or database? if so.... what the hell did they do it for? i can't imagine how long the time period would be before you'd see s return on investment - which is what drives the business world, not CS idealism.
very good point.
i wouldn't do the above in a procedural language anyway, i'd normally put all the data in rdbms tables and access it with stored procs - sort of the same thing I guess, even if the table structure changes the proc can still have the same inputs and outputs so the interface remains the same. storing the data in a database just seems most natural for the sorts of problems i work on.
From here: http://www.crockford.com/javascript/private.html
Private
Private members are made by the constructor. Ordinary vars and parameters of the constructor becomes the private members.
function Container(param) {
this.member = param;
var secret = 3;
var self = this;
}
This constructor makes three private instance variables: param, secret, and self. They are attached to the object, but they are not accessible to the outside, nor are they accessible to the object's own public methods. They are accessible to private methods. Private methods are inner functions of the constructor.
function Container(param) {
function dec() {
if (secret > 0) {
secret -= 1;
return true;
} else {
return false;
}
}
this.member = param;
var secret = 3;
var self = this;
}
The private method dec examines the secret instance variable. If it is greater than zero, it decrements secret and returns true. Otherwise it returns false. It can be used to make this object limited to three uses.
By convention, we make a private self parameter. This is used to make the object available to the private methods. This is a workaround for an error in the ECMAScript Language Specification which causes this to be set incorrectly for inner functions.
Private methods cannot be called by public methods. To make private methods useful, we need to introduce a privileged method.
Odd, I have found time and again that having things stored in the database allows applications on multiple platforms in different languages to work together beautifully. Everyone writes drivers for connecting to the major databases, so all apps that can connect to a database can work on a common set of info. It's probably that when you're good with a tool, whether it's the perfect tool or not, it's often a better tool than the 'perfect tool' you don't know, and I've been doing complex SQL for years so it's just how I think about the problems.
I develop business applications on a small to medium scale with constant refinement of requirements throughout the process. I cannot imagine how I could define interfaces completely before beginning development. Small to medium custom business apps seems to be one problem area where OOP offers little or no advantage.
One other valid criticism of OOP in my book is that it deals too much with data in the programming language rather than stored in a table. I wouldn't solve the above problem with a procedural function in real life, everything would be in tables - the person's income, the tax rate for that income level, conditions that justify exceptions to the rules, additional formulas to be applied, etc and I'd put my logic into the SQL joins between them. So, I see a common underuse of relational databases abilities in the OOP paradigm - just a thought. You pick the right tools/methodologies for the job.
When I mentioned scripting I was mainly thinking of Tcl acting as the glue for C. Procedural programming in a, to me, nice form where you ignore the contents of the black boxes. Also of course works for VBScript calling COM objects, etc.
I had to work on a site with 43 separate com objects controlling the shopping cart, and each object always called at least 3, and up to 8 different other com objects each time it was called. The problem was all the 'glue' logic being embedded in the black boxes, and it still makes me shiver to think of how bad it was. I essentially don't care what's in a black box - if it's an object, a stored procedure, whatever, I just don't like to see application logic embedded at that level.
I don't like OOP.
Example of why:
JavaScript's prototyping is great in my opinion.
And the conception that you can't have private members in Javascript is just wrong.
There are many well-reasoned articles defending scripting as superior to OO, this is just one I could find in a few seconds on google.
The author has a link to many more:
http://www.softpanorama.org/SE/anti_oo.shtml
And of course this has been discussed on slashdot before too:
http://slashdot.org/articles/01/01/09/1420258.sht
Clear, readable structure and flow is vital to the maintainability of a body of code, and in my opinion is better expressed with procedural script calling powerful compiled code than with the morass OO too often becomes. You don't write the NOVEL in script, you write the table of contents and the general narrative - the individual chapters and footnotes you write in C, use a C++ dll, use a Java object, whatever the most appropriate technology is. Any other procedural/scripting programmers out there that agree? Some quotes for all the OOP CS-propagandized out there:
"encapsulation", "reusability", "modularity" all features of good coding, whether the coding is procedural or object-oriented.
Probably even more important for good coding is EXTENSIVE comments and self-documenting variable names. If I never see the variables 'x', 'y', 'i', etc. again in my life I'd be a happy man. For god's sake tell me what you're counting and why.
Time and again I've seen how writing easy to maintain code is SO much more important than writing 'optimized' code. You can't pre-optimize for speed to any great extent, you first need numbers showing where the bottlenecks are. You CAN pre-optimize for modularity/extensibility which is much more important IMHO.
The licensing for Java CLEARLY states that it cannot be used to control nuclear reactors, pacemakers, suborbital rockets, and particle physics experiments.
2 of these are real licensing requirements by the way.
on a planet with no biosphere?
nice
Good call. I hate lop.com and assorted copycats. Like I'm really going to use their site for anything when I suddenly find myself misdirected there?
He just needs to deliberately let a password be stolen, and then sue Charter for damages for not responding to his complaint by securing their server. Corporations are only motivated by money, so it only becomes a management concern when it affects their bottom line.
Calling Visa would work great too, but I wouldn't want to go so far as letting my card get stolen just for satisfaction.
If not clicking the click through actually prevented you from accessing the site, then the googlebot wouldn't be able to get in.
it's not a contract if you don't agree. you read the license, you say 'no'. you then proceed to browse the site. it doesn't even have the power of a click through.
I love Autechre.
Don't get the hate cure part....
Just looked like a regular window, didn't cover start bar, the close box in top right was visible.
Maybe my work computer is too dated for these ads to function 'properly'?
Then I'd throw poop at your abstraction.
Being a chimpanzee, I wouldn't realize I couldn't hit an abstraction, so I'd probably continue like this for 3 or 4 hours.
Tablizer, you're doing a great job presenting this viewpoint. So often the arguments I hear for object oriented are really just arguments for good procedural practice.
the html tags would be a piss poor example of an object.
a good example of an object would be 'customer', 'order', 'account', 'product', etc.
there's a performance hit to instantiate an object. why do so when simple client or (as a second line of defense) server side scripting can do the validation you're talking about? With Visual Interdev Microsoft tried to do the kind of thing you're talking about, having HTML fields generated by programming code, and it was a complete waste of time. HTML works, just use it directly, no fancy interface needed.
This is anecdotal, not evidence. Most studies of the issue show gains in capability with OO only after several years, it's just become accepted as 'better' as a religious belief. Well documented, modular code is all you need for quick modification of existing code.
Maybe you work at a shop that did a big push for quality, and incorporated modularity and good documentation in with the conversion to OO? Speed of development is definitely the biggest thing in the web, and with my standard include libraries I can crank out pages just as fast as you can with your standard objects, but I think it's a lot easier to develop new libraries than it is to develop new objects.
Why do you feel better getting that piece of data from $someObject->getX() than you do when the data is retrieved from the getX() function in an include file? Functions and includes allow you to have the same modularity as OO programming. Modularity is a design consideration and can be implemented with procedural proframming as well as it can with OO programming.
It all depends on what your needs are what is appropriate. For most sites, putting everything in objects is overkill. I worked on a site that had 42 COM objects to manage the site, about 35 to manage the shopping cart. Complete crap, very confusing. Not the fault of OO, just bad programming. A well designed procedural system is better than a mediocre OO system any day. And, IMHO, a well-designed procedural system is better than a well-designed OO system almost any day too, for the performance if nothing else.
There is always a place for modularity - that's not the same as OO.