Never? Never is a long time.

That said, by the time you can actually run a significant software company without any programmers it seems likely that you could also run most white collar firms with vastly fewer employees and then we're going to have bigger problems.

Right, I'm not saying it isn't simpler in terms of syntax. The point I was making is that the syntax is simpler but in a way that makes it worse because while it's easier for computers to read, it's harder for humans.

it was only later discovered that they can be compiled down to native code.

That sounds extremely unlikely. I think you're misinterpreting this quote (which is fair enough; it's not very clear):

Steve Russell said, look, why don't I program this eval ... and I said to him, ho, ho, you're confusing theory with practice, this eval is intended for reading, not for computing. But he went ahead and did it. That is, he compiled the eval in my paper into IBM 704 machine code, fixing bugs, and then advertised this as a Lisp interpreter, which it certainly was. So at that point Lisp had essentially the form that it has today ...

As far as I can tell Lisp was always intended to be compiled and executed. That quote is about compiling the eval() function (which was just meant to explain how Lisp is executed) into a binary and using that as an interpreter.

Also I skimmed the paper that is from, and in fact Lisp was intended to be targeted by AI (in the same way that we get AI to write and execute Python to solve problems), which explains a lot. It wasn't designed for humans to write, so why bother with nice syntax; just have the machine write the AST directly!

(I expect that was only part of the motivation tbf, but still!)

Actually chars() is pretty simple - it's just UTF-8 decoding which is elegant and simple.

The complexity is all around unicode, not UTF-8.

This is awesome. It gets closer to Deno which I think is one of the only things that have actually solved the "ad hoc scripting" challenge, which requires:

1. Easy to install language.
2. Easy to use third party dependencies (from a single file script).
3. Easy to import from other files without setting up a whole project.
4. IDE support.

At one end we have Deno which nails all of those. At the other, Python which fails all of them pretty miserably (despite this being one the most popular use cases for Python).

Seems like with this Rust will have 1 and 2 solved, and I guess 4 isn't too hard. What about 3 though?

If I eventually decide I want to split my one file script into two files will I be able to?

Edit: I had a play and actually it's good news!

• If you want to split up a script you can just do mod foo and it will look for foo.rs (or I guess foo/mod.rs) in the same directory!
• For common code, which you might want to import from e.g. ../../common you can't just use mod but you can add common = { path = "../../common" } to [dependencies]. That directory has to be a proper crate with Cargo.toml but I think that's ok and probably desirable.

The only downsides I found are:

1. No IDE support yet.
2. It prints compilation messages to stdout, which kind of sucks.
3. Even after it has been built, it still does incremental compilation every time you run it, leading to more compilation message noise, and ~100ms startup time.

This is 14 years old by now - hardly "modern". RAII itself is even older.

Hmm I think just using SQLite or DuckDB with normalised data would probably get you 99% of the way there...

Config should be pretty flat.

Why? I don't see any reason for that.

TOML rocks precisely because it nudges you into making simpler configs.

This is just "you're holding it wrong".

In most cases you don’t, and when you do, it’s possible and not unreasonable.

Really. Here's the first Gitlab CI example I could find:

lintDebug:
  interruptible: true
  stage: build
  script:
    - ./gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint
  artifacts:
    paths:
      - app/lint/reports/lint-results-debug.html
    expose_as: "lint-report"
    when: always

Let's see the TOML:

[lintDebug]
interruptible = true
stage = "build"
script = [
  "./gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint"
]

  [lintDebug.artifacts]
  paths = [ "app/lint/reports/lint-results-debug.html" ]
  expose_as = "lint-report"
  when = "always"

Gross. The tool I used to convert even added extra indentation because otherwise it is unclear.

IMO JSON5 is the best:

{
  lintDebug: {
    interruptible: true,
    stage: 'build',
    script: [
      './gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint',
    ],
    artifacts: {
      paths: [
        'app/lint/reports/lint-results-debug.html',
      ],
      expose_as: 'lint-report',
      when: 'always',
    },
  },
}

This is much clearer than TOML and less ambiguous than YAML. It could do without the outer {}, but overall it's still better.

This is the sort of thing you have to learn by experience, like how you can't really learn good coding taste from reading a list of rules (though some lists are helpful).

Anyway in my experience documentation is quite different in public (i.e. seen by customers) and private (inside your company). For internal stuff there's a much smaller incentive to document things because:

1. documentation tends to be inconsistent (as you discovered), so people give up looking for it. Instead they just ask other people. This actually works fairly well inside a company because you can generally easily access whoever is responsible (as long as they haven't left).
2. there aren't customers to keep happy and away from support.

I think the best thing to do is to accept that people aren't going to expect documentation internally. There's zero point writing guides to tools on your company wiki or whatever, because nobody will even try to look for it - they'll assume it doesn't exist.

Instead you should try to keep your documentation as close to the user as possible. That means, don't have a separate docs folder in your repo - put your docs as comments in the code.

Don't put deployment instructions on your wiki - add a ./deploy.sh script. It can just echo the instructions initially.

This is really terrible advice. Sometimes it's better to do that, but definitely not in the example from this article.

If anyone says you should always prefer polymorphism to switches they are a bloody idiot.

Neat hack, but IMO this just loses waaay too many features and UX that Github et al. have. Only masochists will use this. Here are a few I can think of:

1. From a user perspective it's "simpler" in that it saves maybe 1 command... git push (I've still going to want to make a branch), and clicking on the "create a PR" link. But you've also made updating a PR way more of a pain - it was git push, now it's... I dunno some long command I don't remember and looking up a PR number in the web interface?
2. Can't request reviews from people.
3. Can't enforce review requirements.
4. Can't require review comments to be resolved (I bet it's easy to miss review comments!)
5. Can't easily tell who wrote review comments. Are you really supposed to have a conversation by adding // Dave: I agree under comments?
6. Can't add comments to code that doesn't support comments (e.g. packages.json)
7. No CI integration.

I guess some of those are fixable, but overall this seems like a clever hack but very clunky.

I guess it's better than a mailing list at least.

Honestly it's quite obvious from the code snippet and the diagram but I can spell it out:

Go is a quite nice language but mainly because of its fantastic infrastructure. Compilation is very fast, cross compilation is trivial, it makes static binaries that don't even depend on glibc (compatibility nightmare on Linux), the module system is great, it even has built in fuzzing support - how many languages have that?

However the language is decidedly meh. It doesn't have some modern features that make programming much more pleasant. Notably:

• Tagged unions, aka discriminated unions, aka sum types. These vastly improve type safety and are just very convenient.
• Expression based. People can go overboard with this but I don't think anyone who has used an expression based language would want to go back. Some common tasks like the let msg in the example are just so tedious if match is a statement.
• Optional. Somehow Go copied the billion dollar mistake. In fairness languages like Typescript and Rust weren't around when Go was designed so it may not have been obvious to the authors that this was the way to go.

So this is basically a do-over of Go but if it had been designed by someone familiar with these modern best practices in language design.

It also does exhaustiveness checking for enums! Pyright is probably the best thing about Python.