sullyj3

Fair point.

Consulting Wikipedia's "first appeared" field for each:

D: 8 December 2001; 20 years ago

Go: November 10, 2009; 12 years ago

Rust: July 7, 2010; 12 years ago

TypeScript: 1 October 2012; 10 years ago

Zig: 8 February 2016; 6 years ago

The only one of these which isn't at least twice as old as Zig is TypeScript, which has the might of Microsoft behind it, and is based on a well understood, pre-existing language.

This is not a fair comparison.

The problem is that whenever you want to do a quick tweak, you have to do a `home-manager switch`, which can take a good 15 seconds or so. It's not the end of the world, but it's a very annoying bit of friction. It's particularly painful if you're trying to quickly test out changes that you're not confident of and iterate. This is compounded by the fact that home-manager currently doesn't work properly with the new flake based profiles (https://github.com/nix-community/home-manager/issues/2848).

Oni was presumably dead in the water as soon as they switched from Neovim to vim, as the initial backers would have been primarily composed of neovim enthusiasts

Right, but Neovim does in fact have LSP support. That part is done, that's not a blocker for the It Just Works experience. It's that the editor currently doesn't come with the relevant configuration (in vimscript or lua).

The belief that an airtight definition is required in order for a concept to be meaningful is just philosophically confused. That isn't how concepts work. Conceptual boundaries are always fuzzy, with confusing edge cases and ambiguities, and that's ok.

I'd challenge people who think definitions are necessary to grapple with coming up with a definition of a chair, in the form of a list of necessary and sufficient conditions. Make sure you don't exclude anything commonly thought of as a chair, or include anything not commonly thought of as a chair. For an extra challenge, come up with a definition most people would agree on. This endeavour will be a struggle.

And yet we manage to discuss chairs without difficulty. We have a generally understood concept of what we mean by a chair, with central examples like dining chairs or lounge chairs commonly held to be chairs. In the case of ambiguities of communication, we can clarify on a case by case basis ("Did you want me to take the ottomans to the other room too?")

It's true that the documentation situation is pretty rough. However, The problem with this is that common usage of Nix is in kind of a bizarre state at the moment. We're in this limbo between the old `nix-` style commands and the new `nix ` commands, and between Not-flakes and flakes. These new features are labelled "experimental", but in practice they are widely used, and regarded as the inevitable future of the use of Nix. You don't want to be putting enormous amounts of effort into documenting all of the confusing gotchas of a situation that will ideally go away soon.

It makes more sense to make a strong push for getting the new features fleshed out, made user friendly, and stabilized, and then slamming the brakes and doing a documentation push.

In practice, this will take a long time, and it probably makes sense to concurrently work on documenting things that won't change. But I don't think at this stage dropping all feature work for documentation makes sense.

The other thing is that I don't think Nix's learnability issues come entirely from lack of documentation. A big chunk of the problem is a lot of very strange UX decisions and confusing defaults. Rather than documenting these as is, it seems better to put effort into fixing them, making default behaviour more intuitive and less confusing.

I feel like the point of the article isn't so much "how do I solve this specific issue" as "this is the general state of JS packaging", and the solution you present doesn't work in the general case of larger, less trivial dependencies

As usual, the headline is more sensationalised than the actual article

> It's likely that with a harder version of the Turing Test, in which real and fake images of the same content are presented side by side and people are told that one of them is fake, it would be much easier to detect the fake images.

I often use Ctrl-C to abandon a command I'm typing and get a new prompt.

I just don't think this is a problem in practice. Sure, some people advocate spending all your charitable dollars on X-risk, but I think most people find a happy medium of spreading their giving between the different causes they think are important.

I think it's telling that the people most critical of AI alignment as cause for concern so rarely engage substantively with the very reasonable case for taking it seriously.

I very much hope it doesn't

EA has done a great job bringing attention and resources to causes that are clear wins - it's just obvious that global poverty interventions like Against Malaria and GiveDirectly are highly beneficial.

But effectiveness doesn't always doing the most obviously effective thing. It means doing the highest expected value thing. Sometimes that means trying things with low expectation of success, but a high potential payoff.

There's a trade off between exploring the space of potential interventions, and exploiting known good ones. EA needs to keep its healthy focus on exploration, or risk getting stuck in a local minimum. Suppose the X-risk people are right - if we get that wrong there won't be any more people left to help. Certainly EA was sounding the alarm about lack of pandemic preparedness ages ago, and while that wasn't existential, it was the right direction to be looking in. Imagine if we'd had a bit better foresight, been a bit better prepared, and been able to prevent 6 million people dying of COVID.

Something sounding "weird" isn't sufficient reason to discard it. There needs to be an actual convincing argument. And let me tell you, the weird ideas have survived some pretty rigorous debate.

Well, they solve some problems.

This is a good illustration of a binary epistemology vs a continuous one.

> It's always impossible to tell, for any given sequence, whether it was produced by a fair die.

Something like "you can't make any determination, because it's random". Whereas under the second worldview you can make statements about how likely things are, despite uncertainty.

For some reason the binary worldview seems to be incredibly common. My sibling commenter exhibits the same issue.

Here's an example of an extended language model operating in a real world environment:

https://www.youtube.com/watch?v=ysFav0b472w

Tweag is also working on a gradually typed language called Nickel as an alternative, although it's not ready yet.

https://www.tweag.io/blog/2020-10-22-nickel-open-sourcing/

Asdf seems cool, My issue with it is that it seems to be wedded to the paradigm of having a single compiler/interpreter version active at a time for the entire system. I would rather use tools that allows project specific compiler/interpreter versions, without having to manually switch each time you switch projects.

Sorry but the notion that the docs are fine is laughable. Most nix functions don't even have doc comments. You have to figure them out by delving into examples in the depths of github. Nix is in dire need of a culture of providing documentation comments, along with a tool that builds them into a website, like rustdoc or haddock.

Redox too

For sure, which means it's the designer's responsibility to do due diligence in making certain they do understand it. Kickstarting such a process is not an ethically responsible thing to do, unless they are sure it and its future iterations are aligned.

The significant disanalogy is the amount of control parents have over their child's character compared to a programmer. Parents can pretty much do their best to raise a child, but the child may still end up screwed up. I wouldn't really put the blame at their feet. If they deliberately raise their child to be a killer, that's obviously another matter. By contrast, an AGI designer is in an unprecedented situation where they essentially have total control over the character of the being they're bringing into existence. If the AGI does bad things, it's very much on the programmer.

That stuff is an issue, but it's nothing compared to positive effects arising from an increased ability for people to communicate and coordinate in actual oppressive states

Does Kotlin have the equivalent of GeneralizedNewTypeDeriving or whatever is required to make math operators work without boilerplate?

This is always comprehensible in excel because state changes only ever come about as a result of a user changing a value in a cell. In the general case where there are a bunch of different asynchronous sources of change, this could become pretty confusing.

Right, there should be the ability to use either structural or nominal as appropriate.

If that were Haskell instead of python, it would still work, because tmp is never mutated. So it's not really state in that sense, it's just a binding.

    x input = show tmp
      where tmp = input * 5

It would be a different story if you had something like

    class IntState:
      def __init__(self, val):
        self.val = val
      
      def x(input):
        self.val += input
        return str(val)

Yeah, I definitely wouldn't want to argue against having type inference at all. I agree that you don't want to annotate every single local definition (although I'd probably lean towards annotating more often than most).

I'm more saying that I'm fine with type system features that break global inference, as long as there's still local inference that's usually good enough in practice.

A closer analogue is probably do-notation, which comprehensions are syntactic sugar for. Comprehensions can be terser for simple expressions, but for anything longer, do notation is generally more readable.

There are many things I like about Idris 2. I think I'll be more inclined to take it seriously as a practical language once it has the equivalent of Hackage, hoogle, and cabal. Right now I can't even read the standard library docs, I have to browse the github source. And I have no idea how I'd go about depending on a package. I'm sure I could figure it out, but I assume at this stage it's fairly tedious.