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

241–250 of 362 posts

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

#241

Post by redisman »

atoav wrote: post #239
redisman wrote: post #150

Earlier quoted context omitted.

I think setting hard limits on design is a good thing. Creativity needs limits. If your limits can imply something about your desired design goals then that’s a good synergy. It also forces the engineers to think more about design rather than fall back on their goto pattern that may or may not fit the problem. Especially junior and mid level engineers might not have good heuristics on is their design any good or is i…

I think a good programmer should have an "intuition" whether it is worth to build an abstraction for something or not. If in doubt don't do it. If in hindsight your intuition fooled you constantly, adjust it.

I agree but it's kind of too vague to have as a company/team-wide policy

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

#242

Post by asalahli »

Geminidog wrote: post #113

I'll take it one step further. Don't just write pure functions. Write point free combinators. Have you guys ever wondered why no matter how much care or planning you use to organize your code when you begin a project, some time down the line you will always encounter a situation where the organizational scheme you chose is less than ideal or even flat out wrong? It's a sort of inevitable technical debt that occurs. T…

Isn't it ironic to complain about the industry coming up with different solutions for the problem, then to suggest the actual solution is X (whatever x is)?

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

#243

Post by rualca »

serial_dev wrote: post #17

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 made me think about the readers of my code (...) I don't always need to have n+1 layers in my architecture where all the layers just call the next layer anyway.

Your assertion doesn't make sense. N-tier architectures are primarily intended by the needs of said reader of the code, because it provides a clear understanding of how the overall code is organized.

More importantly, it provides a clear idea of what code is expected to call which code, and makes it clear that dependencies only go one way.

I have no idea what leads people to believe that ad-hoc solutions improvised on the spot are helpful to the reader instead of clear architectures where all the responsibilities and relationships are lined up clearly from the start.

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

#244

Post by nightcracker »

m45t3r wrote: post #102

> By "functions" here I mean "pure functions". After programming for Clojure for quite a long time (~2 years), I fully share this sentiment. Using pure functions for business logic (and also using simple data structures instead of, say, classes and encapsulation) seems to generally makes the code more simple and maintainable in the long run. > Of course the qualifier is "mostly": this isn't a dogma. Writing a 100% fu…

For years now I've felt the same way about functional v.s. imperative programming, and where functional languages go 'wrong', and what they get right.

There are exceptions of course, but I personally feel that there's three main 'kinds' of code:

    1. functions that define some input/output relation  
    2. query methods on data structures  
    3. modification methods on data structures  
    4. the bodies of the above functions
In a purely functional language all four are purely functional, but this is (IMO) needlessly restrictive. It leads to recursion where iteration is more natural, awkward choices of data structures or even plain impossibility of certain algorithms/data structures (ask a functional programming zealot to implement an O(1) hash map in a pure way—they will usually stammer, try to move goal posts, before finally admitting it's not possible).

Personally I feel that 1 & 2 should be 'pure' and not modify (observable) data and have the same results, but 3 & 4 are perfectly fine if not natural to be imperative and have mutable state.

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

#245

Post by Geminidog »

asalahli wrote: post #242
Geminidog wrote: post #113

I'll take it one step further. Don't just write pure functions. Write point free combinators. Have you guys ever wondered why no matter how much care or planning you use to organize your code when you begin a project, some time down the line you will always encounter a situation where the organizational scheme you chose is less than ideal or even flat out wrong? It's a sort of inevitable technical debt that occurs. T…

Isn't it ironic to complain about the industry coming up with different solutions for the problem, then to suggest the actual solution is X (whatever x is)?

Well that would be assuming I’m from the industry. What if I’m currently in some place outside of the industry? What if I have a lot of experience both in industry and outside of the industry? Would it still be ironic?

I think the bigger question is what is X and is it definitively correct? Because the irony of a situation has nothing to do with how correct X is.

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

#246

Post by Geminidog »

unityByFreedom wrote: post #226
Geminidog wrote: post #203

Earlier quoted context omitted.

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.

No, they refer to different things but can intersect. Not all pure functions are combinators. Just look it up. Haskell is purely functional but it also promotes many patterns that are not combinatorial.

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

#247

Post by jayd16 »

Geminidog wrote: post #162
unityByFreedom wrote: post #125

Earlier quoted context omitted.

Can you describe that in simpler terms? I read the wiki and the Python example seems to suggest writing functions that take a single argument.

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…

Classes and methods are just sugar around namespaces, functions with implicit "this" params, and some extra markup around design ownership (ie private members).

You don't gain or lose state with classes alone. Your examples didn't remove any state. X is still there, its just not B.x.

What you're fighting against is side effects and reducing what is in scope at any given time. One could argue that the goal of classes is the same!

Sadly one can write terrible, leaky code in either style.

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

#248

Post by ornornor »

> code only those things that people at a junior level would recognize for what they do

Couldn’t agree more. But my colleagues make a point of keeping cryptic code cryptic because comments explaining context and reasoning are for noobs. I guess it’s a mid level developer fallacy and until they’ve had enough of pulling their own hair out over this kind of code, they won’t change their mind.

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

#249

Post by cjfd »

I agree with the sentiment that things should be made as simple as possible. The sine function really has no reason to be anything besides a function. I am not sure, though, that writing the simplest thing possible results in mostly pure functions. In my experience programming is mostly about managing a state. My programming jobs have generally been about tracking what the state of some other piece of hardware and/or software is. It seems hard to escape state in that case. In my spare time I have lately been writing a compiler like thing. That seems to be, among other things, about maintaining a stack of all the stuff that has been defined/declared previously. If so many things are about maintaining a state, how practical is this 'mostly functions' thing actually?

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

#250

Post by kubanczyk »

unityByFreedom wrote: post #125
Geminidog wrote: post #113

I'll take it one step further. Don't just write pure functions. Write point free combinators. Have you guys ever wondered why no matter how much care or planning you use to organize your code when you begin a project, some time down the line you will always encounter a situation where the organizational scheme you chose is less than ideal or even flat out wrong? It's a sort of inevitable technical debt that occurs. T…

Can you describe that in simpler terms? I read the wiki and the Python example seems to suggest writing functions that take a single argument.

I think the easiest way to explain point-free is this bash snippet:

    grok () {
      grep -v DEBUG | sort -n | uniq | tail
    }
Unlike a generic pure function, it forcibly abstracts away arguments. It's a bunch of other functions combined somehow, but it's impossible to know the type/structure/semantics of the input. And in most cases also of the output! Although it's less visible in my example.
Post reply on HN