5 ms·

Really good advice. Whenever I encounter Java code that employs some or more of these techniques, I feel a little bit better about the world.

by gdp 17y ago

Retric 17y ago
Are you joking? This advice is horrible. He is advocating taking a verbose language and making it even more verbose and far less efficient. Think about what the final in "public final int x;" means in #8. Many Java developers have fallen for the idea that everything is an interface to an interface. However, if you start by trying to get stuff done, you find a most scaffolding is pure waste.
- gdp 17y ago
  He is advocating using a style more like modern functional programming languages such as ML, Haskell and F#. The example in #8 is essentially recreating primitive tuple types present in the languages I just mentioned. Given that the overheads on such an object are small, and the garbage collector is good at dealing with short-lived objects, it makes sense to instantiate a new class when it is necessary to mutate it. Your optimiser will love you, and maintaining this style of code is considerably easier.
  - Retric 17y ago
    Functional programming is ancient. You might be all atwitter about the power of functional code. But, it's an old idea. Emulating the functional style a language that's not based on it provides minimal gain, at the cost of code bloat. PS: Pun was intended to be funny not mean. This really is an old idea, which is occasionally useful, but mostly it's a waste of time, money, and CPU cycles.
    - gdp 17y ago
      Sure, but I used the word modern. As in, "of the modern era". There are old functional programming languages and there are young functional programming languages. The fact is that most of the interesting research into programming languages these days goes ends up in functional languages such as Haskell or an ML-variant. And I really don't buy your "bloat" claim. Surely mutating member variables unnecessarily is "bloat". And having redundant getters and setters seems pretty bloated to me. In fact, forcing everything in the universe into a paradigm that largely consists of straight-line imperative code boxed up in classes seems like the ultimate example of bloat, given that one could simply code in an imperative style without using objects. If anything, I would think that the measures suggested would result in marginally smaller code-size, which I assume is the metric you are employing to measure "bloat". In performance terms, I would imagine that these suggestions would result in no performance impact, or some small improvement as it is quite likely that the optimiser will be able to do a better job if you apply this style uniformly. As you say, it might be a minimal gain, but don't we as programmers have something of a responsibility to write the best programs we can and use our tools to the fullest of our abilities, especially when the cost is zero or almost-zero? So what metric are you using here? I assume it's something a bit fuzzy like "readability" or "ease of maintenance"? In that case, you're basically saying "things that are different to what I already do are harder to do", which in addition to being mildly silly, is a total cop-out and is intellectual dishonesty. Too many good ideas in programming languages have been sunk by programmers who hate the idea of not being the expert all of the time, with such behaviour being hidden behind very weak justifications that sound technical, but are actually just about egos. Naturally, this might not be the case with you at all! However, I'd be very interested to know on what objective basis you are making judgements about the awfulness and bloatedness of code (in any language) that employs a more "functional" style.
      - Retric 17y ago
        There is a reason that research into functional languages is limited to an old or new functional language. Without syntax and compiler support you don't gain any power to offset the limitations. Anyway, the power of OOP is creating intelligent data. You can "automatically" do things with a Point that you need to explicitly do with integers. If you start dealing with a Fixed_Point objects, and Mobile_Point object, you now have bloat with little gain. It's far better to have a "Final" flag on your point, so it will toss an error when you try to change it vs. trying to maintain 2 separate classes. That way if you suddenly need to change your point you have to refractor less code. Granted, if Java's foreach would automatically make helper threads to speed things up then there would be an advantage. But, changing the form without compiler support is pointless. PS: Feel free to test your ideas, but allocating memory is still the enemy of speed. When you create a temporary object outside of the stack it really does slow things down.
        KirinDave 17y ago
        I am glad to see someone else equally irritated by this "fashion statement" that people engaging in, abusing their languages to ape other languages. Even worse, most don't really understand the benefits of the languages they copy, they pull the iconic cases and then pretend that languages aren't a teepee of features that cannot stand when just a few poles are pulled in isolation.
        gdp 17y ago
        Huh? Are you suggesting that people use functional programming languages such as Haskell or ML because they are fashionable? Where on earth are you living such that they are fashionable? I wanna live there.
        KirinDave 17y ago
        Please reread what I said. The fashion statement is using a non-functional language and adopting some functional mores.

Really good advice. Whenever I encounter Java code that employs some or more of these techniques, I feel a little bit better about the world.

by gdp 17y ago

Really good advice. Whenever I encounter Java code that employs some or more of these techniques, I feel a little bit better about the world.

Retric 17y ago

Are you joking? This advice is horrible. He is advocating taking a verbose language and making it even more verbose and far less efficient. Think about what the final in "public final int x;" means in #8. Many Java developers have fallen for the idea that everything is an interface to an interface. However, if you start by trying to get stuff done, you find a most scaffolding is pure waste.

gdp 17y ago
He is advocating using a style more like modern functional programming languages such as ML, Haskell and F#. The example in #8 is essentially recreating primitive tuple types present in the languages I just mentioned. Given that the overheads on such an object are small, and the garbage collector is good at dealing with short-lived objects, it makes sense to instantiate a new class when it is necessary to mutate it. Your optimiser will love you, and maintaining this style of code is considerably easier.
- Retric 17y ago
  Functional programming is ancient. You might be all atwitter about the power of functional code. But, it's an old idea. Emulating the functional style a language that's not based on it provides minimal gain, at the cost of code bloat. PS: Pun was intended to be funny not mean. This really is an old idea, which is occasionally useful, but mostly it's a waste of time, money, and CPU cycles.
  - gdp 17y ago
    Sure, but I used the word modern. As in, "of the modern era". There are old functional programming languages and there are young functional programming languages. The fact is that most of the interesting research into programming languages these days goes ends up in functional languages such as Haskell or an ML-variant. And I really don't buy your "bloat" claim. Surely mutating member variables unnecessarily is "bloat". And having redundant getters and setters seems pretty bloated to me. In fact, forcing everything in the universe into a paradigm that largely consists of straight-line imperative code boxed up in classes seems like the ultimate example of bloat, given that one could simply code in an imperative style without using objects. If anything, I would think that the measures suggested would result in marginally smaller code-size, which I assume is the metric you are employing to measure "bloat". In performance terms, I would imagine that these suggestions would result in no performance impact, or some small improvement as it is quite likely that the optimiser will be able to do a better job if you apply this style uniformly. As you say, it might be a minimal gain, but don't we as programmers have something of a responsibility to write the best programs we can and use our tools to the fullest of our abilities, especially when the cost is zero or almost-zero? So what metric are you using here? I assume it's something a bit fuzzy like "readability" or "ease of maintenance"? In that case, you're basically saying "things that are different to what I already do are harder to do", which in addition to being mildly silly, is a total cop-out and is intellectual dishonesty. Too many good ideas in programming languages have been sunk by programmers who hate the idea of not being the expert all of the time, with such behaviour being hidden behind very weak justifications that sound technical, but are actually just about egos. Naturally, this might not be the case with you at all! However, I'd be very interested to know on what objective basis you are making judgements about the awfulness and bloatedness of code (in any language) that employs a more "functional" style.
    - Retric 17y ago
      There is a reason that research into functional languages is limited to an old or new functional language. Without syntax and compiler support you don't gain any power to offset the limitations. Anyway, the power of OOP is creating intelligent data. You can "automatically" do things with a Point that you need to explicitly do with integers. If you start dealing with a Fixed_Point objects, and Mobile_Point object, you now have bloat with little gain. It's far better to have a "Final" flag on your point, so it will toss an error when you try to change it vs. trying to maintain 2 separate classes. That way if you suddenly need to change your point you have to refractor less code. Granted, if Java's foreach would automatically make helper threads to speed things up then there would be an advantage. But, changing the form without compiler support is pointless. PS: Feel free to test your ideas, but allocating memory is still the enemy of speed. When you create a temporary object outside of the stack it really does slow things down.
      - KirinDave 17y ago
        I am glad to see someone else equally irritated by this "fashion statement" that people engaging in, abusing their languages to ape other languages. Even worse, most don't really understand the benefits of the languages they copy, they pull the iconic cases and then pretend that languages aren't a teepee of features that cannot stand when just a few poles are pulled in isolation.
        gdp 17y ago
        Huh? Are you suggesting that people use functional programming languages such as Haskell or ML because they are fashionable? Where on earth are you living such that they are fashionable? I wanna live there.
        KirinDave 17y ago
        Please reread what I said. The fashion statement is using a non-functional language and adopting some functional mores.