Clever code considered harmful
joshwcomeau.com
joshwcomeau.com
- writing "return condition" instead of "if condition then return true else return false end"
- using the conditional-value ("ternary") operator in any capacity
- early returns/goto cleanup instead of nested if conditions
- using basic higher-order functions like map or reduce in any capacity
- any kind of metaprogramming whatsoever
One person's "clever" is another's "elementary". If you want to point out that some code is hard to understand, that's fine. But don't call it "clever". Using "clever" as a criticism is implicitly an ad personam argument, passing value judgement on the person who wrote it ("Oh, they must have written it to show off") instead of an argument about the code itself.
Also, this:
> Hi friend! Hope I didn't startle you. Can I let you know about my newsletter?
is missing a "fuck off to hell, don't you dare disrespect my attention like that ever" button.
> using the conditional-value ("ternary") operator in any capacity
Looks like author of some code I had to comb through recently, maybe had that among guidelines. Said code was replete with:
if(function_that_returns_boolean()){
return true;
}else{
return false;
}
if(foo()){
return true;
}else{
if(bar()){
return true;
}else{
return false;
}
}Why stop there?
switch (byte_value) {
case 0: return 0;
case 1: return 1;
...
case 255: return 255;
}Doing the same for not tiny boolean expression: way more
Just because you think it is cool cuz profs forced it on ya during college is not a argument
What most people object to is leaving the last level of if-then-else and returning true or false, when you could have returned simpleBooleanExpression and do away with 1 level of nesting.
If a And b Then
Return True
Else
Return False
End If
The 2021 final exam (which is the most recent I can find) [1] somehow creates XML records for a SQL database (section C, question 7), and hints at using "data validation" to avoid an SQL injection (section C, question 11.c), which is quite exciting. And the 3.5 gigabit wireless connection (section A, question 13) is definitely not using an ISP-supplied router.
[0] https://www.vcaa.vic.edu.au/Documents/exams/technology/2019/..., answers https://www.vcaa.vic.edu.au/Documents/exams/technology/2019/...
[1] https://www.vcaa.vic.edu.au/Documents/exams/appliedcomp/2021..., answers https://www.vcaa.vic.edu.au/Documents/exams/appliedcomp/2021...
case Big_Expression_Here is
when true => Do_Something;
when others => Do_Something_Else;
end case;
But I would want to know what they've done themselves to evaluate the weight of their expertise. If they have impressive projects, their criticism means something.
there was a koan about the progression of someone's Java program from beginner to intermediate, to expert to master to enlightened. The code for the enlightened looked the same as the beginner.
These koans are useful too
https://prirai.github.io/books/unix-koans.html
Edit: In other words, say a developer that criticized wordpress, do you respect what they say more than the success and value of wordpress (of the wordpress developers)?
I don't like the pride, superiority and smugness that comes from criticizing code and the assumption that they're the ones in the right because of their criticism, rather than the expertise of the one who wrote the code and solved the problem and did the work.
I've noticed people pay more attention to the stones that people throw rather than those throwing them.
Edit: In other words, criticism is cheap if you have no skin in the game.
I don't think it's a fallacy, it's like hosting a wedding and inviting a guest and then being criticised for the entertainment on offer. People pay attention to the criticism, not that the criticism is coming from a guest and that their criticism is not as valuable coming from the guest than the people paying for and tastes of those hosting the wedding.
Whether or not the code quality issues are true or not, their importance is dependent and weight of someone's criticism is not that high as everyone thinks.
> Edit: In other words, say a developer that criticized wordpress, do you respect what they say more than the success and value of wordpress?
Depends on the content of the criticism. There are many legitimate criticisms to be had about WordPress, and they can't all be dismissed with "it's popular, so it must be good".
An authoritative source of accomplishment or demonstration is more valuable than someone with no skin in the game, or who doesn't even contribute even if what they say is true.
Wordpress has had security issues, I didn't mean to say popular = good. What I meant is that I trust the wordpress developer's ability to know how to write software that works than someone who doesn't know how or has ever written successful software but knows how to avoid security issues. Don't let perfect be enemy of the good :-)
What would you prefer or listen to more? More developers capable of writing wordpress-successful products or more developers who can criticize but can't build anything.
You could listen to the wordpress developer's attitudes on software development but you wouldn't take their security advice. Maybe you would ignore the criticizer's criticism on how to build software.
That's true! Just calling something a best practice does not make it so. That also has to be argued for, by demonstrating the consequences of one practice over another.
> I trust the wordpress developer's ability to know how to write software that works than someone who doesn't know how or has ever written successful software but knows how to avoid security issues.
Criticism being easier to state than address does not invalidate the criticism. "Sure, this extension may be full of SQL injection bugs, but that's easier said than fixed, so it doesn't matter. I'm going to install it anyway."
Mmm I've been programming for 30 years across a lot of languages. My code doesn't look the same as it did when I was a beginner. Sure has flopped around a lot though. Take comments:
- When I started, I used no comments (because I was ignorant)
- Then I put comments everywhere because someone told me it was good practice
- Then someone said comments are a sign your functions are too long and poorly named. So I went back to no comments for a bit. But I sort of hated the resulting code - functions were too small and it still wasn't "obvious" no matter how cleverly I named my functions.
- So then I had a few comments here and there, wherever my code wasn't "obvious".
- Then I tried literate programming, and my code was in small islands amidst an essay of comment. That was fun, but it didn't last.
These days I use comments for 2 purposes: to document my APIs, and to write little letters to my future self. Eg:
// This code looks wrong at first glance, but its actually correct.
// Here's why: ...I don’t get it; why?
Anecdotally, me and my colleagues are fine giving ourselves feedback that some code is too clever, without malicious undertones.
I am personally on the fence about this one. It's tremendously useful when writing code, and I've done quite a fair share of it myself; but on the other hand, when you are reading the code, trying to understand what the hell is actually being called and why, it really sucks when your F12 bottoms out at some meta-generic piece of machinery that invokes something when called from somewhere but what and where, exactly, is a mystery that requires a global search over the repo in the best case (in the worst case there is either nothing to search on or the search term will turn up thousands of hits).
But, like all programming: it should help readability and it should help to avoid bugs, not be used for its own sake, aka cleverness.
Metaprogramming tho... You want to make a magic black box that takes hours to debug and conceals real bugs, invest heavily in metaprogramming to save a hundred lines of code that can be maintained with three find and replaces/SED calls and a recompile a year... Most metaprogramming shouldn't exist in production code.
Programming is social. You have to weigh your decisions heavily by who you work with now and who you might work with in the future. If you work in a niche language or toolset you might think "this is my chance to do whatever I want!" But the reality is, it should be the complete opposite.
Most compilers make clever code silly. You can write a 15 line hard to read pipe or method chain, or a 25 line double for loop with the same runtime characteristics. The latter is always better to maintain, while the former is always more clever. One is good for the team the other for someone's self esteem.
I desperately wish I could say this, but I have seen it happen
I've seen both cases for some of these types of things. The rotten culture being the most common
Weirdly, in rust there's lots of cases where the compiler will generate better assembly if you give it map/filter/fold than it will if you give it a for loop. The reasons are weird - like, its easier for the compiler to know it doesn't need bounds checks for list.iter(), and to work around some integer overflow errors while iterating through ranges and things like that.
The difference usually doesn't matter in practice, but I still find myself thinking about it in performance critical sections.
The challenge with DO NOT TOUCH this code comments that intense performance tuning leads too(figuratively and literally) is it makes people who don't understand the code build bizarre(and often slow) monuments all around it that don't usually need to exist and deter from the minor gains won over a cute optimization. I've seen this happen ALOT.
Of course there are times where you should opinionate your code to better serve the machine. But my big thing is, it's rarer then the overly complex design decisions favoring it are and compilers are getting better every day.
Go ahead and try. Many of the libraries you will use use metaprogramming of one flavour or another for ergonomic reasons.
Python decorators are metaprogramming. For example putting @cached above a function declaration esentially wraps your function into another that caches it's values without you ever having to see all of these details.
I am not sure if your production code would really gain from writing out that caching logic over and over again for each of your functions that need caching. I am sure however that it would become less readable and harder to reason about.
In Rust #[derive(Serialize, Deserialize)] can be used to automagically give your data-types serialization and deserialization. This is also metaprogramming. It also reduces the code you have to read and write and the mistakes you will make if you roll this on your own. It also makes your code easier to read to all people who understand what it does (so nearly everyone who programs Rust).
Metaprogramming is okay, if it is done in the right places for the right reasons and doesn't obscure the logic of the program.
I often use it for custom decorators in flask e.g. @admin_user or @authenticated_user to quickly wrap the functions for some http routes with the ever-same logic for authentification. Sure you could also do this with a function, but the ergonomics could be worse and you could accidentally place the function call in the wrong place and thus exposing some parts of a route to unauthenticated users. I don't think this makes it harder to reason about my code.
Like all "don't do X" idioms in programming the one about metaprogramming should be taken with a grain of salt. There are cases where metaprogramming is the best (most reliable, futureproof, usable, etc) way of solving a given problem. The warning is true in that you should avoid using it everywhere without reason. But there are places where it makes sense and there it would be a waste not to use it
You’ve just told us which one you’re more familiar with, that’s all, which is exactly what the other commenter was pointing out. This one also belongs on the list in that comment.
Beyond familiarity and subjective preference, there are benefits to the pipe approach that come from its functional nature. Determining that a for loop is a pure pipeline can be tricky in general, which contradicts your idea about which one is harder to read. And the ability to get reliable parallelism for free - e.g. Java’s parallelStream - is not a feature of for loops.
This is the big one. For large datasets or computationally intensive processing the speed difference will be noticeable.
One of the issues with "cleverness" is also that code that's trivial for John Carmack to understand might not be for $BODY_SHOP_RESSOURCE_200353.
I recall a self taught dev (or maybe from a bootcamp) coming up with a cascade of nested if-else, nested 8 deep. Someone with a background in CS asked him what he was trying to do and basically concluded that what he was trying to do could be expressed as a state machine. To which the initial dev replied that it was "way too fancy" and that he didn't need the code to be fancy, just work.
You can grill me if you want and say I am the problem! Zing ouch got me so good! Those HN points will get racked up, so much winning...
Or you can read between the lines. I drew an unspecific example with microseconds of thought behind it. People who know what I am saying know what I conveyed is fine. People who know me, know I regularly use pipes and chained method calls all day. The point is, the paradigm could go either way, it depends on culture(reading the room), and design decisions. Had I of flipped my example and said "method calls can make code way cleaner than for loops" which in some contexts is equally valid your antiparticle HN contributor would make the same argument you made calling me the problem. Get it?
I would say people trying to shit on everyone around them for being casual are more of a problem then anything else. Especially in collaborative development environments. That supercedes any code anyone could contribute. But that's my take and I'm not going to suggest it belongs on some arbitrary list of ad hoc HN rules (of which none hold water)... I won't be writing a five pager with examples where what I said was sound valid and best praxis, I have nothing to prove, and that was never the point. Everyone who knows what I'm talking about gets it. Happy flag planting with imaginary enemies.
Why not? As in, it just seems like a language design issue, there's no reason why you technically couldn't use the "simpler" syntax. For example, what prevents us from having:
parallel for (Type instance: collection) {
// code for each iteration
}
If the construct you propose were feasible, why do you think it doesn’t exist?
The reason is that it’s not feasible. Compositional pipelines involve constraints and properties that an imperative for loop doesn’t support.
Because it already exists as a part of the Stream API in a way that doesn't change the language much: since you can mostly use .parallelStream() or .stream().parallel() there's basically no need for the "old" syntax to enable the same functionality.
That doesn't mean that it's somehow unfeasible, since the implementation of the example "parallel for" construct would just need to execute the code in the loop body with a ThreadPool. The Ada language has a nice example of parallel loops like that https://ada-lang.io/docs/arm/AA-5/AA-5.5#p26
Of course, there are other benefits to streams and lazy evaluation, but perhaps that's besides the point.
Agree that “clever code” is silly but also important to remember that people need to entertain themselves and “grow professionally.” People get paid more if they write the 15 line pipe and it’s job security. Maybe gpt will help since it’s a lot better to have gpt write easy to debug for loops, but then programming will be less fun. People need to entertain themselves.
I am pro have fun screw up and grow. But macros present a certain kind of danger a lot of other tools don't. If you are playing with them be careful of their scope is my only real warning.
There is a fashion for inverting it: "if (true == some_boolean)", which seems arse-over-elbow to me (I do know why people do that).
if (true = some_boolean)
if (some_boolean = true)
Here’s some more explanation
https://softwareengineering.stackexchange.com/questions/7408...
Looks like the pattern is sometimes referred to as a Yoda expression.
I don't know how you got this conclusion.
I can see judgement being passed to the code with respect to not just who wrote it, but also who's going to need to understand it later, who's going to need to make changes to it. In that sense, calling code "too clever" makes sense, right?
There's hyper-specific reasons why you'd need code that's going to be complex/too clever for that group, esp if it saves cost or is faster than the simpler alternatives, but in most cases there's nothing that justifies it.
Yeah, that's the button I was looking for.
This removes virtually any pop up or cookie banner or suedo ad on any popular website.
this is one of the stupidest things ever said about any piece of code. how about you give that feedback to beethoven (and other great composers)? hey beeth, can you please make your music piece so simple that a junior pianist can play it? this thing over here requires too much study and virtuoso to play, and that's not something we want to aspire to.
or to euclid: hey can you remove this _pons asinorum_ here? i have a beginner whose struggling to understand the isosceles triangle. clever code is art to be studied and enjoyed. they are the vehicles of growth, of new and important ideas. holding them off for the sake of a proverbial junior is stupid.
Cool, great, save it for the Obfuscated C contest. The less time I spend “studying” someone else’s idea of cleverness while trying to fix ticket #51483 or implement some weird business logic corner case the happier I am.
(*) even the example given in the article of an obviously unnecessary use of "reduce" is pretty rarely representative of the sorts of reasons code is hard to understand, though I have come across similar things in 3rd party open-source libraries and the like - I would say though these days you could almost certainly get ChatGPT to explain particularly obscure uses of map/reduce etc. Whereas it's never going to be able to explain high-level behaviour that requires the entire codebase.
Composing music to be performed if very different than sharing the composition of it with many composers.
There is meter and scale and notation but only so many ways you can express things with the most complex being complicated meter. Now performing that - yes - more complexity but not in the composition.
We dont need programmers to "perform" in every CRUD app on the internet. We arent all writing game engines, gpu drivers, etc etc.
There are Beethovens out there doing things that require phenomenal skills (that can be learned) but its not 1:1 with composing music with performers limits in mind when the composer didnt HAVE to collaborate.
In your analogy I think the listener should be the junior programmer. Music by Beethoven can be appreciated by many more than just the people who can compose on that level.
In the same way you can write code so that also junior developers can appreciate it. The challenge lies in clearly expressing solutions to complex problems.
I don't think you quite got the idea this article was trying to convey. Here's a simplification:
Don't make simple things look hard.
Hard problems require convoluted solutions, however those solutions can still be broken down into simpler steps. Don't obfuscate the simplicity, allow all the simple parts to work together to create something complex.
We should not sell humanity short by trying to solve the problem of beginners in our stuff. We need to make things for people to use, and we need to teach people and trust people to be able to learn how to do that.
https://youtu.be/QCwqnjxqfmY?t=1914, https://youtu.be/QCwqnjxqfmY?t=2063
To me, clever code is maintainable code. If you can't understand code, either it is not maintainable, or you don't master the language at the required level.
The thing is that it depends. "Ternary operators are too hard" is not an absolute truth. I would argue that sometimes they are more readable, sometimes not. Same for recursion and everything. The art is to find the balance, and even there, there is not one universal truth.
If my interns need to learn things, that's not a problem for me. The goal is not for the interns or my grandmother to maintain my code. The idea is that the maintainers maintain it. If they find it maintainable, then it's hard to argue that it is not.
* "Literally" used in a way to refer to something that's clearly figurative
* "Non-trivial" used in a way to refer to something that is clearly extremely complicated
Much as I like to decry abuse of language¹, at some point one has just accept that a headword has gained a new bullet-point in the dictionary and move on.
1: and speaking, or, rather, attempting to speak, the Queen's^W King's English, the modern American-centric world certainly delivers opportunities for that!
But then they tend to go as far as to say "never use this concept, because it's too complex", or even go towards wishing that the language did not offer any "clever" features, which I disagree with.
Yes, write good code, as in "maintainable". But don't say that a concept is always bad (be it tertiary operators, recursion or templates). It depends on the language, project and situation.
Smart code is maintainable. Clever code is not.
Smart code takes complex problems and simplifies them in a way that makes them easily understandable by the whole team. Clever code, whether the original problem was complex or not, presents a complex solution that's difficult to follow.
Have you ever poured a lot of work into something only to have a coworker say "how simple - I thought that would be a lot harder?" That's smart code, but your coworker was expecting clever.
Those are the meanings people are using in the conversations about clever code.
The thing is, getting to the point where you can write good code takes experience, not blog posts that say that recursion and tertiary operators are always "clever".
Because “nice to read and easy to maintain” is a goal, not something trivial to evaluate while writing (especially the easy to maintain, which, among other things, is dependent on what the actual future needs will be), and acheiving that involves balancing competing factors, opinions on how to do it conflict, experience of what works varies, and clear and applicable science about both the broad trends and what explains specific variations from the trends is sparse.
I don't have the time or motivation to "master the language at the required level". I want to get in, fix the code, test the fix and get out. That's what I get paid for, not spending weeks to become an expert in Language X's clever code tricks and hacks.
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
I am just saying that the choice of what is "overcomplicated" comes to the maintainer. My project, my rules. If you don't want me to use lambdas in the project you maintain, that's your choice (and it is my choice to contribute or not). I just don't agree when people say "don't use tertiary operators ever, because I don't like them".
Interestingly, I go further than you: good code to me mostly doesn't need comments. Comments are there for the more complicated parts, but most code should be readable as-is. I guess we mostly disagree on what is too complicated :).
Cognitive load of understanding code is expensive. I tend to leave notes for myself. Document the not so obvious things with little one liner comments. Rename variables to clarify what they are for. Extracting code to get rid of the distracting clutter. Etc. I sometimes get comments from others that they find this helpful. That's nice. But I do it for myself as well.
Simple code is obvious in what it does. There's a certain elegance to simple code solving big problems. It takes effort to make things simple. Making things as complicated as needed but not more complicated. Being overly clever means you end up with a Rube Goldberg machine of unnecessary complexity and clever mechanics that is hard to understand and maintain. You get a certain satisfaction out of making that kind of stuff work but in the end it's a mistake.
To understand other people's code, I have to put away my own thoughts of how things work and try understand the thinking model and mental model of the person solving the problem.
And if they're smarter than me, then I have an uphill battle.
I think experts get too deep into values that aren't practically valuable to businesses or me and as a result go into the deep end creating a manifestation of something they think is beautiful or elegant but for me is a mess I am now forced to understand, with reluctance.
They say that one person's trash is another person's treasure and I think it applies to code too.
One person's elegance at runtime is another person's unextendable mess that leads to slow velocity and developer morale.
They say code IS the documentation but I don't agree. I don't want to bounce between 50 tiny files to understand where the core part of your algorithm is and what I need to do to get the behaviour I need.
I think if you're reaching for advanced language features to solve the problem before better data modelling, that's a warning sign.
Right or wrong, I think this is true for most programmers. Would be interesting to understand why this is so. Probably related to the problem in the article: we're writing code that is too clever, so reading it takes too long or is too mentally taxing. If we could read code as fast as we read text, it would be less annoying.
I prefer reading documentation or technical deep dives - such as this one
https://mattwarren.org/2017/02/07/The-68-things-the-CLR-does...
Is code more dense than English? Why do I understand more overall from this blog post than I would if I studied the codebase of the CLR for hours and hours.
I think it's to do with mental models. If developers were on all the same page of understanding the underlying mental models, we could all understand eachother's code because we all understood the same underlying things.
This describes the majority of practices today. Individuals pushing their own values, selling it and hoping it sticks despite having zero evidence to back it up. Even most things 'proven' are fairly context-dependent.
The majority don't even bother making a simple cost-benefit analysis these days. As if any significant social change is just going to break even from moment one and staying 'we should do X because it will give us Y' is a good enough argument. It is crazy how casually some of them advocate for practices that won't break even in the span of a few years at best. That's a lifetime in the field of software development.
It's like opening a time capsule to yourself and getting nothing but a punch in the face.
I often wonder what happened to me. There's a preponderance of evidence that I was smart in the past but very little that I'm smart today.
"Beware of bugs in the above code; I have only proved it correct, not tried it."
- Donald KnuthA really good reason would be to significantly improve performance or reduce a maintainence burden (e.g. loads of duplication). A good reason would not be "elegance" or an abstraction which might be useful one day.
One of things I loathe about code review is fighting for simplicity against people who haven't figured it out yet.
I'm with you though. I don't like reviewing a lot of code because it sucks calling out a simpler approach to someone who is clearly trying to showcase their greatness. Can put mid level engineers who know better in a crappy spot.
Sure there is code that is needlessly labyrinthine or confusing, but otherwise the far more important rules are
- Be concise
- Do not repeat yourself
- Never be scared of the language. Every feature is a tool that has a right time to use.
Code should be simple in these terms, and it takes a fair degree of cleverness to make code simple in these terms
There's a time and a place for clever code. Clever code can save you thousands of dollars in hardware spending and permits you to do more with less. That's great, even if it comes at the expense of costlier maintenance.
That said, most code probably shouldn't be clever. Clever isn't a benefit in itself.
As a profession, we really don't give one another enough help. Coding is not about reaching some platonic form of terse expressiveness, it is a social activity, and the sooner this is commonly understood, the better.
function extractDataFromResponse ([Component, props]) {
return _.pickBy({Component, props}, Boolean);
}
Here’s my version of the “clever” example that doesn’t depend on Lodash. It’s longer than your version but still simpler than the article’s:
const extractDataFromResponse = (response) => {
const [Component, props] = response;
const dataIncludingUndefinedValues = { Component, props };
return Object.fromEntries(
Object.entries(dataIncludingUndefinedValues).filter(([_key, val]) => val)
);
};I still hate perl so much for crap like that.
That guy’s entire job is to become the expert you need. It’s a bad tradeoff to permanently handicap your experts from communicating clearly and concisely to each other, just to accommodate the start of his learning curve. It’s also not doing his career any favors, having to work with worse code for the rest of his tenure.
If you agree that code is a way of communicating with people (not machines), then this is a corrolary of my rule: that if you truly understand a complex matter, then you can explain it in simple language to a reasonably intelligent non-expert.
Wrong. It is extremely easy. The code isn't golfed. It is regular J code that could be written by anyone who's looked at J for more than 5 minutes. They've not even copied it right! I was confused for a second at what gt was, but it's just a mistake from copying >.
The other paragraph is also nonsense. It's just in a different language. Don't hand it off to python (or whatever mainstream lang) programmers, hand it to array programmers and they'll do just fine. If I were to be provocative I'd say that the J is vastly easier to read write and understand than the equivalent in any other (non array) language.
Clarity is more important than performance, and in many cases the performance gain is imaginary in the first place.
Every time I write code and tell myself "I will just keep in the back of my mind why I did that", I know I am writing bad code. There should be no open loops, you should not have hidden knowledge in your brain about how the code works.
By the line, most code and tests will be written by AI in the next few years, with humans specifying it, checking it and checking the overall results.
The next generation will look back and ask, "you wrote code BY HAND ?" the same way 99% of us look back and ask "you wrote assembly code BY HAND ?" (and by the numbers, 99% of us don't manage memory by hand, either)
The first computer I was exposed to was an IBM Schools Computer. It had no assembler. It booted into what in retrospect I suppose was a primitive memory debugger; you toggled machine code into the box as hex bytes.
edit: oh, J lang is a later K. That explains it. Similarly it should be sent to hell. It calculates an average in the most obtuse manner. So clever. I hope I never have to work with that one.
This is the point of the OP and I agree.
So many reasons.
You said the moving average in particular was "obtuse". How? It's more verbose than it could be, to make it more readable/obvious. Like I asked, what would you do? Whenever people say something is bad, if they can't provide either a good reason or an alternative, it makes me inclined to think that it is simply a kneejerk reaction to unfamiliarity.
Another example is, Russian is much more expressive than English due to the more advanced grammar. That said if you want to express yourself to your American peers and they don't speak Russian you don't write in Russian. If you are all Russian sure.
We use kdb/q in our firm but I would rather not and will be trying to migrate away from it in the future. It is good but bigger picture more trouble than it is worth. At least our code is formatted and not all one liners like Morgan Stanley.
Like you say, if everyone speaks Russian, communicating in Russian can have benefits. The same thing is true with J, or k, or any of these more obscure languages. Saying that your code is "formatted" and not "one-liners" to me suggests that you haven't seen these benefits yet, and I'd suggest reading Iverson's Notation as a Tool of Thought[1] or some of the very informative HN comments [2] about how this style of code can be very useful and productive, and yes, readable.
You still haven't answered my original question, which was how the implementation of the moving average was "obtuse". The moving average code is (>:i.$n)%~+/\n. This seems pretty reasonable to me. As the cumulative sum is ascending, you can use /: instead of i.$, but that seems less obvious. I don't know what issue you could have with this code, other than it having slightly more punctuation than a mainstream language.
https://blog.pwkf.org/2022/09/18/always-optimize-for-dummies...
One of my pet hates is when the c# style is for opening braces on a new line, making if/then/else statements much longer than they need to be, so people try to cram as much into a single ternary as possible.
Although given that there are only two properties to process, the gopher-style assignment code preferred by the author would suffice anyway.
Some of these ideas end up in production if I can find a way to make them less clever-looking and more approachable.
When I was younger I wrote fun code in production. Then I had to extend it or debug it some years later and struggled to figure out what was going on. Invariably ended up rewriting it to plain code, often many lines more but with clear intent and little ambiguity.
Doubly so if (when) you're not the one who has to come look at the code in 5 years and spend days deciphering the clever bits.
You know "considered harmful considered harmful"
and complaining about "considered harmful" whenever "considered harmful" post appears?
Why make assumptions that don’t make sense in the language you’re using?
This is what I learned today!
Is the correct pronunciation of Euler equivalent to clever code?