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 <hendrik@???>
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
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>