sam_bishop

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

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.

> 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.