God I remember having to deal with F# when I was an intern, what a nightmare. It's like the worst parts of Java and C# smashed into one esoteric language.
The Untouched Goldmine of F#
41–50 of 58 posts
Re: The Untouched Goldmine of F#
#42> only Odin, F#, OCaml and Zig have [Tagged Unions or Discriminated Unions] The good old missing sum type story. Don't Rust, Haskell, Elm, Kotlin (with sealed classes), etc also have them?
Most languages have them, or allow them to be expressed. The name "Tagged Unions" literally comes from C.
Did it? Didn't Pascal have tagged unions?
Re: The Untouched Goldmine of F#
#43Earlier quoted context omitted.
Most languages have them, or allow them to be expressed. The name "Tagged Unions" literally comes from C.
Did it? Didn't Pascal have tagged unions?
I looked it up and apparently it actually comes from Algol, but I digress. Point being sum types and their equivalents are found all over the place. I wouldn't be surprised to find out modern prologs have them.
Re: The Untouched Goldmine of F#
#44> The question is: Why companies moved from monolithic to microservices? What do they try to avoid? One of the main reasons why companies move from monoliths to microservices is to promote ownership and accountability in large codebases. In a monolith where everyone owns the code, developers can break each other's code. With microservices, each team becomes responsible for one part, and (as long as they keep their SL…
Yet some companies use monorepos, so everybody has access to everything.
Re: The Untouched Goldmine of F#
#45Re: The Untouched Goldmine of F#
#46> The question is: Why companies moved from monolithic to microservices? What do they try to avoid? One of the main reasons why companies move from monoliths to microservices is to promote ownership and accountability in large codebases. In a monolith where everyone owns the code, developers can break each other's code. With microservices, each team becomes responsible for one part, and (as long as they keep their SL…
> With microservices, each team becomes responsible for one part, and (as long as they keep their SLAs) they can't break each other's code.
Well, they still can and do break someone else's code. It is just breaking someones code with more steps in between. And who is at fault isn't necessarily as clear cut.
Re: The Untouched Goldmine of F#
#47Earlier quoted context omitted.
No you dont. Sorry for the blunt answer. ORMs are a bad idea, even when using OO langs: they make the simple queries slightly simpler (`Users.getById(id: Long)`), they do not help you for hard queries (ORM-using codebases of size usually have hard-SQL-queries "in strings"). Most users of FP langs know this and hence will not even try to implement ORMs. Look into jOOQ, LINQ-method-syntax (or whatever it is called, wit…
Most of the time we do simple CRUD operations, I want this plumbing to be as straight forward as possible. Don't be patronising...
I am always confused by this wish. If the operations are simple, why the need for ORM?
Re: The Untouched Goldmine of F#
#48Is TST essentially the validation monad[0]? Glad to see more folks finding and appreciating FP languages like F#. It's good stuff. Scott Wlachin has a great site to discover more F# goodness[1]. [0]: https://hackage.haskell.org/package/monad-validate-1.3.0.0/d... [1]: https://fsharpforfunandprofit.com/
It seems a step on the path to learning both the Either Monad and the Validation Monad, especially for someone coming from golang which desperately needs a proper Either Monad and essentially has baked in the worst of both imperative and FP worlds in the way everything returns as if there were an Either Monad but not enough useful combinators nor a semblance of do-notation/Computation Expressions exist.
Which is fun to see, really, because it is interesting watching someone rediscover FP principles from first practice.
Re: The Untouched Goldmine of F#
#49F# secret superpower that no one has discovered for 30 years, and it will change its popularity in enterprise software.
I must say this take seems a bit... grandiose... to me.
People have been banging on with type systems and similarly "better" capabilities for at least 2 decades [0] and Enterprise continues with a stark preference for language "practicality" and low barrier of entry.
IMO it's because it's best to keep engineers superficially interchangeable rather than having a highly stable system (perhaps stable over spec) and a costly workforce with lots of negotiation leverage. But I digress.
Re: The Untouched Goldmine of F#
#50So… if I ever decide I want to change the call stack of a lower level function… I’m going to break types that all my callers and callers’ callers and callers’ callers’ callers’ are depending on? Like, my call stack is enshrined in a type so that to change it means a refactor all the way up to main()?
Ultimate job security. Write the code that no one will ever dare to touch. And you pass on your job security to those few brave souls who do.