On Thu, 31 Jan 2019 at 17:59, Zach van Rijn <m...@zv.io> wrote: > On Thu, 2019-01-31 at 09:49 -0800, Anselm Garbe wrote: > > > > Our philosophy is about keeping things simple, minimal and > > > > ... > > > > This is still totally accurate for the software industry, even > > more accurate than we could imagine 13 years ago when those > > lines were written. > > I was pointing out the disparity between your (collective) > desire for quality software, while you simultaneously neglect > the quality of your community's forums with over-simplified > technical discussion and the shutting down of dissenting voices.
Not sure what you actually mean. As said we tend to value code higher than some academic deep dive discourse about some programming language theories. By this we might express our (high level) opinion in a more placative fashion than researchers would do. I personally think much of software development is actually an art or a craft, so it is ok to a certain degree to focus on taste rather than strong data driven judgement in all the aspects. Being good or right about things not only requires lot's of experience, but also a good portion of intuition. And the latter is barely elusive by scientific methods. > I agree that time is a valuable resource, though I've found that > spending a even a /little/ bit of time thinking about one's code > prior to sitting and writing it, results in a better outcome. I agree to this and there is no contradiction here. We did spend more time on the code here, than the average project does, just because we carefully think about the essence of things. Besides thinking before you start writing code, there have also methods developed that lead to better software. One is attempting by introducing a feature to remove another or two. This leads towards the essence. > To support your point, wouldn't it make more sense to adhere to > your own software principles during discussion by preemptively > resolving as much ambiguity in your statements as possible? It depends. When we talk about opinion or taste it is acceptable if there is a certain ambiguity. If discussing an idea in detail or in code of course there shouldn't. > Discussions would be more productive and have fewer lines. That may or may not be the case as this thread has already proven. > > understand what went totally wrong. Mixing data structures > > with behaviour is one of the worst ideas that progammers came > > up with and has led to almost unmaintainable code and data > > structures. In Java world 'refactoring' is daily business > > because of this. I can't go into more detail as this would be > > a big waste of time. If you want to learn more about it, I > > suggest to start here: > > http://harmful.cat-v.org/software/OO_programming/ > > In <any serious programming> world, refactoring is an essential > component of code maintenance. It doesn't have to be as drastic > as you might imagine, but to believe that code doesn't ever need > to be changed is irresponsible. Well, you seem to misconceive what I wrote. I did not criticize refactoring, I criticized the excessive need for it in the Java world. If data structures and logic are strictly decoupled and not intermingled, refactoring of the logic is very easy and straightforward. This is particularly true for PLs like C where it is uncommon practice to intermingle data and logic. However in a OO world like Java, it is prevalent and the refactoring becomes a burden because of this. Best regards, Anselm
