Awesome content, been following you for a while now and love seeing a new video released. Been enjoying learning Haskell for well over a year and a half now and just wanted to say your channel has been great :)

You don't need values if you have types!

14:20 but Rust unfortunately also suffers from the ZeroVer problem you mentioned with Haskell, it's pretty bad still

As explained in this video, I have trouble accepting the first value in a professional setting. I am very curious but keep it primarily for my personal projects and learning time. In a professional setting, there will be time to learn and experiment, yet this time is limited, and therefore, promoting experiments to a production environment must be controlled. Many old projects I work with have been organized (seemingly) without much thought or love for the project and the language because there was no structure, consistency, or conventions, making it a misery to understand, maintain, and extend. This is really where experience comes in handy. If you have seen enough bad habits, you may gravitate to establishing some standards; if you are curious, you will be flexible enough to allow for future modifications and corrections.

@majorhumbert676

8 ай бұрын

What about robustness though? Many programmers aren't curious, so they will never discover functional programming. Hence they will spend the rest of their careers catching errors and other unproductive nonsense that hurt the company's finances.

@juantorres9636

8 ай бұрын

​@@majorhumbert676, what about robustness? how do you define it? Robust code can be achieved in functional, imperative, declarative, or any other paradigm out there. It is all a matter of how you do it. Experimenting and learning are fun and important to keep devs engaged, but writing good code that is easy to understand and extend in order to add value to your work is just as important, if not more depending on your line of work (RND devs will have a ton of leeway). Sure, your code can be very stable and safe if you write it in a pure functional style, but how about maintaining it? or passing it on to another team? or scaling it to it without breaking the bank? At the end of the day, it is all a matter of how you use the different paradigms and patterns that matter. If you are experimenting with many new things and never define best practices and standards for your team, you will end up with a mishmash of code that will be very difficult to maintain. I'm not opposed to experimentation, innovation, or change, but in a professional environment, where, at the end of the day, you need to show results, experiments need to be controlled. The way it is explained in this video makes me feel that experimentation should be the norm.

@user-tx4wj7qk4t

6 ай бұрын

​​@@juantorres9636no it can't. By definition you need the highest level of abstraction you can get away with on anything you can do to be robust. Not just in code but in life Building a building out of toothpicks is like using imperative programs to make software. And maintainability? Oh you mean engineers being expected to actually know CS and be more than code monkeys? The horror. Let's all just write assembly since opcodes can be taught in a day to a trained ape

@juantorres9636

6 ай бұрын

@@user-tx4wj7qk4t I’m not sure where you are coming from or what specifically you are referring to. In my mind, a robust program/service is one that not only works, but one that can easily be extended by the original authors or new ones, can be maintained, or scaled to meet the business demands. Too many layers of abstraction are detrimental and how you abstract code should be controlled and structured IMHO, this is specifically for writing services and not for libraries or tools. For junior engineers that I work and have worked with, I expect them to have a learners mind set, I don’t care if they have a BS/MS in CS or did a coding bootcamp. If they are willing to learn, they will grow, if they are curious they will bring new ideas to the table. BUT once again there needs to be a balance with how much you experiment. Learning is an important part of any tech job, but you also need to be productive. You may have more leeway with a startup in the early stages, but it is not the norm in most industries.

Very nice!

Got this in my recommended and I have no idea what FP is.

@klarkc

11 ай бұрын

Functional programming, is a way to program using referential transparent pure functions (you can replace a function with its implementation keeping the same behavior) this is a kind of a simple test that guarantee your function is not sacrificing these values in the video.

@impurepics

11 ай бұрын

Maybe youtube is trying to tell you something? ;)

@willschryver

11 ай бұрын

@@klarkc I don't understand a word you just said.

@willschryver

11 ай бұрын

@@impurepics Doubt it. It's just an algorithm that doesn't have any thoughts of its own.

4:05 I'm not sure those are the graphs that you intended to use

@impurepics

11 ай бұрын

Yeah, it's silly but intentional (like the anonymous axes). The idea is that maintainability in FP is great, but it takes time to appreciate it.

Perfectionism is deeply problematic - both in my personal experience (been there, done that, had backfires in my face) and looking at the colleagues. "good enough" - yes, please, give me two! "perfect" - thanks no, you'll hang around for a few month max, deliver nothing and get fired... Curiosity - need a very healthy moderation, sometimes bringing a library that does exactly thing X you need now is a blessing, other times it is the worst curse in the long run (until you replace it with the alternative that fits your requirements better)

I am learning haskell for fun and find FP rather inspiring. However the thing that annoys me to no end is the unfriendliness of the code. Everything seems to be written with these one letter names obscure operators (instead of just plain old named functions) and abstarctions to the moon. I think its fun to do as a hobby (it feels like solving puzzles for me) but I would go insane doing it for work. In the end of the day when I am working on a problem I want to think about the problem and nothing but problem and so far I havent been able to get to the level to do that. I think your commentary on rust was spot on - its just a more friendly packaged pain on FP concepts, but perhaps thats not a bad thing

@impurepics

11 ай бұрын

Yeah, you're right; it's easy to get carried away with operators and abstractions and end up with hard-to-read code. However, most of the work-code-bases I worked on were quite mild. It's harder to get away with things like that when you have colleagues. I'm trying to argue that there's usually no purely "bad thing"; it's some trade-off.

@user-tx4wj7qk4t

6 ай бұрын

Most of the operators aren't obscure at all, they're from math. And abstractions by definition are simpler, you just need to know them. You're basically complaining about math and actual engineering not being something you can just do without any knowledge. Mathematicians are as efficient as it gets with expression and "focusing on the problem" And rust isn't fp at all, it's still imperative nonsense and far more complicated than the evergreen abstractions in fp. Concepts like in rust are tied to the structure of the system and thinking like a machine which is specific to the von Neumann system,math isn't going to ever go anywhere on the other hand.