outlander wrote: ↑Thu Feb 22, 2018 3:11 pm
it's not the tools that make your performance good, but the ability to make wonders with the limited set of tools you were given, and your capacity to find elegant solutions to stupid limitations imposed upon you.
I'm not sure I follow the line of reasoning here. Sure, a good programmer will do good things with bad tools. But he/she will do great things with good tools.
outlander wrote: ↑Thu Feb 22, 2018 3:11 pm
In the rest of the world, managers decide which set of tools you have, and which set of limitations you need to overcome - and those people are not even coders most of the time, but bean counters and ticket-punchers.
This would likely fall under the category of fundamental things that need to change.
outlander wrote: ↑Thu Feb 22, 2018 3:11 pm
If you disagree, try writing specialised software (military, security, industrial) and you'll find out that you'll be hampered not by the programming tools, but by your lack of knowledge of the processes involved.
Eh, I've worked on training simulations for oil refineries, military training, and HPC physics stuff. Sure, it's not like I've been knee deep in that stuff for 2 decades, and yes getting up to speed on some of their processes takes time, but looking back I can't honestly say that was the largest time sink. And it certainly didn't dominate enough to say tooling improvements aren't a worthwhile investment.
Cornflakes_91 wrote: ↑Thu Feb 22, 2018 3:13 pm
yes, in a team of 20+ with unmanaged pointers and one changes a detail about how he handles his pointer access and suddenly random errors pop up all over the software and nobody knows why.
There are at least 2
major issues in that scenario. 1) Using unmanaged pointers in a system where the implementation is likely to affect the users. 2) Changing that implementation without changing the usage sites and just walking away.
This line of reasoning is looking at the problem from the perspective that "people can do bad things if you give them the ability to. Therefore don't give them the ability to do bad things."
And my response is that I don't believe that's a reasonable solution. You implement safety where the cost isn't too high, then you address the rest with training. I think there are cases where raw memory access is a useful, desirable tool. I'm generally against solutions of the style "you can
never do this thing because you might screw it up". Prefer solutions of the form "hey, this is a pretty big foot gun and we don't encourage it so we have these other tools you can use when it's not super important, but the functionality is there if/when you need it"
Cornflakes_91 wrote: ↑Thu Feb 22, 2018 3:13 pm
also, my comic form answer on the whole "real programmers use raw memory exclusively!" topic
No one has said anything close to this.
Dinosawer wrote: ↑Thu Feb 22, 2018 3:27 pm
Pardon me being blunt, but have you actually done some programming in a decent sized group on a very large commercial long-term project in a non-memory safe programming language?
No, I'm coming from the other direction. I've worked on years long team projects in memory safe languages where that was a large productivity cost. The grass is always greener, maybe?
Dinosawer wrote: ↑Thu Feb 22, 2018 3:27 pm
But no I guess we're just bad programmers for making the occasional tiny mistake in our 2800 files large, 1.7 million lines of code large C/C++ project.
I haven't seen anyone say that. And sure, maybe it's not possible to reach that scale without sacrificing some control. Or maybe it's not possible with that team, or those tools, or that particular codebase, I have no idea since I'm not in that situation.
I work in an industry where I'm probably not going to work in code bases larger than maybe 100,000 lines of code. And in my experience those type of doomsday bugs are so exceedingly rare that I'll take that over having to daily deal with things like not being able to control where my allocations go, not fully controlling the GC, and taking perf hits because of extra GC-induced indirection.
In general, this seems to have ruffled some feathers, and I apologize for that. I mean this as an honest discussion about programming because I find that genuinely interesting. I'm not claiming that I have the answer to everything or that my ideas are the correct and only ideas.
That said, I think it's worth challenging the commonly held beliefs, such as trying to force memory safety onto the programmer. If you are reading between the lines and deciding that I've said "real programmers use pointers", "real programmers don't make mistakes", or some other nonsense you're flat out incorrect.
For the sake of productive discussion, I'm going to try to clarify my position.
Problem 1: most code today is a couple of orders of magnitude slower than it should be.
Problem 2: most code today is full of bugs.
Position 1: It's worth trying to understand why this is the case and working toward solutions.
That's pretty much it. I'm not claiming programmers that make mistakes are bad, or programmers that use high level languages are bad, or any other strange extrapolation from the above.