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

201–210 of 362 posts

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

#201

Post by Geminidog »

AnimalMuppet wrote: post #199
Geminidog wrote: post #189

Earlier quoted context omitted.

Many aspects of a programming language can make it nasty or hard to use under certain contexts. This is something most programmers are aware of through experience. My point is, that the use of combinators and point free programming formally eliminates organizational technical debt. So for this specific issue, Joy should indeed be better by logic.

> My point is, that the use of combinators and point free programming formally eliminates organizational technical debt. Hardly. It may eliminate certain kinds of technical debt. Pretty sure it won't eliminate all of it. As you said in a parallel post: > Readability is definitely worse when using this method. Well, that's a kind of technical debt.

Read my post: I said "organizational technical debt" to specify debt that has to do with how you organized your logic.

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

#202

Post by dathinab »

tomrod wrote: post #19
bob1029 wrote: post #11

I would say functions are important, but absolutely pale in comparison to modeling[1]. If you are unable to describe, on paper, what your problem domain actually is , then you have no business opening up an IDE and typing out a single line of code. I will take that further. If, with your domain model, you are unable to craft a query that projects a needed fact from an instance of the model, the you should probably st…

What if code is needed to explore the problem domain? There is utility in discovery, especially for analysts/data scientists who tend to write a surprising amount of code.

It's a incremental process.

You model a certain experimental ("discovery") thing, then you implement it then you analyses the result then you change the model etc.

And sure in many cases in practice people might not skip the modeling but don't properly write it down in any later one usable way. Especially during initial experimental discovery phases. Which isn't good. But understandable and can be fully ok. Honestly especially for boring simple web API's this is pretty common. It's just important to know when to stop ;=)

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

#203

Post by Geminidog »

unityByFreedom wrote: post #197
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…

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.

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

#204

Post by dvlsg »

andreareina wrote: post #66
brundolf wrote: post #45

Earlier quoted context omitted.

I think there are monads that are reasonably intuitive - Promises, Option types, etc (I know promises are ~technically~ not monads). It's mainly the practice of incorporating state into a stateless language and all the weirdness that entails that's the problem, in my view (so, specifically the IO monad)

> (I know promises are ~technically~ not monads) Do you mean promises in general, or the concrete implementation in js? I've got it in my head that promises the pattern are monadic, but js stuffs it (e.g. by up by making .then() automatically flatten if the callback also returns a promise)

Yeah that's correct. The built-in implementation of Promise violates some of the interfaces monads need to follow, including that auto flatten. But it's definitely possible to have a monadic promise (or future or whatever).

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

#205

Post by IggleSniggle »

Ma8ee wrote: post #153
nomel wrote: post #44

Earlier quoted context omitted.

> 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…

On the other hand, no abstractions is like reading a book where each and every thing is spelled out in outmost detail. Instead of telling you “I’m fuelling the car”, I’ll tell you: “I’m walking to the entrance hall. I’m picking up the car keys. I’m putting on my shoes. I’m putting on my jacket. I’m unlocking the front door ...”. You see where this is going. And here we already assumed that things like “putting on sho…

I have had the good fortune to have never worked in a codebase with the characteristics you describe. But I have seen some issues with theCar.fuel(), and that’s generally around mutability and crazy side-effects. I think most of these are pragmatically overcome by adoption of functional paradigms and function composition over inheritance or instance methods.

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

#206

Post by Geminidog »

unityByFreedom wrote: post #194
Geminidog wrote: post #164

Earlier quoted context omitted.

Depends on the definition of tech debt. Do you mean structural/organizational or readability? If you mean readability then yes, the point free style does not protect you from that imo. But combinators and the point free style does protect you from structural and organizational issues, which is the type of technical debt I'm referring too.

I meant up front you'd need to write more functions than you would when using functions that allow multiple arguments.

Look up something called currying. It solves the issue. You can still write functions with multiple arguments and then "curry" them into functions of just one argument.

Of course this does not solve the readability issue.

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

#207

Post by numpad0 »

Geminidog wrote: post #117
monocasa wrote: post #86

Earlier quoted context omitted.

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…

Why 3? Rule of three sounds catchy but logically it's just a arbitrary number. Similar to SOLID and KISS, why pick some arbitrary (and also obvious) qualitative features and put it into an acronym and declare it to be core design principles? Did the core design principles just Happen to spell out Solid and Kiss? Did it happen to be Three? Either way, in my opinion, designing an abstraction for 3 clients is actually q…

> designing an abstraction for 3 clients is actually quite complex.

tells how abstract abstraction is(to limited extent)

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

#208

Post by IggleSniggle »

methodsignature wrote: post #85
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/…

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.

Clean Code is still a great read in 2020, but I think you’re right about some of the specific advice about functions.

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

#209

Post by modeless »

jim-jim-jim wrote: post #192
modeless wrote: post #5

Earlier quoted context omitted.

This is my least favorite programming advice. Splitting functions for no reason other than "it's too long" is a bad practice. https://news.ycombinator.com/item?id=25263488

I thought I hated small functions too, til I realized I just hated scrolling. The moment it's off my screen, it's out of my head. Assuming you just need helper functions for f(), compare int f(int x) { return g(h(x)); } int g(int x) { return ... } int h(int x) { return ... } to f = g . h where g = ... h = ... Turns out my language choice was the problem, not over-abstraction. If you can fit it all on one screen, then…

The logical conclusion of this line of thinking is APL or K. Some people swear by it. I admit terseness is appealing for solo coding, and I loathe the bloat of Java etc, but when taken to the extreme terseness starts being a problem for collaboration.

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

#210

Post by abledon »

methodsignature wrote: post #85
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/…

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%
Post reply on HN