News for hackers. Stuff that matters.

A comment on Why bad scientific code beats code following “best practices” (2014). Parent comment

Re:Why bad scientific code beats code following “best practi... by andrepd on Sunday August 28, 2016 @05:42PM (#12378682)
>And using public fields in a non trivial project is a sure receipt for disaster.

Why, though? Surely it's the programmers' job to access what they need and leave alone what the don't. As someone else said, Python has no concept of public/private and it works okay.

[ Parent | on HN ]
Re:Why bad scientific code beats code following “best practi... by jedmeyers on Sunday August 28, 2016 @08:05PM (#12379180)
If you make the statically typed field public you lose the ability to change the implementation without breaking the clients. (Getters/setters have the same problems, but not as pronounced). And no, you don't always have the ability to recompile everything that's using your code.
[ Parent | on HN ]
Re:Why bad scientific code beats code following “best practi... by lmm on Monday August 29, 2016 @04:10AM (#12380664)
Python doesn't really "work okay" for ongoing projects. Framework updates become a 6-month migration job.
[ Parent | on HN ]
Re:Why bad scientific code beats code following “best practi... by colejohnson66 on Monday August 29, 2016 @01:07AM (#12380131)
An argument for properties are to hide the implementation details. It keeps idiots from changing variables they shouldn't (if they really want to, there's sometimes reflection), and it hides implementation detail variables from the autocomplete box.
[ Parent | on HN ]