Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>Incompetent people will create incompetent things regardless of the tool

Which is neither here nor there.

For one, it ignores the pragmatic issue, that very competent people (the very people that built the foundations we all work on even) will still make lots of mistakes, even trivial ones, but with severe consequences (e.g. buffer overflows) when the languages don't prevent them.

If only it was just "incompetent people" that made mistakes...

>But after 20 years of bouncing around startups I've never seen the intended results actually happen a single time. Not even close. Not once. Never.

You weren't looking hard enough. Every day millions of programmers don't make "buffer overflow" errors for example, that otherwise they'd have made, because they work in languages that don't allow them.

And they'd have made those mistakes regardless of their programming chops. The best programmers, people that run circles around you and me, still make those mistakes.



Totally agree with this.

The way I think about it is if you think through the entire software stack and all the instructions that get executed across all the machines and their operating systems and programs running underneath before things even get to your code and then all of the standard library and framework code plus your code. For just a simple loading a web page that is a trillion piece jigsaw puzzle and every single piece has to line up or the whole thing just doesn't work.

We do the humbling and the remarkable every day and trillion piece jigsaw puzzles are no joke. It's the exception that you get it right. Given all the pieces required that's a lot of sources of potential entropy and the more it increases the more the system destabilizes and/or becomes unworkable. Things like languages, libraries, frameworks etc make certain decisions on your behalf with the goal to contain some of that entropy within their given abstraction.


Those mistakes aren't easy to spot or easy to fix.

It's about giving code sunlight so that action at a distance and other kinds of magic don't hide errors making them harder to find, get in your way of fixing them, making reproducibility a mess and confirmation simply guesswork.

Its the restrictive design trend of crippling languages which needlessly prevents the sunlight effect from happening along with "information hiding principle" gone completely amuck with the information successfully hidden in dozens of innocently named files with listeners, observers, watchers, triggers and who knows what else being mysteriously called based on reflective programming so not even grep will help you.

Static code analysis and seamless navigation is totally a thing of the past.

Instead, the errors will have the stack of the error handler and that's it. The debugger is useless because stepping through the code is 98% scaffolding.

All these fancy tools bludgeoning any introspection or diagnostic system so the only remaining workable debug system is printing debug variables and rerunning the code like I'm programming on a TI-81 (only that had debug and release run modes...features I can usually only dream of these days) Progress! Welcome to 2019!

It's crazy. This isn't how maintainable code is written


You are speaking to the inmates writing the asylum. Give it up. This is the 4chan of the enlightened.


The amateur-to-expert ratio of any topic is directly proportional to its popularity. It's why popular things are polluted with well-intentioned bogus information.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: