Uncomfortable Truths in Software Engineering • Hacker News Board

Re: Uncomfortable Truths in Software Engineering

#371

Post by TiredGuy » Wed, Dec 15, 2021, 10:17 PM 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'…

But this was specifically in reference to introducing statically-typed tech into something that didn't have it (the original quote was "companies have been backporting typescript/mypy/sorbet onto existing dynamic codebases"), therefore it's new in the sense that it wasn't in that place before and now it is being introduced there. So there could absolutely be a honeymoon period local to that team/project.

Re: Uncomfortable Truths in Software Engineering

#372

Post by 908B64B197 » Wed, Dec 15, 2021, 10:20 PM UTC

62951413 wrote: post #328

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…

Wait until you get to your 40s to appreciate other factors. "teachers, firefighters" enjoy: * structured careers with well-defined benefits that they keep even after retirement * accumulate experience that's valued by their employers all the way to retirement * can find a job anywhere; don't need to emigrate/move to SFBA/NYC/London/Berlin, speak foreign languages, be surrounded by aliens from distant lands * are resp…

> structured careers with well-defined benefits that they keep even after retirement

That's why careers have a stock comp. Jobs don't.

> accumulate experience that's valued by their employers all the way to retirement

Real engineers do get that.

> don't need to emigrate/move to SFBA/NYC/London/Berlin > speak foreign languages > be surrounded by aliens from distant lands

I can't help but hear a dog whistle here...

Re: Uncomfortable Truths in Software Engineering

#373

Post by sorokod » Wed, Dec 15, 2021, 10:30 PM UTC

> 10. TDD/FP/Agile zealots are probably zealots because adopting TDD/FP/Agile/Whatever made them better programmers than they were before.

Possibly, but that doesn't mean it made them good programmers.

Re: Uncomfortable Truths in Software Engineering

#374

Post by de_keyboard » Wed, Dec 15, 2021, 10:32 PM UTC

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.

It's hard to complete with JavaScript on client and server. How's the Ruby to JS story these days?

Re: Uncomfortable Truths in Software Engineering

#375

Post by mamcx » Wed, Dec 15, 2021, 10:38 PM UTC

pron wrote: post #348

mamcx wrote: post #202

Earlier quoted context omitted.

Also, TODAY type checking (and more important, how Types are used) is not the same than YESTERDAY types usage. Java, C++ and similar are terrible benchmark for it. Before, types were almost for do taxonomy, with limited help to actually write CORRECT code, and more important, MODELING the domain was very verbose and with limited advantages!. Against that , no static types makes more sense. With o without the end resu…

You may believe that, but the fact is that 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, either compared to "old types" or in general, and not for lack of trying. At this point, it's okay to believe it, but I'd be very careful about being so sure about it. Large effects are very easy to detect and are hard to…

> 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 issues I get of the Rust codebase are a fraction of what I has.

--- And I think many studies show it?

Re: Uncomfortable Truths in Software Engineering

#376

Post by akavel » Wed, Dec 15, 2021, 10:53 PM UTC

wk_end wrote: post #334

akavel wrote: post #276

Earlier quoted context omitted.

So, that makes me notice I didn't clearly explain, that my idea here would be for some kind of guard blocks that enforce static typing (etc.) in some areas of code. Kinda similar to "unsafe" in Rust: ideally, you could start with e.g. fully dynamically typed code, then mark some parts of it with "I want this area typechecked", finally requiring all of it to be. Now that I think of it, seeing that in statically typed…

If I'm understanding you correctly, this is basically what we have with Typescript, and it's...fine, but it's not great. The difference between what you're suggesting and what Rust does is that in Rust the unsafety is lexically scoped - it concerns static code, not live data, so it can't escape the unsafe code block. Whereas in Typescript, as soon as you let an `any` flow back into the rest of the system, all bets ar…

So, IANAPLT, and I think that must be definitely clear now if it wasn't enough so before... but then, who says I can't dream! :D and in this dream of mine, those things seem to indeed be lexically scoped, apparently... :) As to the next thing, I feel I don't understand completely the details of what you wrote in the ETA section, but wouldn't it be similar like with unsafe in Rust? AFAIU, it's on the writer of the code in the unsafe block to ensure that whatever leaves the unsafe zone, it has its invariants all buttoned up and behaves properly back in the civilised world.

As for not being trivial, I kind of maybe have to understand (I found esp. Hishamhm's presentations about the design and evolution of the Teal language, née TL a.k.a. Typed Lua, enlightening yet approachable in this regard); yet, again, IANAPLT and I can dream :) and who knows, maybe some actual PLT will look at it and say, whaa, hmmm; but is it really for sure impossible? I. AM. CURIOUS.....

Re: Uncomfortable Truths in Software Engineering

#377

Post by pron » Wed, Dec 15, 2021, 11:55 PM UTC

mamcx wrote: post #375

pron wrote: post #348

Earlier quoted context omitted.

You may believe that, but the fact is that 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, either compared to "old types" or in general, and not for lack of trying. At this point, it's okay to believe it, but I'd be very careful about being so sure about it. Large effects are very easy to detect and are hard to…

> 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, but probably not than in Java or even (the untyped) Clojure.

Rust is a special case because its main contribution is to use typing rules to solve a harmful problem that's well-known and particular to C (or C++).

Re: Uncomfortable Truths in Software Engineering

#378

Post by wk_end » Thu, Dec 16, 2021, 12:21 AM UTC

akavel wrote: post #376

wk_end wrote: post #334

Earlier quoted context omitted.

If I'm understanding you correctly, this is basically what we have with Typescript, and it's...fine, but it's not great. The difference between what you're suggesting and what Rust does is that in Rust the unsafety is lexically scoped - it concerns static code, not live data, so it can't escape the unsafe code block. Whereas in Typescript, as soon as you let an `any` flow back into the rest of the system, all bets ar…

So, IANAPLT, and I think that must be definitely clear now if it wasn't enough so before... but then, who says I can't dream! :D and in this dream of mine, those things seem to indeed be lexically scoped, apparently... :) As to the next thing, I feel I don't understand completely the details of what you wrote in the ETA section, but wouldn't it be similar like with unsafe in Rust? AFAIU, it's on the writer of the cod…

Well, all I mean in the "ETA" is that if you want very robust guarantees about type safety - more robust than Rust's notion of safety - then you're going to be very, very restricted in what you can do.

OTOH, if you're fine with looser guarantees about correctness, I'm not sure if marking blocks as safe/unsafe really gets you much more than Typescript, which does (with strictness turned on) force you to be explicit whenever you're using anys. And it's unclear how you can "button up" dynamic data and pass it back to the civilized world.

Re: Uncomfortable Truths in Software Engineering

#379

Post by comp_throw7 » Thu, Dec 16, 2021, 12:24 AM UTC

jazzyk wrote: post #347

lkrubner wrote: post #185

Earlier quoted context omitted.

The wages for software developers were basically stagnant from 2001 to about 2014 or 2015. The big surge in pay is relatively recent. While this is a complex subject, I have written about a few examples, and can offer more. But take this as one example: Right now the best devops people in New York City are making between $200 and $300 an hour. That's obviously good money, but in the 1990s I had older friends who were…

>But it is absolutely true that pay has been surging since about 2014/2015 Only partially true: 1. High total compensation (not salaries) is limited to FAANG/Unicorn employees (awash with money) 2. That high compensation has been achieved by stock options multiplying in value, thanks to abnormal run of the stock market (thank you Federal Reserve), which is not going to continue with rising interest rates 3. Salary ba…

> 1. High total compensation (not salaries) is limited to FAANG/Unicorn employees (awash with money)

Very nearly every publicly-traded tech company, actually. The list of "tech" companies where mid-level engineers aren't breaking 200k TC is much shorter than the opposite.

> 2. That high compensation has been achieved by stock options multiplying in value, thanks to abnormal run of the stock market (thank you Federal Reserve), which is not going to continue with rising interest rates

Initial offers have been increasing; we aren't talking about golden handcuffs that employees have from stock growth. To give a very recent example: Amazon recently bumped up their pay-band for mid-level engineers and they seem to be hitting 350k/year (maybe more; have seen a couple reports of 400k). Their mid-level pay-band previously topped out at ~300k/year.

> 3. Salary base seems to be stuck at $150K for mid-senior developers in bigger cities (except for NYC) for many years now

...you mean "except the Bay Area", right? Though it's definitely not true either way; I live in a large city that isn't in the Bay, Seattle, or NYC, and 180k is a pretty common number for senior engineer base salaries, and I see 200k+ more and more frequently. (Not that I care too much about just base; given the choice why would I work for a company that only pays base salary, i.e. ~half of what other companies pay?)

Re: Uncomfortable Truths in Software Engineering

#380

Post by Tozen » Thu, Dec 16, 2021, 1:02 AM UTC

pbourke wrote: post #319

citrin_ru wrote: post #316

Earlier quoted context omitted.

> Number one, static type checking is hardly a "new tech" Static typing of course not new, but migrations usually happen to relatively new languages: Go, Rust, TypeScript. I haven't seen reports recently of any large migrations to Ada, Pascal or even C++ or other old (20yo+) language. > MongoDB. Way too hyped-up during its honeymoon, and then almost immediately crapped MongoDB is still used in new projects but it is…

> I haven't seen reports recently of any large migrations to Ada, Pascal or even C++ or other old (20yo+) language. Things are quietly rewritten in Java and C# all the time. I’m sure it happens with C++ as well since the more recent quality of life improvements have landed in that language.

Java and C# are very "corporate languages". Microsoft and Sun/Oracle have done well in their marketing and manipulations. The usual philosophy is that it's easier to find programmers that know those languages, so it should be easier to support and replace programmers as needed.

It creates a kind of "self-fulfilling prophecy". "We can only find Java and C# programmers, so everything needs to be and upgraded to Java or C#. Since everything is in Java or C#, we have no choice but to keep using it. Since everything is written in Java or C#, then those are the languages I better learn." It's very hard for other languages to penetrate that bubble.

Ada, and even more so for C++, will hold on relative to the code previously written with them. But clearly, so many programmers will "hedge their bets", with also learning Java or C#.

Pascal/Object Pascal/Delphi, from back in the 1980s, was a "problem" for which big players (like AT&T, Microsoft, Sun, etc...) have arguably pushed a lot of hate and disinformation towards. There is a good argument to say that these days it's really more for independents and mavericks. Way more for Pascal programmers who managed to get themselves into positions of power, that are calling the shots or can influence what gets used.

Delphi/Embarcadero would have made the language extinct because of their short-sightedness, charging outrageous prices for its IDE/compiler to the enterprise, and developing little to no Object Pascal talent, if not for the open source projects of Free Pascal/Lazarus and PascalABC. Interestingly, a few changes in the past or future, and Object Pascal could/can be a contender. It is a viable alternative to Java or C#, but doesn't have the corporate push.