Is it really that much different than e.g. a cook preparing carrots while onions are being cooked? Nobody needed to invent this as far as my knowledge of history goes; so, maybe there really is nothing new under the sun :)
Joking aside, of course, the ingenuity lies in finding a fitting solution to problem at hand, as well as knowing how to apply it.
My concern is slightly different; it's the ease of debugging. And I don't mean debugging the code that I (or sb else) wrote, but the ability to freely modify the code to kick some ideas around and see what sticks, etc. which I frequently need to do, given my field.
As an example, consider a pointer to a const object as a function param in C++: I can cast it away in a second and modify it as I go on my experiments.
Any thoughts on this? How much of an extra friction would you say is introduced in Rust?
I would say it's pretty easy to do similar stuff in Rust to skirt the borrow checker. e.g. you can cast a mut ref to a mut ptr, then back to a mut ref, and then you're allowed to have multiple of them.
The problem is Rust (and its community) does a very good job at discouraging things like that, and there are no guides on how to do so (you might get lambasted for writing one. maybe I should try)
That was a lengthy, but nice article/review about someone that I didn't know of before.
Not strictly similar, but this brings to my mind Graham Greene's masterpiece, The Power and the Glory, and his 'whisky priest'. Easily one of the best novels that I've ever read, so highly recommended to give it a look.
This book is so unexpectedly funny! Once I was reading it on the train and couldn't help but laugh loudly a couple of times. People in the compartment were perplexed.
So, you needed to rewind the tape to the beginning if you wanted to return it after having partially watched it i.e. at 40%? Now I wonder, did the store owners check each tape on return for this? I hope it was a quick process..
> Rewinding to the beginning of VHS tapes was honestly so long that nobody really forgot.
Hmm, if it took so long, wouldn't it have caused the reverse effect? That people would ignore it out of laziness? Maybe I'm too spoiled! :D
Further wrinkle: it only took a long time in your VCR, which (we all believed) was also bad for your VCR (I mean, maybe? But avoiding stressing the VCR's mechanism was why it took a long time). So, gadget catalogs sold standalone high-speed VCR rewinders, which just about anyone who watched a lot of movies owned. They took less than a minute to rewind a cassette.
It took about 3 seconds to check. Pop open the case the tapes came in and look at the plastic window and you can easily see both reels. If the tape was all on the left reel, it was rewound. Just about all rental places did this when you returned the tape. Audio cassette tapes were the same way. The VHS cassette was basically just a larger version of an audio cassette with wider and longer tape.
Interestingly, in the very first iteration of home video cassette rentals, the tapes could not be rewound at home:
> These rental cassettes were red, approximately 7 inches (180 mm) high by 6.5 inches (170 mm) wide by 1.5 inches (38 mm) deep (however used the same videotape used today) and could not be rewound by a home Cartrivision recorder. Rather, they were rewound by a special machine upon their return to the retailer.
What I remember is that it was a cultural part of movie watching to rewind when the credits hit. You'd use that time to discuss what you saw with whoever you were viewing with. That's how I did it.
I recall them having a transparent window so you could see where the tape was. I think the process would have been: slide the VHS out of the sleeve and glance at where the tape was positioned. Should take just a second.
You can tell by looking at a VHS tape if it's been rewound or not; there are two little windows that let you see the tape reels, and all of the black stuff should be in the left window.
Funny that you bring this up -- I feel exactly the same way and I even had more math background than average SW person.
Being on the engineering side of things without much knowledge/focus on programming languages theory and the mathematical nature of computation, one feels as if all the niceties we have in popular PLs are just laws of nature that we just had to discover, whereas in reality they too had to be derived, tried, improved first. But then you study something like this and expect to be able to finally connect the dots and yet, it's still not immediately obvious how we arrived here!
I'd say it's first and foremost a political tool. Pseudo dictators especially love it.
Let's say you're a mayor who needs to increase the price of a public utility by 10%, what do you do? You announce that this price will be increased by 30%. People get furious, protests ensue (sometimes, it's even desirable if riots start) against such an outrageous increase! What to do? You should be as invisible as possible during this turbulent period and let others take all the heat, only to come out at the end announcing that yes, the people have spoken, and as a result the increase will be limited to 10%. Now, the people are happy; it's democracy in action, they have the power! The mayor is happy; he's got his increase happen. Happy ending.
I'm considering getting a Pixel 7 or 8, how do you like your device in general? I'm looking for a cheapish, hassle-free device that doesn't require much maintenance or tinkering with and that just works.
For cheapish, put an "a" at the end. Unless you're looking for a status symbol or the ultimate camera, you won't care about the difference in models.
Pixels are great phones, I've been on them since they were still called Nexus. There are hints of enshittification, with Pixel-only features and what not, but it's not gotten out of hand yet, and I will argue Pixels are the best (non-de-Googled) Android experience -- as they are meant to be Android showcases.
Thank you! This sounds like it's what I am after. I've been using Xiaomi phones for the same purpose, but they started neglecting software side heavily since last year or so. This should be a good replacement.
Yeah, I had to check if it's one of those bots. It's fascinating to me that a person has the urge to spit out two paragraphs devoid of any correct information or value for that matter, as an answer to a question online -- as if it can't be looked up or researched easily!
This is a stylistic difference, as there are some places where the leading return type is invalid, but a trailing return type using the -> is valid. For example, an immediately invoked lambda expression in which some of the returned values require type conversions.
For this reason, some prefer a “auto almost everywhere” style, in which you preferentially use trailing return types.
Not OP but I prefer trailing return type syntax if I were designing a language from scratch... I sometimes wish C++11 would have added the `func` keyword as an alias for `auto` in function declarations.
it is known as sticky syntax in relation to auto (but specifically when the type on the rhs is explicitly declared and not abstracted away with a function signature)
it removes narrowing, inference, while keeping benefits of auto related to inits etc.
it's a way of telling the compiler we want this type moving forward and adheres to the convention of right-to-left reading w.r.t. resource allocation semantics C++ programmers are often accustomed to.
> add a postfix type if inference can't do the job for a reason or another
Ehh... not putting a return type in at all is a bridge to far IMO. Be friendly to the casual reader of the code, and help them understand what the function returns. (Yes I know IDE's can do this for you, but not everyone uses an IDE, and not everyone is reading the code in the context of an IDE... for instance code review, etc.)
Ehh… not using an IDE is a bridge too far IMO. Be friendly to the casual writer of the code and help them express themselves without having to repeat the obvious.
(Yes, I know, we write less time than read, but maybe that is what is actually wrong with the tools we use?)
Mandating or expecting tools for others is a problem. Many code reviews are done in web settings, and that was an example you ignored fromt he person you responded.
And you ignored any value that actually specifying the type can have.
You also ignored the age old wisdom that code is written once and read many times.
Why are you attacking me? I just put some motivation for myself and maybe someone else to switch to an IDE.
Is this mandating tools thing a problem where you are working?
How did that affect you?
Why do you feel attacked? You aren't your ideas, and in this case you had a bad idea.
You said that people not having an IDE was "bridge too far" meaning that people should always have them. We already had examples of where that simply isn't true so your idea was demonstrated as wrong. Own it get a better idea and move on. I certainly had until I went through my past comments looking for childiah arguments and found one.
Those cases are the ones for which the explicit return type was intended. And if the deduced type is counterintuitive you could also use the explicit return type (or a comment: there are good arguments for either choice).
But if your argument is "this makes the reader do extra work" then that's an argument against all uses of `auto`. Now I do consider reader clarity a legitimate (and important) design criterion (and argument in code review), but I don't think it is reasonable in this case.
In fact I consider type deduction with auto to be an important element of readability: it tells the reader not to worry about the type and focus on the logic. Then the cases when a type is explicitly specified it tells the reader that it's worth paying attention.
Ideally, functions should be clear at the call site without a reader having to jump to the declaration to understand what's going on, and you don't get the return type there in the first place.
Joking aside, of course, the ingenuity lies in finding a fitting solution to problem at hand, as well as knowing how to apply it.