jayvanguard

I agree that a lot of the AI risk pundits are either people with no real AI experience (or very outdated, resting-on-their-laurels experience) or if they do know AI, they probably know little about the complexities of running actual large scale, business or mission critical systems.

However, in their defense, the real question is whether those types of problems are something this new class of AI could potentially excel at. I've been an AI skeptic for decades, having had real world industry experience trying to get it to solve problems, and this is the first technological advance that has actually surprised me with its capabilities.

AI Risk still doesn't rank above many current, pressing global problems for me personally, but it also doesn't seem ridiculous anymore.

Exactly. What's interesting as well is how much this initial point in time will perpetuate forward as future language models are built on the output of the current ones, dampening any potential shifting in the overton window. They may try to avoid ingesting their output (ChatGPT says it can detect use of itself), but as more independent models get developed, the detection will never be perfect and in fact may be impossible at some point.

Just because you can do it, doesn't mean you should do it.

That was my question as well.

I think SOLID is appropriate for the public interface parts of your code but the internals should strive for YAGNI/KISS.

So the vast majority of your codebase should aim to minimize lines of code and abstraction. Of course there are exceptions - sometimes you really do need to encapsulate complex sub-systems with abstractions but you should have a clear justification.

Vancouver has changed a lot in the past 5 years. There are now two tiers of tech pay: the smaller companies that pay from low to ok and then a handful of SV companies that have moved in and are paying top tier money.

The dollar numbers are almost on par with the top SV salaries, albeit not with the current exchange rate. That fluctuates though.

Amazon opening up a new HQ in Vancouver will just strengthen this. The downside is that right now it is just a half dozen or so companies paying in this top range.

I don't think you're in the minority. Whenever possible the happy path should be inside the if. The article seems to imply otherwise but on re-read I think he is just building the case for putting the simple, quick pre-condition type handling up front which generally removes the need for the if/then (which I agree with).

For complex methods with branching logic you want prominently displayed, you'd end up with:

def myfunction(args) {

  // check preconditions, return early

  if (x) {
    // happy path
  } else {
    // less happy path
  }

}

But if the else just contains a bunch of error handling you always have the option of wrapping it in a handler method and putting it near the top in a on-liner.

Why did they change the name from the Trans Canada Trail? I liked it better.

Hah, interesting! Mine is writing a simple web server (sockets, IO, string handling) and an ultra-simple command line browser (args handling, 3rd party libs for URLs, HTML parsing, etc.)

It's probably a core part of their scalability that they never have to produce a complete list of posts. Every fetch is on best effort basis within a small time constraint.

When you're working in a large company with many developers spaces make more sense. Large companies generally pay more.

In a perfect world you'd use tabs for semantic indentation and spaces for stylistic indentation but this is too hard to implement in 100+ person teams and also can't be automated via an IDE style sheet.

Good point, the code locality is very important for maintainability down the road. When a single logical unit of functionality is unnecessarily split up across a file or even worse split into multiple classes it makes it much harder to understand.

The SEI work has been around a long time and it has had very limited success outside of academic or very controlled settings. It had its heyday in the late 90s but never really caught on broadly because it is impractical to collect the level of detail necessary, with consistent teams, languages, environments, and practices in a fast moving computing environment.