garethrowlands

On strings in Ada vs Rust. Ada's design predates Unicode (early 1980s vs 1991), so Ada String is basically char array whereas Rust string is a Unicode text type. This explains why you can index into Ada Strings, which are arrays of bytes, but not into Rust strings, which are UTF8 encoded buffers that should be treated as text. Likely the Rust implementation could have used a byte array here.

It's disappointing that your terraform experience with Typescript or python is better than your experience with HCL. HCL should really be better than it is.

Declarative languages can absolutely loop. Otherwise functional languages wouldn't be a thing.

HCL's looping and conditionals are a mess but they're wonderful in comparison to its facilities for defining and calling functions.

Any of the modern configuration languages would be better. They're all very sensitive to the problems of side effects and environment-specific behaviour - it's a defining characteristic. For example, pkl.

Terraform is good overall but HCL just isn't a very good language.

Given that its main purpose is to describe objects of various types, its facilities for describing types are pretty weak and its facilities for describing data are oddly inconsistent. Its features for loops and conditionals are weak and ad-hoc compared with a regular programming language. Identifier scope / imports are a disaster and defining a function is woeful.

Some of this is influenced by Terraform's problem domain but most of it isn't required by that (if it was required, people wouldn't have such an easy time doing their Terraform in python/go/rust).

Despite this, Terraform is overall good. But there's a reason there's a small industry of alternatives to HCL.

Kotlin is also nicely expression-oriented

Switch + goto is the classic way to implement a state machine in C.

Switch + goto is very close to being a native syntax for state machines. It's also very efficient.

As others have said, types don't necessarily exist at runtime. Types allow reasoning about the program source without executing it. Java is more the exception than the rule here; conventionally compiled languages such as C don't usually have types at runtime.

Absolutely.

It's often helpful to distinguish between effects and side-effects. The idea is that an effect is deliberate and explicit, such as, say, sending an email or moving a robot's arm. Whereas a side-effect is one that happens but wasn't your explicit objective - heating the CPU, say, or silently caching a value in thread-local storage. Haskell programs often use the type system to make these kinds of distinction.

The most common proofs are those that the compiler constructs while type checking. The compiled program is the proof witness. All compilers can be thought of as producing a proof-by-construction but they vary wildly in the propositions they can prove.

If this idea is new to you and you want to learn more, google "propositions as types" or "the curry howard correspondance".

Then again, abstractions can be helpful too, including in game programming. Epic's heavily invested, for example. Or in databases, relational algebra often beats out an array with linear access. I agree that OOP-in-the-small lacks mechanical sympathy though. That's one reason for entity-component-model, though another, I'd argue, is that it provides abstractions that are easier to reason about.

Have you tried YAML? :-)

Not in my experience.

You're saying you don't want red squigglies in your IDE when you do your configuration wrong? Why?

It's normal for a programming language to have the ability to define types and create values of those types. Pkl is entirely conventional here.

A major difference is that Nix has no type system or schema. Pkl is typed.

I really like On Lisp's message of building large things from small things. But when I read it these days it feels dated. The examples in the first part of the book are things that you'd expect in your standard library these days and the rest of the book solves problems you can import a library for. Macros can be simple solutions to problems that would otherwise be difficult. But the first section of the book mostly makes macros for things we'd use a higher order function for these days.

Not all inkjet printers require cartridges, of course. Some have ink tanks you just fill from a bottle. They're a bit more expensive than cartridge inkjets, but still affordable.

Glad you like your ET-8550! That's quite a high end, expensive printer. I have a much less expensive one, though, on reflection, I agree the initial purchase price is higher than cartridge ink jets.

Epson make EcoTank inkjet printers ink tanks that you refill from a bottle, not cartridges. It's vastly better than ink cartridges, there's no comparison on price, convenience or environmental impact. The tanks and bottles hold vastly more ink than a cartridge does. The printers are roughly the same price as any inkjet printer. I do not work for Epson.

Haskell reports compilation errors as warnings too.

The “push ifs up” advice is not about checking preconditions, it’s about selecting the right code path. If you have a function with a precondition, by all means assert it at the beginning of that function. For example, the Java type system allows nulls, so a function that requires an object should throw an exception if a null is passed.

Each call site is absolutely responsible for ensuring that it only calls a function if its precondition is true. This follows from the definition of precondition. Nothing can change that.

Calling a function in violation of its precondition is a bug (in the caller). And, sure, functions often need code that checks that (to prevent undefined behaviour). But we should distinguish these assertions from our program’s actual control flow. The article is about the latter.

No, the advice is good. If the wrong function was called, or a function is called with the wrong input, it’s just a bug and no amount of ‘validations’ can fix it. The article is written in the context of Rust, which has a type system, so the compiler can help check.

In cases where a function’s precondition can’t be expressed in the type system, the function should check at the start and bale. For example, it’s reasonable in Java to check if parameters are null (since the compiler cannot do this).

For more on this, Google “parse, don’t validate”.

Yes, this book is excellent. And it's an antidote to some common advice that really isn't very good.

A parser isn't a functor in much the same way as a list isn't a functor.

More things are parsers that that though. Here's an article that gives that kind of perspective, https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

No, you won’t need that.

The book the post mentions, A philosophy of Software Design, has a lot to say about having lots of small classes. It’s not in favour. That book is also strongly in favour of comments, lots of them. This book is well worth reading.

Quite so. I’m currently reading Algebra Driven Design by Smart McGuire. It’s a valuable perspective.