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.

I agree with this. I prefer explicit optional/null return types, otherwise the possibility of an error still exists but is now hidden to the caller. Langs with syntax for concise optional chaining and such fix this problem imo

Note that Typescript - the language of the examples - does have proper null through it's type system. A function that returns `T | null` will require callers check for null before using T.

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

This is true, but an ISO UK keyboard also "provides four easily accessible pairs of single-character symmetrical 'brackets'"; for this particular purpose there is no distinguishing factor between the two layouts.

There are other layouts in North America, including French (Canada), Bilingual (also common in Canada), Spanish (Mexico). Plus a multitude of people who have other preferred layouts. There is no official layout for this landmass.

They are identical when it comes to brackets.

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.

Another way to look at it is that it's designed to be a great "babytalk" language, the idea that everyone should be able to relatively easily learn enough of the language to easily get done what they need to easily get done. I'm not saying it's there yet -- doc is critical -- but that's part of the idea.

Conversely, whereas the P5 motto was TIMTOWTDI, the P6 motto is closer to TIMTOWTDIBSCINABTE, so there's usually relatively few idiomatic ways to do something.

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.

> "saved" via the Save menu.

Where is this menu?

Save menu? The snipping tool disappears as soon as release the mouse button, there is nothing else you can do with it.

lixquid is talking about the old snipping tool, not the one attached to Win+Shift+S.

I agree that it's really unclear what happens when you use Win+Shift+S to grab the screen. No indication at all that the image is on the clipboard.

There needs to be a Win+Ctrl/Alt+Shift+S that automatically saves to the Screenshots directory or something.

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

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

That's what I meant. Thanks! I corrected the typo.

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.

JavaScript is easy to debug and test, its relative safe, and closures makes it easy to write async programs. Compared to C or C++ you'll have a huge productivity boost with a very small performance penalty. It's also easy to learn compared to other languages. It also doesn't have a standard library which makes it easy to integrate into any platform. For example in Windows OS and other Microsoft products you've been able to use JavaScript as a scripting language for a very long time. So JavaScript is not a language that has only been available in browsers. There are actually people out there that prefer JavaScript and write in it voluntarily.

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.

Right, however javascript will still be the only full featured language having its runtime and libraries included with the browser. That means that for other languages, only the ones with fairly light runtimes and libraries could be suitable for inclusion in most web apps. This will limit the choices for non javascript general development. It may be possible to do a webassembly/webgl rendering engine to replace html/css using a limited set of dependencies.

Most news sources already load between 2 and 10 megabytes of Javascript, which is a significant fraction of, say, Python's runtime and many, many people browse those pages on mobile devices and connections without a problem. In Python's case, a large amount of the runtime size is taken up by all of the platform specific implementations of the standard library and they wouldn't work in the sandbox anyway.

Is there anything preventing Python.org from hosting the runtime environment on their CDN that everyone caches locally? Are there security issues from cross domain modules? Worst case, I don't think it would be hard to extend the LocalStorage API to cache modules between domains (perhaps with signed runtimes and a fallback).