101–110 of 274 posts
I agree with the premise, but I'm unsatisfied with the solutions offered. I've worked on both C code and model based designs in Simulink and other more purpose built tools for safety critical embedded systems. First off I can't agree with the notion that programmers don't care about the system. They do. A lot. Especially the good ones. You can't do any meaningful work without caring about the system you're working on…
It is harder to read. Both for humans and for programs.
In code, if you see a mysterious call to "flushData", there are standard ways in each language to discover exactly where the definition of that logic is. In contrast, what is the standard way to discover what a circle means? A dotted arrow?
OK. Maybe your IDE has a right-click "go to shape definition" option. But that's not a language feature. That's a tool feature.
So you don't really have a language spec. You have a tool spec. So the problem is that the language is hard to read because it's not a concrete language. It's a nebulous implementation detail of a tool.
Earlier quoted context omitted.
An excellent framing I saw recently was "I can tell the people who write these articles don't actually want secure code, because they aren't paying me to write it." There's plenty of carefully-written, rigorously-tested code out there. Want to write software for air travel, drug manufacturing, or space flight? You'll have no choice but to write safe, first-rate code. Want a smartphone weather app written to those sta…
Isn't this a tooling and knowledge issue? If I was as productive with TLA+ or model based design as I am with React-Native/Ionic/Swift etc. then we could have a smartphone weather app written to those standards for the same price.
I almost always dive in, but I almost always write my code twice. Essentially the first round is my rough sketch, the second is written when I fully understand the problem, which for me only occurs once I've tried to code it.
Earlier quoted context omitted.
No, we need to use logic and set theory and provide tools for visualizing the implications of our rules and checking correctness of desired properties. There's a strong history and lots of good people working on these things but it's tough to get our message out to working programmers. This article helps but based on the comments we've got a lot of perception work to do :)
There are definitely people making a real effort here, and I appreciate you. But I can't shake the feeling that the reason your task is so hard is that everyone before you has been selling snake oil. "Visual programming", "human-readable software languages" and so on are all just ways of saying "crippled tools". It's not an accident that the examples in the article were WYSIWYG editors, Photoshop, Squarespace, and Ma…
The dangerous unreliability of software is an accountability problem, not a technology problem. Engineering disciplines are regulated so that engineers are held personally and even criminally responsible if they endanger property or lives. Software, being the newcomer, has no such regulation. Instead we have people trying to claim that software deserves a free pass from due diligence because "software is hard," when…
But if we want to pay developers like surgeons and have malpractice insurance, all the better, I guess.
"For Lamport, a major reason today’s software is so full of bugs is that programmers jump straight into writing code. “Architects draw detailed plans before a brick is laid or a nail is hammered,” he wrote in an article. “But few programmers write even a rough sketch of what their programs will do before they start coding.” I almost always dive in, but I almost always write my code twice. Essentially the first round…
I'm sure if architects had the ability to magically conjure building materials out of thin air and try things in real life for free, architecture would involve a lot more trying and a lot less planning.
Of course, I'm sure the article is talking about people just rushing into production code without thought, and I get that is a problem. It's just when people make comparisons like that it can imply this horrendous future where we whiteboard program for months, which is just a terrible idea.
The article didn't mention it, but I think that Excel is a great example of where "the masses" have learned to do programming. It is visual and the effects of changes are immediate.
That's unfortunately a pattern you see with these efforts to make things simpler and more visual. They're great tools, until it gets too complicated, and then you find you'd be better off just writing code.
So we need to write more code to make fancy Photoshop-like editors for the average-Joe programmer who can't see the big picture? That just adds more to the code issue - even Photoshop has bugs you know. The fact that "Few programmers write even a rough sketch of what their programs will do before they start coding" is a soft-skills/experience issue that isn't specific to software. I too can use Photoshop to draw logo…
No, we need to use logic and set theory and provide tools for visualizing the implications of our rules and checking correctness of desired properties. There's a strong history and lots of good people working on these things but it's tough to get our message out to working programmers. This article helps but based on the comments we've got a lot of perception work to do :)
I don't have a silver bullet, or at least not a pithy one. But I don't see how set theory & etc could have led to any different outcome here.