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

301–310 of 362 posts

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

#301

Post by yowlingcat »

Geminidog wrote: post #155
yowlingcat wrote: post #139

Earlier quoted context omitted.

> 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 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 the easy parts easier. And there is something to be said about that -- there are a lot of codebases where just doing the table stakes refactoring that minimizes the surface area of stateful code does a ton to improve the codebase.

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.

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

#302

Post by shakow »

Geminidog wrote: post #206
unityByFreedom wrote: post #194

Earlier quoted context omitted.

I meant up front you'd need to write more functions than you would when using functions that allow multiple arguments.

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.

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

#303

Post by garethrowlands »

ritchiea wrote: post #273

What's the difference between writing OO code that depends on internal state and writing a pure function that expects an argument that is a data structure of a specific type (and thus has internal data that could be different)? Is the pure function no longer pure if the argument is a data structure thats complex and the values within the data structure dictate the outcome of the the function? Or is it a pure function…

Passing a big structure to a function doesn't make that function impure. But passing a structure containing objects with impure methods does make the called function impure.

Passing a big structure to a function is a bad idea in any paradigm because it's a big dependency. Instead, you should write the function to operate on the data that it needs and pass just that when you call it.

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

#304

Post by Phelinofist »

ludocode wrote: post #63
ZephyrBlu wrote: post #51

Earlier quoted context omitted.

I'm not sure what exactly Linus means by this, but I read this as: for good programmers, coding is about managing data structures and their relationships whereas bad programmers are more concerned with just getting the thing to work.

I think it's more that bad programmers focus on surface details like code style. All too often I've seen a code review of a complex feature get derailed by nitpicking of inconsequential things like variable names, formatting, etc. I rarely comment on code style for this reason. I want the review to focus on functionality, not style. I don't really believe the notion "imperfect code style is a code smell" anyway.

I check both when doing reviews. Style and "cleanliness" of the code is important as other people are also expected to work with it. Also I follow the saying that code is more often read than (re)written, so that should not be neglected.

Structure of the code, as in relationship of classes, data flow and high level design is also important and checked during review.

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

#306

Post by garethrowlands »

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…

A higher order function is a function that takes another function as a parameter or returns a function as its result. Famous higher order functions include "map" and "filter", for example. Javascript, for example, uses higher order functions all the time. See [1].

The term "higher order logic" typically means program logic that uses higher order functions. An object-oriented programming style is inherently higher order because objects typically contain functions and are passed to methods.

The term "higher order logic" can also mean a system of logic that allows statements about logical statements. [2]

[1] https://en.wikipedia.org/wiki/Higher-order_function [2] https://en.wikipedia.org/wiki/Higher-order_logic

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

#307

Post by ImprobableTruth »

nightcracker wrote: post #244
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…

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…

>It leads to recursion where iteration is more natural

Viewing iteration as more 'natural' than a fold seems down to mostly taste. And hell, if you really want iteration, you can easily get that in both effectful and non-effectul variants through monads.

>ask a functional programming zealot to implement an O(1) hash map in a pure way—they will usually stammer, try to move goal posts, before finally admitting it's not possible

Except that no one - not even Haskell zealots - will argue that you never need effects, but simply that effects should be encapsulated. In Haskell, nothing prevents you from using mutable state if you really need it and mutable hash tables can be easily implemented using something called functional state threads [1][2].

[1] https://www.microsoft.com/en-us/research/wp-content/uploads/...

[2] http://hackage.haskell.org/package/hashtables-1.2.4.1

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

#308

Post by IggleSniggle »

wruza wrote: post #190
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…

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.

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

#309

Post by eyelidlessness »

rednafi wrote: post #272
eyelidlessness wrote: post #110

Earlier quoted context omitted.

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

I'm someone who came to the server side of things from the scientific Python community. IMO, that community is still learning how to incorporate Python's best practices to cater their very specific needs. For example, if you're writing a plotting library geared towards data scientists, you're almost forced to pick brevity over verbosity even if that means violating some of Python's core philosophies. Data scientists…

Right. And a lot have come from other languages like R where that’s more common.

If I were building a library for something like that, I’d build the core idiomatically, then expose an idiomatic API with aliases for brevity. I’d make sure the alias is documented in the docstring, and types refer to the idiomatic names. I know TIMTOWTDI isn’t entirely “pythonic”, but it’s a small compromise for probably a good maintainability boost.

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

#310

Post by eyelidlessness »

paganel wrote: post #256
eyelidlessness wrote: post #110

Earlier quoted context omitted.

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

For what it’s worth, having spent the last few years writing server-side TypeScript, I’ve evangelized “explicit is better than implicit” fairly aggressively. A lot of even seasoned TS developers are still mainly accustomed to JS interfaces, and fairly often their first instinct is to cram a lot of semantics into a single variable or config flag. I’m glad I spent a few years working with PEP-8 fanatics. It made me much better at thinking about and designing interfaces.
Post reply on HN