Python's carbon guilt

[Avi Gross]

People have a tendency to go too far in their religious zeal, Peter.

We could go back to writing on chalkboards to do calculations then re-use
the chalk dust when erasing to write again.

Many computers do almost nothing 90+ percent of the time. Want to outlaw
those or force them to accept random jobs from the internet when relatively
idle?

But all kidding aside, anything used frequently and not changed often might
be a good candidate for an efficient solution that uses fewer resources. Yet
our computers, so far, have been in many ways getting cheaper and in many
cases use less electricity to do the same number of calculations. But there
are tradeoffs such as optimizing speed over memory use or other resources
that are external and thus slower. 

The ultimate carbon cost can sometimes be for  carbon-based organisms, most
of them suitable to be called human. When you measure how long it takes them
to develop applications and verify they have minimal bugs, you may notice
that some development environments seem to take lots more time than others
for common tasks. Interactive has huge advantages in many cases. Slowest
would be asking people to go back to writing in machine code, not very
portably.

The reality is that speed and other resource use do matter for anything run
often or that would take a very long time. Languages like python and R
acknowledge that and quite a few parts are now replaced by calls to
libraries in other language or C/C++ code. But often that is done only later
when the code is not going to be changed regularly.

I think there is a reality here. The costs of computing end sometimes of
power usage, often are dropping. The users like getting extra features and
underneath the covers, that often means lots of extra IF statements or other
checks, or loops that keep checking regularly to see if they need to do
anything.  If you program a GUI that allows the user to click or type in
many places at random, there can be lots of overhead even when done in a
compiled language. True speed and efficiency might require removing lots of
features entirely as too expensive. It may well be cheaper to do some
operations on matrices where every row/column is of the same object type but
there are very serious advantages to allowing a mixed type operation such as
a data.frame where each column is a hidden vector of some type or even at
times to allowing every cell/item to be of any object type. The overhead
rises in terms of storage and CPU time used but it allows higher levels of
abstraction and often the ability to write code with fewer lines that
handles many more conditions, sometimes invisibly. 

Consider how computing is being used and ask if a little more carbon
footprint there may reduce the carbon footprint elsewhere. Would you rather
have people spend years or months developing some app that can be used in a
way that reduces overall carbon dioxide production?

If your answer is that you can have it both ways, fine. But you may have
trouble hiring enough people willing to work under those constraints and you
may be told of lots of things they won't feel comfortable doing and it may
take longer and ...

A question. Are recent compiled languages that add features as small and
fast as earlier ones? For example, many older languages required a function
to take a fixed number of arguments in a fixed order and of exactly the
types mentioned when created. Some interpreted languages allow lots of
additional functionality, some of which could easily be provided such as
allowing named arguments in any order, or allowing additional optional
arguments or default values and so on. Much of this could be done in a
compiled way, but with additional compile time and even run-time cost. But
some features, by definition, must be at run time and especially for code
that modifies itself or creates new objects dynamically. IF you want some of
these new features, how would you supply them in a compiled way without
adding lots of the overhead you want to reduce? 

Carbon guilt should not be taken seriously as an immediate goal as compared
to an overall goal. If we make more people able to work from home or nearby
offices and avoid long commutes, does it matter if your remote work is much
more carbon friendly than the costs to travel and then still use other
energy there for lighting and more computers and ...




-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net at python.org> On
Behalf Of Peter Pearson
Sent: Saturday, October 10, 2020 11:58 AM
To: python-list at python.org
Subject: Python's carbon guilt

Python advocates might want to organize their thoughts on this subject
before their bosses spring the suggestion:

From
https://www.sciencemag.org/news/2020/10/we-re-part-problem-astronomers-confr
ont-their-role-and-vulnerability-climate-change :

    . . . Astronomers should also abandon popular programming languages
    such as Python in favor of efficient compiled languages. Languages
    such as Fortran and C++, Zwart calculates, are more than 100 times
    more carbon efficient than Python because they require fewer
    operations.


--
To email me, substitute nowhere->runbox, invalid->com.
--
https://mail.python.org/mailman/listinfo/python-list