## digitalmars.D - Some Java/C# design flaws

- bearophile (25/25) Feb 01 2010 A list of some Java flaws:
- Justin Johansson (9/18) Feb 01 2010 Hi bearophile,
- bearophile (23/25) Feb 01 2010 This is a binary tree preorder scan in Python, it contains "yield" that ...
- Justin Johansson (12/43) Feb 01 2010 Thanks for the heads up.
- retard (6/10) Feb 02 2010 Well they only taught us the iterative solution and mentioned that the
- Nick Sabalausky (6/16) Feb 02 2010 I'm reminded of the second half ("Inorder Walks of BSP Trees", pg 1107-1...
- Justin Johansson (2/21) Feb 02 2010 Ah, so it was you who dated Wendy Tucker when you were 14 :-)
- Nick Sabalausky (5/26) Feb 02 2010 Of all the absolutely great material in that book, the one thing in ther...

A list of some Java flaws: http://c2.com/cgi/wiki?JavaDesignFlaws To me among those ones the following three ones seem interesting for D: Every object is a monitor: http://c2.com/cgi/wiki?EveryObjectIsaMonitor nomonitor class Foo {} in D? If you don't use threads this saves a little memory and time. In LDC there's pragma(no_typeinfo) and in future pragma(no_moduleinfo) too. They can become notypeinfo. Java exceptions should be interfaces: http://c2.com/cgi/wiki?JavaExceptionsShouldBeInterfaces I don't fully understand the implications of this, but it seems interesting. Messy exception hierarchy: http://c2.com/cgi/wiki?MessyExceptionHierarchy ------------------ About some C# flaws: http://stackoverflow.com/questions/411906/c-net-design-flaws Among them the following ones looks interesting: 1. non-nullable reference types as a complement to nullable value types, 10. fix quadratic enumerable behaviour, 11. all collections should have immutable snapshots for iteration (ie. mutating the collection should not invalidate the iterator), 12. tuples are easy to add, but an efficient closed algebraic type like "Either" is not, so I'd love some way to declare a closed algebraic type and enforce exhaustive pattern matching on it (basically first-class support for the visitor pattern, but far more efficient); so just take enums, extend them with exhaustive pattern matching support, and don't allow invalid cases, 20. allow operators in interfaces, and make all core number types implement IArithmetic; other useful shared operator interfaces are possible as well, 22. simplify declaring constructors; I like F#'s approach, but the other post here that requires simply "new" instead of the class name is better at least, That point 10, "fix quadratic enumerable behaviour,", it's a problem present in Python too. Bye, bearophile

Feb 01 2010

bearophile wrote:About some C# flaws: http://stackoverflow.com/questions/411906/c-net-design-flaws 10. fix quadratic enumerable behaviour, That point 10, "fix quadratic enumerable behaviour,", it's a problem present in Python too. Bye, bearophileHi bearophile, I had a look at the link but there wasn't much more detail about item 10. Would you kindly explain what exactly is the "quadratic enumerable behaviour" problem. As it's only mentioned for C# in the link and for Python (by you), does Java get a merit point? Presumably it's about some O(n**2) issue. Thanks for your time, Justin Johansson

Feb 01 2010

Justin Johansson:Would you kindly explain what exactly is the "quadratic enumerable behaviour" problem.This is a binary tree preorder scan in Python, it contains "yield" that makes this a generator: def preorder(root): if root is not None: yield root if root.left is not None: for n in preorder(root.left): yield n if root.right is not None: for n in preorder(root.right): yield n Being it a generator you can give the root of the binary tree to it, and then you can iterate on all the nodes like this: for node in preorder(root): do_something(node) I am not 100% sure, but I think the problem comes from those for n in preorder(root.left): that turn a tree scan, that is O(n) in a O(n^2) algorithm. Some Python people have proposed an improvement to generators that as a side effect can lead to reducing that quadratic behaviour back to linear. The following is not the syntax they have proposed but it's more easy to understand. Instead of: for n in preorder(root.left): yield n Something that works as: yield *preorder(root.left) That is a yield that knows how to deal with more than one item, then the C machinery under Python has a chance to optimize things away. I think Lua doesn't share this Python problem. Bye, bearophile

Feb 01 2010

bearophile wrote:Justin Johansson:Thanks for the heads up. It sounds like, at least in this example, that the preorder algorithm be re-written in iterative fashion rather than recursive fashion as currently is. I suspect that would bring the generator behaviour back to O(n). Funny about this; virtually every CS101 course covers recursive binary tree node visitation but rarely is there a mention of the iterative solution. The iterative solution is much more tricky but for larger N, is almost a must for practical situations. Cheers JustinWould you kindly explain what exactly is the "quadratic enumerable behaviour" problem.This is a binary tree preorder scan in Python, it contains "yield" that makes this a generator: def preorder(root): if root is not None: yield root if root.left is not None: for n in preorder(root.left): yield n if root.right is not None: for n in preorder(root.right): yield n Being it a generator you can give the root of the binary tree to it, and then you can iterate on all the nodes like this: for node in preorder(root): do_something(node) I am not 100% sure, but I think the problem comes from those for n in preorder(root.left): that turn a tree scan, that is O(n) in a O(n^2) algorithm. Some Python people have proposed an improvement to generators that as a side effect can lead to reducing that quadratic behaviour back to linear. The following is not the syntax they have proposed but it's more easy to understand. Instead of: for n in preorder(root.left): yield n Something that works as: yield *preorder(root.left) That is a yield that knows how to deal with more than one item, then the C machinery under Python has a chance to optimize things away. I think Lua doesn't share this Python problem. Bye, bearophile

Feb 01 2010

Tue, 02 Feb 2010 08:16:38 +1030, Justin Johansson wrote:Funny about this; virtually every CS101 course covers recursive binary tree node visitation but rarely is there a mention of the iterative solution. The iterative solution is much more tricky but for larger N, is almost a must for practical situations.Well they only taught us the iterative solution and mentioned that the recursive version is kind of nice to know for theoretical reasons, but you never should use recursion in practice because it's so slow. I guess this is great because it makes learning functional programming much harder.

Feb 02 2010

"retard" <re tard.com.invalid> wrote in message news:hk9use$f4r$1 digitalmars.com...Tue, 02 Feb 2010 08:16:38 +1030, Justin Johansson wrote:I'm reminded of the second half ("Inorder Walks of BSP Trees", pg 1107-1113) of chapter 59 in Michael Abrash's "Graphics Programming Black Book"), and the story of his iterative-tree-walking interview test. ( http://nondot.org/~sabre/Mirrored/GraphicsProgrammingBlackBook/ )Funny about this; virtually every CS101 course covers recursive binary tree node visitation but rarely is there a mention of the iterative solution. The iterative solution is much more tricky but for larger N, is almost a must for practical situations.Well they only taught us the iterative solution and mentioned that the recursive version is kind of nice to know for theoretical reasons, but you never should use recursion in practice because it's so slow. I guess this is great because it makes learning functional programming much harder.

Feb 02 2010

Nick Sabalausky wrote:"retard" <re tard.com.invalid> wrote in message news:hk9use$f4r$1 digitalmars.com...Ah, so it was you who dated Wendy Tucker when you were 14 :-)Tue, 02 Feb 2010 08:16:38 +1030, Justin Johansson wrote:I'm reminded of the second half ("Inorder Walks of BSP Trees", pg 1107-1113) of chapter 59 in Michael Abrash's "Graphics Programming Black Book"), and the story of his iterative-tree-walking interview test. ( http://nondot.org/~sabre/Mirrored/GraphicsProgrammingBlackBook/ )Funny about this; virtually every CS101 course covers recursive binary tree node visitation but rarely is there a mention of the iterative solution. The iterative solution is much more tricky but for larger N, is almost a must for practical situations.Well they only taught us the iterative solution and mentioned that the recursive version is kind of nice to know for theoretical reasons, but you never should use recursion in practice because it's so slow. I guess this is great because it makes learning functional programming much harder.

Feb 02 2010

"Justin Johansson" <no spam.com> wrote in message news:hka1ln$tod$1 digitalmars.com...Nick Sabalausky wrote:Of all the absolutely great material in that book, the one thing in there I find myself thinking about more than anything else is: Has Wendy ever heard about that mention of her?"retard" <re tard.com.invalid> wrote in message news:hk9use$f4r$1 digitalmars.com...Ah, so it was you who dated Wendy Tucker when you were 14 :-)

Feb 02 2010