Absolutely. The funny thing is that this story was repeating even in XXI century because TI-BASIC gives you enough of the rope to hang yourself.
Only when smartphones have become ubiquitous and people stopped trying to program in TI-BASIC the problem, finally, went away.
You can find an example (and discussion) here. Note how topicstarter's friend actually does understand “the concept of mutabiity in Rust”. S/he just reacts like other programmers reacted to structured programming: Us converts waved this interesting bit of news under the noses of the unreconstructed assembly-language programmers who kept trotting forth twisty bits of logic and saying, 'I betcha can't structure this.' Neither the proof by Böhm and Jacopini nor our repeated successes at writing structured code brought them around one day sooner than they were ready to convince themselves.
Thus I'm pretty sure languages with lifetimes, inspired by Rust is the future… only it would arrive in the usual way: An important scientific innovation rarely makes its way by gradually winning over and converting its opponents: it rarely happens that Saul becomes Paul. What does happen is that its opponents gradually die out, and that the growing generation is familiarized with the ideas from the beginning.
Thanks. That is a start. What a horrible piece of code. We have an a and a b like so:
val a = listOf(1, 2, 3, 4, 5)
val b = a.filter { it < 3 }
Then we change the a only to find that our b has changed! That is the kind of surprise I don't want in my code. Especially when code gets bigger and more complex and that hidden corruption is not so obvious to see.
It's a start but is there a useful example rather than a toy demonstration?
Given the fact that creators of Make added such “live views” variables (they don't just happen by accident, you have to write significant amount of code to create such crazy-yet-predictable behaviour) they, probably, had some idea in mind.
I'm not big fan of these “we can write five lines of code instead of ten and save five minutes” tricks because they inevitably end with “… and now we need to spend two hours to understand why the heck the whole things falls apart and produces garbage instead of something useful”.
As you have said already: it's GOTO vs structured programming all over again, only this time we are talking about “spaghetti of pointers” vs “spaghetti code”.
And the same two camps: one claims “spaghetti of pointers” are so cool because they are so flexible and other claims it's disastrous because they are unpredictable and hard to debug!
Perhaps. I was really asking curoli about their statement:
Yes, and even before that programmers did not see the point of high level languages at all, what's wrong with assembler? I'm reminded of "The Story of Mel": The Story of Mel · GitHub
“If a program can't rewrite its own code”, he asked, “what good is it?”
I was just trying to make up an example of something that would be difficult to do in Rust. I wasn't thinking of an actual problem to solve.
But since you are asking, hm, let me think of an example. Let's say we have a model that can by manipulated by multiple graphical input elements. Let's say there is a number that is displayed both as text in a textbox and as position of a slider. And we want to be able to change the number both by typing a new value in the textbox, or by moving the slider. And either way, we want the textbox and slider reflect the new value.
In Java, for example with Swing components, we would have a model that we can add to multiple UI components. Each component can change it, and if it is changed, each component gets notified.
In Rust, we'd have to do things a bit differently. Probably, we have some kind of container that holds models and views and passes messages between them.
UI is an interesting example because so far I've yet to find a good, succinct, and natural model in any language or design.
The current mono-culture thinking in the web world at least (though several of the Rust UI libraries directly model this too) is you have a central application state without any UI concepts, you subscribe to changes in this state, and render the new desired view for this state, and subscribe to events from the rendered views and send them as commands/actions to the state, which then updates as appropriate. Which all looks pretty on a diagram, but it really sucks as your program gets bigger, and doesn't answer how to deal with local cross-component state, for example selecting tabs.
In general, though, UI consistently shows up issues with data consistency, regardless of language. Rust can have some other issues GC languages don't, but in terms of data consistency it just throws it in your face early rather than them showing up as bugs.
Also, if it really was a "live view" filter then it would be impossible to fetch any elements out of b that are greater than 3 -- but that is exactly the behavior seen in the example!
If I expected that code to have reasonable behavior, the behavior would be to see that b's length has suddenly decreased from 3 to 2 after changing a[0] = 10.