This comes from the Atlantic so I am sure it's garbage. But their main point seems to be that programming is going to move to these drag and drop models. But my thing is we already had this in the form of prolog. Are they just trying to make programming easy to journalists can do it?
>programming is going to move to these drag and drop models I've heard this since the late 90s.
Carter Parker
>problem solving is just drag drop
Kek.
Oliver Taylor
I mean it sounds stupid and not at all feasible to me, I just want to know why it's being pushed as the next logical step.
Aaron Peterson
>ApP InVeNtOr Is ThE fUtUrE
Nicholas Martin
How is it "next"? It's already there, for at least 10 to 20 years. Ever seen that video of Steve Jobs where he drag and drops an app together in Nextstep in 1992? youtu.be/j02b8Fuz73A?t=1445
Or ever seen automator.app? Drag and drop. Lego Mindstorms? Drag and drop. Even kode with klossy showcased something like that.
Or am I getting something wrong here? Drag and drop is already a thing.
Oh, and I'd like to add that most of the stuff there could be condensed into a smaller article. I say the longer the article, the worse the author. Efficiency is key.
Brandon Nelson
It's what they do with their articles. To hammer every problem looks like nail.
Bentley Martinez
>tell journalists to "learn to code" >they start learning to code actually surprised desu
Luis Rogers
I think you're oversimplifying. Fundamentally the article is about declarative vs. imperative programming, and there are several examples presented.
Ian Young
>tell journos to learn to code >they start implementing even more JS on their websites and if they don't, they program a paywall and complain about trump
Owen Reyes
Sure it's the next big thing™ just like it has been since the 2000s, and the 90s, and the 80s. And so on. And I will take "JoUrNaLiSt" advice on programming once they go back to actual journalism instead of clickbait and fud campaigns against people they don't like.
William Parker
what's ironic is it didn't even keep evolving in that direction - RAD has been stagnant for decades. even apple is finally moving away from its own GUI designer with text markup (SwiftUI). I miss the simplicity of shitting out a little dialog that way, but in the end it doesn't save any time because you've got to manually hunt for and set a million properties anyway.
Hunter Gray
>we already had this in the form of prolog.
What the fuck are you talking about? AFAIK prolog is shit like this?
But yeah, drag-and-drop "programming" has been tried for decades and it only works for simple configurations not to make actual new software.
>ITT: people pretend to read an article and give an opinion based in the OP
The article is about the reliability of software systems and how the complexity in the practice of programming can reach points where it is unmanageable by people. It's also about solutions that mostly involve taking control away from programers.
In the first half of the article the author talks about methods for visualizing the state of a program, and also about a compiler from a flowchart based language to a traditional programming language (C, apparently). In the second half the author talks about formal verification methods, particularly TLA+.
In the first half the author is clearly confused as to what could be achieved via the visualization methods. He seems to think that just by providing a way to examine state, programmers might be able to explore all the branching possibilities of the state in their systems. Just by looking at the example given at the start of the article, we can see that there are states that are too far away in time or that are just too rare/specific to be explored even in these kinds of environments. That said, the uses of these tools for productivity gains and improving the teaching of software and programming is promising, and as the synth boomer said, scientists could use better and easier to use tools aside from code in Matlab/Python/whatever. Nothing to do with safety here tho.
1/2
Landon Lopez
The placement of the "model-based design" system in this portion is mistaken. For the author it might seem that graphical tools go together, but the flowchart aspect of this system is clearly not the point. Flowcharts are used because they are an easy but precise way to specify the requirements of a system. The whole point of the system is translating this high level requirements specification into code that implements it. Just another step up in the ladder of abstraction made available by compiler technology, but one that could save lifes. My point is that this section is not about muh UX or drag and drop programming, but another, friendlier perhaps, way of implementing formal methods.
Finally the author talks about TLA+, and the idea of formal verification. Now, idk how anyone could defend NOT trying to integrate formal verification into safety critical systems such as the software in cars. Nothing in this section is about drag and drop programing. From this section I could only confirm my feelings about my colleagues to be. Programers are mostly an antiintellectual and amoral mob, that can only appreciate the advancements given (for free!) by the academic world for building better systems if the tool itself is framed as a way to save time and effort.
2/2
Liam Gomez
Prolog was/is used for expert systems, the ML of the 80's where people wanted to write programs using IF THEN case style. Surprisingly you still need the mindset of programming to do this, they lack the analytical skill for problem solving and no amount of legos are going to help you make something useful.
Aiden Jones
I don't disagree with the idea that analytical skills are needed. I fail to see how is prolog related to the themes of the article? Prolog was meant to encode logical relations in a direct way (and has found it's uses, beyond symbolic AI) but it wasn't meant to formally verify requirements, so...?