Live data from Hacker News

Why most “clever” code ain’t so clever after all

drive.google.com

101–104 of 104 posts

Re: Why most “clever” code ain’t so clever after all

#101

Earlier quoted context omitted.

I'm starting to feel like you're not actually reading anything I write. I specifically include interfaces. To quote myself: > Also, maybe eliminate inheritance and force interfaces and composition instead. Implementing an interface meets all the conditions of an is a relationship; no redefinition is necessary. [0] After all, interfaces are nothing more than abstract base classes with no method bodies to inherit. I ha…

You wrote this: "Inheritance is nothing but composition with some default implicit virtual method routing." In response to my post where I said that inheritance and composition are two different tools and doesn't make sense to say that one is always better than the other. So it seems to me that you think that inheritance and composition are the same concepts given your words that I quoted and given that you were argu…

OK, I should have stated that inheritance is a bundling of multiple tools, composition and default implicit virtual method routing being two of them. It also creates an is a relationship, which in my version of an inheritance-less world would be handled explicitly via interfaces, which I included in my original "toolbox".

EDIT: Notice how I can enforce the invariants of `Square`, while composing a `Rectangle` and implementing `IRectangle`. This works because composition allows me to encapsulate the problematic setter methods of `Rectangle`, which is not something I can do if I inherit it.

    class Square implements IRectangle {
        private final Rectangle rectangle;

        public Square(final double size) {
            this.rectangle = new Rectangle(size, size);
        }

        public double getWidth() {
            return this.rectangle.getWidth();
        }

        public double getHeight() {
            return this.rectangle.getHeight();
        }

        public double getSize() {
            return this.rectangle.getWidth();
        }

        public double setSize(final double size) {
            this.rectangle.setWidth(size);
            this.rectangle.setHeight(size);
        }
    }

Re: Why most “clever” code ain’t so clever after all

#102

Earlier quoted context omitted.

> With generics you have actually no idea of what type you receive at runtime, you receive just an object. That's kind of the point of generics? I don't understand this argument at all. If you need a specific kind of type, then bound the generic using `extend` and you can use the bounding type's methods and fields. [0] You're still using a different definition of obvious, despite my having defined it for this use cas…

The point of generics is to pass generic arguments to a method/class, as the name says. In Java you are losing every type information and at runtime your method will accept objects, not arguments with a generic type. There are several situation in which preserving the type information is extremely useful. For this reason in Java you still find a lot of libraries that receive a type as argument, while in C# you can ju…

I've got plenty of dislike for type erasure, and I do agree that it makes the language more complicated. An instance where the Java language was sacrificed to ease virtual machine implementation and backwards compatibility.

> The stream is a very well known and completely different concept and it is widely used in reactive programming, they just stole that concept to use it in a completely non obvious way.

Java streams seem to meet the ideas of stream processing to me. Given a sequence, apply transformations in order, possibly in a transparently parallel fashion. Compare the Wiki definition with the `BaseStream` interface documentation:

https://en.wikipedia.org/wiki/Stream_processing

http://docs.oracle.com/javase/8/docs/api/java/util/stream/Ba...

> Finally extension methods are perfectly obvious. They are just syntactic sugar for static methods, I hope that at least you agree that static method are the gist of obviousness.

Yes, I of course agree. My problem is that extension methods hide where they live, by pretending to live on the type. And to be fair, I have the same issue with static imports in Java. When I look at a function or method call, it should be immediately apparent where control flow is going to go. That's not the case with either static imports or extension functions; I have to resolve the method name first.

Re: Why most “clever” code ain’t so clever after all

#103
post #18
post #10

Cycled lists and the modulo operator are two different abstractions for thinking about the same problem, in the same vein of "blind men grasping at elephant." They are different perspectives on the similar problem. The reason we think that cycling a list is "clever" but using modulo is "boring" is because most of us use modulo often, and cycling rarely. There is nothing inherently "clever" about either of the two app…

The issue with the first fizzbuzz isn't just cylcling lists, it's also the use of zipWith. At least, that's what causes some of the brittleness in his examples. --- Also, I think you're slightly wrong in that cycled lists and modulo are "just different abstractions" - they may be to a machine, but they are not to people. And in this case, critically, the original problem's phrasing is much closer to the modulo implem…

Modular arithmetic (a.k.a. clock arithmetic) is equivalent to cycles in a very real, mathematical way. There's a reason that clocks are round -- in order to count the naturals modulo 12 (and again modulo 60), you simply need to cycle 1..12 (or 1..60). I'd argue that for anyone who understands modular arithmetic, the `cycle` solution doesn't seem particularly clever. Anyone with enough knowledge of number theory to understand that "x is a multiple of y" -> "y divides x" -> "x (mod y) = 0" ought to have an understanding of the relationship between modular arithmetic and cycles. This is introductory-level discrete mathematics.

Re: Why most “clever” code ain’t so clever after all

#104

I understand what they're getting at, but I think the final listing is even more "clever" than the first. The first one I could read and understand pretty easily, and I've never written Haskell. The few things it does, and how, are easy to spot. The final one is harder to understand at a glance, even though it's more generalized. Some people take it even further than that, to where the implementation is totally abstr…

The FizzBuzz example was just to underline how a "considered clever" solution for an academic problem behave when moved into "real life" situations. If we are taught to solve and think problems as if we were in an idealized world we are going to suffer once we enter the battlefield.
Post reply on HN