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.
> Most of DuckDuckGo's non-privacy-related selling points are their instant answers, which in my experience are really good.
And yet has no undeprecated pipeline for submitting non-"essential bug fixes" to[1].
I really love the idea of having an engine that does just a little bit more for me up front, but not if it's all closed off; that's what I'm trying to get away from.
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.
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.
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.
Isn't that the whole point of this post though? They've allowed you to edit files marked as "system files" despite a multitude of warnings, and now so many people have fucked up doing so that they've issued a stronger warning.
What's the solution? Put less warnings? Then you'd get even more people destroying their data. Put more warnings? Then you'd get more people complaining that "Windows doesn't let you edit what you want!".
I think your "death by a thousand cuts" comment really resonates with me; but it is a point against MacOS (and Windows!), not for.
Yes, most things "just work". But if something just doesn't quite work in the way you want it to, you often have to move heaven and earth to hack around the problem, maybe even "accepting" that there's nothing you can do, and constantly suffer that irritation every time you butt up against it.
Personally, I have always preferred having my environment "just-so". After suffering constant little niggles when I'm forced to use MacOS or Windows, it's wonderfully refreshing to come home to my configured linux system.
Infinite monkeys on infinite typewriters, and all that.