Rust: Back to the Future

community
#1

Blandy, Jim; Orendorff, Jason. Programming Rust: Fast, Safe Systems Development (p. 121). O'Reilly Media. Kindle Edition.

I'm slogging through the the "Programming Rust: Fast, Safe, Systems Development" book. I had a psychedelic flashback to 1983 when I took a course on "Structured Design" (NOT Structured Programming!) based on Yourdon and Constantine's book.

On page 121 of this Rust book, section "Taking Arms Against a Sea of Objects", the author points out the problem with assuming that your compiler/interpreter will resolve all your memory use machinations by showing a graphic of the pile of spaghetti that OO engenders. Then there is a graphic showing the more hierarchical tree arrangement that Rust's ownership model herds one into. I immediately remembered the core idea in the Y&C Structured Design philosopy: remove and reduce "Pathological Connections". It looks to me like "Ownership" is a very effective answer. I'd recommend that the Rust development team grab and see how we've come full circle through the OOblech in these past decades. Perhaps it will give some directions for future Rust polish and simplification.

Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design

1 Like
#2

I'm not familiar with Y&C exactly but over the decades since the scourge of the "OOP everything" arrived with C++, Java, C# I have read many times people imploring developers to be wary of creating those "Pathological Connections". Generally put in terms of avoiding the introduction dependencies into components where they should not be.

Somebody once described the problem nicely as "You wanted a banana but you got a gorilla holding the banana". Could have been this guy: https://www.johndcook.com/blog/2011/07/19/you-wanted-banana/

I was thinking about this the other week as I was trying to extract some useful functionality out of some C# and reimplement as Rust. The C# program I was borrowing from had a ton of classes for handling a user interface, networking, configuration bla, bla, and buried in the middle was the useful stuff.

I though I would pull that useful class out and build a simple, cut down, command line program around it as reference model for my Rust conversion.

But oh, no. It turned out that pretty much every class in that program depended on every other class in some convoluted, cyclical manner.

I mean really, there were no 'components' in there. No reusable parts. Whoever wrote it may as well have done it all as a 50,000 line file of Visual BASIC and made everything global!

Anyway, my impression is that the Rust developers are very aware of all this, and more.

1 Like
#3

I was puzzled by that distinction you made there.

There are those who would claim that writing a program is design as well. A continuation of the design you started with at the top down at a lower level of detail.

I thought you might be interested in this: "The Forgotten Art of Structured Programming" - Kevlin Henney : https://www.youtube.com/watch?v=M9Yu4FzmmZc

In which he points out that Object Oriented programming was described by Structured Programming. If you read as far as the last chapter of whatever book on structured programming. Which not many paid attention to as they did not have languages to support OOP.

The upshot being that when the world jumped on OOP everyone forgot the "structured" part.

#4

You can write crappy code in any language, but of all the languages I've used, Rust's borrow checker seems to be the most effective mechanism for pushing people towards writing good code.

If you need to worry about who owns what data, it'll force you to maintain a simpler application model with more hierarchy and less cross-component coupling. Just because it makes maintaining memory safety and object creation/destruction simpler.

I'd argue that modern C++ is also pretty good at this with the tendency towards unique_ptr<T> and away from storing raw pointers or references inside a struct/class.

1 Like