Re: OO's best feature survey results

From: Alfredo Novoa (alfredo_at_ncs.es)
Date: 11/02/03 

Date: 2 Nov 2003 03:58:52 -0800

topmind@technologist.com (Topmind) wrote in message news:<4e705869.0311010059.2c7b4408@posting.google.com>...

> "I will
> make IF proceed if the values (strings) are
> such and such and not proceed otherwise
> (jump over)."

Agreed, it is like assembler works.

> > I don't know anybody except you that would like to use a language like
> > that.
>
> I LIKE dynamic languages.

Dynamic languages can be typed, and should be typed.

> > Type is a math concept. Types are independent to time.
>
> So you have a mathematical test that could take say
> a set of classes from any OO language and tell if
> they are or share the same type?

Class and type are the same when class is used in the context of an OO
language.

> > You can't know if I want to make a string or a numerical comparisson.
>
> I prefer languages that have a different operator for numerical
> comparison than for string comparison. Perl is an example of
> such (although I would do it syntactically different
> if given a choice).

More limitations without any gain. It is a lot more readable to have
unique comparison operators and you have less operators to remember.

BTW numerical is a type and string is another type. You are using
types all the time.

> > There is nothing wrong in being artificial.
>
> To a point. I don't find the philosophy of types
> very useful. They don't map to my head, and you seem
> to agree that they don't map to the real world
> that well.

They map perfectly to the real world. We use the concept of type every
day. It is a fundamental concept hardcoded in our brains.

> > entity == type is a great blunder. But it is a very common blunder in
> > the OO world.
> >
> > BTW type is a formal term while entity is not.
>
> I am skeptical of this claim.

Which claim?

> > Relational theory demands at least boolean types, tuple types and
> > relation types.
>
> I think you are overusing "type". Boolean is an interface,
> not a type.

Boolean is a type. I think you don't know what a type is.

Interface is not as formal term.

BTW I should say the boolean type.

> Tables can be represented many different ways.
> Convert them to XML if you want to see strings.

The set of all possible tables is a type. Your table based language
needs the table type.

> > The type concept is precise. In a programming language a type can be
> > viewed as a set of values and a set of operators that act over that
> > values.
>
> Sounds more like set theory than "type". This differs too much
> from the "street meaning" of types.

Types can be viewed as sets, then set theory apply.

I am curious about what a type is for you. You seem to have many
problems with the concept.

The street is not a good source for technical concepts, you should
read some computer science books (I don't mean OO books of course).

Alfredo

Relevant Pages

  • Re: Common Lisp from a Unix perspective - barriers to using CL
    ... This is quite a strange situation: some important facilities ... that Common Lisp does *not* include built-in, ... Most modern programming languages ... Because the world nowadays uses strings, ...
    (comp.lang.lisp)
  • Re: Windows vs. Linux
    ... Rather than thinking in bytes and the like when inserting an EOL marker, ... level languages like Python... ... Or forget to use raw strings. ... backslash escape character story is not quite well-chosen. ...
    (comp.lang.python)
  • Re: An argument against modus ponens
    ... languages do not have access to local weather forecasts. ... But they DO have truth-values, ... when you PRESUME that the truth of some sentence could somehow be ... These strings OCCUR IN A CONTEXT ...
    (sci.logic)
  • Re: How come Ada isnt more popular?
    ... only or get the comfort of unbounded strings. ... It's easier to do simple things with languages that have lists in ... family (including Ada). ...
    (comp.lang.ada)
  • Re: Problem of function calls from map()
    ... 'lines' is a large list of strings each of which is seperated by '\t' ... usually easier to understand as a single gestalt (i.e., ... performance in Python (and other languages, too, but perhaps easier to ... map() isn't much of a win in this case. ...
    (comp.lang.python)