Serious question: Why is readability so important? For me consistency is far more important than anything as subjective as readability. I’d rather be able to reason about a code in its own logic than feel comfortable browsing code without much consistency. In the end all code needs to be understood for its internal logic and notation is secondary.
- in a corporate environment, your code is going to be read by many other people than just you. Your team mates, the guy after you left etc.
- also, by making your code more readable, you're making your own life easier as well. You might have thought at first that your code was fine, but by structuring it properly and possibly removing some redundancy, you might find that you were overlooking some things.
In my experience code reviews are generally cursory and the emphasis on “readability” is more about a culture that seeks to treat programmers as fungible. Also complaints about APL’s lack of readability are never about its lack of structure. So I took “readability” to mean something else as should be clear from my previous comment. Is your complaint about its lack of structure? If so would you mind elaborating?
Hard disagree on code being read more often than it is written. I’ve never seen any study of this and in my experience it is not true. Most code reviews end up being perfunctory. Even calling that “reading” is generous.
Are you counting reading code while you’re developing it? That would sound strange to me. If you’re talking maintenance by someone other than the original developer the pattern I’ve seen is minimal engagement with the code and an almost immediate press to replace it. I’d guess you’re talking about an idealized world.
I think _all_ programming is about finding an appropriate DSL for the problem at hand. First you need to understand the “language” of the problem then you develop a “lingo”.
Losing control of a project is likely more due to the programmers on it than the tools they use. IMHO _anything_ done consistently can be reasoned about and if necessary undone.
Not necessarily. Sometimes the rot goes so deep that there is really no way out.
And the C pre-processor has figured prominently in more than one such case in my career. And it was precisely in the kind of way that is described in TFA.
For something to be doable it needs to make economic sense as well and that's the problem with nightmare trickery like this. Initially it seems like a shortcut, but in the long run the price tag keeps going up.
Best guess is that your analysis is missing some detail. People not tools write programs. Also any serious discussion here ends up in politics. If you design your software so that the programmers are fungible then the software suffers regardless of your choices.
> Best guess is that your analysis is missing some detail.
What do you base that guess on?
I'm not saying it couldn't be done, I'm just saying that it sometimes just isn't worth it.
> People not tools write programs.
Yes. And just like people sometimes write crazy manifestos there isn't much point in fixing them, the purpose that they might have served is most likely better addressed by replacing them entirely.
> Also any serious discussion here ends up in politics.
Everybody knows HN doesn't do politics ;)
> If you design your software so that the programmers are fungible then the software suffers regardless of your choices.
Programmers are fungible not because they are cast from the same mold, but because - assuming they are responsible people - they can look past their present day horizon to the future, where after a lot of context switching they have to revisit that which they have made before, or, where they have to take over someone else's project, either because that person moved to a different role or because they've moved on entirely.
It is with such a future in mind that you can, if you want, make the life of that person a little bit easier by focusing on clarity of thought rather than terseness in expression. Nobody ever died for want of a few keystrokes more, but I'd have been a lot happier if some people made a habit of writing down first what the pile of executable spaghetti they wrought was supposed to be doing in the first place.
If you have not seen how bad it can get then more power to you.
Just one anecdote, which I may have posted on HN before, but a long time ago I worked for a game studio where there was a programmer who got into a fight with management. He left and I had to take over his project. All of the variable names were fruits and all of the functions were vegetables (or the reverse, as I said, it is long ago). There were no comments. But there were some bugs that needed fixing.
Clearly in his mind programmers were not fungible, and in my view the software suffered from his choices. So the one isn't necessarily a guarantee of the other (ok, n=1), though you might find them together every now and then.
I've seen some absolutely brilliant code that was clever and clear. That's the kind of thing that I aspire to, not to see how far I can push the CPP to do stuff it was never intended to do in the first place. We have contests for that sort of thing but it isn't the kind of construct that you should foist off on others in your line of work. Not if we're ever going to get serious about that engineering thing.
Recreational programming, that's a different story. Go wild, and I really hope you enjoy it. But if you submit your preprocessor based magical DSL as a pull request I'll nix it.
All good decisions are a product of the particular circumstances in which they arise. This post seemed to be about generalizing that process which I would guess comes out of a supposition of fungiblity.
As much as one can use a given style for a personal project so can one for a professional one so long as it fills the given need. Too often (in my view) fungibility is seen as a preeminent requirement and layers and layers of self justifying processes are built on top of that. I’m only saying that’s a choice and the costs and benefits are not as obvious as most suppose.
Also you can minimize risks with redundancy but most presume those costs to be too high. But again this quickly becomes about politics.
I think the main question is whether or not you want to reach your goal and see programming as a means to an end or as the end itself. Usually, even when working on my own projects I have a goal, and the software is just a means to an end. So I tend to work on my own as though I am a team of one rather than that I am working 'just for myself'. This means I set up a whole pile of superstructure that isn't strictly a requirement, force myself to try to abstract as cleanly as I can think of and even refactor my code (when there is no project lead telling me to do so), write tests and abstain from trying to be too clever because it gives me better and faster results.
I'd imagine a chef or a competent musician would still use their hard won skill when cooking for themselves or making music for their own enjoyment.
Just to double down here I took a code base written in this style (not exactly atw but inspired by him) and spent about a day expanding it to this point: https://codeberg.org/growler/k/src/branch/expand/a.c
My guess is it would only take a week to get it to what people here are calling “acceptable”.
this is a gross undeappreciation of a truly remarkable effort by my dear friend and associate. also, at least one of the languages presented is due to him. you can call him @ktye. he's too modest.
it is not a Kunstkamera or some computer cryptozoology extravaganza. many things are shown here, from different eras, but some are not - they are evolving. and progress takes sacrifice.
cheers
k.
ps. we usually spell atw as atw :) he also goes by a. don't chicken out, send him an email. he's a very friendly guy. just like me.
Perhaps a more precise question is whether you can write programs as performant as those written in C or Fortran and the answer is it depends on the program (and more likely the programmer). The languages tend to do memory management for you which means giving up some control. Most use “immutable” data structures which force more contraints.
But for the loss of control you get stuff like fancy SIMD implementation for nothing.
All and all there’s a cost/benefit calculation but that ratio can get quite low.
You could say you enjoy toodling on the piano but don’t understand why reading music has to be so hard. It doesn’t _stay_ hard and it opens up new avenues.
