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

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

#311

Post by IggleSniggle » Tue, Dec 22, 2020, 3:44 PM UTC

watwut wrote: post #258

Ma8ee wrote: post #153

Earlier quoted context omitted.

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.

I think it’s honestly just folks talking past each other because these situations are isolated judgement calls, and some folks feel that

    // #1, in essence
    result = a => map => reduce => transform

is easier to read and understand, while others feel that

    // #2, in essence
    aThing = a => map
    aggregation = aThing => reduce
    result => aggregation => transform

is easier to read and understand. Folks in camp #1 think camp #2 is creating too much abstraction by naming all the data each step of the way, and camp #2 thinks camp #1 is creating too much abstraction by naming all the functions each step of the way.

Really it’s just these two mental modalities butting up against each other, because you will separate your layers in different ways for increased clarity depending on which camp you fall into. What makes things clearer for camp #1 makes things less clear for camp #2, and vice versa.

That’s my suspicion anyway: the premise of the discussion is just a little off.

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

#312

Post by Geminidog » Tue, Dec 22, 2020, 3:48 PM UTC

yowlingcat wrote: post #301

Geminidog wrote: post #155

Earlier quoted context omitted.

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

> 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 problem is that the part of your program which processes state...is generally the useful part. This is part of the reason why I eventually came back down to earth after a couple of years of FP zealotry in my early career. I realized that it makes…

You cannot write a program without state. I am obviously not talking about eliminating all state. I am talking about eliminating state from sections of code that don’t need it. Generally for web development the only required state is caching and the database.I am not saying that you eliminate this.

Additionally shortcuts can be taken. Graph algorithms tend to be easier with mutation.

> But in my experience, that's only table stakes. It doesn't make the hard parts (such as unfucking a broken data model and code + existing prod data which depends on those implicit assumptions) any easier. So it's a tool of limited use for most of the thorny issues I've come across in my career, across startups and BigCos.

Well your talking in terms of fuzzy feelings and experience. I am talking about a hard logical rule. A mathematical rule.

If you want to eliminate all technical debt that originates from organizational issues then where you want that technical debt eliminated you simply need to have all your code be combinators in that location.

This occurs because combinators have no dependencies and therefore can alway be moved shifted decomposed and reused. This is a logical statement different from some random anecdote from experience. Also this isn’t just fp. A combinator is different from a pure function.

Look you can’t eliminate IO and you can’t eliminate state in practice. So the formal logic I stated above cannot effectively be applied to your code to completely eliminate this form of debt.

It is however a logical statement and holds as a truth. Thus if you follow it as much as possible you will see that what ends up happening is a segregation and minimization of state along with a minimization of the form of technical debt I described. (Which of course cannot apply to the stateful part of your program)

Most of web development is a similar pattern that was developed independently from the above philosophy but coincidentally arrived at the same conclusion. Web applications are generally stateless with state segregated away to databases and caches. You will find that generally the technical debt lives in this state more then it lives in the web app, but if you follow the combinator rule, you can eliminate organizational technical debt from a good portion of your web app.

The purpose of this post is to elucidate a logical rule and pinpoint the hard origins of technical debt arising from organizational issues rather then walk around and talk about fuzzy feelings and intuitions that arise from experience. Of course state and io cannot be removed from your program. What this means logically is that organizational technical debt can also never be fully removed, but it can be segregated. Better to understand this concept as a science rather then some fuzzy art that comes from experience.

The industry often repeats history because of lack of formal understanding. It’s very hard to optimize something without formal understanding. You cannot prove one pattern is better than another with just fuzzy experience. Hence the reason why the industry jumps from pattern to pattern in an endless flat circle.

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

#313

Post by wruza » Tue, Dec 22, 2020, 3:49 PM UTC

IggleSniggle wrote: post #308

wruza wrote: post #190

Earlier quoted context omitted.

Still lacking good tools in our own toolbox. If ides could expand function calls inline (not a header in a glassbox, but right in code), both worlds could benefit from that. Expand all calls depth 2 and there is a detailed picture. Collapse branches at edit-time based on passed flags/literals and there is your specific path.

Hmm. There’s a vim sequence to accomplish this that you could macro. But even so, don’t most IDEs give you somewhat more than a glassbox header? I’m almost certain I’ve seen people scrolling and even editing code in the “glassbox” preview pane in VSCode.

Afair, it doesn’t inline and overlaps with the code behind it. If that is not true, it may be closer to it, but my experiments somehow failed to show its benefits over “just open to the right pane”. Maybe I should check its config thoroughly. As a vim user, I’m interested in a method you described, is it handmade :read/%v%yp-like thing or an existing plugin?

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

#314

Post by bob1029 » Tue, Dec 22, 2020, 4:00 PM UTC

FpUser wrote: post #112

bob1029 wrote: post #101

Earlier quoted context omitted.

I think you may underestimate the potential scope of a domain model and the capabilities of SQL. It is certainly math. That is actually the incredible part. That its all just math underneath 20 different joins which express a very complex and meaningful view of the domain facts. I challenge anyone to present a problem domain which cannot be meaningfully represented in terms of tables in a database. I would prefer if…

>"I think you may underestimate the potential scope of a domain model and the capabilities of SQL." I am being practical. There are many languages that are Turing complete but ill suited for particular domain. It's been proven that SQL is Turing complete as well. However should you propose using SQL to write implementation of say FFT you are not likely to find much of a sympathy.

I would not use SQL to implement the actual algorithm, but I would certainly consider using it to hold all of the data around such an operation as required. For instance, tables like Samples, Spectrograms, etc.

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

#315

Post by Geminidog » Tue, Dec 22, 2020, 4:08 PM UTC

amw-zero wrote: post #299

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…

That doesn’t solve any problem that I have (or anyone has) encountered.

You’re completely right. I’m talking about Technical debt arising from organizational flaws and issues and your statement made me realize this concept doesn’t exist. Nobody has ever dealt with this form of technical debt ever in the history of existence.

You’re right, everything I said is completely wrong. I’m not a biased person so I admit when I’m wrong.

Also note that this post is not sarcastic. I am 100% serious and being honest here. You are completely right. This is not a joke. It’s rare for people to do a 180 flip so I can see how this post can come off as sarcasm. I am not most people and this post is earnest.

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

#316

Post by Geminidog » Tue, Dec 22, 2020, 4:11 PM UTC

shakow wrote: post #302

Geminidog wrote: post #206

Earlier quoted context omitted.

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.

The problem with currying is that I don't know of a nice syntax to curry on a random access argument rather than on the first one.

It exists with dummy variables. Ive seen it with C++ bind and many fp libraries in JavaScript as well.

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

#317

Post by Ma8ee » Tue, Dec 22, 2020, 4:14 PM UTC

sethammons wrote: post #291

Ma8ee wrote: post #153

Earlier quoted context omitted.

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…

Then you have an electric car, and you use the fuel method and add a special case for isElectric handling inside. And some other dev uses lamp.fuel since it already handled isElectric internally. But later, we have to differentiate between different types of charging and battery vs constant AC and DC power. Then someone helpfully reorganizes the code and breaks car.fuel because the car does have a battery too. And th…

No, you don’t. And the alternative implementation is that you either go through all code where car is used and add conditionals for all the cases where kind of fuel matters. Or is very common for this kind of programming, just copy the whole car.roadTrip() where fuel is called and to the method electricCar.roadTrip and just change a few lines. Then of course all requirement changes or bug fixes must be done in several places thereafter.

My feelings about people that can’t handle abstractions is that they just don’t have had to create or maintain anything complex. Very few real world systems can be kept in ones mind in full.

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

#318

Post by rualca » Tue, Dec 22, 2020, 4:20 PM UTC

rpedela wrote: post #297

rualca wrote: post #243

Earlier quoted context omitted.

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

In practice, it rarely turns out that way. I have to deal with large, mature Java codebases for some of my work. The good thing is that the code does just about everything well and rarely breaks. The downside is that when something does break, and I have to debug the code. At some point in the Java world, best practice became building abstraction on top of abstraction on top of abstraction. And often these abstractio…

> At some point in the Java world, best practice became building abstraction on top of abstraction on top of abstraction.

It really doesn't. There is nothing intrinsic to Java that forces developers to needlessly add abstractions.

If your codebase has too many unwarranted abstractions to the point it adds a toll to your maintenance, it's up to you to refactor your code into maintainability.

And no, n-tier architectures do not add abstractions. They never do. At most, you add an interface to invert the dependencies between outer and inner layers, which does not create an abstraction. Instead they lift the interface that was always there,and ensures that you don't have to touch your inner layers when you need to fix issues in your outer layers.

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

#319

Post by [deleted] » Tue, Dec 22, 2020, 4:46 PM UTC

rualca wrote: post #318

rpedela wrote: post #297

Earlier quoted context omitted.

In practice, it rarely turns out that way. I have to deal with large, mature Java codebases for some of my work. The good thing is that the code does just about everything well and rarely breaks. The downside is that when something does break, and I have to debug the code. At some point in the Java world, best practice became building abstraction on top of abstraction on top of abstraction. And often these abstractio…

> At some point in the Java world, best practice became building abstraction on top of abstraction on top of abstraction. It really doesn't. There is nothing intrinsic to Java that forces developers to needlessly add abstractions. If your codebase has too many unwarranted abstractions to the point it adds a toll to your maintenance, it's up to you to refactor your code into maintainability. And no, n-tier architectur…

[deleted]

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

#320

Post by carapace » Tue, Dec 22, 2020, 4:47 PM UTC

cjohnson318 wrote: post #116

So, I have a question. I have a kind of serial number, and different systems expect slightly different formats. One system likes dashes, one doesn't, one system likes an extra two digits, while another system likes an extra four numbers. Should I write around n(n-1)/2 pure function converters between n systems? Or one class with n methods? (If you're curious, I'm talking about oil well API numbers. It's not rocket sc…

How big is n and how often does it change?