What are OOP's Jargons and Complexities?

[Xah Lee]

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/...ingBuffer.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.sch eme,comp.lang.java.programmer
comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns

Xah
xa*@xahlee.org
∑ http://xahlee.org/

[Wibble]

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/...ingBuffer.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.sch eme,comp.lang.java.programmer
comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns

Xah
xa*@xahlee.org
∑ http://xahlee.org/

[Paul McGuire]

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

[Thomas G. Marshall]

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.

[Peter Dembinski]

"Xah Lee" <xa*@xahlee.org> writes:

[snap]

put it on your blog

--
http://www.peter.dembinski.prv.pl

[Kay Schluehr]

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

[John W. Kennedy]

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 Bokma]

John W. Kennedy wrote:

inescapable necessity for compiling to efficient object code. Strong
typing has been a feature of mainstream programming languages since the
late 1950's.

Give Lee another century and he will get there, hopefully :-D.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[alex goldman]

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?

[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 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

[Wibble]

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?

[alex goldman]

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.

[Tassilo v. Parseval]

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=71423350343770280161397026330337371139054411854 220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($ m+=8)<=200);

[alex goldman]

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/...ypeSystems.pdf

[Tassilo v. Parseval]

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=71423350343770280161397026330337371139054411854 220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($ m+=8)<=200);

[Joe Smith]

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?

[Andreas Rottmann]

Wibble <Wi****@Mailinator.com> 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%20System.

Rotty
--
Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.********@gmx.at
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.

[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.

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"

[Thomas G. Marshall]

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.

[Matthias Buelow]

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]

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.

[Paul Rubin]

Wibble <Wi****@Mailinator.com> writes:

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.
There are runtime semantics that enforce types.
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.

Yes, the compile-time type of 3 is integer, and the runtime type of 3
is also integer. There is no inconsistency. Compare that with C,
which lets you cast 3 to a pointer.

[beliavsky]

Thomas G. Marshall wrote:

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

Since the 1990 standard, if Fortran subroutines and functions are
placed in MODULEs, or if INTERFACEs are provided, the compiler checks
that procedures are called with the right types (int or float, scalar
or array, etc.) of arguments.
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.

Some Fortranners think the language has gotten too big and complicated,
sounding a bit like C programmers complaining about C++ (I don't mean
that pejoratively).

[Xah Lee]

The Rise of “Static� versus “Instance� variables

In a normal programing language, variables inside functions are used by
the function, called local variables.

In OOP paradigm, as we've seen, super-subroutines (classes) are
assigned to variables (instantiation), and the inner-subroutines
(methods) are called thru the variables (objects). Because of this
mechanism, what's once known as local variables (class variables) can
now also be accessed thru the assigned variable (objet) by design. In
OOP parlance, this is to say that a class's variables can be accessed
thru the object reference, such as in myObject.data=4. For example:
mySurface = new a_surface();
mySurface.coordinatesList={...} // assign initial coordinates

However, sometimes a programmer only needs a collection of variables.
For exmple, a list of colors:
black = "#000000";
gray = "#808080";
green = "#008000";

In pure OOP, data as these now come with a subroutine (class) wrapper:
class listOfColors() {
black = "#000000";
gray = "#808080";
green = "#008000";
}

Now to access these values, normally one needs to assign this
subroutine (class) to a variable (instantiation) as to create a object:
myColors = new listOfColors(); // instantiation! (creating a "object")
newColor = myColors.black;

As a workaround of this extraneous step is the birth of the concept of
“static� variables. (with the keyword “static� in Java) When a
variable is declared static, that variable can be accessed without
needing to instantiate its class. Example:
class listOfColors() {
static black = "#000000";
static gray = "#808080";
static green = "#008000";
}
newColor = listOfColors.black; // no instantiation required

The issue of staticality is also applicable to inner-subroutines
(methods). For example, if you are writing a collection of math
functions such as Sine, Cosine, Tangent... etc, you don't really want
to create a instance in order to use. Example:
class mathFunctions() {
static sin (x) {...}; // a static method
...
}
print mathFunctions.sin(1); // no need to create object before use
The non-static variant of variables and methods are called “instance
variables� or “instance methods�, or collectively “instance
members�. Note that static members and instance members are very
different. With static members, variables and methods can be called
without creating a object. But more subtly, for a static variable,
there is just one copy of the variable; for instance variables, each
object maintains its own copy of the variable. A class can declare just
some variables static. So, when multiple objects are created from the
class, some variables will share values while others having independent
copies. For example:
class a_surface() {
static pi; // a static variable
coordinatesList; // a instance variable
...
};
a_surface.pi=3.1415926; // assign value of pi for all
a_surface objects
mySurface1 = new a_surface();
mySurface1.coordinatesList={...} // assign coordinates to one a_surface
object
mySurface2 = new a_surface();
mySurface2.coordinatesList={...} // assign coordinates to another
a_surface object

The issues of static versus instance members, is one complexity arising
out of OOP.

----------
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.sch eme,comp.lang.java.programmer
comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns

Xah
xa*@xahlee.org
∑ http://xahlee.org/

[Ray Dillinger]

Wibble wrote:

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.

I think that such terms of art are sufficiently broad and
subject to interpretation that it is now necessary for each
researcher to say exactly what they mean by a claim placing
a language in a category. That definition must be taken
into account when interpreting the claims that particular
paper makes about those language categories.

That so many researchers have chosen to use the same terms
(static, dynamic, strongly, weakly ... ) to describe subtly
different things is distressing.

Bear

[John McGrath]

On 5/23/2005 at 7:54:24 PM, alex goldman wrote:

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

"Strongly typed" is not a very useful term, unless your intent is to
generate confusion or start an argument. Unfortunately, there is no
consensus as to what the term means.

--
Regards,

John McGrath

[Thomas G. Marshall]

be*******@aol.com coughed up:

Thomas G. Marshall wrote:

*Missattributed* --Thomas G. Marshall (I) did /not/ write the following:

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

Since the 1990 standard, if Fortran subroutines and functions are
placed in MODULEs, or if INTERFACEs are provided, the compiler checks
that procedures are called with the right types (int or float, scalar
or array, etc.) of arguments.

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.

Some Fortranners think the language has gotten too big and
complicated, sounding a bit like C programmers complaining about C++
(I don't mean that pejoratively).

There are old-poops in every discipline. :)
--
Unix users who vehemently argue that the "ln" command has its arguments
reversed do not understand much about the design of the utilities. "ln
arg1 arg2" sets the arguments in the same order as "mv arg1 arg2".
Existing file argument to non-existing argument. And in fact, mv
itself is implemented as a link followed by an unlink.

[Thomas G. Marshall]

Xah Lee coughed up:

The Rise of "Static" versus "Instance" variables

You are clearly unable to form a proper argument, *AND* you have irritated
nearly everyone frequently.

<PLONK>

Ah....the blessed silence....

[Jürgen Exner]

Xah Lee wrote:

The Rise of "Static" versus "Instance" variables
**** Please do not feed the troll *****
----------
to be continued tomorrow.
Please don't
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://[...]/Periodic_dosage_dir[...]
Didn't your doctor tell you that you have to take your dosage regularly?
© Copyright 2005 by Xah Lee. Verbatim duplication of the complete
article for non-profit purposes is granted.
Well, whatever he is missing, he has plenty of selfconfidence.
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.sch eme,comp.lang.java.programmer
comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns

And guess what: that is called spamming.

jue

[David Formosa (aka ? the Platypus)]

On Tue, 24 May 2005 09:16:02 +0200, Tassilo v. Parseval
<ta******************@rwth-aachen.de> wrote:

Also sprach John W. Kennedy: [...]
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.

Modula2 claims to be both statically typed and strongly typed. And
your wonder at its usablity is justified.

--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.

[alex goldman]

John McGrath wrote:

Unfortunately, there is no
consensus as to what the term means.

If the language allows the programmer to write programs from the 'slack'
domain, by saying "just trust me on this", then it's not strongly typed.

What other meanings are there? I wasn't aware of the lack of consensus.

[Pascal Costanza]

alex goldman wrote:

John McGrath wrote:

Unfortunately, there is no
consensus as to what the term means.

If the language allows the programmer to write programs from the 'slack'
domain, by saying "just trust me on this", then it's not strongly typed.

What other meanings are there? I wasn't aware of the lack of consensus.

There is a difference between getting a core dump when you invoke
undefined behavior on some object, or just getting an exception. You can
programmatically react to an exception to do something meaningful but
not to a core dump. Some people use the term weak typing to refer to
languages that potentially core dump whereas they use the term strong
typing for languages that don't.
Pascal

--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/

[John McGrath]

On 5/26/2005 at 3:11:44 AM, alex goldman wrote:

What other meanings are there?

http://en.wikipedia.org/wiki/Strongly_typed
http://c2.com/cgi/wiki?StronglyTyped

--
Regards,

John McGrath

[Piet van Oostrum]

>>>>> "Tassilo v. Parseval" <ta******************@rwth-aachen.de> (TvP) wrote:

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

What do you mean with: 'Haskell has a dynamic typing system'?
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: pi**@vanoostrum.org

[Xah Lee]

Joe: lang x is strongly typed
Dave: you mean statically typed?
John: no no, that's weakly typed.
Mike: actually, it is dynamically typed!

rely on the morons of the IT industry, every mother fucking one of
them, to sing and propagate jargons.

See also:
http://xahlee.org/UnixResource_dir/writ/jargons.html

Xah
xa*@xahlee.org
∑ http://xahlee.org/

[Roy Smith]

"Xah Lee" <xa*@xahlee.org> wrote:

Joe: lang x is strongly typed
Dave: you mean statically typed?
John: no no, that's weakly typed.
Mike: actually, it is dynamically typed!

I used to have a bunch of comp sci questions I would ask interview victims.
One of them was "what does it mean when a language is strongly typed?" I
once had somebody tell me it meant the language had long variable names,
and thus took a lot of typing.

[Paul Rubin]

Roy Smith <ro*@panix.com> writes:

I used to have a bunch of comp sci questions I would ask interview victims.
One of them was "what does it mean when a language is strongly typed?" I
once had somebody tell me it meant the language had long variable names,
and thus took a lot of typing.

But that's incorrect. Strong typing means there's a lot of variables
whose names are in ALL CAPS.

[alex23]

Joe: So I gave my girlfriend some flowers.
Dave: What, like tulips?
John: No, no, he gave her roses.
Mike: Were they red roses?
Xah: You MORONS, they were JUST _flowers_! Enough with the mother
fucking jargon already!!

The moral of the story being that when you're not active in a specific
domain, the intricacies of it can easily look irrelevant to you.

-alex23

[Piet van Oostrum]

>>>>> "Xah Lee" <xa*@xahlee.org> (XL) wrote:

XL> Joe: lang x is strongly typed
XL> Dave: you mean statically typed?
XL> John: no no, that's weakly typed.
That should have been `weekly typed', according to the link below.
Maybe there is also `daily typed' or `monthly typed'?
XL> http://xahlee.org/UnixResource_dir/writ/jargons.html

--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: pi**@vanoostrum.org

[James Stroud]

On Friday 27 May 2005 02:15 am, Piet van Oostrum wrote:

>> "Xah Lee" <xa*@xahlee.org> (XL) wrote:

XL> Joe: lang x is strongly typed
XL> Dave: you mean statically typed?
XL> John: no no, that's weakly typed.

That should have been `weekly typed', according to the link below.
Maybe there is also `daily typed' or `monthly typed'?

XL> http://xahlee.org/UnixResource_dir/writ/jargons.html

"""
If mathematicians are designing computer languages, they would probably just
called such thing _pure functions_. The term conveys the meaning, without the
“lamba� abstruseness.
"""

Proposing "jargon" to cure "jargon". Good job! Of course nothing will ever
rival "jargonize", the crown jewl of all "jargon".

--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

[Xah Lee]

The Rise of “Constructors� and “Accessors�

A instantiation, is when a variable is assigned a super-subroutine
(class). A variable assigned such a super-subroutine is now called a
instance of a class or a object.

In OOP practice, certain inner-subroutines (methods) have developed
into specialized purposes. A inner-subroutine that is always called
when the super-subroutine is assigned to a variable (instantiation), is
called a constructor or initializer. These specialized
inner-subroutines are sometimes given a special status in the language.
For example in Java the language, constructors are different from
methods.

In OOP, it has developed into a practice that in general the data
inside super-subroutines are supposed to be changed only by the
super-subroutine's inner-subroutines, as opposed to by reference thru
the super-subroutine. (In OOP parlance: class's variables are supposed
to be accessed/changed only by the class's methods.) Though this
practice is not universal or absolute. Inner-subroutines that change or
return the value of variables are called accessors. For example, in
Java, a string class's method length() is a accessor.

Because constructors are usually treated as a special method at the
language level, its concept and linguistic issues is a OOP machinery
complexity, while the Accessor concept is a OOP engineering complexity.

-----
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.sch eme,comp.lang.java.programmer
comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns

Xah
xa*@xahlee.org
∑ http://xahlee.org/

[Xah Lee]

the Rise of “Access Specifiers� (or, the Scoping Complexityof OOP)

In programing, a variable has a scope — meaning where the variable
can be seen. Normally, there are two basic models: dynamically scoped
and lexically scoped. Dynamic scoping is basically a time based system,
while lexical scoping is text based (like “what you see is what you
get�). For example, consider the following code:
subroutine f() {return y}
{y=3; print f()}

In dynamic scoping, the printed result is 3, because during evaluation
of the block all values of y is set to 3. In lexical scoping, “y�
is printed because any y in the block is set to 3 before f is called.
With regards to language implementation, Dynamic Scoping is the
no-brainer of the two, and is the model used in earlier languages. Most
of the time, lexical scoping is more natural and desired.

Scoping is also applicable to subroutines. That is to say, where
subroutines can be seen. A subroutine's scope is usually at the level
of source file (or a concept of a module/package/library), because
subroutines are often used in the top level of a source file, as
opposed to inside a code block like variables.

In general, the complexity of scoping is really just how deeply nested
a name appears. For example see in the following code:
name1; // top level names. Usually subroutines, or global
variables.
{
name2 // second level names. Usually variables inside subroutines.
{
name3 // deeper level names. Less often used in structured
programing.
}
}

If a programing language uses only one single file of commands in
sequence as in the early languages such as BASIC, there would be no
scoping concept. The whole program is of one single scope.

OOP has created a immense scoping complexity because its mode of
computing is calling nested subroutines (methods) inside subroutines
(classes). We detail some aspects in the following.

In OOP, variables inside subroutines (class variables) can also be
accessed thru a reference the subroutine is assigned to (that is, a
object). In OOP parlance: a variable in a class has a scope, while the
same variable when the class is instantiated (a objet) is a different
scoping issue. In other words, OOP created a new entity “variable
thru reference� that comes with its own scoping issue. For example:
class a_surface() {
coordinates={...}; // a variable
}

class main() {
mySurface = new a_surface();
mySurface.coordinates = {...}; // the same variable
}

In the above code, the variable “coordinates� appears in two
places. Once as defined inside a_surface, and once as a instantiated
version of a_surface, that is, a object. The variable as thru the
object reference apparently has a entirely different scoping issue than
the same variable inside the subroutine (class) definition. The
question for OOP language designers is: what should the scope be for
variables referred thru objects? Within the class the object is
created? within the class the variable is defined? globally? (and what
about inherited classes? (we will cover OOP inheritance later))

As we've seen, methods are just inner-subroutines, and creating objects
to call methods is OOP's paradigm. In this way, names at the
second-level programing structure often associate with variables (and
inner-subroutines), is now brought to the forefront. This is to say,
the scoping of subroutines are raised to a level of complexity as the
scoping of variables. (they are now both in the 2nd level of names (or
deeper).)

All in all, the scoping complexities of OOP as applied to different OOP
entities (classes, class variables, class's methods, object variables
and methods) is manifested as access specifiers in Java. In Java,
access specifiers are keywords “private�, “protected�,
“public�, used to declare the scope of a entity. Together with a
default scope of no-declaration, they create 4 types of scope, and have
entirely different effects when used upon a variable, a method, a
constructor, and a class.

See this tutorial of Java's access specifiers for detail:
http://xahlee.org/java-a-day/access_specifiers.html
-----
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.sch eme,comp.lang.java.programmer
comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns

Xah
xa*@xahlee.org
∑ http://xahlee.org/

[Dale King]

David Formosa (aka ? the Platypus) wrote:

On Tue, 24 May 2005 09:16:02 +0200, Tassilo v. Parseval
<ta******************@rwth-aachen.de> wrote:

Also sprach John W. Kennedy:

[...]

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.

Modula2 claims to be both statically typed and strongly typed. And
your wonder at its usablity is justified.

I used a variant of Modula-2 and it was one of the best languages I have
ever used. That strong, static type checking was a very good thing. It
often took a lot of work to get the code to compile without error.
Usually those errors were the programmers fault for trying to play fast
and loose with data. But once you got it to compile it nearly always worked.

--
Dale King

[Tassilo v. Parseval]

Also sprach Dale King:

David Formosa (aka ? the Platypus) wrote:

On Tue, 24 May 2005 09:16:02 +0200, Tassilo v. Parseval
<ta******************@rwth-aachen.de> wrote:

[...] 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.

Modula2 claims to be both statically typed and strongly typed. And
your wonder at its usablity is justified.

I used a variant of Modula-2 and it was one of the best languages I have
ever used. That strong, static type checking was a very good thing. It
often took a lot of work to get the code to compile without error.
Usually those errors were the programmers fault for trying to play fast
and loose with data. But once you got it to compile it nearly always worked.

I am only familiar with its successor Modula-3 which, as far as I
understand, is Modula-2 with uppercased keywords and some OO-notion
bolted onto it (I still recall 'BRANDED' references).

I have to say that doing anything with this language was not exactly a
delight.

Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854 220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($ m+=8)<=200);

[Anno Siegel]

Tassilo v. Parseval <ta******************@rwth-aachen.de> wrote in comp.lang.perl.misc:

Also sprach Dale King:

David Formosa (aka ? the Platypus) wrote:

On Tue, 24 May 2005 09:16:02 +0200, Tassilo v. Parseval
<ta******************@rwth-aachen.de> wrote:

[...] 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.
Modula2 claims to be both statically typed and strongly typed. And
your wonder at its usablity is justified.

I used a variant of Modula-2 and it was one of the best languages I have
ever used. That strong, static type checking was a very good thing. It
often took a lot of work to get the code to compile without error.
Usually those errors were the programmers fault for trying to play fast
and loose with data. But once you got it to compile it nearly always worked.

I am only familiar with its successor Modula-3 which, as far as I
understand, is Modula-2 with uppercased keywords and some OO-notion
bolted onto it (I still recall 'BRANDED' references).

I have to say that doing anything with this language was not exactly a
delight.

I've been through Pascal, Modula2 and Oberon, and I agree.

These languages had an axe to grind. They were designed (by Niklas
Wirth) at a time of a raging discussion whether structured programming
(goto-less programming, mostly) is practical. Their goal was to prove
that it is, and in doing so the restrictive aspects of the language
were probably a bit overdone.

In the short run they succeeded. For a number of years, languages of
that family were widely used, primarily in educational programming
but also in implementing large real-life systems.

In the long run, the languages have mostly disappeared from the scene.
It has been discovered that "structured programming" is possible in
about any language. It turns out that programmers prefer the
self-discipline it takes to do that in a liberal language over the
enforced discipline exerted by Papa Pascal and his successors.

Anno

[David Formosa (aka ? the Platypus)]

On Wed, 1 Jun 2005 06:09:43 +0200, Tassilo v. Parseval
<ta******************@rwth-aachen.de> wrote:

[...]

I am only familiar with its successor Modula-3 which, as far as I
understand, is Modula-2 with uppercased keywords and some OO-notion
bolted onto it (I still recall 'BRANDED' references).

Modula-2 also overused caps, I recall the irratation I found
programing it was irratating, streaching my finger to hit the shift
key or taking me hands of the home keys to bump the CAPSLOCK key
quick became phisically painfull.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.

[Matthias Buelow]

Anno Siegel wrote:

I've been through Pascal, Modula2 and Oberon, and I agree.
In the short run they succeeded. For a number of years, languages of
that family were widely used, primarily in educational programming
but also in implementing large real-life systems.

With a few relaxations and extensions, you can get a surprisingly useful
language out of the rigid Pascal, as evidenced by Turbo Pascal, one of
the most popular (and practical) programming languages in the late 80ies
/ start of the 90ies.

mkb.

[Andrea Griffini]

On Wed, 01 Jun 2005 16:07:58 +0200, Matthias Buelow <mk*@incubus.de>
wrote:

With a few relaxations and extensions, you can get a surprisingly useful
language out of the rigid Pascal, as evidenced by Turbo Pascal, one of
the most popular (and practical) programming languages in the late 80ies
/ start of the 90ies.

It was not a language. It was a product in the hand of a single
company. The difference is that a product can die at the snaps
of a marketroid, no matter how nice or how diffuse it is.

Andrea

[Matthias Buelow]

Andrea Griffini wrote:

With a few relaxations and extensions, you can get a surprisingly useful
language out of the rigid Pascal, as evidenced by Turbo Pascal, one of
the most popular (and practical) programming languages in the late 80ies
/ start of the 90ies.

It was not a language. It was a product in the hand of a single
company. The difference is that a product can die at the snaps
of a marketroid, no matter how nice or how diffuse it is.

Of course it is a language, just not a standardized one (if you include
Borland's extensions that make it practical). But does that matter?
With the exception of Scheme, none of the languages that are the object
of discussion of the newsgroups this thread is being posted to, are
standardized. Yet they are all quite popular.

And btw., I haven't used Pascal in a dozen years but my latest info is
that Turbo Pascal still lives in the form of "Delphi" for the Windows
platform. Surely not "dead" as I understand it.

mkb.

[Greg Ewing]

Anno Siegel wrote:

These languages had an axe to grind. They were designed (by Niklas
Wirth) at a time of a raging discussion whether structured programming
(goto-less programming, mostly) is practical. Their goal was to prove
that it is, and in doing so the restrictive aspects of the language
were probably a bit overdone.

This doesn't sound right. That argument might still have
been active at the inception of Pascal, I'm not sure. But
Pascal *does* have a goto statement, although you were
punished a little for using it (numeric labels only, which
had to be declared before use). And surely no-one was arguing
against structured programming by the time Modula came along,
much less Oberon.

The restrictiveness of these languages was mainly in the
type system, which is quite a different issue. And, as has
been pointed out, relaxing the type system of Pascal just
a little has resulted in a very successful family of
languages (UCSD, Turbo, Apple Pascal, etc.)

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg