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

121–130 of 362 posts

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

#121

Post by Matheus28 »

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…

If you REALLY have to use all these different formats, I'd have one canonical one used everywhere in your app, and 2n methods to convert to different ones at api boundaries.

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

#122

Post by m45t3r »

eyelidlessness wrote: post #111
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…

I used Clojure (and ClojureScript) in production for several years, and more or less share your sentiments on this. The only strong objection I have is that the lack of types made even simple data structures an occasional nightmare. Especially when most of the composite types can easily be substituted for many functions, it’s trivial to accidentally recurse a string or a keyword where a data structure should be. And…

I didn't say anything about types, but we use plumatic/schema as a "type system". It is not ideal (for once, it is checked at runtime instead of build time, so we only check types during tests and requests, otherwise the impact would be too great). It is not ideal, but it works and keeps our sanity.

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

#123

Post by cjohnson318 »

Matheus28 wrote: post #121
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…

If you REALLY have to use all these different formats, I'd have one canonical one used everywhere in your app, and 2n methods to convert to different ones at api boundaries.

Ah! Thank you, that is a very good middle road.

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

#124

Post by carapace »

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…

I like this talk: "Domain Modeling Made Functional" by Scott Wlaschin https://www.youtube.com/watch?v=Up7LcbGZFuo He's working in F# but the concepts map.

There's a fascinating book "Data Model Patterns: A Metadata Map" by David C. Hay that's pretty much a Pattern Language or catalog for data models. You can just implement the subset of Hay's patterns that make sense for your application.

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

#125

Post by unityByFreedom »

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.

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

#126

Post by chj »

bob1029 wrote: post #104
chj wrote: post #54

Earlier quoted context omitted.

I have trouble understanding this kind of talk. What's a problem domain, what's its dimension and normalization, and what's the high order logic all about? Can we use plain words people from our grandfather generation can recognize?

Problem domain = Shopping, Banking, Coffee Shop, Factory, Airplane Dimension = Customers, Accounts, Users, Widgets, Inventory Higher-Order Logic = combining basic functional building blocks in order to compose more complex functionality. SQL enables direct, declarative access to the whole space of higher-order functions. E.g. You want the list of widgets made 3 quarters ago but scoped to one factory line, and only wh…

Thanks. That is clear.

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

#127

Post by trylist »

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…

This sounds like a graph problem similar to the google unit conversion problem (https://alexgolec.dev/ratio-finder/). You could probably do a data driven solution, but the gist is convert to and from one normalized form. Then it's n*2 functions.

This is probably what you're implicitly doing with the class solution you're talking about.

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

#128

Post by hutzlibu »

pineconewarrior wrote: post #106
nx7487 wrote: post #50

Earlier quoted context omitted.

> In my experience, code with too many functions is more difficult to grok than spaghetti code. In a way, it kind of _is_ spaghetti code. Even if there's no back references, it turns a single train of thought into a string of entrances and exits.

It's easy to say ugh, but we juniors are more than willing to learn "the right way". This is the hardest part for me. I get anxiety about it and it slows me down. How do I apply this to taking over someone else's 4 year old Magento project? We're out here doing our best, and sometimes our learning environments are in that context.

"the right way"

I would say, don't stress about it too much. There is no perfect way. Everyone makes misstakes. And about when to make abstractions and when not, is mostly about experience. There are modules worth optimizing and abstracting. And others are not. You definitely will make wrong decisions about it and later found out, this optimisation was a waste of time, or that quick and dirty approach really cost you much later on, we all did that and still do.

Much worse than making a wrong (design) decision is making no decision at all - because mostly you have to decide for something and then just go with it. Overthinking things seldom helps. What helps me sometimes is, putting a special hard problem to the side if I am stuck and solve something easier first. Then after some time, when I get back to it, things are much more clear.

But I also wasted too much time thinking about the right approach in a neverending, neverprogressing loop to achieve perfection.

Now my question is not, is it perfect or shiny, but: Is it good enough?

What matters is, that shit gets done in a way that works.

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

#129

Post by plasticchris »

eyelidlessness wrote: post #103
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…

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?

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

#130

Post by eyelidlessness »

m45t3r wrote: post #122
eyelidlessness wrote: post #111

Earlier quoted context omitted.

I used Clojure (and ClojureScript) in production for several years, and more or less share your sentiments on this. The only strong objection I have is that the lack of types made even simple data structures an occasional nightmare. Especially when most of the composite types can easily be substituted for many functions, it’s trivial to accidentally recurse a string or a keyword where a data structure should be. And…

I didn't say anything about types, but we use plumatic/schema as a "type system". It is not ideal (for once, it is checked at runtime instead of build time, so we only check types during tests and requests, otherwise the impact would be too great). It is not ideal, but it works and keeps our sanity.

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