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

51–60 of 400 posts

Re: Uncomfortable Truths in Software Engineering

#51

Post by abernard1 »

varjag wrote: post #30
abernard1 wrote: post #20

Earlier quoted context omitted.

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.

This is true, but the adoption has been dramatic.

The question I would have is what would take for this adoption to reverse? Where is the dissatisfaction with the model? The rationale for Typescript and Sorbet was precisely long-term maintenance and codebases at scale.

To add to the list, there's also Clojure spec and Elixir spec. All of these tools have a similar philosophy across very different problem domains. All of them have enthusiasm and the model of type annotations for dynamic languages is decades old.

To reference another one of the author's points: people are slow learners in software engineering. The continued reinvention of this concept decade after decade shows its utility, both theoretical and practical.

Re: Uncomfortable Truths in Software Engineering

#52

Post by ReleaseCandidat »

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…

The biggest problem is talking about 'statically typed' and 'dynamically typed' languages as if Haskell and C and Javascript, Python and Common Lisp (or Clojure) are the same.

Re: Uncomfortable Truths in Software Engineering

#53

Post by helpfulmandrill »

stickfigure wrote: post #49
beaconstudios wrote: post #12

Earlier quoted context omitted.

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.

"Capitalism" and "government" aren't opposites.

Re: Uncomfortable Truths in Software Engineering

#54

Post by CharlesW »

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.

From a capitalistic POV, it's irresponsible not to exploit ("make full use of and derive benefit from") underlying economic systems, no? This is why a purely capitalist, free market economy would be a societal disaster.

Re: Uncomfortable Truths in Software Engineering

#55

Post by varjag »

abernard1 wrote: post #51
varjag wrote: post #30

Earlier quoted context omitted.

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

This is true, but the adoption has been dramatic. The question I would have is what would take for this adoption to reverse? Where is the dissatisfaction with the model? The rationale for Typescript and Sorbet was precisely long-term maintenance and codebases at scale. To add to the list, there's also Clojure spec and Elixir spec. All of these tools have a similar philosophy across very different problem domains. All…

Well my point was not that all technologies are equivalent. And it could well be than a new iteration of B is better than ancient version of A. But that the way industry celebrates new (or if you wish, rediscovered) paradigms is too detached from reality to be useful as any objective metric.

Re: Uncomfortable Truths in Software Engineering

#56

Post by formerly_proven »

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…

I too have C++ experience and would never take "it compiles" as a sign that it'll work. I don't dispute that there are languages which have sufficiently powerful and complex type systems and compilers that enable you to model significant amounts of domain constraints such that you feel you don't "need" tests, because it'll probably work if it compiles (though I'd argue that you really ought to still have tests to verify your modelling of the domain in the type system is correct, i.e. a set of programs that must typecheck and a set of programs that mustn't typecheck) -- C++ is not usually one of those.

Re: Uncomfortable Truths in Software Engineering

#57

Post by the_gastropod »

emteycz wrote: post #46
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.

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 frameworks like Django, Rails, Spring, etc.

Re: Uncomfortable Truths in Software Engineering

#60

Post by hasmolo »

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…

i think your expertise in C++ might be affecting your view of python more than expected. i used to feel this way about languages other than my « primary » one and it turned out i just wasn’t as good at others and blamed the language for it
Post reply on HN