I keep telling noobs that writing code is like 10% of what they do, and each line of code is a millstone round their neck. Terse, optimal performance (not optimized!) code meeting user requirements is the route to success. And so, doing less is how to go faster, but not what the video means
Fastest and most maintainable code is one that does not exists.
Best one after that is it short and simple one.
Knicking this
Now, I am just a modder and not a full blown dev or anything, but I've always questioned others who critcized my scripts and suggested much more complicated ways of doing the same thing. Like I can do exactly what I wanted with 1 line of code, and someone would come in and say "do it this way for better results" and it's 6 lines of crap that ends up working exactly the same. Why?! Especially when this was for a game that has a notoriously slow script engine, meaning more lines of code = slower, no matter what you were doing.
Generally the performance difference will be minimal, but the benefit to others (and yourself in the future) in keeping the code's functionality clear and readable is much more important, especially in a professional setting.
A lot of programmers do have this 'code golf' mentality that less lines == efficient, but unless its a bottleneck and you've benchmarked it to be significantly faster, code readability should always trump performance.
Hard agree.
Less code is not a positive metric to measure your implementation by, and is not a valid premise to justify itself. Often increasing the complexity (again, LOC is not an indicator of complexity), tanking performance, and harming the debugging experience is a common result of the mentality. Things that make software worse.
Not all one-liners are bad ofc, that's not the argument I'm making. It's about the mentality that less code is more good, where poor decisions are made on a flawed premise.
That single line of code may be using a slow abstraction, doesn't cover edge cases, has no caching of reused values, has no optimization for the common path, or any other number of issues. Thus being slower, fragile, or sometimes not even solving the problem it's meant to solve.
More often than not performance and robustness comes at a significant increase to the amount of code you have to write in high level languages... Performance optimizations especially.
A high performance parser I was involved in writing was nearly 60x the amount of code (~12k LOC) of the lowest LOC solution you could make (~200LOC), but also several orders of magnitude faster. It also covered more edge cases, and could short circuit to more optimal paths during parsing, increasing the performance for common use cases which had optimized code written just for them.
More lines of code = slower
It doesn't. This is a fundamental misunderstanding of software engineering and is flawed in almost every way. To the point of it being an armchair statement. Often this is even objectively provable...
This makes me feel better about my if..then..else walls.
It doesn't. This is a fundamental misunderstanding of software engineering and is flawed in almost every way. To the point of it being an armchair statement.
I was talking about a specific edge case there. The way the scripting system for ARMA is handled, a longer script will take more time to parse and run than a script that can do the same thing in fewer lines, except in some rare instances where you actually could optimize how it's handling a certain function.
Less lines doesn't automatically mean a CPU does less. I can write a one liner in ruby that will munch through a thread. But in general you're correct imo
My comment though was more that performance isn't about just CPU time. Development time is another performance metric, as is maintenance, overly complicated abstractions can yield big brain points but rarely anything else
If you solve only the problem you have with less code (why, some sort of example driven development may be of service here) then you're on the road to better everything
each line of code is a millisecond round their neck
My man here thinking performance optimizations= fewer lines of code đđđ
Let me rephrase then as you missed my point. Each line of code is a millstone around you, your team, and your companies neck. Maintainability usually corellates to LOC. Performance often aligns to LOC. Understanding your Big-O is far easier with less lines for when you do need to optimize. It's easy to write ten lines of code. The wisdom comes from knowing which of those lines you need and which you don't
I keep telling noobs that writing code is like 10% of what they do, and each line of code is a millstone round their neck. Terse, optimal performance (not optimized!) code meeting user requirements is the route to success. And so, doing less is how to go faster, but not what the video means
Fastest and most maintainable code is one that does not exists.
Best one after that is it short and simple one.
Knicking this
Now, I am just a modder and not a full blown dev or anything, but I've always questioned others who critcized my scripts and suggested much more complicated ways of doing the same thing. Like I can do exactly what I wanted with 1 line of code, and someone would come in and say "do it this way for better results" and it's 6 lines of crap that ends up working exactly the same. Why?! Especially when this was for a game that has a notoriously slow script engine, meaning more lines of code = slower, no matter what you were doing.
Generally the performance difference will be minimal, but the benefit to others (and yourself in the future) in keeping the code's functionality clear and readable is much more important, especially in a professional setting.
A lot of programmers do have this 'code golf' mentality that less lines == efficient, but unless its a bottleneck and you've benchmarked it to be significantly faster, code readability should always trump performance.
Hard agree.
Less code is not a positive metric to measure your implementation by, and is not a valid premise to justify itself. Often increasing the complexity (again, LOC is not an indicator of complexity), tanking performance, and harming the debugging experience is a common result of the mentality. Things that make software worse.
Not all one-liners are bad ofc, that's not the argument I'm making. It's about the mentality that less code is more good, where poor decisions are made on a flawed premise.
That single line of code may be using a slow abstraction, doesn't cover edge cases, has no caching of reused values, has no optimization for the common path, or any other number of issues. Thus being slower, fragile, or sometimes not even solving the problem it's meant to solve.
More often than not performance and robustness comes at a significant increase to the amount of code you have to write in high level languages... Performance optimizations especially.
A high performance parser I was involved in writing was nearly 60x the amount of code (~12k LOC) of the lowest LOC solution you could make (~200LOC), but also several orders of magnitude faster. It also covered more edge cases, and could short circuit to more optimal paths during parsing, increasing the performance for common use cases which had optimized code written just for them.
It doesn't. This is a fundamental misunderstanding of software engineering and is flawed in almost every way. To the point of it being an armchair statement. Often this is even objectively provable...
This makes me feel better about my if..then..else walls.
I was talking about a specific edge case there. The way the scripting system for ARMA is handled, a longer script will take more time to parse and run than a script that can do the same thing in fewer lines, except in some rare instances where you actually could optimize how it's handling a certain function.
Less lines doesn't automatically mean a CPU does less. I can write a one liner in ruby that will munch through a thread. But in general you're correct imo
My comment though was more that performance isn't about just CPU time. Development time is another performance metric, as is maintenance, overly complicated abstractions can yield big brain points but rarely anything else
If you solve only the problem you have with less code (why, some sort of example driven development may be of service here) then you're on the road to better everything
My man here thinking performance optimizations= fewer lines of code đđđ
Let me rephrase then as you missed my point. Each line of code is a millstone around you, your team, and your companies neck. Maintainability usually corellates to LOC. Performance often aligns to LOC. Understanding your Big-O is far easier with less lines for when you do need to optimize. It's easy to write ten lines of code. The wisdom comes from knowing which of those lines you need and which you don't
I learned this lesson through one of my optimization tasks. Speeding up programm by just reducing input data by 80% solved multiple problems. And real eye openner was an "article" about grep: https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html
Basically if you have less work you will do it faster. Since then my first question is always: Can we do less work?