3 ms·

> 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

by gdp 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 I don't understand what this means. > If you start dealing with a Fixed_Point objects, and Mobile_Point object, you now have bloat with little gain Why would you not have a single point class implementing multiple interfaces? Surely if they do the same thing, you wouldn't bother. Good design would dictate that if they do similar things (but not the same), they should probably share an abstract parent class anyway. > It's far better to have a "Final" flag on your point, so it will toss an error when you try to change it And check this at runtime for every access!?! Why on earth would that be more efficient than static checking at compile time?

Retric 17y ago
I don't understand what this means. EX: Tail recursion (http://en.wikipedia.org/wiki/Tail_recursion http://en.wikipedia.org/wiki/Tail_recursion) will be optimization if your code is a specific form AND your compiler also supports transforming to into loop. However, if you use the form without compiler support you are killing the stack and should manually convert your code to a loop by hand. Edit: Tail recursion really is just another loop; it's often used as a backhanded way to have mutable variables in a functional language, but in Java you might as well just have a loop. And check this at runtime for every access!?! Why on earth would that be more efficient than static checking at compile time? You only need to check it when you are updating a member variable not when you read it. Note: it does not save you from updating the variables inside the class if you bypass the getters and setters, but that’s a side issue. Anyway, if you check it ~50 times vs. creating one extra object you should come out ahead in speed. More importantly you will have far less and more maintainable code. PS: Using multiple interfaces to the same class is a reasonable option, with some tradeoffs. You still need to maintain more code, but it is pure fluff so not that big a deal. However, that's not what he did.
- gdp 17y ago
  Do you have any figures to back up the claim that memory allocation for small, short-lived objects consisting of final members is actually as slow as you claim? My understanding is that it isn't.
  - Retric 17y ago
    That's not a simple question. A name with string first, string last takes longer to create than a point with int x, int y. Temporary fixed size objects can be created and destroyed with little overhead. But you need to profile things to get a good metric. http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf http://java.sun.com/j2se/reference/whitepapers/memorymanagem... Has some of the details. Creating an object that lives on the processor cache can take 150 cycles which is FAST. But, the more complex the object the longer the allocation, and you can quickly start to fragment your memory if you have several short lived objects that don't die at the same time. Assuming your checking a variable in L1 cache then it's still an order of magnitude faster, but once you start taking longer to load the object into cache etc so it's not really a stable time either... PS: It's going to get really application specific so I can't think of realistic test outside of an actual application. Still I will try some simple cases tomorrow.

by gdp 17y ago

Retric 17y ago

I don't understand what this means. EX: Tail recursion (http://en.wikipedia.org/wiki/Tail_recursion http://en.wikipedia.org/wiki/Tail_recursion) will be optimization if your code is a specific form AND your compiler also supports transforming to into loop. However, if you use the form without compiler support you are killing the stack and should manually convert your code to a loop by hand. Edit: Tail recursion really is just another loop; it's often used as a backhanded way to have mutable variables in a functional language, but in Java you might as well just have a loop. And check this at runtime for every access!?! Why on earth would that be more efficient than static checking at compile time? You only need to check it when you are updating a member variable not when you read it. Note: it does not save you from updating the variables inside the class if you bypass the getters and setters, but that’s a side issue. Anyway, if you check it ~50 times vs. creating one extra object you should come out ahead in speed. More importantly you will have far less and more maintainable code. PS: Using multiple interfaces to the same class is a reasonable option, with some tradeoffs. You still need to maintain more code, but it is pure fluff so not that big a deal. However, that's not what he did.

gdp 17y ago
Do you have any figures to back up the claim that memory allocation for small, short-lived objects consisting of final members is actually as slow as you claim? My understanding is that it isn't.
- Retric 17y ago
  That's not a simple question. A name with string first, string last takes longer to create than a point with int x, int y. Temporary fixed size objects can be created and destroyed with little overhead. But you need to profile things to get a good metric. http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf http://java.sun.com/j2se/reference/whitepapers/memorymanagem... Has some of the details. Creating an object that lives on the processor cache can take 150 cycles which is FAST. But, the more complex the object the longer the allocation, and you can quickly start to fragment your memory if you have several short lived objects that don't die at the same time. Assuming your checking a variable in L1 cache then it's still an order of magnitude faster, but once you start taking longer to load the object into cache etc so it's not really a stable time either... PS: It's going to get really application specific so I can't think of realistic test outside of an actual application. Still I will try some simple cases tomorrow.