3 ms·
It’s also massively unsafe to drive in general, so we should probably ban the usage of cars wherever possible.
by BaculumMeumEst 4y ago
It’s also massively unsafe to drive in general, so we should probably ban the usage of cars wherever possible.
- rowanG077 4y agoDriving also brings great value. Using C over another language "Because you can't tell me what to do" does not. The more apt comparison would be if we had fully self driving cars that are proven to make almost no mistakes. And then still wanting to drive a car yourself on public roads, endangering yourself and others.
- BaculumMeumEst 4y agoC and C++ still see overwhelming usage in many industries because of the business value they provide in terms of performance and how quickly you can produce software in it. That does not seem likely to change any time soon- game studios are not widely adopting rust, for example, and I don't expect that to change, even though they impact a MASSIVE amount of people. Hare's value proposition is simplicity- which allows you to better reason about the software you write, for one thing. We are each entitled to our own opinion about how valuable that is.
- ncmncm 4y agoC and C++ are at diametric opposite ends of the scale of value proposition. Listing them side by side eliminates any credibility your argument might have had. Hare's "value proposition" of simplicity is, simply, a shuck. Any software effort has essential complexity that your language may help you manage, or chuck you in the deep water to sink or swim. Hare does the latter, and is even self-righteous about it.
- BaculumMeumEst 4y agoI mentioned performance and game development specifically. I'm sure you're aware that it's common to write C++ that's very close to C while taking advantage of few features of C++. I don't think it's fair to call that the "diametric opposite of C". Your opinion of Hare's view of simplicity is your opinion. Any software effort has some amount of essential complexity, in my experience many languages and tools quite a bit of incidental complexity that could be avoided.
- ncmncm 4y agoYou can write bad code in any language. (We used to say "you can write FORTRAN code in any language", back when.) C code compiled with a C++ compiler is C, and bad. With the C compiler, you had no choice. You do not get that excuse when you have a C++ compiler. Avoiding unnecessary complexity is everybody's responsibility. Dumping every last bit of unavoidable complexity onto the programmer where it has been long demonstrated that tooling can take care of much of it is simply irresponsible, and inexcusable. I do not excuse it.
- staticassertion 4y agoWe license people to drive and have a legal system for dealing with irresponsible drivers.
- BaculumMeumEst 4y agoCompanies have policies for software security. Industries have regulations.
- staticassertion 4y agoThe most common policy will be for SOC2, ISO27001. There's virtually nothing about software security in there, other than scanning for vulnerabilities. Everything else is about controls on infrastructure, threat modeling, that sort of thing. It's not really relevant. Besides, none of those have to do with software engineers. Compliance doesn't imply any individual responsibility.
- BaculumMeumEst 4y agoThe most common policy for what? I've worked in defense and there are stringent security requirements for applications and servers, which programs written in manual memory management languages would likely fail. "Some existing policies are bad" is not a convincing argument that hare shouldn't exist.
- staticassertion 4y agoThe most common for companies to have/ be required to have. > I've worked in defense and there are stringent security requirements for applications and servers. Like? FEDRAMP? The vast majority of compliance is about threat modeling and access controls.
- BaculumMeumEst 4y ago> Like? FEDRAMP? No, STIGs. > The vast majority of compliance is about threat modeling and access controls. If compliance doesn't address security, that sounds like a bigger issue than a new hobby language existing.