LangWart: Method congestion from mutate multiplicty
dreamingforward at gmail.com
Sun Feb 10 23:01:45 CET 2013
On Sun, Feb 10, 2013 at 1:51 PM, Chris Angelico <rosuav at gmail.com> wrote:
> On Mon, Feb 11, 2013 at 8:28 AM, Mark Janssen <dreamingforward at gmail.com> wrote:
>> Yes, I was aware of his sarcasm. But I was actually wanting to agree
>> with the fundamental idea: that one could reduce all data types to 1
>> atomic unit and 1 grouping construct, and like set theory in
>> mathematics, derive everything else.
> There are many things that work fine in theory, but aren't practical.
> You could theoretically rewrite any Python program in Ook (or its
> non-G-rated cousin), but that doesn't mean that Ook's data model is
> worth working with.
Ah, but you're conflating a *data model* (which is already composed of
simple theoretical elements (like 1/0)) and a *programming language*,
which is composed of either an implicit or explicit data model
(usually the former) AND a set of transforms that operate on it.
IOW, I'm wanting to take something that is usually just inherited and
historical (and thereby taken for granted), and make it something to
look at. Traditional Data Structures in CompSci goes somewhat towards
this end, but doesn't quite take the idea to its ultimate, and that's
what I'm proposing with a unified data model.
More information about the Python-list