lixquid

I believe they mean token costs aren't a concern when you're not paying for a SOTA model via API, and are instead running local models.

Infinite monkeys on infinite typewriters, and all that.

Why wait until then? The loudest and earliest crash you can get is a failure to compile with a rich type system (obviously, when possible).

Program logic fundamentally has to contend with different conditions. Sometimes the user will be logged in and have friends, sometimes they won't.

The "maybe" style has the inconsistency embedded in the type system; it's impossible to have an invocation to getFriends and then not handle the resulting possibility of not being logged in.

Shifting it up to the caller just means that you're going to have to remember to ensure the user is logged in before calling getFriends otherwise you'll get some kind of error, which might give you more control, but now there's no guarantee in the type system that you've handled the case where the user isn't logged in.

Writing ifs everywhere to handle failure conditions might be a bit of a pain, but that's more of a failing of the language than the style.

The ISO UK keyboard layout exists. The North American keyboard layout is North American, not "English".

It's asymmetric; it is significantly easier to make a clear image harder to read than it is making a fuzzy image clearer, and the same applies to data sets.

There might be swaths of teams all focused on enriching the data, but you eventually can't derive more information out of a deliberately flat information graph, and all it takes is a few extreme data points to distort the average.

That's understandable; if you look at the slides and see all of the integrated features in one big blast, you're going to think "holy moly this was not meant for mortal men".

In a way that's correct, because ultimately Perl6 is designed as the ultimate "kitchen sink" language; it has all the little features you could think of already baked in, which will include a lot of features you won't use.

The main reason for this stems from the overarching design philosophy; "There is more than one way to do something". The language ultimately tries to be as flexible as possible, going so far as to support modification the the core grammar, the object system, etc.

This is meant to make the developer as comfortable as possible, but it can lead the common case of perl-itis, also known as "write-once, read-nonce" code.

I'm sure you probably discovered this by now, but the image is kept in memory until it is "saved" via the Save menu.

The UX could probably do with some improvement showing that the image is not automatically saved to disk, like scrot or OSX's Image Capture shortcuts, though.

Symbol.for("a") != Symbol.for("b")

Perhaps you meant Symbol.for("a") for both?

Personally, I'd say Lua and its family of small, easy languages more easily fills those roles.

Not that I doubt some people do voluntarily enjoy JavaScript, but because of the sheer volume of StackOverflow questions, blog posts, micro-techologies, and other assorted attention bestowed upon the language it can be easy to make the logical jump that JavaScript the language is far more popular (in the satisfaction sense) than is actually so.

I'd wager a lot of this popularity is correlation, not causation. A lot of its popularity stems from being the dominant browser scripting language. This causes it to be popular with back-end frameworks for code re-use and shared developer skill. This causes it to be popular with, say, database engines that are used by the back-end, and so on and so forth.

WebAssembly is the first steps to truly breaking that chokehold, and truly seeing how popular JavaScript the language really is.

Please do not compare all of the UK's immigration services with the way one customs agent handled their bad day.

I think that the author does get the pun; they made another of a similar calibre in the title of the post!

Their main objection to the pragma would seem to be the MONKEY-SEE-NO-EVAL name; if you don't understand the reference, say you're a non-native speaker, or just have no idea what it's referring to, all you'll see is "NO-EVAL", and then get confused why the code suddenly allows EVAL everywhere. Levity and fun is perfectly acceptable, but is it just as acceptable when the language is less obvious for it's extended developer community?

But.. they are exploiting people. That's literally what they are doing; expecting people to purchase these tickets at a higher cost for the simple reason that supply is short.

Tell that to the drunk car crash victim, or the overloaded EMT at closing time.