Am 08.11.2014 um 09:31 schrieb Richard Fateman:
Yes, but you can't even name any design flaws.
You can read my published reviews of macsyma and mathematica.
That does not help naming design flaws in SymPy. We'd be unable to check
whether any criticism even applied - Python is quite different from most
languages, so it leads to rather different design decisions from the outset.
Plus, your advice essentially amounted to "redo it in Lisp".
I'm not sure I said that
Implicitly, by harping on its advantages whenever some design issue
popped up.
I have noticed you have stopped doing so. Or maybe it's statistical
outliers, I don't have the time to read every thread.
> -- but if you are rewriting a program
it i s a good opportunity to look at the old
one,
Yeah, but a rewrite isn't really a viable option at any time.
Particularly not a rewrite in a different language. The barriers are
simply too high.
(I'm also quite sceptical about Lisp, because it's all power to the
developer and no guarantees to the maintainer, and I do not think that's
a viable option in the long term unless you can guarantee that every
coder on the project is top-notch, but that's just a tangent).
I don't follow. If you think Lisp is a "write-only" language and can't be
read by maintainers,
Well, sort of. Essentially, you can never know whether a call is really
going to the code that it says; there could always be a macro or even
some homegrown redirect in place, and you have no chance to detect it by
looking at the call site and at the callee. Essentially, you need to
know in what way the standard call semantics have been changed.
This is very, very powerful for writing new code, but each use of such a
mechanism means that any maintainers need to be aware of all mechanisms
in use, and they can't even be sure that the texts that document what
mechanisms are in use are really up-to-date and correct.
Such things make it also infeasible to do any kind of static automatic
checking.
Which is somewhat unfortunate I'd say. You often want to be 100% sure
that specific things work the way you think they work.
For example, I'm currently working on an import sanitizing tool for
SymPy. I can't do any static checking; I have to run an "import sympy"
and trace what it's actually doing, and I'll still miss all the imports
that do not run during "import sympy". So there's no way to make 100%
sure that SymPy does not have any circular imports, for example; I can't
do more than make it somewhat unlikely. And import order is just a very
basic correctness issue in Python programming.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/545E65D6.1060104%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
