Fighting Complexity in Software Development

> This is only really the case where the prototype was fundamentally solving the right problem in the right way to begin with and the subsequent changes are incremental in nature. If the design of, say, a microcomponent is flawed from the outset or it did the wrong thing and you have to re-do it, those "stiff" tools slow you down.

This. So, so, so, so much this.

I absolutely agree that getting the contours of the tool right (nice analogy there) is (one of) the hardest parts. The main issue I find when using strict, type-driven FP langs for "first draft" style implementations is that I waste time with the unavoidable ceremony that most of these languages require, when what I really want to be doing is probing around to discover the rough edges. The "my last name is Curry" style of FP almost requires you to declare these edges up front as you code.

I actually find that TDD is even more useful in FP contexts than in procedural - mainly because a) it's a good way to help think about the shape of the tool before building it, and b) the FP implementations are often more mentally complex with recursion, pattern matching, and other such things that (IMO) require more brainpower to grok than simple procedures, and to be honest I just find myself needing the tests so I don't go mad trying to be a human compiler. I think even the most staunch TDD fanatics wouldn't try to argue that it's a fast way to prototype.

These days I find myself reaching for dynamic languages with gradual typing for prototypes that might hit production (JS+TS, Python, even PHP). When I'm satisfied with the general shape, I'll add a few type hints here and there to make my IDE friendlier. After a while, usually at the point where there are large additions to requirements, I'll find myself rewriting at least a chunk of the original in a completely different manner, usually in a more type-driven manner, usually with a more FP slant, and often in a different language with more strictness.

I would like to see more mainstream languages support both type-driven FP and simple procedural code without using Haskell-inspired syntaxes or turning into the incomprehensible mess that is Scala. Java is slowly morphing that way, but it still lacks some of the FP fundamentals for when you do want to go full-zealot.

> For which purposes if not software development exactly?

Well, if you recognize only 1 category "software development", I can't help you. C was designed for software development as well, but you wouldn't chose it to do web development, I hope? It's a good tool when you need to develop something small and resource efficient. OOP fits good when you don't have much of concurrency, but you manage complex states in memory (which you do with help of objects and inheritance). And functional programming fits well when you need to manage data flow applications.

And truth is in a big complex system you need a decent support of both FP and OOP. Point is that languages like C# decently support only OOP.

> Your starting to build your own validation library inside that validation context.

I'm building a simple composite data structure, outside of NPM this is not remotely a library. With a bit of luck not even that, I'm a bit rusty but I think the MVC framework had one built in to handle this.

> Next problem

I already addressed it, a lambda function instead of a string that can extract the property name, but your right that nameof might be a better option these days.

> The class is getting a lot responsibility, and you want to seperate validation out into its own class responsible for that. Maybe extract to a validation object which operates on a request/command class?

I already have, the actual validation is in a static method somewhere, so it has only one responsibility and the validation context is mostly a simple data structure, that's not too much responsibility.

> Might point is you eventually you end up building something like fluent validation. With own set of default rules, validation classes etc. Maybe fluent validation is overly complicated but I'd rather get the speed boost of using a well tested library that I already know instead of gradually refactoring into something custom.

It's not an unbounded problem with lot's of gotchas down the line, it's a well known and simple to solve problem that practically everyone has seen before. What you're ignoring is the complexity of adding a dependency in general and the complexity of this library in particular. Adding a dependency is not a free lunch, it has a cost in time, mental overhead and maintenance. This particular dependency increases the complexity of your code and delivers practically nothing. As for the speed boost, assuming it's true does not mean it reduces complexity, faster (initial) dev time very often comes at the cost of creating more complexity.

Some people really don't get programming while others do.

When I studied at university many years ago, my course had a reputation for being tough. Before the course started properly, there was a three week intensive Java course with an exam at the end. They suggested that if you didn't pass the exam, then it probably wasn't the subject for you. A couple of people failed that exam and continued with the rest of the year long course anyway. Those people did struggle and I don't think any of them passed.