Poll
Question:
What's the best high-level programming language for jobs?
Option 1: Java
Option 2: C#
Option 3: C++
Option 4: Python
Option 5: Ruby
Option 6: Other
Out of the options given, which do you think is the best high-level programming language for jobs? Consider the demand for certain languages in working environments (popularity), and the capabilities of each language. Post the reason(s) behind your vote.
Note: I know that this question may have been asked a dozen times, but it hasn't been asked in a while, and opinions may have changed. So don't tell me to "stop reviving old topics!" :P
I went C++ since there was no PHP and "Other" is icky.
I like C++ because of it's (atleast intended) portability across languages withought much runtime support (moreso in C but whatever). It is object oriented and that itself offers some neat features like operator overloading and classes. I would have chosen Java but really I havn't worked with it much and it's limited in most areas since it's interpreted.
I've had good results with Ruby and I'd recommend it to anyone but like Java I havn't used it enough.
Java has some serious shortcomings in the realm of object-orientation. For instance, you can't do multiple inheritance or operator overloading. Access specifications must be repeated for every variable or method. Traditional Java (pre-1.5) provided very little support for typesafe containers. (You'd get a ClassCastException at runtime if you screwed up, which is nice if you happen to have a testsuite that exercises that path. Otherwise...) 1.5 finally has some support for it with the so-called "generics", but I'm not clear on whether code which uses generics can even be compiled for a legacy JVM. Worse, the 1.5 javac defaults to compiling bytecode which is not legacy compatible and complains at you if you don't use 1.5-specific features like generics.
Beware that if any true Java zealots see your message, they'll go on and on about how Java is now almost as fast as C++. Some fanatics will even claim Java is faster than C++, which can really only occur if the C++ compiler isn't doing a full enough job. :)
Well I wasn't getting on it's speed I was getting on it's ability to perform on a level suitible for things like Game Development and stuff. Seriously I know it has a 3D factor but due to thier need to be cross platform I'd asusume it was OpenGL and most likely not very good across platform.
I'd rather use C++ with some ifdef's here and there to maintain portability than complicate things in the long run with Java. Not saying it's not good for a practical application though.
Quote from: Kp on January 02, 2006, 12:07 AM
Java has some serious shortcomings in the realm of object-orientation. For instance, you can't do multiple inheritance or operator overloading. Access specifications must be repeated for every variable or method. Traditional Java (pre-1.5) provided very little support for typesafe containers. (You'd get a ClassCastException at runtime if you screwed up, which is nice if you happen to have a testsuite that exercises that path. Otherwise...) 1.5 finally has some support for it with the so-called "generics", but I'm not clear on whether code which uses generics can even be compiled for a legacy JVM. Worse, the 1.5 javac defaults to compiling bytecode which is not legacy compatible and complains at you if you don't use 1.5-specific features like generics.
Beware that if any true Java zealots see your message, they'll go on and on about how Java is now almost as fast as C++. Some fanatics will even claim Java is faster than C++, which can really only occur if the C++ compiler isn't doing a full enough job. :)
On the other hand, I think that Java is more OO then C++ and one of the most OO languages there is. IMHO, the absence of multiple inheritance is a good thing, and it was definitely done deliberately by Java's creator. Multiple inheritance just makes it so much more likely that you're going to change one of your base classes and as a result screw up your child classes. Also, you could make the mistake of accessible variables with the same name in different base classes, or making functions with the same names and parameters. I think that Java's interfaces are a very good replacement to C++'s multiple inheritance.
I agree that Java can't be as fast as C++. Java's interpreted whereas C++ is translated. But there is a benefit of interpretation, which is better debugging! :P And Java's speed has never been an issue for me.
What I don't like about Java is that it is too hard to access asm with it, and it has no unsigned data. These seem like small concerns, because both can be fixed (though accessing asm is a pain), but these are the problems I have come into contact with Java.
My overall opinion on Java and C++ is that Java is more high-level than C++, and so the advantages and disadvantages of both languages revolve around this.
Java. Compiled to Java Bytecode it is supported over many systems including Linux, MacOS, BSD, Solaris, and Windows, and if you dislike its interpreted nature, programs such as gcj can compile it to native executables.
Someone told me recently that the "Java executables" are just 10-line C programs that use commandline to start up a Java program, such as a jar. And worse, that the computer still needs to have all the Java stuff required for any other Java program, including the JVM. Is this true?
Quote from: Ender on January 02, 2006, 09:20 AMOn the other hand, I think that Java is more OO then C++ and one of the most OO languages there is. IMHO, the absence of multiple inheritance is a good thing, and it was definitely done deliberately by Java's creator. Multiple inheritance just makes it so much more likely that you're going to change one of your base classes and as a result screw up your child classes. Also, you could make the mistake of accessible variables with the same name in different base classes, or making functions with the same names and parameters. I think that Java's interfaces are a very good replacement to C++'s multiple inheritance.
Agreed, Java's creators definitely (wrongly) thought it was bad to support multiple inheritance. How do interfaces mitigate any of these risks? You can still change the interface to break an implementing class. You can still have conflicting prototypes come down from multiple interfaces.
Quote from: Ender on January 02, 2006, 09:20 AMI agree that Java can't be as fast as C++. Java's interpreted whereas C++ is translated. But there is a benefit of interpretation, which is better debugging! :P And Java's speed has never been an issue for me.
How does being an interpreted language have any effect whatsoever on debugging? A C++ program built with debugging symbols can be traced more easily than a Java program can be traced with jdb. Build something in VC7 with full debugging symbols, then try to trace it with windbg. You get symbolic names of all the variables and original source in a companion display. Or have a C++ program commit an access violation, and check out the core dump. Assuming it didn't run afoul of RLIMIT_CORE, you get a full image of the process's memory at the time of the fault.
Quote from: Ender on January 02, 2006, 09:20 AMWhat I don't like about Java is that it is too hard to access asm with it, and it has no unsigned data. These seem like small concerns, because both can be fixed (though accessing asm is a pain), but these are the problems I have come into contact with Java.
Java is specifically designed to keep you away from high performing constructs like programmer directed runtime code generation, in the interest of keeping it portable. There's no excuse for leaving out unsigned types though. They
did include floating point, even though the JVM is required to implement a full emulation of floating point if the host hardware cannot do it natively. Given that, why not just require that the JVM emulate unsigned types if it runs on a host which lacks unsigned operations?
Quote from: Ender on January 02, 2006, 10:31 AMSomeone told me recently that the "Java executables" are just 10-line C programs that use commandline to start up a Java program, such as a jar. And worse, that the computer still needs to have all the Java stuff required for any other Java program, including the JVM. Is this true?
If it takes a C program 10 lines to start up a JVM, that's a bit silly. It shouldn't require nearly so much space. The rest of the answer depends on whether you meant binaries created by gcj (http://gcc.gnu.org/java/index.html) or some other strange construct. GCJ produces true native code from the Java source, though I think it still requires a GCJ-created Java runtime for support.
I agree about multiple inheritence.... I've seen some pretty cool things done with it, but on the whole, it seems to be more trouble than it's worth, especially when you run into virtual calls and naming collisions. Interfaces seem to solve this problem elegantly. Also, they allow for some very odd OOP behavior, like a class that inherits from a WheelBarrow and a FireTruck. While the resultant object might be able to transport materials as well as put out fires, it's pretty clear that the situation should not be that the new class IS_A WheelBarrow and IS_A FireTruck - but rather it simply shares common functionality. This should be defined via an abstract command -- interfaces -- rather than multiple base classes. The size saved in code reuse might be beneficial, but changes in the base class -- as already noted -- might come back to haunt you (because as I said, you can change a fire truck, but since our derived class isn't a fire truck, you might not think the change would affect it).
Operator overloading is very much a missing feature. It's about damn time, too, that the compiler does implicit typecasting for native types so that you can call a method on int. Too bad that feature isn't available in legacy systems. Java 1.5's "generic" or "template" feature is funky too.
Quote from: Kp on January 02, 2006, 11:02 AM
Agreed, Java's creators definitely (wrongly) thought it was bad to support multiple inheritance. How do interfaces mitigate any of these risks? You can still change the interface to break an implementing class.
But you know it at compile-time, not runtime.
Quote from: Kp on January 02, 2006, 11:02 AM
You can still have conflicting prototypes come down from multiple interfaces.
But you don't need to choose which implementation to support. If both a FireTruck and Wheelbarrow specify "transport(Object)," you know that the derived class is going to transport an object. You don't know how it's done (it's a "black box" of OOP), which is the way it's supposed to be. You know the input data and the result state.
Yeah... it would be really nice if Java had operator overloading. It's a growing language though, perhaps it will come out in the next platform, just like Enums (a wonderful addition) came out in the 1.5.0 platform.
Quote from: MyndFyre on January 02, 2006, 11:14 AMQuote from: Kp on January 02, 2006, 11:02 AM
Agreed, Java's creators definitely (wrongly) thought it was bad to support multiple inheritance. How do interfaces mitigate any of these risks? You can still change the interface to break an implementing class.
But you know it at compile-time, not runtime.
The same holds true if you're using an abstract base class in C++. It's always seemed a bit silly that an interface can define a function (instead of just declaring it). I can see how you get a
very slight bit of safety here, but I still don't think it merits swearing off multiple inheritance. :)
Quote from: MyndFyre on January 02, 2006, 11:14 AMQuote from: Kp on January 02, 2006, 11:02 AMYou can still have conflicting prototypes come down from multiple interfaces.
But you don't need to choose which implementation to support. If both a FireTruck and Wheelbarrow specify "transport(Object)," you know that the derived class is going to transport an object. You don't know how it's done (it's a "black box" of OOP), which is the way it's supposed to be. You know the input data and the result state.
I don't follow here. If you were doing pure virtual functions in C++, you'd be forced to implement a hybrid-specific transport and get a guarantee that it's the one called (since no other exists). If the functions aren't pure, then you have a conflict. In Java, interfaces match pure virtual functions much more closely than non-pure ones. If the interface mimiced a non-pure function, wouldn't you have the same problem?
Enums were long overdue. I remember seeing some really ugly hacks to simulate enums in prior versions of Java.
Quote from: Kp on January 02, 2006, 01:08 PM
The same holds true if you're using an abstract base class in C++. It's always seemed a bit silly that an interface can define a function (instead of just declaring it). I can see how you get a very slight bit of safety here, but I still don't think it merits swearing off multiple inheritance. :)
But polymorphism would be impossible without defining the function. Polymorphism relies on the fact that you can talk to an object without knowing what object it is. What you do know is the object's interface. If interfaces didn't define functions, then you wouldn't know the exact interface, you wouldn't know what parameters to send to the function. And to know this, you would have to know which kind of object it is, which is why polymorphism would be impossible.
Quote from: Kp on January 02, 2006, 01:08 PM
I don't follow here. If you were doing pure virtual functions in C++, you'd be forced to implement a hybrid-specific transport and get a guarantee that it's the one called (since no other exists). If the functions aren't pure, then you have a conflict. In Java, interfaces match pure virtual functions much more closely than non-pure ones. If the interface mimiced a non-pure function, wouldn't you have the same problem?
Hm, I also seem to be on a different wavelength! I quickly googled c++ virtual functions, and so I'm basing this post on what I got out of it (so if I'm completely wrong, forgive me :P). What I got out of it is that pure virtual functions are functions of a base class that not all derived classes can handle. So the base class creates a pointer as to which object is talked to when this function is called. So you can talk to many objects that are all derived from abstract base class A, and you don't have to worry that not all of the derived objects can take a certain function call that you plan to make. If I got this right, then this is different from Java's interfaces because in Java's interfaces all objects implement a certain interface, so all the objects derived from abstract base class B have impementations of the defined interface. It seems that the limitation in c++'s pure virtual functions is that the pointer that the base class creates can only apply to
one derived class. This helps you in that you can talk to your objects in a uniform, non-specific manner, but you cannot have different implementations of a pure virtual function because a pure virtual function can only point to one derived class to do the work, and so there is a single implementation.
Or maybe I'm wrong, and there is a way to conditionally decide which derived class to point to for a pure virtual function. I'm not that familiar with c++.
DId anyone even mention Python? Not that it is used in many jobs today. But soem day it, and its fellow interpreted languages will be used everywhere. The idea of these languages is to ease the creation of software developement, where you may hit hard to fix or hard to find errors that require you to debug in languages such as C/C++, Python is the exact opposite. I never have to search for errors in my Python applications, and I develope 10 times as fast as if I used C/C++, C#, or Pascal (just languages I know or relatively understand). The speed difference between Python and C++ for example, is hardly noticeable, and in the end does not matter at all. In the next few years, more and more companies will be developing in Python and other interpreted languages. Lua seems to be gaining some popularity.
Hm, well it's true that interpreted languages are better for debugging and testing, but then again they are slower, and the line-by-line interpretation can result in "bottleneck" situations. They also create larger programs. I agree that interpreted languages will be further embraced as computers become more powerful over time, but I cannot see any large games (i.e. Starcraft, Diablo, WoW) being written in interpreted languages in the near future. Which is an important consideration when deciding whether to use interpreted languages or translated languages.
EDIT3:
Deleted EDIT1 and EDIT2 (lol)
Deleted the rest, because I should back up my opinion (or be prepared to) with evidence before posting it.
Quote from: Ender on January 06, 2006, 04:27 PM
Quote from: Kp on January 02, 2006, 01:08 PM
The same holds true if you're using an abstract base class in C++. It's always seemed a bit silly that an interface can define a function (instead of just declaring it). I can see how you get a very slight bit of safety here, but I still don't think it merits swearing off multiple inheritance. :)
But polymorphism would be impossible without defining the function. Polymorphism relies on the fact that you can talk to an object without knowing what object it is. What you do know is the object's interface. If interfaces didn't define functions, then you wouldn't know the exact interface, you wouldn't know what parameters to send to the function. And to know this, you would have to know which kind of object it is, which is why polymorphism would be impossible.
Quote from: Kp on January 02, 2006, 01:08 PM
I don't follow here. If you were doing pure virtual functions in C++, you'd be forced to implement a hybrid-specific transport and get a guarantee that it's the one called (since no other exists). If the functions aren't pure, then you have a conflict. In Java, interfaces match pure virtual functions much more closely than non-pure ones. If the interface mimiced a non-pure function, wouldn't you have the same problem?
Hm, I also seem to be on a different wavelength! I quickly googled c++ virtual functions, and so I'm basing this post on what I got out of it (so if I'm completely wrong, forgive me :P). What I got out of it is that pure virtual functions are functions of a base class that not all derived classes can handle. So the base class creates a pointer as to which object is talked to when this function is called. So you can talk to many objects that are all derived from abstract base class A, and you don't have to worry that not all of the derived objects can take a certain function call that you plan to make. If I got this right, then this is different from Java's interfaces because in Java's interfaces all objects implement a certain interface, so all the objects derived from abstract base class B have impementations of the defined interface. It seems that the limitation in c++'s pure virtual functions is that the pointer that the base class creates can only apply to one derived class. This helps you in that you can talk to your objects in a uniform, non-specific manner, but you cannot have different implementations of a pure virtual function because a pure virtual function can only point to one derived class to do the work, and so there is a single implementation.
Or maybe I'm wrong, and there is a way to conditionally decide which derived class to point to for a pure virtual function. I'm not that familiar with c++.
It seems your understanding of the terminology is wrong. It's quite possible to create an interface without defining a single function. The functions need to be declared, but needn't be defined. A pure virtual function is a declaration of the prototype. A non-pure virtual function is a declaration of the prototype
and a definition of a default implementation (which is used if the derived class does not override it). Your second paragraph really doesn't make much sense, so I'm not even going to bother rebutting it.
Ok, so I went out on a limb and lost it =p I'm a C++ newbie. Let me ask one question though: if you have an abstract base class A with a pure virtual function doSomething(MyParam param), all the derived classes have to implement this function, right? I read something about the abstract class creating a pointer to the derived class which implements it, or at least, its ability to, and this is what confused me.
EDIT:
Wow this has become so off-topic. But who cares :P Also changed it's to its* ::)
Quote from: Ender on January 06, 2006, 09:16 PMif you have an abstract base class A with a pure virtual function doSomething(MyParam param), all the derived classes have to implement this function, right?
Strictly speaking, no. The following is legal:
class A
{
public:
virtual void doSomething() = 0;
};
class B : public A
{
int x;
/* doSomething is not implemented here */
};
class C : public B
{
virtual void doSomething();
};
void C::doSomething()
{
}
However, since I neglected to implement doSomething in B, B is also an abstract class. Therefore, I cannot declare an instance of A, nor can I can declare an instance of B. I can declare an instance of C, since C provides an implementation of doSomething.
Note that it's redundant to say 'abstract base class with a pure virtual function'. A class with a pure virtual function is automatically abstract.
Ah, that makes sense. Thanks.
Ender, interpreted languages can handle creating games just as well as C++ can. I've een games written in Python, you wouldn't know that they were written in an interpreted language. So what if interpreted languages are slower? Can a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases. Would you rather have a faster program that is more error prone, or a "slower" program that will never let you down?
Quote from: Ender on January 02, 2006, 12:17 PM
Yeah... it would be really nice if Java had operator overloading. It's a growing language though, perhaps it will come out in the next platform, just like Enums (a wonderful addition) came out in the 1.5.0 platform.
If there's one thing I hope never reaches Java, it's operator overloading. I hate it.
I've been using the 1.5 stream the last couple days, and I have to say I like it. Enumerations aren't actually numeric values, they're pure enumerations (you can request a value, with ElementName.ordinal(), if you want). And templates feel so much cleaner than they did with C++, until 2 days ago I always hated templates because they became so unwieldy, but Java actually handles them reasonably gracefully.
For opponents of Java's decision on unsigned: Java does unsigned the same way as Assembly does, with different operators. I both Java and Assembly, data types aren't signed, they're just data. How you use them indicates whether or not they're signed (the classic example is the signed and unsigned shift operators, >> and >>>). C chose to use different variable types, and Java chose to use a different operator. In the end, they both have unsigned. It's VB that doesn't have unsigned at all.
To answer your question from this thread: none of the above. Different workplaces use different languages, commonly Java and C#, but if you want to have a much easier life, you should also learn C, Perl, and Shell (Bash or whatever). When I'm at work, I frequently need to throw together a quick script to make my life easier. I'll usually use Perl or Shell for it. If I'm writing anything a little bigger, or that's processing-heavy (not data), I use C. If I need a program that has to work on different systems or that has to do something more advanced (unzip files, send objects across a network, etc), I use Java. It really comes down to: The right language for the job. And they're all important, because it's rare that you do one single job.
Quote from: iago on January 07, 2006, 01:07 PMFor opponents of Java's decision on unsigned: Java does unsigned the same way as Assembly does, with different operators. I both Java and Assembly, data types aren't signed, they're just data. How you use them indicates whether or not they're signed (the classic example is the signed and unsigned shift operators, >> and >>>). C chose to use different variable types, and Java chose to use a different operator. In the end, they both have unsigned. It's VB that doesn't have unsigned at all.
So what's the operator to use to perform an unsigned comparison against another value? I use < and > for signed comparisons, but for unsigned...? :)
Quote from: Kp on January 07, 2006, 02:05 PM
Quote from: iago on January 07, 2006, 01:07 PMFor opponents of Java's decision on unsigned: Java does unsigned the same way as Assembly does, with different operators. I both Java and Assembly, data types aren't signed, they're just data. How you use them indicates whether or not they're signed (the classic example is the signed and unsigned shift operators, >> and >>>). C chose to use different variable types, and Java chose to use a different operator. In the end, they both have unsigned. It's VB that doesn't have unsigned at all.
So what's the operator to use to perform an unsigned comparison against another value? I use < and > for signed comparisons, but for unsigned...? :)
Hmm, now that you mention it, that's never come up. The only way that comes to mind is moving it into a bigger variable type, but that's gross. You win! :P
Quote from: Yegg on January 07, 2006, 12:44 PM
Ender, interpreted languages can handle creating games just as well as C++ can. I've een games written in Python, you wouldn't know that they were written in an interpreted language. So what if interpreted languages are slower? Can a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases. Would you rather have a faster program that is more error prone, or a "slower" program that will never let you down?
IMO, there is no way an interpreted language can create a program that can efficiently run a game like Starcraft, Diablo, or WoW. All the instructions for a translated language are already translated into machine language when you run it. But with an interpreted language, you have to run the bytecode (or the equivalent of Java's bytecode) through a virtual machine for interpretation. Each instruction has to be translated into machine language at runtime. Whereas a translated language is already compiled into machine language and only has to run this machine language, an interpreted language has to interpret the instructions into machine language AND then run the machine language through the lower levels. And as I said before, there can be "bottleneck" situations in the interpreted language's VM, whereas a translated language would have already worked these situations out. Games like chess and poker could be easily accomplished using interpreted language, but games like starcraft, with a more complex UI and way better graphics... Then again, my opinion is not based on evidence per se (I have never seen a Starcraft-like program written in Java at runtime). So I could be completely wrong.
Quote from: iago on January 07, 2006, 01:07 PM
Quote from: Ender on January 02, 2006, 12:17 PM
Yeah... it would be really nice if Java had operator overloading. It's a growing language though, perhaps it will come out in the next platform, just like Enums (a wonderful addition) came out in the 1.5.0 platform.
If there's one thing I hope never reaches Java, it's operator overloading. I hate it.
Hm, why?
Quote from: iago on January 07, 2006, 01:07 PM
For opponents of Java's decision on unsigned: Java does unsigned the same way as Assembly does, with different operators. I both Java and Assembly, data types aren't signed, they're just data. How you use them indicates whether or not they're signed (the classic example is the signed and unsigned shift operators, >> and >>>). C chose to use different variable types, and Java chose to use a different operator. In the end, they both have unsigned. It's VB that doesn't have unsigned at all.
Ah, you're right. I looked up the >>> operator. It says so here (http://java.sun.com/docs/books/tutorial/java/nutsandbolts/bitwise.html). I guess this operation makes this (http://forum.valhallalegends.com/index.php?topic=13705.0) post look silly!
Quote from: Kp on January 07, 2006, 02:05 PM
Quote from: iago on January 07, 2006, 01:07 PMFor opponents of Java's decision on unsigned: Java does unsigned the same way as Assembly does, with different operators. I both Java and Assembly, data types aren't signed, they're just data. How you use them indicates whether or not they're signed (the classic example is the signed and unsigned shift operators, >> and >>>). C chose to use different variable types, and Java chose to use a different operator. In the end, they both have unsigned. It's VB that doesn't have unsigned at all.
So what's the operator to use to perform an unsigned comparison against another value? I use < and > for signed comparisons, but for unsigned...? :)
Hm, I see your point. That becomes a problem when you're comparing unsigned qwords... which is java's limit for data storage (64 bit signed integers (long)). So the problem in Java is that the reduced range of data types due to everything being signed.
Quote from: Ender on January 07, 2006, 02:35 PM
Quote from: Yegg on January 07, 2006, 12:44 PM
Ender, interpreted languages can handle creating games just as well as C++ can. I've een games written in Python, you wouldn't know that they were written in an interpreted language. So what if interpreted languages are slower? Can a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases. Would you rather have a faster program that is more error prone, or a "slower" program that will never let you down?
IMO, there is no way an interpreted language can create a program that can efficiently run a game like Starcraft, Diablo, or WoW. All the instructions for a translated language are already translated into machine language when you run it. But with an interpreted language, you have to run the bytecode (or the equivalent of Java's bytecode) through a virtual machine for interpretation. Each instruction has to be translated into machine language at runtime. Whereas a translated language is already compiled into machine language and only has to run this machine language, an interpreted language has to interpret the instructions into machine language AND then run the machine language through the lower levels. And as I said before, there can be "bottleneck" situations in the interpreted language's VM, whereas a translated language would have already worked these situations out. Games like chess and poker could be easily accomplished using interpreted language, but games like starcraft, with a more complex UI and way better graphics... Then again, my opinion is not based on evidence per se (I have never seen a Starcraft-like program written in Java at runtime). So I could be completely wrong.
Partly true. Don't forget, when you have a program that is interpreted, there can be run-time optimizations. If it is optimized well while it is running, it is possible to skip large parts of processing that may or may not be required, then turn out to not be required. An example program is to write a loop in Java and C that does nothing, but does it 10000000 times. The key is to make it do something conditionally so that the compiler can't optimize it out. The Java version will remove it at run-time, but the C one won't, can't.
Java is currently slower than C. But keep in mind that it isn't IMPOSSIBLE, just difficult.
Quote from: Ender on January 07, 2006, 02:35 PM
Quote from: iago on January 07, 2006, 01:07 PM
If there's one thing I hope never reaches Java, it's operator overloading. I hate it.
Hm, why?
That's a whole other discussion. Search my history for it, I've already said it a long time ago.
Actually, I did the search, and here's one thing I said about it:
Quote from: iago on May 20, 2004, 07:16 AM
I disagree - I *hate* operator overloading. It makes things happen that shouldn't happen which just confuses things.
std::string a ="123test" + 3;
That should make a point to the character array "test", and it's impossible to figure out what's going on without the documentation because of the two overloads (= and +).
That code sample is extremely ambiguous as a result of overloading.
QuoteIt's VB that doesn't have unsigned at all.
I may be taking this out of context, because I don't know exactly whats being discussed, but
Byte is unsigned.
QuoteCan a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases.
In computer programming class, a few days ago, I ran the following code side-by-side:
Java 1.4:
public class Main {
public static void main(String args[]) {
for(long i = 0; i > -1; i++) {
System.out.println(i);
}
}
}VC++ 6:
#include "stdafx.h"
int main() {
for(long i = 0; i > -1; i++) {
printf("%u", i);
}
return 0;
}By the time Java reached 20,000, C++ was far past 60,000.
Quote from: Joe on January 07, 2006, 08:11 PM
QuoteCan a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases.
In computer programming class, a few days ago, I ran the following code side-by-side:
Java 1.4:
public class Main {
public static void main(String args[]) {
for(long i = 0; i > -1; i++) {
System.out.println(i);
}
}
}
VC++ 6:
#include "stdafx.h"
int main() {
for(long i = 0; i > -1; i++) {
printf("%u", i);
}
return 0;
}
By the time Java reached 20,000, C++ was far past 60,000.
Hmm, quite interesting. I'm not sure how accurate such a speed test is, but could you compare Python with C++ in the same manner if you get the time?
Quote from: Yegg on January 07, 2006, 09:01 PM
Quote from: Joe on January 07, 2006, 08:11 PM
QuoteCan a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases.
In computer programming class, a few days ago, I ran the following code side-by-side:
Java 1.4:
public class Main {
public static void main(String args[]) {
for(long i = 0; i > -1; i++) {
System.out.println(i);
}
}
}
VC++ 6:
#include "stdafx.h"
int main() {
for(long i = 0; i > -1; i++) {
printf("%u", i);
}
return 0;
}
By the time Java reached 20,000, C++ was far past 60,000.
Hmm, quite interesting. I'm not sure how accurate such a speed test is, but could you compare Python with C++ in the same manner if you get the time?
It's not accurate to do a speed test in that manner, and it's been discussed before. Not to mention that something as insignificant as that (a few statements) is not indicative of speed of the language at runtime, IMO.
This (http://forum.valhallalegends.com/index.php?topic=8102.msg75439#msg75439) topic I made ages ago brings up some discussion about speeds.
Quote from: Mephisto on January 07, 2006, 10:44 PM
Quote from: Yegg on January 07, 2006, 09:01 PM
Quote from: Joe on January 07, 2006, 08:11 PM
QuoteCan a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases.
In computer programming class, a few days ago, I ran the following code side-by-side:
Java 1.4:
public class Main {
public static void main(String args[]) {
for(long i = 0; i > -1; i++) {
System.out.println(i);
}
}
}
VC++ 6:
#include "stdafx.h"
int main() {
for(long i = 0; i > -1; i++) {
printf("%u", i);
}
return 0;
}
By the time Java reached 20,000, C++ was far past 60,000.
Hmm, quite interesting. I'm not sure how accurate such a speed test is, but could you compare Python with C++ in the same manner if you get the time?
It's not accurate to do a speed test in that manner, and it's been discussed before. Not to mention that something as insignificant as that (a few statements) is not indicative of speed of the language at runtime, IMO.
I didn't want him to do the test between C++ and Python to say that one was faster than the other, I knew that Python would be far behind C++. I'd just like to see the final result.
Quote from: Yegg on January 08, 2006, 12:33 PM
Quote from: Mephisto on January 07, 2006, 10:44 PM
Quote from: Yegg on January 07, 2006, 09:01 PM
Quote from: Joe on January 07, 2006, 08:11 PM
QuoteCan a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases.
In computer programming class, a few days ago, I ran the following code side-by-side:
Java 1.4:
public class Main {
public static void main(String args[]) {
for(long i = 0; i > -1; i++) {
System.out.println(i);
}
}
}
VC++ 6:
#include "stdafx.h"
int main() {
for(long i = 0; i > -1; i++) {
printf("%u", i);
}
return 0;
}
By the time Java reached 20,000, C++ was far past 60,000.
Hmm, quite interesting. I'm not sure how accurate such a speed test is, but could you compare Python with C++ in the same manner if you get the time?
It's not accurate to do a speed test in that manner, and it's been discussed before. Not to mention that something as insignificant as that (a few statements) is not indicative of speed of the language at runtime, IMO.
I didn't want him to do the test between C++ and Python to say that one was faster than the other, I knew that Python would be far behind C++. I'd just like to see the final result.
And my reply had nothing to do with the nature of your complaint, so...
Quote from: Joe on January 07, 2006, 08:11 PM
QuoteCan a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases.
In computer programming class, a few days ago, I ran the following code side-by-side:
Java 1.4:
public class Main {
public static void main(String args[]) {
for(long i = 0; i > -1; i++) {
System.out.println(i);
}
}
}
VC++ 6:
#include "stdafx.h"
int main() {
for(long i = 0; i > -1; i++) {
printf("%u", i);
}
return 0;
}
By the time Java reached 20,000, C++ was far past 60,000.
The key words?
Quote from: iago on January 07, 2006, 03:55 PM
If it is optimized well while it is running, it is possible to skip large parts of processing that may or may not be required, then turn out to not be required.
Try making the print conditional, if i < 0 print().
Just for fun, I did the test. Because Java has more startup time, I had to use significantly sized loops to prove the point. Here are my programs:
int main(int argc, char *argv[])
{
int i, j;
for(i = 0; i < 10; i++)
{
for(j = 0; j < 100000000; j++)
{
if(i < 0)
printf("%d\n", i);
}
}
return 0;
}
public class Test
{
public static void main(String []args)
{
int i, j;
for(i = 0; i < 10; i++)
{
for(j = 0; j < 100000000; j++)
{
if(i < 0)
System.out.println(i);
}
}
}
}
Then I compile and run each of them:
iago@slayer:~/tmp$ make test
cc test.c -o test
iago@slayer:~/tmp$ javac Test.java
iago@slayer:~/tmp$ time ./test
real 0m5.531s
user 0m5.473s ***
sys 0m0.003s
iago@slayer:~/tmp$ time java Test
real 0m4.936s
user 0m4.832s ***
sys 0m0.010s
Does this prove that Java is faster? No. It proves that Java outperforms C in some situations.
<edit> put astrisks beside the important value.
<edit2> for anybody who cares, if C is optimized:
iago@slayer:~/tmp$ gcc -o3 -o test test.c
iago@slayer:~/tmp$ time ./test
real 0m1.040s
user 0m1.020s
sys 0m0.000s
QuoteIt's not accurate to do a speed test in that manner, and it's been discussed before. Not to mention that something as insignificant as that (a few statements) is not indicative of speed of the language at runtime, IMO.
It shows how fast it can do arithmatic, by incrementing a register.
And for anyone defending Java, I gave it the head start, because I couldn't do them both at once. I'd probably have been better off in the other lab, which has dual-cores (or dual-chip, I don't know), but you'll live.
Quote from: Joe on January 08, 2006, 03:53 PM
QuoteIt's not accurate to do a speed test in that manner, and it's been discussed before. Not to mention that something as insignificant as that (a few statements) is not indicative of speed of the language at runtime, IMO.
It shows how fast it can do arithmatic, by incrementing a register.
And for anyone defending Java, I gave it the head start, because I couldn't do them both at once. I'd probably have been better off in the other lab, which has dual-cores (or dual-chip, I don't know), but you'll live.
I suppose you didn't read my post where I used a system call to time a C and a Java version, and show that the Java one was faster?
And the slowest part of yours, by FAR, is the print. I let it run for a few seconds, and pulled these stats:
Quote
Flat profile of 6.85 secs (608 total ticks): main
Interpreted + native Method
0.2% 1 + 0 Test.main
0.2% 1 + 0 Total interpreted
Compiled + native Method
1.8% 11 + 0 java.nio.Buffer.<init>
1.0% 6 + 0 sun.nio.cs.ISO_8859_1$Encoder.encodeArrayLoop
0.3% 2 + 0 java.io.PrintStream.write
0.3% 2 + 0 java.io.BufferedWriter.write
0.3% 2 + 0 java.lang.String.indexOf
0.2% 1 + 0 java.io.FileOutputStream.write
0.2% 1 + 0 Test.main
0.2% 1 + 0 java.lang.Long.stringSize
0.2% 1 + 0 java.io.PrintStream.write
0.2% 1 + 0 java.lang.Long.toString
0.2% 1 + 0 sun.nio.cs.StreamEncoder$CharsetSE.implWrite
0.2% 1 + 0 java.lang.Long.getChars
4.9% 30 + 0 Total compiled
Stub + native Method
94.6% 0 + 575 java.io.FileOutputStream.writeBytes
94.6% 0 + 575 Total stub
As you can see, 95% of the time is spent writing out bytes, and only 0.2% is spent in your loop. That's hardly a useful measure.
Also, when you're running 2 programs simultaneously, they are sharing the CPU, which doesn't really make for a useful test.
Also I would bet that using System.out.println() forces the output buffer to be flushed to the screen. The C program using printf() will not flush the buffer after every call, probably resulting in a substantial performance gain.
It would be interesting to try calling fflush() on stdout after every printf and see if the results change.
I believe at a newline character \n, the output is flushed.
But you're right, the fairest thing to do would be to use cout, with endl's.
But measuring output speed is pointless.
Quote from: iago on January 08, 2006, 04:43 PM
I believe at a newline character \n, the output is flushed.
But you're right, the fairest thing to do would be to use cout, with endl's.
But measuring output speed is pointless.
What is the value of endl? Is it simply '\n'?
Quote from: Yegg on January 09, 2006, 02:23 PMWhat is the value of endl? Is it simply '\n'?
I found this with my Googling expertise:
QuoteMany programmers append the endl manipulator after each cout expression, as in:
cout << "user login" << endl;
cout << "enter your name: " << endl;
cin >> name;
In the first line, the endl manipulator is added to force a line break. However, it's cheaper in terms of performance to use the '\n' character instead of endl because endl also flushes the stream rather than just adding a line break. Flushing a stream can be a costly operation. The second cout expression too has a redundant endl manipulator because the display must appear on the screen before the cin expression is executed, as cin and cout are tied.
The bottom line: avoid using the endl manipulator if you can because it slows down your program.
I've never heard this before and I've heard that endl is better. Anyone else know which is "better"?
I always use std::endl instead of a \n. Unless you're outputting to the screen rapidly -- and I mean very rapidly -- I doubt you will notice any performance difference in your program. std::endl is also guaranteed to actually end a line on every platform, whereas windows likes "\r\n", *nix likes '\n' and Mac likes '\r'.
endl flushes the buffers in addition to adding an endline character, similar to the way Java's System.out.println() does. And yes, in this example, 95% of the CPU time is spent putting output on the screen, so that is the controlling factor. Of course, it's a bad example in the first place, and it's already been explained why.
You soo rigged that test iago.
How?
And who cares? The two programs do the same thing, and Java was faster. Regardless of whether it was a contrived test, it proves that C isn't ALWAYS faster, as people here would have you believe.
Quote from: iago on January 10, 2006, 10:23 AM
How?
And who cares? The two programs do the same thing, and Java was faster. Regardless of whether it was a contrived test, it proves that C isn't ALWAYS faster, as people here would have you believe.
And sometimes execution speed isn't the primary concern. Sometimes coding speed is paramount.
Quote from: iago on January 10, 2006, 10:23 AM
How?
And who cares? The two programs do the same thing, and Java was faster. Regardless of whether it was a contrived test, it proves that C isn't ALWAYS faster, as people here would have you believe.
It was a joke lighten up :/
Quote from: MyndFyre on January 10, 2006, 10:44 AM
Quote from: iago on January 10, 2006, 10:23 AM
How?
And who cares? The two programs do the same thing, and Java was faster. Regardless of whether it was a contrived test, it proves that C isn't ALWAYS faster, as people here would have you believe.
And sometimes execution speed isn't the primary concern. Sometimes coding speed is paramount.
Actually, that's almost always true. And Java (and C#) tend to have shorter coding times, so there's yet another reason to use the higher level languages.
I chose Java, seeing that it is fast and is usable on all system platforms.
Saying Java is nice because it works on all platforms (which really it doesn't, it doesn't work on many hobby OS's, such as JoeOS or Optimix, but lets not go there) is like saying anal sex is good because it works on all genders.
Although Java's cross platform ability is nice (kinda like anal sex), you shouldn't pick it explicitly for that reason.
Quote from: Joe on January 30, 2006, 04:36 PM
Saying Java is nice because it works on all platforms (which really it doesn't, it doesn't work on many hobby OS's, such as JoeOS or Optimix, but lets not go there) is like saying anal sex is good because it works on all genders.
Although Java's cross platform ability is nice (kinda like anal sex), you shouldn't pick it explicitly for that reason.
... of course it doesn't there is no JVM implmented and iirc there isn't a *good* open source one. (I know there are some which I don't feel like citing now).
I'd opt for C# or C++ because it's simple a nice language all around.
Hardware is cheaper than people. It's better in most situations to have a language that's faster for people to write and slower to execute than vice versa. See Ruby on Rails.
Quote from: Banana fanna fo fanna on January 30, 2006, 06:31 PM
Hardware is cheaper than people. It's better in most situations to have a language that's faster for people to write and slower to execute than vice versa. See Ruby on Rails.
mindfuck!
Quote from: Banana fanna fo fanna on January 30, 2006, 06:31 PM
Hardware is cheaper than people. It's better in most situations to have a language that's faster for people to write and slower to execute than vice versa. See Ruby on Rails.
I agree 100%.
Quote from: Joe on January 30, 2006, 04:36 PM
Saying Java is nice because it works on all platforms (which really it doesn't, it doesn't work on many hobby OS's, such as JoeOS or Optimix, but lets not go there) is like saying anal sex is good because it works on all genders.
Although Java's cross platform ability is nice (kinda like anal sex), you shouldn't pick it explicitly for that reason.
That's the stupidest reason to choose Java IMO. I hate .NET because of virtual machines even if Vista will come standard with the .NET framework. The mass GUI interfaces on these applications is ridiculous.
IMO C++ is the best language. It makes you an efficient programmer, it makes you a more secure programmer, it makes you a more knowledable programmer, it makes you a more aware programmer.
I counter claims that C++ takes forever to code with: If you're good at it, it won't take that long.
I may be talking out of my ass but that's what I believe after having minor contact with most languages.
I agree. .NET is just a last ditch effort for Microsoft to keep world domination (defeating wine).
Who claims C++ takes forever to code with? Any language you don't know can take a while to code with.
If you're basing your opinion solely because it "makes you and efficient programmer, more secure programmer, more knowledgeable programmer" it would be kind of nice to show some examples since the only thing that makes you efficient is knowing the language, secure is knowing about exploits, and knowledgeable is again knowing the language.
But then again, that comes hand in hand with every language.
People need to face facts, this is 2006 not 1991 if we kept compatibility with everyone then we'd still be using DOS with FAT12. Microsoft and most of the world is moving to more advanced hardware with 3D Acceleration and those who refuse to accept it will be left behind.
Vista is doing a great job at implementing components to make it easy for programmers to develop applications and be able to take full advantages of the abilities of the operating system. If you havn't seen the raw power of some of the new things in Vista then I suggest you take a look at them because they dont' seem overdone or slow in the slightest.
Even some Linux desktops are starting to get 3D acceleration for Window transparency "glass like" effects and other misc window decorations. Things like XGL and such. Just goes to show the direction in which things are going.
C# is by far the easiest language I've programmed in and it's heavily documented both on MSDN and other sites. Offers the ability to create powerful applications with minimal efforts as it does things like garbage collection for you which in term makes you application performance better since it removes the threat of memory leaks in a program.
Anyhow thats my rant.
Also @ Joe's latest response:
Just when I thought you couldn't say anything dumber within a single topic..you post.
Quote from: Warrior on January 30, 2006, 09:18 PM
C# is by far the easiest language I've programmed in and it's heavily documented both on MSDN and other sites. Offers the ability to create powerful applications with minimal efforts as it does things like garbage collection for you which in term makes you application performance better since it removes the threat of memory leaks in a program.
Sounds like you haven't been introduced to interpreted languages and other dynamically typed languages (LISP, Scheme, Haskell, etc.). :p
Quote from: Networks on January 30, 2006, 09:00 PM
IMO C++ is the best language. It makes you an efficient programmer, it makes you a more secure programmer, it makes you a more knowledable programmer, it makes you a more aware programmer.
It makes you all of these things because of its many issues. It's lack of allowing the programmer to use their imagination to the fullest is a killer.
I said easy not lame.
Quote from: Warrior on January 30, 2006, 09:31 PM
I said easy not lame.
I must be tired. Unless you're talking to someone else? Anyways, I'm going to bed before I say something that makes absolutely no sense (other than what I mentioned about C++...).
Quote from: Yegg on January 30, 2006, 09:26 PM
Quote from: Warrior on January 30, 2006, 09:18 PM
C# is by far the easiest language I've programmed in and it's heavily documented both on MSDN and other sites. Offers the ability to create powerful applications with minimal efforts as it does things like garbage collection for you which in term makes you application performance better since it removes the threat of memory leaks in a program.
Sounds like you haven't been introduced to interpreted languages and other dynamically typed languages (LISP, Scheme, Haskell, etc.). :p
Quote from: Networks on January 30, 2006, 09:00 PM
IMO C++ is the best language. It makes you an efficient programmer, it makes you a more secure programmer, it makes you a more knowledable programmer, it makes you a more aware programmer.
It makes you all of these things because of its many issues. It's lack of allowing the programmer to use their imagination to the fullest is a killer.
I was under the pressumption that C++ gave you more control thus letting the programmer use their imagination to the fullest. I am not sure what you mean by that statement.
If imagination (which seems by Yegg's standards) to make someone not efficient at programming...then no thanks.
Quote from: Kp on January 02, 2006, 11:02 AM
Quote from: Ender on January 02, 2006, 09:20 AMOn the other hand, I think that Java is more OO then C++ and one of the most OO languages there is. IMHO, the absence of multiple inheritance is a good thing, and it was definitely done deliberately by Java's creator. Multiple inheritance just makes it so much more likely that you're going to change one of your base classes and as a result screw up your child classes. Also, you could make the mistake of accessible variables with the same name in different base classes, or making functions with the same names and parameters. I think that Java's interfaces are a very good replacement to C++'s multiple inheritance.
Agreed, Java's creators definitely (wrongly) thought it was bad to support multiple inheritance. How do interfaces mitigate any of these risks? You can still change the interface to break an implementing class. You can still have conflicting prototypes come down from multiple interfaces.
Quote from: Ender on January 02, 2006, 09:20 AMI agree that Java can't be as fast as C++. Java's interpreted whereas C++ is translated. But there is a benefit of interpretation, which is better debugging! :P And Java's speed has never been an issue for me.
How does being an interpreted language have any effect whatsoever on debugging? A C++ program built with debugging symbols can be traced more easily than a Java program can be traced with jdb. Build something in VC7 with full debugging symbols, then try to trace it with windbg. You get symbolic names of all the variables and original source in a companion display. Or have a C++ program commit an access violation, and check out the core dump. Assuming it didn't run afoul of RLIMIT_CORE, you get a full image of the process's memory at the time of the fault.
Point one, multiple inheritance is considered to be a bad idea by most if not all modern OO languages (that being those designed in the last 10 years, no there aren't many) because it makes it harder to determine the nature of your class at first glance (though only slightly IMO) and also introduces the possibility of attributes/methods clashing.
Java gets around this need by using constructs not available in C++ such as the protocol, which as far as I know appeared in widespread use in Objective-C.
I'll tell you also why interpreted languages are better for debugging, maybe not Java which is essentially a compiled language trying to be interpreted but missing the point entirely. More generally interpreted languages let you catch errors that simply can't known at compile time and obviously this contributes to the number of bugs that slip though into the final program – as you said you can get an image of the program at the time it crashed but this seems highly inelegant when compared to the facilities available to interpreted langs.
The best example of this IMHO is in CL implementation. Most good CL's allow a different style of programming to what you'd likely be used too. Under this model the program is built and debugged interactively by the programmer as it runs, allowing functions to be tested at and replaced and for you to browse and see low level details that aren't easily available in other languages very easily.
One example where this is was useful was when NASA debugged one of it's [I believe] voyagers (which incidentally used LISP) in this manner while it was hurtling through space :). How many languages have got this far, and how many would allow this to happen without disrupting operations?
Mark.
Quote from: Ender on January 02, 2006, 12:17 PM
Yeah... it would be really nice if Java had operator overloading. It's a growing language though, perhaps it will come out in the next platform, just like Enums (a wonderful addition) came out in the 1.5.0 platform.
Not to be a bitch, though I'm very capable of being one I'm sure but it's always a great source of amusement to see people go all gooey over operator overloading. It's a simply syntactic overly which really gives you nothing, not even the illusion of control and yet it's so loved. I'll have to write a paper about this sometime ;).
Consider the following incredibly simple implementation of Pythons for loop (similar to for-each in other languages), it's more pointing than operator overloading and yet only the most basic of examples as to what meta-programming can do. Just having real macros may very well blow your brains.
I can hear the C/C++ programmers now. Shhh, you don't make macros you have text replacement and there's a huge difference.
(define-syntax for
(syntax-rules ()
((for var in lst
body ...)
(map (lambda (var)
body ...) lst))))This small piece of Scheme (based on idea's developed 50 years ago) can handle just about everything the for loop in Python can with the exception that it can be extended i.e. zipped parameters could be added to the form easily enough to allow this operation too and then it's complete – unless you wish to add more :D.
I don't think anyones actually interested in this mind but even still. It's kinda funny when you compare a language near the top of the power spectrum with what most programmers consider powerful :).
Mark.
Quote from: Joe on January 30, 2006, 04:36 PM
Saying Java is nice because it works on all platforms (which really it doesn't, it doesn't work on many hobby OS's, such as JoeOS or Optimix, but lets not go there) is like saying anal sex is good because it works on all genders.
Although Java's cross platform ability is nice (kinda like anal sex), you shouldn't pick it explicitly for that reason.
Hahah love it and so true, though Java really isn't as cross platform as everyone seems to think. I can name many languages of the top of my head which are more cross platform: C, Perl, Python, Ruby, Scheme, CL, TCL, Obj-C... the list goes on.
Java has been said to have some issues with memory managment issues on some platforms.
Now on with the anal ;),
Mark.
Quote from: Networks on January 30, 2006, 09:00 PM
Quote from: Joe on January 30, 2006, 04:36 PM
Saying Java is nice because it works on all platforms (which really it doesn't, it doesn't work on many hobby OS's, such as JoeOS or Optimix, but lets not go there) is like saying anal sex is good because it works on all genders.
Although Java's cross platform ability is nice (kinda like anal sex), you shouldn't pick it explicitly for that reason.
That's the stupidest reason to choose Java IMO. I hate .NET because of virtual machines even if Vista will come standard with the .NET framework. The mass GUI interfaces on these applications is ridiculous.
IMO C++ is the best language. It makes you an efficient programmer, it makes you a more secure programmer, it makes you a more knowledable programmer, it makes you a more aware programmer.
I counter claims that C++ takes forever to code with: If you're good at it, it won't take that long.
I may be talking out of my ass but that's what I believe after having minor contact with most languages.
Oh let me count the number of things I could say about that... a lot but I wont waste my time because anyone who goes around citing "belief" is not going to see reason even when other languages are so obviously better.
C++ will not make you a better programmer, it will not make you think elegantly, it will not make you think securely (as evident by holes in most software written). Windows is a good example of an OS which uses C++/OOP in all the wrong places. That said it will make you a programmer hopelessly dependent on one specific idea – OOP. Good thing?
When you said other languages however I assume from your comment that you've stayed very firmly within the bounds of accepted industry practice – OO, imperative or procedural languages ;).
Personally I can program very well in OOP, I did for a long time but I wouldn't want anymore. After working with other "alternative languages" I've become more than a little aware that OOP is very much code bloat, and inflexible bloat at that.
You can try all the Algol/C-like language you like and learn nothing more than how to apply syntax in different ways. Change the semantics and most of these programmers would be hopelessly lost. Maybe you're not one of them though :).
Mark.
Quote from: Warrior on January 31, 2006, 10:54 PM
If imagination (which seems by Yegg's standards) to make someone not efficient at programming...then no thanks.
Personally I define a good programmer as one who comes up with elegant and good solutions, this takes imagination. Not blindly following like a sheep so in this instance Yegg is right.
IMO any language which forces you to think in unnatural and or limited ways as C++ and others do can't be defined as a good language. Hence any programmer who thinks in this way is just working within the borders provided. The number of solutions available for a given task are slashed, often the most elegant.
I would challenge any programmer here to write in C++ or Java an equivalent to the accumulator function below, in purpose and elegance. If you can't then maybe I have a point lol, if you can then I must just be crazy but I doubt it ;).
> (define (make-counter i) ; Defines a function which returns a closure over i.
(lambda (n) (set! i (+ n i)) i))
>
> (define (show-counter c) ; Define a function which shows the value of a counter.
(c 0))
>
> ;;; The code below demonstrates these functions being in used. This could be extended with a
> ;;; symbol parameter to emulate OOP style fully but in practice there is little point.
>
> (define counter1 (make-counter 0))
> (counter1 1)
1
> (counter1 1)
2
> (counter1 1)
3
> (counter1 1)
4
> (counter1 2)
6
> (counter1 2)
8
> (counter1 2)
10
> (show-counter counter1)
10
>
> (define counter2 (make-counter 1))
> (counter2 1)
2
> (counter2 1)
3
> (show-counter counter2)
3
> (show-counter counter1)
10
>
This code encapsulates a number, which should be initalized. It allows numbers to be added to the counter through the closure (a more generalized form of what you call an instance, with some important differences) and for the current value to be show in a clear and protected manner; this being the reason for encapsulation.
Think you can do it? I will of course give some concesion for the fact that types in C++ are stricter so don't worry about that, not that this should be a problem anyway.
Finally:
From the list my vote was Ruby because of it's rapidly increasing popularity, some very well known programmers are also betting that it will overtake Java as the next big language (it just overtook Python in book sales with ease) so it may well be worth learning :). Of the OOP languages it is IMO the most flexible and is available on multiple platforms. Aside from that the growing user base is producing some very nice third party libs.
Take care all I'm off to read,
Mark.
netytan: Stop with the trolling. You should present your arguments in a respectful fashion; I'm not going to see this discussion degenerate into a flame war.
Quote from: Skywing on February 01, 2006, 11:21 AM
netytan: Stop with the trolling. You should present your arguments in a respectful fashion; I'm not going to see this discussion degenerate into a flame war.
Sorry SkyWing :-[.
I assure you I'm NOT trying to start a flame war, I have no interest in arguing with people over which language is the best period, however the purpose of this thread was which languages would be best for work which may be taken a number of ways.
Which language will get you the best job? What is a good job? Which languages will get you a good job etc.
Everyone is free to use what they want of course and I hope they're free to express their thoughts on such subjects regardless of who disagrees? I'm simply expressed my oppinions about the posts I read as I came to them as everyone else here has. Unluckily there were a lot of good posts here and alot I wanted to reply to :).
The result is Trolling?
It's not my style to be false and keep my mouth shut – if I have something to say you can be sure i'll say it and I would hardly discribe this as Trolling but thats just me.
I wasn't trying to be disrespectful or anyone either but I obviously would like to see the equivilent if only out of personal interest, it was more to back up my claims :). People can talk until they're blue in the face and never back things up, I think I did that.
Anyway nice to meet you Sky, I've heard good things,
Mark.
I don't have a problem with you presenting arguments, but I would rather that the majority of your replies don't come barbed against those you do not share your point of view. Sound arguments stand alone and don't need that kind of thing included.
All that accomplishes is making it more difficult for people to reply objectively to your statements.
Quote from: netytan on February 01, 2006, 10:39 AM
Quote from: Warrior on January 31, 2006, 10:54 PM
If imagination (which seems by Yegg's standards) to make someone not efficient at programming...then no thanks.
Personally I define a good programmer as one who comes up with elegant and good solutions, this takes imagination. Not blindly following like a sheep so in this instance Yegg is right.
IMO any language which forces you to think in unnatural and or limited ways as C++ and others do can't be defined as a good language. Hence any programmer who thinks in this way is just working within the borders provided. The number of solutions available for a given task are slashed, often the most elegant.
I would challenge any programmer here to write in C++ or Java an equivalent to the accumulator function below, in purpose and elegance. If you can't then maybe I have a point lol, if you can then I must just be crazy but I doubt it ;).
> (define (make-counter i) ; Defines a function which returns a closure over i.
(lambda (n) (set! i (+ n i)) i))
>
> (define (show-counter c) ; Define a function which shows the value of a counter.
(c 0))
>
> ;;; The code below demonstrates these functions being in used. This could be extended with a
> ;;; symbol parameter to emulate OOP style fully but in practice there is little point.
>
> (define counter1 (make-counter 0))
> (counter1 1)
1
> (counter1 1)
2
> (counter1 1)
3
> (counter1 1)
4
> (counter1 2)
6
> (counter1 2)
8
> (counter1 2)
10
> (show-counter counter1)
10
>
> (define counter2 (make-counter 1))
> (counter2 1)
2
> (counter2 1)
3
> (show-counter counter2)
3
> (show-counter counter1)
10
>
This code encapsulates a number, which should be initalized. It allows numbers to be added to the counter through the closure (a more generalized form of what you call an instance, with some important differences) and for the current value to be show in a clear and protected manner; this being the reason for encapsulation.
Think you can do it? I will of course give some concesion for the fact that types in C++ are stricter so don't worry about that, not that this should be a problem anyway.
Finally:
From the list my vote was Ruby because of it's rapidly increasing popularity, some very well known programmers are also betting that it will overtake Java as the next big language (it just overtook Python in book sales with ease) so it may well be worth learning :). Of the OOP languages it is IMO the most flexible and is available on multiple platforms. Aside from that the growing user base is producing some very nice third party libs.
Take care all I'm off to read,
Mark.
If a specific method of programming has been time tested to work then I don't see the need to reinvent the wheel and possibly reduce the performance of the application as a result of it.
I don't know about you but I'm not going to let my performance suffer because I want to have special looking code. Sure thinking outside the box is what a programmer should do, but that's when it comes to solving problems in programming and getting something done, not in terms of efficiency or using a programming style which will do more harm than good.
Point noted Sky. Warrior what about writing smaller programs which allow for a greater degree of abstraction, which is often domain specific and includes less bugs while being more suited for the type of application at hand makes you think that your productivity would suffer by this?
Note: All of these statements may easily be proven though a short search on language productivity and functional vs imperative programming on google.
The point was not to reinvent the wheel here but to provide an elegant functional comparison between the use classes and the more general and hence flexible closure. It was purely an excursive, and far more simple than anything likely to be done in a real program but one not as easy accomplished under less able paradigms.
If OOP, the ruling idea behind the design of modern software, can't provide an equally elegant solution to such a simple problem then how would it elegantly handle more complex uses of closures?
Take the definition of quick-sort in haskell as an example of seriously improved productivity.
qsort [] = []
qsort (x:xs) = qsort i_lt ++ [x] ++ qsort i_em
where
i_lt = [y | y <- xs, y < x]
i_em = [y | y <- xs, y >= x]
Notes: ++ is the append operator and : is equivilent to cons in other languages. i_lt is a list of items less than x and i_em is a list of elements equal to or more than x.
If you've done any higher maths you should be able to follow this reasonably well right of the bat :). I'm not a math whiz lol, in fact I've never been much good with maths but I'm learning.
You're welcome to prove me wrong here using OO.
Mark.
Quote from: netytan on February 01, 2006, 10:39 AM
I would challenge any programmer here to write in C++ or Java an equivalent to the accumulator function below, in purpose and elegance. If you can't then maybe I have a point lol, if you can then I must just be crazy but I doubt it ;).
I'm hardly a C/++ preprocessor expert, but here's my rough equivalent. Note that I include cout in the macro because you're entering at a command-line and attempting to evaluate an expression, and I'm not.
#include <iostream>
// > (define (make-counter i) ; Defines a function which returns a closure over i.
// (lambda (n) (set! i (+ n i)) i))
#define MAKE_COUNTER(N) (N) = (N) + 1; cout << N << endl;
// > (define (show-counter c) ; Define a function which shows the value of a counter.
// (c 0))
#define SHOW_COUNTER(N) cout << (N) << endl;
// (define counter1 (make-counter 0))
#define COUNTER_1(count) for (int ___n = 0; ___n < (count); ___n++) { MAKE_COUNTER(number) }
// > (define counter2 (make-counter 1))
#define COUNTER_2(count) for (int ___n = 0; ___n < (count); ___n++) { MAKE_COUNTER(number2) }
int main(void);
using namespace std;
int main()
{
int number = 0; // > (define counter1 (make-counter 0))
COUNTER_1(1) // > (counter1 1)
COUNTER_1(1) // > (counter1 1)
COUNTER_1(1) // > (counter1 1)
COUNTER_1(1) // > (counter1 1)
COUNTER_1(2) // > (counter1 2)
COUNTER_1(2) // > (counter1 2)
COUNTER_1(2) // > (counter1 2)
SHOW_COUNTER(number) // > (show-counter counter1)
int number2 = 1; // > (define counter2 (make-counter 1))
COUNTER_2(1) // > (counter2 1)
COUNTER_2(1) // > (counter2 1)
SHOW_COUNTER(number2) // > (show-counter counter2)
SHOW_COUNTER(number) // > (show-counter counter1)
return 0; // syntactically correct but unnecessary if you prototype main() as void.
}
This is a poor example, in part because of the unnecessary use of macros, which I simply included because of the claim you made in the other thread about poor use of macros. The entire program would have been much more easily written:
int main()
{
int number = 0;
for (int i = 0; i < 4; i++) cout << (++number) << endl;
for (int i = 0; i < 3; i++) cout << (++(++number)) << endl;
cout << number << endl;
int number2 = 1;
for (int i = 0; i < 2; i++) cout << (++number2) << endl;
cout << number2 << endl;
cout << number << endl;
return 0;
}
Awesome Mynd.
the problem is that where the output may be the same the effect is not. Data in your program isn't encapsulated/protected, its just a variable and that can be modified by simple assignment. As isn't the case with data within an object, which is what I expected someone to do so 100 out of 10 for original thinking :).
In either case though both pieces of code are longer and not as clear, in fact, where my code works by calling a function yours works via looping and incrementing a variable or in the first case though replacing text at preprocessor time.
The idea here was to provide protection for the counters internal storage; in a sense to prove the OO is not the only, or indeed best way to do this. Heres a formal specification for an accumulator function:
"A function that takes a number n, and returns a function that takes another number i and returns n incremented by i."
In terms of OO you can simply simply replace "function" in the spec, though I also added to this a way of viewing the value in the accumulator which should be present in your code:
"A class that takes a number n, and returns an instance that takes another number i (probably though a method) and returns n incremented by i."
My comment about "macros" wasn't so much that they were used badly but that they're just replacing text. Macros in a much truer sense allow complete access to the code (in fact there are examples of Macros being used to implement entire languages) this means the AST; the very guts of the code at compile time, not it's textual representation – Macros in the sense that C/C++ uses them are like a neutered puppy in comparison.
Maybe I wasn't as clear as I'd hoped while explaining what I wanted the programmer to do? Hopefully it makes more sense now, sorry :).
Mark.
netytan,
Semantically, your scheme example is no different than creating a C++ class with some internal variable and an "add" method to modify this variable along with some property to retrieve the value.
You should try modifying your example so it doesn't use set! ;)
neytan, while he may be a troll, just illustrated a great point: everyone here missed the point that he was using a closure.
I voted Python.
However, eventually we are going to end up with a mix between Scheme and Smalltalk.
Quote from: dxoigmn on February 01, 2006, 03:44 PM
netytan,
Semantically, your scheme example is no different than creating a C++ class with some internal variable and an "add" method to modify this variable along with some property to retrieve the value.
You should try modifying your example so it doesn't use set! ;)
I'll do that dx if you can tell me how you can store the new value of a symbol without storing that value, sounds a little screwed no lol. Like telling someone to cross the road without crossing the road ;).
Not so, where the effect is similar in this case closures work in very different way to classes and this is a very important to how we can use them.
In OO languages a class is (in the most general terms) a template used for creating an instance of that class in memory. When you ask for a new instance of a class the interpreter/compiler allocates memory and and binds it too a pointer so you can interact with it.
This is fundamentally different from a closure which binds the *lexical environment* in which it was created. This happens from to top down and allows for far more control and richness here. For instance you can create a closure at any point, not least within a function definition. With very little functional sugar you could turn this into a simple protected relational object db (even though in fact it uses closures not objects) based on these ideas.
This is considerably harder using OO because it forces you to use the concept/abstraction in the way it defines. This is one very good reason that closures are more useful, you can define a system for OO programming using closures but you can't define a closures using OO (without managing the environment itself and then you're part way to defining a sub-language or env, in either way it gets complicated).
Aside from the conceptual point you raised the OO equivalent of the code I asked for where it may be equivalent will be longer and more convoluted; you have to do it the way it wants which effectively spoils the elegance of such a simple concept.
Why should a simple task be extended into being more than it is? Do I want to define a type every time I want to take advantage of this concept, even where it isn't needed? I've programmed in this way enough to answer no.
My $0.0000000000002
Mark.
Quote from: Banana fanna fo fanna on February 01, 2006, 03:51 PM
neytan, while he may be a troll, just illustrated a great point: everyone here missed the point that he was using a closure.
I voted Python.
However, eventually we are going to end up with a mix between Scheme and Smalltalk.
I'd like the technical definition of a troll sometime ;). If it's replying to a lot of posts then I most definitely am but the way I understood it had to do with irrelevance and each post I've made has some relevance to the reply though obviously I intend to say what I think as everyone here does :).
I'd prefer that my opinions and my willingness to express them didn't get me classified as a troll but if they must they must.
It would be a Python programmer who made the distinction, didn't expect that so much but I'm glad :).
Thanks Banana,
Later all,
Mark.
Quote from: netytan on February 01, 2006, 04:38 PM
I'd like the technical definition of a troll sometime ;)
I have to head to work soon, and I'll provide replies to other things mentioned once there, but I'll oblige this now.
A troll is someone who fits one or more of the following:
1.) posts incessant or irrelevant information,
2.) posts several times in a row when a "modify" link is available,
3.) posts with complete disregard to the opinions of others,
4.) posts opinions without grounding them with examples or clearly unbiased, professional research,
5.) advocates a point of view or opinion as fact, or
6.) posts without any kind of sensible consideration for common respect for others.
From what I can tell you fit items 2-5 of that list (inclusive).
netytan sent me a private message with a dispute about this list. I want to share his comments and my reply with the forum community, in hopes we might be able to clear up some forum etiquette.
I will address each of your points.
Quote from: netytan
1) If you look at the replies then you'll see that it is related/relevant, but they also include my opinions and whos dont? The whole broad is this and it's to be expected.
I did not accuse of you of this. I said that that a troll fits one or more of those, and said that number 1 did not apply to you.
Quote from: netytan
2) I dont see this so let me explain. I was replying to different posts and working though the thread, modifying my post each time with quotes from other peoples posts would have been pretty annoying.
Is it my bad that others didn't reply in the several hours I was to fill in the gaps? I'm sure you yourself have posted more than once to a thread before.
I believe you misunderstood me. Replying to a thread is perfectly acceptable and encouraged, as is replying to replies. However, this is the annoying part to other members of the forum -- example from pages 5 (http://forum.valhallalegends.com/index.php?topic=13734.60) and 6 (http://forum.valhallalegends.com/index.php?topic=13734.75) of the thread called "Best Programming Language for Jobs":
Warrior
netytan
netytan
netytan
netytan
netytan
Skywing
netytan
Skywing
Warrior
netytan
MyndFyre
netytan
dxoigmn
$t0rm (you know him as Banana fanna...)
netytan
netytan
MyndFyre
In the space of 18 replies yours took up 10; this is more than one reply for every reply made to you. The repeated-reply issue is one that we bring up frequently: if you are the most recent person to post in a thread, simply modify the last post rather than make a new reply. Or, if you are about to post a reply, open a copy of the thread you want to quote from in a new window or tab, select "Reply with Quote," copy the quote or part you want to copy, and then paste that into the reply textbox of the original.
Since you asked if I've posted multiple times in a thread, yes, I have. However, to see an example of the technique I just mentioned, take a look at this reply (http://forum.valhallalegends.com/index.php?topic=13943.msg142372#msg142372).
There are certain times, of course, when posting a second time in a row are warranted; these include situations in which a thread should be bumped out of necessity (although this is also frowned upon).
Quote from: netytan
3) This one again, everyone here was expressing different opinions however admittedly I don't agree with some of these (as you don't with mine) and I wont pretend I do but...
This one is more influenced by the following, although I'm sure I had a good reason for stating it when I did. Your tone is as if nobody else has anything worthwhile to say or contribute. That is not acceptable.
Quote from: netytan
4) ... I have backed this up with several examples, even if you don't agree with what I said they exist.
The only example you have given me is your counter example. You gave an example of a "color" abstraction, but you did not provide me with concrete details of how the abstract "color" concept is realized. Furthermore, you never demonstrated how this would be represented in a computer, where a Color OOP object is very clear and concise.
Quote from: netytan
5.) This ones crazy. There are Very few facts in reality however with a little time taken to research these subjects you'll see they are widely considered to be "fact" by researches and CS's on the front line.
This is a patent example of what I just accused you of. "With a little time taken to research these subjects, you'll see they are
widely considered to be 'fact' by reserchers and C[omputer] S[cientists] on the front line."
YOU are making the argument, so
YOU need to present the research. It is not apparent to me that Lisp and Scheme are front-line top-notch languages, because I don't see all numbers of programs popping up in them. But I'm not making the argument that they are.
Quote from: netytan
6) This one I can see because where I didn't mean to offend I wasn't considerate in expressing what I think.
Again, I did not make this claim about you, so I am not going to address it.
Quote from: netytan
7) Tack this one on, I am guilty of letting one thread spill over into another when it shouldn't have but this is in a large part because of replies made there.
They were related. It's OK, that happens quite a bit. $t0rm shouldn't have made a third thread about it, though, although he likes to make language flamewar threads just to see how long they last.
Quote from: netytan
I really don't really like being labeled a troll and as is likely common for trolls, I don't feel this label is justified. Which 5 things, taking this into account do you really think apply?
You probably don't mean to be a troll, but you're exhibiting troll-like behaviors. So perhaps take into account the behaviors I've listed and ask yourself whether you do them.
Quote from: MyndFyre on February 01, 2006, 04:47 PM
...
I will address each of your points.
Quote from: netytan
1) If you look at the replies then you'll see that it is related/relevant, but they also include my opinions and whos dont? The whole broad is this and it's to be expected.
I did not accuse of you of this. I said that that a troll fits one or more of those, and said that number 1 did not apply to you.
Ah, I read that wrong I read it as between 2 and 5 of these things apply to me but not as actually specifying which ones. My apology there Mynd.
Quote from: MyndFyre on February 01, 2006, 04:47 PM
Quote from: netytan
2) I dont see this so let me explain. I was replying to different posts and working though the thread, modifying my post each time with quotes from other peoples posts would have been pretty annoying.
Is it my bad that others didn't reply in the several hours I was to fill in the gaps? I'm sure you yourself have posted more than once to a thread before.
I believe you misunderstood me. Replying to a thread is perfectly acceptable and encouraged, as is replying to replies. However, this is the annoying part to other members of the forum -- example from pages 5 (http://forum.valhallalegends.com/index.php?topic=13734.60) and 6 (http://forum.valhallalegends.com/index.php?topic=13734.75) of the thread called "Best Programming Language for Jobs":
Warrior
netytan
netytan
netytan
netytan
netytan
Skywing
netytan
Skywing
Warrior
netytan
MyndFyre
netytan
dxoigmn
$t0rm (you know him as Banana fanna...)
netytan
netytan
MyndFyre
I can see your point here however aside from being a little annoying I don't see it as being a major problem, I will however modify them in the future. To be honest I wasn't really thinking about it I was just replying to what came up in turn :-[.
Quote from: MyndFyre on February 01, 2006, 04:47 PM
Quote from: netytan
3) This one again, everyone here was expressing different opinions however admittedly I don't agree with some of these (as you don't with mine) and I wont pretend I do but...
This one is more influenced by the following, although I'm sure I had a good reason for stating it when I did. Your tone is as if nobody else has anything worthwhile to say or contribute. That is not acceptable.
I took it to be more of a debate than a discussion, possibly a bad idea but I still wouldn't of conceded if I didn't agree.
Quote from: MyndFyre on February 01, 2006, 04:47 PM
Quote from: netytan
4) ... I have backed this up with several examples, even if you don't agree with what I said they exist.
The only example you have given me is your counter example. You gave an example of a "color" abstraction, but you did not provide me with concrete details of how the abstract "color" concept is realized. Furthermore, you never demonstrated how this would be represented in a computer, where a Color OOP object is very clear and concise.
The color example was a metaphor Mynd, as Banana recognized. I wasn't using it literally so there was no need to provide an actual representation for it. I also provided an example of quick-sort implemented in haskell which is obviously clearer than equivalent versions in other languages. I personally have seen examples of quick-sort done in most languages and this is without a doubt the most concise.
And then obviously the counter example and the Macro for expressing Pythons for loop in Scheme?
Quote from: MyndFyre on February 01, 2006, 04:47 PM
Quote from: netytan
5.) This ones crazy. There are Very few facts in reality however with a little time taken to research these subjects you'll see they are widely considered to be "fact" by researches and CS's on the front line.
This is a patent example of what I just accused you of. "With a little time taken to research these subjects, you'll see they are widely considered to be 'fact' by reserchers and C[omputer] S[cientists] on the front line."
YOU are making the argument, so YOU need to present the research. It is not apparent to me that Lisp and Scheme are front-line top-notch languages, because I don't see all numbers of programs popping up in them. But I'm not making the argument that they are.
You just win here, but the fact that you haven't looked into them doesn't make them any less "facts" than they would be otherwise. Surely some responsibilty must also go the person trying to disprove the argument? I'll present more evidence in the future besides by own posts on the subject :).
Thanks at least for giving me the opportunity to explain Mynd, though I didn't expect this to end up in the forum. I PM'd it too you because I didn't think it had any relevance to the thread. It's not my wish to act as a troll in ANY but I do get carried away in things like this. Things I feel strongly about.
Take care,
Mark.
Quote from: netytan on February 01, 2006, 06:53 PM
Thanks at least for giving me the opportunity to explain Mynd, though I didn't expect this to end up in the forum. I PM'd it too you because I didn't think it had any relevance to the thread. It's not my wish to act as a troll in ANY but I do get carried away in things like this. Things I feel strongly about.
As I said, I didn't think that this would be particularly harmful to bring to the forum (I try to be as considerate as possible when doing such a thing), but I also thought that it would benefit the forum community as a whole. Don't take what I say as an attempt to quash your opinions or make you shut up. That is not the intent.
Is it possible netytan is someone we've seen in the past trying to come back with a "boom?"
I hope you're not thinking what I'm thinking ;)
Quote from: UserLoser on February 01, 2006, 08:07 PM
Is it possible netytan is someone we've seen in the past trying to come back with a "boom?"
He's no one you would know of.
Quote from: Yegg on February 01, 2006, 08:54 PM
Quote from: UserLoser on February 01, 2006, 08:07 PM
Is it possible netytan is someone we've seen in the past trying to come back with a "boom?"
He's no one you would know of.
How do you know this?
Quote from: UserLoser on February 01, 2006, 08:07 PM
Is it possible netytan is someone we've seen in the past trying to come back with a "boom?"
Well User, I can unequivocally say no to that because I've never posted on this forum before yesterday. You're welcome to check but you'd be wasting time.
Mark.
I can say that while his posting style may ruffle some feathers, I like the fresh perspective.
Personally, as far as "programming languages for jobs," the best thing you can do is be well-rounded. Being able to pick up a project written in C, Java, Lisp, a webscripting language, etc... at a moment's notice is an invaluable skill, and much more valuable IMO than being an absolute know-it-all with one language and being completely clueless with everything else.
Quote from: Zakath on February 04, 2006, 07:57 PM
I can say that while his posting style may ruffle some feathers, I like the fresh perspective.
Personally, as far as "programming languages for jobs," the best thing you can do is be well-rounded. Being able to pick up a project written in C, Java, Lisp, a webscripting language, etc... at a moment's notice is an invaluable skill, and much more valuable IMO than being an absolute know-it-all with one language and being completely clueless with everything else.
Hah, Zakath.. talking about programming?! Afk for ever.
Kidding.
Quote from: Zakath on February 04, 2006, 07:57 PM
I can say that while his posting style may ruffle some feathers, I like the fresh perspective.
:D thanks Zakath
The parts of this topic that talk about "what is a troll?" would make an interesting topic of its own. Maybe the moderator will see fit to split it off. I have my own ideas of what a troll is and would enjoy sharing. However, it would be offtopic to discuss in response to the "best programming language for jobs" thread.
im a troll :D
Quote from: effect on February 06, 2006, 09:59 PM
im a troll :D
(http://www.javaop.com/~joe/images/orly.jpg)