[Edu-sig] Quadrays again... cross-training in two langauges

[kirby urner]

On Mon, Aug 10, 2015 at 2:03 PM, Mark Engelberg <mark.engelberg at gmail.com>
wrote:


>
> For performance reasons, clojure.core/+ isn't something you can directly
> overload.  However, you can replace it in your own namespace with a `+`
> that has a more complex polymorphic dispatch process and then do whatever
> you want.  For a real-world example of overloading + in this manner to work
> on vectors and matrices, see:
> https://github.com/mikera/core.matrix
>
>
>

But I can't do this, right?

(defprotocol VectorOps
  (+ [this other])
  (- [this other])
  (len [this])
  (neg [this])
  (norm [this]))

I get:

WARNING: + already refers to: #'clojure.core/+ in namespace: qrays.qrays,
being replaced by: #'qrays.qrays/+

I see from the core.matrix docs that it *can* be done, so obviously I'm
just not seeing *how* it's done yet.  The books I've looked at don't seem
to make operator overloading a priority as much as Python books do.



>
>> I think the basics of Polymorphism may be communicated without
>> introducing the wrinkle of not having original source code.  Not wanting to
>> change it might be easier for a math student to understand.
>>
>> Not having the original source code sounds like a social problem, an
>> institutional issue, vs. a truly theoretical issue, and that's confusing to
>> newbies.
>>
>
> I see it as a more fundamental theoretical issue, and relevant to students
> in the sense that one of the higher aims of software engineering is to
> figure out how to deliver reusable pieces of code.  Even if all the code in
> the world were publicly available on Github, it would be folly to teach
> that reuse involves forking and editing code.  The expression problem is
> one meaningful measure of whether your programming language forces you to
> do that, when what you really want to do is build off of some component in
> a way that doesn't involve editing the original.  This is a sufficiently
> important principle that we need to take care on how we teach it to
> students in programming languages that don't have robust support for both
> axes of function and datatype extensibility.
>

I understand it put that way.

We do not want to redo so much as reuse the old code, on which others
depend.  It's like wanting to use machines that are already built.

Just copying an algorithm over and over, and having innumerable versions,
is in no way elegant -- but is what we have, many wheels reinvented.

Subclassing was a way OO addressed the issue but without solving it.

My understanding is Ruby allows us to keep adding to class definitions.  If
you wanna add a new method later, just open the class again.

More homework:
http://bit.ly/1PhdGyZ
http://web.engr.oregonstate.edu/~walkiner/teaching/cs609-su14/expression-problem.html

Thanks for the interesting discussion.


Kirby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20150810/18c33454/attachment.html>