I wouldn't recommend the Gang of Four book. Many of the design patterns they espouse are way over complicated from the days of peak OOP. You know, FactoryFactoryVisitor stuff. Usually best avoided.

I don't. You can't even copy to the clipboard in an insecure context.

Except... You can! You just have to use the old deprecated and ridiculously awkward execCommand method.

If that's so insecure why do all browser's still support it?

The article said it pretty well:

if your answer to any perceived failing in a person is “just try harder”, you are either woefully inexperienced or a just a dick

That applies to writing impossibly comprehensive unit tests too.

Though really for a filesystem they should really do silicon-style verification (which we're calling Deterministic System Testing now).

Ah this ancient nonsense. Typescript and JavaScript get different results!

It's all based on

https://en.wikipedia.org/wiki/The_Computer_Language_Benchmarks_Game

Microbenchmarks which are heavily gamed. Though in fairness the overall results are fairly reasonable.

Still I don't think this "energy efficiency" result is worth talking about. Faster languages are more energy efficient. Who new?

Edit: this also has some hilarious visualisation WTFs - using dendograms for performance figures (figures 4-6)! Why on earth do figures 7-12 include line graphs?

What would they sign it with? How do you verify the signature?

I'm going to try with an awful language so I can better criticise it in future.

Oh cool how do I run VSCode in Termux?

I disagree. It's a sign your code isn't structured in a way that the borrow checker understands, but that is a subset of well-structured code.

In other words, if your code nicely fits with the borrow checker then it's likely well structured, but the inverse is not necessarily true.

One thing I always run into is using lambdas to reduce code duplication within a function. For example writing a RLE encoder:

fn encode(data: &[u8]) -> Vec<u8> {
  let mut out = Vec::new();

  let mut repeat_count = 0;

  let mut output_repeat = || {
     out.push(... repeat_count ...);
  };

  for d in data {
      output_repeat();
      ...
  }
  output_repeat();
  out
}

This is a pretty common pattern where you have a "pending" thing and need to resolve it in the loop and after the loop. In C++ you can easily use lambdas like this to avoid duplication.

Doesn't work in Rust though even though it's totally fine, because the borrow checker isn't smart enough. Instead I always end up defining inline functions and explicitly passing the parameters (&mut out) in. It's much less ergonomic.

(If anyone has any better ideas how to solve this problem btw I'm all ears - I've never heard anyone even mention this issue in Rust.)

I never did a CS degree but recently I've been doing some things that make me wish I had. But it isn't any of this stuff which seems mostly programming things that you can easily learn outside academia.

The stuff I would like to understand which I haven't yet been able to learn on my own is the hard computer sciency stuff: lambda calculus, type inference (how do you read that weird judgement syntax?), how SAT/SMT solvers work, dependent typing systems... Does anyone have any good resources for those sorts of things?

Looks nice. Well as far as I can tell anyway. Maybe next time you're showing off a GUI don't make the screenshots 320x240?

Anyone know what toolkit they are using? As far as I know none of the Rust GUI toolkits are close to mature.

Edit: it's iced.

Quite a lot of misunderstanding here I think.

This will make the point of your language being compiled entirely moot imo.

Not at all. Compiling to machine code rather than bytecode isn't about avoiding having a runtime. Hell, C has a runtime. It's called the C RunTime (CRT).

ML/Scheme/CLisp achieve memory safety through closures. Haskell achieves this through Monads.

No they use garbage collection and bounds checking just like imperative languages. There are some slight differences but those are nitpicks.

Functional languages have a property which allows them to be be both compiled into machine code and bytecode, and also, interpreted like an scripting language.

Absolutely nothing to do with being functional or not. Dart is not functional and it supports AoT and JIT compilation.

You can’t describe what C does with math.

You absolutely can describe what C does with maths. I understand it's very hard but check out CBMC for example.

What C does depends on the platform, the CPU, etc.

So does Rust to some extent, e.g. usize.

Semantics here is clear. Right?

I have no idea what you're trying to say here. The lifetime is completely irrelevant here because you have no references.

What is a ‘function’ in C? Well most C compilers translate it to an Assembly subroutine, but what if our target does not support labels, or subroutines?

The C specification says what a function is.

You see what I am arriving at?

Not even remotely lol

Well, I can't read it... But I would say it's nonsense that Git is intrinsically confusing. The core data model is extremely simple and intuitive. The problems are:

• Terrible CLI.
• Terrible terminology (index is probably the worse; why not draft commit?)
• Bad tutorials. Lots of them explain things wrong or just confusingly
• It's a fundamentally visual problem yet so many people advise against using a GUI.

It's like trying to explain CAD using OpenSCAD instead of SOLIDWORKS. Of course it's going to seem like CAD is confusing.

That's not to say Git's data model is perfect. What's there is decent but there are big gaps. Support for large files is bad (LFS is a hack). Support for very large projects is bad (monorepos tend to get slow and sparse checkouts are difficult; submodules have lots of issues). Conflict resolution tends to be very dumb, though I think there are some projects to improve that.