sam_bishop

I could read it once I forced my browser into light mode.

I've avoided #pragma once because of reports that it slows down gcc/g++: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58770

But given that I haven't seen any mention of that issue in other comments, I wonder if it really is an issue.

I'm not a compiler expert either, but I think LLVM IR is the way it is for the benefit of the optimizer. It wasn't intended to be written by humans, typically.

It's more "portable" than assembly so that the same optimizer passes can work on multiple architectures. The static-single-assignment restriction makes it easier to write compiler passes by removing the complexity that comes with multiple assignments.

One of my beefs with Clean Code is its name.

There is no objective measure of code cleanliness. So if "clean code" is your goal, then you have no meaningful criteria to evaluate alternatives. (Including those pitched by Bob Martin.)

It gets worse, though. There's a subconscious element that causes even more trouble. It's obviously a good thing to write "clean code", right? (Who's going to argue otherwise?) And to do otherwise would be a moral failing.

The foundation on which "Uncle Bob" tries to build is rotten from the get-go. But it's a perfect recipe for dogmatism.

I'm an American who lived in the UK for a couple of years. They have many roundabouts there, and I love them. But now I live in an American town with a few, and I've realized that there's a reason that they are less safe in the US than in the UK--besides the fact that American drivers are less familiar with them. It's a solvable problem, but not one I've heard people talk about. (Though to be clear, I'm not a traffic engineer.)

Most American drivers are familiar with slip lanes, which allow drivers to make a right-hand turns without necessarily coming to a stop. (Wikipedia article: https://en.wikipedia.org/wiki/Slip_lane. Note that the diagram shows an example from a country where they drive on the left side of the road.) They're convenient for drivers, but dangerous for anyone on foot or a bike. This is because a driver in a slip lane is looking for an opening in traffic in the direction opposite of the direction they're traveling.

A roundabout is basically an intersection made up of nothing but slip lanes. So they're fundamentally dangerous to pedestrians in the same way that a slip lane is, but the fact that vehicles are moving slower means that they're still safer than typical American intersections.

However, if I remember correctly (it's been over 20 years ago), in the UK they don't mix roundabouts and crosswalks. They'd put crosswalks (called "Zebra crossings": https://en.wikipedia.org/wiki/Zebra_crossing) between intersections, where drivers aren't distracted by other things. I think we need to do that in the US as well if we're going to adopt roundabouts.

If you’re storing doubly linked lists in a DB you’re doing it wrong.

Assuming that the database uses B+ trees (like most do), then the database records themselves are very likely to be in a doubly linked list.

Not every doubly linked list is the kind you see in an introductory data structures class.

But this is not TDD.

That's true. Did you miss the part where I mentioned the "TDD process" versus the "TDD mindset"?

Whether your code is easily testable will be challenged by writing tests regardless of the moment of writing test - before or after writing impl.

I don't want to derail the conversation, but when I'm working on projects alone then my test coverage is 100%. (Line and branch coverage.) But surely that slows me down, right? And I must have a million test cases? No, quite the opposite actually. Writing code that way is just a skill though, the same as juggling, that becomes easy with enough practice. (Along with the right practices and tools.) However, I don't aim for 100% (or even a particularly high percentage, to be honest) when I'm working on projects with other people, because the only way it's possible is if the code was designed for it from the get-go.

I encourage junior developers to learn and try to use TDD for a while because it can be useful sometimes and improve the way they write code. But I would never require them to do it.

I don't use the proscribed TDD process very often, but I use the TDD mindset all the time to great effect.

Listing out the tests you're going to write before you write the code (even mentally) can be considered a continuation of the requirements-gathering process. And thinking about how you're going to test your code before you write it will, in my experience, improve the design. (Particularly, it seems to encourage the single-responsibility principle, as code that's doing too much or combining layers of abstraction is really hard to test.)

I've heard that the Hotspot JVM uses a bump allocator but don't know the details. I'm sure it's heavily optimized though, so I'm curious about how this compares.

Pooling objects (for the purposes of minimizing GC) is consider a bad practice in modern Java. The article suggests that compacting, generational collectors are a bad thing, but they can dramatically speed up the amount of time it takes to deallocate memory if most of your objects in a given region of memory are now dead. All you have to do is remove objects that are still alive, and you're done: that region is now available for use again. The result is that long-lived objects have a greater overhead.

I agree. The author seems to know quite a bit about Go and GCs, but doesn't seem to have much experience with Java. As a Java performance engineer, it sounds like he is comparing Go to how he thinks Java works based on what he's read about it.

I can't think of a really good computer analogy to explain stroads, but if I were to attempt it I would say that it's analogous to forcing everyone to use a CLI, for _everything_.

Roads can move a lot of people and material long-distances, quickly. CLIs are powerful, but I've never seen an e-commerce application with a command-line interface. It'd be the wrong tool for the job.

Similarly, you shouldn't build multi-lane roads with wide lanes (which is all a great fit for highways) in places where you expect a lot of people to be, especially if they're shopping.

It was a good idea to post this to HN. Back when I was an LLVM contributor I was using an email address from a provider who is no longer around. I had no idea that the LLVM maintainers were trying to get a hold of me. There's probably a lot of overlap between LLVM contributors and HN readers.

For what it's worth, in the state I live in it is legal for bike riders to treat stop signs as yield signs. It started in Idaho in the 80s and has been adopted by a growing number of states since then.

It's also legal in my state to ride bikes on the sidewalk. That doesn't cause much of a problem for pedestrians because unfortunately there are few bike riders or pedestrians.

I only mention this to make people aware that what's legal depends on where they live.

I'm a software developer. I like the idea of accessible web interfaces, but I have, and probably always will, work on user interfaces that have a relatively small user base compared to large sites like the Washington Post or Google. (I've worked for SaaS companies for the last 15 years.) Someone in another thread mentioned legal requirements regarding accessibility for US air carriers; are there any general requirements for software accessibility? (Software used as part of a job, in particular.) Otherwise I don't think that I'd be able to convince my management that this was worth worrying about, unfortunately.