81–90 of 104 posts
As a company we use C# and Visual Studio as an IDE. Everyone has Resharper, which is undoubtedly an invaluable tool. However, Resharper had a feature that will convert for/for each loops with conditional logic into LINQ lambdas. For simple cases I find it's conversion useful and readable, but for more complex cases it becomes an unreadable nightmare for anyone bug fixing later on. I find that to be the case even when…
Earlier quoted context omitted.
> 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.
Earlier 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?
Hmm, it's also what drove me away from Haskell and kept me on and off with the language, as most of the powerful stuff are too powerful and so hard to tame...
[1] http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude...
Earlier quoted context omitted.
You can use composition to reduce boilerplate as well. Composition > inheritance is something that is emphasized greatly in the React community.
Composition increases boilerplate code. With simple inheritance hierarchies there is an inherent advantage in this regard. If you use inheritance you don't need to encapsulate the "base" object and implement all the methods of the interfaces doing most of the time just a routing to the base object, you can just extend from the abstract base object and implement only the methods that you need. Obviously if your hierar…
You're stretching a bit too far. Inheritance is nothing but composition with some default implicit virtual method routing. You admit as much in your comment. If you want tools, it's more like a hammer vs a mallet and a prybar. Same tools, same purpose, just one is bundled.
So 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…
While comments can certainly become stale, we're talking about portions of code that will most likely not change frequently. If there's a clever solution it better need to be clever otherwise it's just bad style.
Earlier quoted context omitted.
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 sayi…
Why post this draft to HN instead of letting the other make it more refined and readable?
Earlier 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.)
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 the…
Now Java is the king of obviousness; it's very clear exactly what is being done on every line of code. It pays for it in being very wordy. I don't like inheritance because it breaks obviousness; it's no longer obvious where a virtual call is actually going to be served. With composition, the immediate object has to serve the call, even if it's just to delegate it. The only virtual calls would be dispatching calls to interface methods. And this style isn't expensive after JIT; inlining these kinds of delegations is its primary optimization. (Think getter-method chains that return a field value, a common pattern in Java.)
Lambdas were a step towards terseness, but they sacrifice obviousness to get there. It hides things... What SAM type is a lambda implementing? You have to check to call site; the lambda itself won't tell you. The anonymous class syntax tells you exactly what is being implemented, but that means you have to type more to get there.
Now, I like properties because IMO they optimize both obviousness and terseness. You are obviously making a single property with a getter and a setter, as opposed to defining each separately. And you are more terse by removing the need to define each separately.
I like that he made an attempt to make this language-agnostic, the final example, but now he's introducing the idea of "elegance," (missing a definition) and kind of saying that "cleverness == elegance == overfitting?" I think the problem here is that he's _too_ generic (might I say, he's trying to be too clever : P) and pulls in a third field to make his abstract "cleverness" case. But, from my understanding, I'm under the assumption that cross-validate is a given for models: overfitting is for chumps and students. I'd give that a "to be improved" for draft 1.1.
---
Overall, from the recap:
> “Clever” code tends to exploit explicit and implicit symmetries in the problem structure, building highly-symmetrical solutions by exploiting highly-symmetrical library functions / types.
and from the abstract:
> Unfortunately, people tend to assume that the style of such (supposedly) clever code is representative of “good” functional programming.
The main issue here is that clearly the first part is correct and makes for fragile code (given context), but he’s completely opinion based on the latter. What he needs to do is find “production-level code" or “education-level practices” that are handed down to new FP developers and taken as “truths." After reviewing the citations, I think that his points on [6] and [7] are weak: he needs to show more than just comments and one-offs, and needs to hammer in the "why this is bad" more. Instead, it feels like he's just trying to show his contempt for haskell. I'm also thinking that, if he wasn't just trying to run haskell through a ringer, you'd think he'd use other functional languages / language-features (frege is designed as "a Haskell for the JVM").
His opening line of 'there is a deluge of “clever” code constantly pushed down from gurus to hipsters to innocent readers' also primes me to think that this is more of a cathartic article than a useful one.
I'd love to agree with him, say that "stupid code, everywhere" is a problem in educating new devs for pure-functional languages, then spider the internet, comment/fix all these code examples, and finally make all my friends haskell developers : P (disclaimer: I'm just an enthusiast). However, I remain unconvinced — I think the problems in haskell education is elsewhere. Perhaps I have simply been lucky in finding sane, good resources, and all the production code I study is uncommonly blessed. Looking forward a 2.0 so that I can convert all my friends.
(I redacted some more thoughts since this is my first real post to HN; be nice!).