Weird, I have always aligned as the gp showed. I’m reasonably sure tidyverse documentation does the same (which is probably where we both picked it up from).
One neat thing about the referenced chapter on macros from Practical Common Lisp is that it's chapters 7 and 8 of a 30+ chapter book. You're only learning about variables in the chapter before and then macros. I like to think about that when conversations about macros always devolve into talking about how you should never use macros.
Now apologies for the aside—and I know I'm likely wading into a very expansive topic and reducing it down to something simple—but why in Rust, if the types are known:
struct Song {
title: String,
artist: String,
rating: i64,
}
do you have to call `.to_string()` on things that look a lot like strings already?
Because to_string allocates. And if a function requires a String (owned), it cannot accept a str reference (borrowed), it would defeat the purpose of the strong type system. String is moved, while str is passed by reference.
There is the exception of Deref. If the function requires type A, and you pass it type B, which Derefs into type A, the compiler will Deref it for you. But that is zero cost and panic free, whereas allocating (and copying) an owned type from a reference isn't. In Rust you have to be explicit.
Anyway, using String in function signatures is most often not the best choice. If you will internally be required to use a String, it's better to ask for a type "impl Into<String>", you'd call into() inside your function. And in the most common case, where you require a &str or can convert to your type from it, the best choice is an "impl AsRef<str>" and you can call as_ref() on it to get a str reference, which you can wrap in a Box, Rc, Arc, String, or your custom type, or pass it directly to other functions. All of those, Box<str>, Rc<str>, etc implement both traits.
Using impl Trait, you avoid having to declare generic parameters.
They’re different kinds of strings, the String string means heap allocation, and Rust never allocates in the language, so the compiler automatically invoking allocation routines for you wouldn’t be good, in Rust’s view.
Those "things that look at a lot like strings already" are literals and thus constants, with the type `&'static str` which is how Rust spells an immutable reference to a string slice which lives forever. So, Rust is promising that the string slices "Hate Me" and "Blue October" exist, and in practice probably if you look inside the resulting executable it says "Hate MeBlue October" or similar.
On the other hand the String type is a growable array of bytes used to assemble strings, it's an owning type, so Song will own those two Strings, they can't go away or be altered via some other force. Owning a string would allow you to add to it, change it, or discard it entirely, you obviously can't do that to the text baked into the executable, so if you want to own a String it will have to be allocated at runtime.
You can also write "Some Words".to_owned() for example to the same effect.
To be fair, as much as Rust macros are nice, it is a losing battle to go up against the Lisp macro system. Lisp might have its flaws, but macros in Lisp are second to none.
When to use them is a whole different story. But examples of macros I like are `when` and `unless`. Yes, simple, but they show a nice example of their power.
For more complicated once, love it or hate it, but the `loop` macro is probably THE prime example of a powerful macro.
When you have a &str (like "Blue October") and pass it to something that wants a String, you can do .into() instead of .to_string()
It’s shorter to write and takes up a little less space on screen to. I almost always use .into() when like in your example I initialize String field members of a struct in Rust.
the reasons to not use macros have to do with hygeinicity? -- macros can do things like introduce code that is hard to understand, perhaps a dynamically named function, or a difficult to chase dependency or import... moreover these can make grepping harder.
I often think of Thoreau when my mind drifts to romanticizing farming:
> I see young men, my townsmen, whose misfortune it is to have inherited farms, houses, barns, cattle, and farming tools; for these are more easily acquired than got rid of. Better if they had been born in the open pasture and suckled by a wolf, that they might have seen with clearer eyes what field they were called to labor in. Who made them serfs of the soil? Why should they eat their sixty acres, when man is condemned to eat only his peck of dirt? Why should they begin digging their graves as soon as they are born?
So you don't have to go through the factory reset if you are fine with having the app store? Safari is the only app I need to excise, and the OS won't let me delete it.
I was using a vertical Logitech mouse but was still experiencing discomfort mousing out to the side of my enormous Advantage2 keyboard. In an effort to head off any compounding RSI issues, I switched to a ploopy Adept trackball. Had no idea if I'd like switching to a trackball, and I love it! My hand never moves in an awkward motion, and mousing has become pretty restful. Better be careful tossing the ball up in the air idly during meetings as I won't be able to get a replacement if ploopy has paused shipping to the US (It's a pretty dumb habit at any rate).
They're just 1.75" snooker balls. It's very easy to get a big box of them. You'll also quickly notice why red never goes out of stock on Ploopy's website.
Is the q solution equivalent? In doing a plus scan, isn't the last element always going to be the largest? To find the largest subarray sum, I would think you'd want to split into a matrix along the `null`s first and then plus reduction and then a max of those results.
Say what you will about clarity, but my mind sort of glossed over the intention in the python and rust code, focusing instead on the syntax, while the q code made me consider what was actually happening.
It is equivalent because it's not a plus-scan but a (0^+)-scan which resets every time it hits a null (there's a more in depth explanation here https://robertandrewspencer.com/aoc_2022_1/ )
Perhaps q did both force you to consider what was happening, and hide it from you...
When the article mentions "tech-adjacent," I think it is worth keeping in mind that this includes a broad swath of jobs that would never had qualified for amortizing salaries as R&D. For example, I'm skeptical that the tax change will have an impact on the number of television and film producers that are currently unemployed due to a huge slowdown in greenlighting projects from streaming services. I feel there is a contraction happening (though, practically, it doesn't always appear that way) that is a greater source of consternation than amortizing developer salaries will alleviate.
Surely the weight of a tractor pales in comparison to the person sitting inside? The heavy weight is for that big engine with a lot of torque. Can a lighter weight tractor pull its load?
I’d assume all the functionality inside the cab, the space needed, seat, controls, windscreen, AC inside the cabin, etc, add up to quite a bit of weight. If you went truly driverless without a cabin you could save a ton of weight.
Maybe a ton at the most - but the tractor weights far more than a ton. Actually more weight is a good thing in tractors because that allows for more traction.
Tractors are not cars - weight balance doesn't make nearly as difference. Between lower speeds, lack of suspension, and all wheel drive it doesn't matter.
Weight balance absolutely makes a difference. If you don’t have enough weight on the front of the tractor, for instance, certain implements are nonfunctional. You need to balance weight from front to back. Standard issue parts of tractors is adding weight boxes to either the front or back of the tractor to balance the weight of the implement on the other side.
Fair enough - but the humans and the need for a cab is not significant. Those weights are still added based on the implement, and removed for other operations. They are also heavier than the cab + human in many cases. They are also added in front of the front axle, or behind the rear, while the human weight affects both axles (not evenly, but close enough)
Removing a cab and a human removes at minimum 300-500 lbs (when you account for human weight, all the framing, window glass, HVAC components, seats, screens, etc etc) which is balanced somewhat evenly across both axles.
That means you can take that weight, and use only a portion of it to balance the tractor. Less weight overall.
First of all more weight is good! Weight means more traction, and traction is important. Depending on the system traction or horsepower may be the real limit, but the other is still close.
Second while balance can matter typically doesn't. Even when balance matters, you still need weight on the other axles. Most of the time your are towing something with most of the weight not on the tractor so you just want more weight and you want it more or less evenly balanced - about what a cab gives you.
Tractors tend to spread their load with more, gianter, wider tires.
The trade-off for making the tractor larger is that you can pull wider and multiple or multi-function implements to do the entire thing faster in one pass.
The larger contact patch for having an absurd number of wheels reduces soil compaction and reduces the chance you get stuck; working in fewer passes further reduces soil compaction and prevents you from getting stuck (since in the ideal case, you're doing one pass on solid ground, and never driving over tilled soil).
Tractors get stuck when they drive in mud (and other mud like soils) all the time. However when driving on not-mud it is true. That is the trade off, the heavier you are the more care you need to take about mud.
I suspect tanks get stuck often in part because that is fun and in part because they need to train troops how to get them unstuck and so they intentionally send tanks into mud - which is to say in a real war the generals might (should) avoid getting stuck, but in training it is important to get stuck often. I'm not a military expert though, but that is my opinion on tanks.
What you could achieve with a driverless tractor is using two smaller ones instead of one big one. Since the driver's effective wage leaves the cost equation, the number of tractors can potentially be much larger.
Come to think of it, this might also benefit small landholders eventually by reducing the minimum amount of land required to fund a single tractor.
I can't figure out how to link, but if you search me you will see elsewhere that I explained that bigger is better for the soil.
Most small landholders should sell and move to the city. You need a fair amount of size to make a decent living selling something cheap. Though my biggest worry is the medium sized farmers - wasting $10/acre in extra chemicals when you have 600 acres is only $6000 - you probably won't even notice it and in any case not wasting it costs investment too. When you have 6000 acres though that $10 is a larger number and you can afford to put a lot of money in better whatever to not waste it.
In order to link, you right-click (or equivalent) on the time stamp of the post, which on your comment currently says "4 hours ago". That creates a link like this:
> Most small landholders should sell and move to the city.
Economically, this has been true for decades irrespective of developments in autonomous vehicles. But city life is miserable, and there will always be people trying to escape it on the farm.
The American voter is too ideologically attached to the idea of the small family farm and opposed to the big scary boogeyman corporation to support any policy that encourages consolidation of farming and farmers to move to th city
Typically you align a pipeline like so:
But these topics are largely left to code formatters these days.