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....@python.org> On Behalf Of Peter Pearson Sent: Saturday, October 10, 2020 11:58 AM To: python-list@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 -- https://mail.python.org/mailman/listinfo/python-list
