616 karma · joined December 19, 2017
If I am procrastinating in software development or research it is
(1) for complexity reasons, (2) for foreseeable vast grunt work I have already done and solved in the past.
Example (1): I have to choose between at least two fundamental different ways to get ahead in writing software. I know that implications come late, wasted time can be a lot. I will often pause until it comes to me.
Example (2): Writing a new library in Julia, when I covered the topic in Python or C++ years ago, but cannot directly reuse it, the whole thing intensifies when it has already been done in several incarnations. Becomes more and more difficult ("been there, done that") with age, especially if the occasion is determined from outside. The same applies to research which requires a larger amount of knowledge from the past that needs to be reactivated.
(2) could be attributed to negative emotions (boredom, and yes, even laziness), but (1) is different, more a search for an optimal strategy prior to the start, because the cost for doing otherwise could be prohibitive. It is simply unwillingness in decision-making (too early).
https://www.bmu.de/themen/atomenergie-strahlenschutz/nuklear...
Never was it for me, and I'm certainly not alone.
I've been using the Wing IDE for several years. It sometimes chokes when I try to inspect larger numpy arrays as a whole, using the application-specific array visualization (but there are other ways). Otherwise I'm quite happy with it.
It tries to embrace it, but this is not necessary (and limited for non-trivial cases - and what isn't non-trivial for serious projects). CMake itself has good VS support for a long time. I always try to create VS solutions in parallel with ninja, nmake, jom, whatever completely from it without hand-holding of some integration.
I'm in 3D and image processing software, often with GPU interface requirements involved. I can reconcile some aspects in the virtual environments, but yet in the single case not all of them. On top of each other and according to experience, difficulties multiply.
https://www.kauffmann.nl/2019/03/04/how-to-install-docker-on...
https://blogs.vmware.com/workstation/2020/01/vmware-workstat...
This has to change first (the links giving some kind of hope).
I'm using it this way as a tool (being a software writer in this industry), but the tasks belonging to it and those for Krita have a virtually empty intersection.
@parent Of course - I also switched for ebooks from a dedicated reader to a tablet. But I'm still missing the ability for reading in the full sun, power for two weeks w/o charging, easiness on the eyes.
Similar - but harder to tolerate - things apply to a painting tablet. You cannot replace it simply by a multi-function device without losing quite a lot functionality.
The only way still working for me is an arcane - in fact deprecated for a long time - Qt environment variable (QT_DEVICE_PIXEL_RATIO), that makes a difference for at least a portable Krita installation.
Why should I do so when I have my own experience?
> On the other hand any other brand than the leading brand is truly terrible.
So you've tried them all? Not to talk about the use cases...
Finally - a few months ago - I aquired something remarkable cheaper, a chinese Gaomon M106K. It turned out, it is not cheap at all in the other sense of the word. Good quality and support at least for my use case (a bit different, handwritten formulas and sometimes some sketched diagrams). But my youngest kids use it for painting with Krita too.
But the highest priority by far remains doing the basic things. Regularly - in any weather in this case - without excuses. That is the core. All other issues are premature optimizations (or to be clear, no optimization at all)
Which one?
- Update problems for packages (refusing for non-explainable network errors)
- hardwired installation path for something I forgot (Juno, julia?)
- screwing python search path globally after installing julias python interface
- more, I'm not remebering anymore
A fully portable 'installation' with decent VSCode support would be the first thing, I needed.
No, often you will use nothing - simple juxtaposition.
https://www.amazon.de/Love-Math-Heart-Hidden-Reality/dp/B00N...
from someone, born in the system:
Ironically, her independence from ZF would make the classical Bourbaki group shiver. The same way the earlier, better known, work of Goedel did.
I don't know, if you are aware of Bourbakis spirit. There is something much more important in this context as the content-wise difference between sets and numbers. I never would argue against applying naive set definitions in a suiting way. But Bourbaki had an agenda, and this agenda is not for everyone (certainly not for me).
The other part is content: Bellman dealt with the same problem. But Bellman equations are notoriously hardware-demanding. Pontryagin on the other hand gave necessary (and sufficient for some cases) conditions in a form much more accessible to pen and paper.