What is the purpose in these Python/Ruby/SmallTalk hybrids? I mean, yeah it's kind of cool to go type in some java commands in an interrpretor and see the output without going through the compiling process, but I still don't see a NEED for these languages. Actually, I don't really see what Python and Ruby do that would require them to be used instead of C++, C, Java, etc?? Could someone please explain what the point in these languages are?
I think the point's pretty simple; some people got together with a common idea that no language quite does what they want, and it's worth their time and efforts to create one that does. In the interests of broadening the appeal of their innovation, they promote use of the language to others, hoping that increased scrutiny and use of the tool will lead to an even better tool. Perl is an example of that, as an effort in creating a quantum leap in flexibility and power over the traditional pattern-matching Unix tools. From there Perl exploded into all sorts of other uses as a darling of sys admins (similar to how admins regard the bash shell -- indispensable). I do think we have far more choice than we need now in similar tools, but that's not preventing anyone from creating their own. Python has some really cool aspects to it that Java does not. When Ruby came around, I saw the writing on the wall and dropped anchor. I imagine we'll see a bit more 'innovation' and fusion of tools before it calms down and people get more selective.
I think interlanguage communication has always fascinated certain programmer types ... if the linkage is not there someone with time on their hands will put it in place. I agree that I see little utility in mixing statically typed OO languages with dynamically typed ones. But ... whatever floats your boat i that area. C (not C++) is fundamentally different. Use it when you know it and do not know assembler or the task is large. G.
Why Python and Ruby? Loosely typed, built in support for collections, developer speed, functional programming, string manipulation and the ability to tap into the Java API set. BTW I wrote a series of articles about languages that run in the JVM for the JDJ, and I wrote a Jython book. Basically, languages like Python and Ruby have less baggage and allow you to focus on the problem domain. In the articles, I showed programs written in Java and their equiv. in other languages. The Python versions of the same programs were much smaller and did the same thing. In addition the Python code is typically more readable. I am not against Java. I think it has its place. I use it a lot. Analogy: If your program was a building then Java would be the foundation, the frame, the roof. And, Python would be the carpet, paint, and furniture. I think you can view the articles online if you are a member of the JDJ. Membership use to be free and it may still be.
I found the article online. JPython (Jython; Python) The indentation does not show up well. Compare the Java code listing to their equiv. Python code listings.
This isn't a case of my-language-can-beat-up-your-language syndrome. JPython doesn't replace Java; it augments it. Java and JPython have complementary roles - sometimes they overlap. JPython facilitates the following: Embedded scripting language: You can add JPython to your application to enable those pesky, demanding end users to extend your applications through scripts. Thus your end users can extend your application to add functionality that only a domain expert could dream of. Interactive experimentation: JPython, like many scripting languages, provides an interactive interpreter. I use this to try out new APIs and for prototyping. Also, this is a great debugging tool - you can execute methods in any order, not in the normal sequence. Since the syntax is close to Java, it's easy to prototype. Rapid application development: Python programs are shorter than the equivalent Java programs, as I'll show in the Rosetta stone examples. Python is a lot easier to learn than Java. A novice programmer can learn enough Python in half a day (or sometimes in a few hours) to write effective scripts. In addition to being good for programming-in-the-small, you can use it for larger programs. Python has advance namespace management that makes programming-in-the-large feasible - many scripting languages don't. For example, Python has packages similar to Java's.
Back before Java became popular, I was a C++ bigot. I programmed in nothing but C++. I lived, ate and breathed C++. If it wasn't C++, it was rubbish. I thought C++ was the alpha and omega of object-oriented programming. I had "operator overloading" for breakfast, "templates" for lunch and "multiple inheritance" for dinner, and I always went back for seconds. Then a funny thing happened. I got a new job at another company as a C++ programmer. But they pulled the old bait and switch. Once I started working, someone suggested writing a good portion of a large project in a scripting language. I protested - I would not condescend to program in any other language but C++. Shortly after I started at this new company the following edict was put forth: "Thou shall use a scripting language." Thus I was forced by management to write a good portion of the project in a high-level scripting language. They told us to glue components written in C++ together with this scripting language (in addition to writing components in C++). At first I hated it, as any self-respecting C++ bigot would. Then, gradually, the productivity of my team - and me - skyrocketed. I became a true believer in scripting languages. The more I saw productivity climb, the less I coded in C++ and the more I coded in the scripting language. Granted, the scripting language had some limitations, but for many tasks it was just what the doctor ordered. Have you had a similar experience with a scripting language? If not, perhaps you should. Scripting Languages Many scripting languages are either object-oriented or object-based. Almost all of them are interpreted and use late-bound polymorphism. This makes scripting languages extremely dynamic and easy to program, which is essential for rapid application development (RAD), gluing components together and prototyping projects. There's a fine line between a scripting language and a programming language. For example, Smalltalk is an extremely dynamic interpreted language, yet I dare you to call it a scripting language to a Smalltalk evangelist - you'll probably get punched in the nose. When I refer to scripting languages, I'm referring essentially to languages that are mostly interpreted and extremely dynamic, that is, they employ late-bound polymorphism and dynamic typing. ....
Read the article... I think it will answer your question.