41–50 of 362 posts
> Writing a 100% functional system ("going vegan", if you will) Sometimes an analogy is funny but that doesn't make it less wrong...
(Which is that you can get the most benefit from mainly adhering to a principle, while full adherence has intense costs)
I like the sentiment of this article. It's a great analogy. Might be a little off topic, but it reminds me how I am happy that the Go programming language and its philosophies gained popularity even though I don't use the language regularly. Watching Go talks made me appreciate simplicity and clarity. It made me accept that I don't always need to use every design pattern in the book. It made me think about the reader…
It's hard to stay simple when the number of users grow. Go will probably not stay simple for much longer (with generics and whatnot). One thing that I don't understand about the ecosystem is the hate towards GOPATH. Why introduce a complex dependency system for a package manager when you can just pin submodules with git and reap the same benefits? :)
this post seems like a graphically appealing way of just making the usual "FP is better" argument, except without any other actual argument other than "In my experience most codebases have a pure functional subset, and I believe writing that subset in a pure-functional style is nearly always a win for the long-term health of the project." in my experience I've seen codebases that are entirely object oriented where we…
> this post seems like a graphically appealing way of just making the usual "FP is better" argument I would rephrase it as "FP is a better default". A big part of my thesis is that dogmas tend to have shortcomings, which contrasts with the stereotypical "FP is better" literature. > in my experience I've seen codebases that are entirely object oriented where we are writing methods, not functions, or codebases that use…
I like the sentiment of this article. It's a great analogy. Might be a little off topic, but it reminds me how I am happy that the Go programming language and its philosophies gained popularity even though I don't use the language regularly. Watching Go talks made me appreciate simplicity and clarity. It made me accept that I don't always need to use every design pattern in the book. It made me think about the reader…
As I get older my code gets a little more verbose and a little less idiomatic to the language I am writing. I’ve been writing code, starting with C, since 95. Mostly Python these days, but I try to make it clear and easy read. Mostly for myself. Future me is always happy when I take the time to comment my overarching goals for a piece of code and make it clean and well composed with enough, but not too many, function…
In my experience, code with too many functions is more difficult to grok than spaghetti code. It's like trying to read a book with each sentence reference a different page. So, I try to code like I would write, in digestible chunks.
> As I get older my code gets a little more verbose
I've seen too many of my previous projects die right when I moved on. Now I tend to write code as if it were written by a beginner: verbose and boring, with no magic.
Earlier quoted context omitted.
> this post seems like a graphically appealing way of just making the usual "FP is better" argument I would rephrase it as "FP is a better default". A big part of my thesis is that dogmas tend to have shortcomings, which contrasts with the stereotypical "FP is better" literature. > in my experience I've seen codebases that are entirely object oriented where we are writing methods, not functions, or codebases that use…
Monads are mainly hard to grasp because Monad is a terrible name and all explanations overly convoluted
I like the sentiment of this article. It's a great analogy. Might be a little off topic, but it reminds me how I am happy that the Go programming language and its philosophies gained popularity even though I don't use the language regularly. Watching Go talks made me appreciate simplicity and clarity. It made me accept that I don't always need to use every design pattern in the book. It made me think about the reader…
It's hard to stay simple when the number of users grow. Go will probably not stay simple for much longer (with generics and whatnot). One thing that I don't understand about the ecosystem is the hate towards GOPATH. Why introduce a complex dependency system for a package manager when you can just pin submodules with git and reap the same benefits? :)
In simpler terms, the people who designed the language don't use GOPATH at all. That's why it's terrible.
The decoupling provides greater resiliency to change and thus doesn't add geometrically to the complexity of the code base, rather just linearly.
Let's go full FP and demand immutable data too.
I think there's going to be many different Venn diagrams of combining OOP and FP. Someone should identify and name them. Immutable data is hard in languages that don't support it unless you're happy with a 80/20 solution.
I don't get upset by a local var i in a while loop, although I often don't see the point.
The problem is the dark mutable data. All those objects being passed around, are they just being read?, are they being modified by this method call?
So if mutable data is used responsibly, it's not a problem. But there's no guarantee that it's used responsibly. Unless all data is immutable. Then it's guaranteed
Earlier quoted context omitted.
As I get older my code gets a little more verbose and a little less idiomatic to the language I am writing. I’ve been writing code, starting with C, since 95. Mostly Python these days, but I try to make it clear and easy read. Mostly for myself. Future me is always happy when I take the time to comment my overarching goals for a piece of code and make it clean and well composed with enough, but not too many, function…
> well composed with enough, but too many, functions. In my experience, code with too many functions is more difficult to grok than spaghetti code. It's like trying to read a book with each sentence reference a different page. So, I try to code like I would write, in digestible chunks. > As I get older my code gets a little more verbose I've seen too many of my previous projects die right when I moved on. Now I tend…
In a way, it kind of _is_ spaghetti code. Even if there's no back references, it turns a single train of thought into a string of entrances and exits.