digitalmars.D - Some Java/C# design flaws
- bearophile <bearophileHUGS lycos.com> Feb 01 2010
- Justin Johansson <no spam.com> Feb 01 2010
- bearophile <bearophileHUGS lycos.com> Feb 01 2010
- Justin Johansson <no spam.com> Feb 01 2010
- "Nick Sabalausky" <a a.a> Feb 02 2010
- Justin Johansson <no spam.com> Feb 02 2010
- "Nick Sabalausky" <a a.a> Feb 02 2010
- retard <re tard.com.invalid> Feb 02 2010
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, bearophile
Hi 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: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
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 Justin
Feb 01 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: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.
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/ )
Feb 02 2010
Nick Sabalausky wrote:"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: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.
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.
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/ )
Ah, so it was you who dated Wendy Tucker when you were 14 :-)
Feb 02 2010
"Nick Sabalausky" <a a.a> "Justin Johansson" <no spam.com> wrote in message news:hka1ln$tod$1 digitalmars.com...Nick Sabalausky wrote:"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: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.
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.
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/ )
Ah, so it was you who dated Wendy Tucker when you were 14 :-)
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?
Feb 02 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