I believe you (other than tests being specifications, they are examples at best). But that doesn't change the fact that TDD looks more adopted in untyped languages, and that deserves an explanation.
Mine is that a lot of potential errors (typos, type mismatches) don't need to be exercised by running code in typed language.
I'm a Haskell bro and I love testing. You misunderstand me, though. All I say is that maybe _some_ of those tests deliver value by just making sure that code even runs, which is otherwise covered by types.
> That also explains why TDD is more popular in say Ruby or Python vs. Java.
I'd say that TDD being more popular in untyped languages speaks against TDD, as it hints that maybe some of its benefits are covered already by a type system.
> it violates various architectural principles, for example, from the point of view of our business logic, there's no such thing as "tenant ID"
I'm not sure I understand how hiding this changes anything. Could you just not pass "tenant ID" to doBusinessLogic function and pass it to saveToDatabase function?
Thanks. This does sound like a state machine, though, but the devil is probably in the details. Yes, here Haskell is probably a bad choice, and something where direct memory manipulation is bread and butter should do better. Which is completely fine; Haskell is a high level language.
But in your example, PHP is also a bad choice, and alas, it dwarfs Haskell in popularity. I can't really think of where PHP is a great fit, but Haskell isn't.
4. History. In those types of discussions, there are always "rational" arguments presented, but this one is missing.
> One with lots of persistent mutable state.
You mean like a database? I don't see a problem here. In fact, there is a group of programs large enough, that Haskell fits nicely, that it cannot be 3; REST/HTTP APIs. This is pretty much your data goes in, data goes out.
> It's almost never "we just don't have to care" when comparing to most other popular languages.
Struggling with Haskell type system is not an experience of somebody who has developed an intuition about Haskell type system. Granted, it is not a binary thing, you can have good intuition about some parts of it and struggle with others.
I think they way you put it is, while technically true, not fair. Those "most other" languages are very similar to one another. It is not C# achievement, that you don't struggle with its type system coming from Java.
This is like people struggling with Rust because of burrow checker, well, they have probably never programmed with burrow checker before.
I do AoC in SQL, I wish it was true. With Postgres, you have lots of regex/string manipulation functions that make it easy.
For me, the biggest problem was memory. Recursive CTEs are meant to generate tables, so if you are doing some maze traversal, you have to keep every step in memory, until you are done.
Yes, I thought I just wanted to chill and listen to a song, but actually cutting-edge AI technology decided that I will have a better time listening to this car mechanic over-reacting to my favorite song, that he surely hears for the first time in his life.
Not to mention that our AI-overlords coming out swinging, with a billion of dollars research behind, couldn't figure out that if I'm looking for a live recording of a song, then maybe, just maybe, I actually know those other songs too and could search those if I wanted to. Let's give them a few years to go back to search results they had a few years ago.
And the modern web search tools don't even try to be good at searching, but some engagement-bullshit-here-is-something-that-might-interest-you contraption.
I love listening to bootlegs (recording of a concert that is not official, mostly done by fans). I happen to be a fan of a band that has quite dedicated fan base and tons of bootlegs. I remember, and I'm quite sure of it, that I could type "<BAND> <SONG> <YEAR> live" in youtube search and get pages upon pages of exactly that. Recording of the song by the band, in given year.
Today if I type "tool right in two live" I get:
actually what I requested - 12
official audio - 1
cover song - 4
other song by the band - 12
full concert - 4
"reaction" video - 4
And after that there are mostly "reaction" videos, yea, just what I wanted. Try it out, it's actually funny (and sad).
That makes no sense to me. If this coder has to access array by index twenty times a day, then he is going to remember it, eventually, no? If is it rare that he has to do it, then why memorize it?
You really think there is more value in remembering how to do something in some arbitrary, shitty, programming language than understanding the concept of doing it? With understanding the idea you can do it in any language, at any time, it is just a few seconds away.
To be fair if your config is just a structure with strings then you declare your types only once, too. Minus the codegen, but also minus the editor integration.
I'm not hating on Pkl here, we deserve better in this space, so I'm happy with more developments.
It's nice, but it comes at a cost. For example, every user of toml forever will have to put strings in quotes. Why? Because having other types creates ambiguity, that is resolved by this one simple trick.
But if you don't quote them then you have "the Norway problem" like in yaml.
My take on this is that there is not obvious reason not to, but it just so happens that typed configuration languages are not rich enough and not integrated enough to be that useful.
Those languages that arrived with the JSON hype train like yaml or toml might be great for dynamic languages, where you can load them to some native object. But in statically typed languages you are gonna declare your types, in code, anyway. So configuration providing types doesn't really do much.
Mine is that a lot of potential errors (typos, type mismatches) don't need to be exercised by running code in typed language.
Yours is... well, you don't really address it.