Beware clever devs, says Laravel inventor Taylor Otwell

[-]

_mini@reddit

All depends on context, dev delusional think him/her self is clever? Or actually clever. The former is usually stupidly obvious stupid. 🤣 so stupid that he/she doesn’t even know!

[-]

tony_bologna@reddit

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it,

[-]

GaboureySidibe@reddit

Clever is a good word, people need to get over themselves and write in the most clear, simple and straightforward way possible.

[-]

Ameisen@reddit

write in the most clear, simple and straightforward way possible

I've yet to find a way to write a function that emits an x86-64 machine code chunk that generate a patchable jump that has the address returned by a seperate function, that also injects the offset and value of this patch into a different table of patch addresses... in a clear, simple, and straightforward way... :(

[-]

GaboureySidibe@reddit

This seems like you're trying to inject whatever is on your mind into a thread that has nothing to do with it.

[-]

m15otw@reddit

It is always weird to me. In the UK:

Clever = intelligent.

Smart = well-dressed and groomed.

"A little too clever" = too complex.

I am well aware that in the US the words are assigned different meanings.

[-]

GaboureySidibe@reddit

They aren't assigned different meaning and smart doesn't mean "well dressed and groomed".

In this context people being clever on the expression level with their programs gains nothing but gives more cognitive load on anyone dealing with it.

[-]

tony_bologna@reddit

Agreed.

If you're part of a team, it should be written so people after you can understand it as easily as possible.

If it's your own personal project, than do whatever insanity you want.

[-]

clintCamp@reddit

But if you write understandable code, then you are expendable because they will just hire a Jr dev to take over the project once the heavy lifting is done.

[-]

Ok-Seaworthiness7207@reddit

That's cute you think there's an actual scenario where you aren't actually expendable in a company's view.

[-]

josefx@reddit

If you're part of a team, it should be written so people after you can understand it as easily as possible

I had to obfuscate bugfixes to get them past code review. Between self proclaimed programming gods, people with photographic memory of every bit of documentation they ever saw and the lesser programmers that totally know how iterators work it was flat out impossible to get some straight forward fixes merged. A convoluted mess that also improves performance while hidding the bugfix on the other hand would fly right past review because nobody actually has time to look at all that.

[-]

shevy-java@reddit

I am thinking this a lot when I look at JavaScript written by other people!

[-]

MrDilbert@reddit

Do you think about it when looking at JS you wrote? Because I bet other people do...

[-]

GetIntoGameDev@reddit

I tend to read the word “clever” more as “deviously correct”, as opposed to “smart”. It could be due to the associations or common usage of those words

[-]

GaboureySidibe@reddit

I tend to read the word “clever” more as “deviously correct”, as opposed to “smart”.

Right... that's the entire context of this thread.

[-]

bwainfweeze@reddit

The problem is a lot of people think they want to be clever and don’t realize their coworkers are arguing over coffee about who should take them aside and tel them to knock it the fuck off.

Clever is a pejorative. Deal with it. If you want to be amazing, write smart or wise code instead. If you don’t know how, that’s a you problem. Find a mentor.

[-]

PressWearsARedDress@reddit

I don't agree with this law.

Well thought out code is much easier to debug then code that was haphazardly thrown together.

[-]

wichwigga@reddit

Clever does not mean well thought out in this context, I know the dictionary definition blah blah.

[-]

Genesis2001@reddit

Yeah, I think clever in this context means "rules lawyering" your way to a solution, to borrow an analogy. Coming up with some workaround / solution to a niche problem. They make great memes down the road but suck to debug usually lol.

(I can't think of any examples off the top of my head now... ><)

[-]

badpath@reddit

Instead of:
int c=a a=b b=c

A clever version would be:
a = a XOR b b = a XOR b b = a XOR b

Both achieve the same outcome of swapping the values of two variables, but in 99% of situations, you're sacrificing the intuitive readability of your code for the space saved by not instantiating one integer. It works, but it's not how anyone expects you to implement that.

[-]

Anodynamix@reddit

There's absolutely nothing wrong with the XOR version if it looks like this:

void swap(int &a, int &b) {
    // using bitwise XOR because it's faster. 
    a = a ^ b;
    b = a ^ b;
    a = a ^ b;
}

The function name and the comment explain what is going on and it can still be clever.

The problem with "clever" code only comes about when it's poorly described. But that's a problem with non-clever code as well.

[-]

WoodyTheWorker@reddit

It's not even faster

[-]

GeckoOBac@reddit

The problem with "clever" code only comes about when it's poorly described.

I disagree here. Because this is a working example.

The assumption here is that the clever code is in NEED of debugging. NOW you have an issue, and the comments don't necessarily help.

Do they describe accurately what the code IS doing? What it SHOULD do? And which one is the desired outcome? And if I'm not familiar with the "clever trick", how do I fix it, even assuming that the comments are of any help?

Sure I can understand the "cleverness" where extreme performance is needed, but otherwise? I'd rather have something clear, simple and possibly even less performant (as long as the impact isn't huge), than an unwieldy monstrosity that I will have to wrangle until the end of the eternity.

[-]

tonymet@reddit

But once you know it it’s more readable

[-]

DearChickPeas@reddit

Readibility is king

[-]

bwainfweeze@reddit

I’ve done a shit tom of debugging and I’ve done a lot of pair debugging. I have a little coach in my head that watches where I stumble and takes notes.

Every time a block of code contains a bug, people will spend time looking at every code smell in that block trying to discern if it’s the source. It’s a constant tax on every new feature, bug fix, and exploratory triage.

Thats why people are shitty to you about your code smells and clever code. It’s not OVD, it’s not aesthetics. It’s wear and tear.

[-]

coderemover@reddit

This is really clever. And the most readable.

(a, b) = (b, a)

:P

[-]

germansnowman@reddit

One example is a single statement that uses several chained map/filter/reduce functions, instead of putting the result of each into intermediate variables, or even using a more traditional for loop. Clarity is preferable over conciseness and performance if the latter is not critical.

[-]

Void_mgn@reddit

Nah correctly structured filter chains are the best way to express operations on streams...bad examples would be hacked in side effects into the stages that change external state to "improve performance"

[-]

ub3rh4x0rz@reddit

Depends on the language. If js for example, it's both inefficient and harder to debug without deconstruction because each step sees all the values before the next step. If it actually produces a pipeline that individual values go through one at a time, like in rust, it's fine.

Source: reformed map/filter/reduce junkie. Sometimes a short procedural loop is just what the doctor ordered

[-]

Void_mgn@reddit

JS does have a very unfortunate implementation that's for sure. Async/await is another problem that makes a proper stream pipeline implementation difficult for it

[-]

ub3rh4x0rz@reddit

Re async/await, if youre referring to uncaught rejections, that's just a quirk of the js runtimes' eager promise execution, and isn't specific to using async functions in array processing methods. You can mitigate it by including try/catch in your async functions

[-]

Void_mgn@reddit

You won't be able to use Async functions in any of the Js array methods unless you are working with an array of promises. I've seen it come up a few times causes some nasty bugs but ya just one of the trade offs of the await pattern

[-]

ub3rh4x0rz@reddit

Well yes, you would indeed be working with an array of promises. You still need to do what I described to avoid leaking unhandled rejections

[-]

Void_mgn@reddit

Well for filter it just doesn't work at all https://stackoverflow.com/questions/47095019/how-to-use-array-prototype-filter-with-async

And same with forEach...map can work but I've seen people do stuff like map over Async then expect that it has awaited then do other stuff before handing back the array with promises that did not yet complete. It's a mess tbh

[-]

ub3rh4x0rz@reddit

True only mapping really makes sense

[-]

RedditNotFreeSpeech@reddit

Variable pollution. Just format it with each chain on a line

[-]

germansnowman@reddit

I wouldn’t call it that, I think that’s a bit harsh. I agree on the formatting though, that definitely helps readability.

[-]

RedditNotFreeSpeech@reddit

It's not meant to be harsh. It's just a bunch of unnecessary variables. Drives me nuts when I see it.

[-]

germansnowman@reddit

Fair enough, to each their own.

[-]

RedditNotFreeSpeech@reddit

Let me be more specific as to why. If it's a variable, I now have to search through the code and see if it's used elsewhere. If it's a chain I know exactly where it's scoped and what lines are using it.

[-]

Mognakor@reddit

Sounds like your methods are too big.

[-]

RedditNotFreeSpeech@reddit

They are. It's a fortune 500 legacy codebase. A lot of cruft.

[-]

germansnowman@reddit

The first problem is easily solved for me by placing the text cursor into it – my IDE highlights all occurrences of this variable in the current scope. Also, the scope is usually quite small.

I find this kind of slightly more verbose and explicit code easier to understand once it has gone out of working memory (i. e. after a couple of days). At the very least, the result should have a descriptive name and, if necessary, a comment should explain what is going on if it is not a commonplace occurrence.

[-]

RedditNotFreeSpeech@reddit

In a code review, I now have to assess it's terribly named unnecessary variables and give a better naming suggestion. It just slows things down and makes me grumpy.

But I do always make suggestions to chain optional changes

[-]

yxhuvud@reddit

Huh, I find the chained maps and filters a lot more understandable than putting stuff in a for loop. Probably cause I think about the collection operations in those terms.

But just don't do it in python - list comprehensions have inside out reading order so nesting them is a quick way to insanity.

[-]

sammymammy2@reddit

How well are those chains integrated with your debugger btw? As in, is it easy to break between each op and check the intermediate result?

I'm thinking that things like stream fusion would make inspection difficult (I guess you can disable it with a debug build???).

[-]

ZorbaTHut@reddit

I will say that I don't think this is a huge deal; it's pretty easy to split something like that apart into variables to inspect it in more detail if you need to, and some debuggers even let you run parts of it manually in the debugger to aid in inspection. "Debuggable code" is not necessarily "code that's already broken up to make debugging easy", I'd actually prefer "code that is simple and easy to understand", trusting the programmer to be able to do whatever manipulations they need for debugging.

[-]

sammymammy2@reddit

Man, fuck C++ and its build times.´, it really contorts how you think about this kind of stuff.

[-]

ZorbaTHut@reddit

Honestly, I've done maybe half my career in C++, and most of the time the debugging changes you need to make are limited to a single .cpp which really isn't that bad.

. . . the fundamental header changes are a nightmare though. I worked at one company that kept horribly underprovisioning hardware for its workers, and changing one of the core headers was like a 4-hour build for half the company. I was a contractor and made sure I had good hardware and could do a full build in like 20 minutes, but a few times I literally had a bugfix rejected - not that implementation of the fix, but the entire concept of fixing the bug - because it would require too much build time.

Absolutely bizarre priorities there.

[-]

yxhuvud@reddit

I don't use a debugger. I use tests and print statements. Adding a print statement is as easy as adding another chain: .tap { p it }

[-]

Steveharwell1@reddit

For those that aren't super familiar with tap or can't add that to their collections. Here is a JS version using map.

const result = arr.map((a) => {
  console.log(a);
  return a;
  });

[-]

germansnowman@reddit

I guess I’m old-school enough to still have to look up every time what these operations do. (It differs of course between languages.) I prefer the explicit manipulation of data over “magical” black-box operations. I am getting used to them of course, but in moderation :)

[-]

floriv1999@reddit

It is just functional programming which itself is pretty old-school.

[-]

germansnowman@reddit

I know. I should have clarified that it wasn’t a thing in the languages I grew up with and which formed my initial habits: BASIC in the early 1990s, then TurboPascal, C, even Objective-C until Apple added these as collection methods.

[-]

floriv1999@reddit

Okay fair. Otherwise I would have bin impressed by you career, as e.g lisp has been around since the 50s.

[-]

ltouroumov@reddit

It depends on the language. In Scala, the default way to manipulate collections is to use map or flatMap.

The for(n <- coll) {...} syntax, which is a more traditional for-loop is actually compiled to a call to coll.foreach { n => ... } under the hood.

The more common use of the for construct is to manipulate monadic containers like Option or Either.

Example:

for {
  a <- findUser(...)
  b <- findProfile(a)
  c <- computeStatus(a)
} yield Response(profile=b, isOnline=c.isOnline)

The nice thing is that it works with any container that supports map and flatMap, which includes Future<T> for async operations. Libraries can also take advantage of this. The IO type from Cats also conforms to the "interface" and so it can be used in the same way.

[-]

oscarolim@reddit

Something like

return c1 ? v1 : (c2 ? v2 : (c3 ? v3 : v4))

[-]

rcfox@reddit

That's just a formatting issue.

c1 ? v1 :
c2 ? v2 :
c3 ? v3 :
v4

[-]

oscarolim@reddit

I’ve never seen it format that way, and I’ve seen a lot of code, and you could of course add a few dozen additional conditions.

In the end a case would be much more readable.

[-]

ShinyHappyREM@reddit

A case wouldn't express the same logic, unless you encode c1+c2+c3 in an integer. (But then you'd have to write out more cases.)

[-]

Magneon@reddit

Some languages support switch case using non-integers (golang for example), and even more broad pattern matching (rust match).

[-]

jangxx@reddit

In JS and TS you can do something cursed like

switch (true) {
  case c1: return v1;
  case c2: return v2;
  case c3: return v3;
  default: return v4;
}

not that I would recommend ever doing that though, especially considering the thread we're in.

[-]

oscarolim@reddit

c1 to 3 are not integers. They are Boolean conditions. Condition 1, condition 2, value 1, value 2, etc. was just shortening as pseudo code.

[-]

syklemil@reddit

I'm sometimes tempted to replace an if-else chain with something like

fn main() {
    match () {
        () if foo() => println!("foo"),
        () if bar() => println!("bar"),
        () if baz() => println!("baz"),
        () => println!("fizzbuzz"),
    }
}

but I have, so far, been able to resist that temptation.

Explanation: >!The match () matches on the unit type, (), which only ever has one member, (), which acts as the default/fallback case. The rest of it is just using guards on a match to simulate the ternary layout, effectively turning the match statement into something similar to a cond from Lisp.!<

If I ever were to do it, I think I might as well add some formatting rules to make it look as much as possible as syntactic mystery rather than match & unit type abuse.

[-]

AlSweigart@reddit

Here's even better formatting:

if c1:
    return v1
elif c2:
    return v2
elif c3:
    return v3
else:
    return v4

[-]

syklemil@reddit

Given that the original post here mentions Laravel, it's also somewhat of a language issue. Some languages just get ternaries wrong, and PHP is one of them.

[-]

Nanobot@reddit

PHP originally got ternaries wrong, which is why unparenthesized ternary chaining became deprecated in PHP 7.4 and removed in PHP 8, so that the behavior can be changed in the next major version.

[-]

Mysterious-Rent7233@reddit

If your code will be confusing as soon as a formatter touches it, you should rewrite it. Most teams run code formatters.

[-]

rcfox@reddit

It is an unorthodox formatting. Most people see the ternary operator as a way to cram an if statement into one line. But if you do end up needing a line break, maybe this should become to proper way to format it. It's certainly much more useful than what Prettier will currently give you:

  const x = c1
    ? v1
    : c2
      ? v2
      : c3
        ? v3
        : c4
          ? v4
          : c5
            ? v5
            : v6;

On the other hand, I'm not really sure if we should encourage people to create large ternary structures. It kinda looks like a switch statement, but each condition is executed in sequence until a match is found. It might accidentally mislead people about the flow of execution.

[-]

jasminUwU6@reddit

I've never seen it formatted like that, it looks nice

[-]

colei_canis@reddit

What’s worse is which such code is actually necessary (because a critical upstream service is run by total clowns for example), it’s horrible to debug and unlike other ‘clever’ code you can never really improve it.

[-]

shawncplus@reddit

People confuse clever and elegant. An elegant solution is always desirable because it's usually the least amount of work and/or easiest to reason about solution to a problem. A clever solution is usually arrived at by trying to trick the programming gods into doing what you want but as any DM will tell you any puzzle you come up with will be orders of magnitude harder to solve such that sometimes even children's puzzles seem like the engima code without prior context.

[-]

bwainfweeze@reddit

90% of the people who I ever worked with who liked the word elegant were architectural astronauts who made everyone else’s life a living hell for their own gain. That word is 🚩🚩🚩🚩🚩🚩🚩

[-]

shawncplus@reddit

People that read the gang of four and vomit design patterns are exactly the type of people I'm describing when I say people confuse clever and elegant. You don't need a FacadeFunctorBridgeFactory and anyone that describes it as elegant is probably hanging over the cliff of their own expertise Wile E Coyote style

[-]

bwainfweeze@reddit

Fucking GoF.

Did you know that book was supposed to be a master's thesis? Written by the guy with by far the least experience. The rest were basically reviewers.

[-]

imp0ppable@reddit

Well, I have seen code that once I worked out what it was doing I thought it was beautiful and elegant (probably faster than what I would have done to boot) but it still took me an hour of sweating to figure it out.

[-]

bwainfweeze@reddit

And in six months you’ll have to unpack it again, unless you refactor it right now.

[-]

imp0ppable@reddit

I feel like judicious use of comments is an option

[-]

bwainfweeze@reddit

I mean yeah but if it took you an hour to unpack it... The comments will only go so far.

[-]

ikeif@reddit

It reminds me of code exercises where you can find the "smallest amount of code" to accomplish the task.

It's insanely clever, but often damn-near indecipherable.

[-]

GammaGargoyle@reddit

It doesn’t actually matter how well thought out a solution is either. What matters is that it’s maintainable and extensible. You can have an over-engineered solution that was well thought out but a pain in the ass to work on.

[-]

Theemuts@reddit

You can have an over-engineered solution that was well thought out but a pain in the ass to work on.

i.e. a clever solution...

[-]

Fidodo@reddit

The dictionary definition for clever is not "well thought out". I have no idea where the commenter got that from. The dictionary definition is "marked by wit or ingenuity", which is the same usage as in programming. Witty and ingenious solutions are non-obvious which makes them hard to debug.

[-]

ClownPFart@reddit

That's your subjective interpretation. Mine is that whoever wrote that felt humbled by code they couldn't understand and decided that writing such code is universally a bad thing.

[-]

Dizzy_Response1485@reddit

It's always the ternary operator

[-]

euvie@reddit

A lot of times, overly “clever” is optimizing code length at the expense of readability or hiding complexity behind metaprogramming or lesser-used language features. Really, the opposite of quick hacks since it often takes more time to carefully craft such systems…

It’s the primary reason many C++ style guides heavily restrict or even ban templates and operator overloading, to name two favorite language features of clever programmers.

[-]

cake-day-on-feb-29@reddit

A lot of times, overly “clever” is optimizing the length of code

It's like they think a regular project is a code-golf challenge. Maybe misguided by some idea that less code = faster.

[-]

Wandering_Melmoth@reddit

Well, less code = less places to debug and look for issues.

[-]

Uristqwerty@reddit

Clarity is multidimensional. You can have code where every statement is perfectly clear in isolation, but the business logic it implements is buried, and the algorithm by which it does so is unrecognizable. Or maybe you have something written tersely, where you can recognize the algorithm from its overall structure, but need to have a printout of the accompanying paper it was first presented in to understand what the variable "pi" means (hint: it's not the well-known constant; it's an unrelated thing that happens to start with "P", because within the bounds of the paper, its author shortened it to a single greek letter.)

Maximizing one axis of clarity is easy. Figuring out something that clearly expresses the code on every level simultaneously, though? Sometimes the obvious solution introduces unnecessary complexity. So what would you call something where, when you see the answer the whole thing's instantly obvious, but you wouldn't have figured it out on your own? I'd say that is a form of clever by definition, albeit one that doesn't carry the usual drawbacks.

[-]

Fidodo@reddit

"Clever" is a very commonly used term in programming. It means code that most people wouldn't think of which means it's non-obvious.

Even in non programming terms, I've never heard of clever used as "well thought out". The dictionary definition for describing a thing as opposed to a person is "marked by wit or ingenuity". Both wit and ingenuity mean things that are non obvious and non simple.

Clever doesn't mean the code is hacky, it means it's so smart that most people wouldn't think of it off the top of their heads, which in programming is a bad thing.

[-]

PaintItPurple@reddit

It's neither. "Clever" is similar to "show-offish." Rather than putting your intelligence toward constructing code in a way that will read as natural and obvious, you're instead thinking about what tricks you could employ to get it done in fewer lines or with some unnecessary degree of flexibility, so that people will say, "Oh, that's clever."

[-]

Mysterious-Rent7233@reddit

Or am I confusing "clever" with "well thought out".... and what is "clever" is actually just "quick hacks" that worked in the moment?

"Clever" means "non-obvious." Tesla door handles are "clever".

[-]

PressWearsARedDress@reddit

That is a good explaination, thank you.

[-]

Numerous-Mine-287@reddit

I take “clever” in this context as meaning over-optimised. Trying to look smart by doing some pointer arithmetic mixed with bitwise operators, etc.

Those are super hard to debug… and the compiler might have applied the same optimisations from “clean” code anyway.

[-]

ub3rh4x0rz@reddit

Length is one example, but in general I'd say "optimized for the wrong thing". Hot code paths can rightly be contorted into some inscrutable code, other places should be optimized for readability and maintainability

[-]

Downtown_Category163@reddit

"Well thought out" means you can see what it is at a glance

"Clever" means you need to decipher it like you're Columbo

[-]

ClownPFart@reddit

"Clever" means "code i dont understand"

[-]

neriad200@reddit

can confirm. life has pushed me mostly into support or maintenance type roles where I see and debug alot of other people's code. after a while the coat and cigar simply manifest on you.. I don't even like cigars ..

[-]

SnugglyCoderGuy@reddit

Clever code is code that tries to do a million things in a few lines of code

[-]

NotSkyve@reddit

Clever usually refers to "it works but we don't understand why/how". So yeah, well thought out is usually not the case when we refer to it in this way.

[-]

corny_horse@reddit

Clever is just a synonym for regex in this case. /s. Or not /s maybe.

[-]

aint_exactly_plan_a@reddit

Not even necessarily quick hacks... I know people at work that try to fit as many tables as they can into a SQL query. They know the schema and SQL so well that they try to just do everything at once.

Until they are missing data or have extra data. Then trying to figure out how to add or subtract rows or tables without breaking the whole mess takes forever.

"Clever" code is usually quicker to write but harder to read, and takes MUCH longer to troubleshoot or maintain. If you spend a little extra time documenting the code and making sure it's easy to read and troubleshoot, you'll save time overall when bugs start rolling in, or when the customer wants to add something or take something out.

[-]

pimuon@reddit

Clever means making use of advanced features just to show that you can.
Or creating much more abstraction than required for the problem at hand.
Making it hard to see how things really work, hidden behind layers of abstraction.

[-]

omgFWTbear@reddit

Neither.

It’s from 50 years ago, so it may be difficult to imagine where “don’t reinvent the wheel,” isn’t really helpful advice, and so you may have cause as an everyday developer to write your own fundamental algorithm implementation.

In which case, given a choice between a straightforward algorithm - say, for sort - iterate over list, compare each step, swap if smaller, repeat - and a complicated one that I think I understand, I should choose the former, because if I make a mistake in implementing the latter, since I don’t actually understand the behavior, I can’t spot the mistake.

[-]

yxhuvud@reddit

A clever solution is one you need high IQ to write and to understand. A well thought out solution is one a brick could understand.

[-]

Historical_Cook_1664@reddit

i always think of "clever" as "you need to be smart to think of it, but you also need to be lucky it actually worked..."

[-]

atomic1fire@reddit

Isn't this just similar to the idea that it's better to write for the dumbest person in the room because then you know that everyone can understand it?

[-]

LessonStudio@reddit

I emphatically disagree. Often, by writing the most clever code you've ever written, you have become a better programmer.

Also, truly clever code should inherently be far less prone to bugs, and by design, easy to test and debug.

Most clever code does one of 3 things:

Reduce or prevent tech debt
Replace some convoluted buggy pile of existing crap
Increase performance, which is of some large value. In this last, by increasing value drastically, even if it is going to be buggy, and hard to debug, this is why they pay us. To create value. Ideally, value creating clever code covers my first two as well as increasing value through higher performance. Often it takes truly clever code to achieve the required performance at all. That is, without it, the feature would either suck, or have to be cut. Performance could be speed, or reducing some other resource requirement.

On this last, this is where a huge amount of ML libraries are glorious. Some start out as giant resource hogs; yet still provide immense value; then someone even more clever reduces those resource requirements.

Not always. Pretty typical modern ML which might require at least a gaming laptop would require a supercomputer cluster 10 years ago.

[-]

tony_bologna@reddit

/sigh

You all are really hung up on the word "clever", and desperate to find exceptions to the rule ("law").

When he says "clever" he means needlessly complex! Good lord people, you just find yourselves a semantics related bone and won't let it go.

[-]

LessonStudio@reddit

Some people's valuable clever is other peoples needlessly clever.

I've had long unresolved arguments that most microservices are needlessly complex. Those people obviously disagree.

This is not a black and white issue.

[-]

tony_bologna@reddit

Maybe you can have a debate about diction with Brian Kernighan then.

[-]

archiminos@reddit

I once got told that my design for a UI system wasn't good because it wasn't complicated enough. Like, keeping it simple and easy to use was the whole point of the design.

[-]

tony_bologna@reddit

Lol, if it isn't intuitive, then you have to explain it - which is a bummer.

I wonder of that person has ever heard of Google, or Apple, and their never ending quest to eliminate all "unnecessary" controls.

[-]

thirachil@reddit

Debugging is what prevents machines from taking over. But it is scary how fast they are learning.

[-]

Plank_With_A_Nail_In@reddit

I think we need to define exactly what we mean by "clever" in this context.

[-]

tony_bologna@reddit

Sounds like a task you're more than capable of taking on yourself. Behold, a cursory glance at a google search:

Kernighan's Law makes the argument that simple code is to be preferred over complex code, because debugging any issues that arise in complex code may be costly or even infeasible.

Better?

[-]

usernamedottxt@reddit

Wrote a recursive poker pot solver that was super clever. Handled arbitrary numbers of side pots in the recursion tree. Then an edge case happened. Fixing a recursive solver for an edge case is tough. Then another edge case. Then a third. It worked.

Then a buddy joined the project, looked at my recursive solver, and quit the project lol.

Fourth edge case was identified and we just re-wrote it. Now it works and is clean and easily debugged. And auditable, which is also really hard to do in recursive trees.

[-]

LordAlfrey@reddit

That's assuming that things like AI and search engines don't exist, I suppose.

It also takes 'clever' to mean 'convoluted'. Cleverly written code can be clever due to how readable it is.

[-]

tony_bologna@reddit

https://www.reddit.com/r/programming/comments/1n687q0/comment/nbyu2mb/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button

[-]

LordAlfrey@reddit

Fair enough

[-]

arpan3t@reddit

Imagine trying to “gotcha” Brian Kernighan lmao.

[-]

LordAlfrey@reddit

I mean, feel free to tell me what's wrong with what I write, that very much is the point of saying things on the internet.

[-]

arpan3t@reddit

Ask an ai search engine

[-]

LordAlfrey@reddit

If I wanted to, I would have. Instead I wrote a comment on reddit.

[-]

ClownPFart@reddit

This is an extremely stupid "law". It’s a law against trying to learn and trying to push outside of your comfort zone.

Sticking with what’s safe is good in a professionnal setting, but when doing things as a hobby there is nothing wrong with pushing things to the limits of your understanding and then try to make it work anyway.

[-]

tony_bologna@reddit

You're definitely missing the point.

Try replacing "clever" with "novel" (as in "new or unusual in an interesting way"), maybe that'll get you to the correct understanding.

[-]

quuxl@reddit

Clearly Kernighan was an OO programmer

[-]

Maybe-monad@reddit

That only makes sense if by clever code you mean C code that makes heavy use of macros and ternaries.

[-]

HenkPoley@reddit

/me waves at Laravel’s “Facade” implementation.

[-]

zendarr@reddit

I think he worked with some people I know 😝

[-]

frnzprf@reddit

So you're programming more cleverly if you program less cleverly? Then more clever code would me less clever code, would be more clever code, would be less clever code, ...

I'd call it "optimized for debugging" vs "optimized for performance" or for something else.

I haven't read the article yet — and I will do it — but I assume "being friends with the compiler" and making use of the appropriate abstractions and language features makes code more readable as well as more performant.

[-]

Icy_Foundation3534@reddit

those are some bars preach

[-]

thepeopleseason@reddit

As an engineer who once made a seven line regular expression to "solve" a problem and then had to maintain the code, I can only wholeheartedly agree with Otwell.

[-]

lookmeat@reddit

I once did do a 7 line regex. Though in my defense it was a relatively simple regex: about 150 characters, and using only simple features. But I split it up into substrings for each sub group and added a comment explaining what part of what we were parsing it covered.

And yeah, a single regex was needed, because this was on a part that could block the whole thing so it needed to be fast, also the same reason I used simpler features: I could ensure that no backtracking would be needed.

[-]

this_is_a_long_nickn@reddit

Mandatory joke:

You have a problem. You tell yourself, I’ll solve it with a regex. Now you have 2 problems.

[-]

lelanthran@reddit

You have a problem. You tell yourself, I’ll solve it with a regex. Now you have 2 problems.

Many modern takes on this

You have a problem. You decide to use an ORM. Now you have n+1 problems.

You have a problem. You decide to use an AI. Now You're Absolutely Right!

You have a problem. You decide to use React. Now your your problem has 1000 dependencies.

You have a problem. You decide to use MongoDB. Now you have a ¯_(ツ)_/¯ problem.

You have a problem. You decide to use AWS. Now you have a problem and a $10,000/m bill.

:-)

[-]

Seeveen@reddit

You have a problem. You decide to use threads. Have problem you now a.

[-]

ggppjj@reddit

Now you have punchlines arriving before the setup. You decide to use UDP. You have a problem.

[-]

MrDilbert@reddit

I'd tell you a UDP joke, but you might not get it...

[-]

HaykoKoryun@reddit

So Yoda was just multi-threading his speech.

[-]

thepeopleseason@reddit

Really feeling that last AWS one...

[-]

levelstar01@reddit

You tell yourself, I’ll solve it with a regex. Now you have 2 problems.

Better alternation: Now you have 2) problems.

[-]

lookmeat@reddit

Fair, I had it in my comments too.

[-]

GaboureySidibe@reddit

150 characters is a simple regex?

This is where people get themselves into trouble. If something is split up into multiple separate statements then you can look at the intermediate data and debug it.

If you get 'clever' and combine a bunch of stuff into a one liner it gets much more difficult to debug because you can't see into it and can't narrow down the problem without trial and error.

[-]

lookmeat@reddit

150 characters is a simple regex?

I did use "relatively", as in "relatively simple given it was spread over 7 lines".

Also it's not that hard to get to a regex that long, if there's long key words that need to be considered. And if you want to avoid being too clever, you get repetitive. Regex is one of those areas where it becomes clear that DRY means "don't repeat your definitions" rather than "don't repeat code or code patterns", you want to have that.

If you get 'clever' and combine a bunch of stuff into a one liner it gets much more difficult to debug because you can't see into it and can't narrow down the problem without trial and error.

Debugging regex requires specialized tools (at least I recommend that). I also had a lot of tests validating the regex itself.

But you are right, a one-liner with a 150 character regex is a lot, but that's why I split it up and added comments on it.

I also made an effort in not being clever. I could have hand-rolled my own parser, or I could have used a more complex lexer and then parsed the tokens, but trying to keep that fast, while efficient, was going to be a challenge.

Notice that I said "simple 150-characters" because this are two orthogonal issues. You can haver a very long, but very easy to understand regex (e.g. we-first-match-this-whole-string-straight-forward-[\d]*) and very complex but otherwise short and terse regexes.

[-]

FlyingRhenquest@reddit

I once took a coding challenge for a internal position at a company I worked in. Dude wanted a program that counted lines of code in C. I wrote the code in C using Lex (Well, Gnu Flex, basically same difference) went over the possible corner cases -- another comment delimiter inside comments, lines split with backslash, semi-colin delimiters in for loops, multi-line strings, string concatenation across multiple lines, that sort of thing.)

It's really not that hard in Lex and I spent maybe a couple hours putting it together. A couple weeks later the manager told me I was the only one who didn't use regexes, my code was the only one that gave the right answer for all his tests and that I was overqualified for the position.

[-]

frenchchevalierblanc@reddit

you were too smart for the boss..

[-]

granadesnhorseshoes@reddit

See though, that sounds like dealing with required complexity with class. You already knew what you were doing was gonna suck and took mitigating steps.

Stay classy.

[-]

lookmeat@reddit

Oh yeah, I did regex because it was simpler than building an actual parser. My point is that sometimes you will write monsters, but it doesn't mean it's complex code, sometimes that just the simplest solution.

[-]

a1454a@reddit

Same. I now aim to write the most boring and predictable code possible that meets the requirements of the ticket.

[-]

bizarre_coincidence@reddit

Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems.

[-]

light-triad@reddit

Could you really not break it into a union of smaller regular expressions? I’m realizing that the term “clever devs” often refers to people who are clever enough to solve complex problems without applying sufficient software engineering principles to make the maintainable.

[-]

thepeopleseason@reddit

Yes, I could have broken it up. I don't remember the full context (it was about 18 years ago), but I thought by cleverly running a single regex, the result would be more performant.

[-]

Chii@reddit

tbh, large regex'es are fine, but only if you also wrote out what the regex is attempting to do in a comment (and/or break it out into individual chunks and document them).

The issue with regex'es are that they tend to just be a blob with no explanation of why or how it's supposed to work (and often, the intention is not exposed either).

A common bad practise is to regex out some subset of a pattern, but excludes one or two that would've also fit (but is inextricably not in the regex, and not mentioned why). Is it intentionally so? Or just an omission and error?

[-]

Tyg13@reddit

Just say regexes. There's no need for an apostrophe there.

[-]

DrShocker@reddit

Commenting the intent can be tricky since if something is NOT intended but becomes relied upon in the future, there's no way to actually document that since you're unaware of it. Sure, ideally that doesn't happen, but we know what happens in real life.

[-]

PrimozDelux@reddit

Knowing that the intent of the code does not match current use is so useful during a refactor

[-]

DrShocker@reddit

That's true, I'm often left trying to decipher what mistake was made based on someone's likely intent without anything other than the code itself to guide me which can be annoying.

[-]

mark_b@reddit

Better than a comment would be to put the regex into a constant and write tests demonstrating what it does and doesn't support, including edge cases.

[-]

DrShocker@reddit

In my opinion you more or less need fuzz testing to explore states you didn't consider. The issue with regexes is more often the conditions we didn't think of rather than the ones we did.

[-]

oorza@reddit

If it's large enough that you need 7 lines of regular expressions and it's parsed often enough you need care about parse performance, just write a damn parser lol

I feel like writing a grammar and turning it into a parser and using said parser should be something that more people reach for more often. It's not terribly difficult to learn and solves a number of common problems where the often accepted solutions, such as regular expressions, are hiding big foot cannons.

[-]

PeachScary413@reddit

Or you know.. just use a parser combinator and avoid the regex hell?

[-]

andrewsmd87@reddit

I need a very specific use case, as well as well defined metrics that aren't foreseeably going to change over time, before I will pass a regex in code review. I feel like I've dealt with so many more problems from them, than benefited from things they've "solved"

[-]

usernamedottxt@reddit

Regex is write only anyway. I “maintain” my regex by rewriting them from scratch whenever the previous one stopped working.

[-]

campbellm@reddit

You absolute monster.

[-]

thepeopleseason@reddit

I mean, I did it to myself...

[-]

campbellm@reddit

Without giving out any IP, what kind of problem was this, if you don't mind saying?

[-]

thepeopleseason@reddit

Parsing radio automation software output to generate Radio Data System displays.

[-]

gajarga@reddit

"Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems."

[-]

Shaper_pmp@reddit

I inherited a codebase written by rabid FP/Ramda fanboys.

A senior dev on my team and I (lead) once spent half an hour unpicking an 11-line Ramda pipeline to discover it was a simple four-line if/else clause checking a single value... so we replaced it with that.

The downside is we didn't get to rub ourselves off over how clever we were, but the upside was that even the junior devs on the tab could immediately understand what it was doing, and it didn't have any bugs in it.

[-]

hkric41six@reddit

Regex is exactly everything wrong with the industry and programming in general.

[-]

idebugthusiexist@reddit

I always follow the principle that you should write your code as if the next person who was to work with it is an axe murderer with a short tempter. Or, to put it another way, write your code such that it doesn't require comments to document what it is doing.

[-]

linuxwes@reddit

Weird, Laravel feels far too "clever" to me. It's nice when it works, but trying to debug what is going on when you have a problem sucks.

[-]

Lewke@reddit

dont get me started on trying to find anything in the api docs, half the classes have 10 traits and 300 proper functions

it's a shit show, and the regular documentation is pretty bad at anything that isn't the most cookie cutter shit

[-]

OnionsAbound@reddit

Me struggling for two hours to define a damn PUT route

[-]

november512@reddit

Yeah, it always feels to me like there's an obvious way that these servers should be structured. There's a spot where you bootstrap everything, there's a part where you register endpoints, etc. These frameworks obfuscate that and it's fine when the magic works but if it isn't doing what you want it becomes a lot harder to figure it out.

[-]

FlyingRhenquest@reddit

I feel that way about Rails too. It always felt to me like it was pretty easy to do fairly trivial things but if you needed something out of the ordinary you'd quickly end up needing to know implementation-level details about the platform. To be fair, my pain threshold was significantly lowered because most of the projects I had to work with it on were inherited by someone who wanted to be "clever." I took over one project from a guy who was building and evaling strings in active record code to change the name of a database. He had a couple hundred line long string to do something that was trivial to do with the platform. I ended up throwing all of his code out as soon as a feature came along that would have required more time digging through his bullshit than it took to write it all from scratch.

[-]

tj-horner@reddit

I did really find it funny that the criticism was expressed on a podcast by a Rails consultancy firm. Ruby and Rails are well-known for their clever "magic" solutions that obfuscate real implementations behind several layers of indirection.

[-]

rusl1@reddit

I would never say that about Rails honestly. It's pretty easy to customize it and use tour own configuration or libraries. In contrast, I recommend you to give a look to any Rust framework like actixweb or axum. They are complexity nightmares trying to be so smart that you need a PhD to write a Middleware for a controller

[-]

djipdjip@reddit

You should check out the Django code base, it's amazing.

[-]

BasicDesignAdvice@reddit

Django is just Laravel for Python. Tons of shit you don't need.

[-]

Herr_Gamer@reddit

"How to make user login with E-Mail instead of username" is a 10-step process adjusting 3 services and 10 multi-inherited, nested base classes. Wtf is up with Django.

[-]

BasicDesignAdvice@reddit

I feel that way about all these "frameworks."

Just write clear simple code. If there is a need to be complex, trap it in a crystal package and tuck it away behind its interface.

[-]

ZelphirKalt@reddit

Well, the title is nothing more than a clichee and the author "Taylor Otwell" has not achieved any wisdom in saying/writing that phrase. Basically, it is saying nothing without proper definition of "clever".

[-]

samplenull@reddit

Too much magic under the hood

[-]

stronghup@reddit (OP)

I think "clever code" comes in 3 variants:

Code that runs faster , but takes more time to understand.
Code that uses less memory , but takes more brain-cells to understand.
Code that takes fewer characters to type, but more head-scratches to understand

Of course sometimes you need to squeeze the most performance possible out of your code, or to make it run with less memory. But I think the 3rd variant is rarely useful.

[-]

SpikeV@reddit

Man's got an Article really telling programmers to KISS

[-]

shevy-java@reddit

Phew, he said clever devs. I can happily say that I don't belong to them!

The reason my code is outright stupid and simple is because for two reasons:

1) I regard code as an potential enemy so I must tame the best. 2) Also, my memory and brain isn't that good. That's why I write a lot of examples and documentation, because otherwise I forgot what I did a few months after; in particular when I did something stupid, which I do a lot, so I need comments to explain WHY I went that route. This is especially important when there are bugs; if the comment is not ancient, it is often true, so then the implementation must be wrong. (Would be interesting for a system that has comments be a working specification.)

[-]

One_Being7941@reddit

Beware Laravel.

[-]

zrooda@reddit

Clever devs can be scary but have you seen dumbass devs?

[-]

lunchmeat317@reddit

I see myself in the mirror every day, so yes.

[-]

BasicDesignAdvice@reddit

All devs are dumbasses except those who embrace their inner Grug.

[-]

ososalsosal@reddit

We need a good definition of "clever" because overly complex, unmaintainable but kinda neat tricks are right there in Dunning-Kruger territory.

[-]

chamomile-crumbs@reddit

I mean it’s a pretty thin line in some places. Higher order functions are “clever” in my book, since it takes a minute to figure out what they’re doing. But if you use them tactfully you can remove a ton of boilerplate and solve problems in really elegant ways without a lot of code

[-]

LessonStudio@reddit

There are two types of clever:

Raising the bar to places other devs didn't think were possible, or even conceive. Then, everyone is better and the skill level of most just went up a notch.
Too clever for their own good. We all know this one, and I think it is what this article covers.

My favourite example of the first is a guy who showed me that clever math can get you amazing algos. The right algo in the right place might see a 1000x or even 1,000,000 times increase in performance. Far better than the most clever use of SIMD, parallel, etc. I vastly increased my math chops continuously ever since.

My favourite example of bad clever is found non-stop in embedded programming as EEs from the 90s try to squeeze more out of some old decrepit but (in their words) "proven" MCU. One guy had a function which would allocate some variables at the start of a new function. This would go on the stack. The function would do things leaving those variables containing some values. Then, the function would exit, and another function would run, but not initialize its first handful of variables. The "uninitialized" memory would still have the values from the last function call, as that was stack, and could predictably be freed, and then allocated.

So, this second function would mysteriously have the desired values in an uninitialized variable.

Not even a comment mentioning this.

When I ran coverity on his code my computer grew legs and ran away. It wasn't only his clever crap which set off the alarms, but his crap crap, which also did.

He should have just named all his files: buffer_overrun_01.c buffer_overrun_01.c ...

[-]

TedditBlatherflag@reddit

Hard to maintain code is bad code, not clever code.

[-]

Dean_Roddey@reddit

One very powerful tool to fight this is for developers to run their own companies. When the buck stops with you, and it's going to be you having to move the code forward for years, and you who will be up at midnight on Saturday trying to figure out a bug, you quickly learn some important lessons. One of them is obviously keep it simple unless there is a very important reason not to.

[-]

kyru@reddit

Been saying this for years, I always told my students to make sure they weren't being clever for clever's sake or at least to document cleverness so someone 6 months from now doesn't have to boggles at what the code is doing.

Be clever in personal code, be straight forward and simple in everything else.

[-]

JackBlemming@reddit

Existing PHP frameworks were too Java-inspired, and Otwell wanted something with a built-in ORM (object-relational mapper) that offered more functionality out of the box.

Sounds like he doesn’t practice what he preaches. ORMs are pure poison.

[-]

Adohi-Tehga@reddit

I recently had this experience building a site in Laravel with the Twill CMS package. Followed their guide on making a simple site and everything looked okay. Then I added a couple of pages and discovered that not only are all relations lazy-loaded by default, but that walking up a tree structure recursively requests all the parents for the current node at each level... e.g. 3 levels deep, 3 identical sets of SQL queries for the root node executed by the ORM; each of which is is actually about 4 linked queries as slugs, translations, thumbnails etc are all separate relations...

After struggling to try and fix it in the ORM I ended up gutting out all the code and rewriting it as raw SQL queries. I don't really know Laravel very well (chose it as all our existing sites are written in it), so there could well be other ways of getting around the problem, but it felt very frustrating that the default way of doing things is so incredibly inefficient. After the amount of time I've wasted battling with the ORM and framework, it probably would have been quicker to write the few pieces of custom functionality as WordPress plugins.

[-]

AdvancedSandwiches@reddit

ORMs are useful when your codebase is tiny. At a certain point you'll outgrow it and ripping it out will be a 2-year endeavor.

I'd call it a premature optimization to avoid it, except it's really not all that helpful to begin with. Selecting the fields you want and passing them to a factory isn't exactly hard.

[-]

ARM_64@reddit

ORM's can make a mess of your codebase very quickly and the pattern honestly encourages you to do it that way.

[-]

ZirePhiinix@reddit

Why is an article written in 2025 referencing events in 2013 as if people are still going through it?

If you have been struggling with an upgrade for 12 years, you probably should move on.

[-]

tomato_rancher@reddit

I agree. And devs can be petty like that..

[-]

fubes2000@reddit

You've just made an enemy for life.

[-]

vplatt@reddit

But is he going on your mortal enemies for life list Sheldon?

[-]

HoratioWobble@reddit

If you have been struggling with an upgrade for 12 years, you probably should move on.

People are still citing that one article from 2012 about why you shouldn't use PHP. There are still lots of devs who live in the past

[-]

nexxai@reddit

The point wasn't that people are still upgrading apps from 12 years ago, it's that he learned a lesson 12 years ago and is still trying to apply that lesson to code he writes today.

The rewrite broke backwards compatibility, and the experience made him determined to avoid such breakage in future unless it is for something "incredibly important" that needs a fix.

Unless I'm reading that wrong, it just feels like he's really done his best to internalize that lesson of "don't make breaking changes unless absolutely necessary". I feel like that's generally a good thing, no?

Or maybe I'm reading that wrong

[-]

ZelphirKalt@reddit

Hm, seems like a bad learning. People need to be ready to accept that their code has to change sometimes, for the tool/library/framework they are building on top of to be able to drop old baggage that is holding it back. But this kind of fanatical backwards compatibility attitude is typical for the PHP ecosystem, a language, that has been held back for many years by its stewards.

As long as breaking backwards compatibility leads to a major version change and offers at least the same amount of flexibility, and doesn't make it impossible to do what you could do before, then it will generally be acceptable. Put a dev to work on porting the code base of your project, until you have a new version running in parallel based on the new version of the language/library/framework. It really shouldn't be too much magic. Unless of course you have built shit with all kinds of weird practices, that are all somehow crucial now that they are depended on by everything in the project. But that is the result of bad engineering, and the backwards compatibility breakage is not the one to blame.

[-]

iKindred@reddit

It's PHP did you expect anything different?

[-]

BlueGoliath@reddit

Can't wait for their next article on agile and scrum.

[-]

Regal_Kiwi@reddit

Agree with the title, the article has no actual content, avoid.

[-]

CircumspectCapybara@reddit

Cleverness feels good until you have to maintain it, or worse, someone else has to read what you wrote and maintain it.

I really like Google's approach to "readability" and the style guide that enforces uniform code style and principles. For example:

For C++, we ban use of template metaprogramming or defining new preprocessor macros unless there's a really good reason
In Kotlin, we ban overly clever use of scope functions when they make the subject unclear, e.g., nested use of scope functions, especially those that mix subjects / context receivers, because it makes it unclear what the context receiver or subject is by visual inspection

And many other style decisions that an overly clever developer might want to rebel against.

But the data has borne out the truth that code is read 1000x more often than it's written, by 1000 more people than the original person who wrote it, and when you're working in a team, and in teams of teams, and people have to maintain and evolve this code over time, probably for much longer than you'll be around, simplicity and uniformity is key. Everybody needs to "speak the same language," so to speak.

[-]

TankAway7756@reddit

Miss me with that.

Problems don't disappear by ignoring them. If your language is too simple, the complexity you've supposedly banished will come back in the form of patterns (which are convention-upheld language extensions where you -not a deterministic algorithm- are the compiler).

[-]

campbellm@reddit

If your language is too simple™, the complexity you've supposedly banished will come back in the form of patterns

I love this.

[-]

ZelphirKalt@reddit

For C++, we ban use of template metaprogramming or defining new preprocessor macros unless there's a really good reason

Haha, wow what an enlightened view! Basically, this says nothing, except that some group of people somewhere will decide whether it is OK.

[-]

haywire@reddit

Or you have to upgrade packages and your weird custom stuff means you…can’t.

[-]

Dyledion@reddit

This man advocates for PHP. His opinion can be dismissed out of hand.

(And don't you dare tell me that "oh, PHP's changed! It's different in the year 20XX, I swear!" No, it hasn't, not enough, no it isn't, and, yes, I spent two years working with PHP very recently, it ain't good.)

[-]

NotANiceCanadian@reddit

Only a bad dev calls a language bad.

PHP is fine. Hop off the bandwagon

[-]

Godd2@reddit

PHP is objectively bad, though.

[-]

oorza@reddit

I've literally never understood this argument. There are objective axes upon which tools can be measured. Of all of the ways to measure a programming language, PHP falls short in most of them.

It is possible to build great software with PHP. It's possible to build an entire mansion without power tools, too. You can achieve great things without using the best tools, that doesn't mean the tools were well suited to the task at hand. PHP has not been well suited for writing software since the era of the SPA dawned and all of the things it does best were no longer important.

[-]

lelanthran@reddit

There are objective axes upon which tools can be measured. Of all of the ways to measure a programming language, PHP falls short in most of them.

So does Javascript. And Ruby. And Python.

And yet, whether you (or I) like it or not, a significant percentage of development happens in those languages.

If the "objective metrics" aren't correlated to successful products, maybe they aren't so important after all.

[-]

Hacnar@reddit

But the objective metrics do correlate to successful products. It's just that vast majority of programmers doesn't care about them.

[-]

lelanthran@reddit

But the objective metrics do correlate to successful products. It's just that vast majority of programmers doesn't care about them.

I want to see the study where they determine the correlation; there are simply too many successful projects right now that are using Python/PHP/Ruby/Javascript for me to take the assertion of a correlation at face value.

[-]

oorza@reddit

PHP hasn't had a visibly successful project in more than a decade now. Ruby is almost as blasé in 2025 as PHP is. Python's shortcomings are well understood and herculean effort is being expended to lessen them. Javascript's shortcomings will never matter as long as it is better at running in the web browser than any other language.

One of the most important axes to measure a programming language on is ease of access. PHP won that handily in the halcyon days of cgi-bin scripts written with pre-C99 C. It was far and away the best option for the web in the PHP 3 days. The things that made it successful are no longer true, and it's no longer well suited for web development compared to the alternatives. That's not an absolute measure of its quality as a tool, but a relative one. But there was a time where it was the most accessible way to build websites users expected and do it quickly.

The same can be said of Rails, as most of the metaprogramming and patterns it introduced have been consumed by less cumbersome frameworks and languages. But there was a time where it was the most accessible way to build websites users expected and do it quickly.

Right now is arguably the time when JS/TS is the most accessible way to build websites users expect and do it quickly.

That single factor, in every case, outweighs everything else. It does not invalidate everything else, and as we can see with PHP and Ruby which are largely persisting on momentum built years ago, once removed, the language gradually drifts into the background.

All of this can be true and it's still a bad idea to migrate away from an existing PHP/RoR infrastructure, so those ecosystems will continue to persist as long as the businesses that rely on them.

[-]

lelanthran@reddit

Maybe your opinion is all true, but it sure is hard to believe something when there is no study linked.

My position is still "I want to see this study that established the correlation between your objective metrics (that PHP fails at) and successful products".

Long opinions, such as you posted, are rarely convincing.

[-]

Dyledion@reddit

No, a good dev demands more from their tools. PHP is fundamentally flawed and dangerous.

[-]

Fenix42@reddit

I spent 2+ years as QA at a PHP shop. It was the most miserable time I have had as QA. Most of that missery was because of the people. PHP just did not help the situation.

[-]

bludgeonerV@reddit

I hate PHP as well, but he's right on this point imo, I've long since abandoned the ethos of building clever abstractions, i look back on that kind of work as a bit of a dumning-kreuger phase.

I'd rather have verbose but simple code, and use language and framework features directly rather than special snowflake solutions. I used to live and breath Reflection and codegen, now i see it as an evil only to be used as a part resort.

[-]

TankAway7756@reddit

Codegen and runtime reflection are the opposite of clever. They're two manifestation of the design mistake of missing AST macros.

[-]

Iychee@reddit

Lol how is this a serious comment, we're really still doing the language wars?

Fwiw this would have been a funny joke comment.

[-]

lelanthran@reddit

Lol how is this a serious comment, we're really still doing the language wars?

Maybe we should ask GP what his take on Tabs vs Spaces is. Or Vim vs Emacs :-)

[-]

oofy-gang@reddit

Regardless your opinion of PHP, he is right about simplicity > complexity in software.

[-]

eightslipsandagully@reddit

Can you please inform the engineering leadership at my company?

[-]

picklestheyellowcat@reddit

This guy wrote one of the largest and most successful frameworks in use today along with a massive amount of infrastructure.

His framework is used by thousands of devs to build things.

You're a numpty making snide remarks about PHP which is a sure that you're probably not a very good programmer to start with.

His opinion holds far far more weight than yours ever will

[-]

Fenix42@reddit

Frameworked PHP is fine. It's the unframeworked early PHP that people still talk trash about. I worked at a shop where the core code was unframeworked PHP, and the main dev was learning PHP on the job. It was a complete mess.

It would have been a mess no matter the language, though. ;)

[-]

_Rook13@reddit

Ah yes, you should dismiss someone's opinion just because they're not using your beloved programming language. Fuck off.

[-]

RDOmega@reddit

As a former Laravel dev, I have utmost respect for Taylor. He's always had a keen eye for good design and tends to make the right calls. I learned a lot thanks to his efforts with Laravel and even though I've moved on to other ecosystems, I still hold it in high esteem.

[-]

hacksoncode@reddit

Enh... yes, but that's only because you have to make sure they aren't irresponsibly clever.

[-]

Mr_Splat@reddit

I haven't read the article but going by the comments am I safe in assuming this is another example of this adage?

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

[-]

hacksoncode@reddit

And the addendum: And because that guy will be you in 6 months.

[-]

HoratioWobble@reddit

I agree, but when i first used Laravel back in the early days I felt the very same about the creator of Laravel...

[-]

Sir_KnowItAll@reddit

The bro builds a framework that is not easily extendable and replaceable as others and blames others for the workarounds they have to make.

[-]

Maybe-monad@reddit

Blaming others is easier

[-]

AConcernedCoder@reddit

You have no idea of the lengths I'm willing to go to, or how low I can go to create for myself an edifice of weaponized complexity for the sake of my own job security. Yes. Beware.

[-]

Think-Memory6430@reddit

A tremendous opportunity to share one of my favorite posts, the grug brained developer - https://grugbrain.dev

[-]

Shaper_pmp@reddit

When it comes to code, "clever" is a four-letter word.

[-]

TedDallas@reddit

Code for maintenance and support-ability. Clever is rarely careful or thoughtful.

My younger self is guilty as hell.

[-]

poemehardbebe@reddit

There is nothing wrong with recursion, it’s just a tool and when it is the right job is great

[-]

FlyingRhenquest@reddit

I like recursion!. Works great as long as you don't make eye contact! I honestly don't think that code is even that horrifying to read, though it would probably be much more so if I hadn't commented it as much as I did. You do have to meditate very carefully about the intersection between compile time and run time, though. The stuff you can do with it once you do that kinda feels like sorcery.

[-]

NMe84@reddit

I can see why someone who invented or helped invent those gruesome facades Laravel uses would be wary of devs that are actually clever.

[-]

danikov@reddit

That's why I'm so good at programming: all I do is debug.

[-]

rag1987@reddit

Do: write code that someone who didn't write it (or, you in 6 months) can read and understand the intention not just the code itself.

Don't: write super awesome code that is actually far too convoluted and overly abstracted and takes a tonne of mental energy to understand and makes it hard for others when they do code review.

In a simplified way, when you have a choice favour the one that is easier to read and understand. Just because you can refactor those 5 lines down to 2 doesn't mean you should if it makes your code less readable.

That's my take anyway.

[-]

Akarastio@reddit

Often when you think to yourself: wow I’m so smart look at what I did, then it’s too complicated. 🥲

Many junior devs fall into that trap.

[-]

Bjorkbat@reddit

So, earlier today I was watching this video on how some devs managed to fit their game into 40kb so it can play on an NES cartridge (https://www.youtube.com/watch?v=ZWQ0591PAxM). It's only 12 minutes long, you should watch it, but the tl;dr is they used a shit-ton of "clever" solutions.

I would say I mostly agree with Taylor Otwell, but at the same time you see a ton of comments on how bloated software has become, and I can't help but wonder how much of that is because we've penalized cleverness.

[-]

oorza@reddit

we've penalized cleverness.

This isn't an inaccurate statement, but it's through a heavily distorted lens.

For a long time now, software has been the most important thing that gets engineered. For an even longer time, the bottleneck of software engineering has been human.

Stuff like "penalizing cleverness" can be reframed as "trying to optimize for human hours over the cumulative lifespan of a piece of software" in a much more fair way.

Your game devs weren't being clever, they were employing clever solutions to a limiting problem they had. There's a subtle distinction there, but "a limiting problem they had" is very important. Their limiting problem was not "we have way more software to write and maintain than man hours in which to do it" which is the default state for every software project until demonstrated otherwise.

[-]

omgFWTbear@reddit

limiting problem they had

This reminds me of another very zealot bound topic that I will dodge naming besides to say the original paper on the topic is likely older than anyone in this thread, and it included three suppositions to be true for allll the rest of the paper.

One of them was “supposing a machine that physically exists,” ie, no hypothetical infinite computers which may sound silly, but here and there in the paper this limit is relevant. The other two I’ll also dodge since they’re a bit of a give away, other than to say, for a long time no one ever actually wanted to build a system that didn’t suppose premise B. Until they did.

The NES cartridges had important considerations that aren’t standard for software - once you ship, that’s it: no one is ever reading that code again. There’s no version 2.

There’s also, an even by the standards of the day, an incredibly limited amount of space to work with. Nailing 95 Thesises on the wall of how you’ve written an impenetrable algorithm that does 5k of normal code in 1k of thicket is a trade off one makes.

The efficiency complaint is related but tangential, cf the GTA Online JSON unique filter disaster.

[-]

lordorwell7@reddit

This is only tangentially related, but the development of Myst is an interesting story for some of the same reasons.

[-]

cbusmatty@reddit

They have basically zero dependencies and are using sprites. This is like saying doom can run on a watch.

Bloat generally comes from abstractions or libraries. Yes I could build a more clever more succinct javalang library that I will now have to maintain in perpetuity, that no one will know why it’s built this way and is technically debt the second I install it.

There are times when clever is necessary, but obvious and deliberate code is the best solution for like 98% of things

[-]

joebloe156@reddit

But that's not clever for cleverness' sake. As someone who has had to try to squeeze games into tiny flip phones in the pre-smartphone era I also used clever tricks (including one trick that shaved one instruction off of the rasterizer that Abrash described in the quake engine, but only for a very narrow case for tiled terrain on the ngage) but I commented them thoroughly, knowing that if I didn't I'd have to spend energy re-solving the problem if a problem came up.

[-]

5tu@reddit

Nothing wrong with clever devs, ‘Show off devs’ using us ternary statements, multiple commands on one like or ego ones dismissing AI are the dangerously ones imho.

[-]

TankAway7756@reddit

The devs not outsourcing their brain to a word roulette being the dangerous ones is certainly a novel take.

[-]

bwainfweeze@reddit

Making the code into a giant DAG because they can. Mutually recursive functions are the hardest to debug.

I will say it's tricky being a young, clever coder without showing off.

The wisdom to make smart code with your cleverness instead of 'clever' code with your cleverness takes a lot of work. For me, my Second System Syndrome taught me a lot about how to steer your work into more socially acceptable outlets.

[-]

bennett-dev@reddit

"Beware clever devs", says creator of framework marketed to the not-clever ones

[-]

James_Jack_Hoffmann@reddit

Laravel's APIs are very well done which I'll give credit for, whether it be for the not-clever ones or the power users. But his cohorts and probably him too are not exactly people I would like working with. It's been a while since I worked with Laravel (8/9?), but having seen them with poor personalities in GitHub Issues really turned me off on the ecosystem. Locked and deleted PRs/issues, combative and poorly thought-out comments (which results in getting rained on by thumbs downs), and things I hear through the grapevine are just ick.

[-]

Dgc2002@reddit

He'd show up and lash out on r/PHP every few weeks years back.

[-]

bennett-dev@reddit

Laravel was one of the first frameworks I ever learned, and I have a soft spot for it. But I'm not particularly impressed by even well-implemented frameworks which are essentially just language rewrites of MVC/WebObjects backends.

[-]

AaronDNewman@reddit

exactly my thought.

[-]

-lq_pl-@reddit

Why is this upvoted? That article is basically an ad for Laravel. Information content is zero.

[-]

isaiahassad@reddit

So, Otwell's basically saying: 'Keep it simple, or risk building a cathedral of complexity.' Guess it's time to retire my 'clever' one-liners. 😅

[-]

TankAway7756@reddit

Beware languages (and frameworks, which effectively are languages) which create a need for cleverness.

[-]

arekxv@reddit

Considering the "decisions" made in Laravel to make it so opinionated as not to even support some features people need and for others you have to work around the framework to since they are locked down or that Laravel breaks down its simplicity the moment you have to do something it doesn't normally support. I would say that Taylor promotes "clever dev" mindset.

[-]

srona22@reddit

So only I can debug my shit code. I must be "smart" then.

[-]

elperroborrachotoo@reddit

Yes but today it's a smell if you fold a single piece of paper without an origami package.

[-]

VivienneNovag@reddit

Complexity from the combination of simple, well understood, elements.

The design paradigm, commonly associated with microservices, is absolutely applicable to almost all of programming. The concept of functions already allows for it.

Good article on a topic that is often overlooked in the current learning environment.

[-]

timeshifter_@reddit

You know, for a species that built civilization on the shoulders of those who came before, I seem to see this headline a lot.

[-]

shizzy0@reddit

“Beware clever devs.”

“Hmm, we don’t have to worry about them. This factory seems to keep them out. Here. Look. This light switch. What do you think it does?”

“Turns on the light.”

“Yeah, it used to but now it turns on the scary machine in back. Haven’t had any accidents since—well, so long as only one person operates it.”

The lights go off. Lights return and everyone on the floor is waving their hands around briefly. “Motion sensor, very high tech.”

[-]

noideaman@reddit

Beware clever developers until you’re sure you need a clever developer!

[-]

esiy0676@reddit

PHP framework ... why not ask the author of Pascal?