newb question about @property
On 04/10/2017 06:32, Steve D'Aprano wrote:
> On Wed, 4 Oct 2017 02:00 am, bartc wrote:
>> Does all this advanced stuff (which I don't understand and which doesn't
>> look very appealing either; hopefully I will never come across such
>> code) still count as programming?
> I could not have hoped to see a more perfect example of the Blub effect in
> action if I had invented it myself.
> As long as our hypothetical Blub programmer is looking
> down the power continuum, he knows he's looking down.
> Languages less powerful than Blub are obviously less
> powerful, because they're missing some feature he's used
> to. But when our hypothetical Blub programmer looks in
> the other direction, up the power continuum, he doesn't
> realize he's looking up. What he sees are merely weird
> languages. He probably considers them about equivalent
> in power to Blub, but with all this other hairy stuff
> thrown in as well. Blub is good enough for him, because
> he thinks in Blub.
I've seen that example brought up before. It still doesn't cut any ice.
You might as well be condescending of someone who finds Joyce or Proust
unreadable, and prefers McBain, Simenon or Chandler. (Sorry, can't think
of any modern pulp novelists).
It is just being elitist. I have a preference for keeping things simple
and avoiding unnecessary complexity. But with programming languages many
do have a penchant for the latter.
As an example, a recent discussion on comp.lang.c was about implementing
named constants. I proposed one very simple way of doing it, other
people were talking about using #define, enum, const, static const, or
importing constexpr and special rules for 'const' from C++. All
unsatisfactory and each having their own problems.
For that matter, I don't think Python has such a feature either. So that
you write for example:
const C = 123345
and then whenever C appears within the code, it's implemented as:
I'm pretty sure that there are very complicated ways of achieving
something similar, maybe with all your decorators, or using PyMacro or
whatever. But not doing it straightforwardly. [Python's design makes a
simple implementation harder.]
Anyway, what I'm saying is that languages sometimes neglect the basics
in favour of all this other stuff.
> You don't think that adding a cache for an expensive function is programming?
> If you had ten expensive functions, and you wanted to add a cache to each of
> them, would you write out ten separate caches (probably copying and pasting
> the code each time)?
> Or would you write a function that builds a cache and adds it to the expensive
> function *once*, then call it ten times, once for each function being
I'm trying to think of a real example where I've had to add a cache to
to a function, whatever that even means (memoisation?).
Is it looking to see if a certain combination of parameters has been
used before and retrieving the return value that resulted on that
occasion without having to redo the calculation? In my sort of coding
that would need be done on a per-function basis because there would be
It does still sound like adding a turbo-charger to your engine, rather
than actually going anywhere. That at least might be useful, but it's
still not driving.
But if the ultimate purpose is more speed, then piling on yet more code
and more layers may be counter-productive!
> That you think that this is not programming is an indictment off your
> programming skills. These sorts of functional programming techniques go back
> to the 1950s, Lisp is literally the second oldest high-level language ever
> (only Fortran is older). You may or may not have been a hotshot in your
> little corner of the programming world, but there's an entire world out
What other languages apart from Python have equivalent features to
decorators and, what's the other one, descriptors? Apart from Lisp.