Re: OO's best feature survey results

From: Topmind (topmind_at_technologist.com)
Date: 10/30/03 

Date: 30 Oct 2003 14:38:46 -0800

> > >
> > > > I will agree that people tend to think in "types"
> > >
> > > Types are an essential concept in modern programming.
> >
> > I don't agree with that. I could easily live with a programming
> > language where everything is a string
>
> You always need the boolean type.
>
> if a = '1' then
> ...

That could simply be a short-cut for:

if isEqual(a, '1') then ....

In fact, I often make routines like that in web
programming to strip away leading and trailing
white spaces and make it ignore capitalization
for the compare. To the interpreter, it is only
a function call. It may have no concept of
"Boolean" built in.

>
> a = '1' returns a boolean value.
>
> How would you solve this?

It returns whatever the heck isEqual() wants to
return. To the interpreter, it is a function that
takes strings as a parameter and returns
strings. It is blind to human purpose or
intention.

>
> > many scripting/dynamic languages actually do. An "add" operation
> > will "convert", or at least treat the operands as if
> > they were numbers during the operation.
>
> With that kind of variables you usually can check the type of the
> stored value, and the interpreter checks the types before doing the
> operations. Eg
>
> a := '0';
> b := '#@#@';
>
> c := a + b; // invalid conversion error

Again, assume that "+" is just a shortcut for an
Add() function. For the sake of argument, assume
that Add is not a built-in function.

c = add(a, b)

>
> This language is still typed, but I would like to detect the error in
> compilation time.

What Add() or isEqual() does is up to the implementor(s).

>
> > "Type"
> > is something very temporial in this approach.
>
> No, types are immutable and eternal, but variables may hold values of
> many types.

Didn't Universe just say that types are, or are often situational?
You two should get on the same page, or perhaps agree that
"type" is a psychological viewpoint and not a universal
truth.

>
> > You call them "numbers" during the operation, but
> > they are just strings and the result is just string.
>
> String is the representation, buy they behave like numbers and they
> are numbers.

Declared by the human, not by the interpreter. Again,
the interpreter is blind to human intent. It only processes
strings as the programmer tells it. And, one can write
their own Add() function using just strings. (It may not
be the most efficient approach CPU-wise, but that is
an internal implementation issue.)

>
> How do you solve this?
>
> if '10' > '9' then ...

See above.

>
> > They are a part of a lot of programming languages, but not
> > a necessity.
>
> And programming languages are not a necessity either, but they make
> our lifes more comfortable.

"Types" are too artificial IMO for many things, perhaps most.

>
> > Besides, typing working on a small scale does not necessarily
> > translate to a larger scale. Extrapolating "integer" ADT
> > type concepts to business entities is a big leap.
>
> Business entities map very well to relation typed variables (AKA
> tables).

I don't know that entity == type. If so, why have a separate
term "entity"?

>
> Without types the relational model can not exist.

I disagree. True, the "Oracle way" and its clones may involve typed
columns, but I don't see anywhere where relational theory
demands types anymore than a procedural language does.

>
> I agree with you about that biz entities map very bad to scalar typed
> variables.
>
> > > Types are constant. This is not a type, it is a derived variable.
> >
> > Constant?
>
> Of course. The integer type is the same always.
>
> > Does that mean that dynamical languages don't
> > really have types?
>
> If you change a "type" what you have is another type.
>
> Eg:
>
> type A is integer constraint A > 0 and A < 100;
> drop type A;
> type A is integer constraint A > 0 and A < 10;
>
> You call A to two different types.

Why not call them constraints instead of types?
Constraints can be mixed and matched also so that
they do not always form a clean tree. In otherwords,
a "set of constraints".

This is turning into a definition issue. I don't question
that everything can be viewed as types IF one wants to,
as described in a reply to Universe. (I had a typo there
where I said "is-a-type" instead of "is-a-table", BTW.)
It is the utility of such that I question.

>
>
> Alfredo

-T-

Relevant Pages

  • Re: Two Questions about "strlen", "strcat" and "strcpy"
    ... > length delimited strings in C. ... > Important is that we have in the standard language a way of using ... programming languages deal with strings (like Python, Perl, Java, ...
    (comp.lang.c)
  • Re: Pondering My Next Programming Frontier
    ... >I thought my next programming frontier would be Visual BASIC ... > people to download Microsoft's 21-meg dot net framework. ... compiled language that lets you build GUIs just as easily as VB. ... so an interpreter would ...
    (microsoft.public.vb.general.discussion)
  • Re: How could they complain about lisp-scheme syntax
    ... language is usable as a scripting language at some level, ... more tailored to scripting than others. ... First, it's clear, that writing scripts is similar to programming. ... Taking that back to Pascal's previous definition, it becomes clear why Bash-Syntax is the way it is: Bash-language is a language focusing on calling programs, doing some minor processing and redirecting to other programs, all done with strings as strings are the common Unix data type. ...
    (comp.lang.lisp)
  • Re: Why C is really a bad programming language
    ... Most of my programs are in gcode. ... The only place you can use strings ... between), hate language. ... Nearly 100% of what I do (programming ...
    (comp.lang.c)
  • Re: Strings or Symbols?
    ... Common Lisp has built-in hash-tables which you can ... use for looking up strings. ... Nowadays symbols are often used as elements in the programming ... Natural Language Processing: ...
    (comp.lang.lisp)