Laravel Inventor Tells Devs To Quit Writing 'Cathedrals of Complexity' (theregister.com) 48
Taylor Otwell, inventor and maintainer of popular PHP framework Laravel, is warning against overly complex code and the risks of bypassing the framework. From a report: Developers are sometimes drawn to building "cathedrals of complexity that aren't so easy to change," he said, speaking in a podcast for maintainable.fm, a series produced by Ruby on Rails consultancy Planet Argon.
Software, he said, should be "simple and disposable and easy to change." Some problems are genuinely complex, but in general, if a developer finds a "clever solution" which goes beyond the standard documented way in a framework such as Laravel or Ruby on Rails, "that would be like a smell."
A code smell -- for the uninitiated in the The Reg readership -- is a term developers use for code that works but may cause problems at a later date. Otwell described himself as a "pretty average programmer" but reckons many others are the same, solving basic problems as quickly and efficiently as they can.
Software, he said, should be "simple and disposable and easy to change." Some problems are genuinely complex, but in general, if a developer finds a "clever solution" which goes beyond the standard documented way in a framework such as Laravel or Ruby on Rails, "that would be like a smell."
A code smell -- for the uninitiated in the The Reg readership -- is a term developers use for code that works but may cause problems at a later date. Otwell described himself as a "pretty average programmer" but reckons many others are the same, solving basic problems as quickly and efficiently as they can.
There is no greater code smell... (Score:2, Troll)
...Than using Ruby on Rails.
+37 Insightful (Score:1)
(Choice of "+37" intentional)
Re: There is no greater code smell... (Score:5, Insightful)
Clearly you've never had to deal with the stygian horror that is modern web code with an unholy mix of html, style sheets , javascript with multiple offsite libraries in the browser, and whatever dogs dinner combination that runs the backend.
If you're not using 256 JS lib for a simple form.. (Score:4)
Re: (Score:2)
with multiple offsite libraries in the browser,
Recalls to mind the hilarious fallout when that hubspot garbage libraries starting shipping malware to every site using them.
If I spot this behaviour in any code change - you're fired. We don't need more Wordpress garbage.
Unfortunately... (Score:3)
...theres a breed of programmer who uses writing complex code as silent bragging rights and boasting "look at me" it says, "bet you cant understand this easily because I'm l33t and you're a grunt". Theres also another breed who simply cant think in a logical fashion and their code is an unintentional rats nest that probably doesnt work anyway but they're less common as they usually get the boot from companies during their probationary period.
Re: (Score:2)
The fact that you refer to them as geniuses should tell you something: they do stuff that you can't do, or they do them in a much shorter time than you can do. Of course you proceeded to call them "plainly overconfident". Well, if they're overconfident, then they probably aren't geniuses and just assholes. But if they're true geniuses, then you learn to put up with some of their idiosyncrasies because chances are that they're still right. Curious and wondering what you think about our good old Linus?
Re: Unfortunately... (Score:2)
Easy fix (Score:4, Insightful)
Use Symfony. Laravel is like a poorly thought out, feature deficient, grab bag of libraries based on the great work done for Symfony.
Just use Symfony.
Re:Easy fix (simple and disposable and easy) (Score:5, Insightful)
I just stick with what I can write in vanilla PHP that is "simple and disposable and easy to change" to use his phrase. I've tonnes of little things on my LAN, dozens of lines, hundreds at most, to do simple tasks. You can read the entire thing in a few minutes, if necessary just rewrite the whole thing in a few minutes. As soon as you have 10k's or more of lines, you need to do organisational gymnastics. If you want to use a large framework, that starts constraining how you deploy: vs just stick 5 .php files in a folder under htdocs somewhere and done.
You can do a lot with PHP and no framework, and I prefer to stick to that. My solution to the problems of code complexity is simply not to have the complexity if it can be avoided.
Re: (Score:3)
That's fine for hobby programming, but sadly companies now do all their PHP coding with frameworks, either Symfony or, more commonly, Laravel. I'm guessing because they think it makes their developers more like replaceable cogs. No need to demonstrate real coding proficiency, just experience with the chosen framework.
Re: Easy fix (simple and disposable and easy) (Score:2)
If you and your entire team can all effectively make architectural decisions about a project and generate good documentation, it doesn't matter what you use.
But what I'm getting at is that Symfony has much better, fully formed architecture, while Laravel leaves you hanging.
You CAN use Laravel to do what Symfony does by making good architectural decisions. But the reason this Laravel guy is bitching about poor use of Laravel is specifically due to the fact that it's a cobbled together solution with little ar
Typical (Score:2)
A guy who maintains a PHP framework is telling coders "just stick to the framework bro". Surprise surprise.
Genius admires simplicity... (Score:3)
...mediocrity admires complexity.
Joel on Software explained it in 2000 (Score:4, Informative)
Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. ...
Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.
It is true today. All that complex code is money: it is functionality the user (or the marketing folks) want to sell more, to provide better service, or to differentiate. Simple code is for textbooks. Complex, crufty, miserable code reflects the complexity of a successful business or a highly-used open source project.
Why? Try explaining the rules of English spelling or grammar to someone. It requires many special cases, exceptions, and exceptions to the exceptions. Business processes are, sadly, the same way.
Should you refactor? Of course, when doing so allows faster fixing of bugs or adding new features (i.e., when it makes it easier to make the code more functionally complex.)
Re:Joel on Software explained it in 2000 (Score:4, Interesting)
I suspect this is a message intended to those starting out to do something weird rather than accumulated complexity over time.
I have seen some pretty stupid stuff. For example, a development team came to me for help because some operation was slow. Turned out they had written their own file copy routine instead of using the standard library, and they manually copied stuff in and out of a 512 byte buffer. There was no good reason for this, no possible good reason, but for whatever reason they wrote a bespoke function to copy a file from one place to another despite the standard library having that built in. Replacing calls to that with the standard library sped up the operation over a hundred fold.
Now that said, sometimes 'complexity' is invoking "frameworks" too liberally, and trying to use them for things they were never really geared to do. So you have a framework that strives to be a streamlined facility for a GUI wrapped around a SQL database, and that framework is popular so someone declares 'lo, we shall use framework X', except there's no SQL database in the particular scenario and thus it really doesn't make sense and you end up doing all kinds of weird things to circumvent the natural design point of SQL at the core of the given framework. The framework was designed to make exactly one thing easy, and you aren't doing that, yet you still try to use the framework anyway.
Like all sorts of this guidance, everyone can find a way to agree or disagree depending on how they interpret it.
Re: Joel on Software explained it in 2000 (Score:2)
That does suggest a good use-case for Copilot (or whatever the AI-helper-of-the-day is); it could detect when you are reinventing a wheel and suggest the standardized functionality that you could call instead.
Re: (Score:2)
Unfortunately, I've seen the exact opposite. I asked it to do something that *should* have indicated a very well maintained external function call, but it instead emitted an unholy mess of a function. I thought it would have saved me a bit of search to find it, but had to search myself. I have no idea if the function would have worked in this case, as I took one glance and said that not only is it failing to use a third party library for a complex interoperability that needs active maintenance, it looked
Re: (Score:2)
You mean ear and bear aren't pronounced the same? Where does tear fit into the picture? Can we try food, book, and good?
Re: (Score:2)
Re: (Score:2)
Simple code is for textbooks. Complex, crufty, miserable code reflects the complexity of a successful business or a highly-used open source project.
Too true.
Chesterton's fence applies here. You'd better have a super solid and deep understanding of why that fence is there before you even think about taking it down. "I don't know why it's even there" isn't good enough.
Re: (Score:2)
If there's something truly novel that required more than 4 hours thought, it's worth putting a one or two line summary in the form of a comment for the next guy. Heck with modern tooling you don't even have to document it yourself "add a comment here explaining the problem and how this solves it and why". My code isn't 50% comments, but it's at least 3-5%
Vibe code it (Score:3)
Software should be "simple and disposable ... (Score:4, Interesting)
If software is working and provides the functionality you need, then why would you dispose of it?
If your software does anything useful, you modify rather then dispose of. There are obviously limits in reality, spaghetti code does develop over the lifetime of modifications.
If you have a complex problem to solve, then your solution must address that complexity. Simple and complex are opposites.
If you simplify, then by definition, you reduce complexity. You can't really simplify things very much. Ex. if you use Wireshark, you still need to understand Internet Protocol. Some people consider Wireshark easier to use than tcpdump, but if you don't understand the data/protocol, you won't be able to use either. Wireshark is a gui. Does that actually simplify anything?
Everybody would like to have simple answers to complex questions, but that can't happen without the loss of information.
Easy to change? Would be nice, but reality usually ends up in the spaghetti zone.
IMO, you'd only dispose of software, most likely, because you vibe generated it, and it's so brittle you can't change it.... or in a more legitimate scenario, you developed a prototype to prove a concept. Concept got proven, then you set out on an actual design.
Re:Software should be "simple and disposable ... (Score:4)
If you have a complex problem to solve, then your solution must address that complexity. Simple and complex are opposites.
Everybody would like to have simple answers to complex questions, but that can't happen without the loss of information.
Important points to live by, not just for software. The drive to find simple solutions to complex problems rather than accepting and managing complexity causes a lot of harm and waste.
Re: (Score:1)
Whether a GUI or CLI is easier for you depends on your history. Either way, your code is implicitly hiding something, otherwise the user/programmer would just be using the "bare metal" your code is built on.
Make sure what your code hides isn't something your user needs to see, that they can easily see and change anything they may need to. I'm suddenly feeling the urge to expound on how, but I think tha
Ask ColdFusion, ASP, JSP, EJB, J2EE developers (Score:2)
Really? No. This is just writers filling up blank space. If software is working and provides the functionality you need, then why would you dispose of it?
Ask anyone who wrote an app in ColdFusion, ASP, JSP. I still think JSP is perfectly fine...and everyone in the world thinks I'm a masochistic moron for that, apparently. I've written many great applications with modern technologies that were thrown away. Why?...the customer changed their mind...they hired a new MBA dipshit who thought the code needed to be written by an offshore agency giving him kickbacks...sometimes your platform just is too old. My ColdFusion 5 publishing platform from 20 years ago wa
Re: (Score:2)
What people don't understand is that every language or programming method has its own strengths and weaknesses. Take, for instance, string processing on SQL server. It doesn't really exist. Sure, I can write a Perl script to get SQL data and manipulate it, but that's only useful if I am writing an interface and will be doing something with the data outside of SQL afterward. I loved the list processing functions in Coldfusion (and if I go back further, those from Advanced Revelation in the 80s), so I wro
Re: (Score:2)
Just tell them you're a genius and you can actually code even faster if they pay you more.
Then slow down by 10%.
It's not the complexity with cathedrals (Score:2)
It's the time need to be completed.
Cologne Cathedral, 632 years
St. Vitus Cathedral, 585 years
Rouen Cathedral, ~678 years (with long pauses)
Milan Cathedral, ~579 years
Ulm Minster, 513 years
Strasbourg Cathedral, 424 years
Notre-Dame de Paris, 182 years
York Minster, 252 years
Seville Cathedral, 106 years
Sagrada Família, 143+ years (ongoing)
Writing simpler systems is harder (Score:2)
Anybody can just throw more code at any problem and eventually fail. Making things simple but functional is a lot harder and not many people can do it. But if there is one thing to learn from engineering history, it is that simple solutions are always fundamentally better than complex ones. Of course, depending on the problem, there is a lower minimum complexity that you cannot go below. But any good engineer will always try to get close to than boundaries. Unfortunately, there are a lot of bad and mediocre
Re: (Score:2)
Re: (Score:2)
Then you have no place in any kind of system or software design.
Re: (Score:2)
Re: (Score:2)
Nicely yielded, and I'd add, code is just code, and I guess the real issue is, has the person grappled with the issues in the particular domain area long enough to know the particulars of what matters and what's relevant, rather than some abstract ideal like "engineering".
I'm guessing that engineers have common sense rules of thumb, like, every rule has exceptions, and, solve the right problem, because beyond principles like quality and reliability, you still have real world messy situations to deal with. L
Re: (Score:2)
Engineers have assured qualifications, minimal standards that are relatively, have been shown their own limitations time and again in their education and ... have personal liability if they screw up bad enough.
Engineers are what you want if you have a "messy situation", because (good) engineers are capable of actually understanding the mess and they have a large set of tools in their toolbox. Yes, if you just want to write a lot of code that has low requirements, by all means use a coder and not an engineer
Re: (Score:2)
Re: (Score:2)
True in many ways.
But I wonder why it hasn't happened; coders being expected to have similar professional liability as people who design and calculate steel structures.
We recognise the rigour of real engineering, and wish programming could be like that, but I wonder if that's an illusion.
For example, I might wish my doctor has the same clarity and objectivity as the structural engineer, but medicine and biology are just so much more complicated.
That's not for lack of smarts, the doctor learnt vast informati
Stop Writing Cathedrals of Complexity (Score:4, Funny)
and Start Writing Bazaars of Improvisation ;-)
Re: (Score:2)
Years later... (Score:1)
Stuff I write tends to hang around for years and sometime decades. There's a water vending machine that I wrote almost 40 years ago now and it's still running just like it always did, though the hardware and even the shack by the side of the road that it lives in has changed a few times over the years.
I've found that when I have a brainstorm and write some "clever" code it tends to turn around and bite me when I come back to it ten years later to make a change. Either because I can't remember why it's doi
We're trying, but (Score:1)
management is interfering.
Complex vs Complicated (Score:2)
Complex is fine. The code needs to as complex as the task at hand requires. As long as there's order and structure to it, complexity is not a problem at all.
It's "complicated" that's the problem. Things that are either poorly written or without structure or order, needlessly convoluted or overengineered, unmaintainable.
My manager: Just have Cursor write something (Score:2)
I think it's time to leave this company before the house of cards generated by Cursor comes falling apart.
Code smell (Score:2)
Cathedrals of complexity....you mean like coming up with bizarre terminology to describe basic things....such as "code smell" for "this may be a problem later" ?
54 years on Earth. Many of those spent in and around the world of software development. This is the first time I've ever heard the term "code smell".
I hope it's the last.
Re: Code smell (Score:2)