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.

Check out the ACM Tech Packs. They are curated lists of papers organized by topic.

https://techpack.acm.org/

I followed this link to a SlateStarCodex article on Google Correlate. At the top of the Google Correlate page was:

"Google Correlate will shut down on December 15th 2019 as a result of low usage. You can download your data under Manage my Correlate data in the top bar, or right from here"

Good timing! Get your correlations in while you can.

https://www.google.com/trends/correlate

https://slatestarcodex.com/2013/02/16/google-correlate-does-...

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.

This article needs to be shown to all upcoming architects, senior developers, and design minded engineers. Too often the balance between abstraction and specialization isn't thought about explicitly but rather dogmatic rules kick in.

I'd be interested to hear if he has also looked into any parallels with the pre- and post-telephone generation. I'd imagine that was a similar in many ways, particularly since public airplane transportation came of age in roughly the same era.

I find TIOBE to be so far from reality I question why it exists and anyone continues to pay any attention to it. It still ranks Delphi higher than Objective-C. Assembly language above Visual Basic. Dart above Scala, Erlang, Haskell, and Bash.

Is he though? Questions on the most performant way to iterate over something rarely result in flame wars.

I believe you are thinking of people arguing over JS frameworks or whether JS sucks or not. Both are identity related.

When it comes down to arguing the specific mechanics of comparing how framework X uses MVC vs how framework Y uses it, you don't see so much conflict because it is expertise, not identity driven.

I'm surprised the outsourcing companies aren't listed on this. They are often huge contributors to the overruns.

Yes, definitely not double. In fact, they aren't actually better than other top end competitors, they are just a bit different, which gives enough wiggle room for fanboys to claim something "magical".

http://www.dxomark.com/Reviews/Leica-M-review-How-does-the-n...

That said, I really like the manual focus tabs on the lenses and the mechanism on the Q looks interesting. The Q is also newer so likely has a few improvements, but in general Leica has always been a bit behind the likes of Nikon, Sony, and Fuji in terms of electronics and firmware. Where they win is build quality.

I quite like Sublime Text 3 as well, but only because it has a vi mode.

Up to iOS 7 at least, there was no way to run in the background without the app being launched at least once. I haven't worked with the latest two versions though.

Evernote is a great product that fits an valuable niche for many people. The only problem is that it got trapped within a venture capital ecosystem that wants it to be more than it should be.

The article is dubious at best. You hear about the big failures or notice when rewrite releases take forever, but you never hear about the companies that slowly lose opportunities or fail to keep up with innovators because they keep trying patch a crappy codebase. Nor do you necessarily hear about the successful rewrites since they just happen under the covers.

I thought this was well known enough everyone would get the joke. In fact, I was surprised to see Matt's scripts were still kicking around on a website other than the wayback archive.

I suppose you might want to use CGI.pm for some low level stuff but I find I can still get most of what I need by copy and pasting stuff from Matt's CGI scripts (http://www.scriptarchive.com/).

Keeping sticky eyeballs from the first internet generation around.

A component is is meant to be re-used in different contexts, a view not necessarily.

I see it as a gradual thing. Early in the project loosey and then as the software matures add in more typing. But yeah, everyone needs to agree on the right level for that stage in the project.