Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write code. Not too much. Mostly functions.

brandons.me

Post reply on HN
Print view View original

221–230 of 362 posts

Re: Write code. Not too much. Mostly functions.

#221

Post by varrock »

monocasa wrote: post #86
momokoko wrote: post #69

Earlier quoted context omitted.

>I don't always need to have n+1 layers in my architecture where all the layers just call the next layer anyway. This is by far the most common thing I’ve seen consistently in especially difficult to maintain codebases. Anecdotal for sure, but number 2 on that list is way behind. Extra abstractions for a future that has yet to happen and abstractions because the IDE makes it easy to click through the layers is the nu…

Hard same. The best organizational level technique I've found so far is to add the rule of three to code review checklists. An abstraction requires at least three users. Not three callsites, but three distinct clients with different requirements of the abstraction. Obviously it's not a hard rule, and we allow someone to give a reason why they think that it's still a good idea, but forcing a conversation starting with…

Does this also apply to UI? I think a lot of front end libraries entice developers to fall for those early abstractions.

Re: Write code. Not too much. Mostly functions.

#222

Post by Geminidog »

darksaints wrote: post #213
Geminidog wrote: post #162

Earlier quoted context omitted.

It's pretty simple. x = 1 addSomething(y) = y + x The above is not a combinator. addSomething relies on the line x = 1 and is forever tied to it. You cannot reuse addSoemthing without moving x = 1 with it. Therefore addSomething is not modular. This is the root of organizational technical debt. When logic depends on external factors it cannot be reorganized or moved. This is also a big argument against OOP because OO…

The downside to taking that combinator approach too dogmatically is that passing all state as parameters can get extra unwieldy, because now a simple change in data schema can result in you refactoring every single function call. This dilemma has a name: The Expression Problem. A decent summary can be found here. https://wiki.c2.com/?ExpressionProblem Functional programming is an amazing paradigm for most domains. Ho…

>The downside to taking that combinator approach too dogmatically is that passing all state as parameters can get extra unwieldy, because now a simple change in data schema can result in you refactoring every single function call.

This should happen with methods too. Whether a variable is free or a parameter doesn't change anything.

   x = {b = 1, c = 2}
   f(x) {return x.b}
   g() return x.b
A change in x, say deleting b, will require a refactor for both the combinator and the method.

I'm not saying combinators are the solution to everything. Of course not. I'm saying combinators are the solution to technical debt caused by organizational issues. Of course there are trade offs, I never said otherwise.

Both of the issues above are separate from the expression problem though. Personally I don't think the expression problem is much of a problem. Whether you add a new function or a new shape to either paradigm in the example link you gave, the amount of logical operations you have to add is equal for both cases. The difference is the location of where you put those logical operations. In one case they can be placed closed together, in another case they have to be placed in separate scopes, but the total amount of logical operations written to achieve a certain goal is equal.

For example adding perimeter to either paradigm necessitates the need for you to define the perimeter of every shape no matter what. Neither paradigm actually offers a shortcut when new information is introduced into the system.

Re: Write code. Not too much. Mostly functions.

#223

Post by neolefty »

gfxgirl wrote: post #174

I find it interesting that React ignores this advice about pure functions. From the react docs import React, { useState } from 'react'; function Example() { // Declare a new state variable, which we'll call "count" const [count, setCount] = useState(0); return ( You clicked {count} times setCount(count + 1)}> Click me ); } It's clear "Example" will be called every time it's rendered yet "useState" is NOT "pure". Some…

Correct, `useState` (and `useEffect` and `useContext`) are not pure. They are ways of managing impurities while writing mostly pure functions.

Re: Write code. Not too much. Mostly functions.

#224

Post by tekdude »

abledon wrote: post #210
methodsignature wrote: post #85

Earlier quoted context omitted.

They all probably read Clean Code, the discussion on functions in that book may be the most harmful/costly to programming in the last 20 years.

Is there a good blogpost/writeup on this idea? I've seen it mentioned before in other threads.... And i agree 100%

From John Carmack:

http://number-none.com/blow/blog/programming/2014/09/26/carm...

Re: Write code. Not too much. Mostly functions.

#225

Post by IggleSniggle »

darksaints wrote: post #213
Geminidog wrote: post #162

Earlier quoted context omitted.

It's pretty simple. x = 1 addSomething(y) = y + x The above is not a combinator. addSomething relies on the line x = 1 and is forever tied to it. You cannot reuse addSoemthing without moving x = 1 with it. Therefore addSomething is not modular. This is the root of organizational technical debt. When logic depends on external factors it cannot be reorganized or moved. This is also a big argument against OOP because OO…

The downside to taking that combinator approach too dogmatically is that passing all state as parameters can get extra unwieldy, because now a simple change in data schema can result in you refactoring every single function call. This dilemma has a name: The Expression Problem. A decent summary can be found here. https://wiki.c2.com/?ExpressionProblem Functional programming is an amazing paradigm for most domains. Ho…

Generally the solution that functional programmers arrive at when facing UI / game / simulation, is to have a consistent persistent data structure. Incidentally, this is also basically what SQL is: a functional language for transactionally querying the global state.

Re: Write code. Not too much. Mostly functions.

#226

Post by unityByFreedom »

Geminidog wrote: post #203
unityByFreedom wrote: post #197

Earlier quoted context omitted.

Yeah I'm already on board with modular functions and functional programming in general. I was wondering about the point free thing. I agree that's like going vegan.

functional programming still allows the usage of functions that are not combinators. So I'm referring to that specifically, not functional programming in general. The OP is recommending functional programming I'm taking it a step further.

It sounds like a combinator is roughly the same thing as a pure function. I'm more familiar with the term pure function, and OP does specifically advocate for pure functions.

Re: Write code. Not too much. Mostly functions.

#227

Post by pedro1976 »

sameerds wrote: post #193

I know my request might be off-topic ... the original article is from a blog that does not export an RSS/Atom feed. I am looking for recommendations for a service which can let me scrape a feed by guessing the structure of the articles.

I did exactly that [0]. Check out the live version [1].

[0] https://github.com/damoeb/rss-proxy

[1] https://rssproxy.migor.org/

Re: Write code. Not too much. Mostly functions.

#228

Post by Geminidog »

darksaints wrote: post #213
Geminidog wrote: post #162

Earlier quoted context omitted.

It's pretty simple. x = 1 addSomething(y) = y + x The above is not a combinator. addSomething relies on the line x = 1 and is forever tied to it. You cannot reuse addSoemthing without moving x = 1 with it. Therefore addSomething is not modular. This is the root of organizational technical debt. When logic depends on external factors it cannot be reorganized or moved. This is also a big argument against OOP because OO…

The downside to taking that combinator approach too dogmatically is that passing all state as parameters can get extra unwieldy, because now a simple change in data schema can result in you refactoring every single function call. This dilemma has a name: The Expression Problem. A decent summary can be found here. https://wiki.c2.com/?ExpressionProblem Functional programming is an amazing paradigm for most domains. Ho…

One more thing I should mention. UI programming and game programming are now currently the areas where functional programming techniques are sort of in vogue.

If you want to do FP in your job, becoming a front end developer is your best bet as React + Redux currently follow a paradigm called functional reactive programming (FRP) with react trying to go more and more in the direction of FP and trying to separate out all side effects from pure functions.

A popular pattern in game programming is called ECS, which isn't strictly FP but is similar in the sense that functions are separate from data rather then attached to data as it is in OOP. The game industry is definitely heading in this direction over OOP style techniques. It's actually rather similar to FRP.

Re: Write code. Not too much. Mostly functions.

#229

Post by Lammy »

ZephyrBlu wrote: post #51
earthboundkid wrote: post #33

> Bad programmers worry about the code. Good programmers worry about data structures and their relationships. — Linus Torvalds

I'm not sure what exactly Linus means by this, but I read this as: for good programmers, coding is about managing data structures and their relationships whereas bad programmers are more concerned with just getting the thing to work.

> what exactly Linus means by this

“I’m a good programmer”, I imagine. I wouldn’t disagree :p

Re: Write code. Not too much. Mostly functions.

#230

Post by abledon »

kvothe_ wrote: post #107
abledon wrote: post #68

Earlier quoted context omitted.

> It's like trying to read a book with each sentence reference a different page. Yes!!! I've been trying to teach Juniors that if the function itself has 4 levels of abstraction, even if the names are readableFunctionThatDoesXwithYSideEffect ..... it is harder to understand, Ctrl+clicking downards into each little mini-rabbit -hole. Just keep the function as a 80-liner, not a 20-liner with 4 levels of indirection w/…

I think you may find it difficult to test an 80 liner... There is way too much happening.

its java
Post reply on HN