doctor_eval

2 ปีที่แล้วdiscuss

Witness K and Bernard Collaery came to mind when I was writing it. They blew the whistle on illegal espionage used to pillage the resources of our tiny neighbour, and the government threw the book at them. Absolutely shameful.

doctor_eval

2 ปีที่แล้วdiscuss

I understand that Wikileaks is controversial but I don't think there is any dispute that he has acted in the role of whistleblower to some extent. But that's not really the point I'm trying to make, so I've removed the reference.

doctor_eval

2 ปีที่แล้วdiscuss

Are strong whistleblower protections what’s needed to balance this?

As an Australian I am absolutely horrified that we continue to put people in jail who have blown the whistle on the government here, and it makes me think that large organisations are absolutely terrified about strong whistleblowing protections.

This all suggests to me that whistleblower laws would be very effective.

doctor_eval

3 ปีที่แล้วdiscuss

that’s the argument I kept hearing, but in practice, it’s trivial.

    1695029423495
    1695029483502
    2023-09-18T09:30:23.495Z
    2023-09-18T09:30:25.502Z

In fact I can see by just looking at your integer timestamps that it’s about 60,000ms difference, or 60 seconds, so I think your time stamps are wrong.

I personally find that it's much more difficult to compute the number of seconds between two different ISO timestamps without help, and that’s my point.

doctor_eval

3 ปีที่แล้วdiscuss

Everyone - especially those in my own team - told me that dates needed to be human readable strings in my APIs and messages, but I ignored them and used Java time stamps (Unix, but milliseconds) instead.

Lo, nobody complained about the readability because most time problems are relative to other events, rather than to a specific clock time. It’s so much easier to work out that two events occurred a few milliseconds apart when you don’t need to take segmentation (ie: ymdhms.s) into account. And using an integer obviates time zone and daylight savings corner cases. You can simply subtract two numbers and get useful information. And it’s much easier to do the math in your head and in scripts.

For those relatively rare times that you do need to know the clock time, there are CLI tools (ie, date -s) and websites galore.

Of course my use case was not everyone’s use case. But I ignored the blanket recommendation to use human readable time, and despite the naysayers, life became much easier for me and my team. I doubt that I would go back to string timestamps for any purpose.

Honestly, human time is for humans, it’s a presentation problem. Computer time is for computing.

doctor_eval

3 ปีที่แล้วdiscuss

Go generics are still in their infancy. Java generics enabled a lot of functionality that came later. But java generics and particularly type erasure are nothing to write home about, and Go maintainers were also said to be against them, so who knows if comprehensions or other features might pop up one day.

doctor_eval

3 ปีที่แล้วdiscuss

FactoryFactory is (or was) a well known parody of the multiple levels of abstraction Java developers were encouraged to make when performing even simple tasks. This started with an insistence that we should use getters and setters for field access, and it basically went downhill from there.

This kind of nonsense was endemic to the Java engineering culture while I was working in it.

Perhaps the worst example I saw was during the fluent API craze where someone in my team replaced a constructor call for a Button with five lines of fluent Builder pattern gibberish.

The point of mentioning FactoryFactory was to poke fun at the culture surrounding Java, which ended up being one of the reasons I stopped using it, because idiomatic java stopped making sense to me.

Hopefully it’s changed now.

doctor_eval

3 ปีที่แล้วdiscuss

I’m guessing these will come with generics. Wasn’t that also the case with Java?

doctor_eval

3 ปีที่แล้วdiscuss

Yeah I find the argument for Graal to be very disingenuous. It’s certainly not an out of the box solution; I’d say it’s just another Java technology stack we would need to learn. And there are so many of those.

So I guess I also like Go’s batteries-included standard library.

doctor_eval

3 ปีที่แล้วdiscuss

Well, I listed a number of things I prefer about Go, and the verbosity I was talking about was the classic ButtonFactoryFactory and other naming classics. It’s true however that I ended up throwing that stuff away from my Java code and started to enjoy life again.

But I can say honestly that I prefer Go’s error handling, which I find tends to result in errors which are actionable. I think it takes a lot more effort up front to get Java exceptions to work rationally.

If I could change Java then the thing I’d do is I’d make it necessary to declare all exceptions in a method, but get rid of caught exceptions. So you can see what’s coming, even if you don’t have to deal with it.

In terms of stream operations, well, I write a lot of typescript lately and just like in Java, I find that I end up having to fall back to regular loops quite often. I’m not convinced that stream operations are useful in as many use cases as people would like. For example, the moment something can throw an exception, things are going to get gnarly.

doctor_eval

3 ปีที่แล้วdiscuss

I’m older generation, choose Go because it’s almost universally better for my use cases.

But what would I know? I only worked in Java for 20+ years…

doctor_eval

3 ปีที่แล้วdiscuss

I wrote Java code for 20+ years and I can tell you exactly why I prefer Go: it produces native binaries.

I mean, it’s also less verbose, easier to start a new project, faster to startup, has far fewer configuration knobs, has native dependency management, is far easier to build CI/CD for, compiles more quickly, has very few NPEs gotchas, has value types, and avoids idiomatic boilerplate.

Go is far from perfect, but it has clear advantages over Java and I would not go back.

But the thing I love the most is the lack of a JRE. If I build for a target, it runs there.

doctor_eval

3 ปีที่แล้วdiscuss

Totally agree we should wait for the investigation. It’s going to be very interesting.

To your point though, we also don’t know what was going on in the cockpit of the 737. Even if they were aware of how close the FedEx jet was, it’s entirely possible something went wrong that caused them to delay the takeoff roll (assuming it was delayed).

There are plenty of things that could have gone wrong on the ground. Separating traffic is the ATCs job and clearly there was a loss of separation. Very hard for me to see how this could be Southwest’s problem particularly since they weren’t yet airborne.

doctor_eval

3 ปีที่แล้วdiscuss

How are we supposed to learn if you just tell everyone to “leave it to the professionals”?

If you don’t agree with something someone posts, contribute to the discussion by explaining the issues. Why shouldn’t the ATC be sacked? Safety culture. Why shouldn’t they install ground radar? Complexity. Etc.

Appeals to authority are the worst kind of arguments because they don’t help us to understand what to expect from them.

Just think of it as CRM for the internet. :)

doctor_eval

3 ปีที่แล้วdiscuss

There is nothing wrong with a layman’s perspective in any industry, and aerospace is not certainly not the sole domain of safety critical systems. An aerospace layman might still bring insight from other areas, which was the case here IMO.

You have been repeatedly dismissing people in this thread, but HN is about being curious. “Leave it to the professionals” is neither satisfying nor interesting.

doctor_eval

3 ปีที่แล้วdiscuss

You’re assuming situational awareness, but they would have been running checklists preparing for takeoff, and may not have heard how far away the fedex was. I didn’t think they took overly long, and they weren’t instructed to hurry.

doctor_eval

3 ปีที่แล้วdiscuss

A safe system is resilient to errors. The controller made a mistake - that happens, the system should deal with it. But in this case, a crash was averted only because the fog lifted. It was pure luck. Ground movement radar, a runway incursion warning system, or a different landing clearance protocol could all have provided the necessary safety buffers.

When you’re up to the last “hole” in the cheese, that’s a failure.

doctor_eval

3 ปีที่แล้วdiscuss

That’s horrifying. The controller completely ignores all the information and clears the USAir plane to take off, twice. But the crew knew there was a plane on the runway and refused, twice. Incredible.

Well, I guess the Swiss cheese worked.

doctor_eval

3 ปีที่แล้วdiscuss

I did hit some kind of networking bug on a Linux server recently (in the past 2 weeks) which required a restart of the Docker daemon, and that is my classic personal experience. We went all-in on Docker Swarm several years ago, and we ended up having to do full server reboots on what seemed like a weekly basis. And I know I'm not alone in having loads of problems on MacOS - although I must admit it seems to have been a lot better recently.

doctor_eval

3 ปีที่แล้วdiscuss

This is what drove me away from docker in the first place - only to find there’s little alternative today. Honestly, the poor reliability of docker on any platform, for so many years, has tainted it in my mind and I will change in a heartbeat if something better comes along.

comments