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

341–350 of 400 posts

Re: Uncomfortable Truths in Software Engineering

#341

Post by Too »

eweise wrote: post #174
akavel wrote: post #10

Re. 3 & 5: my theory is that a language with gradual typing, gradual error handling enforcement, and "gradual proving" that is seamlessly embedded in it (see e.g. the https://nim-lang.org/docs/drnim.html experiment) could hopefully actually work here. And as to dynamic typing, I found it useful when prototyping, to quickly PoC/MVP the "happy path" of an idea/design, and see if it is worth investing any bigger effort,…

Gradual typing seems like the worst of all worlds. You spend time adding typing but can't depend on it consistently. I was surprised using Dart that it would throw runtime type exceptions even though it looked like the code had explicit types.

With that argument you wouldn’t start adding unit tests either?

If I only add one test, how can I depend on it consistently.

Re: Uncomfortable Truths in Software Engineering

#342

Post by AnimalMuppet »

dmurray wrote: post #254
jrochkind1 wrote: post #159

Earlier quoted context omitted.

Also nothing in Ruby that's called a "DSL" is actually a "special syntax". It's necessarily all just method calls on objects, ruby has no actual mechanism to introduce new syntax. So I'm not entirely sure what the OP is meaning to mean. I don't know about Scala.

You kind of know what he means. Ruby uses methods for things that look like syntax in other languages (eg the plus sign for addition) and lets you define them however you want. AND Ruby has the method_missing magic method, which means anywhere the language was expecting a method call you can put pretty much any tokens of your choice, and use metaprogramming to interpret it at runtime. Those are things that people lea…

Hmm. So C++ operator overloading is a DSL, at least in a sense. It lets you define things like + and * for vectors and matrices, so you can write your code using your usual notation for such things.

But it's a fairly limited DSL, because you can't introduce new (non-C++) syntax.

I hadn't thought of it that way, but I can kind of see it.

Re: Uncomfortable Truths in Software Engineering

#343

Post by friedman23 »

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…

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.

Re: Uncomfortable Truths in Software Engineering

#344

Post by irq-1 »

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. Something that would cause a media sensation.

Since we're talking uncomfortable truths: BALLISTIC MISSILE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL.

That was blamed on a bad UI/UX at the time, and nobody died, but there was never even talk of regulation. Credit Cards on the web got PCI DSS regulation because money, not because of people dying. Money has to be tied to "things like performance, compatibility, accessibility, security, or privacy" not lives.

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

Also, the recent Boeing 737 Max scandal resulted in a payment but no regulation.

https://www.justice.gov/opa/pr/boeing-charged-737-max-fraud-...

Re: Uncomfortable Truths in Software Engineering

#345

Post by merpnderp »

simion314 wrote: post #209
merpnderp wrote: post #82

Earlier quoted context omitted.

When people say capitalism is bad, what they're saying is allowing people to choose is bad. Because no one is forcing these products on anyone and nearly everyone has at least heard of the issues and mostly don't care.

>When people say capitalism is bad, what they're saying is allowing people to choose is bad. Because no one is forcing these products on anyone and nearly everyone has at least heard of the issues and mostly don't care. My issue is with "free markets" solve everything when most of the time you don't have free markets(like when you have too few competitors or when you have collusion not to compete ) , or when you forg…

Don't confuse free with unregulated. Not even Adam Smith wanted unregulated markets. Free simply means everyone is equally free to play in the same market created by a system of laws and equal enforcement. And I doubt you'll find anyone defending monopolies or duopolies. All systems are corrupted, we just try to minimize it when we can.

Re: Uncomfortable Truths in Software Engineering

#346

Post by poulsbohemian »

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

A couple weeks ago there was a conversation here about software in the 90s where the argument was proposed that as an industry, software veered off in the wrong direction somewhere along the way. When I read the above from the article, there's a part of me that starts feeling this...we have all this horsepower in both hardware and software such that it should be as "easy" for people to make software in the same way they can now make pictures, music, and videos without needing hundreds of thousands of dollars invested in a movie or recording studio. Like, these are mutually exclusive points - you can have APIs that maybe are a step beyond, but does that mean that all software must be hard to write? I was telling my son just last night about how people did all these cool, unexpected things with Hypercard back in the day. It didn't need to be perfect, it didn't need to be "enterprise grade" because it was easy to make and was good enough for what people wanted to do.

Re: Uncomfortable Truths in Software Engineering

#347

Post by jazzyk »

lkrubner wrote: post #185
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…

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 base seems to be stuck at $150K for mid-senior developers in bigger cities (except for NYC) for many years now

Re: Uncomfortable Truths in Software Engineering

#348

Post by pron »

mamcx wrote: post #202
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'…

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 hide. The fact that we haven't been able to easily see the effect in any rigorous way, suggests that even if there is some positive effect, the most reasonable assumption we can make right now is that it is most likely small. Having had experience with both "new types" and "old types," my personal impression (which is certainly not rigorous or necessarily trustworthy) is that such claims about a big bottom-line impact are exaggerated. Sometimes people feel they're writing more correct programs more easily, but the bottom line doesn't quite support it.

Re: Uncomfortable Truths in Software Engineering

#349

Post by evouga »

Uehreka wrote: post #326
MathCodeLove wrote: post #308

Earlier quoted context omitted.

You're correct about my language choice, I could (and should) have used more neutral language to describe my position. While I do believe that there are some fundamental differences in the interests and abilities of the genders (neither for better nor worse, they just are) I also agree that's its a slippery slope that has been abused in the past. Societal pressures and conditioning certainly play a role, however I th…

I disagree about the “equally important” stuff, and here’s why: If I’m wrong and the overwhelming majority of women really don’t like programming, I’ll have wasted some of my time, but no one will have been materially harmed[0]. However, if I am right, then there are currently a large number of people who are being pushed away from a career or hobby that could increase their overall happiness and/or standard of livin…

The unstated major premise here is that software engineering work is valuable/fulfilling/high-status, while other work is not---so that pushing someone naturally suited to software engineering away causes harm, while pushing people more naturally suited to a different field into software engineering causes less harm.

I don't think your premise is wrong, but I think it does explain why computer science is particularly focused on broadening participation, compared to other disciplines like nursing, teaching, etc. Computer science is current (for better or ill) a golden ticket to economic mobility.

Re: Uncomfortable Truths in Software Engineering

#350

Post by jazzyk »

avgDev wrote: post #214
zerocount wrote: post #171

Earlier quoted context omitted.

I would gladly give up software development for a medical or law degree. I would gladly study for a bar exam or do a medical internship instead of grinding Leetcode and throwing salt over my shoulder or some other good luck inducing act, in the hope of passing the often subjective, 'are you a fit', can you design and code Z in the next 38 minutes type interview. The barrier of entry is way too low these days and ther…

I know people saving up and getting out of the medical field, as it became extremely toxic in the US. Expensive and mostly ran by huge corporate entities seeking profit. I would much rather click on a computer.

There are quite a few toxic places in the software business, no?

Medical field (being a physician) is not a walk in the park, but:

1. nobody questions you intelligence/knowledge after, say, 20 demonstrably successful years in the business

2. on your way home you can say "tough day, but at least I am making $600K/year"

Post reply on HN