Coders' Primal Urge To Kill Inefficiency -- Everywhere (wired.com) 181
For software engineers, lack of friction is an aesthetic joy, an emotional high, the ideal existential state. It's what drives them, and what shapes our world. An excerpt from an upcoming book on coding, via Wired: The thrust of Silicon Valley is always to take human activity and shift it into metabolic overdrive. And maybe you've wondered, why the heck is that? Why do techies insist that things should be sped up, torqued, optimized? There's one obvious reason, of course: They do it because of the dictates of the market. Capitalism handsomely rewards anyone who can improve a process and squeeze some margin out. But with software, there's something else going on too. For coders, efficiency is more than just a tool for business. It's an existential state, an emotional driver.
Coders might have different backgrounds and political opinions, but nearly every one I've ever met found deep, almost soulful pleasure in taking something inefficient -- even just a little bit slow -- and tightening it up a notch. Removing the friction from a system is an aesthetic joy; coders' eyes blaze when they talk about making something run faster or how they eliminated some bothersome human effort from a process. This passion for efficiency isn't unique to software developers. Engineers and inventors have long been motivated by it. During the early years of industrialization, engineers elevated the automation of everyday tasks to a moral good. The engineer was humanity's "redeemer from despairing drudgery and burdensome labor," as Charles Hermany, an engineer himself, wrote in 1904.
[...] Many of today's programmers have their efficiency "aha" moment in their teenage years, when they discover that life is full of blindingly dull repetitive tasks and that computers are really good at doing them. (Math homework, with its dull litany of exercises, was one thing that inspired a number of coders I've talked to.) Larry Wall, who created the Perl programming language, and several coauthors wrote that one of the key virtues of a programmer is "laziness" -- of the variety where your unwillingness to perform rote actions inspires you to do the work to automate them.
Coders might have different backgrounds and political opinions, but nearly every one I've ever met found deep, almost soulful pleasure in taking something inefficient -- even just a little bit slow -- and tightening it up a notch. Removing the friction from a system is an aesthetic joy; coders' eyes blaze when they talk about making something run faster or how they eliminated some bothersome human effort from a process. This passion for efficiency isn't unique to software developers. Engineers and inventors have long been motivated by it. During the early years of industrialization, engineers elevated the automation of everyday tasks to a moral good. The engineer was humanity's "redeemer from despairing drudgery and burdensome labor," as Charles Hermany, an engineer himself, wrote in 1904.
[...] Many of today's programmers have their efficiency "aha" moment in their teenage years, when they discover that life is full of blindingly dull repetitive tasks and that computers are really good at doing them. (Math homework, with its dull litany of exercises, was one thing that inspired a number of coders I've talked to.) Larry Wall, who created the Perl programming language, and several coauthors wrote that one of the key virtues of a programmer is "laziness" -- of the variety where your unwillingness to perform rote actions inspires you to do the work to automate them.
Ha... exactly backwards (Score:5, Interesting)
Numerical Recipes in $LANGUAGE states it is written for scientist not coders because the difference is that scientists work on the next generation of problems on the last generation of computers (and hence need efficiency), while coders solve the last generation of problems on the next generation of computers (and thus make the code more elegant but less efficient).
Re: Ha... exactly backwards (Score:3)
and thus make the code more elegant but less efficient
Huh??
Re: (Score:1)
It means that when you have lots of resources you are not focused on efficiency in using them. For example a mind set of removing hacks and doing things the right way in a design pattern even if it means lots of overhead per call or memory inefficiency or having to throw more threads at the same task. If you are resource rich you strive for clean, re-usable code not optimizing resource constrained performance on the next larger problem. Look at all the metrics coders use to judge code and you can see it
Re: (Score:1)
It means that when you have lots of resources you are not focused on efficiency in using them. For example a mind set of removing hacks and doing things the right way in a design pattern even if it means lots of overhead per call or memory inefficiency or having to throw more threads at the same task. If you are resource rich you strive for clean, re-usable code not optimizing resource constrained performance on the next larger problem. Look at all the metrics coders use to judge code and you can see it's about clean, re-usuable, APIs
Ugh.. boil it down to the simple statement. Computers and computer resources are dirt cheap compared to coders, as such the corporate desire is to spend the least amount of money on both that results in "adequate" performance for the masses.
Re: (Score:2)
In some cases this is true locally but not globally.
For example, a product like Hadoop is/was very widely used and the aggregate global usage consumes/consumed vast computing resources (and the attendant real estate to house them, energy to power them, energy to cool them, etc -- i.e. TCO). Squeezing, on the average, a 0.5% performance improvement may be well worth the initial development cost when viewed globally across all organizations as
Re:Ha... exactly backwards (Score:5, Interesting)
Numerical Recipes in $LANGUAGE states it is written for scientist not coders because the difference is that scientists work on the next generation of problems on the last generation of computers (and hence need efficiency), while coders solve the last generation of problems on the next generation of computers (and thus make the code more elegant but less efficient).
You have a narrow idea of "efficiency". You're thinking about CPU-time, which matters so rarely these days. Good software professionals optimize for human-time, writing code that's easy to support and maintain. That's "efficiency" that will bring a smile. Nothing better than a code review that's "all red", that is, removes a ton of pointless lines of code from a legacy system.
Re: (Score:1)
Those things are important to optimize too, which is why nobody writes SQL database queries in assembler.
But I've done tons of work to optimize CPU/GPU rendering code, where shaving 75 milliseconds of time out of a loop is the difference between a frustrating user interface and one that is smooth and makes the customer happy. (25 mS render time = 40 FPS, 100mS render = 10 FPS). Humans notice that lag at 10 FPS when interacting with a touchscreen. Customer in this case being the driver of a high end car.
Re: (Score:2)
"Premature optimization is the root of all evil" -Knuth
Yeah, that web app isn't slow because of CPU. It's slow because of a bunch of stupid architectural decisions, and very likely over-reliance on a RDBMS that work fast enough when there were only test users.
Re: (Score:2)
I take it you don't work in embedded software, video games, or high-performance computing of any kind.
Depending on how you look at it, I ran a fairly powerful supercomputer for years. Need 1 million cores? (OK, less impressive this year than a few years ago.) Sometimes just throwing more hardware at the problem works, and there are several categories of problem that parallelize well even with high latency between nodes.
The areas where constant-time perf improvement actually matter shrink every year. It's still a very fun sort of programming, but it's just so rarely comes up in most software jobs.
Re: Ha... exactly backwards (Score:4, Funny)
Indeed. Web grunts with CRUD apps think CPU time doesnÃ(TM)t matter because they think a 5 second page load is acceptable.
I guarantee you that CPU was never the bottleneck in the performance of that web app. Wasting time optimizing the part of the process that takes 5 microseconds to make it take 4 microseconds of that 5 seconds is something people do because it's fun, not because it's productive.
Meanwhile that poorly-written DB query that runs once an hour (to make a report no one reads) and browns out the DB server for 3 minutes is why someone's getting 5-second page loads, but only between X:03 and X:06 every hour. Good luck even reproducing that. Welcome to the real world.
Re: (Score:2)
You reduce that by having a replica for "data mining", you don't do that on the life data base.
Re: (Score:2)
Wouldn't that be nice? A world where people avoid doing obviously stupid stuff on production serves? It's a nice fantasy.
Re: (Score:2)
If the CPU isn't the bottleneck in a web app then you are paying way too much for your cloud CPU instance. You shoul dhave bought a cheaper instance to make it the bottleneck
Re: (Score:2)
Most software I work with is I/O-bound. Since most programmers these days don't know what "asynch I/O" is (is it even possible with Java?), you either run out of threads, or sink into a quagmire of thread dispatch. Although it's nice when you can instead be memory-bound, because what you're doing caches well, but read-intensive loads are trivial anyway.
Also: still using "instances" in current year argument? Get with the times! That's so five years ago. Containers are old fashioned now. Bro, do you eve
Re: (Score:2)
Spikes are why you use clouds. Spawn new instances to handle loads.
If you can wait 5 minutes for new instances to come up behind the LB, that's a ramp not a spike. Of course, that's fine for some cases.
Haven't seen that. I see crap and non-crap (Score:4, Interesting)
That's an interesting observation. I'll look for it.
I suppose I DO see it in programming tools, such as languages.
I do a lot of code review and mostly I see bad code and good code. Good code tends to be elegant and efficient. Bad code tends to be inelegant and inefficient. They tend to go hand-in-hand. Partly because mathematically they are sometimes correlated, and partly because those who write good code, write good code. I don't often see "good" as in "elegant" code that is also "bad" as is "inefficient".
I wonder though about whether programmers in general have that instinct, that desire, for efficiency, or if that's just the 10% who are particularly good at it. A lot of people do in fact write crap. Do they have a strong desire to do much better, but just don't know how to learn? I'm not sure. Maybe 30% of my teammates signed up for my last series of classes I taught, so those 30% indicate by their actions that they really want to improve.
* Talking about teaching classes sometimes makes people think I'm arrogant. I'm really, really bad at singing. Horrible. I can't play any video or board games. I can't draw for shit. I spend all my time learning about programming and designing information systems. I'm pretty good at that one thing.
Re: (Score:2)
while coders solve the last generation of problems on the next generation of computers (and thus make the code more elegant but less efficient).
That is nonsense.
A for loop is a for loop is a for loop. It does not lose efficiency just because a coder gets older and a computer gets faster.
We lose efficiency because problems and solutions become more complex and coders are forced to deliver in relatively short time. So they rely on frameworks that focus on simplifying work and ensuring "safety" from mistakes (
Re:Ha... exactly backwards (Score:5, Interesting)
For the READER not the developer (Score:1)
Code should be written for the next developer to read and understand it.
Your cutting edge coding style, set of libraries and tools is a time bomb of maintenance work in 2 years.
Code written for the next reader, not for cuteness, not for creative writing assignment, not for an interlarded overstratification of layered gunk, not a large number of misappropriated patterns.
I'd expect to see these three etched in gold plate on the next moon probe:
- Use the guard clause, once you get past the guard clauses, busin
Re: (Score:2)
What about "CustomerAccountCreate" and "CustomerAccountDisable"? Would this not produce a beneficial grouping of the "CustomerAccount" methods?
Or shouldn't there be a CustomerAccount class so you could simply say
CustomerAccount activeCustomerAccount = new CustomerAccount();
followed by
activeCustomerAccount.dispose(); // frees internal resources prior to garbage collection
activeCustomerAccount = null;
Re: (Score:2)
activeCustomerAccount = null; ... why the funk are there still people who set local variables to null?
Please please please, don't do this.
After the CPU returns from the current subroutine, that stack frame is gone
You relying on Escape Analysis? (Score:2)
Because in Java (note the comment about garbage collection), all object allocations go on the heap.
OK, OK, there is Escape Analysis where the runtime, if it so optimizes your code, will allocate on the stack an object from which no references "escape" the current context.
Good luck with that being a guarantee.
Re: (Score:2)
Perhaps you want to read how GC works.
Setting a local variable to null is a waste of time and time of the coder and a reason to fire him.
Which part of: "after the subroutine returns, the stack frame is gone" don't you grasp?
Re: (Score:2)
Thanks, dude, I understand your point about the reference-on-the-stack having its stack frame expunged.
Good thing that I don't work for you. I would be out of a job for something that a simple explanation to teach me something would suffice.
Re: (Score:2)
On the other hand, setting the local reference to null right after calling the dispose() method will set a runtime Null Pointer Reference exception if I erroneously invoke a method using that reference afterward. The reason for a dispose() method, by the way, is to free resources such as file handles, in the absence of an object destructor.
There are all manner of corrections that can come up in a review of even the shortest code snippet, that is, unless you fire a person after their first use of an inef
Re: (Score:2)
One more thing:
https://stackoverflow.com/ques... [stackoverflow.com]
Setting a reference to null could allow a memory-hungry object to be collected within a local scope.
Re: (Score:2)
Yes, it could.
In real world such cases don't exist, just read the rest of the SO article.
Setting a local reference to null is in 99.9999% of all cases WRONG, especially in a finally block as the SO question was asking.
Re: (Score:2)
You do know that there are IDEs?
So you have a variable, v, and you write the dot behind it, v., the methods applicable pop up? If I see you naming methods in a Customer class containing the word "Customer" again, you will be chained in the basement with water and bread until you repent. And yes, the methods are verbs and start with the most significant verb.
There is nothing wrong with: Customer::create, File::create, Window::create ... and so on.
Understood?
What is "sloppy vector"? (Score:2)
A quick Web search did not turn up "sloppy vector" as a coding style.
I understand how locality of reference can make a big difference in processing speed. But is "sloppy vector" simply a description of attempting to optimize loops scanning through arrays for the vector-architecture supercomputers but doing it in a haphazard way? Or is it a term-of-art that I can read about someplace?
Thanks!
Feel-good nonsense (Score:3)
Re: (Score:2, Insightful)
Very true. Most programmers aren't interested having a 100% efficient program at this point. But we are interested in automating tasks. The two things are independent, but the summary conflates the two. Probably written by a non-developer.
Re:Feel-good nonsense (Score:5, Insightful)
If you are looking at gcc flags to get overall optimization, you are doing it all wrong. You gain fractions from gcc optimizations. I've refactored code and gotten 1000X from silly stuff that people have done. gcc would have done nothing to make those problems go away.
Re: (Score:2)
That's because there is an overwhelming lack of understanding of what they write as code and what it actually means as far as instructions to perform it. In fact most of what people think they are doing to help performance is likely optimized away by the compiler.
Which btw highlights the difference between programmers who write things like compilers and the rest of the "bro programmers". Sadly, guess which ones are likely pulling down more salary.
Re: (Score:3)
That's not what they're talking about. They're talking about automating *something* with code.
Even the slowest BLAS libraries are faster than a human at doing matrix multiplication. Having humans do math was inefficient and slow until some coders came up with a way to do it 'automatically'. Then the world moved on.
Right now I'm Jenkins-ing everything at work. Even trivial stuff that takes time. I just put it in a batch job and let it run.
Re: (Score:2)
Sometimes spending the time to make something more efficient is inefficient. I'll happily admit that I have code out there that I know is not the most efficient, and I even know the ways to make it MORE efficient.
I write internal apps for a private business. If one of my webpages takes 10milliseconds longer to load than I could optimize it for... so be it... we're not talking about thousands of people hitting the site at the same time.
I have a long list of things to work on and I can crank out more pages
Re:Feel-good nonsense (Score:5, Insightful)
A very good point. I work in videogames, which obviously has, as an industry, a great interest in writing efficient code.
However, in code meant for tools, or even game code that's reasonably far off the critical path, I'll happily sacrifice efficiency in some complex code in order to make it more readable, because that's significantly more important for the those that may come after me who have to maintain it. For code that's in a critical path, only then will I spend the extra effort writing more optimal code. Optimal code sometimes has a price to pay both in the time spend writing it, but also maintaining it in the future.
There are occasions where more optimal code is also clearer and more elegant, but you have to have a reasonably comprehensive knowledge of both the language and the project you're working on to properly make this call.
Re: (Score:3)
The older I get, the more I notice that I am way more annoyed by problems in the big picture, vs. some small loop that could be slightly more funkyly coded.
It is relatively easy to get some super coder to make a routine more efficient, or geek out oneself to hyperfocu
Re: Feel-good nonsense (Score:4, Insightful)
For nearly all code you should write the simplest implementation, selecting ease of reading, security, and maintainability over speed. After your program is nearly done and you begin profiling then start optimizing. People are notoriously bad at guessing where bottlenecks will be and what causes them.
Re: (Score:2)
And yet--gamers? Let me take a wild guess that game programmers are people who like games.
Games are the antithesis of efficiency. They consist entirely of a deliberate choice to waste as much time as possible, often to the detriment of useful activity. Even reading books or watching movies can sometimes be considered educational to some extent. Games; not so much.
Of course many games require extreme speed and efficiency to generate maximum endorphins and adrenaline. That code must be impressive. Congrats if
Re:Feel-good nonsense (Score:5, Insightful)
Not only feel-good nonsense, but it makes a ridiculous generalization about "coders" as if they are some kind of special life form. Do "carpenters" have a primal urge to "kill inefficiency" because they use power tools?
Re:Feel-good nonsense (Score:5, Insightful)
Not only feel-good nonsense, but it makes a ridiculous generalization about "coders"
Yup. After all, the inefficient code that "coders" love to optimize had to come from somewhere. Where, if not from "coders"?
Re: (Score:2)
That could conceivably happen.
Here's a more plausible scenario:
1) Human does work
2) Developer fresh out of college with limited google-foo and general DIY mentaility re-invents the wheel to make process 1000 times better than human
3) Re-invented wheel is tweeted about and another developer also unaware of 10s of other previously existing wheels wraps implementation into an API for whatever the popular language of the week is, making it 3 times less efficient.
4) Developer at startup integrates said library a
Re:Feel-good nonsense (Score:4, Interesting)
Not only feel-good nonsense, but it makes a ridiculous generalization about "coders" as if they are some kind of special life form. Do "carpenters" have a primal urge to "kill inefficiency" because they use power tools?
Close. Carpenters have a primal urge to have more tools, thus the need to buy both hand tools and power tools. You can generalize this from carpenters to all woodworkers to most men quite accurately :-)
Re: Feel-good nonsense (Score:2)
Re: (Score:2)
it would be like a carpenter spending hours to make a chest of drawers open more neatly
Carpenters don't make chests of drawers. Carpenters build houses, stores and banks [youtu.be]; furniture makers make furniture, it's an entirely different profession.
And if you think "coders" don't follow established procedures you don't know anything about writing software.
Re: (Score:2)
Re: (Score:2)
=
I use C/C++ when computer time is important, and use a lot of the fancy tricks to avoid various dumb things.
But I also do lots of "research grade" code where I just wan
Re: (Score:2)
SysAdmins Too (Score:3)
As an Operations Engineer, I'm also working on improving things. Automation to speed up deployments, monitoring to identify bottlenecks, etc. The bad part is when the provided tools don't give me that visibility so I can make improvements, I deploy my own tools (or write my own). It's probably less efficient but I can then work on improving the environment. My current audit script identifies some 34,000 things that can be improved across our environment.
[John]
Comment removed (Score:4, Interesting)
FACT (Score:5, Insightful)
Re: (Score:3)
In 4th grade (early 90s) I got in trouble for something and had to write out something 20 times.
I convinced my teacher that typing was a useful skill. I failed to mention how copy and paste worked. So I said I typed it out 40 times to practice and got a congratulations for that.
Since then my whole career has been slight of hands with managers and code in the background.
That 4 hours invested will 'break even' after 24 times. Maybe it takes a year or two, but after that you're working on 'free' time.
Add in a
Re: FACT (Score:2)
Re: (Score:2)
Shakes fist.
Re: (Score:2)
X < N < Y
where:
N is the number of things you have to do.
X is the most you can do manually without getting really really bored.
Y is the number where automating it breaks even in terms of effort.
But automate it anyway, just in case it comes up again ;-)
Re: (Score:2)
--LOL - I did the same thing with one of my teachers, only I wrote PUNSMENT.BAS to do it
Re:FACT (Score:5, Informative)
Oblig. https://xkcd.com/1205/ [xkcd.com]
Re: (Score:3)
It's not the coding that drives me nuts with automating stuff, it's the testing/QA. You do make sure that all mission critical things you do are tested to make sure the automatic process isn't doing something wrong, right? Ideally with another party (internal or external) acting as QA.
I heard Boeing is hiring (Score:3)
You might consider sending your resume to Boeing?
Re: (Score:2)
I originally was going to make a crack about whether the OP works at Boeing. But I have no clue what went wrong there.
I'm not saying I don't QA it, I'm saying the OP seemed to be "automating and forgetting."
Never a waste (Score:2)
So if you only ever have to do it twice, then you just spent 4 hours, plus the time to run the code twice on completing a task that would have taken you twenty minutes.
It's faster in the abstract.
*I* understand.
P.S. Also over time you realize that even if that time it wasn't falser overall you probably learned something to make something similar faster later.
Re: (Score:2)
P.S. Also over time you realize that even if that time it wasn't falser overall you probably learned something to make something similar faster later.
This right here. I'm trying to get my co-worker into the habit of re-factoring when he comes across redundant code in the hopes that he'll stop wasting time writing redundant code in the first place. As such, I hold myself to the same standard. It seems to be appreciated by the rest of the team as they've often struggled to release new features at a good place and haven't had much time to re-factor their own code.
Re: (Score:2)
I was once in a software project with a team of about 6 or 8, where a friend of mine and I were joking: we don't measure efficiency by the amount of code we write but by the amount of code we delete during refactorings.
TL;DR (Score:2)
Efficiency of machine versus of human (Score:2)
Some seem overly obsessed with machine speed. I know one coder who was so obsessed he made a mess out of the software because it was designed for speed over maintenance, and maintenance fell behind, making for spaghetti code that was even slower than it would have been. Penny-wise, pound foolish.
I like software stacks that can be tuned for shop conventions to remove repetitions grunt-work, but others don't seem to care much about that. Why I am I typing the field title and size in in 4 different places? Why
Re: (Score:2)
Re: (Score:1)
There were poor designs in there. A poor design is a poor design.
For example, if you spot a bubble sort algorithm for big datasets, you know its "speed" score is low compared with alternatives without using a timer.
Re: (Score:2)
but often can't be used when later changing things because customizations have been added that would be overwritten
Then your generator sucks.
When generating OO code you use a sandwich architecture. Assume you want to have a Customer class, it would look like this: BaseCustomer <- GenCustomer < Customer.
Initially all 3 are generated, because they don't exist. The "generated" code goes into GenCustomer. Now you have two hooks where you can do your manual customization, BaseCustomer (you most likely neve
Well depends on the situation... (Score:2)
... sometimes I like to do something unbelievably inefficient. Not for production code though.
In college a teacher gave us an assignment to reverse a linked list. I made it recursive. My teacher said: "It's inefficient and that will only works with small lists, you will get a stack overflow". I said "Who cares, it is pretty", Still got an A.
I've said it since my youth.... (Score:2)
- tm Jake, ca 1980
Larry Wall, who created the Perl programming language, and several coauthors wrote that one of the key virtues of a programmer is "laziness" -- of the variety where your unwillingness to perform rote actions inspires you to do the work to automate them.
Larry Wall said it better (Score:2)
Laziness
The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer.
Comment removed (Score:3, Insightful)
Re: (Score:2)
Faster, more efficient, simpler. They usually do go together! It drives me nuts to see 400 lines of code that could have been written in 50! Worse, those 400 lines all have to be maintained, as long as the software has life. Simplifying code is worth a lot more than just the time it saves in clock cycles.
Causation may differ (Score:2)
What code is he looking at? (Score:1)
He clearly isn't looking at the code I usually have to maintain.
The worst part is... (Score:2)
I seem to only find this sentiment in developers after the code goes into production.
There's no thought given to the impact of not using a connection pool or not caching retrieved data or whether or not to overarchitect a complex solution with tons of layers for a relatively simple problem...
It's too bad devs aren't trained to consider runtime aspects of their code before they start developing it...
It's in our nature (Score:2)
From the onset of our teen years, we strive to reduce friction where it would be leaving a chafing feeling.
350MB to render this article (Score:3)
n/t
OCD mathy nerds... (Score:2)
..find pleasure in quantifying things and then trying to OCD-like remove anything 'inefficient"?
News at 11?
LOLZ no coders have opposite motivation (Score:2)
Coders like mental masturbation, piles of unnecessary layers of cruft using libraries they don't understand, bogging a processor that could do billions of operations a second to doing less real work than one a decade ago in twice the amount of time...
Laziness... (Score:2)
Really... (Score:1)
I thought it was no where, and had died out with the advent of near-unlimited computing power.
To quote someone on a Facebook group whom I told Windows 10 is incredibly inefficient and a ram hog. their reply was "Ram? Who cares about ram? What are you, poor?"
Seems that since the advent of really high power CPUs and GPUs efficiency of code and optimization has gone by the wayside. Something that is hanging on by a thread ever-so-slightly in console game development. Once consoles start to have the power of PC
Huh? (Score:5, Insightful)
Coders hate inefficiency? Then who the hell has been programming all the shitty software we have to deal with every day? The software whose every iteration gets more and more bloated (Firefox, Office, etc)? Software which takes longer and longer to load each time a new version comes out, yet is no more useful than what was produced a decade ago? Why does it take 90 scripts to load one web page, including a simple picture?
Where are these mythical beings who want to kill inefficiency? Are they hanging out with Big Foot?
Re: (Score:1)
Coders hate inefficiency? Then who the hell has been programming all the shitty software we have to deal with every day? The software whose every iteration gets more and more bloated (Firefox, Office, etc)? Software which takes longer and longer to load each time a new version comes out, yet is no more useful than what was produced a decade ago? Why does it take 90 scripts to load one web page, including a simple picture?
Where are these mythical beings who want to kill inefficiency? Are they hanging out with Big Foot?
UI designers and Graphic artists, with only minimal training in code development and worse yet programming in a drag-n-drop environment.
Wirth's Law (Score:3)
Coders might have different backgrounds and political opinions, but nearly every one I've ever met found deep, almost soulful pleasure in taking something inefficient -- even just a little bit slow -- and tightening it up a notch.
Garbage!
What gives coders pleasure is a combination of going home early, finding someone else to blame a bug on and getting stuff through acceptance testing.
As for wanting to improve efficiency? There is no evidence for this. Nearly 25 years ago we were enlightened by Wirth's Law [wikipedia.org] which addressed the question why does software get slower more rapidly than hardware becomes faster? and nothing in the intervening quarter century has improved the matter.
Re: (Score:2)
What gives this programmer pleasure is happy users who like using my software, and are able to do cool things with it.
Given that, my primary goal usually isn't optimal efficiency, but rather 100% program correctness (nobody likes a buggy program), and acceptable worst-case performance (nobody likes a slow program either).
Users aren't going to care if my program is a few milliseconds slower than it could be. They are going to care if it crashes or bogs down in certain situations. Therefore it's better to h
Orly? (Score:3)
Have you ever worked at a startup company? (Score:1)
Your primal urge may be "efficiency" to perform tasks which may be easily automated, but the rube goldberg machine making it happen isn't.
*cough* tesla *cough* *cough*
https://forums.somethingawful.com/showthread.php?threadid=3862643&userid=20544
Re: ineffcient use of time sometimes (Score:1)
Existence is an illusion therefore our time has no value, except when we are optimizing a minor subroutine.
Re: (Score:2)
Re: (Score:2)
In my experience there is no difference between a C++ or Java programmer.
Can you give an example where one is more aware about costs and writes better code regarding that?
Re: (Score:2)
I've done both. So I think I have at least some idea.
Both C++ and Java programmers have control of what algorithms they choose. And these higher level choices have the most profound impact on overall performance.
Assuming both C++ and Java programmers pay attention to overall design and algorithm efficiency, it is my opinion that C++ programmers have more control over c
Re:ineffcient use of time sometimes (Score:4, Insightful)
Sometimes the primal urge to make everything more optimized can be a waste of time given the slight performance benefits. Especially when you've spent excessive amounts of time trying to squeeze out that last 1% of performance. Sometimes squeezing the last bit out of it isn't worth the time.
Sadly there are too few programmers who get that concept.
Exactly this. I've argued with a peer many times over making some odd error handling routine that is only called on a catastrophic failure more efficient. Well it takes too long or uses too much memory if you do it this way.... Over, Yea, but if it's ever called, this program is going to die a quick and complete death so why does it matter? Why are we wasting development time discussing this?
It's the same mentality that gets up in arms about how many spaces are used for indentation or if you use a line feed before your curly braces or not. Don't get me started on the "You have TABS in your file, instead of spaces! Or there are too many line feeds here" complaint. Why are we wasting time fixing this stuff after the code is working? Sure, bring it up so we can all agree to do all this the same way, but it's not worth wasting hours of the developers' time to "fix" stuff that isn't really broken.
Re: ineffcient use of time sometimes (Score:2)
Every language should have something like gofmt (https://golang.org/cmd/gofmt/). One and only one canonically correct way to format code, automatically, using an official tool included with the language distribution. Never argue about inane formatting issues again!
Re: (Score:1)
Quite frankly IDEs should display code in whatever format or style the user prefers based on rendering a (possibly incomplete) abstract syntax tree instead of worrying about locations of spaces or tabs in a text file.
Re: (Score:3)
Depends - are you optimizing the code, or are you optimizing the algorithm?
Code is usually small gains, and modern compilers can claim most of the low-hanging fruit themselves.
Data structures can be much bigger gains in some contexts, as using hardware cache inefficiently for frequent operations can cost you an order of magnitude of performance.
The algorithm though - that can easily often make several orders of magnitude difference. That's where optimization and elegance can often really come together. So
Re: (Score:1)
Re: (Score:1)
Maintainability/Efficiency Need to Balance (Score:3)
The most efficient code in the world is useless if it is broke because it can't be maintained.
Re: (Score:2)
There are edge cases where this isn't true, like one-off supercomputing applications that will run for weeks, so spending hours to optimize a small part is worth it even if you'll have to revert back to the non-optimized version the next time you need it.