Live data from Hacker News

Ask HN: Have we screwed ourselves as software engineers?

news.ycombinator.com

321–330 of 430 posts

Re: Ask HN: Have we screwed ourselves as software engineers?

#321
post #216

Earlier quoted context omitted.

The debugging story around PHP is better than other major scripting runtimes like Node. With PHP and kcachegrind you can really understand where you're spending CPU easily. The tools for Node work but just aren't there yet. Another nice combo is Java + Mission Control.

The debugging story around PHP is better than other major scripting runtimes like Node. With PHP and kcachegrind you can really understand where you're spending CPU easily. The tools for Node work but just aren't there yet. Another nice combo is Java + Mission Control. Fair enough, but I was thinking more along the lines of debugging logic. With python I can open up a local repl or jupyter, run the affected functions…

Fair enough as well, but the internet seems full of people who’ve used php decades ago, and spread falsehoods based on that as fact. Your REPL complaint specifically is void these days - you can do exactly the same with a php interpreter, there’s kernels for Jupyter, tracebacks, repl locally and in any production environment (readline is baked in).

It’s incredibly frustrating to see people discuss the language without any actual knowledge of it. Modern php involves one of the most stable package managers of any language, an extremely fast runtime with a JIT compiler and opcode cache, asynchronous code and coroutines (well, native green threads at least, but proper coroutines via an extension), mature frameworks, stateful application servers, solid standards among frameworks, containerised stacks,… it’s a joy to work with, yet people complain about standard library function names and form handling in templates from 1999.

Re: Ask HN: Have we screwed ourselves as software engineers?

#322

You are experiencing what I call "The Bisquick Problem". Bisquick is basically flour with some other stuff, like salt, premixed into it, and sold in a box in the USA. So instead of just buying flour and salt, you buy them together, which makes some things easier (like making pancakes), but it complicates literally everything else. You can't use it as flour, or as salt. With software, the problem is even greater. You…

I like the analogy, but it strikes me as missing the upside (and other potential causes of problems the author may be seeing).

Bisquick is a great solution if you have only one problem. I want more solutions like Bisquick: easy to map to the problem (pancakes -> Bisquick; not pancakes -> not Bisquick), hard to fuck up, low marginal cost above the inputs. It's great!

In the converse, we have lots of custom software solutions which are exorbitantly costly over the long term. Small companies without in-house expertise have to figure out how they will maintain software they depend on when their consultant (or the boss's nephew) leaves. Big companies with significant workloads and workforces can afford (and indeed, profit from: https://danluu.com/in-house/) high-complexity custom engineering, which is...fine...but even FAANG have trouble figuring out how to incentivize system maintenance and support.

At heart, I believe we haven't come to grips with the extreme disparity in capital costs vs unit costs of software, such that we don't really know how to pay for the unpredictable costs of bitrot and maintenance. As a result, every software development project is ultimately a question of "how are you going to pay for its ongoing support".

Re: Ask HN: Have we screwed ourselves as software engineers?

#323
It has been these waves for the last forty years I have been doing this for a living. "The New Thing" shows up, people run around like chickens with heads cut off chasing "The New Thing", then "The New Thing" becomes "The Old Thing". Wash. Rinse. Repeat.

What you have to do as a developer is try to keep up with the hundred new things, possibly dabble in them to see what they are, and decide for yourself how much effort you want to put into that particular "thing". You have to use judgement or you will burn yourself out.

I never bothered with Pascal. I learned enough Java to be dangerous, but it didn't really apply to my problem/solution domain. I did learn C++ and also learned to distinguish between when a solution looked like an object (C++) and when it did not (ANSI C). If anyone tells you to 'always use C++' ignore them.

I learned Perl, because I found it more useful than AWK for large problems, but AWK still reigns supreme for 'one liners'. Then I learned Python, and discovered that the problems then fall into Python or AWK. I rarely use Perl anymore.

I tried my hand at Go. I don't find it very satisfying. I am looking at Rust.

Everything else I have ignored, by virtue of choosing what problem domains I am interested in solving.

So that software engineers are not screwed, not by any margin. Just choose the problem/solution domain that you want to work in, narrow down the tools you want to be competent in, and move forward. Try to avoid the 'Look! A Squirrel!' response mode as much as possible, but do poke your head up to see what the world is doing on occasion. But be aware, a lot of it us useless noise.

Re: Ask HN: Have we screwed ourselves as software engineers?

#324

Earlier quoted context omitted.

Because it is repeating theme on these boards: someone expresses a nonconventional or old-school way of doing things, and someone else always jumps on with why overcomplicated cloud shit should be the solution to everything. Most businesses are never going to be a Netflix or a TikTok or whatever. Yet their businesspeople are absolutely infected with this mindset. And don't get me wrong, it is a disease and its primar…

> and someone else always jumps on with why overcomplicated cloud shit should be the solution to everything. I didn't say anything like that. the opposite in fact. Next time try reading and understanding a comment before going off like an obnoxious jerk

You didn't say it, I did. Pot, meet kettle. This "obnoxious jerk" has an axe to grind.

Re: Ask HN: Have we screwed ourselves as software engineers?

#325
post #17

Earlier quoted context omitted.

From Wolfram Math World > Reversion to the mean, also called regression to the mean, is the statistical phenomenon stating that the greater the deviation of a random variate from its mean, the greater the probability that the next measured variate will deviate less far. In other words, an extreme event is likely to be followed by a less extreme event. It is a stretch (and invalid, generally) to extrapolate this well-…

> There are many complex systems that maintain or increase their complexity. Increased complexity is only achieved with additional energy input. im suggesting that if energy (read: money) going into the system decreases rather than increases, there will be a reduction in complexity.

The software industry has significant energy input.

Re: Ask HN: Have we screwed ourselves as software engineers?

#326

Earlier quoted context omitted.

No, it definitely has got worse, I've been doing this 15 years, the sweet spot was the Rails revolution. Before that a lot of frameworks were a bit too much magic, and not enough understanding of how browsers, http and html worked. Simple MVC stacks went to all languages, jQuery front-ends doing enough but not a lot. JavaScript enhanced easy to reason about server-side stacks. You used to spend a couple of days a yea…

> Moving everything into hard to debug http calls has been a disastrous productivity sink. I'll admit for the vast majority of web apps out there, this is not needed, but there is definitely a scalability concern if your entire stack is a single ruby on rails mvc application.

This is the misconception that will just never die.

I've worked on multiple products with 1 million+ users running on stock Rails MVC backends. Everything scales just fine. Until you hit a DB hardware limit you can just keep adding more web instances behind your load balancer. And DB Hardware limits these days are astronomical.

If you're actually hitting the limit of scaling our web backends horizontally and you don't have the money to deal with the problem, you might need to take a hard look at your product.

And I'm confident this is true for whatever your backend is: Django, Rails, Laravel, whatever.

Re: Ask HN: Have we screwed ourselves as software engineers?

#327
post #17

Earlier quoted context omitted.

From Wolfram Math World > Reversion to the mean, also called regression to the mean, is the statistical phenomenon stating that the greater the deviation of a random variate from its mean, the greater the probability that the next measured variate will deviate less far. In other words, an extreme event is likely to be followed by a less extreme event. It is a stretch (and invalid, generally) to extrapolate this well-…

> There are many complex systems that maintain or increase their complexity. Increased complexity is only achieved with additional energy input. im suggesting that if energy (read: money) going into the system decreases rather than increases, there will be a reduction in complexity.

Consider a counterexample: an open source project that loses favor / funding / contributors. Does it become less complex? Probably not.

Re: Ask HN: Have we screwed ourselves as software engineers?

#329
post #12

> Rust for CRUD apps? Are all CRUD API’s insensitive to performance? Correctness?

No, but Rust is a low productivity, high formality language; one needs to make a tradeoff whether it's really that important. Given that most CRUD services are just a layer on top of a database. This is the reality of software development; you have a budget and you have a goal. If all your budget goes up on making it correct without finishing it, you have a problem. Anyway, it's just a CRUD app, it doesn't have to be…

Claiming that Rust is a low productivity language, generally, is too broad of a claim to be even be plausible.

The parent commenter may have some narrow or situational definition of productivity.

Re: Ask HN: Have we screwed ourselves as software engineers?

#330
post #76

Earlier quoted context omitted.

> But all those ideas solve real problems too. All of them, except for blockchain. That one can go die on the trash heap of history.

Well, it's a good tool for money laundering and purchasing drugs.

Keeping a permanent log for one's illegal activities seems... suboptimal.
Post reply on HN