Re: dynamic vs. static: the age-old debate

Other than that, it does everything yours does

Yours doesn't statically check to the same degree
How can you be sure of this? What is your definition of "statically
check"?

and will be many times slower.
And many times more extensible.

and has the same length.

Yours is 18 LOC and incomplete, my OCaml is 14 LOC and my Mathematica is 11
LOC and also incomplete.
No, that was the more readable version. The compacted version would be
exactly the same length with the 3 lines added. If my language had let
rec support built in, then it would have exactly the same functionality
in your version, although I fail to see the need for such a construct
when generators are available.

but yours wasn't doing the same thing as mine.

Until you post code than actually works, you can't reasonably make such
claims.

How do you know it doesn't work?

Because it is known to be incomplete and is written in a language that
doesn't exist.
How is it possible to write something in a language that does not
exist? Doesn't the presence of such a program prove that said language
does, indeed exist? A compiler or interpreter might not be available,
but it's perfectly possible to "run" it by hand. After all, your brain
is turing complete.

It's clear enough to be verifiable by hand,

Except for the non-trivial bit that is missing, yes.
Which is only made trivial in your version because it happens to be
built in to the language. In fact, the only reason it's needed at all
is because you're practically rewriting the host language in itself--if
you were to write a python interpreter, for example, there would be
several non-trivial bits that you'd have to write from scratch.

even if it doesn't compile directly. In fact, I've even shown you
how to convert it to python so you _can_ run it.

If I translate it myself and work out how to "use generators", whatever kind
of depraved OO design pattern they are.
Generators are a concept from python, not OO. They're basically
functions which stream data back instead of returning it all at once,
e.g.:

def get_nums():
while True:
num = int(raw_input())
yield num

This basically returns an iterator which lets you iterate over the
users input in a lazy manner.

Why?

To attain the same level of flexibility present in my version you'd
have to either 1) pass around all functions which operate on the data
or 2) pass around a struct or its equivalent.

That is what you believe I would have to do. I believe you are wrong.

Can you challenge me with some way that you want to extend the functionality
of this program that you believe will be easier to add using OOP? Then we
can both have a go and compare the results objectively.
Of course. Let's say I want to add a 'print' function and a new type of
expression. (it doesn't matter what kind--take your pick :)

The first one is still
rather inflexible in that you have to update all function definitions
every time you add a function,

Not if you use a functor, for example.
Perhaps, but you still have to pass them around at the callsite, don't
you?

This is academic anyway, I can see no reason to "pass around all
functions..." unless I want a higher-order function.
Or if you want to leave the door open to extension later on without
having to rewrite a large portion of code.

Hehe. Humor me, how is it less extensible in "many useful ways"?

The ones I already enumerated twice:

parallel pattern matching
variable binding
structure matching
or-patterns
guarded patterns
static checking
algorithmic matching
...

I doubt any of those are particularly verbose when implemented using
classes.

Here is another counter example:

The following Mathematica code implements polynomial integration using only
Mathematica's pattern matcher and the FreeQ[e, f] function (which checks
that the pattern "f" does not match any subexpression of "e"):

integrate[y_ + z_, x_] := integrate[y, x] + integrate[z, x]
integrate[c_ y_, x_] := c integrate[y, x] /; FreeQ[c, x]
integrate[c_, x_] := c x /; FreeQ[c, x]
integrate[x_^n_., x_] := x^(n + 1)/(n + 1) /; FreeQ[n, x] && n != -1

For example:

integrate[3 a x^2 + 2 b x + c, x]
=> c x + b x^2 + a x^3

Just doing that exploits tremendous sophistication in the pattern matcher,
far beyond the capability of OOP.
I have no idea what that does. Could you possibly describe the
algorithm in a bit more detail?

Given that this is more complicated and more error prone than the previous
example, it is essential that the translation can be executed.
I'll put up a python version once I figure out what it does, which
should be useful to show that the version in my language is correct. I
doubt I'll have to use any facilities not present in python, so mine
should be almost identical except less verbose.

.

Relevant Pages

  • Re: Does Python really follow its philosophy of "Readability counts"?
    ... with enforcing that "shouldn't" in the language itself? ... In Python, direct access to pointers is a MUST NOT. ... where you are allowed to mess with the implementation. ... human assembly language programmers? ...
    (comp.lang.python)
  • Re: A request for information please.
    ... Could language explain our intelligence? ... with instincts! ... not possible without possessing consciousness or a mind. ... But Pi is not considered random even though it has no pattern because ...
    (comp.ai.philosophy)
  • Re: Python for Fortran programmers
    ... proposition for Python in the Fortran community", ... compiled language such as Fortran or C++, but I would still prefer to ... greater number of programming errors that are typically detected by a ...
    (comp.lang.fortran)
  • Re: Basic inheritance question
    ... used 'this' in C++ and Java. ... but in Python it doesn't. ... language, they would write a lot of ten liners that is changed a LOT ... Add three levels of inheritence and a couple globals and you'll find out ...
    (comp.lang.python)
  • Re: About alternatives to Matlab
    ... Python will almost certainly be notably slower than moderately ... the powerful and flexible Python language. ... particularly that an OCaml user can easily switch back and forth ... The knowledge is there for the compiler to use but I don't believe any of ...
    (comp.lang.python)