There is an interesting genre of complexity that is justified (by its creators) on the grounds of simplicity. One sub-genre makes reducing the line count the primary measure of simplicity. Another sub-genre aims for the most generic and flexible code in order to simplify reuse and modification, regardless of the chances those capabilities will ever be used, or whether several different specific programs would be the simpler, faster and cheaper solution.
Why most “clever” code ain’t so clever after all
71–80 of 104 posts
Re: Why most “clever” code ain’t so clever after all
#72This article hinges on a rather silly fallacy. Luckily the author does us the favor of making his mistake very clear in the curve-fitting analogy; but first look at the code. He gives several examples of poorly-written FP code (which we're supposed to believe is "clever" by virtue of being FP), then introduces some new problem constraint which is carefully selected to make the FP solution break but some equally ridic…
So I think what the article asks for (i.e. to bring some more objectivity into the "alchemy" of code preference) is a great ask. However I agree with you however that his examples feel cherry-picked (and I sense an annoyance at FP). I suppose the most valid case would be to both real world problems and real-world change-requests to those problems.
I tried to make a programming challenge based around this premise: http://alexrohde.com/zennish/index.html#/challenges but it never seemed to interest many people.
Re: Why most “clever” code ain’t so clever after all
#73Earlier quoted context omitted.
My rule of thumb is that I attempt to write code that a junior programmer whose experience is limited to a little more than having taken a course in the language and has done a couple tutorials on the framework(s) can maintain. I see so many developers try to squeeze every new language feature or loads of esoteric library use cases into their code because they learned something and feel like it MUST belong in the pro…
For all of Java's pitfalls, this is one of the things it really has going for it. The language itself is extremely simple. I think adding properties instead of the weirdness of getters and setters would take it to peak simplicity and straight-forwardness. (Also, maybe eliminate inheritance and force interfaces and composition instead.)
Adding properties would just make the language MORE complex. Then you would have fields, getters/setters AND properties. That said, a "property" keyword that auto-generated default getters/setters would be nice.
This was one of things that always bothered me about C#, What is the point of properties. What do the offer that public fields don't?
Re: Why most “clever” code ain’t so clever after all
#74Earlier quoted context omitted.
For all of Java's pitfalls, this is one of the things it really has going for it. The language itself is extremely simple. I think adding properties instead of the weirdness of getters and setters would take it to peak simplicity and straight-forwardness. (Also, maybe eliminate inheritance and force interfaces and composition instead.)
> eliminate inheritance Why would you want that? Wouldn't eliminating inheritance add a lot of boilerplate code?
You can use composition to reduce boilerplate as well. Composition > inheritance is something that is emphasized greatly in the React community.
Re: Why most “clever” code ain’t so clever after all
#75This article hinges on a rather silly fallacy. Luckily the author does us the favor of making his mistake very clear in the curve-fitting analogy; but first look at the code. He gives several examples of poorly-written FP code (which we're supposed to believe is "clever" by virtue of being FP), then introduces some new problem constraint which is carefully selected to make the FP solution break but some equally ridic…
But with mathematics, nitpicking is ~kind of~ the point. For example when dealing with real numbers, you can get away with defining Compact sets as bounded and closed sets; however when you enter a different Topological space, that definition will surely fall apart. So in retrospect, defining compact as bounded and closed was working in your limited test cases (real numbers) but in the real world you really have to embrace that it means there exists an open cover that a finite subcover covers the set. It is not pretty or clever as the limited case, but it is what you need to do if you want applicable flexibility.
Same with fitting polynomials to data. Statistics and Machine Learning specifically warn you of overfitting. You can get 0% training error if you try to fit MNIST with a 60,000th order polynomial, but can you imagine the test error rate?
Re: Why most “clever” code ain’t so clever after all
#76So long as the "cleverness" is well-documented it's not a problem. Authors should explain why it is written the way it is. Problem solved. I've seen some weird-ass calculations in code with no comments. If the author has gone through so much effort to come up with the clever solution why not add some commentary so the next guy can read it quickly. That's why every language has support for comments..
OTOH comments easily become outdated, and it's painfully easy to make a change that subtly invalidates a comment in another file. They're like lines of code that is never tested or run. For calculations, I'm not really sure I agree either. I used to work in games, specifically on physics and collision, and there's a point at which you have to assume that the person maintaining it has a reasonable level of familiarity…
I do not see this as an issue if the comment immediately Precedes the "Clever" section of code.
Calculations are the most important part of the code to comment I'm an Engineer most of the guys I work with have never been formally taught any programming often I see a bunch of code written in Fortran with notoriously short variable names if it wasn't for comment very easy to get lost.
So long as there is a comment saying something like
"Ergun's Equation - Calculates Pressure Drop"
You don't need to follow all the fluid dynamics to know what the code does - at minimum someone reviewing it can google "Ergun's Equation"
You don't need to comment linear Alegbra but at least comment what the code does "//Solve using LU factorization" or similar is sufficient and it beats seeing segments of code like this with no explanation:
r[i] = 1/(pb[i]+t[i]-fr1[i-1]-gr2[i-2]); u[i] = a[i]-r1[i-1]u[i-1]-r2[i-2]u[i-2]; f = pc[i]+t1[i]-h*r1[i-1];
Edit: It stripped chunks of the above code but you get the idea.
Re: Why most “clever” code ain’t so clever after all
#77Earlier quoted context omitted.
Do you maintain a high-enough level within the team though? Most "clever code" I've seen is called clever by people who are not yet proficient enough in a language to understand it. So with unskilled programmers pretty much anything that isn't straight combination of classes, loops and conditionals will be considered clever. There's a tradeoff here - I get the business reasons why one may want to have the codebase at…
Not every company wants highly skilled programmers. Depending on the complexity of the project, and cost of defects unskilled programmers may be the most cost effective.
Unskilled software developers are never cost effective. Never.
Re: Why most “clever” code ain’t so clever after all
#78This article hinges on a rather silly fallacy. Luckily the author does us the favor of making his mistake very clear in the curve-fitting analogy; but first look at the code. He gives several examples of poorly-written FP code (which we're supposed to believe is "clever" by virtue of being FP), then introduces some new problem constraint which is carefully selected to make the FP solution break but some equally ridic…
i agree with both of you
i think we need to merge and supplant imperative and functional
Re: Why most “clever” code ain’t so clever after all
#79Earlier quoted context omitted.
For all of Java's pitfalls, this is one of the things it really has going for it. The language itself is extremely simple. I think adding properties instead of the weirdness of getters and setters would take it to peak simplicity and straight-forwardness. (Also, maybe eliminate inheritance and force interfaces and composition instead.)
Adding properties would just make the language MORE complex. Then you would have fields, getters/setters AND properties. That said, a "property" keyword that auto-generated default getters/setters would be nice. This was one of things that always bothered me about C#, What is the point of properties. What do the offer that public fields don't?
You don't need getters and setters in c#. If you don't have any side effect in a read-write property you can just use an automatic property. The same for read only properties that don't need to be recalculated on the fly. And I hope that I don't need to explain why using a write only property is almost always a code smell.
In the other cases you can use a normal property with a backing field.
If your code is well written and you use the appropriate tools, only rarely you need normal properties (that are as annoying as getters/setters).
What do getters and setters offer that public fields don't? Properties offer exactly the same advantage as getters and setters, fields encapsulation https://en.m.wikipedia.org/wiki/Field_encapsulation No wonder that you don't understand properties if you don't know why getters and setters are useful.
Re: Why most “clever” code ain’t so clever after all
#80Earlier quoted context omitted.
My rule of thumb is that I attempt to write code that a junior programmer whose experience is limited to a little more than having taken a course in the language and has done a couple tutorials on the framework(s) can maintain. I see so many developers try to squeeze every new language feature or loads of esoteric library use cases into their code because they learned something and feel like it MUST belong in the pro…
For all of Java's pitfalls, this is one of the things it really has going for it. The language itself is extremely simple. I think adding properties instead of the weirdness of getters and setters would take it to peak simplicity and straight-forwardness. (Also, maybe eliminate inheritance and force interfaces and composition instead.)
Java is a quite awful language honestly. And I use it everyday at work. Generics implementation with type erasure is a pain and complicates things a lot. There is no automatic static type inference and before Java 7 you had to specify twice the generic types in the same statement. This adds a lot of "complexity" or noise when reading some code. Checked exceptions..do we want to speak about all the complexity that they add?
Before Java 8 there was absolutely no first class support to closures, and if you wanted to have something equivalent you had to use an anonymous inner class... Very simple, eh?
All the streams (as in input/output streams) are heavily used and while sometime they are useful, they complicate needlessly the code.
The streams implementation (as in the Linq-like feature) is more complex than Linq.
Honestly I can't say that Java is a simple language.
It may be true if you just use loops and basic statements, but you can say the same for pretty much every other high level language.
Finally I'm quite perplexed for the reasons why you want to kill inheritance.
While it is true that when it is abused is bad, ditching it completely is wrong because used in the right way can make you code simpler.