>or in lisp style
>(set a "a string")
>(set b "another one")
>(set c (join a b))
>(print c)
This code has a syntax error. If you use "set" then you have to quote
the first argument:
(set 'a "a string")
Alternatively, you could use the more popular setq or setf:
(setq a "a string")
(setf a "a string")
Setq is a macro whose only purpose is to transform (setq x y) to (set
'x y) while setf is a far more powerful macro that can sometimes
perform function inversion to accomplish its task.
>So, a simple code like this in normal languages:
>a = "a string";
>b = "another one";
>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());
> }
>}
I don't think it has to be that complicated. I'm new to Java, and don't
have a compiler handy, but wouldn't this work?
String a = new String("a string");
String b = new String("another one");
String c = a + b;
System.out.printIn(c);
Eric Lavigne wrote:
Please don't remove attributions for quoted material.
>>So, a simple code like this in normal languages:
<snip>
> I don't think it has to be that complicated. I'm new to Java, and don't
> have a compiler handy, but wouldn't this work?
<snip>
Please watch for cross posts and remove any groups not appropriate for
your reply. Java obviously has nothing to do with C, C++ or Lisp so is
definitely off topic in comp.lang.c and comp.lang.c++ and I assume in
comp.lang.lisp
Also, this Xah Lee characters original post was off topic in
comp.lang.c, and from the way s\he massively cross posts stuff obviously
off topic in several of the groups, I would suggest s\he is a troll and
not worth responding to.
FU set.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Eric Lavigne wrote:
> I don't think it has to be that complicated. I'm new to Java, and don't
> have a compiler handy, but wouldn't this work?
>
> String a = new String("a string");
> String b = new String("another one");
> String c = a + b;
> System.out.printIn(c);
in Java it is even easier:
String a = "a string";
String b = "another one";
String c = a + b;
System.out.printIn(c);
but Xah Lee is right: in Java you have to wrap it in some function of a
class, so use Lisp:
(defparameter a "a string")
(defparameter b "another one")
(defparameter c (concatenate 'string a b))
c
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
> a simple code like this in normal languages
How do you define a "normal" language? Your view seems rather narrow.
> or in lisp style
LISP isn't a normal language? So is it an "abnormal" language, since it
doesn't fall into your "normal" and "OOP" world of computer
programming? If find your arguments so far to be nonsensical since
you're having trouble with simple classification.
> becomes in pure OOP languages
Funny how you use the most concise syntax possible for your favored
languages and the least concise possible for your OOP example. A better
Java example would be:
public class test {
public static void main(String [] args) {
String a = "a string";
String b = "another one";
String c = a + b;
System.out.println(c);
}
}
Oddly enough, that's only two logical lines longer than your supposedly
superior examples. Of course, you also need to consider that many
programming languages (that happen to not be OOP) require some form of
framework such as library inclusion of a function at the top lexical
level to act as an entry point, so most runnable examples will be
longer and more complicated whether they be OOP or not. Your example
translated to C would look like this:
#include <stdio.h>
#include <string.h>
int main(void)
{
char *a = "a string";
char *b = "another one";
char c[20];
strcpy(c, a);
strcat(c, b);
puts(c);
return 0;
}
C isn't OOP, yet the code is longer than even your verbose Java example
and not any easier to understand to a newcomer. Though C isn't a high
level scripting language, so it may be "abnormal" according to your
definition of programming languages.
> This Object Oriented Programing style and dedicated languages (such
as C++, Java)
You realize that C++ isn't an object-oriented programming language,
right? It's a multi-paradigm language that supports several programming
styles, among which, one is OOP. In fact, to make the best use of C++,
you would find yourself mixing multiple styles together to get the
powerful flexibility that makes good applications.
> among the programing mass of ignoramuses in the industry
You don't seem like such a bright bulb yourself. Perhaps if you gave a
more objective and well thought out comparison of OOPL and non-OOPL
then I (and probably most everyone else) wouldn't shrug you off as just
another biased fool who has his head too far up his own ass to smell
the bullshit.
By the way, I'm not a fan of OOP, so my opinion is based completely on
how you presented the material, not my own opinion of the topic.
I say what I mean and mean nothing at all. ;-) Putting aside the
stylistic reasons for not performing multiple definitions/operations on
a single line, my example was a direct translation of the Python-esque
code, it wasn't intended to be the most concise C possible. And I also
don't compile as C99, so your code would have undefined behavior for
me. So no, that's not what I meant at all. ;-)
"Jirka Klaue" <······@tkn.tu-berlin.de> wrote:
> ITYM:
>
> #include <stdio.h>
And _I_ think you all mean: "Oops, we shouldn't have followed up to a
known kook and/or troll".
HTH; HAND.
Richard
> ITYM:
>
> #include <stdio.h>
> #include <string.h>
>
> int main(void)
> {
> char *a = "a string", *b = "another one", c[20];
> puts(strcat(strcpy(c, a), b));
> }
>
> /* ;-) */
Just for the record, in Java you could write:
String a = "a string", b = "another one", c = a+b;
System.out.println(c);
All of this is irrelevant, the point is that the comparison by the OP is
meaningless as an example of what OOP leads to.
--
Morten
Morten Alver <······@invalid.no> writes:
> > ITYM:
> >
> > #include <stdio.h>
> > #include <string.h>
> >
> > int main(void)
> > {
> > char *a = "a string", *b = "another one", c[20];
> > puts(strcat(strcpy(c, a), b));
> > }
> >
> > /* ;-) */
>
> Just for the record, in Java you could write:
>
> String a = "a string", b = "another one", c = a+b;
> System.out.println(c);
>
> All of this is irrelevant, the point is that the comparison by the OP is
> meaningless as an example of what OOP leads to.
>
The OP is a fool and well known to be one. Xah has a reputation for
posting flawed and incorrect information on a regular basis. I think
it was only last week he was claiming Perl didn't support lists and
today he is claiming that *everything* in Java is a class - unless
things have changed a lot since I escaped java 6 years ago, not
everything is a class - for example int, double and float do not have
to be classes (though they do have class versions as well). In fact, I
seem to remember in my initial reading concerning the design of Java
that it was decided that making everyting a class was a *bad idea*,
especially for arithmetic, which is why int, double, float are not
implemented as objects and that the object versions are included for
when you need interoperability with class objects.
If you want a good laugh, visit Xah's homepage. He makes some
incredibly amusing claims and statements of 'fact' - as they say, on
the Internet, nobody knows your a dog!
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
From: alex goldman
Subject: Re: What are OOP's Jargons and Complexities?
Date:
Message-ID: <1482841.4WpqR85RcB@yahoo.com>
Tim X wrote:
> If you want a good laugh, visit Xah's homepage.
He mentions that over a million people already visit it per year.
> ITYM:
>
> #include <stdio.h>
> #include <string.h>
>
> int main(void)
> {
> char *a = "a string", *b = "another one", c[20];
> puts(strcat(strcpy(c, a), b));
> }
>
> /* ;-) */
You're cheating ! :-)
public class test {
public static void main(String [] args) {
String a = "a string", b = "another one";
System.out.println(a + b); // yes, I know you already know that :-)
}
} // Java - 1 ; C - 0... O:-)
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
From: Ola Bini
Subject: Re: What are OOP's Jargons and Complexities?
Date:
Message-ID: <d6sohr$k6v$1@news.su.se>
If you're going to critize programming paradigms - and specific
languages - wouldn't it be GREAT to actually be fluent in the languages
you're talking about? There are quite a few problems with the things
you've said:
> 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.
>
No, this is incorrect. There is no possibility to actually model
subclasses if a Class only was a "supersubroutine".
> 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 is simply NOT TRUE. Java has primitive number types, which makes
these simple to work with, very much like C data types.
> 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.
This is, as almost all your statements, not true. What you don't mention
is that PrintStream.println() actually is overloaded to take an Object,
and call that objects toString() automatically.
> For a example of the complexity of classes and methods, see the Java
> documentation for the StringBuffer class at
> http://java.sun.com/j2se/1.4.2/docs/api/java/lang/StringBuffer.html
This doesn't actually SAY anything. I could give you a few links to CLHS
pages, which define the functions and macros for working with strings
and sequences, and you would easily find as much complexity there.
> 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());
> }
> }
As already been noted here, the idiomatic Java way of writing this looks
somewhat like this:
public class Test {
public static void main(final String[] args) {
final String a = "a string";
final String b = "another one";
final String c = a + b;
System.out.println(c);
}
}
Furthermore, you could do this in a simple functional style like this:
public class Test {
public static void main(final String[] args) {
System.out.println("a string" + "another one");
}
}
> 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.
This is also incorrect. The String class is the only one class available
for handling strings. The StringBuffer/StringBuilder is simply an
utility class.
I do not say that OO is good for everything. In fact I hold the opposite
view, that it's harmful in many instances. The Lisp way is almost always
better. This critique is purely based on the fact that your column was
very full of errors and omitted information.
/O
Xah Lee schrieb:
> 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.
Hallo
To set a new idea I try to describe the oppostite here:
Assume you want n*n to any numbers. So give your OO-Box a few examples
and let the programm(s) have a look for the right methode.
3*3 --> 9
8*8 --> 64
... (working until return happen)
This will show you how many objects you have you can only use for
exactly one thing. Those objects should be removed (they are
problem-oriented). All other objects you can use for more than one case
are better. And consequently you have a new viewpoint to inherit
(recursive inherit, when a method can change other methods cross and
backwards).
Doing so to all objects will give you no control about what happens
inside. You only judge the result to: is good or not. At this point you
may see, what object oriented can be else. This can end in a object
environment, where all objects do more or less the same thing.
Or, an other try:
What you have is kind of monolithic. One object, one variable, one
process to manipulate the variable and one return value of the
manipulated variable. Maybe you take two or more variables in, the
variables have to be of the same kind (say all integer), otherwise your
object can't handle this.
Now your objekt should realize the type of variable and then be able to
give the variable to another object, which can handle that type. So
create a directions-object that calls other objects as
subroutines/methods to get a return value. You need a describer object,
that should know all kinds of variable-types the system can handle and
the special subroutine for not handled datas to create a new set of
subroutines. If it is good, one object passes variables only once and do
not controll, what other objects do. Else, when you allow your object(s)
to change itself, there is no need for new objects and your system keeps
small but the passthorugh time can be longer. (In my experiments I come
to oneway layers.)
stefan