Re: What are OOP's Jargons and Complexities
On Fri, 30 Mar 2007 09:28:36 +0100, bugbear
[EMAIL PROTECTED] wrote:
Er. How about
public class test {
public static void main(String[] args) {
String a = a string;
String b = another one;
StringBuffer c = a + b;
System.out.println(c);
}
}
Even better: pick one entry of your choice from
http://images.google.com/images?q=%22don%27t+feed+the+troll%22
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}-(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^RY]*YB='
.'KYU;*EVH[.FHF2W+#\Z*5TI/ERZ`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:\r;print,redo}#JAPH,
--
http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
Arved Sandstrom wrote: Timofei Shatrov [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Fri, 30 Mar 2007 06:48:05 GMT, Mike Schilling [EMAIL PROTECTED] tried to confuse everyone with this message: Xah Lee wrote: So, a simple code like this in normal languages: becomes in Java: Only when written by someone almost entirely ignorant of Java. Which is the state most people want to be in... Which based on what I've seen, is the state that most Java programmers are in. They'd have no idea why Mike said what he did. what EVerrr! -- Lew -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
Michele Dondi wrote: Even better: pick one entry of your choice from http://images.google.com/images?q=%22don%27t+feed+the+troll%22 I pick http://img371.imageshack.us/img371/8263/noah7ok6rh.jpg/ -- Lew -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
Even better: pick one entry of your choice from http://images.google.com/images?q=%22don%27t+feed+the+troll%22 Michele OMG and here I am thinking that Ken Rockwell's site is full of crap. This one's worse... Does the guy have a job? Or a life? -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
On Fri, 30 Mar 2007 06:48:05 GMT, Mike Schilling [EMAIL PROTECTED] tried to confuse everyone with this message: Xah Lee wrote: So, a simple code like this in normal languages: becomes in Java: Only when written by someone almost entirely ignorant of Java. Which is the state most people want to be in... -- |Don't believe this - you're not worthless ,gr-.ru |It's us against millions and we can't take them all... | ue il | |But we can take them on! | @ma | | (A Wilhelm Scream - The Rip)|__| -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
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 Java:
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());
}
}
Er. How about
public class test {
public static void main(String[] args) {
String a = a string;
String b = another one;
StringBuffer c = a + b;
System.out.println(c);
}
}
Alternatively I could recode your Lisp example
as badly as you coded your Java.
BugBear
--
http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
Timofei Shatrov wrote: On Fri, 30 Mar 2007 06:48:05 GMT, Mike Schilling [EMAIL PROTECTED] tried to confuse everyone with this message: Xah Lee wrote: So, a simple code like this in normal languages: becomes in Java: Only when written by someone almost entirely ignorant of Java. Which is the state most people want to be in... As a particular case of the general proposition that most people want to be ignorant of computer programming. -- Lew -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
Xah Lee wrote:
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());
}
}
Er. How about
public class test {
public static void main(String[] args) {
String a = a string;
String b = another one;
StringBuffer c = a + b;
System.out.println(c);
}
}
bugbear wrote:
Alternatively I could recode your Lisp example
as badly as you coded your Java.
From what I've seen and heard of Xah Lee, you'd probably lose the bad-coding
competition to him. He's a professional.
-- Lew
--
http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
Timofei Shatrov wrote: On Fri, 30 Mar 2007 06:48:05 GMT, Mike Schilling [EMAIL PROTECTED] tried to confuse everyone with this message: Xah Lee wrote: So, a simple code like this in normal languages: becomes in Java: Only when written by someone almost entirely ignorant of Java. Which is the state most people want to be in... Most of them have the brains not to display their ignorance so widely. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
bugbear wrote:
Er. How about
public class test {
public static void main(String[] args) {
String a = a string;
String b = another one;
StringBuffer c = a + b;
String c (etc.), that is.
System.out.println(c);
}
}
--
http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
Timofei Shatrov [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Fri, 30 Mar 2007 06:48:05 GMT, Mike Schilling [EMAIL PROTECTED] tried to confuse everyone with this message: Xah Lee wrote: So, a simple code like this in normal languages: becomes in Java: Only when written by someone almost entirely ignorant of Java. Which is the state most people want to be in... Which based on what I've seen, is the state that most Java programmers are in. They'd have no idea why Mike said what he did. AHS -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
Mike Schilling [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
bugbear wrote:
Er. How about
public class test {
public static void main(String[] args) {
String a = a string;
String b = another one;
StringBuffer c = a + b;
String c (etc.), that is.
My answer, Mike. Since there was never any need for variables a and b to
be separate, I'd just be blatting out
System.out.println(a stringanother one);
as the solution to this particular problem. It's just a confuscated Hello
World.
AHS
--
http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
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 from both the OOP language machinery as well as a engineering practice. I think the fact that many design patterns from OOP are redundant in the presence of functional programming is very interesting. I'd like to see more written about this, not least because it would serve as an excellent introduction to functional programming for the majority of programmers who are versed only in object orientation (primarily C++, Java and C# programmers). There is an old paper on the GOF's OOP design patterns implemented in OCaml but it was not written by OCaml-savvy programmers and contained many errors and omissions. Perhaps the Lisp community have generated something better? Also, pattern matching is fundamental to many modern functional programming languages. Here, pattern matching is often the only way to manipulate concrete data structures and often results in code that is both faster and more concise than any object-oriented equivalent. I recently gave the example of a small symbolic simplifier written in OCaml/F# that is difficult and tedious to translate into many other languages efficiently (including C++, Java, C# and even Lisp). -- Dr Jon D Harrop, Flying Frog Consultancy OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
please DO NOT EVER followup xah's posts into comp.lang.perl.misc. he is not wanted there and is considered a troll. he hates perl so why he crossposts there is a question. if you want to followup, post only in your own group. keep him and his useless threads out of c.l.p.misc. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
Uri Guttman wrote: please DO NOT EVER followup xah's posts into comp.lang.perl.misc. he is not wanted there and is considered a troll. he hates perl so why he crossposts there is a question. if you want to followup, post only in your own group. keep him and his useless threads out of c.l.p.misc. We've heard similar reports about Xah Lee on other newsgroups as well. -- Lew -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
This idiot is a troll. This idiot is a troll. ThThis idiot is a troll. This idiot is a troll. is idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. This idiot is a troll. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
James Stroud wrote: there's a serious bug waiting here This idiot is a troll. This idiot is a troll. ThThis idiot is a troll. This idiot is a troll. is idiot is a troll. This idiot is a troll. This Remember, rockets went back to earth on such things (in pieces) ... idiot is a troll. This idiot is a troll. This idiot is a troll. This better use Xah's functional paradigm combined with his most hated religion instead: print This idiot is a troll. x 42 Regards f'up c.l.java.p Mirco -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities
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 Java:
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());
}
}
Only when written by someone almost entirely ignorant of Java.
--
http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
The Rise of Class Hierarchy Because of psychological push for purity, in Java there are no longer plain subroutines. Everything is a method of some class. Standard functions like opening a file, square root a number, for loop thru a list, if else branching statements, or simple arithmetic operations... must now somehow become a method of some class. In this way, coupled with the all-important need to manage data with inheritance, the OOP Class Hierarchy is born. Basic data types such as now the various classes of numbers, are now grouped into a Number class hierarchy, each class having their own set of methods. The characters, string or other data types, are lumped into one hierarchy class of data types. Many types of lists (variously known as arrays, vectors, lists, hashes...), are lumped into a one hierarchy, with each Classe node having its own set methods as appropriate. Math functions, are lumped into some math class hierarchy. Now suppose the plus operation +, where does it go? Should it become methods of the various classes under Number headings, or should it be methods of the Math class set? Each language deals with these issues differently. As a example, see this page for the hierarchy of Java's core language classes: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/package-tree.html (local copy) OOP being inherently complex exacerbated by marketing propaganda, and the inheritance and hierarchy concept is so entangled in OOP, sometimes OOP is erroneously thought of as languages with a hierarchy. (there are now also so-called Object-Oriented databases that ride the fad of all data are trees ...) Normally in a program, when we want to do some operation we just call the subroutine on some data. Such as open(this_file) square(4) But now with the pure OOP style, there can no longer be just a number or this_file path, because everything now must be a Object. So, the this_file, usually being just a string representing the path to a file on the disk, is now some file object. Initiated by something like this_file = new File(path to file); where this file class has a bunch of methods such as reading or writing to it. see this page for the complexity of the IO tree http://java.sun.com/j2se/1.4.2/docs/api/java/io/package-tree.html (local copy) see this page for the documentation of the File class itself, along with its 40 or so methods and other things. http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html (local copy) --- to be continued... 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 [EMAIL PROTECTED] http://xahlee.org/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Andrea Griffini wrote: Of course it is a language, just not a standardized one (if you include Borland's extensions that make it practical). The history of runtime error 200 and its handling from borland is a clear example of what I mean with a product. Hmm, I had to google this up... Quite embarrassing, but it's a runtime bug and got nothing to do with the language per se. And it certainly manifests itself after the hey-days of Turbo Pascal (when Borland seems to have lost interest in maintaining it.) mkb. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
On Sun, 05 Jun 2005 16:30:18 +0200, Matthias Buelow [EMAIL PROTECTED] wrote: Quite embarrassing, but it's a runtime bug and got nothing to do with the language per se. And it certainly manifests itself after the hey-days of Turbo Pascal (when Borland seems to have lost interest in maintaining it.) The point is not the bug, of course, but how borland handled it. It appeared when the user community of borland pascal was well alive and kicking, but borland didn't even invest 5 seconds for the issue. The users had to fix the library themselves (possible because at that time with Borland Pascal you were getting the whole source code of the library; but note that it was a 100% genuine bug due to misprogramming, fixing it even on a dead product would have been the a nice move from borland). The user community went even further, as so many executables were written witn borland pascal that a special tool for binary patching executables was built (actually a few of them, as being unofficial it wasn't that simple to get to know that such a tool existed, so different people independently resorted to the same solution). Andrea -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
On Wed, 01 Jun 2005 23:25:00 +0200, Matthias Buelow [EMAIL PROTECTED] wrote: Of course it is a language, just not a standardized one (if you include Borland's extensions that make it practical). The history of runtime error 200 and its handling from borland is a clear example of what I mean with a product. You are of course free to call even Microsoft Access a language (and make long term investment on it) if you want. Andrea -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Anno Siegel wrote: Tassilo v. Parseval [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. I fail to see how they were that different in terms of structured programming than C. The main benefit I was talking had more to do with types. It had types that were not compatible just because they had the same base type. For example you could have a type inches that was an integer and a type ounces that was also integral. Just because they were both integral did not make them type compatible. You couldn't just assign one to the other without you as the programmer explicitly saying that it was OK (by casting). In the environment I was programming in (engine controls for cars) where safety was a critical thing and a programming bug could kill people that safety was a very good thing. I think that also has a lot to do with why the government uses Ada. 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. I've posted before that hardly any language that has ever been somewhat popular has actually died (depending on your definition of that word). When asked for someone to name one once I got Simula for example (the forerunner of OO languages). Turns out that it continues to actually grow in popularity. 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. There are lots of reasons they have not taken over, although Ada is still in wide use. It seems to me that too many people like playing with dangerous power tools without the guards in place. -- Dale King -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
The Rise of Inheritance
In well-thought-out languages, functions can have inner functions, as
well as taking other functions as input and return function as output.
Here are some examples illustrating the use of such facilities:
subroutine generatePower(n) {
return subroutine (x) {return x^n};
}
In the above example, the subroutine generatePower returns a function,
which takes a argument and raise it to nth power. It can be used like
this:
print generatePower(2)(5) // prints 25
Example: fixedPoint:
subroutine fixedPoint(f,x) {
temp=f(x);
while (f(x) != temp) {
temp=f(temp);
}
return temp;
}
In the above example, fixedPoint takes two arguments f and x, where f
is taken to be a function. It applies f to x, and apply f to that
result, and apply f to that result again, and again, until the result
is the same. That is to say, it computes f[f[f[...f[x]...]]].
FixedPoint is a math notion. For example, it can be employeed to
implement Newton's Method of finding solutions as well as many problems
involving iteration or recursion. FixedPoint may have a optional third
parameter of a true/false function fixedPoint(func,arg,predicate) for
determining when the nesting should stop. In this form, it is
equivalent to the while loop in procedural languages.
Example: composition:
subroutine composition(a,b,c,...) {
return subroutine {a(b(...c...))};
}
The above example is the math concept of function composition. That is
to say, if we apply two functions in sequence as in g[f[x]], then we
can think of it as one single function that is a composition of f and
g. In math notation, it is often denoted as (gf). For example,
g[f[x]]y is the same as (gf)[x]y. In our pseudo-code, the
function composition takes any number of arguments, and returns a
single function of their composition.
When we define a subroutine, for example:
subroutine f(n) {return n*n}
the function is power of two, but the function is named f. Note here
that a function and its name are two different concepts. In
well-thought-out languages, defining a function and naming a function
are not made inseparable. In such languages, they often have a keyword
lambda that is used to define functions. Then, one can assign it
a name if one so wishes. This separation of concepts made many of the
lingustic power in the above examples possible. Example:
lambda (n) {return n^2;}\\ a function
(lambda (n) {return n^2;})(5) \\ a function applied to 5.
f = lambda (n) {return n^2;}\\ a function is defined and named
f(5)\\ a function applied to 5.
lambda (g) {return lambda {g(f)} } \\ a function composition of
(gf).
The above facilities may seem exotic to industrial programers, but it
is in this milieu of linguistic qualities the object oriented paradigm
arose, where it employees facilities of inner function (method),
assigning function to variable (instantiation), function taking
function as inputs (calling method thru object), and application of
function to expressions (applying method to data in a class).
The data-bundled-with-functions paradigm finds fitting application to
some problems. With the advent of such Objet-Oriented practice, certain
new ideas emerged. One of great consequence is the idea of inheritance.
In OOP practice computations are centered around data as entities of
self-contained boxed sets (objects). Thus, frequently one needs
slightly different boxed sets than previously defined. Copy and Pasting
existing code to define new boxed sets quickly made it unmanageable. (a
messy set of classes). With powerful lingustic evironment and
habituation, one began to write these new boxed-subroutines (classes)
by extending old subroutines (classes) in such a way that the new
subroutine contains all variables and subroutines of a base subroutine
without any of the old code appearing in the body of the subroutine.
Here is a pseudo-code illustration:
g = subroutine extend(f) {
new variables ...
new inner-subroutines ...
return a subroutine that also contains all stuff in subroutine f
}
Here, extend is a function that takes another function f, and
returns a new function such that this new function contains all the
boxed-set things in f, but added its own. This new boxed-set subroutine
is given a name g.
In OOP parlance, this is the birth of inheritance. Here, g inherited
from that of f. f is called the base class or superclass of g. g is the
derived class or subclass of f.
In functional terms, inheritance mechanism is a function E that takes
another function f as input and returns a new function g as output,
such that g contained all enclosed members of f with new ones defined
in E. In pure OOP languages such as Java, the function E is exhibited
as a keyword extends. For example, the above code would be in
Java:
class g extends f {
new variables ...
new inner-subroutines ...
}
Here is the same example in Python, where inheritance takes the form of
a class definition with a parameter:
class
Re: What are OOP's Jargons and Complexities?
posted mailed Paul McGuire wrote: 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 I've actually heard overloaded method signatures be referred to as ad-hoc polymorphism. Aren't there like 4 types of polymorphism: inheritance, ad-hoc, parameter templetization (sp?), and something else...can't remember. -- C -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Xah Lee wrote: to be continued tomorrow. Please don't... mkb. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Tassilo v. Parseval [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
On Wed, 1 Jun 2005 06:09:43 +0200, Tassilo v. Parseval [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
On Wed, 01 Jun 2005 16:07:58 +0200, Matthias Buelow [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Matthias Buelow wrote: 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. There's also FreePascal, which compiles approximately the same language as Turbo Pascal/Delphi, (and inherits most of Borland's linguistic extensions) and is opensource, works fine on Unixes, etc. It's in active use by several people, making games. Bear -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
the Rise of Access Specifiers (or, the Scoping Complexity of 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.scheme,comp.lang.java.programmer
comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns
Xah
[EMAIL PROTECTED]
http://xahlee.org/
--
http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
David Formosa (aka ? the Platypus) wrote: On Tue, 24 May 2005 09:16:02 +0200, Tassilo v. Parseval [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Also sprach Dale King: David Formosa (aka ? the Platypus) wrote: On Tue, 24 May 2005 09:16:02 +0200, Tassilo v. Parseval [EMAIL PROTECTED] 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=71423350343770280161397026330337371139054411854220053437565440; $m=-8,;;$_=$n(0xff)$m,,$_=$m,,print+chr,,while(($m+=8)=200); -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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.scheme,comp.lang.java.programmer comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns Xah [EMAIL PROTECTED] http://xahlee.org/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Xah Lee [EMAIL PROTECTED] (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 [EMAIL PROTECTED] URL: http://www.cs.uu.nl/~piet [PGP] Private email: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
On Friday 27 May 2005 02:15 am, Piet van Oostrum wrote: Xah Lee [EMAIL PROTECTED] (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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Tassilo v. Parseval [EMAIL PROTECTED] (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 [EMAIL PROTECTED] URL: http://www.cs.uu.nl/~piet [PGP] Private email: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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 [EMAIL PROTECTED] http://xahlee.org/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Xah Lee [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Roy Smith [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
RE: What are OOP's Jargons and Complexities?
[Paul Rubin] Strong typing means there [are] a lot of variables whose names are in ALL CAPS. +1 QOTW. =Tony.Meyer -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
On Tue, 24 May 2005 09:16:02 +0200, Tassilo v. Parseval [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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 = #00;
gray = #808080;
green = #008000;
In pure OOP, data as these now come with a subroutine (class) wrapper:
class listOfColors() {
black = #00;
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 = #00;
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.scheme,comp.lang.java.programmer
comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns
Xah
[EMAIL PROTECTED]
http://xahlee.org/
--
http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
[EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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 Ahthe blessed silence -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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.scheme,comp.lang.java.programmer comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns And guess what: that is called spamming. jue -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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); -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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); -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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? -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Wibble [EMAIL PROTECTED] 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 | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Wibble [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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). -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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
Re: What are OOP's Jargons and Complexities?
Xah Lee [EMAIL PROTECTED] writes:
So now we find out that Xah Lee is as ignorant of other programming
languages as he is of Python and Perl.
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...) {...}
}
Nested subroutines date back to Algol, which was first specified in
the 50s.
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.
Actually, classes and other OO concepts come out of simulation programming,
not as an outgrowth of nested functions. Most of the features one
associates with OO languages were present in Simula.
Function nesting and classes were viewed as independent features. Some
OO languages support nesting, others don't. I think it was Grace Murray
Hopper commenting on Ada who said that With classes, nesting is for the
birds.
This style of programing and language have become so fanatical that in
such dedicated languages like Java, everything in the language are
Classes.
Strictly speaking, this isn't true of *any* language. Even the most
fanatical of languages distinguish between classes, objects and
methods.
But IIRC, Java comes with a set of low-level types that don't have
classes associated with them.
This Object Oriented Programing style and dedicated languages (such as
C++, Java)
This is pretty sloppy english. You imply that C++, like Java, is pure OO
language - meaning that there are no freestanding functions or variables.
That's false.
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.
Actually, C++ became popular because it promised access to the power of
OO programming while leveraging the programmers familiarity with C. In
reality, it combined the worst features of both. Java became popular
because it fixed some of the problems with C++ while leveraging
programmers familiarity with C++ and promising run anywhere capability.
Personally, I think that these two languages are good examples of
someones ability to design a popular language being much better than
their ability to design a good language. But that's a matter of opinion,
and as such is debatable.
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.
At that time, OOP was pushing 30 years old. Some people were using it
and getting that component reuse that it promised. Others were using
it and discovering that designing reusable classes is *hard*. It was
clear to pretty much everyone that OOP wasn't a silver bullet.
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.
This is simply ludicruously wrong.
to be continued tomorrow.
Please don't waste our time.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Mike Meyer wrote: Xah Lee [EMAIL PROTECTED] writes: So now we find out that Xah Lee is as ignorant of other programming languages as he is of Python and Perl. I think you're misreading some of what is being said. Nested subroutines date back to Algol, which was first specified in the 50s. I think the author was speaking in terms of how high a level of a language it is, not necessarily how recent it is. Actually, classes and other OO concepts come out of simulation programming, not as an outgrowth of nested functions. Most of the features one associates with OO languages were present in Simula. Again, I think the author was pointing out that it is an outgrowth logically, not necessarily historically. There is a basic equivalence between a class and a group of functions closed over the same variables. I mention something similar in an IBM DeveloperWorks article here: http://www.ibm.com/developerworks/linux/library/l-highfunc.html Function nesting and classes were viewed as independent features. Some OO languages support nesting, others don't. I think it was Grace Murray Hopper commenting on Ada who said that With classes, nesting is for the birds. Doesn't this quote show the opposite? Strictly speaking, this isn't true of *any* language. Even the most fanatical of languages distinguish between classes, objects and methods. I think the point was that in Java everything is done within the context of a class. You can define methods, but only as a part of a class. You cannot define a function or even a variable that stands on its own. But IIRC, Java comes with a set of low-level types that don't have classes associated with them. But still, it does not allow you, the programmer, to do the same. Jon Learn to program using Linux assembly language http://www.cafeshops.com/bartlettpublish.8640017 -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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.
--
http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Xah Lee [EMAIL PROTECTED] writes: [snap] put it on your blog -- http://www.peter.dembinski.prv.pl -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Jonathan Bartlett wrote: I think you're misreading some of what is being said. I think you're giving the author too much credit. -- Erik Max Francis [EMAIL PROTECTED] http://www.alcyone.com/max/ San Jose, CA, USA 37 20 N 121 53 W AIM erikmaxfrancis Love is the true price of love. -- George Herbert -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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? -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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? -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
Jonathan Bartlett [EMAIL PROTECTED] writes: Mike Meyer wrote: Xah Lee [EMAIL PROTECTED] writes: So now we find out that Xah Lee is as ignorant of other programming languages as he is of Python and Perl. I think you're misreading some of what is being said. Given how clear Lee's writing is, that's certainly possible. I note that, while you disagree with my interpretation of what Lee said, you trimmed the text under discussion in *every* case. That sort of makes the discussion moot. I don't care enough about the subject to dig out his original quotes. I do stand by my interpretation of them as radically wrong, which is par for the course for Lee. If you really want to discuss these, please repost your comments, leaving Lee's text in place. Function nesting and classes were viewed as independent features. Some OO languages support nesting, others don't. I think it was Grace Murray Hopper commenting on Ada who said that With classes, nesting is for the birds. Doesn't this quote show the opposite? I don't think so. I had originally written a comment to the effect that early OO languages seemed to include it or not, with no apparent rhyme or reason. The GMH quote was meant to show that nesting - or lack of it - was pretty much irrelevant. I left out the intervening text. My bad. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
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. -- http://mail.python.org/mailman/listinfo/python-list
