Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uncomfortable Truths in Software Engineering

buttondown.email

Post reply on HN
Print view View original

21–30 of 400 posts

Re: Uncomfortable Truths in Software Engineering

#21

Post by bluGill »

varjag wrote: post #6

There’s no rigorous academic evidence for this, but a lot of companies have been backporting typescript/mypy/sorbet onto existing dynamic codebases and the case studies have been overwhelmingly positive. Not to be a buzzkill, but migration reports from any tech A to tech B are always overwhelmingly positive when the industry has a newlywed period with tech B. Save for a clear, undeniable failure the stakeholders will…

After using python and C++ in production for more than 10 years I'll reach for python for trivial things, but for something complex give my C++ over python! Yes C++ has awful syntax full of footguns, but at least I can change a large project. At 50k lines of code python becomes something you can't change for fear of some 1 in a million path that will only break after it hits production. Static types means that C++ won't compile in most of those cases. As a result python needs a lot more unit tests, and even 100% code coverage isn't assurance that you covered all the cases that can crash.

Don't take the above as a statement that C++ is a great language. I'm interested in rust and ADA (just to name a few that keep coming up) which might or might not be better for my needs. I'm a C++ expert though, so I know what the limits are.

Re: Uncomfortable Truths in Software Engineering

#22

Post by CuriouslyC »

zerocount wrote: post #4
mojuba wrote: post #3

No. 13 is gold: > We’re never going to get the broader SE culture to care about things like performance, compatibility, accessibility, security, or privacy, at least not without legal regulations that are enforced. And regulations are written in blood, so we’ll only get enforced legal regulations after a lack of accessibility kills people. Sorry, can't help but blame capitalism for saying "fuck performance, compatibi…

It's not capitalism, but the bad apples exploiting it.

It's not the fault of a system that rewards unethical behavior by having a massively skewed risk/reward profile for said behavior, it's the fault of people with low-normal levels of empathy who make rational decisions. Sure.

Re: Uncomfortable Truths in Software Engineering

#23

Post by HeckFeck »

zerocount wrote: post #4
mojuba wrote: post #3

No. 13 is gold: > We’re never going to get the broader SE culture to care about things like performance, compatibility, accessibility, security, or privacy, at least not without legal regulations that are enforced. And regulations are written in blood, so we’ll only get enforced legal regulations after a lack of accessibility kills people. Sorry, can't help but blame capitalism for saying "fuck performance, compatibi…

It's not capitalism, but the bad apples exploiting it.

It is a bit naïve to just blame the free market for everything wrong in the world. When I read complaints like that I wonder what "alternative" the author has in mind.

Capitalism in this sense also gave us much of the software and hardware that is praised on HN.

It is more accurate and useful to discuss which motivations, cultural shifts, or even psycological traits that have caused the decline in software quality and freedom. These are more practical than proposing mass economic realignment.

Re: Uncomfortable Truths in Software Engineering

#24

Post by XorNot »

xwdv wrote: post #13
mojuba wrote: post #3

No. 13 is gold: > We’re never going to get the broader SE culture to care about things like performance, compatibility, accessibility, security, or privacy, at least not without legal regulations that are enforced. And regulations are written in blood, so we’ll only get enforced legal regulations after a lack of accessibility kills people. Sorry, can't help but blame capitalism for saying "fuck performance, compatibi…

Software is not charity. I will not work hard to deliver all those things out of the goodness of my heart. The ROI on those things isn’t great. If it’s easy to do I’ll do it, but none of those are trivial things.

I'll go further: I would love nothing more then some well-defined common standards to work towards. Weighty documents I can drop on product manager's desk and tell them the ways in which our customers and the government will legally have their way with them if we don't meet those requirements.

Re: Uncomfortable Truths in Software Engineering

#25

Post by db48x »

delecti wrote: post #17
zerocount wrote: post #4

Earlier quoted context omitted.

It's not capitalism, but the bad apples exploiting it.

Capitalism is a handful of people who own the means of production and the rest of us trying to get by. The bad apples exploiting it are the people who own the means of production, and saying they're the bad part of capitalism might as well be saying "capitalism is only bad because of what makes capitalism what it is".

You replied to that comment using a computer. That computer is the means of production for software. You own the means of production here. What have you been doing with that capability?

Re: Uncomfortable Truths in Software Engineering

#26

Post by flaviojuvenal »

varjag wrote: post #6

There’s no rigorous academic evidence for this, but a lot of companies have been backporting typescript/mypy/sorbet onto existing dynamic codebases and the case studies have been overwhelmingly positive. Not to be a buzzkill, but migration reports from any tech A to tech B are always overwhelmingly positive when the industry has a newlywed period with tech B. Save for a clear, undeniable failure the stakeholders will…

Yes, survivorship bias too.

Re: Uncomfortable Truths in Software Engineering

#27

Post by bluGill »

mojuba wrote: post #15
zerocount wrote: post #4

Earlier quoted context omitted.

It's not capitalism, but the bad apples exploiting it.

I'd like to see examples of well known good apples outside of OSS that care about performance, compatibility, accessibility, security, and privacy.

Even in OSS caring about performance, compatibility, security and privacy is the exception. The biggest projects do tend to care, but the majority don't. The biggest examples in OSS are mostly funded by capitalism to care ab out those things.

Re: Uncomfortable Truths in Software Engineering

#28

Post by teddyh »

> 6. We don’t have the Alan Kay / Free Software / Hypercard dream of everybody having control over their own computer because integrating with disparate APIs is really fucking hard and takes a lot of work to do. This will never get better, because API design is decentralized and everybody is going to make different decisions with their APIs.

No, it’s because it’s the incentive of most every developer involved to make it harder for the user to have control over their own computer. Even though it might make a net win, a proprietary software developer wants to not have competition. Also, they lobby for copyright and DMCA, etc. to further lock in their assumed place in the hierarchy.

Re: Uncomfortable Truths in Software Engineering

#29

Post by mojuba »

xwdv wrote: post #13
mojuba wrote: post #3

No. 13 is gold: > We’re never going to get the broader SE culture to care about things like performance, compatibility, accessibility, security, or privacy, at least not without legal regulations that are enforced. And regulations are written in blood, so we’ll only get enforced legal regulations after a lack of accessibility kills people. Sorry, can't help but blame capitalism for saying "fuck performance, compatibi…

Software is not charity. I will not work hard to deliver all those things out of the goodness of my heart. The ROI on those things isn’t great. If it’s easy to do I’ll do it, but none of those are trivial things.

Software is not charity but it's a responsibility. As probably the most innocent example, when you ship an app that drains a user's battery you betray your users.

But then how about an app that sneakily collects data knowing that users won't even understand what you are doing or why?

You can be a responsible business which unfortunately won't necessarily be appreciated. Or you can be a typical business that exploits information asymmetry to the last bit.

Re: Uncomfortable Truths in Software Engineering

#30

Post by varjag »

abernard1 wrote: post #20
varjag wrote: post #6

There’s no rigorous academic evidence for this, but a lot of companies have been backporting typescript/mypy/sorbet onto existing dynamic codebases and the case studies have been overwhelmingly positive. Not to be a buzzkill, but migration reports from any tech A to tech B are always overwhelmingly positive when the industry has a newlywed period with tech B. Save for a clear, undeniable failure the stakeholders will…

For Typescript, I think it's safe to say the honeymoon period is over. It's been >9 years, or more than 3 internet generations. For at least this one case, many people (including myself) believe it's a success. Whether the tooling for Sorbet or mypy ever reaches that point, there are compelling reasons to believe in the success of the model.

Adoption curve takes a while. Typescript definitely wasn't common back in 2012, I can tell you that.
Post reply on HN