wodny · HackerTrans

5 yıl öncediscuss

And it's also worth noting that eg. Debian has been providing hybrid images for years. Hybrid meaning you can write them directly to block device like USB drive or burn on CD. They exploit the fact that ISO images have first blocks empty and unused so you can put a classic MBR boot loader there.

wodny

5 yıl öncediscuss

Why "yikes"? Note that doesn't mean I don't know how to use eg. gdb outside or inside IDE. My debugging record proves my methods are quite efficient but there's something even more important - there are ways to systematically avoid the need to use a debugger by keeping projects' sanity level high.

wodny

5 yıl öncediscuss

That is not the point I was trying to make here. I was talking about extreme cases of faulty code which luckily are not that common. I meant that as long as you couple with sane libraries and adhere to standards in your own team extreme measures such as a debugger are not necessary.

wodny

5 yıl öncediscuss

> The big thing here is that you seem to only work with your own code, where you can arbitrary refactor it and keep the entire thing in your head, as well as quickly find which module does what.

Not at all. Due to lack of documentation I look at code of foreign libraries and applications all the time to check what really happens inside and what are the guaranties. The latter being often the case when it comes to concurrency problems.

wodny

5 yıl öncediscuss

Print debugging is not that different from setting logging level to DEBUG and those logging calls should already be there in code and give meaningful insight so I don't get printing being often ridiculed.

For over ten years of commercial work I used a debugger only a couple of times and in most cases it was against someone else's code, usually when things were completely broken and I needed to get backtraces from multiple deadlocked threads or lacked debugging symbols and things like radare were also required. There were also times when I manually called a syscall using gdb.

My opinion is that if you can't reason about the code helping yourself with just a couple of additional messages the code is probably broken/too complicated to begin with and requires serious refactoring. I've never understood people stepping through a program hoping to find some mysterious creature somewhere along a huge stack of calls. In my career I have often seen people always debugging an application as a whole instead of separated modules. Dividing a problem is the key. The same key that allows me to still program using vim without autocompletion, keep APIs sane and coherent, and avoid dead code.

One really useful exception is when dealing with electronics. My friends programming hardware use debuggers all the time and in this case it actually makes perfect sense because there is no way to print anything and things like hardware interrupts come into play.

wodny

5 yıl öncediscuss

I think this is an oversimplification. Just look at the number and the history of PEPs:

- The Theory of Type Hints - PEP 483

- Annotations - PEP 3107 - 3.0

- Type hints - PEP 484 - 3.5

- Variable annotations - PEP 526 - 3.6

- Postponed evaluation - PEP 563 - 3.7 (3.10)

- Core support - PEP 560 - 3.7

- Distribution - PEP 561 - 3.7

- Data Classes - PEP 557 - 3.7

- Literal types - PEP 586 - 3.8

- TypedDict (limit keys) - PEP 589 - 3.8

- Final qualifier - PEP 591 - 3.8

- Static duck typing - PEP 544 - 3.8

- Flexible annotations - PEP 593 - 3.9

- Type Hinting Generics In Standard Collections - PEP 585 - 3.9

wodny

7 yıl öncediscuss

No. "Z raku" would mean that "raku" accompanies you and the play on words would be gone because it would be either "programuje z raku" ("one is accompanied by raku the programming language") or "programuje z rakiem" ("codes having/with cancer").

wodny

7 yıl öncediscuss

It will have quite interesting implications, especially for former Perl 5 syntax enthusiasts. One could say in Polish they "code in cancer" ("programuje w raku").

comments