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

151–160 of 362 posts

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

#151

Post by fiddlerwoaroof »

dragonwriter wrote: post #133
eyelidlessness wrote: post #130

Earlier quoted context omitted.

Yeah something like that is essential in a dynamic language. To be honest though I don’t think I could go back to runtime-only type checking and having to write those tests where a compiler tests so much automatically.

> where a compiler tests so much automatically Compilers don't necessarily check anything. Static analysis tools (including static type checkers) check things, and some compilers also include static analysis tools. But static analysis tools are often available beyond whatever a compiler provides.

And, some compilers (sbcl) can do fairly sophisticated static analysis on dynamically typed code.

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

#152

Post by the_af »

AntiImperialis2 wrote: post #62

The closing line of the article: > Use the primitives that are there, when possible. Write what is simple, and natural, and human. I agree with this very much, but most of this article doesn't support this statement. Let's start with the statement it is based on. > Eat food. Not too much. Mostly plants. Michael Pollan is great but the human way is definitely not what Michael Pollan suggests. No human tribe ate that w…

> Similarly, functional programming has a simplicity to it which works great in many applications. When complexity grows, you have to get used to various other patterns and concepts to write real-world applications.

Have you read the seminal paper "Why Functional Programming Matters"? In it, it's argued -- quite successfully -- that FP is all about modularization and managing complexity. That is, that FP (and related techniques) is the way to go precisely in order to both modularize and glue the parts together, i.e. keep the complexity tractable.

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

#153

Post by Ma8ee »

nomel wrote: post #44
bitexploder wrote: post #37

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…

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 shoes” are provided by a standard library.

There seems to be two types of programmers: one that can read a line of code like or theCar.fuel() and trust that you in the current context understand enough of what the call does that you can continue reading on the current level of code. This type of programmers don’t mind abstractions even if a function is called in only one place.

The other type of programmer must immediately dig into the car.fuel code and make sure she understands that functionality before she can continue. And of course then each and every call becomes a misdirection from understanding the code, and of course for them it is better is everything is spelled out on the same level.

I’ve seen quite a bit of code written by the second type of programmers, and if you don’t mind scrolling and don’t mind reading the comment chapter headers (/* here we fuel the car */) instead of all the code itself, it can be reasonably readable. But there’s never comprehensive testing coverage for this kind of code, and there’s usually code for fuelling the car in four different places because programmers 2-4 didn’t have time to read all the old code to see if there was something they could reuse, and just assumed that no one had to fuel the car before since there wasn’t any car.fuel() method.

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

#154

Post by eyelidlessness »

dragonwriter wrote: post #133
eyelidlessness wrote: post #130

Earlier quoted context omitted.

Yeah something like that is essential in a dynamic language. To be honest though I don’t think I could go back to runtime-only type checking and having to write those tests where a compiler tests so much automatically.

> where a compiler tests so much automatically Compilers don't necessarily check anything. Static analysis tools (including static type checkers) check things, and some compilers also include static analysis tools. But static analysis tools are often available beyond whatever a compiler provides.

Yes, you’re right. It’s often but not always the case that type checking and compilation are part of the same tool and flow. Thanks for adding that.

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

#155

Post by Geminidog »

yowlingcat wrote: post #139
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…

> 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? I'm with you here... > The actual solution to the above problem is to use point free combinators as much as possible in your code. You lost me here. Perhaps if you're working in a problem space with high complexity, little ambiguity and hard performance requirements (fai…

I'm more referring to a type of technical debt. Of course if your product manager wants you to refactor your web app into a PS5 video game nothing can save you. I wouldn't call the fact that your code wasn't prepared to be refactored into a PS5 video game "technical debt."

As most software engineers know, there's tons of examples where the main issue was mostly organizational issues preventing the programmer from simply removing/replacing/moving logic to fulfill the main objective. This is the "technical debt" I'm talking about.

In that case if all your logic was combinators (and thus dependency free) then all you need to do is move things around, pull things out and/or put things in like lego blocks.

The main reason why people can't move code around like lego blocks is because most logic contains dependencies or is tied to state. Combinators are never tied to state or anything and thus if all your code was made up of combinators you would have no issues in moving logic around. The problem of organizational technical debt is solved with combinators.

If you take it a step further and use the point free style, you are eliminating state all together further protecting your program from ever being dependent on state.

The logic is pretty sound though most people can't put the benefits of FP into purely logical terms. They only talk about why they like it qualitatively without ever pinpointing why it's truly better for design/organizational issues.

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

#156

Post by bitexploder »

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.

Depends on the language. In general I find the way many unit tests are written to be very brittle. There is a balance here. If the 80 lines are clear and easy to understand they will likely be easy to test also. It’s very situational though. An 80 line function isn’t that bad. Check out the SQLite code base, which is extremely well tested, or the linux kernel. C code tends to push out the line count. Whereas 80 in Python is probably a bit much. Some libraries, especially GUI code tend to take a lot of lines, mostly just handling events and laying things out and there you often see big functions as well.

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

#157

Post by eyelidlessness »

harpiaharpyja wrote: post #145
eyelidlessness wrote: post #131

Earlier quoted context omitted.

That’s not what I took from it, but even if that’s what was meant, I think I’d have the same reaction. In terms of abstraction implementations, a class is just a different expression of the same idea of encapsulation.

Given the context of the posts that it was replying to, my impression was that they meant the "rule of three" applied to an entire abstraction layer.

I still don’t think I’d react differently. A function is an abstraction layer. Maybe this is just me being unintentionally obtuse because I’ve worked so long in environments where functions or collections/modules of functions are the primary organizing principle, but when I encounter “premature abstraction” arguments I don’t generally understand them to mean “sure take those three repetitions of the same logic and write a function, but think really hard about writing a module/namespace/package/class/etc”. Am I misunderstanding this?

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

#158

Post by unityByFreedom »

Geminidog wrote: post #149
shakow wrote: post #137

Earlier quoted context omitted.

IME, the limitations of this recommendation appear when one needs to combine multiple functions taking multiple arguments, some being fixe and some other not. Although they are mostly syntactic, they hamper the readability of the resulting code.

I agree with you. Readability is definitely worse when using this method. It doesn't mean it can't be circumvented with good naming. Overall though this method basically solves the problem with technical debt I described above. The root of all dependencies come from free variables. So if you get rid of free variables and turn your functions into combinators, then all your logic is modular. If you get rid of all varia…

> this means don't even use pure functions in classes. Just use functions.

... so you agree with the author of this post?

Also, seems like there is tech debt with point free, you just have it up front rather than putting it off until later.

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

#159

Post by flukus »

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…

One of the best products I've had to maintain recently was a cgi app with very few abstractions, many of the pages in the app didn't even have functions, just construct sql, read it and spit out html. If someone had a problem all the code was right there in a single file and the error could be found patched and deployed in minutes.

Over the years there were a couple of attempts at replacing this legacy system with a "well-architected" .net one but all the architecture made things harder to maintain and it only ever got to a fraction of the functionality. When there was a bug in those ones we had to not only find it but we had to go through every other bit of calling code to ensure there were no unwanted side effects because everything was tied together. Often the bug was in some complicated dependency because spitting out html or connecting to a database wasn't enterprisy enough. Deployment was complicated enough it had to be done overnight because the .net world has a fetish for physically separating tiers even though it makes many things less scalable.

90% of the corporate/enterprise code I've seen would be much better off being more like that cgi app.

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

#160

Post by x0054 »

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…

Not sure why you are down voted, I completely agree.
Post reply on HN