Fighting Complexity in Software Development
1–10 of 117 posts
Re: Fighting Complexity in Software Development
#2Domain modelling made functional is fantastic book(What this article is inspired by). Taught me a lot about encoding business logic using functional programming techniques.
Functional programming is basically my goto when there is complicated business logic involved now.
Re: Fighting Complexity in Software Development
#3Perhaps the best way to take this seriously is to ensure developers RTFC (Read The Fucking Code). While that sounds like a given it’s taken for granted that developers actually do that before forming all manners of biased or incomplete assumptions.
Re: Fighting Complexity in Software Development
#4I’m quite happy to be seeing conversations about the benefits of simplicity, boring tech, etc lately.
It’s a breath if fresh air from the sadly too common (IMO) flavor of the month new tech promotion.
Re: Fighting Complexity in Software Development
#5I’m quite happy to be seeing conversations about the benefits of simplicity, boring tech, etc lately. It’s a breath if fresh air from the sadly too common (IMO) flavor of the month new tech promotion.
Sometimes it's hard to disentangle if a conversation is having an upward trending trajectory, or if you just happen to pay attention more to the links that mention some subject you happened to have caught an interest in.
Re: Fighting Complexity in Software Development
#6I love F#, but using F# instead of (type|java)script would add a lot of complexity to my 'full stack'. Let's see I replaced my node.js backend with an F# one, the following issues would arise:
1. I now have two different languages for client and server, and can't share e.g. validation code.
2. Dealing with 2nd class linux support (no REPL)
3. No library that combines the maturity and simplicity of express.js. Yes I am aware of ASP.NET Web API and no I do not think that compares.
So as much as I love pipes and partial application and concise syntax, F# would create an explosion of complexity, not fight it.
EDIT: This also follows the common trend I see of starry eyed functional programmers who - to put it bluntly - don't seem to know what they are criticizing.
Of course some things from here we can do in C#. We can create CardNumber class which will throw ValidationException in there too.
A Result datatype with all the bells and whistles is what, a few hundred lines in C#? I agree that it sucks that there isn't one built in, but if you like them and you're stuck in C#, code one up and forget about the 'issue' ever again.
But that trick with CardAccountInfo can't be done in C# in easy way
That example looks trivially translatable to an abstract class with two concrete sub-classes to me.
EDIT 2:
The F# docs are awful. Struggling to find the API for the Result module. There's a guide on how to use it, but when you look at the core namespace it's missing.
Re: Fighting Complexity in Software Development
#7Perhaps the best way to take this seriously is to ensure developers RTFC (Read The Fucking Code). While that sounds like a given it’s taken for granted that developers actually do that before forming all manners of biased or incomplete assumptions.
That's necessary, but the aim of good software practice should be to make it as easy as possible for the reader of the code to follow and understand it. Including skipping over well named functions which should not nest unintuitive behavior.
Re: Fighting Complexity in Software Development
#8In mature OOP you have ways to write nice models and have good validations.
https://guides.rubyonrails.org/active_record_validations.htm...
I will argue that the complexity of software development is not because of OOP vs Functional. Tooling, documentation, quality of libraries and people are what matter most. Ruby was a massive success is largely attributed to above. We are humans, we can understand and deal with a fixed amount of complexity if I can offload some of it to a framework, library or tool I will have more time to work on my problem.
Every time I try to play with anything Functional I got hit by a bus of undocumented frameworks(Erlang), multiple standard libraries (ocaml), competing half finished implementations (lisp), arcane tooling (scala), no tooling (Haskell) and broken tooling (F# on Linux).
Re: Fighting Complexity in Software Development
#9I really love the concepts provided by Domain Driven Design (DDD), regardless if you choose OOP or FP to implement it with.
It's fine if you want to choose C#, and there're better ways of addressing the approaches to validation in OOP than were provided in the examples. Value objects are a nice way to ensure strong immutable types like credit cards can be created and passed around without requiring separate validation classes or wild abstract base classes.
I like exceptions in C# - when I used to code that I'd make a lot of domain/business exceptions that the code would throw anytime there was a violation. Here I think Java is a lot stronger in that you are forced to declare what types of errors can be thrown from a function so you have a chance of handling them. In C#, Typescript, I'm finding myself having to lean on codedoc "@throws" to do the same thing (though not as reliably).
That said, I generally am fine for most exceptions to not be handled and instead bubble up "globally". If it happened because of an API request? Let middleware map it back to a 400 Bad Request with the error body. If it happened because of a message handled? Log it, retry the message until it gets dumped to the DLQ. If it's not a violation, then it may not be an exception in the first place, in which case it can be returned with a compensating action performed.
I really like F#, but I struggled to find the actual benefit of it in this article from a DDD perspective.
Re: Fighting Complexity in Software Development
#10I love F#, but using F# instead of (type|java)script would add a lot of complexity to my 'full stack'. Let's see I replaced my node.js backend with an F# one, the following issues would arise: 1. I now have two different languages for client and server, and can't share e.g. validation code. 2. Dealing with 2nd class linux support (no REPL) 3. No library that combines the maturity and simplicity of express.js. Yes I a…
I really don't think it adds complexity. Sure, it's going to be different, so there's a mental hurdle to clear in learning how a new stack works. That doesn't mean it's going to be more complex.
> 1. I now have two different languages for client and server, and can't share e.g. validation code.
You could use Fable to transpile F# to Javascript, keeping a single language
> 2. Dealing with 2nd class linux support (no REPL)
FSI is available under Linux, but I admit it's got some hairs on it. (FWIW, FSI on Windows needs a lot more TLC too).
> 3. No library that combines the maturity and simplicity of express.js. Yes I am aware of ASP.NET Web API and no I do not think that compares.
This is purely a matter of taste. While express.js is very accessible, I don't think it's any more so than Giraffe (a wrapper around ASP.NET Core).
I'm all-in on F# now - once you're over the (mild) initial learning curve, you see huge dividends from the smaller codebase, static typing, fewer null-checks and drastically less testing required.