Oh I agree Henrik, but like all things, there is a time and place for it. It is a good principle to keep in mind even when you break it when designing a language because it avoids "feature creep" which is something that has become far too prevalent in software, especially today. I consider OOP to be the worst example of feature creep.
I'm not all for or against OOP, but I do not think that it should be the solution automatically pulled out in the majority of cases. While I agree that some of the principles of OOP are worth having, I just think that it is prudent to question the value of the rest, especially now that battery life is a concern. I often ask myself if you can really do an really do an algorithmic N-operations analysis anymore, and when dealing with OOP I don't even bother to try. I fully expect to waste 30% (perhaps more) of execution time on overhead compared to procedural programming. At that point, anyone wanting efficiency really starts questioning the value of OOP. On Sat, Jul 25, 2015 at 1:55 PM, Hendrik Boom <[email protected]> wrote: > On Sat, Jul 25, 2015 at 12:36:47PM -0500, T.J. Duchene wrote: > > > > > > On 7/25/2015 5:26 AM, Roger Leigh wrote: > ... > ... > > This really > > violates the standing principle of "paying for only what you use." > > I encountered this principle long ago when I got involved in the > design and implementation of Algol 68 -- they deliberately violated it > with one feature -- they decided that everyone would pay the price of > a procedure calling mechanism that supported recursion. > > Sometimes it is the right thing to do. The same decision was made by > practically eveery language designed afterward. > > Not to say they didn't accidentally violate it a few times, of course. > I'm talking five decades ago, back when people were inventing the > language design principles we now take for granted. > > -- hendrik > _______________________________________________ > Dng mailing list > [email protected] > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
