Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing Pythagorean triples in C++, D, and Rust

atilanevesoncode.wordpress.com

Post reply on HN
Print view View original

111–118 of 118 posts

Re: Comparing Pythagorean triples in C++, D, and Rust

#111

Post by pjmlp »

steveklabnik wrote: post #47
marksomnian wrote: post #45

Earlier quoted context omitted.

How do you debug logic errors in that case? I imagine that most logic errors can't be caught by the compiler, although I could be wrong.

I come from Ruby, where debuggers are useful but also not often used. I find that I tend to write more and smaller unit tests than people who reach for debuggers. I debug logic errors by using println or writing more tests. And yes, Rust is still very susceptible to logic errors.

Developing with powerfull debuggers is an experience that kind of resembles using a REPL, specially with languages that enjoy fast compiles.

I advise devs to go through Xerox PARC and ETHZ papers about interactive development, or Apple's Object Pascal/MCL/Dylan/Hypercard, on was the birth of IDEs.

Re: Comparing Pythagorean triples in C++, D, and Rust

#112

Post by the_why_of_y »

burntsushi wrote: post #64
saagarjha wrote: post #58

Earlier quoted context omitted.

Debuggers are great interrogating arbitrary program state (it's a printf you don't need to hardcode!) and acting as a REPL for trying out new code.

I'm with Walter on this one. He's right. When I printf-debug, I very much do not want to necessarily see the raw in-memory details. I want to see a pretty printed view. For example, right now I'm working with DFAs, and if I just printed out its transition table as it is in memory, it would be unreadable. Instead, I have a custom fmt::Debug impl that pretty prints something I can read and comprehend. I don't think I'd…

With current gdb (i.e. released this decade), you can define pretty-printers in Python that are loaded automatically and print whatever you think is most important for a given type; the "print /r" command is available to print the raw details when necessary.

libstdc++ ships with pretty-printers for its types.

But I agree that printf debugging still has its uses.

Re: Comparing Pythagorean triples in C++, D, and Rust

#113

Post by geezerjay »

forrestthewoods wrote: post #82
burntsushi wrote: post #80

Earlier quoted context omitted.

I don't use C++ and I don't use Visual Studio. And even if I did, it would be pretty annoying to have to define debugger specific files just to print my data types. In Rust, I just add a fmt::Debug impl and now everyone who uses my code benefits from it, whether in a debugger (by calling that impl) or by print-debugging. I'm not here to convince anyone to use printf debugging. I don't care about some grand "argument"…

I'm familiar with your work. I use ripgrep daily, thanks! > I mostly use printf. A debugger is only good for telling you where it seg faulted and the stack trace. That was Walter's statement, with which you agreed, and with which I strongly disagree. Maybe I overgeneralized. The Rust debugger story indeed sucks and I mostly use printf! I interpreted "a debugger is only good for..." to be all debuggers. And I don't th…

> 2019 won't be the year Rust's IDE story gets good. But maybe 2020? People are laying the groundwork. I'm hopeful.

I'm very hopeful 2019 will see some major improvements in that domain. Some IDEs such as Qt Creator just added support for the language server protocol [1] which already supports Rust. Thus the critical groundwork is already being deployed, albeit some work still needs to be done.

[1] https://langserver.org/

Re: Comparing Pythagorean triples in C++, D, and Rust

#114

Post by renox »

berkut wrote: post #90
keldaris wrote: post #39

Those of us who have compute-bound workloads (scientific simulations in my case, but this often comes up in gamedev and elsewhere) often complain about how unusably slow debug builds impede our workflow in C++. One fairly common solution to this in extreme cases is sticking to a mostly C-like subset of the language or just using C. I don't have much experience with Rust, but judging by the results here, debug builds…

Not talking about Rust here, so not really an answer, but in the film VFX industry (rendering in my case) pretty much all the high performance code is C++ or CUDA, and before we moved to c++11, I'd worked out that for STL iterators, at least in the 4.2/4.4 GCC versions, pre-caching the end() iterator of an STL collection before the loop instead of calling it each time as a control condition of the loop made faster de…

Have you tried -Og? I would try this before modifying the sources..

Re: Comparing Pythagorean triples in C++, D, and Rust

#115

Post by steveklabnik »

pjmlp wrote: post #111
steveklabnik wrote: post #47

Earlier quoted context omitted.

I come from Ruby, where debuggers are useful but also not often used. I find that I tend to write more and smaller unit tests than people who reach for debuggers. I debug logic errors by using println or writing more tests. And yes, Rust is still very susceptible to logic errors.

Developing with powerfull debuggers is an experience that kind of resembles using a REPL, specially with languages that enjoy fast compiles. I advise devs to go through Xerox PARC and ETHZ papers about interactive development, or Apple's Object Pascal/MCL/Dylan/Hypercard, on was the birth of IDEs.

Fun fact: I loved coding in HyperCard as a kid.

Re: Comparing Pythagorean triples in C++, D, and Rust

#116

Post by kareemadel000 »

jordigh wrote: post #5

By the way, is it a secret to programmers that Pythagorean triples can be parametrised? I understand that the point of the code is to enumerate them without knowing that they can be parametrised, but the parametrisation in this case is not so scary, so it's a fun bit of trivia for programmers (for mathematicians, it's more fundamental, as the Pythagorean parametrisation is an important prototype for counting rational…

Also, Fibonacci numbers and Binet's formula

https://en.wikipedia.org/wiki/Fibonacci_number#Binet's_formu...

Re: Comparing Pythagorean triples in C++, D, and Rust

#117

Post by int_19h »

ajross wrote: post #98
int_19h wrote: post #96

Earlier quoted context omitted.

printf debugging doesn't work when your code already crashed, and all you have is the process dump (and if you're very lucky, it's a heap dump, not just stacks).

That's like saying that time spent developing a robust resupply and support network is wasted because your army is already starving in Russia. It's true, but sort of misses the point. Obviously it's possible to debug an issue based only on static state like a core dump. And in extraordinarily rare cases that might be the only available option and a debugger (or more manual tooling) might be your only choice. But in t…

Those "extraordinary rare cases" aren't anywhere near as rare or extraordinary when you have millions of users.

In fact, I would argue that reproducible reports are relatively rare in the industry, especially once you get out of developer tooling (where the users are people who know the value of such reports, and how to obtain them).

And then stuffing a printf in the middle of it can easily mean several minutes of build time, for a large native codebase. A tracepoint, on the other hand, is instant.

Re: Comparing Pythagorean triples in C++, D, and Rust

#118

Post by Avi-D-coder »

staticassertion wrote: post #43
keldaris wrote: post #39

Those of us who have compute-bound workloads (scientific simulations in my case, but this often comes up in gamedev and elsewhere) often complain about how unusably slow debug builds impede our workflow in C++. One fairly common solution to this in extreme cases is sticking to a mostly C-like subset of the language or just using C. I don't have much experience with Rust, but judging by the results here, debug builds…

Can't speak to others, but it's funny to think of "printf debugging" as a last resort when it's easily my go-to. I'll often add some println's and re-run tests to trace through what happened. I only step into a debugger when I'm really wtf'd, and I don't think that's happened to me even once with Rust (it used to happen a lot with C++, since printf debugging mixes so poorly with segfaults etc). No question that long…

The code generator that may complement/replace llvm for this use case is Cranelift.

https://github.com/CraneStation/cranelift

Post reply on HN