Ephera

I mean, for what it’s worth, I’m a seasoned dev and just did a run where I tried to answer everything as it makes sense to me (which is “throws an error” or “invalid date” for all of them) and I also got a score of 4/28.

…and two of those points were given to me, because the quiz interpreted my answer differently than I meant it.

In other words, this quiz exists to highlight that JavaScript’s Date functions make no sense.

Well, the thing is, if you’ve got a whole bunch of biodiversity and you cut down a small patch in the middle of it, where you grow your monoculture and use your big machines and whatnot, that’s when this fuck-biodiversity approach is rather profitable.

But if you scale that up, if a whole bunch of farmers kill biodiversity in the same region, this will obliterate profitability. You need biodiversity for:

• pollination
• enriching the soil (we have no industrial process for creating humus; it’s mostly just earthworms doing their thing)
• pest control (birds and whatnot can eat your pests, if they settle nearby; they won’t settle nearby, if there’s no food for half the year because you’ve killed everything else)
• resilience against pests and climate variations (if your harvest consists out of multiple different plants, then some of them failing from pests or droughts etc. is much less of a problem)

I’m probably forgetting more aspects, and we probably don’t yet know all aspects either. But ultimately, plants have evolved to exist in rich biodiversity. It isn’t just some moral thing to do, to keep that intact. Plants will falter without biodiversity, no matter how much fertilizer and pesticide you pour onto them.

A few years ago, all the languages I would use started to have automatic unused variable warnings built-in. And yeah, by now when I hear of people that don’t have that, it’s very much a feeling of “Man, you live like this?”.

Not if you never get your application into production…

I wish this was as much of a joke as I’m pretending. It’s so common for software projects to get cancelled that lots of tooling differences are just in terms of how long they let you not deal with long-term problems and how violently they do then explode into your face.

For most of the development lifecycle of a GCed project, you’re gonna ignore memory usage. And if you’re lucky, it can be ‘solved’ by just plonking down a thiccer piece of hardware…

Yeah, it’s easy to underestimate how big of a leap it is from a toy application to real-world usability. Not just in terms of security, but also:

• useful error messages
• logging / monitoring
• configuration
• building a distribution
• deploying in a reproducible way
• documentation
• integration with existing infrastructure
• data migration strategies
• etc.

This adds a lot of complexity, so you’ll need to learn additional complexity to be able to deal with it at all:

• modularization
• version control systems
• software specifications (via unit/integration tests)
• team communication
• helper tooling, like package managers, linters etc.

Learning about all this stuff takes years, especially if no one in your surroundings has much experience with any of it either. Professors don’t have the time to gain or retain this experience, since they already have a different full-time job.

My advice would be to get students to do internships or to take a job as a working student in a company/organization. Sometimes, these can be shitty for the students, but they can often provide significantly more real-world context than college ever could.

It’s a Google Docs link…

:.|:;

I mean, he did fuck up a good chunk of everything…

Ah, interesting. I went from garbage-collected languages where thinking about ownership might be useful for keeping complexity low and occasionally comes up when you manage lists of objects, but ultimately isn’t needed, to Rust where well-defined ownership is enforced by the language.

So, I wasn’t aware that ownership is even as concrete of a thing in other languages…

Hmm, not sure, if I’ve heard of it. I’m guessing, we’re not talking about simply drawing a UML class diagram…? Is it for figuring out which object will have to clean up which other objects, in non-GCed languages?

As far as I’m aware, the microfiber cloths specifically made for dusting have a structure like this:

So, it isn’t (intentionally) rough either. You wouldn’t really scrub with these. But yeah, certainly not ever going to be silky smooth either…

To me, it feels almost like I’m touching very fine-grained sandpaper…

Is that usable for dusting then, or is that for something else? I feel like for dusting, you want a somewhat rougher structure, so it can hold the dust better…

Dry skin is mostly caused by not enough oils being on your skin, which normally prevent the water from escaping. You’ll have a hard time hydrating so much that that’s no problem at all.

But at the same time, the cheapest lotion will do the trick. In principle, you can even use sunflower oil or similar. The water isn’t picky from what oil it gets blocked…

Yeah, these become a lot less relevant with routine.

• Avoiding the main-thread panicking is mostly just a matter of not using .unwrap() and .expect().

• String vs. &str can mostly be solved by generally using owned datatypes (String) for storing in structs and using references (&str) for passing into function parameters. It does still happen that you forget the & at times, but that’s then trivial to solve (by just adding the &).

• “temporary value dropped while borrowed” can generally be avoided by not passing references outside of your scope/function. You want to pass the owned value outside. Clone, if you have to.

• “missing lifetime specifier” is also largely solved by not storing references in structs.

The thing with OOP, particularly how it’s used in GCed languages, is that it’s all about handing references out to wherever and then dealing with the complexity of not knowing who has access to your fields via getters & setters, or by cloning memory whenever it’s modified in asynchronous code.

Rust has quite the opposite mindset. It’s all about tracking where references go. It pushes your code to be very tree-shaped, i.e. references typically¹ only exist between a function and the functions it calls underneath. This is what allows asynchronous code to be safe in Rust, and I would also argue that the tree shape makes code easier to understand, too.

But yeah, some of the patterns you might know from OOP will not work in Rust for that reason. You will likely need to get into a different mindset over time.

Also just in case: We are talking OOP in the sense of the paradigm, i.e. object-oriented.
Just using objects, i.e. data with associated functions/methods, that works completely normal in Rust.

¹) If you genuinely need references that reach outside the tree shape, which is mostly going to be the case, if you work with multiple threads, then you can do so by wrapping your data structures in Arc<Mutex<_>> or similar. But yeah, when learning, you should try to solve your problems without these. Most programs don’t need them.

Yeah, we onboarded some folks into a Rust project last year and a few months in, they were genuinely surprised when I told them that unwrapping is pretty bad. Granted, they probably did read about it at some point and just forgot, but that isn’t helped by lots of code using .unwrap() either.

Can still use .is_positive(), though…

I don’t think, it’s open-source…

This does not look to be open-source. The webpage lists open-source licenses for the libraries used by this app, but there’s no open-source license for the app itself.
And while there’s a GitHub repo, it’s empty. It seems to be used just for hosting the APK files.

An open-source app with decent editing capabilities is Fossify Gallery: https://f-droid.org/en/packages/org.fossify.gallery/