• 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

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

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

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

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

"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/ ) 

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 :-)

"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?

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.