Once it's available in even one browser not behind a flag, sure, but while it's still entirely undocumented and only available to people who both use Chrome Canary and know to go turn on a specific flag?
In terms of task running specifically it does generally stay that simple for the likes of just.
The only complexity there is getting it installed on everyone's machine, but that's true of most tooling, even the common stuff given versions won't match. I solve that with Nix.
I agree that the documentation story could be better. I also think it's a great shame that the language isn't statically-typed, so to understand how to use something I have to inspect its source code.
I've found it to be quite flexible though. For example, here's a commit in which I apply a patch to a tool to solve a problem that the derivation hadn't taken into account (and absent a home-manager solution): https://github.com/samhh/dotfiles/commit/867dd3b4d4b3942a0aa...
Static types are documentative, and language servers often also show you things like JSDoc alongside the type signature. Nix has neither of these, hence I have to check the source code or run a build and see what happens.
I really like Nix but in this particular way it feels like taking a big step backwards from the other languages I frequently use, particularly for a language in which you'll necessarily be constantly interacting with bespoke interfaces.
Informative function signatures, allowing programmers to add per-function documentation, and tooling that displays those things are by no means limited to staticly typed languages.
I guess knowing allowed types for each parameter is informative (more if very specific types are used rather than string or integer), but documentation usually specifies that anyway. And even knowing all the types isn't usually enough without documentation.
My point is just that I've used plenty of libraries in dynamically typed languages without needing to read the source. And conversely, I've occasionally needed to look at the source of a function in a staticly typed language, to answer some question not answered by the types and documentation.
Being able to see a function's entire type signature at a glance is the single most useful way of documenting code I've ever come across. No alt-tabbing to docs or relying on an IDE to pop up hints, etc., it's just right there.
Haskell is the ideal here, since it separates the type signature into its own separate line at the top of the function declaration. That confers readability and reduces cognitive overhead more than any other language I've used.
It also changes the programming thought process. You can pseudo-code an entire program just with function type definitions. Then test that the type defs compile without error, and go back and implement the function definitions. As long as the function definitions adhere to their type signature, the program almost always works (barring some I/O errors).
Not all statically typed languages are created equal. The ones fundamentally oriented around function type signatures, rather than variable types, are the ones I think parent had in mind in his comment.
Yeah, Arcade's selection is very lackluster. I have it as part of my Apple One subscription and I personally enjoy it, but I'm not much of a gamer and I'm pretty sure most serious players would rather have Game Pass.
Anecdotal but everywhere I've worked on JS codebases has used lockfiles. It might be this isn't affecting that many but those it is affecting are loud.
If you interpret "spirituality" this broadly then the word is useless. This is why you'll receive some dismissive answers.
I drink espresso every morning. I challenge you to find a way to link that to this thread that isn't as useless as defining a synonym for the word "habit", or "preference", or similar.
Reality doesn't have to be interesting, nor do the results of self-examination. As best I can tell I'm a biological entity with a false sense of self and free will on a rock in the middle of an unfathomably large universe, the existence of which I will never understand. That's it. That's actually already quite interesting. Why do so many feel the need to try and force the elevation of the everyday and the mundane into that same plane? And worse yet, to speak condescendingly of others as you do so.
I don't personally interpret it that broadly, but I've been surprised and delighted by the range expressed in other comments today! So at least to me I can't really consider that broad definition useless, at least across a group of people.
Yes, impurity (or rather the representation thereof) is contagious. This is where the common "functional core, imperative shell" comes into play. You generally try to push side effects to the edge.
There are other approaches you can take too, like encoding your effects in a monad which has a different runtime representation in tests. It's like mocking on steroids with type safety.
reply