youerbt

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.

Yours is... well, you don't really address it.

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.

But they chose a solution (if I understand correctly), where tenant ID is not in the signature of functions that use it, either.

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.

So why hasn't it happened?

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.

One exception for me about >>=, is instead of this:

thing <- getThing

case thing of

writing this:

getThing >>= \case

Not so much because it is less code, but fewer variables to name.

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.

This news is about conscription they do twice a year, regardless of the war.

This isn't even hyperbole.

Is there even some big scale mobilization going on in Russia right now?

Or is this just the standard dig at Russia, because the topic is related to Russia?

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.

Oh, I didn't comment on the Pkl, just on the status quo. My bad for not making that clear.

"Enough" is the keyword here, time will tell I guess.

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.

Yes, it's like the difference between adding a task in Jira vs in some todo.txt file.

Slowness of the interface aside, you just have to do the whole ceremony for some simple don't forget/think of it later note.

the alternative seems to be aggressively metricize and cut

This is, for me, the funny part about it. If all those metrics, meetings, tickets and what have you, pushed mostly by the management btw, can't help them, then I'm afraid nothing can. ROT is as much of an excuse as the above.

Thanks, that might be just what I'm looking for!

We should ask them instead to modify the existing INI file. I bet most would do just fine.

I have seen this post on HN before and I wasn't received very well AFAIR.

But I can't help agreeing with its main point: so much complexity to support a few basic data types that are not sufficient for anything complex anyway.

I feel like natural joins simplify writing queries, but not exactly reading them (especially if you are not familiar with the database). IMO a good compromise is the USING clause, which acts like a natural join, but columns have to be named explicitly.

Programming languages are tools to get shit done.

I, on the other hand, find it baffling that some programmers, despite the fact that programmers generally make computers useful for other people, don't care how computers can be more useful for them.

Those guys in the "square wheels comic"[0] are also getting shit done.

[0] easy to google

While not many didn't touch it, many for sure didn't consider it for AoC: SQL.

You can go for one query solution or use views/tables for multiple steps.

It's an acquired taste for sure, but I kinda like it!

It can also get confusing, because in some languages there is no general notion of being a tuple or n-tuple if you wish. Even if they are casually all called tuples.

For example in Haskell 2-tuple and 3-tuple are simply distinct types, as distinct as Int is from String. You can't speak to the type system about "all n-tuples".

I'd call that function: polymorphic over tuple length.

Either business data and job are committed or none of them. Then as you write, either polling or listening to an even worker, can pick it up. Bonus stuff, from implementation perspective, is that if worker selects row FOR UPDATE (locking the job from others to pick up) and dies, Postgres will release the lock after some time, making the job available for other workers.