garethrowlands

9 ms·

31.
by garethrowlands 1y ago
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.
32.
by garethrowlands 1y ago
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
33.
by garethrowlands 1y ago
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.
34.
by garethrowlands 1y ago
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 oddl
35.
by garethrowlands 2y ago
Kotlin is also nicely expression-oriented
36.
by garethrowlands 2y ago
Switch + goto is the classic way to implement a state machine in C.
37.
by garethrowlands 2y ago
Switch + goto is very close to being a native syntax for state machines. It's also very efficient.
38.
by garethrowlands 2y ago
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 u
39.
by garethrowlands 3y ago
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 happe
40.
by garethrowlands 3y ago
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
41.
by garethrowlands 3y ago
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 mech
42.
by garethrowlands 3y ago
Have you tried YAML? :-)
43.
by garethrowlands 3y ago
Not in my experience.
44.
by garethrowlands 3y ago
You're saying you don't want red squigglies in your IDE when you do your configuration wrong? Why?
45.
by garethrowlands 3y ago
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.
46.
by garethrowlands 3y ago
A major difference is that Nix has no type system or schema. Pkl is typed.
47.
by garethrowlands 3y ago
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
48.
by garethrowlands 3y ago
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.
49.
by garethrowlands 3y ago
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.
50.
by garethrowlands 3y ago
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 va
51.
by garethrowlands 3y ago
Haskell reports compilation errors as warnings too.
52.
by garethrowlands 3y ago
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
53.
by garethrowlands 3y ago
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 th
54.
by garethrowlands 3y ago
Yes, this book is excellent. And it's an antidote to some common advice that really isn't very good.
55.
by garethrowlands 3y ago
A parser isn't a functor in much the same way as a list isn't a functor.
56.
by garethrowlands 3y ago
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...
57.
by garethrowlands 3y ago
No, you won’t need that.
58.
by garethrowlands 3y ago
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.
59.
by garethrowlands 3y ago
Quite so. I’m currently reading Algebra Driven Design by Smart McGuire. It’s a valuable perspective.
60.
by garethrowlands 3y ago
I like this. He shows some of the basic ideas of functional reactive programming and of entity component systems. And then the thing about large objects not being efficient to update, well it's not efficient in C either, or in database

More ›