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

71–80 of 400 posts

Re: Uncomfortable Truths in Software Engineering

#71

Post by StevePerkins »

the_gastropod wrote: post #50
StevePerkins wrote: post #16

Earlier quoted context omitted.

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

Popular music changes every 5 or so years, because freshmen entering high school want their own identity that's distinct from the seniors who just graduated. This is why they can reject the music wave that came just before, yet also embrace nostalgia for the prior wave that came before that. That's fine, because the previous wave of kids (from which we want a separate identity) weren't into that wave.

This teenage dynamic carries over into adulthood. Academia is a bunch of young adults chasing tenure, by publishing papers arguing that the existing batch of tenured professors are washed up and got it all wrong. And also "rediscovering" the older research that was discarded by the previous generation.

Software development is a bunch of a junior devs working on bug tickets. Frustrated by the tech debt they inherited, and convinced that tech debt comes from the tech rather from the organization. It's just that in comparison to academia, technology has the generational lifespan of fruit flies. So we spin through the cycle a lot faster than other walks of life.

Re: Uncomfortable Truths in Software Engineering

#72

Post by emteycz »

the_gastropod wrote: post #57
emteycz wrote: post #46

Earlier quoted context omitted.

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.

While that may be true, I'm not sure that's evidence that DSL's are the reason. I would argue the explanation is: JavaScript. I think many people are compelled by the idea that you can learn one language, and handle both back and front-end development. As the language has improved over the past ~10 years, this angle has only become more compelling, and has eaten into the popularity of other "traditional" web framewor…

I myself am one of these people. But even if Ruby worked anywhere and I could share all my code, I would still prefer TypeScript because of its support for typed JSX and excellent typing system overall. The IDE can help me in most cases, while it stays silent a lot with Ruby. I just don't see what more Ruby offers - and I'm saying that as someone who really likes OOP and really wanted to like Ruby.

Re: Uncomfortable Truths in Software Engineering

#73

Post by roenxi »

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…

Typing is almost a no-loss addition though. If your function takes an integer argument and someone might pass it a string, that is a bug. It is quite hard to argue that a typing mechanism won't improve code quality, and it is very lopsided in the amount of time it takes to type a function vs. debug something that would have been caught by a type system.

There are edge cases that can be argued all day, but if some large codebase is going to be maintained long term it is difficult for me to see how types could be a handicap. Even if a coder doesn't really engage with the type system "properly", as little as capturing information that was already obvious anyway will reduce the bug count.

There are good reasons to expect typed languages to do well.

Re: Uncomfortable Truths in Software Engineering

#74

Post by WhompingWindows »

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 making great money by utilizing the greatest tool of all time: the computer.

It's uncomfortable because many of us didn't understand this going in. We liked computers for a long time, we had a penchant for working with them, and it turned out that made us great money. Meanwhile, our friends who are teachers, firefighters, child-care workers, etc. are doing tough work daily for less pay, perhaps simply because they didn't use computers much or didn't like them. And yet, their jobs are ESSENTIAL and we need people to do them even though they're grueling and underpaid.

Re: Uncomfortable Truths in Software Engineering

#75

Post by jasonhansel »

nickjj wrote: 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.

Languages that allow the creation of such DSLs do, in the end, seem to be gradually declining in popularity. This is probably because it is difficult to add static typing to a language that flexible. (Even in JavaScript this has proven difficult, as shown by the fact that TypeScript is known to be unsound.)

Re: Uncomfortable Truths in Software Engineering

#76

Post by mojuba »

snth wrote: post #69
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…

Counterpoint: life in communist countries is not known for being "not miserable".

That's the most irrelevant counterpoint that can be made here. "Communist" states were also totalitarian, i.e. undemocratic and that was the main reason for their ultimate failure. With democracy they'd be able to self-correct and likely switch to free[er] markets for example.

Consumer software and Internet are probably the least regulated areas of engineering today, that's the problem. Compare that to aerospace, construction, etc. Regulation though is not part of the free market capitalism paradigm, it's the prerogative of democracy.

Re: Uncomfortable Truths in Software Engineering

#77

Post by teddyh »

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?

Probably not, no.

https://en.wikipedia.org/wiki/Criticism_of_copyright

Re: Uncomfortable Truths in Software Engineering

#78

Post by afarrell »

nisa wrote: post #67

> The open source maintainer problem isn’t going to get much better in the near future. People are gonna keep blaming “Capitalism” for this. People are gonna keep blaming “Capitalism” for a lot of irrelevant things. People are gonna argue with me about blaming “Capitalism”. Goddamn I am so tired of “the problem is CAPITALISM” takes and they will never stop The entitlement and arrogance is pretty mind-blowing - those…

The problem is that there’s no agreed-upon point when we give FOSS maintainers the negotiating power to get the compensation they actually need —- whether that is patches or pesos.

Re: Uncomfortable Truths in Software Engineering

#79

Post by stackedinserter »

bluGill wrote: post #21
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++ wo…

Python in a project == tech debt. Same for bash scripts.

For us, Golang turned out to be the optimal balance between (probably imaginary) strictness of C++ and "everything allowed until 2AM PD call" philosophy of Python.

Even for simpler things like scripts and little auxiliary services Python is bad, because these little things tend to grow and get more complex.

Post reply on HN