What are OOP's Jargons and Complexities?

Discussion in 'Perl Misc' started by Xah Lee, May 23, 2005.

  1. Xah Lee

    Xah Lee Guest

    What are OOP's Jargons and Complexities
    Xah Lee, 20050128

    The Rise of Classes, Methods, Objects

    In computer languages, often a function definition looks like this:
    subroutine f (x1, x2, ...) {
    variables ...
    do this or that
    }

    In advanced languages such as LISP family, it is not uncommon to define
    functions inside a function. For example:
    subroutine f (x1, x2, ...) {
    variables...
    subroutine f1 (x1...) {...}
    subroutine f2 (x1...) {...}
    }

    Often these f1 f2 inner functions are used inside f, and are not
    relevant outside of f. Such power of the language gradually developed
    into a style of programing. For example:
    subroutine a_surface () {
    coordinatesList = ...;
    subroutine translate (distance) {...}
    subroutine rotate (angle) {..}
    }

    Such a style is that the a_surface is no longer viewed as a function.
    But instead, a boxed set of functions, centered around a piece of data.
    And, all functions for manipulating this piece of data are all embodied
    in this function. For example:
    subroutine a_surface (arg) {
    coordinatesList = ...
    subroutine translate (distance) {set coordinatesList to translated
    version}
    subroutine rotate (angle) {set coordinatesList to rotated version}
    subroutine return () {return coordinatesList}

    if (no arg) {return coordinatesList}
    else { apply arg to coordinatesList }
    }

    In this way, one uses a_surface as a data, which comes with its owe set
    of functions:
    mySurface = a_surface();
    mySurface(rotate(angle)); // now the surface data has been
    rotated
    mySurface(translate(distance)); // now its translated
    newSurface = mySurface(return())

    So now, a_surface is no longer viewed as a subroutine, but a boxed set
    of things centered around a piece of data. All functions that work on
    the data are included in the boxed set. This paradigm possible in
    functional languages has refined so much so that it spread to other
    groups and became known as Object Oriented Programing, and complete
    languages with new syntax catered to such scheme emerged.

    In such languages, instead of writing them like this:
    mySurface = a_surface();
    mySurface(rotate(angle));

    the syntax is changed to like this, for example:
    mySurface = new a_surface();
    mySurfaceRotated = mySurface.rotate(angle);

    In such languages, the super subroutine a_surface is no longer called a
    function or subroutine. It is now called a “Classâ€. And nowthe
    variable holding the function "mySurface = a_surface()" is now called a
    “Objectâ€. Subroutines inside the function a_surface() are no longer
    called inner-subroutines. They are called “Methodsâ€. The act of
    assigning a super-subroutine to a variable is called instantiation.

    This style of programing and language have become so fanatical that in
    such dedicated languages like Java, everything in the language are
    “Classesâ€. One can no longer just define a variable or subroutine.
    Instead, one creates these meta-subroutine “Classesâ€. Everything
    one do are inside Classes. And one assign Classes inside these Classes
    to create “Objectsâ€. And one uses “Methodsâ€to manipulate
    Objects. In this fashion, even basic primitives like numbers, strings,
    and lists are no longer atomic entities. They are now Classes.

    For example, in Java, a string is a class String. And inside the class
    String, there are Methods to manipulate strings, such as finding the
    number of chars, or extracting parts of the string. This can get very
    complicated. For example, in Java, there are actually two Classes of
    strings: One is String, and the other is StringBuffer. Which one to use
    depends on whether you intend to change the data.

    So, a simple code like this in normal languages:
    a = "a string";
    b = "another one";
    c = join(a,b);
    print c;

    or in lisp style
    (set a "a string")
    (set b "another one")
    (set c (join a b))
    (print c)

    becomes in pure OOP languages:
    public class test {
    public static void main(String[] args) {
    String a = new String("a string");
    String b = new String("another one");
    StringBuffer c = new StringBuffer(40);
    c.append(a); c.append(b);
    System.out.println(c.toString());
    }
    }

    Here, the "new String" creates a String object. The "new
    StringBuffer(40)" creates the changeable string object StringBuffer,
    with room for 40 chars. "append" is a method of StringBuffer. It is
    used to join two Strings.

    Notice the syntax "c.append(a)", which we can view it as calling a
    inner subroutine "append", on a super subroutine that has been assigned
    to c, where, the inner subroutine modifies the inner data by appending
    a to it.

    And in the above Java example, StringBuffer class has another method
    "toString()" used to convert this into a String Class, necessary
    because System.out.println's parameter requires a String type, not
    StringBuffer.

    For a example of the complexity of classes and methods, see the Java
    documentation for the StringBuffer class at
    http://java.sun.com/j2se/1.4.2/docs/api/java/lang/StringBuffer.html
    (local copy)

    In the same way, numbers in Java have become a formalization of many
    classes: Double, Float, Integer, Long... and each has a bunch of
    "methods" to operate or convert from one to the other.

    Instead of
    aNumber = 3;
    print aNumber^3;

    In Java the programer needs to master the ins and outs of the several
    number classes, and decide which one to use. (and if a program later
    needs to change from one type of number to another, it is often
    cumbersome.)

    This Object Oriented Programing style and dedicated languages (such as
    C++, Java) have become a fad like wild fire among the programing mass
    of ignoramuses in the industry. Partly because of the data-centric new
    perspective, partly because the novelty and mysticism of new syntax and
    jargonization.

    It is especially hyped by the opportunist Sun Microsystems with the
    inception of Java, internet, and web applications booms around 1995. At
    those times, OOP (and Java) were thought to revolutionize the industry
    and solve all software engineering problems, in particular by certain
    "reuse of components" concept that was thought to come with OOP.

    As part of this new syntax and purity, where everything in a program is
    of Classes and Objects and Methods, many complex issues and concept
    have arisen in OOP.

    We now know that the jargon Class is originally and effectively just a
    boxed set of data and subroutines, all defined inside a subroutine. And
    the jargon "Object" is just a variable that has been set to this super
    subroutine. And the inner subroutines are what's called Methods.

    ----------
    to be continued tomorrow.

    This is part of an installment of the article
    “What are OOP's Jargons and Complexitiesâ€
    by Xah Lee, 20050128. The full text is at
    http://xahlee.org/Periodic_dosage_dir/t2/oop.html

    © Copyright 2005 by Xah Lee. Verbatim duplication of the complete
    article for non-profit purposes is granted.

    The article is published in the following newsgroups:
    comp.lang.c,comp.lang.c++,comp.lang.lisp,comp.unix.programmer
    comp.lang.python,comp.lang.perl.misc,comp.lang.scheme,comp.lang.java.programmer
    comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns

    Xah

    ∑ http://xahlee.org/
     
    Xah Lee, May 23, 2005
    #1
    1. Advertising

  2. Xah Lee

    Wibble Guest

    You're point being...?

    I'm an old lisp hacker too, and lisp developed
    objects too, because they're cool and useful (Flavors & CLOS).

    Java has inner classes also, and nobody misses FLET & LABELS.

    Limiting responsiblity and enhanced type safety, as well as
    improved readablity are a win hands down over the bad old
    days.

    Lisp is not a more advanced language than Java. Its 30+
    years older and shows it in alot places. Lisp has some
    things I wish were in Java but the corralary holds true.

    Object orient programming in Lisp is nice too.

    Xah Lee wrote:
    > What are OOP's Jargons and Complexities
    > Xah Lee, 20050128
    >
    > The Rise of Classes, Methods, Objects
    >
    > In computer languages, often a function definition looks like this:
    > subroutine f (x1, x2, ...) {
    > variables ...
    > do this or that
    > }
    >
    > In advanced languages such as LISP family, it is not uncommon to define
    > functions inside a function. For example:
    > subroutine f (x1, x2, ...) {
    > variables...
    > subroutine f1 (x1...) {...}
    > subroutine f2 (x1...) {...}
    > }
    >
    > Often these f1 f2 inner functions are used inside f, and are not
    > relevant outside of f. Such power of the language gradually developed
    > into a style of programing. For example:
    > subroutine a_surface () {
    > coordinatesList = ...;
    > subroutine translate (distance) {...}
    > subroutine rotate (angle) {..}
    > }
    >
    > Such a style is that the a_surface is no longer viewed as a function.
    > But instead, a boxed set of functions, centered around a piece of data.
    > And, all functions for manipulating this piece of data are all embodied
    > in this function. For example:
    > subroutine a_surface (arg) {
    > coordinatesList = ...
    > subroutine translate (distance) {set coordinatesList to translated
    > version}
    > subroutine rotate (angle) {set coordinatesList to rotated version}
    > subroutine return () {return coordinatesList}
    >
    > if (no arg) {return coordinatesList}
    > else { apply arg to coordinatesList }
    > }
    >
    > In this way, one uses a_surface as a data, which comes with its owe set
    > of functions:
    > mySurface = a_surface();
    > mySurface(rotate(angle)); // now the surface data has been
    > rotated
    > mySurface(translate(distance)); // now its translated
    > newSurface = mySurface(return())
    >
    > So now, a_surface is no longer viewed as a subroutine, but a boxed set
    > of things centered around a piece of data. All functions that work on
    > the data are included in the boxed set. This paradigm possible in
    > functional languages has refined so much so that it spread to other
    > groups and became known as Object Oriented Programing, and complete
    > languages with new syntax catered to such scheme emerged.
    >
    > In such languages, instead of writing them like this:
    > mySurface = a_surface();
    > mySurface(rotate(angle));
    >
    > the syntax is changed to like this, for example:
    > mySurface = new a_surface();
    > mySurfaceRotated = mySurface.rotate(angle);
    >
    > In such languages, the super subroutine a_surface is no longer called a
    > function or subroutine. It is now called a “Classâ€. And now the
    > variable holding the function "mySurface = a_surface()" is now called a
    > “Objectâ€. Subroutines inside the function a_surface() are no longer
    > called inner-subroutines. They are called “Methodsâ€. The act of
    > assigning a super-subroutine to a variable is called instantiation.
    >
    > This style of programing and language have become so fanatical that in
    > such dedicated languages like Java, everything in the language are
    > “Classesâ€. One can no longer just define a variable or subroutine.
    > Instead, one creates these meta-subroutine “Classesâ€. Everything
    > one do are inside Classes. And one assign Classes inside these Classes
    > to create “Objectsâ€. And one uses “Methods†to manipulate
    > Objects. In this fashion, even basic primitives like numbers, strings,
    > and lists are no longer atomic entities. They are now Classes.
    >
    > For example, in Java, a string is a class String. And inside the class
    > String, there are Methods to manipulate strings, such as finding the
    > number of chars, or extracting parts of the string. This can get very
    > complicated. For example, in Java, there are actually two Classes of
    > strings: One is String, and the other is StringBuffer. Which one to use
    > depends on whether you intend to change the data.
    >
    > So, a simple code like this in normal languages:
    > a = "a string";
    > b = "another one";
    > c = join(a,b);
    > print c;
    >
    > or in lisp style
    > (set a "a string")
    > (set b "another one")
    > (set c (join a b))
    > (print c)
    >
    > becomes in pure OOP languages:
    > public class test {
    > public static void main(String[] args) {
    > String a = new String("a string");
    > String b = new String("another one");
    > StringBuffer c = new StringBuffer(40);
    > c.append(a); c.append(b);
    > System.out.println(c.toString());
    > }
    > }
    >
    > Here, the "new String" creates a String object. The "new
    > StringBuffer(40)" creates the changeable string object StringBuffer,
    > with room for 40 chars. "append" is a method of StringBuffer. It is
    > used to join two Strings.
    >
    > Notice the syntax "c.append(a)", which we can view it as calling a
    > inner subroutine "append", on a super subroutine that has been assigned
    > to c, where, the inner subroutine modifies the inner data by appending
    > a to it.
    >
    > And in the above Java example, StringBuffer class has another method
    > "toString()" used to convert this into a String Class, necessary
    > because System.out.println's parameter requires a String type, not
    > StringBuffer.
    >
    > For a example of the complexity of classes and methods, see the Java
    > documentation for the StringBuffer class at
    > http://java.sun.com/j2se/1.4.2/docs/api/java/lang/StringBuffer.html
    > (local copy)
    >
    > In the same way, numbers in Java have become a formalization of many
    > classes: Double, Float, Integer, Long... and each has a bunch of
    > "methods" to operate or convert from one to the other.
    >
    > Instead of
    > aNumber = 3;
    > print aNumber^3;
    >
    > In Java the programer needs to master the ins and outs of the several
    > number classes, and decide which one to use. (and if a program later
    > needs to change from one type of number to another, it is often
    > cumbersome.)
    >
    > This Object Oriented Programing style and dedicated languages (such as
    > C++, Java) have become a fad like wild fire among the programing mass
    > of ignoramuses in the industry. Partly because of the data-centric new
    > perspective, partly because the novelty and mysticism of new syntax and
    > jargonization.
    >
    > It is especially hyped by the opportunist Sun Microsystems with the
    > inception of Java, internet, and web applications booms around 1995. At
    > those times, OOP (and Java) were thought to revolutionize the industry
    > and solve all software engineering problems, in particular by certain
    > "reuse of components" concept that was thought to come with OOP.
    >
    > As part of this new syntax and purity, where everything in a program is
    > of Classes and Objects and Methods, many complex issues and concept
    > have arisen in OOP.
    >
    > We now know that the jargon Class is originally and effectively just a
    > boxed set of data and subroutines, all defined inside a subroutine. And
    > the jargon "Object" is just a variable that has been set to this super
    > subroutine. And the inner subroutines are what's called Methods.
    >
    > ----------
    > to be continued tomorrow.
    >
    > This is part of an installment of the article
    > “What are OOP's Jargons and Complexitiesâ€
    > by Xah Lee, 20050128. The full text is at
    > http://xahlee.org/Periodic_dosage_dir/t2/oop.html
    >
    > © Copyright 2005 by Xah Lee. Verbatim duplication of the complete
    > article for non-profit purposes is granted.
    >
    > The article is published in the following newsgroups:
    > comp.lang.c,comp.lang.c++,comp.lang.lisp,comp.unix.programmer
    > comp.lang.python,comp.lang.perl.misc,comp.lang.scheme,comp.lang.java.programmer
    > comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns
    >
    > Xah
    >
    > ∑ http://xahlee.org/
    >
     
    Wibble, May 23, 2005
    #2
    1. Advertising

  3. Xah Lee

    Paul McGuire Guest

    Is this supposed to be some sort of wake-up call or call-to-arms to all
    the CS lemmings who have been hoodwinked by Sun into the realm of
    jargon over substance?

    Please do some informed research and homework before spouting off with
    such blather. Sun Microsystems is hardly The Great Satan of OOP,
    trying to foist object-speak on the rest of humanity. The object
    concepts of classes, methods, instances, inheritance, polymorphism,
    etc. were already well on their way into the CS consciousness before
    Java came on the scene. To attempt to relate the emergence of object
    concepts as starting with Java simply illustrates a lack of historical
    awareness. To omit so obvious a Java precursor as Smalltalk seriously
    undermines any authority you may have once had on this topic.

    It is easy to attack "terminology" as "jargon," but in fact, precise
    definitions of terms help improve communication of complex concepts.
    Unfortunately, some of the concepts *are* complex - we just recently on
    this forum had someone ask about "polymorphism" when what they really
    meant was "overloaded method signatures." (It is even more unfortunate
    that language features such as overloaded method signatures and
    operator overloading get equated with OOP, simply because OO language
    XYZ supports them.) I would say that terminology becomes jargon when
    it introduces new terms that do not really help describe any new
    concepts, but simply raise an arbitrary barrier to new students of the
    field. And *any* complex field's terminology will be perceived as
    jargon to those who have not done adequate study - are you about to
    begin a parallel crusade to attack the jargon-spewing conspiracy among
    quantum physicists, what with their terms of top, down, spin, charm,
    muon, meson, lepton, etc.?

    Your complaint about Java requiring all code to reside in a class is
    not new. It is a common newbie issue that one has to get past "static
    void main(string[] args)" just to do a simple "Hello, World!". But
    this seems to be a minor point for someone as authoritative as yourself
    to waste over 1000 words on. All computing languages have good and bad
    features. Determining whether Java's "classes-only" language design is
    "good" or "bad" is something of a point of view - let it go that some
    folks find it overly purist and a nuisance, while others like the
    uniformity of implementation.

    You certainly seem to have a lot of energy and enthusiasm for these
    topics. It would be nice if you could find a way to illuminate and
    educate, without falling prey to the urge to pontificate. If you
    really have some points to make, put away the breathless and profane
    debate style - it just gets in the way of anything you're trying to
    say. Really, we are *mostly* adults here, and can make up our own
    minds on most things.

    -- Paul
     
    Paul McGuire, May 23, 2005
    #3
  4. Paul McGuire coughed up:
    > Is this supposed to be some sort of wake-up call or call-to-arms to
    > all the CS lemmings who have been hoodwinked by Sun into the realm of
    > jargon over substance?


    ....[rip]...

    > You certainly seem to have a lot of energy and enthusiasm for these
    > topics. It would be nice if you could find a way to illuminate and
    > educate, without falling prey to the urge to pontificate. If you
    > really have some points to make, put away the breathless and profane
    > debate style - it just gets in the way of anything you're trying to
    > say. Really, we are *mostly* adults here, and can make up our own
    > minds on most things.



    Of the many things that bother me about his post is his tendency to voice
    his conclusions as if they would be universally arrived at given his data.
    {shrug} Paying attention to this guy's post has proven to be a complete
    WOT.


    --
    I've seen this a few times--Don't make this mistake:

    Dwight: "This thing is wildly available."
    Smedly: "Did you mean wildly, or /widely/ ?"
    Dwight: "Both!", said while nodding emphatically.

    Dwight was exposed to have made a grammatical
    error and tries to cover it up by thinking
    fast. This is so painfully obvious that he
    only succeeds in looking worse.
     
    Thomas G. Marshall, May 23, 2005
    #4
  5. Xah Lee

    Kay Schluehr Guest

    Xah Lee wrote:

    > As part of this new syntax and purity, where everything in a program

    is
    > of Classes and Objects and Methods, many complex issues and concept
    > have arisen in OOP.


    Yes and it is easy to communicate a class which represents some thing
    determined by object oriented analysis and can be graphed as an element
    of an UML diagram in your development team. This is simply the state of
    the art in the IT industry and if FP-people or followers of any other
    alternative programming style can communicate their concepts and design
    patterns via type-classes or parentheses as well or better than they
    will going to lead the dicourse and OO will fall apart. I'm just
    sceptical that this is going to happen.

    Kay
     
    Kay Schluehr, May 23, 2005
    #5
  6. Xah Lee wrote:
    > So, a simple code like this in normal languages:
    > a = "a string";
    > b = "another one";
    > c = join(a,b);
    > print c;
    >
    > or in lisp style
    > (set a "a string")
    > (set b "another one")
    > (set c (join a b))
    > (print c)
    >
    > becomes in pure OOP languages:
    > public class test {
    > public static void main(String[] args) {
    > String a = new String("a string");
    > String b = new String("another one");
    > StringBuffer c = new StringBuffer(40);
    > c.append(a); c.append(b);
    > System.out.println(c.toString());
    > }
    > }


    The actual Java parallel to what you have written above is:

    String a = "a string";
    String b = "another one";
    String c = a + b;
    System.out.println (c);

    > In the same way, numbers in Java have become a formalization of many
    > classes: Double, Float, Integer, Long... and each has a bunch of
    > "methods" to operate or convert from one to the other.


    Byte, Short, Integer, Long, Char, Float and Double are wrapper classes,
    which exist chiefly to allow primitive content to be stored in
    collection classes.

    byte, short, int, long, char, float, and double are primitives.

    > Instead of
    > aNumber = 3;
    > print aNumber^3;
    >
    > In Java the programer needs to master the ins and outs of the several
    > number classes, and decide which one to use. (and if a program later
    > needs to change from one type of number to another, it is often
    > cumbersome.)


    This has nothing to do with object orientation or classes, but with
    strong typing, which is important for program verification, and an
    inescapable necessity for compiling to efficient object code. Strong
    typing has been a feature of mainstream programming languages since the
    late 1950's.

    --
    John W. Kennedy
    "The bright critics assembled in this volume will doubtless show, in
    their sophisticated and ingenious new ways, that, just as /Pooh/ is
    suffused with humanism, our humanism itself, at this late date, has
    become full of /Pooh./"
    -- Frederick Crews. "Postmodern Pooh", Preface
     
    John W. Kennedy, May 23, 2005
    #6
  7. Xah Lee

    John Bokma Guest

    John Bokma, May 24, 2005
    #7
  8. Xah Lee

    alex goldman Guest

    John W. Kennedy wrote:

    > Strong
    > typing has been a feature of mainstream programming languages since the
    > late 1950's.


    I'm just curious, what do you mean by /strong/ typing, and which strongly
    typed languages do you know?
     
    alex goldman, May 24, 2005
    #8
  9. Xah Lee

    Wibble Guest

    Java or even C is more strongly typed than lisp or tcl which
    dont really have a concept of a typed variable.
    Lisp only does runtime type checking unless you do wierd
    unnatural things.

    I suppose ADA or Eiffel might have stronger typing than
    java, but I dont know those languages.

    I guess strong is relative.

    alex goldman wrote:
    > John W. Kennedy wrote:
    >
    >
    >>Strong
    >>typing has been a feature of mainstream programming languages since the
    >>late 1950's.

    >
    >
    > I'm just curious, what do you mean by /strong/ typing, and which strongly
    > typed languages do you know?
     
    Wibble, May 24, 2005
    #9
  10. alex goldman wrote:
    > John W. Kennedy wrote:
    >
    >
    >>Strong
    >>typing has been a feature of mainstream programming languages since the
    >>late 1950's.

    >
    >
    > I'm just curious, what do you mean by /strong/ typing, and which strongly
    > typed languages do you know?


    Unfortunately, I have seen the meaning shift with the context. In Ada
    '83, it means it is not possible to have the equivalent of a C
    unprototyped function, and that mixed-type expressions tend to need
    explicit casting. In other contexts (as here), I've seen it used to mean
    simply that variables have definite types, and it is not possible
    (except by the use of polymorphic classes) for a variable to change from
    an integer to a float to a character string in the course of execution.
    In this sense, compile-to-machine-code languages (ee.g., Fortran, COBOL,
    C, C++, or Pascal), are generally strongly typed and interpreted
    languages (ee.g., shell scripts, Perl, REXX, APL, or LISP) are generally
    not. (In pure OO languages, such as SmallTalk or Ruby, the distinction
    may not really apply, since all variables are of the single type
    reference-to-root-class.)

    --
    John W. Kennedy
    "The bright critics assembled in this volume will doubtless show, in
    their sophisticated and ingenious new ways, that, just as /Pooh/ is
    suffused with humanism, our humanism itself, at this late date, has
    become full of /Pooh./"
    -- Frederick Crews. "Postmodern Pooh", Preface
     
    John W. Kennedy, May 24, 2005
    #10
  11. Xah Lee

    alex goldman Guest

    John W. Kennedy wrote:

    > Strong
    > typing has been a feature of mainstream programming languages since the
    > late 1950's.


    Is Fortran a strongly typed language? I don't think so. Strong typing has
    been invented in the 70's, if I'm not mistaken, when ML was invented, but
    strong typing has never been mainstream.
     
    alex goldman, May 24, 2005
    #11
  12. Also sprach John W. Kennedy:

    > alex goldman wrote:
    >> John W. Kennedy wrote:
    >>
    >>
    >>>Strong typing has been a feature of mainstream programming languages
    >>>since the late 1950's.

    >>
    >> I'm just curious, what do you mean by /strong/ typing, and which strongly
    >> typed languages do you know?

    >
    > Unfortunately, I have seen the meaning shift with the context. In Ada
    > '83, it means it is not possible to have the equivalent of a C
    > unprototyped function, and that mixed-type expressions tend to need
    > explicit casting. In other contexts (as here), I've seen it used to mean
    > simply that variables have definite types, and it is not possible
    > (except by the use of polymorphic classes) for a variable to change from
    > an integer to a float to a character string in the course of execution.
    > In this sense, compile-to-machine-code languages (ee.g., Fortran, COBOL,
    > C, C++, or Pascal), are generally strongly typed


    These are statically typed. The extent to which they are also strongly
    typed differs: C++ is probably a little more strongly typed than C, but
    by and large their typing is still fairly weak.

    Most often, languages with strong typing can be found on the functional
    front (such as ML and Haskell). These languages have a dynamic typing
    system. I haven't yet come across a language that is both statically and
    strongly typed, in the strictest sense of the words. I wonder whether
    such a language would be usable at all.

    Tassilo
    --
    use bigint;
    $n=71423350343770280161397026330337371139054411854220053437565440;
    $m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
     
    Tassilo v. Parseval, May 24, 2005
    #12
  13. Xah Lee

    alex goldman Guest

    Tassilo v. Parseval wrote:

    > Also sprach John W. Kennedy:
    >
    >> alex goldman wrote:
    >>> John W. Kennedy wrote:
    >>>
    >>>
    >>>>Strong typing has been a feature of mainstream programming languages
    >>>>since the late 1950's.
    >>>
    >>> I'm just curious, what do you mean by /strong/ typing, and which
    >>> strongly typed languages do you know?

    >>
    >> Unfortunately, I have seen the meaning shift with the context. In Ada
    >> '83, it means it is not possible to have the equivalent of a C
    >> unprototyped function, and that mixed-type expressions tend to need
    >> explicit casting. In other contexts (as here), I've seen it used to mean
    >> simply that variables have definite types, and it is not possible
    >> (except by the use of polymorphic classes) for a variable to change from
    >> an integer to a float to a character string in the course of execution.
    >> In this sense, compile-to-machine-code languages (ee.g., Fortran, COBOL,
    >> C, C++, or Pascal), are generally strongly typed

    >
    > These are statically typed. The extent to which they are also strongly
    > typed differs: C++ is probably a little more strongly typed than C, but
    > by and large their typing is still fairly weak.
    >
    > Most often, languages with strong typing can be found on the functional
    > front (such as ML and Haskell). These languages have a dynamic typing
    > system.


    No, ML & Haskell are strongly and statically typed. Read this paper if
    interested:

    http://research.microsoft.com/Users/luca/Papers/TypeSystems.pdf
     
    alex goldman, May 24, 2005
    #13
  14. Also sprach alex goldman:

    > Tassilo v. Parseval wrote:


    >> Most often, languages with strong typing can be found on the functional
    >> front (such as ML and Haskell). These languages have a dynamic typing
    >> system.

    >
    > No, ML & Haskell are strongly and statically typed. Read this paper if
    > interested:


    You're right, their type system is in fact static. To me they never had
    a very static feel though which is why I get their classification wrong
    most of the time. LISP would have been an example for strongly and
    dynamically typed.

    Tassilo
    --
    use bigint;
    $n=71423350343770280161397026330337371139054411854220053437565440;
    $m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
     
    Tassilo v. Parseval, May 24, 2005
    #14
  15. Xah Lee

    Joe Smith Guest

    Xah Lee wrote:

    > The Rise of Classes, Methods, Objects


    1) Most of the information you posted was incomplete and much of
    it is just plain wrong.

    2) What you posted was not perl related.

    Are you deliberately trying to make yourself a laughingstock?
     
    Joe Smith, May 24, 2005
    #15
  16. Wibble <> writes:

    > Java or even C is more strongly typed than lisp or tcl which
    > dont really have a concept of a typed variable.
    > Lisp only does runtime type checking unless you do wierd
    > unnatural things.
    >

    You get terminology totally wrong here. As already said, Lisp is
    stronger typed than C, but C is statically typed, whereas Lisp is
    dynamically typed. In Lisp (or Scheme), all variables have types:

    (define foo #(1 2 3))
    (vector? foo) => #t
    (boolean? foo) => #t

    See http://cliki.tunes.org/Type System.

    Rotty
    --
    Andreas Rottmann | Rotty@ICQ | 118634484@ICQ |
    http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc
    Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
    v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com

    Python is executable pseudocode, Perl is executable line-noise.
     
    Andreas Rottmann, May 24, 2005
    #16
  17. alex goldman wrote:
    > John W. Kennedy wrote:
    >
    >
    >>Strong
    >>typing has been a feature of mainstream programming languages since the
    >>late 1950's.

    >
    >
    > Is Fortran a strongly typed language? I don't think so. Strong typing has
    > been invented in the 70's, if I'm not mistaken, when ML was invented, but
    > strong typing has never been mainstream.


    I begin to believe that I have been reading naughty references, and that
    I should rather have said "statically typed".

    I am not familiar with modern Fortran. Surely it at least has argument
    prototyping by now?

    --
    John W. Kennedy
    "You can, if you wish, class all science-fiction together; but it is
    about as perceptive as classing the works of Ballantyne, Conrad and W.
    W. Jacobs together as the 'sea-story' and then criticizing _that_."
    -- C. S. Lewis. "An Experiment in Criticism"
     
    John W. Kennedy, May 24, 2005
    #17
  18. John W. Kennedy coughed up:
    > alex goldman wrote:
    >> John W. Kennedy wrote:
    >>
    >>
    >>> Strong
    >>> typing has been a feature of mainstream programming languages since
    >>> the late 1950's.

    >>
    >>
    >> Is Fortran a strongly typed language? I don't think so. Strong
    >> typing has been invented in the 70's, if I'm not mistaken, when ML
    >> was invented, but strong typing has never been mainstream.

    >
    > I begin to believe that I have been reading naughty references, and
    > that I should rather have said "statically typed".
    >
    > I am not familiar with modern Fortran. Surely it at least has argument
    > prototyping by now?



    There are some fortran advocates that pop into here now and again. Frankly,
    I'm spooked by how far fortran seems to have come. There is even OO support
    now. OI.

    I preferred the old days of thinking that fortran sucked "just 'cause". :)


    --
    Enough is enough. It is /not/ a requirement that someone must google
    relentlessly for an answer before posting in usenet. Newsgroups are
    for discussions. Discussions do /not/ necessitate prior research. If
    you are bothered by someone asking a question without taking time to
    look something up, simply do not respond.
     
    Thomas G. Marshall, May 24, 2005
    #18
  19. Andreas Rottmann wrote:

    > You get terminology totally wrong here. As already said, Lisp is
    > stronger typed than C, but C is statically typed, whereas Lisp is
    > dynamically typed. In Lisp (or Scheme), all variables have types:
    >
    > (define foo #(1 2 3))
    > (vector? foo) => #t
    > (boolean? foo) => #t


    Hmm.. weird Scheme you're using here.
    Normally you have to quote the vector (see R5RS, 6.2.6) because it is
    not self-evaluating, and boolean? should not return true on vectors (6.3.1).

    I get (on scheme48):

    (define foo '#(1 2 3))
    (vector? foo) => #t
    (boolean? foo) => #f


    mkb.
     
    Matthias Buelow, May 24, 2005
    #19
  20. Xah Lee

    Wibble Guest

    Thats how common lisp specifies a vector.

    Andreas, your link indicates that lisp is a Weakly typed language not
    strong. Theres no compile time type semantics, at least in CommonLisp,
    MacLisp, ZetaLisp or FranzLisp.

    (setq foo #(1 2 3))
    (setq foo 1)
    (setq foo "Whatever")


    Theres no type associated with foo, only with what the variable is
    currently referencing.

    From your link:
    When the types detected or declared are strictly enforced by the
    language's semantics, the language is strongly-typed.
    when the semantics of the language allows for inconsistencies between
    the compile-time type and the run-time type, the language is
    weakly-typed.


    Matthias Buelow wrote:
    > Andreas Rottmann wrote:
    >
    >
    >>You get terminology totally wrong here. As already said, Lisp is
    >>stronger typed than C, but C is statically typed, whereas Lisp is
    >>dynamically typed. In Lisp (or Scheme), all variables have types:
    >>
    >>(define foo #(1 2 3))
    >>(vector? foo) => #t
    >>(boolean? foo) => #t

    >
    >
    > Hmm.. weird Scheme you're using here.
    > Normally you have to quote the vector (see R5RS, 6.2.6) because it is
    > not self-evaluating, and boolean? should not return true on vectors (6.3.1).
    >
    > I get (on scheme48):
    >
    > (define foo '#(1 2 3))
    > (vector? foo) => #t
    > (boolean? foo) => #f
    >
    >
    > mkb.
     
    Wibble, May 25, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Xah Lee
    Replies:
    48
    Views:
    1,175
    Xah Lee
    Jun 7, 2005
  2. Xah Lee
    Replies:
    8
    Views:
    368
  3. Xah Lee
    Replies:
    18
    Views:
    563
    Xah Lee
    Jun 7, 2005
  4. Xah Lee
    Replies:
    24
    Views:
    600
    Bradd W. Szonye
    Feb 2, 2005
  5. Xah Lee
    Replies:
    58
    Views:
    941
    Xah Lee
    Jun 7, 2005
Loading...

Share This Page