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

341–350 of 362 posts

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

#341

Post by nickbauman »

m45t3r wrote: post #290
nightcracker wrote: post #244

Earlier quoted context omitted.

For years now I've felt the same way about functional v.s. imperative programming, and where functional languages go 'wrong', and what they get right. There are exceptions of course, but I personally feel that there's three main 'kinds' of code: 1. functions that define some input/output relation 2. query methods on data structures 3. modification methods on data structures 4. the bodies of the above functions In a p…

> In a purely functional language all four are purely functional, but this is (IMO) needlessly restrictive. I concur. My two favorite languages nowadays (Elixir and Clojure) are far from being purely functional. They are functional enough that mutating state is awkward, but if you do need it it is there. I also think having immutable data structures by default is a saner choice IMO. > It leads to recursion where iter…

I often write a loop recur that I will later turn into a map reduce as you say.

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

#342

Post by nickbauman »

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…

Have you considered Clojure Protocols for this?

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

#343

Post by eyelidlessness »

nickbauman wrote: post #342
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…

Have you considered Clojure Protocols for this?

I used them. But they’re still runtime-only.

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

#344

Post by ftcHn »

m45t3r wrote: post #290
nightcracker wrote: post #244

Earlier quoted context omitted.

For years now I've felt the same way about functional v.s. imperative programming, and where functional languages go 'wrong', and what they get right. There are exceptions of course, but I personally feel that there's three main 'kinds' of code: 1. functions that define some input/output relation 2. query methods on data structures 3. modification methods on data structures 4. the bodies of the above functions In a p…

> In a purely functional language all four are purely functional, but this is (IMO) needlessly restrictive. I concur. My two favorite languages nowadays (Elixir and Clojure) are far from being purely functional. They are functional enough that mutating state is awkward, but if you do need it it is there. I also think having immutable data structures by default is a saner choice IMO. > It leads to recursion where iter…

> I rarely use recursion/for loops

Same here. I use c# and Typescript mostly. In c# you can use Select for map, Aggregate for reduce and there's a huge selection of other list processing operations that make use of lambda expressions. In typescript/javascript there map, reduce, etc

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

#345

Post by yowlingcat »

Geminidog wrote: post #312
yowlingcat wrote: post #301

Earlier quoted context omitted.

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

> Look you can’t eliminate IO and you can’t eliminate state in practice

Not only can you not eliminate IO nor state in practice, but it's literally the most important part. The useful things computers do are IO and state. The difference between using pure functions and combinators is the difference between which color of paint you're going to put on your car. The color of paint you put on your car has nothing to do with its drivetrain.

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

#346

Post by shakow »

Geminidog wrote: post #332
shakow wrote: post #327

Earlier quoted context omitted.

But then it's not pointfree, it's just anaonymous variables instead of named.

Yeah technically it's not point free. But technically nothing can truly be point free just like nothing can ever be truly purely functional. In purely functional programming your IO and state has to live somewhere just like how your points in point free programming still have to exist on the function call. A function that takes multiple arguments introduces extra points to your program similar to introducing extra IO…

Don't get me wrong, I rather agree with you on the conceptual side of things; I just wish there was a pretty syntax to do it practically.

As you mention them, pipes, for instance, get close to that, and e.g. Elixir uses them to a great result. However, it requires unambiguous priority of the arguments and cooperation & discipline from the librairies authors, so that piping follow the intuitive (and hopefully unambiguous) understanding of the data flow.

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

#347

Post by hakfoo »

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…

My first programming job was with a firm that never had money for paying developers, let alone tools. It was also a few years before Visual Studio Code was a serious thing. So I used "programmer's editors" -- those cute things like Notepad++ which had syntax highlighting and on some days autocomplete but no real code understanding. There was no middleware, no dependency-injection, and things like the database instance were globals. More or less, the things you needed to know were in a single file or could be inferred from a common-libraries file.

My second job, they splashed the cash for full-scale professional IDEs, and they couldn't get enough abstraction. I suspect the conveninence of "oh, the tools will let us control-click our way to that class buried on the opposite side of the filesystem" made it feasible.

I wonder if there's some sort of "defeatured" mode for IDEs which could remind people of the cognitive cost of these choices.

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

#348

Post by gr__or »

brundolf wrote: post #16
jhardy54 wrote: post #14

That looks familiar: https://news.ycombinator.com/item?id=24920186

Hah, I wrote it in a comment myself a while back :) (I'm the author of the article): https://news.ycombinator.com/item?id=24919615

Phew, I remembered tweeting that comment (https://twitter.com/watware/status/1323610182560161792) and was about to flame this post for lack of attribution. Glad I read on! Good stuff.

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

#349

Post by agallant »

UK-Al05 wrote: post #283
agallant wrote: post #90

Earlier quoted context omitted.

The best label I've heard for the excessive layers anti-pattern is "lasagna code."

Lasagna code isn't meant to be derogatory, just a description.

https://wiki.c2.com/?LasagnaCode https://en.wikipedia.org/wiki/Spaghetti_code#Lasagna_code https://matthiasnoback.nl/2018/02/lasagna-code-too-many-laye... https://dev.to/mortoray/what-is-your-tale-of-lasagne-code-co...

Generally used with a negative connotation. C2 also discusses how the layers can become entangled/stuck with one another and difficult to replace, which seems to fit the metaphor.

For describing layered code in a non-negative fashion, just saying "layered (or "modular") seems most typical.

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

#350

Post by Geminidog »

yowlingcat wrote: post #345
Geminidog wrote: post #312

Earlier quoted context omitted.

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

> Look you can’t eliminate IO and you can’t eliminate state in practice Not only can you not eliminate IO nor state in practice, but it's literally the most important part. The useful things computers do are IO and state. The difference between using pure functions and combinators is the difference between which color of paint you're going to put on your car. The color of paint you put on your car has nothing to do w…

It depends on the application whether or not it’s more important or less important. Chat application vs. neural network. A neural network is mostly compute a chat application is mostly io.

If you work with a framework like nodejs the framework agrees with your assumption but nobody is going to write a neural network with it. Ironically JavaScript is the language showing a sort of resurgence for fp but nodejs is the worst platform for it due to its focus on io based concurrency.

Still though you will notice that despite the above caveats for node the framework still follows the classic pattern of segregating state away. Typical nodejs apps are stateless along with most web apps. If you worked with frameworks that have request handlers as the primary pattern you will see that this pattern tries to segregate io away as much as possible by turning the abstraction into a request/response combinator

So basically, The compute part of any application, no matter how small is a prime candidate for combinators via segregation of compute and side effects.... but of course if your application is io bound or highly stateful you can only go so far.

Post reply on HN