www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Some Java/C# design flaws

reply bearophile <bearophileHUGS lycos.com> writes:
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
parent reply Justin Johansson <no spam.com> writes:
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
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
parent reply Justin Johansson <no spam.com> writes:
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
parent reply "Nick Sabalausky" <a a.a> writes:
"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
parent reply Justin Johansson <no spam.com> writes:
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
parent "Nick Sabalausky" <a a.a> writes:
"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
prev sibling parent retard <re tard.com.invalid> writes:
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