@j_g00da @skarn yes, well neutrinos don't drink water, so you really almost turned yourself into neutrino. Dangerous, you might have even started oscillating... or become dark matter candidate.

@scholar yes, we do this. For warm water, it makes sense, for heating - not so much, because you have excess heat during summer. And it is extremely tricky to sync supply and demand. You need stable long term housing contracts...

@scholar silent external fancoil. 25 dB for 10 kW. Ubelievable...

@herbert_tiemens The downhill advantage is because of aerodynamics.

As for uphill... this is where the idea of solar charged recumbent touring ebike came from 🙂

@plactagonic @bicycle_touring

@beejjorgensen I spent so many time writing manual loops even in Basic, sometimes in ASM (on Z-80) later in C, but actually, abstraction level of manually written loops is relatively low.

Ok, core concept in Python are iterable objects. Iterable objects are much, much more advanced abstraction, than manual loop - I and yes, I have spent many, many years writing manual loops again and again, later I added some macros, but still - in Python, it is not only less keystrokes, but the iterable object abstraction is something, which was absent in Fortran and C (maybe not in C++, but C++ was mostly pain)

Syntactic sugar poured on iterable objects is maybe not so important, but in enviroments without certain core concepts, no amount of syntactic sugar will fix that.

Think of it as it was in Basic: it had no pointers (unless you wished to peek and poke memory manually). C had pointers and pointer aritmetics, which was powerful abstraction, compared to Basic. You would need to manually call peek() function to read pointer... well, technically possible, but you would read one byte at a time, with no clue about data type, etc). C pointer is not just syntactic sugar over peek(), it is much more than that.

And there are more and more such powerful abstraction, which are just absent in older languages. You can eg. call try ~ except (or catch, or whatever) syntactic sugar - well, maybe it is, but is sugar coated setjmp()/longjmp() call of libc, not sugar coated goto, as it may seem at the first glance...

@chrastecky @php eh, cože? proč?

@Bjoern_Tantau eh, yes. It was not intended. I just subscribed to the group and wanted to infotm other local users and my followers. But now I see mentioning the group works like cc:.. sorry about that.. would deleting the toot fix it?

@agressivelyPassive ok, comprehensions are just syntax, but still, they still allow producing new arrays directly from iterable objects, without need to store them in temporary arrays, which counts as added abstraction.

Basically I agree, that there are concepts which are simply not available in certain runtime libraries/interpreters, like multithreading or lazy evaluation. So I more or less agree, that syntax is not so important and we should categorize the underalying abstractions, accessible by syntax (or whatever).

But at least memory management abstractions of Python are very different from Fortran or C (ok, you can use many different libraries for that in C, but you will hardly get reference counting and automatic clenaup of unreferenced objects and so, and this not just syntax issue... it is automation issue...)

@agressivelyPassive @beejjorgensen ehm, not really. Comprehensions [I didn't even know they are called as such for a long time] ale light years ahead of any abstraction provided by Fortran, and unfortunately also C (maybe not so C++, which is dangerous and versatile beast).

The core concepts of Python are two or three generations newer than that of Fortran.