eh, i really did look for a joke. all i see is a “well actually” opinion that somebody here probably holds

Yes if you remove all frivolity I’m sure the joke will be funnier

I definitely agree on the last point. Personally I like languages where I can get the compiler to check a lot more of my reasoning, but I still want to be able to use all the memory management techniques that people use in C.

I remember Jonathan Blow did a fairly rambling stream of consciousness talk on his criticisms of Rust, and it was largely written off as “old man yells at clouds”, but I tried to make sense of what he was saying and eventually realised he had a lot of good points.

I think it was this one: https://m.youtube.com/watch?v=4t1K66dMhWk

That’s what std::move does, and you’re right that it’s quite an ugly hack to deal with C++ legacy mistakes that C doesn’t have.

I say move semantics to refer to the broader concept, which exists to make manual memory management safer and easier to get right. It’s also a core feature of Rust.

Also I’m talking about parametric polymorphism, not subtype polymorphism. So I mean things like lists, queues and maps which can be specialised for the element type. That’s what I can’t imagine living without.

I would have said the same thing a few years ago, but after writing C++ professionally for a while I have to grudgingly admit that most of the new features are very useful for writing simpler code.

A few are still infuriating though, and I still consider the language an abomination. It has too many awful legacy problems that can never be fixed.

The only conceivable way to avoid pointers in C is by using indices into arrays, which have the exact same set of problems that pointers do because array indexing and pointer dereferencing are the same thing. If anything array indexing is slightly worse, because the index doesn’t carry a type.

Also you’re ignoring a whole host of other problems in C. Most notably unions.

People say that “you only need to learn pointers”, but that’s not a real thing you can do. It’s like saying it’s easy to write correct brainfuck because the language spec is so small. The exact opposite is true.

I’m not a fan of C++, but move semantics seem very clearly like a solution to a problem that C invented.

Though to be honest I could live with manual memory management. What I really don’t understand is how anyone can bear to use C after rewriting the same monomorphic collection type for the 20th time.

They are both doomed because neither is transformative enough to justify adoption. They are going to need to solve much harder problems to do that.

Take Rust as an example. It solved a problem that most people weren’t even paying attention to, because the accepted wisdom said it was impossible.

REBOL is one of my biggest blind spots in programming language familiarity. I remember there was another REBOL revival project called RED, which always boasted huge feature sets with small amounts of code, though I never got around to investigating those claims myself.

This project seems to aim to provide strong foundations for a more performant compiler, but still lacks the most powerful REBOL features. I wonder if anyone can summarise those features? In particular, is there anything fundamental that distinguishes REBOL from Lisp, Smalltalk, Ruby, etc?

If you want to do anything other than long-term blue sky VM research, don’t write your own VM. That’s my advice. Same goes for programming languages, game engines, etc.

Always do the unambitious thing that seems like it should take one weekend, and probably set aside a month for it >_>

Also admit to yourself that things like bloat and binary size are not real problems, unless they intrude on your daily workflow. They are just convenient distractions from harder tasks.

I say this as someone who is constantly failing to complete any projects for all these reasons.

But I don’t see why by that logic any turing-complete language wouldn’t be in the group “portable”, including any hardware-specific assembly. Because you can always implement a translator that has well defined-behaviour?

What matters is the practical reality. Generally, languages are not portable when they don’t have well-defined behaviour, and when this causes their implementations to differ.

And thanks to this low standard for portability, a lot of VMs and high level languages are portable until you get to the FFI.

e.g. is 6502 assembly now portable that C64 and NES emulators are commonplace?

I would say yes! It’s just that portability is not the only thing required to make a VM spec useful.

But if you lacked other options, you could theoretically build gcc for 6502 assembly once, and then use the same binary to bootstrap the gcc on lots of different platforms, specifically thanks to the proliferation of NES emulators.

This would also only work if there is a standard NES API available in all the emulators that is rich enough to back a portable libc implementation. I have no idea about that part.

Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.

This is front and centre on the homepage…

It makes assumptions about the native architecture for the sake of performance, but it’s still portable because you can implement all that behaviour in a VM if necessary. The important thing is that the behaviour is well defined.

It’s not perfect but I don’t think the situation is any worse than in Java, C#, Lua, etc. If your hardware has non-standard floats you’re going to have a bad time with any VM.

My criticism is almost the opposite. I think LLVM is pretty easy and quite a good way of learning about low-level stuff in an incremental way. I just think it sucks to have it as a critical dependency in a mature product.

When I see a new language that is built around llvm I know the build time is going to be terrible.

As an aside, if I were teaching a compilers class I’d look quite seriously at wasm as a target. It’s pretty much the only target that is open-ended, high performance, and portable.

I’ve never used it though, so I don’t know how easy it would be for beginners to make sense of.

Now this is a cool project. Thanks for sharing!

I was quite interested in this project at the time, but I never saw any examples that could convey how this module system works, or what it makes possible.

I still have no idea today. It seems like a shame, as the high-level outline sounds great.

Wait until this guy finds out that Elon doesn’t actually build the cars

It does frustrate me that people say “composition over inheritance” and then act like the problem is solved.

For a start, dependency injection is an abomination. Possibly the single worst programming paradigm in the history of software development.

The only codebases I’ve seen that deliver on some of the promises of composition have been entity-component systems, but this concept hasn’t even matured to the point of being a first-class language construct yet, so the programming style is pretty janky and verbose.

I agree if we’re talking at the granularity of function signatures, but beyond that I don’t. Every language supports type inference when chaining expressions. Inference on local variables is often a way of breaking up large expressions without forcing people to repeat obvious types.

As for inferring code from types, scrub the symbol names off any production java code and see how much sense it makes. If you really go down this path you’re quickly going to start wanting refinement types or dependent types. Both great research fields, but the harsh reality is that there’s no evidence that either field is production ready, or that either solves problems in readability.

The best technologies for reading code are all about interactive feedback loops that allow you to query and explore. In some languages that is type-based, with features like dot-completion, go-to-definition, and being able to hover to see types and doc comments. And just knowing whether the code compiles provides useful information.

In other languages, like Python and JavaScript, that feedback loop is value-based, and in some ways far richer and more powerful, but it suffers from being unavailable in most contexts. Most importantly, the lack of error messages is not a very useful signal.

I am obviously no authority, but my honest opinion is that type inference is completely orthogonal to the questions that actually matter in code readability, so blaming it is silly.

The article doesn’t make a persuasive case at all. It immediately backs off by acknowledging that 99% of type inference is fine, because it’s really only complaining about function signature inference, which is an extreme case that only a few obscure ML variants like Ocaml and F# support.

It’s like saying all american movies are terrible, and then clarifying that you’ve only seen White Chicks

Author has paper rejected by territorial reviewer who expects everyone to cite their shitty type inference research.

Author drops type inference diss track in response.