Write code. Not too much. Mostly functions. • Hacker News Board

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

#251

Post by Geminidog » Tue, Dec 22, 2020, 9:01 AM UTC

kubanczyk wrote: post #250

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.

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.

Of course it’s possible. Just look at the type signature of each function to know what goes in and what comes out. Not much different then looking at the type signature of an assigned variable.

Debugging the point free style is different though as there are no points to put your breakpoint. Think of the identity function with a side effect as a replacement for print or breakpoints.

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

#252

Post by KronisLV » Tue, Dec 22, 2020, 9:12 AM UTC

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…

I recently ran into the very same thing.

Instead of creating a Spring service to call a repository for data retrieval, i instead called the repository directly, because there was just a single method that needed to be implemented for read-only access of some data.

And yet, a colleague said that there should "always" be a service, for consistency with the existing codebase (~1.5M SLoC project). Seeing as the project is about 5 years old, i didn't entirely agree. Even linked the rule of threes, but the coworker remained adamant that consistency trumps everything.

I'm not sure, maybe they have a good point? However, jumping through extra hoops just because the software is a large enterprise mess doesn't seem that comfortable either, just because someone decided to do things a particular way 5 years ago. It feels like it'd be easier to just switch projects than try to "solve" "issues" like that (both in quotes, given that there is no absolute truth).

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

#253

Post by kubanczyk » Tue, Dec 22, 2020, 9:15 AM UTC

felixyz wrote: post #238

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.

This talk is an excellent, very accessible introduction to point free style and some of its tradeoffs: "Point-Free or Die: Tacit Programming in Haskell and Beyond" by Amar Shah https://www.youtube.com/watch?v=seVSlKazsNk

The title is a bit clickbaity, the "or Die" is not really addressed in the actual talk. But the hilarity...

I would rename that video to "Tacit Programming: It's Not A Joke "

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

#254

Post by Geminidog » Tue, Dec 22, 2020, 9:29 AM UTC

jayd16 wrote: post #247

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…

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…

I am not talking about leaky code. I am talking about code that is not modular.

Rest assured, I know you’re talking about a perceived isomorphism between a function with a struct as a parameter and the same struct with a method. There are some flaws with this direction of thought.

It is the usage of implicit ‘this’ that breaks modularity. When a method is used outside of a class the ‘this’ is no longer implicit thereby preventing the method from ever being moved outside of the context of the class. This breaks modularity. Python does not suffer from this issue.

Couple this with mutation. Often methods rely on temporal phenomena (aka mutations) to work, meaning that a method cannot be used until after a constructor or setter has been called. This ties the method to the constructor or setter rendering the method less modular as the method cannot be moved or used anywhere without moving or using the constructor with it.

My claim is that combinators can be reorganized without dragging context around thereby eliminAting technical debt related to organization and repurposing and reusing logic.

Note that when I say combinator, I am not referring to a pure function.

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

#255

Post by chriswarbo » Tue, Dec 22, 2020, 9:35 AM UTC

momokoko wrote: post #69

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…

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

> 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 number 1 by far reason I’ve seen code based be very difficult to maintain.

This is always tempting. A good argument against it is to realise that future developers (us included!) will know their requirements far better than we can guess them; if code needs writing, they should do it (as an extra bonus, we don't waste effort on things which aren't needed). The best way to help them is to avoid introducing unnecessary restrictions.

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

#256

Post by paganel » Tue, Dec 22, 2020, 9:39 AM UTC

eyelidlessness wrote: post #110

zamalek wrote: post #70

Earlier quoted context omitted.

> Mostly Python these days, but I try to make it clear and easy read. Which is why I enjoy languages that let me do this without getting too hung up on performance. It's curious that you bring up Python, because idiomatic Python (especially where math libs are concerned) seems to vastly favor brevity/one-liners over all else. It's nice to hear that a veteran is favoring clarity.

> idiomatic Python (especially where math libs are concerned) seems to vastly favor brevity/one-liners over all else I can’t speak to math libs, but in my experience with server-side development, Python devs tend to (often even religiously) cite PEP style guides favoring explicitness and verbosity. I think there may have been a shift as Python got a lot of uptake in scientific and ML communities, and I hope that hasn…

> cite PEP style guides favoring explicitness and verbosity.

Explicit is better than implicit, always has been, always will be. Granted, I've been writing backend/server-side Python code for 15 years now, so that might be one of the reasons.

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

#257

Post by rightbyte » Tue, Dec 22, 2020, 9:41 AM UTC

Geminidog wrote: post #196

craftinator wrote: post #191

Earlier quoted context omitted.

The rule of 3 is catchy like you say, which means programmers will have a better chance of remembering when it's needed.

But a catchy name serves only to be catchy it doesn't serve as justification for the rule actually being correct.

Ye I don't like these way too specific rule of thumbs either. It is superstition that is invoked during code reviews to not having to explain or justify your arbitrary nagging on the reviewing side or defending a bad layout on the other.

Stuff should be analyzed in its context.

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

#258

Post by watwut » Tue, Dec 22, 2020, 9:58 AM UTC

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 agree. This whole discussion prefering long functions seems like advocacy for bad code to me.

It is just ... I have seen both types of code and if written by someone else, coffee that at least attempt to segment things into chunks that clearly don't influence each other (functions with local variablea) is massively easier to read.

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

#259

Post by m_mueller » Tue, Dec 22, 2020, 10:02 AM UTC

plasticchris wrote: post #129

eyelidlessness wrote: post #103

Earlier quoted context omitted.

I’m curious why three call sites isn’t sufficient. Any time I find I have three instances of the same non-trivial logic, I immediately think of whether there’s a sensible function boundary around it, and whether I can name it. If I can, it’s a good candidate. Obviously for trivial logic that’s less appealing. And obviously all the usual abstraction caveats (too many options or parameters are a bad sign, etc) apply. T…

Abstraction here likely means more than a function - maybe something like an interface base class?

A function is an abstraction as well. In case of a function, a 'client' of the function is the call.

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

#260

Post by jahaja » Tue, Dec 22, 2020, 10:04 AM UTC

wirrbel wrote: post #195

https://lucumr.pocoo.org/2013/2/13/moar-classes/

Would be curious to know if he has changed his view since then.

Also I think that the source code of his projects in Python pretty much validates the point of writing simple code. He has made great user-facing APIs (flask) but as soon you dive into the code base itself it's imo a rather dense and hairy mess of abstractions.