Quantum number of dependencies for the uuid crate? By default it actually has none. If you were to enable the `v4` feature, it only pulls in `getrandom` for platform independent rng. All other dependencies are disabled by default or are dev dependencies used in tests.
You could make the exact same argument for something like git. Yet everybody would be totally fine if their remote/origin is down for a couple of hours. Offline support is about bridging smaller periods of being unconnected while still enabling the user to be somewhat productive.
> This page is copyright 2005 by Graeme Cole. What are you allowed to do with it? Pfft. Anything within the realms of common sense, really. I don't want to prescribe rigidly what people can and can't do with it, so I've decided on a benchmark. It's this: you're allowed to do with this page anything you wouldn't mind me doing with your cat. So yes, you can photoshop it for comedy effect, you can copy bits of it for illustrative purposes and so on, but you can't steal it and pass it off as your own.
I'm not sure what the relevance of your example is regarding your question.
Aside from that, how did you come the to the conclusion that the second project is 'lacking when it comes to good programming'? Just because you didn't get it running?
This hits home. Manytime have I come to appreciate a library or technology only after delusionally attempting to create a 'better' version. Mid attempt I actually start to understand the problem space, at which point I humbly and thankfully start depending on said library or technology.
It's not just about upsetting the other person, it's more about the end goal. If the end goal is to express superior knowledge, do strike down your hammer of truth.
But if the end goal is to enlighten the people around you, and let them enlighten you, then it matters how you package your truth. Sadly it's seems to be human nature that if you tell someone that their perspective of the universe is wrong and don't give them any leeway, there's a high chance of them just dismissing it because it would hurt them.
Now if you are more diplomatic with your self devised absolute thruths, you might find that the people on the receiving end are more willing to accept them.
This concept seems to be fully absent from politics these days.
Using ballast in port operations is significantly different then using ballast while sailing especially for offsetting a non static moment.
Container vessels are designed to sail at a very specific draught. The bulbous bows on most container vessels are fine tuned hydrodynamic shapes that impact ths wave patterns that ships generate. Sailing at a different draught because you're adding ballast will greatly decrease fuel efficiency. Additionally any added draught also increases the amount of water you have to displace, so again decreasing fuel efficiency.
Further more, I highly doubt regulations would permiss this. I'd have to dive in IMO statues to verify, but imagine because of any event the rolling moment from the sails decreases in a short amount of time. Now the vessel has the same instability that you initially tried to offset, just caused by your own ballast.
I'd be interested to hear what your thoughts are on these issues. Non the less, very interesting ideas
Exactly. Compiler developers wrote the logic for the errors you see, they (mostly) have the knowledge to explain the error, why do we need a language model trained on all this derived information, when it could be provided upfront together with context from your own source code.
Firstly I think the most important thing in engineering is nothing is free. If you change a parameter in your design something else has got to give. If you increase the cargo capacity of a plane it is probably going to have a slower cruising speed. The hard part is finding the sweet spot that exactly fits the requirements of the client or use case. And also! now a dosen of other parameters have shifted to, like weight balance or climbing rate. How do these fit in?
Now for software, let's say you have two clients with almost identical requirements for a piece of Software. The only difference being one of them thinks time to market is important, the other one has less focus on time. As a software engineer you should produce two very different pieces of Software for these clients. You will have to make decisions based on the time it will take to implement something and also understand the effects of this on other aspects of the end product.
There are many ways to remodel a bathroom. Some more optimal than others.
Now imagine your plumber tells you he discovered a better layout for the plumbing just after finishing his work, then he enthusiastically asks if he could tear everything out and start over (and pay him for it).
What ever model works for a group of people producing software I'm fine with.
But as someone else said in this thread: If the question is more about who provides the estimate and less about why is there an estimate (also plenty of opinions about that in this thread) then I would say that time estimation is a integral part of an engineers job.
What makes someone an engineer is being able to provide a weighted solution towards the needs of a client or consumer. Not the best solution in the world, but the best solution for that client. If the requirements are that it should be delivered fast, you understand that the quality goes down. If the client wants high quality, it takes more time.
We're performing applied mathematics, but we're performing that task as engineers. The key is in 'applied'. Going from theory to practice takes planning and is not as unbounded as performing science in my opinion.
As someone who moved from a practical engineering field into software engineering, this separation in tasks between management and developers seems weird. Engineering in general is about finding a local optimum in a multidimensional problem space, one of the axes could be time, another one could be complexity or agility. For me, an engineer is not just tasked with outputting code, but also working out these optimums.
Rust actually accomplishes this with the unit '()' type which is similar but not the same as void in other languages. Any statement (or expression) produces a value, sometimes that value is just a unit, which can be passed around just as any other value. Currently the exception to this are 'let' statements but there is a nightly feature where this produces a unit value as well.