SoylentNews is people
SoylentNews
An outrageous, insightful, and sadly accurate commentary on programming. I found this an extremely entertaining read and agree with most of it. It doesn't offer solutions, but certainly highlights a lot of the problems.
"Double you tee eff?" you say, and start hunting for the problem. You discover that one day, some idiot decided that since another idiot decided that 1/0 should equal infinity, they could just use that as a shorthand for "Infinity" when simplifying their code. Then a non-idiot rightly decided that this was idiotic, which is what the original idiot should have decided, but since he didn't, the non-idiot decided to be a dick and make this a failing error in his new compiler. Then he decided he wasn't going to tell anyone that this was an error, because he's a dick, and now all your snowflakes are urine and you can't even find the cat.
Personally, I think things will only get better (including salaries) when software development is treated like other engineering disciplines.
(Score: -1, Troll) by Anonymous Coward on Thursday May 01 2014, @02:00PM
Coders think programming sucks because coders are not real programmers. Coders should not be programming. CODERS SUCK.
(Score: 3, Interesting) by Sir Garlon on Thursday May 01 2014, @02:15PM
The optimist hopes the world will get better when his discipline is treated exactly like other engineering disciplines. The pessimist fears that it already is.
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
(Score: 4, Insightful) by tibman on Thursday May 01 2014, @02:26PM
The article is not about programming sucking. It's about the environment and team a software engineer works within. Crazy business requirements. Inescapable modals to gather information that you KNOW customers don't know and are just going to fill with garbage. Deadlines pulled out of thin-air. Paying for the previous guy's project architecture experiments. Some sort of WaterScrumFall hybrid because someone read the preface of a team management book. All the things around writing the code.
The whole coders vs programmers vs software engineers is just a "no true Scotsman" argument : )
SN won't survive on lurkers alone. Write comments.
(Score: 1) by Noldir on Saturday May 03 2014, @03:54PM
Ah yes, the lovely project management method of scrummerfall. I hope it doesn't catch on too much, all the agility of scrum wrapped in hard deadlines and red tape..
(Score: -1, Troll) by Anonymous Coward on Thursday May 01 2014, @02:16PM
when software development is treated like other engineering disciplines. No one will pay engineers' salaries to fuckwit morons who can't even hack pointer arithmetic without causing a segfault.
Coders are not worth the combined cash value of their bodily fluids.
(Score: 1, Interesting) by Anonymous Coward on Thursday May 01 2014, @02:39PM
Your bridge collapsed because Bob from Accounting set it up in a place where there's no support under one of the towers, Nigerian saboteurs drilled out half the rivets, and then a horde of bored children decided to see what happens when you drive a billion cars over it simultaneously? Wow, you pathetic wanker.
(Score: 2) by maxwell demon on Thursday May 01 2014, @02:45PM
Actually bridges have collapsed because some idiots thought it was a good idea to do collective swinging on them ...
The Tao of math: The numbers you can count are not the real numbers.
(Score: 5, Funny) by JeanCroix on Thursday May 01 2014, @02:50PM
...if they had to build things to be deployed by idiots and withstand forces unconstrained by physics or logic.
Hi. I design things for the military.
(Score: 3, Interesting) by fishybell on Thursday May 01 2014, @04:31PM
Having written software for military training devices, yes: this; times a million.
(Score: 0) by Anonymous Coward on Friday May 02 2014, @07:21AM
I worked with truck drivers...
These guys have LOTS of free time to think up new inventive ways to fuck something up. Then try it on their mandatory 8 hour 'sleep'.
(Score: 2) by Dunbal on Thursday May 01 2014, @03:23PM
" if they had to build things to be deployed by idiots"
I think you're giving a bit too much credit to imported construction workers if you think they're not idiots...
(Score: 3, Insightful) by egcagrac0 on Thursday May 01 2014, @02:21PM
If you want to be treated like engineers, then you'll need to act like engineers.
All changes will need to be initiated by a change request, thoroughly designed and documented, approved by signoff from 6 different departments, and under formal release revision control.
Expect no more lone cowboy lifestyle if you want ot be treated like an engineer.
This is what "software engineering" produces. [fastcompany.com] This team deserves to get treated like engineers... and they probably are.
(Score: 2, Funny) by Anonymous Coward on Thursday May 01 2014, @02:30PM
Never fear, GitHub will fix everything! It's like social and cloudy, bro! Commit to git and the cloud will fix your shit!
(Score: 4, Insightful) by Ethanol-fueled on Thursday May 01 2014, @02:47PM
If you work for a place that does things properly as you suggested, there will already be numerous strict specific guidelines and a version control system for software/firmware departments.
If you work in a place stuck in a garage mentality like I do, where the version control system is e-mail and stashing your fistful of source files in some shared desktop folder on the Starcraft server, chances are the engineering department's gonna be similarly run.
Sure, there's a document-control system and a numbering scheme, but people are going to be pencil-whipping those drawings when they should be checking them, and then once those changes are implemented an ECO or whatever is released but nobody is made aware of it, and then you have a NASA-style disaster where people are building stuff in SI units while the drawing now calls out inches and shit.
tl;dr - Both software/firmware and engineering departments can be run well or like shit.
(Score: 2, Interesting) by Anonymous Coward on Thursday May 01 2014, @03:04PM
Not to mention that if your code fails, you lose your license to make a living. If it causes damage, you go to jail.
It may seem harsh, but that is the way it is for real engineers. From the view of an Information Assurance manager, the most dangerous threat is not hackers, or terrorists, or APTs, or the NSA, or competitors, it is programmers. The vast majority of security flaws are found in code, not in implementation where they should be. Until programmers are held accountable for their own failures, intentional or not, they will be regarded as nothing more than very expensive keyboard pounders by PHBs, and rightfully so.
(Score: 3, Insightful) by tibman on Thursday May 01 2014, @05:19PM
That doesn't sound like software engineering, that sounds like a lot of red tape for no reason. Change requests don't need to be signed off, the new implemented code does! Nobody should be unable or afraid to make changes to the code. If they break something while refactoring a test will fail. If new code is written it is because a test made them do it. If they fix a bug or add a feature, who cares. If business decides they don't want the bugfix or feature then they can reject it. Needing permission to fix a bug is bad bad bad. Those systems are full of bugs because it takes more time and effort to get the change request approved than to just fix it while you're in there.
There is almost zero need for documentation inside of development. The code (and tests) is the documentation. If someone writes a companion document to describe what the system is doing then there is zero guarantee that it is what the system is actually doing. Business can make all the documentation they want but development has no need to ever see it. Saying you need documentation is like saying an architectural blueprint isn't good enough to describe the building and making a word document that describes how the building should look with some photoshopped images. The building architects don't need that word document, the laymen do. Code documentation in software engineering is for people who aren't the software engineers.
A software engineer makes no change to production code unless a test is failing. Period. A software engineer has no problem with someone peer reviewing (they desire it!). I apologize for the ranting, i'll stop. To each their own i guess : )
SN won't survive on lurkers alone. Write comments.
(Score: 2) by Nerdfest on Thursday May 01 2014, @05:42PM
You're my new best friend.
(Score: 1) by mrMagoo on Thursday May 01 2014, @06:16PM
That's because they are describing a CMMI Level 5 shop.
A real one; not the fake Indian kind.
CMMI Level 5 is what you use when lives and billions of dollars are at stake.
A bridge would be a CMMI Level 5 job.
However, Level 5 is way inefficient. It's really kind of commercially unfeasible. Most production shops run at Level 3.
Software engineering needs more discipline and process. However, it doesn't need to have shackles attached to its ankles.
A lot of "traditional" engineers are pretty spiteful towards software, as they see us as a bunch of hippies.
I am in a position where I am trying to marry an ISO9001 process with badly-needed innovation and flexibility. The last few years, I let the process folks have their way.
The pooch was royally screwed.
I now need to force them to let go of their death grip, and work out a less restrictive methodology that will actually allow my organization to create competitive software.
Fun stuff.
I love the guy's rant.
"Good judgment comes from experience. Experience comes from bad judgment." -Originally attributed to Nasrudin
(Score: 2) by egcagrac0 on Thursday May 01 2014, @08:01PM
You're absolutely right, of course. Go ahead and play with it, except it doesn't go live until it's been thoroughly vetted and blessed.
... only "playing with it" is usually not something I see the engineers do. They get informed of a specific problem, and design a specific solution to address that problem while attempting to not introduce any new problems.
That's not a particularly engineerly attitude. The engineers I see make careful notes about what changes they're making and why, and usually have a brief discussion of their design decision (and why any obvious alternates were rejected) in their notes.
Interfacing with the laity is important; they're usually the ones who sign the checks.
(Score: 2) by tibman on Thursday May 01 2014, @11:52PM
The engineers I see make careful notes about what changes they're making and why
You're completely right. One of the very nice things about writing software is version control systems. Any change you make and "commit" has the specific things you changed, a comment why (optional), and usually a relationship to the task that told you to do it (mostly for time-tracking reasons). Then usually someone will come behind you and check what you changed and have a discussion with you about it.
Interfacing with the laity is important
You're right, i was far too flippant. I apologize.
"playing with it" is usually not something I see the engineers do
Now this is a difference between my experiences and yours. In my experience, software engineers enjoy the challenge of attempting to optimize or better organize something. Sort of like the boyscout rule of "leave it better than you found it". They salivate over the thought of completely rewriting a piece that everyone hates.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by egcagrac0 on Saturday May 03 2014, @04:57PM
I think one of the differences here is you're talking about software engineers, and I'm talking about hardware engineers (EE, ME, etc). If we're discussing the idea that the software guys should be treated with the same kind of respect as the "other engineers", I think it's valid to compare the different behaviour patterns.
(Score: 4, Interesting) by c0lo on Thursday May 01 2014, @02:33PM
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 3) by Nerdfest on Thursday May 01 2014, @02:48PM
I was a big fan of :
I would have been proud to have written it.
(Score: 5, Interesting) by Thexalon on Thursday May 01 2014, @02:39PM
In the vast majority of professions, horrific incompetence is tolerated. About the only thing that makes programming different is the number of people affected by an incompetent programmer in an incompetent organization - one stupid mistake in a program and 40 million people are adversely affected, whereas one stupid mistake by, say, a PR flunky and only a few people are adversely affected.
In other professions that can have that kind of effect on things, we have extensive exams and certifications to try to prevent incompetent people from having careers in the field. We don't for programmers, because for the most part the smeg-ups affect people other than the ones who hired the incompetent programmers (users, partner businesses, members of the general public, other programmers).
If we really wanted to change the culture of professional programming, one of the key things we'd have to do is make it illegal to sell software or sell access to an online application that requires users to accept an EULA with language like this:
(Yes, this was taken directly from a real EULA, with the company name replaced to protect the guilty)
Because once you read through it, you realize that what this is saying is that:
1. The software may not work at all.
2. The software may not do anything remotely similar to what it's advertised to do.
3. The software may cause serious and expensive problems for you or your organization.
4. The software may be infringing on patents, copyrights, or trade secrets of third parties. You have no way of verifying this one way or the other, and if it is the case, you rather than $COMPANY are liable for the damages.
5. $COMPANY may know for a fact that this software will cause massive damage to you or your organization. Even so, they are not liable for this damage.
In other words, right now you are allowed to sell the software equivalent of a live grenade with the pin pulled, packaged to look like it's a bag of dog food, and when the grenade goes off it's entirely your fault. Make the sellers of software entirely liable for the consequences of their own mistakes, and they'd demand processes and exams and continuing education requirements to ensure high quality programming.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 3, Interesting) by maxwell demon on Thursday May 01 2014, @02:54PM
Well, just because they write it in their EULA doesn't mean it really holds under the law. There's a reason why EULAs also contain sentences like this (also taken from a real EULA):
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Interesting) by Thexalon on Thursday May 01 2014, @03:41PM
That it exists at all means that there exists at least one jurisdiction where such clauses are enforceable, and since many EULAs also include a declaration of venue (which is common in contracts of all sorts), they can simply pick a jurisdiction that allows those clauses.
EULAs are one of the many places in which companies fleece consumers who don't have expensive lawyers. And even some with expensive lawyers: Now-senator Elizabeth Warren once described one of her regular exercises in her contract law courses as going through ordinary consumer contracts for cell phone plans and bank loans and credit cards and the like, and discovering that neither her, her students, nor her colleagues at Harvard Law could really figure out what they actually meant.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Friday May 02 2014, @03:26AM
"That it exists at all means that there exists at least one jurisdiction where such clauses are enforceable"
Not necessarily. Perhaps the person putting in there put it in there in case there is a jurisdiction where such a clause is enforceable. Also, laws change with time so perhaps the clause is in there to anticipate possible changes in future laws. Perhaps one clause is valid in one location and not another. Sometimes it may depend on the court and the specific judge even.
It's much easier to just put a catch all document than to try and figure out what each jurisdiction allows and work from there.
(Score: 4, Insightful) by Anonymous Coward on Thursday May 01 2014, @03:35PM
Even the oldest, most wise and experienced rockstar of a programmer can never be exactly sure what his code will do, simply due to the fact that it will be compiled by software written by other people, run on operating systems written by other people on hardware designed, built and maintained by other people. Implementing functional requirements (often contradictory, or impossible) specified by other people. He can try to avoid catastrophic failure by building various types of safeguards into the software, maybe turn it into graceful failure, but he will never be able to prevent failure altogether.
So please be a bit more nuanced. Designing and building a bridge, or doing a brain surgery, is child's play, compared to what many programmers in the world today have to deal with. THAT..and the lawyer culture, is why we have disclaimers.
Civilization runs on what we do. I'm sick of being treated like a digital brick layer, after all the effort and expense I went through to learn what I know, while MBAs and banker parasites reap the profits.
Yes I am an Anonymous Coward, and proud of it!
(Score: 2) by dublet on Thursday May 01 2014, @02:40PM
I don't think software engineering as a whole will ever be treated the same as many other engineering disciplines, as generally the building of software is cheap compared to say building a sky scraper, a bridge, etc. Obviously there are exceptions such as automotive and space. NASA's way of working [ed.ac.uk] outlines the "sacrifices" that have to be made in those sorts of environments.
"If anyone needs me, I'm in the angry dome. [dublet.org]"
(Score: 4, Insightful) by TheLink on Thursday May 01 2014, @03:09PM
Civil Engineering:
Design Phase costs about 10% of Build Phase
Build Phase involves tons of construction workers and heavy machinery.
The blueprints and plastic models are way cheaper to make than the Real Thing.
Management often doesn't mind spending a bit extra to get the design better, because the budget only allows for one big Build.
Software Engineering:
Design Phase costs more than 1000 times the Build Phase.
Build Phase involves the programmer typing "make all" and going to read SoylentNews or fetch a coffee or do some sword-fighting.
The "plastic" models cost as much to make as the Real Thing.
Management often sells the blueprints/plastic models as v1.0 because they compile and "kinda run" and the budget only allows for one big Design...
It should be no surprise then that the "plastic" models regularly fail.
In the case of NASA they are willing to spend more time and resources on the Design.
(Score: 4, Insightful) by githaron on Thursday May 01 2014, @03:21PM
You are forgetting that software development tends to have constantly moving target. Building a bridge does not.
(Score: 3, Insightful) by maxwell demon on Thursday May 01 2014, @02:41PM
I disagree with the claim that those intentionally obfuscated languages/programs are a sign of "destructive impact on the brain". It would if people used such code in production, but (I hope) nobody does that.
If an architect likes to build card houses in his free time, I don't consider him a bad architect for that, as long as he knows that his card houses are card houses and not real buildings. When he delivers a card house as my new home, then I'm going to question his sanity.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 4, Insightful) by Thexalon on Thursday May 01 2014, @04:00PM
Oh, but in the software business, this happens all the time. I've picked up well-paying contracts because of it.
There are 3 causes of this phenomenon, in a nutshell:
1. Because software is largely invisible, a card house looks, to a layman, completely identical to a real building (or even better, because they could focus on really cool painting on the outside rather than silly stuff like foundations or load-bearing walls).
2. The Dunning-Kreuger effect means that the programmer building the card house often truly believes he's doing the same job as a programmer building a real building.
3. All else appearing to be equal (see 1), a layman purchaser will choose the lowest bidder. Since it's a lot cheaper to build a card house than a real building, the card house will nearly always triumph - until the day when a good gust of wind comes along.
And after that is when folks like me can come in and fix it for a price that is much higher than it would have cost to build it right in the first place.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 4, Insightful) by Lagg on Thursday May 01 2014, @03:17PM
As subject says I've been a freelancer for a decade+ and am currently trying to exit this career path for reasons that will momentarily be clear. I could not resist nodding my head in sympathy for most of that article and I do not sympathy-nod easily. Inheriting code is like inheriting a school cafeteria from the lazy and worthless janitor that just got fired most of the time for me. I'm not trying to claim to be a special little snowflake that writes perfect code but with all my experience and forced learning (as a result from not only fixing my mistakes but tons of others') I would like to think I know my shit enough to write clean code worth admiring and being able to tell when others write clean code and respect them for it. The number of my predecessor fellow programmers that I have respected throughout my freelancing career are vanishingly small and these respectable individuals are only becoming more rare as this fad of outsourcing becomes more prevalent. Which leads me to my next point:
No. Treating programmers like normal engineers will just result in stuff like what you saw with healthcare.gov until you know what "treating it like other engineering disciplines" entails. For one thing the absolutely insane deadlines will need to stop and most bureaucrat infested companies will not allow that. Secondly, it requires paying people what they're worth. Again, good luck getting that past the MBA pricks which leads me to the third point: Stop outsourcing, you stupid pieces of shit. Would you outsource the engineering and implementation of the crane used to hoist firefighters up to burning buildings to a guy in Nigeria that also runs a spam mail server on the side? No you wouldn't. So what makes that okay for the software that runs in the control panel of that crane? On top of that you'd have the normal strict guidelines that other engineers like those in hardware deal with. Those engineers usually get sufficient time to learn those standards. Even in the strictest job because the people paying them know how much of a liability it is if they screw up and that crane rockets a firefighter into a skyscraper window.
I feel like the submitter has never dealt with this hell. It's all too easy to say "Oh yeah they should just be treated like other engineers. That'll fix it!".
Oh, and hilariously enough the C++ snippet in the post is something a seasoned programmer won't do. Because endl flushes the buffer in addition to writing a newline. It makes things slow if you use it to write a bunch of lines out to any file stream. But that isn't obvious and many people don't know it because of things already mentioned in the post itself.
http://lagg.me [lagg.me] 🗿
(Score: 3, Insightful) by bradley13 on Thursday May 01 2014, @05:35PM
The biggest problem we have in software is overly complex, continually changing tools. In a sense, we do it to ourselves. Consider the obvious example, web development:
Around 1997, we used CSS/1, HTML/4, along with Javascript and some antique version of PHP. Interweaving four different languages with totally different syntaxes and semantics - stupid, but it's what we had. On the positive side, the languages were individually small. CSS/1, for example, was completely specified in under 100 pages.
What do we have now? We still have the unholy mix of languages. But they have individually become huge! You cannot even find a clear definition of the current CSS standard - it's a moving target - but the specification of all the different parts runs to thousands of pages. We haven't cleaned out the marsh, we've just built skyscrapers on top of it.
On top of those rickety skyscrapers, everybody uses frameworks - Apache alone has dozens, and there are plenty of others. Essentially all of these are in continual development. So we build software systems on frameworks, following absurdly complex specifications, using an unholy mix of languages that just happened accidentally, sort of. What a wonderful way to produce reliable systems.
In the end, programmers who want to "stay current" spend too much time adapting to their changing tools and frameworks, and too little time actually developing software. More, the immense complexity of the tools and frameworks makes it almost impossible for average or mediocre programmers to be productive. At best, they settle in some particular niche, work there for 10 years, and then discover that they have become unemployable.
And the good programmers? We cheat, each in his or her own way. My personal cheat is to avoid frameworks. If a project requires framework-like internals, it is more efficient to create something specifically tailored to the project, rather than to import half-a-dozen gigantic, overly complicated, everything-to-everyone beasts. I would even submit that the reduced complexity leads to more understandable and more reliable software.
Web development is the worst, because it is the most rapidly evolving. However, the normal programming world isn't a lot better: Tools, languages, libraries and frameworks - all continually evolving. It's all well-meant, of course. Ralph really needs JavaFX. Anne really needs the newest features in Santuario. But Bill and Sue and James and Sarah? Their software doesn't work anymore with the new versions; they've got to learn what's changed, and fix previously working systems.
Don't get me wrong - I love technology. I love programming. But really, the software world needs to reach a certain level of maturity. Provide stable tools with longer lifecycles, throw out 90% of the frameworks and replace them with guidelines (think: Design Patterns) on how to solve certain types of problems. Let software developers develop software, instead of struggling to stay current on 20 different fronts.
/rant
Everyone is somebody else's weirdo.
(Score: 1) by nwf on Friday May 02 2014, @05:17AM
I think part of the point of making software more like engineering is that it would prevent exactly that sort of outsourcing. You could only contract with licensed software engineers, which the random guy from Nigeria wouldn't be.
Large software projects nearly always end up like healthcare.gov when done by large corporations and the government. Something about corporate culture that's mostly use to dealing with non-technical requirements and solutions. I've seen it time and time again, which is why I don't work for a large corporation or the government anymore.
The thing about software is that since it can be reproduced cheaply, and you can see the result of your effort almost immediately, it fuels rapid innovation and new ideas. I don't think people are willing to give this up to make software significantly more engineered, except on high-consequence projects.
(Score: 0) by Anonymous Coward on Thursday May 01 2014, @03:22PM
I picture an insane clown hitting himself in the head with a metal pipe. After that, he creates Java frameworks. Then he hits himself again. Then he works on a framework. That's the only explanation for Java frameworks that I've ever been able to come up with. How else could they be so over-engineered, crazy, unstable, and in a constant state of change?
I think this metaphor could be generalized to a lot of other things related to programming as well.
Exercise: Pick a dozen or so popular programming languages and determine how to find the length of a string. Then compare and contrast this insanity with the clown metaphor. If we as an industry can't consistently pick one way to get the length of a string, how can anything else not be crazy?
(Score: 2) by bradley13 on Thursday May 01 2014, @05:51PM
It's the same anywhere. Consider web programming: I can't even begin to guess how many frameworks are out there, being developed by how many different organizations. I've been in and around the field for a long time, and just today I saw an ad for an "entry level" development position naming stuff I've never heard of.
The Microsoft world is only marginally better, in terms of overall complexity, and comes with the price of being tied to a specific vendor.
Everyone is somebody else's weirdo.
(Score: 2) by Bot on Thursday May 01 2014, @06:47PM
It is only a matter of discovering the real motives behind a result.
Implement an app on a light, concise, high performance, secure, scalable framework, sell it to your client, see your client perfectly content and not needing you for A long time. Or ever at all if the son of the client is a bright guy and starts hacking some added functionality.
Implement an app on a bureaucratic java framework and you will have the client depending on you forever.
Also, the COBOL way of creating programs is insane for the single man's project, but could actually help in an organization where its bureaucracy maps well against the structure already there.
Account abandoned.
(Score: 2) by tangomargarine on Thursday May 01 2014, @08:15PM
obligatory xkcd [xkcd.com]
"But my way is the RIGHT way!"
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 3, Insightful) by RobotMonster on Thursday May 01 2014, @05:34PM
Programming is like banging your head against a brick wall, except with fewer opportunities for reward.
(Score: 1) by SplawnDarts on Thursday May 01 2014, @08:44PM
The problem with programming, and this is not really news, is that it doesn't scale up with size or down with programmer intelligence/capability.
Yes, in theory you can use any number of techniques to modularize and create interfaces so you don't have to know everything about everything to change the code. And those techniques plain and simple DO NOT WORK. For every successful example of modularization, there are 20 failures. Just look at language standard libraries - about 1/10th are both functional and easy to use. About 3/10ths are theoretically functional but a complete shitstorm to actually use (STL anyone?). The rest aren't even really functional. So for a very well understood problem on which we've spent about 60 years trying to modularize it, roughly one attempt in 10 is successful. Failure rates are obviously higher for things on which less effort is spent, like your code.
Where does that leave us? Well, if you can't really modularize then the key programming skill is to be able to retain in your brain the full machinations of whatever Rube Goldberg program you're working on so you can make changes and find all the consequences. Great - that's a skill that's about 0.9 correlated with IQ. Only problem: not enough high IQ programmers to go around. So management hires some guy who's merely average, and he's be unable to hold it all in his brain and as a result screw up left and right. So management puts him in a pair with someone who is smart enough, and now that person's output drops and the original dude's still not smart enough.
The problem, it appears, is largely unfixable. In other words, the amount of complicated, working code the world can have is finite and dependent on a small (relative to all programmers) pool of people.
(Score: 2) by maxwell demon on Thursday May 01 2014, @10:41PM
I honestly cannot understand the issues that most people seem to have with the STL. For me it's one of the best libraries. Sure it's not perfect, but it's quite close to it.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1) by SplawnDarts on Thursday May 01 2014, @10:54PM
Because it generates code like (taken from an example - maybe not optimally readable): // Dump the list to check the result
for (list::const_iterator citer = mylist.begin();
citer != mylist.end(); ++citer)
{
cout (*citer).m_iData endl;
}
Instead of (python):
for item in list:
print(item)
(Score: 1) by SplawnDarts on Thursday May 01 2014, @11:01PM
OK, HTML formatting mangled that (my bad for not checking)
vs (python)
(Score: 2) by maxwell demon on Friday May 02 2014, @06:17PM
In C++11, you can write
Not that much more complicated than your Python variant, is it? But note that (both in C++11 and in Python) this sort of loop needs specific language support, while the STL was written are pure library for C++ (and only afterward integrated into the C++ standard library). You cannot add new for loop syntax using a library.
Anyway, your examples are not equivalent: The equivalent code in C++89 to your Python code would be cout . I wonder if you intentionally made the C++ code do something more complex to increase the perceived complexity of C++ (also your use of (*citer).m_iData instead of the equivalent but simpler citer->m_iData hints in that direction).
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by maxwell demon on Friday May 02 2014, @06:19PM
Damn, should have been preview instead of submit ...
Of course the corresponding C++89 line would be
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2, Interesting) by drk9000 on Thursday May 01 2014, @10:25PM
I am from the other side of the spectrum, let's call it "physical world engineering" and I can assure you, it isn't the wonderland full of simple, obvious decisions and sane management that it seems that some programmers make it out to be. I do know how to code (almost all competent engineers can nowadays) and although I have never worked on a massive code base that I had written less than even half of nor do I consider myself a professional programmer, I can parallel many themes of the article with frustrations that I do have to deal with.
Many times, before even starting a design I might have to read 10 different, snore inducing standards, created by different standards bodies who probably all have not heard of each other and then choose which of the conflicting standards are most relevant. Team members on projects frequently go rogue, eschewing best practices because they were under a tight deadline or because they had lost all interest in doing their job correctly and many, many things have to be revised and usually not just once. There are layers and layers of bureaucracy too and managers (usually who got the job through connections) capable of stupidity and counter-productiveness that is nothing less than astounding. I would also add that many of our functions (that probably should done with code) are typically done with a mind blowing number of Excel files that are as a rule never: documented, have any relevant function, organized in a logical manner or even named correctly with anything other than a date stamp and a one word description like "Materials". And to boot, at the current moment we are having a much harder time finding work and when we do the pay is not nearly as good.
If you knew the kind of organizational chaos that went into the design of the fancy airplane you are boarding for your family vacation you would probably never step foot onto it, I personally have to be medicated before putting myself on a plane as a direct result of working with Boeing for years. Yet, airplanes are a safe, affordable means of travel, and will remain so. I think what you are all complaining about is not an exclusive problem for programmers. You should be payed more, but don't argue it by badmouthing other professions and making them to seem less complex, we are all in this mess together.
(Score: 2) by Reziac on Friday May 02 2014, @02:57AM
I think that's generally true of any industry where one side of the table gets to say what they want and how they want it, and the other side of the table is tasked with implementing it but lacks authority to change what doesn't work.
And there is no Alkibiades to come back and save us from ourselves.
(Score: 0) by Anonymous Coward on Friday May 02 2014, @03:26PM
That was actually well written, unlike most rants. :)