Hacker News Reader

Comment by astrobe_ | Hacker News Reader

Point-free is generally the main style for concatenative languages.

In order to be able to read it, you have to know by heart the signature of the standard operators, and then you have to learn on the go the signature of the operators of the particular program your are studying.

It doesn't fly well if the author doesn't follow certain "usability" rules:

- name things thoughtfully and properly,

- no more than 3 arguments for your functions,

- keep the complexity of the functions as low as possible.

This is good advice in any language, but I'd say that with concatenative languages at least, deviations are likely to have more acute negative consequences on maintainability.

View on HN

> - keep the complexity of the functions as low as possible.

This seems particularly critical. This style works well in Haskell where it's extremely common to have short functions.

I've found that Haskell code often has two kinds of functions: 1-2 line functions (or function cases) that do actual work and computation (often combining other such functions), and 50+ line monadic functions that implement simple sequential routines with very simple control flow (calling other functions for any non-trivial computation). Point-free style works quite well for many of the former.

I don't do Haskell, but I have worked on projects with lots of small functions, and one of the problems with that is that can be... too many functions. You have to go look up three functions every time you read a block of code. Worse, people start writing the same functions over and over again.

There's probably a bigger picture problem and fix in that kind of situation, but it is something I think about.

> You have to go look up three functions every time you read a block of code.

When you write small, single-purpose functions, you can make them fairly self-documenting with the name alone. If you have to look up a one-line function, it probably doesn't have a very clear function or name.

> Worse, people start writing the same functions over and over again.

That one I've definitely run into.

> There's probably a bigger picture problem and fix in that kind of situation, but it is something I think about.

Mechanisms to search functions by type ("find me a function that takes an X and returns a Y") help quite a bit.

Conventions also help.

For instance, the lazy readTVar, modifyTVar, etc. functions have strict analogs called readTVar' and so on. mapM, foldM, replicateM, and traverse return a monadic value, while mapM_, foldM_, replicateM_, traverse_ and friends discard the return value (giving an m () instead of an m a).

When you write small, single-purpose functions, you can make them fairly self-documenting with the name alone.

Sometimes, although with languages like Haskell there can be a related problem that accurate names for these small functions wind up being almost as long, or even longer, than their definitions.

Pharo/Squeak (and probably other Smalltalk systems) have a utility that let you find a function given a set of input/output examples.

Do you have a name/link? That sounds fascinating.

In order to be able to read it, you have to know by heart the signature of the standard operators

Unfortunately, while that tells you how many operands there are, it doesn't help you find them in the surrounding syntax.

In Forth, for instance, the operands of a + could be a pair of immediately preceding constants like 1 2 +. These could be far away in a contrived way: 1 2 [... snip stuff that produces side effects and keeps stack balanced ...] +. Or just due to expression complexity: [30 word expr] [27 word expr] +: the left operand of + is the result of the 30 word expr, which is 27 words away from the + symbol. Or is that 26? 29?

The 30-word expr should have been another word, or two.

So German trennbare Verben (split verbs)? :)

Whenever the literary German dives into a sentence, that is the last you are going to see of him till he emerges on the other side of his Atlantic with his verb in his mouth. - Mark Twain

> These could be far away in a contrived way: 1 2 [... snip stuff that produces side effects and keeps stack balanced ...] +

This is obviously poorly written. "1 2 + [stuff]" is the sane way to write it. Or "2 [stuff] 1 +" if [stuff] takes one parameter and outputs one result.

> Or just due to expression complexity: [30 word expr] [27 word expr] +

Post that on comp.lang.forth, and people will certainly tell you "don't do that" or "why do you that" if it's less trivial than a factoring issue.

In similar situations some people have this trick of separating sub-expressions with double spaces. But that's ignoring the writing on the wall.

What I learned from Forth is that it's true that it has its shortcomings, but I have my own shortcomings too. As Forth is a DIY language, you have to make this distinction in order to improve language/programmer pair.

This is obviously poorly written.

It's only obvious in the example form which I have. If such a thing occurs in real code, the stuff won't look like [stuff]; it will not stand out.

"Poorly written" happens.

I think concatenative languages have great potential when paired with a proper type system and IDE. But you're absolutely right when it comes to plain text programming; point-free style feels clever to write, but makes it more difficult to read.

In Haskell there are some rules of thumb: if your new function is just a composition of existing function, point-free is fine. If you need 'flip' and friends, consider giving points a chance. There's a grey area in the middle that asks for judgement calls.

if your new function is just a composition of existing function, point-free is fine.

I'd probably extend that to things like straightforward partial application as well, but I strongly agree with your implied point that once some new function isn't a relatively simple derivation from some existing function(s), point-free style tends to become a liability. It's cute doing things with weird combinations of operators like (.) and ($), but it's also the Haskell version of writing C code full of one-character identifiers and obscure macros.

no more than 3 arguments for your functions

It is hard for me to believe that this is a piece of style advice that anyone writing serious software would follow.

If you need to do something wherein the basic task requires 8 arguments' worth of information (which happens A LOT) then trying to factor that into 3-argument pieces is going to give you something Byzantine that is probably also buggy (and it could get extremely heinous, in a way determined by the data dependencies internal to the procedure you are factoring). And if you somehow succeed at all this, congratulations, you just did a bunch of engineering that did not improve the functionality of your software in any way. (In fact it probably made the software take longer to compile).

If doing a certain job needs 8 pieces of information, it needs 8 pieces of information. It doesn't help anyone to try to break that up.

Similarly with this:

keep the complexity of the functions as low as possible

Not really. If you are just factoring some block of complexity in to 4 blocks of less-complexity, well, now you have the same amount of complexity as the original code, plus the complexity of the call graph, and the fact that the person who comes along to read the code will not be able to clearly see the control flow.

There definitely are many cases when factoring a procedure into simpler things is beneficial. But to claim that it's a good idea all the time, or even half the time, is I think mistaken.

A guideline like "three arguments to a function" says nothing about the type of those three arguments. You are right that there are many jobs that require 8 or more pieces of information, but often those parameters can be grouped into structures which each hold multiple pieces of information. The point is not to create types for every function just to hold their arguments, but that well-thought-out data abstraction can simplify things by factoring data into named structures that are used in multiple functions. For example you could have a drawRectangle function which takes four parameters (x1, y1, x2, y2) of some primitive numeric type, or you could create a Point type and use just two of those. This improves clarity because it is obvious just from the signature of drawRectangle(Point a, Point b) that you are specifying the endpoints of the rectangle, whereas four numeric arguments could mean (x1, y1, x2, y2) or (x, y, width, height).

(a) This kind of thing in many cases is just tedious busywork that you are now making someone do every time they call the routine. What if they have a MyPoint and your procedure takes a YourPoint? And what if your point is 8-dimensional, anyway, what does that constructor look like?

(b) This has performance implications, not least because of the ABI. And depending on what language you are using, they can be quite severe (good luck if you are using one of those languages that always puts classes on the heap).

> What if they have a MyPoint and your procedure takes a YourPoint?

Then you get early warning that you need to be paying attention, rather than silently corrupting your data by swapping some coordinates around.

> And what if your point is 8-dimensional, anyway, what does that constructor look like?

You don't want an 8-dimensional point literal that takes 8 arguments directly, that's never going to be readable. You might want to use a builder. More likely you want to load it from a data file or something on those lines rather than constructing it directly. Where are you even getting these 8-dimensional points from?

> This has performance implications, not least because of the ABI. And depending on what language you are using, they can be quite severe (good luck if you are using one of those languages that always puts classes on the heap).

In Haskell (or indeed in C) it doesn't necessarily have performance implications; an 8-element structure may have exactly the same runtime representation as those 8 elements being passed distinctly.

(In my experience performance concerns are always overblown in any case. If you have actual performance constraints then profile; if you don't, don't worry about it. Too often performance is used as an excuse)

Then you get early warning that you need to be paying attention, rather than silently corrupting your data by swapping some coordinates around.

No, a real-world case is that I have a giant program that uses my own geometric primitives, and now I want to start heavily using a library. I know they are just fricking 3D points or quaternions or whatever. Yet because of some weird ideology you want to increase the amount of gruntwork I have to do, and make my life much less pleasant.

WHAT ARE YOU TALKING ABOUT

In Haskell (or indeed in C) it doesn't necessarily have performance implications; an 8-element structure may have exactly the same runtime representation as those 8 elements being passed distinctly.

Wow, okay, this conversation is over.

>> In Haskell (or indeed in C) it doesn't necessarily have performance implications; an 8-element structure may have exactly the same runtime representation as those 8 elements being passed distinctly.

> Wow, okay, this conversation is over.

I'm confused as to why this was a conversation ender.

An 8 element structure using newtypes in haskell would have the same runtime.

For more info, see:

https://skillsmatter.com/skillscasts/5296-safe-zero-cost-coe...

It was the "or indeed in C" that ended it for me right there (though that was compounded by the 'you want to load your 8-dimensional points from a file, where else could you possibly be getting them?' stuff, which shows that the correspondent has not done any scientific or geometric programming, or computer graphics, or video games, which are some of the main fields where performance matters most, so if someone is going to make a performance argument ... maybe he should actually know about performance programming).

If you want to talk about Haskell, fine ... I don't know anything about Haskell, though, and I am interested in high-performance programming, which is an area where Haskell cannot currently play (nor can any GC'd language). Making claims about how the performance of an operation in a slow language doesn't get any slower under certain circumstances isn't that interesting to me.

If you're not interested in a constructive conversation then don't comment in the first place.

If I've misunderstood what's going on with C then by all means tell me what does happen. To the best of my knowledge, if we're talking about 8 same-typed coordinates then there's no alignment/struct-packing issue, so whether you have 8 named doubles (say) or a struct with 8 double members (or indeed an array of 8 doubles), the in-memory representation on the stack is going to be the same; function calling convention is platform-specific but could easily have the same behaviour for the struct vs the named doubles (an array would be different in that case since you can't pass them by value). If that's wrong then talk constructively about what does happen.

> you want to load your 8-dimensional points from a file, where else could you possibly be getting them?

My point wasn't that you want to load them from a file, it's that it would be rare to want to have a point literal directly in your source. But why let that stop you leaping to a good ad hominem?

Function calls pass parameters in registers if they're small enough.

Reply on news.ycombinator.com