When the Levee Breaks (original version by Kansas Joe McCoy and Memphis Minnie) https://www.youtube.com/watch?v=swhEa8vuP6U
The snow must have stopped coming down soon after I went to sleep, as I woke up to partly cloudy skies and about six inches on the ground.
Weather report says thirty-seven percent chance of one to three inches more today. But it also says thirty-three percent chance of three to six inches more!
I hope it stays on the smaller end of the scale. I've got enough snow to be pretty, but not enough to be a big problem. I'd like to keep it that way.
I've got six inches of snow now and it's still coming down, albeit with somewhat less enthusiasm at the moment.
If tomorrow turns out like today I'll have significantly over a foot of snow out there. So much for the three to six inches in the forecast. And the weather report has been making tomorrow out as the big snow day.
First year I was up here I got three-plus *feet* of snow that hung around for six weeks. There's not been a winter like that since. I'm thankful for that.
In my case, it is telling me there's yet another reason to appreciate the way the Rust language design basically forces the programmer to make good choices.
In C I can leave off const, the compiler doesn't care. In Java I can copy mutable objects or go with heavier-weight, more complex, designs based on threadsafe mutable objects and there will be no warnings generated.
In Rust I don't have a choice. But the restriction exists in a way I already know is the best way to design and implement.
But by making the data immutable it's entirely safe for multiple threads to retain a reference. If two threads execute a method or reference a getter they do it on separate stacks. The underlying data is read only.
Of course, once again, how you implement your threaded code changes if you use immutable objects a lot.
And it turns out, like with C, the design patterns for threads in Java using immutable objects is very similar to how Rust works.
So, what does this tell us?
All you have to do to make an immutable object in Java is remove all the setters from it's class and only provide constructors, zero-side-effect functions, and getters. Done.
You can even have subclasses which are mutable and provide convenience methods to swap the representations back and forth. So now you are free to pass data back and forth between threads without worry.
Yes, you are breaking the 'retain a reference' rule for C, but this is Java; you've got garbage collection. No worries.
With Java you don't have to worry about retaining references and functions are less likely to cause problems if you forget to const your strings. But it does have one area where thinking about mutability is super-important: threads.
I've written plenty of threaded code in different languages, including C, but I really cut my teeth on threads with Java. There I quickly learned the trick was working with immutable data structures.
And, in Java, you can make an object immutable really easily.
Here's the thing: good C programmers know you need to watch yourself with strings, but they tend to forget the same rules often apply to other data structures for the same reasons. And, when you do apply them, you find your structure/function design patterns change in ways similar to how Rust works.
And, in any case, the compiler isn't doing this for you as with Rust. Instead you are applying the rules yourself by sheer force of will. Programming uphill.
Java has a similar thing going…
That 'const' qualifier makes it impossible for you to accidentally (or intentionally) change the string inside the function. If you try something like this the compiler will puke: bar = 'a';
Another thing you have to do is never, *ever*, EVER retain that reference in a data structure outside the function. If you need to retain the string contents make a copy. But don't keep the pointer because you don't know where that address came from and it might not be valid after the function returns.
Let's start with C. We're talking my favorite language here, but I'm the first to acknowledge the warts. One of the biggest warts is C strings.
Besides all the other things wrong with C strings, you can *only* pass them to a function by reference. A pointer to the beginning of the string.
This means you *must* be absolutely legalistic about string references in functions. For one, *always* declare a string reference as a constant: void foo(const char * bar);
With me so far?
#Rust: A unique perspective. (On data ownership and mutability.) https://limpet.net/mbrubeck/2019/02/07/rust-a-unique-perspective.html
This is sort of a beginner's introduction to Rust's type ownership system; giving the 'why' as well as the 'what'. It's a pretty good read and, if you don't totally grok Rust variable ownership yet it's worth your time.
But it also made me think about some patterns I have long used in C and Java, usually for different reasons. So THREAD.
This paper is heavy going, but rather interesting. Not sure I understood it completely, so I'm linking for when I think about these things more later.
It's been coming down REALLY hard for the last hour and a half. The snow is now at four inches of new, on top of two inches left over from the last snowfall.
I just ran my Jeep Liberty up and down my driveway a bunch of times to flatten it out a bit and see how hard it would be to drive out if I have to leave. (I have a LONG driveway.) No problems there, didn't even need 4WD.
If I'd had problems I would have left the Jeep out by the road and walked back. But, not bad enough yet.
#Prismo is currently under construction, and will be a free open federated alternative to Reddit.
You can follow the project here:
There's a demo instance at:
If you're a developer, you can contribute to the code here:
If you want to support the project financially, you can donate here:
Whenever you are past the edge, out in the wind, look for me.
Rusted Neuron is an invitation-only 'Intentional Community'. It is not intended to represent a specific focus, although the people you find here are generally intelligent, creative, and witty. Content and conduct rules are set by the community, not by fiat. The one thing we will not tolerate here is intolerance; you can agree to disagree, but you must treat others with respect.Currently the membership limit is 100 people and there are plenty of slots available. The goal is to try to replicate real-world community interaction and norms enforcement online. Keeping it small is intended to create a village atmosphere by staying well under Dunbar's Number.