Slashdot Mirror
Code is Too Hard To Think About (theatlantic.com)
From a longform piece on The Atlantic: What made programming so difficult was that it required you to think like a computer. The strangeness of it was in some sense more vivid in the early days of computing, when code took the form of literal ones and zeros. Anyone looking over a programmer's shoulder as they pored over line after line like "100001010011" and "000010011110" would have seen just how alienated the programmer was from the actual problems they were trying to solve; it would have been impossible to tell whether they were trying to calculate artillery trajectories or simulate a game of tic-tac-toe. The introduction of programming languages like Fortran and C, which resemble English, and tools, known as "integrated development environments," or IDEs, that help correct simple mistakes (like Microsoft Word's grammar checker but for code), obscured, though did little to actually change, this basic alienation -- the fact that the programmer didn't work on a problem directly, but rather spent their days writing out instructions for a machine. "The problem is that software engineers don't understand the problem they're trying to solve, and don't care to," says Leveson, the MIT software-safety expert. The reason is that they're too wrapped up in getting their code to work. "Software engineers like to provide all kinds of tools and stuff for coding errors," she says, referring to IDEs. "The serious problems that have happened with software have to do with requirements, not coding errors." When you're writing code that controls a car's throttle, for instance, what's important is the rules about when and how and by how much to open it. But these systems have become so complicated that hardly anyone can keep them straight in their head. "There's 100 million lines of code in cars now," Leveson says. "You just cannot anticipate all these things."
It's lousy requirements, fickle customers, bad environments and tools. The code is the easy part.
love is just extroverted narcissism
"There's 100 million lines of code in cars now"
No, there isn't. So this guy, criticizing, is making shit up in order to do it.
Whats he selling?
"His name was James Damore."
If you think "code is hard", then maybe SlashDot isn't the right site for you.
The problem is that software engineers don't understand the problem they're trying to solve, and don't care to,
Then those software engineers are idiots. Standard for my projects and my teams is, when starting a project, before ever writing a line of code, we try to understand exactly what it is we're trying to accomplish. Work with customers to get requirements, prod the customers to figure out the details they didn't think about and figuring out the best compromises when we have conflicting requirements. Only after we've got a pretty good idea what we're trying to do will we actually start coding.
At least not too hard for everybody. But the simple plain fact is that thinking about code above a certain minimal complexity requires special talent. Tools, languages, coding-styles, etc. make no real difference.Those that do not have it ( probably something like 95% of all people) should stay away from professional coding. Incidentally, the same applies to mathematical thinking and reasoning, for example. Nothing surprising here, just too many people writing code that do not have what it takes.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Any experienced programmer will know very well that abstraction does not always make better solutions. The sad truth is that complex problems usually require complex solutions.
To me, it's a machine or tool. Like a hammer. Use a hammer this way and it does something. Use it another way and end up with bruised fingers. It all seemed so simple and transparent and obvious . I just groked it, long before the concept of grok, and I could not for the life of me understand why other people couldn't get it.
What intensified that was the need to read and memorize about a zillion IBM and FORTRAN manuals. That also appealed to my obsessive ADHD side, long before the concept of ADHD. Add the extra ego brownie points when I could describe some obscure feature or function call to the instructor or one of the advanced calculus students and it was a match made in heaven.
The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
"The problem is that software engineers don't understand the problem they're trying to solve, and don't care to,..."
I think they do understand the problem and that's why things generally work, or don't they? I think they do work on the whole.
The reason is that they're too wrapped up in getting their code to work.
To this, I must rephrase:
"The reason is that they're too wrapped up in getting their code to work, as they should..."
Before a single line of code hits the IDE, you plan out what you're trying to solve, the problems you have to deal with, and how the logic will have to act. Coding happens after the "hard" work has been done, once you have a good idea of what has to be done and how to do it.
If anyone thinks that a true software engineer just sits down, starts slamming on some keys and then says "Oh well, I wrote code, let's see how the throttle handles it", then they don't understand software development or software engineering.
Rust will solve every problem known to mankind. In Rust, you don't even need to think about the problem your code should solve. The Rust toolchain will do that automatically for you. When using Rust, bugs are a thing of the past -- they are simply impossible.
This confused me at first as well. Once you've been in the community and built up your karma you may be asked to moderate at some point. For me it just kind of showed up one day as a pull down under each comment. As I have moderated over the years it seems like I am offered the chance more frequently. Probably because I actually do pay attention and try to moderate in a helpful way. Note, now that I have commented on your comment I can't moderate anything in this discussion. That's to prevent me from moderating people down if I am in the discussion itself. Makes sense really.
Be kind, for everyone you meet is fighting a difficult battle. - Plato
Should be the real title. Eg, POTUS can easily start a nuclear war, here are the directions: https://www.bloomberg.com/poli...
Visual programming is the "answer"? Every decade some non-programmer discovers visual programming and says we are all going to be creating programs by dragging blocks around. No, I didn't bother to RTFA.
I write code for the gov and the hard part is when the bug is in the law. The bug might have not been obvious to lawmakers, but when I write my if-else it becomes dead obvious. It is hard because
A) I know what I'm doing is wrong, but I have to do it, because it is written into the law
B) There is no bug tracker where I can submit bugs in the law.
You could perhaps consider providing an example of what you're talking about. Without a concrete example, your submission is anemic I am afraid.
Too hard to think about is good because it means job security for those who can.
It likely also means we should consider dismissing this novel concept of teaching every child to code in school.
It's a rather pointless effort to try and force onto 95% of students when the majority don't get it, and never will.
We haven't solved the hard AI problems necessary to make computers think like us, so we have to think like computers in order to program them, and we're not good at it. This is news?
like programmers wrote programs, the first woodpecker that came along would destroy civilization.
Sorry that's the only (hopefully funny) comment I could come up to contribute (and I didn't even come up with it, I read it somewhere in pre-Internet time!).
When you're writing code that controls a car's throttle, for instance, what's important is the rules about when and how and by how much to open it. But these systems have become so complicated that hardly anyone can keep them straight in their head.
This bullshit argument is unarguably true, but it can be applied to anything, and means absolutely nothing.
There is this persistent myth of the "lone programmer" or "lone inventor", but that is not how things work in the real world.
Even a moron knows that nobody in this blue marble can be a master of every possible field, and very few people can even master ONE specific field. In the real world - where shit gets done, not some sitcom fantasy - you work in teams, so that each member can bring their skillset, experience and opinion to the table, and so that together they can come up with a superior solution.
The design is separated from the implementation, and done in advance. Things aren't done "as you go". The methodology doesn't change midway. Everything is planned, and THEN the plan is executed.
This is how airplanes stay in the air, why you can carry a computer in your wrist, and why I can post this shit on the internet. There are thousands of people working on this shit. Yeah, sometimes they break, but we learn from that and we fix them and make them better.
If things were as bad as these bullshit articles try to make them, we would still be sitting in caves eating shit because "Agriculture has become so complicated that hardly anyone can keep it straight in their head.".
It is an insult to our collective intelligence and human achievement.
Developers should avoid writing code by hand and instead write abstract high-level programs that generate code. This rule aims to reduce human errors and save time.
Which is why we've been abstracting away the hard bits for a while now. We're not manually flipping in digits. We made punch cards, automated punch cards, compilers, and higher level languages.
I couldn't imagine doing non-linear control algorithms with C or assembly. Did simple PIDs in college, understand how to do it and just let Simulink write the DO-178C and MISRA 2012 code for me. It's already certified for critical code.
It's also easy to build a plant model to unit test against and add in SIL/MIL/HIL level testing. I let Windriver and other compilers handle the assembly generation. Again, they're already tested and certified.
"100001010011" and "000010011110"
Great guys.
Software is still in that era. Each machine built then was made from the scratch, with custom built parts. There were no standard off the shelf components then. We still don't have a standard reliable gui that can be assumed to be supplied by the OS in linux. Windows guarantees a mouse/screen but it can't even give multiple customizable desktops in 2017 Windows 10.
If I am designing an electric motor, I don't have to worry about the anchoring bolts. I know the power and torque and weight of what I am shooting for. I will simply pick from well tested components library a set of four, six or eight bolts with known tensile strength, corrosion resistance, temperature profiles, cost and provide for holes large enough for the anchor bolts. If I am designing the controller for the same damned electric motor, every interaction the motor has with the micro processor that controls it is custom made. Several device control muPs each with its own protocol for data, feedback and error handling.... If I am designing a mortgage consolidation program for the asset management of a bank, every data feed I get, every data output, feedback, and error handling is custom built. That is why software reliability is poor, security holes are ill understood and development is insanely complex.
Having said that, we have made great strides in standardization. File IO within a system, of https requests across the network is getting standardized. XML is helping a lot. Entrenched players deliberately mess up interoperability with ulterior motives. But as the end users become more and more aware of switching costs and vendor locks, eventually these things will dry up and interopera bility will improve.
Well tested, well understood components are the key to building large, complex but reliable machines. We are getting there. Serious computation is a mere 60 year old technology. Hardly two and a half human generations, coping up with 45 generations of computational technology evolution. It will take a couple of human generations before we have senior managers who grew up with technology who would not fall easily for the sales tricks and demand real tested true interoperability and well tested well understood components.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Not true at all. The computer used by code breakers in WW2, for example, had no assembler. So of course they had programming forms with columns for each bit in the instruction word. I did something similar in the 1980s for a bit-slice based disk controller. THe cross-assembler that was available as the time ran on a VAX and the company could not afford it.
Time for bed, said Zebedee - boing
I read the article on Friday and remember how it was trying to propose some kind of other way to visualize the behavior of code, and thought it was pretty cool idea. Then I remembered the first anecdote in the article about how a 911 calling system crashed because the unique ID's hit their max value. If one were to create a visualization of the system, it would still show "green" for when the system hit their max value for unique ID's. So I don't think that the solutions proposed fixes the problems at all.
I also didn't like how it bemoaned how programmers will start programming a little bit before working out all of the architectural details. That's probably true for a brand new system, but for adding a new feature, I find it much more beneficial to poke around a little bit to see what's possible with the pieces which are already in place. It's a very helpful way to get my mind to think about parts of the code with which I am unfamiliar with.
I love thinking about code.
Since the invention of hexadecimal. It was such a pain, working with all those 1's and 0's on your screen. Lots of cutting and pasting to get anything done. People looking over your shoulder at your screen couldn't tell what you were doing, though, so browsing for porn at work was easier.
Have you read my blog lately?
may be summarily dismissed as newsstand magazine click-bait.
The gist article may have been relevant in 1988, or 1978, or 2008, or any particular decade since the 1940s. Only the details need to be changed to reflect the latest cherry-picked failures. One does not predict a Zombie Apocalypse because of a few cases of leprosy.
Functionally sound and working software pervades nearly every aspect of our lives. Practically every aspect of nearly all manufactured product we consume is designed/made/shipped/distributed and delivered utilizing software. That we continue to have occasional failures is simply a sign that we continue to push the boundaries of what we attempt to do with it. No one was promised a utopia. For that, we must wait for the AI Overlord. (And I, for one, look forward to welcoming.)
The author's view is that if you can't look over someone's shoulder and understand what they're working on, then there methods must be broken: "it would have been impossible to tell whether they were trying to calculate artillery trajectories or simulate a game of tic-tac-toe". Let's ignore that the same goes for any hardware development. Likewise, we can't distinguish between a man working a math problem on a plane, and a man carrying a bomb on a plane, so math must be broken, too?
IDEs ... did little to actually change, this basic alienation
As far as I can tell, although they do make the day-to-day job of programming computers much easier (and yes, I did start coding before there were any IDEs), they've made things worse in terms of expectations. Even as getting programs correct is getting harder, the people who don't do it are looking at the tooling and the support, and the how simple the very basic stuff is, and thinking, "this looks easy, therefore it must be easy, therefore if this guy can't get it done in a couple of hours, the only possible explanation is that he's incompetent."
Proud neuron in the Slashdot hivemind since 2002.
You shouldn't be in the field of software development. Whoever uttered that statement should be fired from any programming related job.
It does require a special sort of insight (eg. being able to keep track of state and thinking much more abstractly about computers than what you're used to) which can be both acquired or natural but is only improved by practice but it's by no means impossible to think about code and what it will end up doing. In most cases, programmers have thought about ways the program can fail (eg. buffer overflows) and either think it's no big deal (it will never get connected to the Internet) or have to give up finding solutions for it due to lack of time or funding.
Custom electronics and digital signage for your business: www.evcircuits.com
You're forgetting that much of the environment your code has to work in consists of more code. And while we often do out of habit, we really cannot ignore that forever. There's also that debugging is said to be twice as hard as writing it in the first place. So if you're being at your maximum cleverest while writing, you end up with a problem debugging that code. "Coders" tend to be in love with their cleverity. And the people who're just writing code because it's a job typically aren't that clever in the first place. That's all before the corner case coverage incompleteness theorem and all that what follows from there.
So yeah, the root of the problem is complexity, too much of it. Not that TFA has a sensible answer. In fact, while they correctly identify some problems, their solutions are too clever by half, also. Buncha ironic hipsters.
But anyway, this is a deep and thorny problem that so far we're only compounding. We certainly haven't seen the last of it yet.
In about 100 years, the codebase of most simple appliances will start to resemble the size of the entire genetic material for a small insect. While no human can possibly think about the entire DNA sequence for even a simple creature, we start to think of which alleles can be switched "on" or "off" and cut and paste sections using CRISPR from related codebases. This is the ultimate in "script kiddie" hacking, but that's where we are with complex code like genetics, and that's where we will be with manmade code as well once it reaches hundreds of billions of lines of code.
You might think, "no human can analyze or write that much code!!!", and you would be correct. However, we will start using more and more automated tools. We will have programming interfaces where you can just talk to it and roughly describe what you want and it will spit out a portfolio of possible solutions like a commissioned artist might at their patron's behest. "I want my self-driving car to prioritize skipping potholes over saving running over kittens!". And while those solutions will look polished and smooth, it will be anything but in the underlying code and employ not just hideously complex code but hideously complex data like random forests or gradient-boosted regression trees with tens of thousands of trees and millions of leaf nodes for the simplest of classification questions, "is it a pothole or a kitten?".
It will be akin to those Frontpage and WYSIWYG web editors that spew out hundreds of thousands of lines of HTML code for the simplest of web pages. We will move to an FDA-like deployment process, where no one reviews the code but we just test it in simulation, and then in real life with mice and then monkeys and then humans. It will take 5-7 years to release code because no one will understand what it does or its long-term side-effects like modern pharmaceuticals. The QA-process will just involve large-scale clinical trials and zero code review.
After attempting to read through the 100 million lines of article I gave up around the point where they started talking about writing flowcharts to represent code. But they did mention this was connected to a Kickstarter project called Light Table (which apparently somehow inspired Apple's Swift??). So I watched the kickstarter video ( https://www.youtube.com/watch?... ) and the kickstarter page ( https://www.kickstarter.com/pr... ) and I still don't have a clue what it is, what is new about it, or how it makes programming unnecessary. Are we supposed to be spending writing tools that write programs instead of writing programs? Aren't we already doing that?
Maybe someone with an entire day of their time can read the article and decipher what it is they are talking about.
It sounds to me more like they are making code harder than it actually is.
Anyone looking over a programmer's shoulder as they pored over line after line like "100001010011" and "000010011110" would have seen just how alienated the programmer was from the actual problems they were trying to solve; it would have been impossible to tell whether they were trying to calculate artillery trajectories or simulate a game of tic-tac-toe.
All I see it blonde, brunette, redhead...
"When information is power, privacy is freedom" - Jah-Wren Ryel
Ah, yes? The only point of that was marketing and some politicians simulating being "modern" anyways. And some nice rip-off-type business models for "coding schools".
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
"Why do we pay IT, everything is working without their help." "Why do we pay IT, nothing is working". Sub in developers for IT. YMMV.
Fat, drunk, and stupid is no way to go through life, son.
Yes programming is difficult. Being creative logically, understanding the big picture and where the project is going, being able to get lost for hours in your head and staying focused as your tracking variables and flowing data ya, it’s hard. It’s also exactly why this silly notion that “everyone needs to learn to code” is simply asinine and coding boot camps are a lie. Different people have different skills
Well, I have when doing I/O to specific hardware components. But that is about it. For actual code, I always had at least an assembler.
I do agree that the stance of the article is mostly BS, also because you _cannot_ think like a computer. Computers are exceptionally dumb in a very fast fashion. No human can think like that. Smart humans can think in a smart and complex fashion pretty slowly. That is nothing alike computers.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I wonder if the existing method of writing software isn't just running into the limits of general human cognition.
We can conceptualize complex systems or tasks, but to make software that does them requires a very low level of understanding of how it will work and gluing together many low-level functions to get to the finished complex system.
Fixing a system like this when it doesn't work as expected requires an encyclopedic level of knowledge about all of the low level pieces as well as the larger picture of the entire system.
I'm sure there are people who are better at this than others, but maybe we're just reaching the point where the systems are so large and there are so many of them that we lack the access to the human resources or methods of automation capable of managing them. Ordinary, even conventionally above-average people, simply aren't capable of effectively managing the complexity involved.
The problem is that software engineers don't understand the problem they're trying to solve, and don't care to
I thought the article had some issues but this one really made me mad... I have worked with scores of professional developers who indeed spent a LOT of effort trying to understand the domain (problem) we were writing software for, most of them would push back on requirements that made no sense for "solving the problem" when we knew it would hinder (or at least not help) users.
Also on a sidenote, the TLA+ stuff sounded interesting but if you go find the webpages that describe that, they are pretty old and have not been touched in years... it sure seems like yet another flash in the pan magic bullet for creating software. Has anyone successfully used TLA+ on projects in recent times?
I don't think developers are inherently against mathematical models to help define systems, it's just that invariably the models we have all seen applied tend to fall down trying to describe the complexities of real software. I mean, remember the UML craze (not mentioned in the article), which had significant efforts trying to build software from a model... but the major issue (at least at a company I worked for) was that the final code was way to complex to be represented in the model. The model became just another kind of requirement that after some time failed to track with the results.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
These were not really computers in the modern sense. No capability to run general-purpose code. Also, if I remember correctly, they basically had people doing the job of an assembler between the coders and the machines. Might even be were the name comes from.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Lawmakers are what happens when people think their written word defines reality. Alternatively they start writing holy books, which is even worse.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I read the article on Friday and remember how it was trying to propose some kind of other way to visualize the behavior of code, and thought it was pretty cool idea. Then I remembered the first anecdote in the article about how a 911 calling system crashed because the unique ID's hit their max value. If one were to create a visualization of the system, it would still show "green" for when the system hit their max value for unique ID's. So I don't think that the solutions proposed fixes the problems at all.
I also read it Friday, and also thought that idea was interesting - as mentioned in the article, Swift Playgrounds has something a bit like that, because after running a session you can see some values charted over the lifetime.
That to me is the key, not that you can simply visualize the software but that you see it over time - so in that case it wouldn't be all green, you'd see the software over the lifespan of projected use, and at some point see red when the ID boundary was exceeded... at least that's how I see such a visualization factoring in time.
I still think it's an interesting approach to try and model and visualize software behavior over time, perhaps we'll see some more analysis tools around that, which hardly anyone would use just like all of the other code analysis tools we have today. :-)
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I've seen roughly an even mix of both. Bleep happens.
As far as car control software, back in the days, you had to keep your hardware controls fairly simple for manufacturing costs, repair-ability, and to have tolerances for wear and manufacturing defects.
Software removed many of these constraints and so companies have stretched software to its limits in order to be competitive in terms of performance and fuel efficiency. It does NOT have to be complex, but you likely will be sacrificing metrics to gain simplicity. Perhaps much if it can be reworked to be simpler, but that requires a lot of software and hardware engineering effort, and may delay car models. At least the current code is road-tested.
In short, there's no free lunch. Now that more functionality of an automobile has moved to software, companies are flummoxed because they are used to focusing on hardware. Their cheese moved:
Welcome to the Change Club. The first rule of the Change Club is that the first rule will change.
Table-ized A.I.
Too many developers solve the problem at a low level programming domain language and constructs. They need to learn to solve the problem. Decompose he problem in natural language with natural language abstractions. Test Driven development, particularly using BDD for requirements and Unit Testing is a very effective approach that allows the implementation to be varied.
job security for those who can
I doubt it. More like taking the blame for everything.
Proud neuron in the Slashdot hivemind since 2002.
Tight code that just does the job and no more can be done, but the writer, or the guy standing over him, has to *deeply* understand the problem, from the inside. Frankly, I think it's easier to teach the problem-expert programming than it is to teach a programmer the problem.
I worked for my local water/sewer utility, first as their IT head, then moved back to my first degree, engineering - but it was my IT that got me the engineering job, which was putting all our pipes, valves and other assets into a giant database that was also a "GIS", a map. We had already for years been switching to mapping with CAD, and had various macros and programs written within its development environment to make, say, placing a hydrant a single graphic operation.
So I got the one contract CAD programmer to greatly expand his "macros" into a comprehensive drafting system where the draftsman first drafted the underlying network, then all the pipes and other assets on top of that; the database understood the connected network and could trace it, analyse flow. The coding from the one former draftsman, who completely understood the drafting problem and the needs of his fellow-draftsman customers hired a couple of young programmers,made sure they were doing what his customers needed, and was done in a year for about $400,000. The IT department charged me much more than that to just supervise him and make sure he "met all corporate standards"!
Well, the IT and Mapping departments hated this software because it ran on top of the CAD package, Microstation. They insisted this was at end-of-life and all mapping was going to an "All-GIS" environment in the 800-lb gorilla of the GIS market, ESRI. They went over me (multiple levels) to get a huge project approved to replace my little $400K amateur effort from a mere engineer.
Long story short, that project peaked at 35 staff, went 3 years, spent $8 million and generated I can't imagine how much code because it was all with Microsoft programming tools that load in whole libraries every time you do anything.
At that point, management realized that it was another $2M-$3M to finish it, and testing showed it would offer no improvements and maybe some slowdowns.
They cancelled it.
My $400,000 CAD software is still there, not yet "end of life" at the age of 20, some 8 years after it was declared good-as-dead. Pity about the lost $8M. What I could have done with that! (There is, by the way, no sign of the whole CAD market vanishing in favour of GIS. Not surprising. Our IT and mapping people also picked Microsoft Silverlight as a winner.)
Whenever I read about giant code messes, I wonder if good, working software for the same problem would be less than a tenth that size. And it isn't bad programmers, it's bad project management. You should never put IT in charge, always their customer. This absolutely requires IT-savvy customers, and these horrors will go on until we get some.
We, at Special Education for the Santa Clara County Office of Education, couldn't agree more with you!
For the valuable /. users that might already have read the following, please note that there is an important update.
IMPORTANT UPDATE:
Special Education for the Santa Clara County Office of Education has invested money to buy Chris a new chair:
http://www.keynamics.com/image...
Information about Christopher Dale Reimer and autistic people:
Autistic people have obsessions about things normal people don't care. For example, one of our autistic patient went haywire when he realized that there was a penny missing in his pocket change.
To calm him down, one of our educator pretended to have found it on the floor and gave a penny to him.
The autistic patient condition went even worse because he realized it wasn't the same penny!
Chris has an obsession with budgeting every penny. He doesn't understand that most people do not budget to the penny and have a flexible amount they allow for miscellaneous items.
I am Nancy Guerrero and I am Director of Special Education for the Santa Clara County Office of Education. We use Chris' (a.k.a. creimer,cdreimer) picture in our document because he is the hardest case we have ever had to handle:
http://www.sccoe.org/depts/stu...
Our artists were inspired by the low carb diet that Christopher follows scrupulously for the small lunch box and by the picture linked below for the rest. I am sure that you will notice the similarities such as the bump on the side of his chest and more:
https://ibb.co/gVad65
Please be easy on Christopher although, I am aware that some of our staff handling Chris post joke comments here and obvoiusly, the Santa Clara County Office of Education disapprove that behavior vehemently:
https://school.discoveryeducat...
But it isn't Chris' fault if he is the way he is. We do the best we can do with him and he is partially integrated into society. We try to cure his abnormal need for attention but he is kind of stubborn and won't listen to anybody.
Thank You dear users,
-Nancy Guerrero
Microsoft on Visual Studio, an IDE that costs $1,199 a year
Not that I think Visual Studio is helpful or useful or much more than bloat, but supposing that somebody did do the research and expend the effort to come up with something that actually WAS useful in taming software complexity, and it cost $1,199/year (or hell, even $199/year), the first question from management would be, "how do we get that for free?"
Proud neuron in the Slashdot hivemind since 2002.
I've been working on CRUD-centric applications since before the GUI era. And I wonder why we keep reinventing CRUD systems? Most of the "logic" COULD be defined as attributes, such as data dictionaries, and relatively simple "rule tables" that are kept in the database. These could handle roughly 95% of the logic, and most the rest could probably be put in stored procedures to make them app-language-change-proof.
I've seen products that kind of come close, but they get tossed out when the shiny New Thing comes along and kills sales or momentum. People are so scared of being left behind that they throw everything out and start over to keep up with the IT Joneses. I don't really blame them: agism is real and ugly in our industry.
I agree the front-end style keeps changing, such as going from CUI to GUI to Web to mobile etc., BUT most of the principles of CRUD have not changed. Do we really have to throw out the entire CRUD engine to get the latest front-ends?
Techniques like MVC were supposed to separate front-end issues from the rest, but as implemented I fail to see it. They often do or assume data joins in code instead of the database, for example. That's stupid; whey reinvent the database? And they often rely on "scaffolders", which are code generators. If you are relying on an attribute-centric CRUD model, then you don't need to generate app code. Generating code means you failed to abstract ideas into attributes and are implementing low-level attribute handling in app code instead of reading/processing them directly from the attribute/rule tables. They automated bloat, not removed it. (Sure, you'll still need to generate client-side code, such as jquery handlers, but it could be at run-time.)
Maybe CRUD is not as exciting as aerospace and thus has none of the modelling tools and abstraction languages mentioned in the article. It has a reputation as being too simple, which is not really true. Dealing with customer expectations, databases that have built up a lot of tangled cruft over the years, and adapting abstract representations to changing UI fashions is often not easy.
Table-ized A.I.
Has anyone here tried TLA+? Any comments?
Table-ized A.I.
Yes, this is getting much closer to my objection to the quoted piece. Writing a program is essentially constructing a mathematical proof. Can you get from your desired inputs (assumptions) to your desired results (theorem)? Over the years, I've seen CS coursework reduce the underlying background in math, and specifically formal methods like proofs, in favor of getting in there and programming. That's a recipe for producing more programmers quickly, but not necessarily assuring that they have what it takes.
Separately, there seems to be a very strong incentive to let a cool prototype, with all that that implies about its (non-)handling of edge cases, say, turn into critical infrastructure as people pile on to enjoy the initial benefits. We as consumers accept this all the time, and often have neither the time (or think we don't) nor the capability to question things until it's too late.
If code wasn't challenging, I wouldn't enjoy programming.
It is nobodies fault. People have limits and most are most limited when it comes to abstract thinking. That is just the way things are set up in this universe.
I do agree on the author of that piece though.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
It gets better when you are a highly-paid tech consultant. You still have to fight for the information, but you can usually get it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Indeed. And it _is_ reflected in the outcomes. A brain-surgeon with this rate of failure on standard tasks would go to jail.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
“Typically the main problem with software coding—and I’m a coder myself,” Bantégnie says, “is not the skills of the coders. The people know how to code. The problem is what to code. Because most of the requirements are kind of natural language, ambiguous, and a requirement is never extremely precise, it’s often understood differently by the guy who’s supposed to code.”
My reading of the article is that it's not coding itself that's the problem, we can do that, the problem is that we're struggling to develop requirements for more and more complicated systems. As systems become more flexible and their environments more variable, it's becoming harder to write them.
Try it yourself: Stand straight, feet side by side. Prepare to walk. First you will have to shift your weight to one side so that the foot on the other side can be raised. Balance, lift leg, move that leg forward. Did you notice that when moving that leg forward your body moves back to maintain balance? Did you notice your arms moving? Think about how your arms move while walking- do you fully understand what is happening there?
Riding a bicycle is too hard to think about. Playing a violin is... The reality is that we do many things in life without conscious awareness. Thinking is not only NOT required, it is counterproductive. We depend upon reflex actions that are a result of repeated practice. Coding isn't that special.
...omphaloskepsis often...
But with Brian and Steven's help, I guess I can be a computer engineer!
Most of the article is just pointless storytelling that carries no useful information whatsoever. Here's the gist: The author has no fscking clue about programming. The problem: Yes, it's hard to keep all the invariants in your head (not to mention budget and time constraints) which leads to bugs. The proposed solution: Formal verification. So now instead of getting the code right, we just need to get the verification specs right. It's turtles all the way down.
Also, not just any formal verification but some supercool (read: idiotic) graphical system where you create the specs by connecting boxes with lines. Because that's somehow supposed to be easier than working with text. Anyway, good luck finding a mistake in a spec with more than 20 boxes. You're gonna need it with all that visual clutter in front of you.
I wanted to upvote a comment. Can't easily see how to do it.
You don't get to just because you want too. Moderation points are given out randomly to those with higher karma. Its been this way since the mid 90's so likely most of your life. If you see dropdown boxes next to comments, you have moderation points to use. There is even meta-meta-moderation (reviewing the moderation points others assigned). Its been an effective system for reducing the effects of trolling and raising the best comments to the top since before upvote was a word. And /. has had none of the issues that Reddit has had as a result. But maybe you like mob like behavior in your comments?
"Those that start by burning books, will end by burning men."
A rational manager would look at a tool and think, "This is $1199 a year for a developer I spend $150K a year on. Does it make my developer 1% more efficient? If so, it's worth it."
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Yes! In the real world there is often time to do something thrice or more but nowhere near enough time to get it right on the first try. Doing is the quickest way to learn. One of the most common mistakes I see is leaving integration test until after "design" is complete.
refactor the law, its bloated, confusing and unmaintainable.
I tried to read the article, but it was too hard to think about.
Actually, it does raise some good issues, but one corollary of its central point - that as systems grow more complex, the potential for error increases - is that as time goes on, our understanding of how to solve a particular problem will change.
Putting Lovelace aside, we've only been working with software for less than a century. Many of humanity's technologies are quite a bit more mature, stable, and less prone to such error, as we've had time to work out the kinks.
Were this article to be re-visited in 2117, many of the "problems" it raised would no longer exist (though certainly other, newer ones that had yet to be "debugged" would).