5 ms·
I like to build this way when possible. Unfortunately, I find many people - especially tech leads - resistant to this approach. The first and most common reas
by michaelteter 4y ago
I like to build this way when possible. Unfortunately, I find many people - especially tech leads - resistant to this approach. The first and most common reason is, "Why do I need this? What we are doing is fine." Or when the attitude is positive about it, the common issue is, "I think this would be too difficult for our devs to adopt."
I find both of these scenarios disappointing and frustrating, because technology (and software) is usually about improving processes and systems so better results can be made more easily. But at this point it feels like a lost cause, or rather a hill not worth dying on. For my own projects, I go this path; for others, I work dumber and keep the corporate apple cart upright.
Rant aside, there is a video which I really like that demonstrates this functional core/imperative shell approach: Solving Problems the Clojure Way - Rafal Dittwald. It is a Clojure talk, but it gives an imperative to functional refactor demo in JavaScript in the middle of the talk. Even though it is a toy example, it is big enough that the result shows a meaningful difference in approach.
https://youtu.be/vK1DazRK_a0 https://youtu.be/vK1DazRK_a0
- epolanski 4y agoI think that most people, including leads, they do see the benefits, but they think the cons heavily outweighting the pros. Without having a certain number of key developers pushing the transition it's hard to make this jump. I would also say that this kind of transition can be had progressively, I myself know a person who pushed a company into a fully-typed static pure functional programming a team that started their whole business in php. Gradually moved them into typed functional php and then into Haskell. He was lucky enough that the team/company was small enough for that at a bigger scale this would've been much more difficult. In other places I've seen the transition happen (into the functional typescript ecosystem which is a sweet spot imho) it has been mostly the CTO pushing for it.
- danuker 4y agoHow do you gradually move the software of a small company to Haskell? Do you have to build two artifacts, one in PHP and one in Haskell? Two deployment mechanisms?
- epolanski 4y agoI don't know the specific details of how the transition went exactly, I didn't work there. I know they moved into a more functional php, then typed php, then started rewriting some parts of the system to Haskell. The company got eventually bought up by a competitor and killed. Few companies I know here in Italy are going through a similar into more functional and statically typed php with efforts such as facile.it with libraries like that: https://github.com/facile-it/php-codec https://github.com/facile-it/php-codec' Most go through the fp-ts/effect-ts ecosystems and never jump on the scala/haskell languages as they find functional typescript to be the sweet spot for them.
- deleted 4y ago[deleted]
- fulafel 4y agoAre these heard con arguments about greenfield development or refactoring proposals?
- michaelteter 4y agoOn greenfield it's worse, because it means from the beginning you have a whole different approach. On refactoring it's a bit easier, especially since if you choose the right scenario (big new feature), you can just do it that way and then try to teach by example. It's less scary that way, even though there still is initial resistance. Also I think it's better this way, because when you write the tests for the new feature, you can show them side by side with other tests in the codebase. The simplicity of the new tests, and the fewer lines of code but higher coverage, helps sell the deal.