HN user

dannas

363 karma

dannas.name twitter.com/dannas_

People to follow:

  roca
  glandium
  DannyBee
  pm215
  pcwalton
  tptacek
  psykotic
  lvh
  zx2c4
Posts18
Comments29
View on HN

I recommend https://eleshop.eu/jbc-bt-2bqa-soldering-station.html

The handle is so light! Active tips! Heats up in 2 seconds. Goes to standby mode when you put away the handle to save the tips.

There's even a lighter compatible precision handle that you can buy.

Luke Gorrie posted a bunch of Twitter threads where he compare the sizes of soldering handles. Can't find it now but https://github.com/lukego/soldering might lead you to them.

Rico Mariani gives his opinions on the future of system programming languages.

His main point is that C++ with EH introduces too much bloat; that the opaque error handling combined with no compiler assisted checking hides bugs; and that you can't write C++ codes from "the books" since it leads to more bugs!

With Rust you can write it like in the books!

"Modern C++ has so many hazards and is so costly that I can't but view it as anything less than a total failure in the systems space. I can't begin to tell you how disappointing this is to me. "

=== Cut needless words ===

The article references Covingtons How to Write more Clearly, Think More Clearly [...] Powerpoint presentation [1]. I highly recommend it!

A fun part in that presentation is when Covington, in a series of steps, revises this sentence...

“One of the best things you can do for yourself to improve your writing is to learn how to cut out words that are not necessary.”

..Into this one:

“To improve your writing, cut out unnecessary words.”

OPs article calls for more words to provide context. But by revising you can often cut the length in half.

[1] https://www.covingtoninnovations.com/mc/WriteThinkLearn.pdf

Has anyone had a chance to read this yet? Is it a good complement to Brendan Greggs and Denis Bakhvalov books?

What more besides the ideas in Richards ACM Queue article are present? https://queue.acm.org/detail.cfm?id=3291278

How does his KUTrace Linux kernel patches differ from the existing tracing infrastructure? This talk [1] seems to suggest that the reason his KUTrace is so fast is because the other tracers collect more information.

How does the tracing capabilities here compared to what the Windows WPA subsystem can offer? Does it have less overhead for collecting such traces?

Sampling profilers like Superluminal claims to be able to recognize very small delays. For how many cases do you need something like KUTrace and when is Superluminal enough?

[1] https://www.youtube.com/watch?v=UYwWollxzAk I felt a little uneasy watching it due to Richard being so disagreeable to anyoone asking him questions

Yes, providing good error message is a hard problem. Writing a parser that just bails out when it encounters and error is easy. Writing one that provides error messages that are useful to the user is a _lot_ more work. That's a dimension I didn't touch on in the article.

I would be interesting to do a follow-up to this post where I compare the error handling for some common libraries/programs and ask the authors on what trade-offs the faced when designing error handling. It's a subject, I beliveve, that is often overlooked.

Speaking of C++ exceptions: Andrei Alexandruesco has investigated the performance impact of replacing exceptions with error codes. Dave Cheney made a summary of Andreis points in https://dave.cheney.net/2012/12/11/andrei-alexandrescu-on-ex...

* The exceptional path is slow (00:10:23). Facebook was using exceptions to signal parsing errors, which turned out to be too slow when dealing with loosely formatted input. Facebook found that using exceptions in this way increased the cost of parsing a file by 50x (00:10:42). No real surprise here, this is also a common pattern in the Java world and clearly the wrong way to do it. Exceptions are for the exceptional. * Exceptions require immediate and exclusive attention (00:11:28). To me, this is a killer argument for errors over exceptions. With exceptions, you can be in your normal control flow, or the exceptional control flow, not both. You have to deal with the exception at the point it occurs, even if that exception is truly exceptional. You cannot easily stash the first exception and do some cleanup if that may itself throw an exception.

More context to that quote: >Per Vognsen discusses how to do course-grained error handling in C using setjmp/longjmp. The use case there were for arena allocations and deeply nested recursive parsers. It’s very similar to how C++ does exception handling, but without the downsides of the costly C++ memory deallocation on stack unwinding.

I have never used setjmp/longjmp myself. And I agree with you that my first instinct would be to use it in the similar manner as in many GUI programs: they have have a catch statement in the message loop that shows a dialog box of the thrown exception. You just jump to a point where you print a user friendly error message and exit.

But I still can imagine use cases where you've isolated all other side effects (locks, shared memory, open file handles) and are just dealing with a buffer that you parse. Has anyone used setjmp/longjmp for that around here?

Given your many years in the field and Cygnus background I guess you've used it a few times? Do you happen to have any horror stories related to it? :-)

Can you make the distinction between "centralization" vs "composition" of errors?

Do you mean the fact that there must be some if-statement within the API that reacts to the different errors and sets a flag used by the Err() method?

Is you opinion that "composition of errors" always requires special syntactic elements such as the match statement?

The code from the blog section:

  scanner := bufio.NewScanner(input)
  for scanner.Scan() {
      token := scanner.Text()
      // process token
  }
  if err := scanner.Err(); err != nil {
      // process the error
  }

I've collected references to error handling but - I have to shamefully admit - have never encountered Common Lisp's condition system.

I'll take the time to read up on it properly, but from a quick glance it seems to me to be in the category of non-local transfer of control with a co-routine flavour.

It looks powerful, but I get the sense that a lot of language designers are on purpose trying to restrict the powers of error handling. So returning sym types or error codes are simpler than throwing exceptions which - again looks to me - to be simpler than allowing transfer of control to be decided at run time as in the condition system.

Again, very interesting. And thank you for making me aware of its existence.

Oh, that was sloppy of me. I should have read up more on Swift (I've never used it myself).

While I have your attention: A big thank you for Fish shell!

And related to the current subject: How does fish handle errors? A quick skim found some constants that are returned upon failure, such as this case for disown: https://github.com/fish-shell/fish-shell/blob/master/src/bui...

What trade-offs did you face when designing error handling for your shell?

Here's one of Bruce Dawsons articles about debug symbols. It contain links to the rest of the articles in the series. I hadn't realized how much progress Feodora has made on providing a symbol server where packages can be downloaded based on buildid.

Yihaa! I guess this will provide the equivalent of a Windows Symbol Server but for Linux. Retrieving debuginfo and sources för Ubuntu is a mess. I've heard that Feodora is better but they're both leaps behind Windows in this regard. Bruce Dawson has sön a blog series about setting up a symbol server för Linux. It was fiddly.

I remember being surprised when I read an interview with Robert Sedgewick where he listed the PostScript Language Reference Manual on his list of top ten programming books. I've never read it though.

Thank you for your suggestions, very much appreciated. I've updated my styles.css file.

Sorry for the inconvenience. I'm an embedded developer and know nothing about web design. The jekyll theme was copy-pasted from one of the default styles provided by github.

Next step: Learn some css to make the design acceptable.