Live data from Hacker News

Uncomfortable Truths in Software Engineering

buttondown.email

41–50 of 400 posts

Re: Uncomfortable Truths in Software Engineering

#41

Earlier quoted context omitted.

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

It's not about the free market per se, but rather a system that allows to turn the information asymmetry into money without consequences most of the time.

Re: Uncomfortable Truths in Software Engineering

#42
This one from the article is a bit weird:

> Sophisticated DSLs with special syntax are probably a dead-end. Ruby and Scala both leaned hard into this and neither got it to catch on.

Rails is one of the most popular web frameworks around and a combo of Rails and Ruby power some really high traffic / high importance platforms like GitHub, Shopify and Stripe's API.

Re: Uncomfortable Truths in Software Engineering

#43
post #15

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.

Although they have many faults, Microsoft has cared about compatibility for 30 years (you can still run DOS programs on your Windows 10 computer). They have cared about the security of their users since about 1999, and they cared about their user’s privacy for about 10 years before dropping it in favor of advertising revenue a few years ago. People still install Windows on new their computers, so it evidentially isn’t a big concern for most people either. Their support for accessibility technologies is probably better than most operating systems, though it’s a bit hard to tell from the outside. Performance is an odd one. It is my understanding that the Windows kernel gets high marks for performance, but aside from that almost nothing does.

Re: Uncomfortable Truths in Software Engineering

#44

Earlier quoted context omitted.

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.

"The system harnesses the power of incentives to make people do the right thing!"

"But here the incentives point in the wrong direction."

"It's not the system's fault! People shouldn't follow those incentives!"

Re: Uncomfortable Truths in Software Engineering

#45
> ... will never broadly adopt Sphinx/rST or Sphinx/MyST, because everybody already knows how to use markdown.

No. It's because the syntax is, well, §!$?§$. Headings, things like using an image as a link, that takes two lines of it's own (3 with an alt text).

    .. |LABEL_TO_USE| image:: image.jpg
       :target: http://example\.com

Re: Uncomfortable Truths in Software Engineering

#46
post #42

This one from the article is a bit weird: > Sophisticated DSLs with special syntax are probably a dead-end. Ruby and Scala both leaned hard into this and neither got it to catch on. Rails is one of the most popular web frameworks around and a combo of Rails and Ruby power some really high traffic / high importance platforms like GitHub, Shopify and Stripe's API.

Ruby had a huge hype, then its growth slowed down and now it's falling behind quickly. Yeah it's big, but other frameworks that chose a different path w.r.t. metaprogramming seem to be the more popular (and growing) choice today.

Re: Uncomfortable Truths in Software Engineering

#47
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?

Re: Uncomfortable Truths in Software Engineering

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

It... depends.

I like Typescript. The Typescript enthusiasts are also glib about what a pain it can be to teach. This is not a minor tradeoff.

Re: Uncomfortable Truths in Software Engineering

#49
post #5

>The open source maintainer problem isn’t going to get much better in the near future. >People are gonna keep blaming “Capitalism” for this. Capitalism is great, there really is no need to defend it at every opportunity, especially if no one is attacking it.

great is a relative term. It's much better than feudalism, and certainly better than the most prominent socialisms that've been tried (USSR, China etc). However, it does not align incentives towards the things we think are "good", like maintaining open source software, securing software, etc - so it certainly isn't ideal.

Government systems don't seem to have any better track record for security. That alone should stop this particular line of argument.

Re: Uncomfortable Truths in Software Engineering

#50
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'…

I think the trend is more of a pendulum swinging back and forth than a single cycle of "static" => "dynamic" => "oh, dynamic was bad, so static" explanation. Prolog, Smalltalk, Lisp, etc. are likely older than most of the engineers now very enthusiastic about static typing. Static typing is fashionable right now, I suspect, because it's the first time many engineers are stumbling upon it via Typescript, Sorbet, Haskell (or Haskell-derived projects like Elm). I predict eventually the costs (and let's be honest: static typing is not free) are realized, there will be a re-emergence of dynamic typing being fashionable again in the next 10 years.
Post reply on HN