garethrowlands

The number one hard working concept in Haskell is parameterisation. A typical Haskell concept is just a concept, not a Haskell concept.

That map doesn't seem to include the trees in actual parks. Somewhere like Hampstead Heath or Richmond Park has actual woods.

That's awesome. Though, it doesn't seem to think Hampstead Heath has any trees. Nor Croydon, not even Thornton Heath. The Wilderness in Richmond Park seems to be a missing spot, as are some of the plantations (maybe Isabella Plantation, my map fu is failing me). Maybe the royal parks keep their own records?

Citation needed.

STM isn't really used in Go like it is in Haskell.

Here's the example from a Go STM package that's based on Haskell STM. It has gotchas that you won't encounter in Haskell though, due to the nature of these languages.

https://github.com/anacrolix/stm/blob/master/cmd/santa-examp...

For the equivalent Haskell, check out the link at the top of the file.

It's very good. And quite short!

XSLT's matching rules allow a 'push' style of transform that's really neat. But you can actually do that with any programming language such as Javascript.

I used to use XSLT a lot, though it was a while ago.

You can use Javascript to get the same effect and, indeed, write your transforms in much the same style as XSLT. Javascript has xpath (still). You have a choice of template language but JSX is common and convenient. A function for applying XSLT-style matching rules for an XSLT push style of transform is only a few lines of code.

Do you have a particular example where you think Javascript might be more verbose than XSLT?

The term 'variable' is from mathematics. As others have said, the values of variables do vary but they do not mutate.

One way to get some intuition with FCIS is to write some Haskell.

Because Haskell programs pretty much have to be FCIS or they won't compile.

How it plays out is...

1. A Haskell program executes side effects (known as `IO` in Haskell). The type of the `main` program is `IO ()`, meaning it does some IO and doesn't return a value - a program is not a function

2. A Haskell program (code with type `IO`) can call functions. But since functions are pure in Haskell, they can't call code in `IO`.

3. This doesn't actually restrict what you can do but it does influence how you write your code. There are a variety of patterns that weren't well understood until the 1990s or later that enable it. For example, a pure Haskell function can calculate an effectful program to execute. Or it can map a pure function in a side-effecting context. Or it can pipe pure values to a side-effecting stream.

Surely transactions are a pretty good example of where functional core / imperative shell is a good guide. You really don't want to be doing arbitrary side effects inside your transaction because those can't be backed out. Check out STM in Haskell for a good example.

I'm unclear what you're suggesting here. Are you suggesting you couldn't write a POS in Haskell, say?

Indeed, the general idea of imperative assembly comes to mind as the ultimate "core" for most software.

That's not what functional core, imperative shell means though. It's a given that CPUs aren't functional. The advice is for people programming in languages that have expressions - ruby, in the case of the original talk. The functional paradigm mostly assumes automatic memory management.

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.