Uncomfortable Truths in Software Engineering • Hacker News Board

Re: Uncomfortable Truths in Software Engineering

#381

Post by drewcoo » Thu, Dec 16, 2021, 1:05 AM UTC

StevePerkins wrote: post #16

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…

Number one, static type checking is hardly a "new tech" for which the industry is in a "newlywed period". If anything, it is the middle-aged wife that the industry's crawling back to, as the passion fades from its dynamic mistress dalliance. Secondly, the obvious counterexample here is MongoDB. Way too hyped-up during its honeymoon, and then almost immediately crapped on by the entire industry (to the point where we'…

Software developers are goldfish, not tortoises. We retain no long-term memories. There is always - oh, look! - a brand new side of the bowl to swim toward. All change is new tech to us.

Except COBOL. We've never seen it but it's a punchline.

Now regarding number one . . .

Re: Uncomfortable Truths in Software Engineering

#382

Post by onecommentman » Thu, Dec 16, 2021, 1:33 AM UTC

irq-1 wrote: post #344

13. 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. [3] And regulations are written in blood, so we’ll only get enforced legal regulations after a lack of accessibility kills people. [3] ...I think the killing has to be directly and obviously attributable to the software…

Money and focus to improve SE culture can come from just changing civil liability doctrines, instead of gov’t regulation.

For example, guilty-until-proven-innocent (res ipsa loquitur) would make poor IT design and operations a lot more expensive, at the expense of a lot more court cases and a chilling effect on new software. For mature core operations, the price paid by society might be worth it. The IT industry would then be forced to come together and address issues at an industry level, if for no other reason than every player avoiding painful amounts of time and money spent in the civil justice system…which is a lot less fun than even the most torturous code reviews.

My sense is (IANAL) that the liability doctrines for software are stuck in the 1960s with all software viewed as a “best effort” sort of experimental exercise that must be protected from the rigors of normal liability. I think we are past that point for a lot of software components. But who in the software industry dare acknowledge it?

Re: Uncomfortable Truths in Software Engineering

#383

Post by sysOpOpPERAND » Thu, Dec 16, 2021, 1:40 AM UTC

ponow wrote: post #47

teddyh wrote: post #28

> 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…

So software copyright is not a net win?

its fine until it stifles innovation one could argue

https://www.investopedia.com/terms/p/patent-troll.asp

Re: Uncomfortable Truths in Software Engineering

#384

Post by t0mbstone » Thu, Dec 16, 2021, 2:24 AM UTC

notreallyserio wrote: post #225

ryandvm wrote: post #156

> Pairing is probably better than two solo devs if both pairers can handle it. Man, am I the only one that absolutely detests pair programming? Not only do I find it socially awkward, it completely kills my productivity. Software development is often about building a very complex model in your head and then figuring out the changes that need to be made. Having to dedicate half of my mental bandwidth to handling socia…

I just want to be able to fart at my desk in peace. I haven't tried pair programming. It sounds miserable. I figure I'd end up paired with one of those people that can't stand to see you looking for something. You know the type: you're looking through cabinets for something and they demand you tell them what and they demand you go directly to the right place. Sure, I'm looking for something, but I'm also learning whe…

The trick to pair programming is for each dev to have their own workstation with two screens.

Then, you simply use a screen sharing tool to share and collaborate on a code editor on each of your primary screens. We used to use Screenhero for this before they got bought out by Slack, but another tool that works well is something like Tuple.app or Drovio.

The beauty of this approach is that each person can "check out" temporarily and do research and look up stuff or check messages on their secondary monitor (without the other person seeing it), but they can easily move their mouse back over to their primary monitor and re-join in on the pair programming.

It makes pair programming a lot more tolerable, and gives you the ability to collaborate, while still having some flexibility and autonomy.

This also works well in both local and remote pairing sessions.

Re: Uncomfortable Truths in Software Engineering

#385

Post by bb88 » Thu, Dec 16, 2021, 4:12 AM UTC

friedman23 wrote: post #366

bb88 wrote: post #351

Earlier quoted context omitted.

You're not wrong, but yet you are. There were failures with Ada as well as I recall. Statically typed. Ahead of it's time. But in some critical use cases, it failed. It also cost a lot to maintain. Compilers/IDE's were super expensive. Yet there were cases of undefined behavior that you still had to (hopefully) catch in a peer review. This was the case of the Arianne 5 rocket explosion caused by software written in s…

>Java and the log4j mess are similar. It's a statically typed language, but a poorly reviewed code base. The static typing didn't catch the security hole. And it's cost the US millions of dollars so far to fix it. This is a ridiculous statement and just really devalues everything you are saying. How is a vulnerability in a library that is completely orthogonal to typing relevant in this discussion. Static typing neve…

You said:

> Static typing is net 0 cost. We don't need to be "honest" static typing is obviously not free you need to think of types. The real revelation was that the cost of dynamic languages far exceeds the cost of a statically typed language.

And my point is the static typed languages we do have didn't save us anything in terms of cost.

I recommend maybe you read the hackernews posting guidelines before you post again.

https://news.ycombinator.com/newsguidelines.html

Re: Uncomfortable Truths in Software Engineering

#386

Post by [deleted] » Thu, Dec 16, 2021, 6:57 AM UTC

WhompingWindows wrote: post #74

My Own Addition: 14. Those who code for a living make good money. I have a lot of friends who went into various fields, and it seems relative to the number of buttons we press daily, anyone who works on software makes great money. We didn't spend a ton of $ to go to medical school and 3 years of residency. We didn't go to law school and take the bar. Most of us went to 4 years, or less, of school, and here we are mak…

[deleted]

Re: Uncomfortable Truths in Software Engineering

#387

Post by john-shaffer » Thu, Dec 16, 2021, 8:40 AM UTC

pron wrote: post #377

mamcx wrote: post #375

Earlier quoted context omitted.

> we haven't been able to find any evidence to support the fact that "new types" significantly increase correctness and have a greater return on investment Rust? A lot of people say Rust improve the game (I'm one of them). I have coded in +12 langs all my life,. Rust totally remove tons of issues (for me) that were present in the past just before shipping and even after. And I port the same project. The kind of issue…

I was expecting someone would say that. There are very specific situations where a language has an advantage over an exceptionally "bad" language in the same domain, such as Rust vs. C or TypeScript vs. JS (for which we also have evidence of a ~15% improvement). But that doesn't mean that the very concept of "new types" generally has a big impact. E.g., it's easier to write more correct software in Rust than in C, bu…

Clojure is strongly typed and dynamically typed, not "untyped". Much of its core behavior is built on interfaces like ISeq.

It's not uncommon to use a spec library like clojure.spec or malli, whose benefits overlap those of static typing. I'm not sure if there is a measured improvement from their use, but they have either advantages like facilitating generative testing that do help one to write more correct software.

Re: Uncomfortable Truths in Software Engineering

#388

Post by pron » Thu, Dec 16, 2021, 9:23 AM UTC

john-shaffer wrote: post #387

pron wrote: post #377

Earlier quoted context omitted.

I was expecting someone would say that. There are very specific situations where a language has an advantage over an exceptionally "bad" language in the same domain, such as Rust vs. C or TypeScript vs. JS (for which we also have evidence of a ~15% improvement). But that doesn't mean that the very concept of "new types" generally has a big impact. E.g., it's easier to write more correct software in Rust than in C, bu…

Clojure is strongly typed and dynamically typed, not "untyped". Much of its core behavior is built on interfaces like ISeq. It's not uncommon to use a spec library like clojure.spec or malli, whose benefits overlap those of static typing. I'm not sure if there is a measured improvement from their use, but they have either advantages like facilitating generative testing that do help one to write more correct software.

The term "untyped" means anything that isn't statically typed (or just "typed"). This is because (static) types and dynamic "types" are two very different objects, and only the former is called "types" in programming language theory and formal languages in general.

I am well aware of clojure.spec, and it, as well as many other techniques employed in development, are probably among the reasons why types don't actually seem to have a big relative impact on correctness.

Re: Uncomfortable Truths in Software Engineering

#389

Post by amw-zero » Thu, Dec 16, 2021, 10:29 AM UTC

ryandvm wrote: post #156

> Pairing is probably better than two solo devs if both pairers can handle it. Man, am I the only one that absolutely detests pair programming? Not only do I find it socially awkward, it completely kills my productivity. Software development is often about building a very complex model in your head and then figuring out the changes that need to be made. Having to dedicate half of my mental bandwidth to handling socia…

I’m totally not trying to convince you, because I don’t strongly believe in pairing or anything. But, one benefit that I do see with pairing is that code is always shared amongst a team. You’re seeing the social interaction as only a cost, but there is also a benefit: pairing ensures that the code produced matches more than just one person’s brain.

It basically frontloads the communication / knowledge sharing of the structure and reasoning behind the code, and avoids using patterns that only one person enjoys or understands. Which surely is an important part of working on a team.

Re: Uncomfortable Truths in Software Engineering

#390

Post by amw-zero » Thu, Dec 16, 2021, 10:33 AM UTC

3pt14159 wrote: post #102

This piece is great overall, but: > TDD[...] zealots are probably zealots [...] Because they're sick to death of things breaking in production and having to program against interfaces that were designed as an implementer was thinking about them over how a caller would view them. There are times and places to not do TDD, I'd say on the backend around 15% of the time where exploration first is more important (e.g., som…

What got me out of TDD zealotry is the enormous cost of really testing software well, I mean all branches, all sides of all conditions, large amounts of input space coverage. Then that coupled with the fact that specifications change constantly and relentlessly, invalidating some percentage of all of your cases.

I agree with the sentiment that got me into testing in the first place: software is complicated and hard to modify without breaking something. But, TDD for sure isn’t the answer to that problem.