Language Strengths/Weaknesses

dosnlinux · 04-30-2005, 08:43 AM

Hello, I'm extremly interested in programing, but I'm really not sure what languages are out there and what each is best suited to do.

The main languages I'm curious about are (mainly because they're the only ones I know of):
Python
Java
C
C++
C#
Pearl

If you know of any other languages I'd like to know about them too.

Why do you prefer one over the others?
What tools are available for each?
What do I need to know to get started with programming with these languages?

jschiwal · 04-30-2005, 09:11 AM

I think it really depends on what you want to do with the language. If you want to program in the KDE/Qt or Gnome/GTK+ frameworks, you will be probably want to use C++.

For kernel or kernel module programming, you need to use C with the gcc compiler.

Sometimes the target is the overriding concern. Using something like wxWidgets would make it easier to write a program for both linux and windows.

A program like K3b would be written in C++, but the program is actually a GUI front end for other console programs written in C.

For C programming on GNU Linux, I would highly recommend the book:
Linux Programming by Example: The Fundamentals
by Arnold Robbins.

I hope I've given you some ideas!

dosnlinux · 04-30-2005, 06:15 PM

Python:

ideal language for prototype development and other ad-hoc programming tasks, without compromising maintainability.

Python Strengths:
* Very-high-level language
* Easy to read code - white space matters
* Object Oriented
* Code can be grouped into modules and packages.
* supports raising and catching exceptions
* Data types are strongly but dynamically typed - see http://diveintopython.org/getting_to...functions.html
* contains advanced programming features
* Automatic garbage collection
* common programming tasks included (connecting to web servers, regular expressions, and file handling to name a few)
* interactive mode makes it easy to test short snippets of code.
* The interpreter can also be embedded into an application
* Easily Extended
* Open source
* Runs on many different platforms including Windows, MacOS, many brands of Unix, OS/2, ...

Python Weaknesses:
* No explicit return types

Python - General Info
www.python.org
http://www.linuxjournal.com/article/3882

coolman0stress · 04-30-2005, 06:59 PM

I'm a big fan of Scheme and Common Lisp. Also planning to check out Ruby at some point (because of Ruby on Rails).

win32sux · 05-04-2005, 02:09 PM

i was reading this (5-year-old) article about the Python programming language:

http://www.linuxjournal.com/article/3882

one of the anonymous comments after the article cracked-me-up, LOL:

Quote:

After looking at Python I believe that COBOL will make it big again,
especially if they call keep on calling it Object Oriented COBOL
force you to interpret, not compile it.
Let me say that I always recommend interpreted languages
to prospective software developers.
One big advantage of such languages is, of course, that if you (or your customer) runs into a problem you/he will do so at runtime,
which may be quite a while after you have sold your code (and cashed
the check).
Also, since your application will be about ten- to a hundredfold slower than a compiled version, you may profitably hook up with a
friend selling the newest and fastest 128-bit hardware with
more than 16GB of RAM or so, so that your customer will actually
be able to run your 'application' with tolerable performance.
At times it will still feel slow though, since the average
interpreter has the habit of allowing your app to eat up all of
that memory, at which point it will get an out of memory hint
and will a process called garbage collecting, which will take
about a minute or two for 16GB.
Other advantage is that even if you write a proggie that is about
five lines you can convince the customer you've done major software
engineering by installing the colossal interpreter, 'optimized'
to do all things from serving secure HTTP pages through 3D graphics processing and UI functionality to scientific SIMD calculations.
To do all of this it also comes with about half a terabyte
of semi-documented 'libraries'without which your program will
utterly fail irrespective of its requirements, and do so with
incomprehensible error messages that are fully out of your control.
If you make sure that your customer gets face-to-face with these
messages a number of times early on in the lifecycle it may even
land you a support contract. Thus all of this should be
considered beneficial to the engineer.

But perhaps the best part of an interpreted language is that if your
customer notices your app's lousy performance you can always
blame it on the interpreter. In fact you can probably blame the
stupidest of your programming errors on the interpreter. And then
the real fun starts. You mutter "yes but PERLTHON 98.3 is now out,
and it is free". Your customer will be fascinated.

Not for long because he will be forced to fork over a whole lot
more money on you rewriting your application after he accidentally
agrees to upgrade his system to this 'new, better' interpreter.
This without you having to add any new functionality whatsoever!
Rewriting each time some unknown, outside force decides to release a
new 'sorta backwards compatible' interpreter is yet another bigtime
advantage of the interpreted language to the software engineer
in search of cash.
If you haven't screwed up too badly earlier on in the product
cycle (ALWAYS blame 'the interpreter', never yourself!) you can
really make big bucks during this stage.

Readability, intelligibility and maintainability are key words
for any sofware project. The three words conspire to keep a sofware
engineer out of a higly paid and irreplacable position.
This brings me to free-form languages. They are known to allow you
to create programs that are virtually meaningless to anybody but
yourself - if you have a photographic memory - and should
considered as prime choices for any engineer trying to secure
future employment. Some may construe this to mean that I prefer
PERL over Python. While I do agree that PERL has a plethora of
built-in features to allow even unskilled engineers to craft
absolutely unreadable code, I see no reason why you could
not create similarly unreadable code with Python! My advise to
you is: apply yourself, be creative and you may be surpised.
Remember that the Python code may well be slower, too!

For big projects with many tens of thousands of lines of code only
the best structured object-oriented languages will lead to a
manageable project. Thus, for such projects Python or PERL are both
excellent candidates to maximize cost and man-power required.
Allow me to introduce yet another option though. You may have heard
of COBOL. Back in the sixties I did some punchcard programming
and was forced to look at COBOL. I was not impressed at the time.
You could create a working program with just a dozen punchcards.
However time has passed.
We are 2005 today. We can now have all the disadvantages of COBOL
without any of the benefits. Try interpreted COBOL. You will fill
half a moderate-sized harddisk with just the libraries. With
COBOL, as with Python, you can enter keystrokes as fast as
you can type them - just make sure that you are not forced
to debug them. Alternatively, an arcane sequence of rarely
executed if-then-else statements will allow you to get away
with an almost limitless quantity of erroneous code, an especially
attractive characteristic for those paid by lines of code written.

THE great advantage of COBOL is that is a brand name. Your client
will have heard of it. Just like Coca Cola, it may have a bad taste
but it rings a bell. Quite unlike Python which sounds as if it
could strangle, or at least bite, a prospective client later on
during the product lifecyle. Just ask your client, I suggest COBOL
for this, but if would you rather have me implement this in PYTHON...
Ten-to one he will agree to let you do it in COBOL.

The kicker here is that some engineer here or there might still be
interested to look into Perl or Forth or LISP or Python, but
there ain't a soul in the world looking forward to doing some
COBOL. Meaning that you will be quite sure of prolonged employment
if you convince somebody to implement anything critical in COBOL.

Ask for very little money up-front. Your customer is bound to come
back to you. Do it in interpreted COBOL and your pay will go
through the roof!

Conclusion.

I applaud Eric Raymond on his article. When it comes to writing
interpreted and unmaintainable code, Python like PERL has lot
going for it. Now with Python we have the choice.
But when it comes to get money off of prospective customers I
think you will soon realize the value of Brand Names!
IMHO Object Oriented Interpreted COBOL is the way forward.

Thank you.

mrcheeks · 05-04-2005, 02:19 PM

*i would use java most of the time because it is easy to build gui, web or console applications with it. The major inconvenient is the speed(see azureus or limewire).

*My second choice would be python because it is portable and easy. I would use wxpython for gui programming, you can do cgi in python too.

* for maximum performance(speed) and very complex operations with maximum control, i would use C or C++

* for text processing i would use perl. With other languages it sometimes takes 50 lines more do achieve the same goal in perl.

I tend use the most the language i can quickly develop with and which allows me to build gui, web and console applications. When they are lots of criterias and select the language unless i am compelled to use java.

jlliagre · 05-04-2005, 03:59 PM

I'm primarily using java, which is simply fast and brilliant with its 5.0 version, I use C for low level, O/S dependant code, javascript for bringing life to web pages, and finally korn shell and bits of awk for general purpose scripts.
I consider today that all other programming languages are, for me, a waste of time.
I had quite a long time ago some interest with basic, assembler, and smalltalk though.

dosnlinux · 05-05-2005, 05:05 PM

Java was the first high level language I learned, (hows that for backward) and I know what the guy in the python article was talking about when he said interpreted languages are resource intensive (if you thought KDE and GNOME were heavy weights imagine Suns project Looking glass http://www.sun.com/software/looking_glass/index.xml)

That Python article was what made me want to try and learn python, but then I found an article on Ruby that made Python seam like a very unappealing language, but I think I'll still learn python

dosnlinux · 05-05-2005, 05:17 PM

Features of Ruby

* Ruby has simple syntax, partially inspired by Eiffel and Ada.
* Ruby has exception handling features, like Java or Python, to make it easy to handle errors.
* Ruby's operators are syntax sugar for the methods. You can redefine them easily.
* Ruby is a complete, full, pure object oriented language: OOL. This means all data in Ruby is an object, in the sense of Smalltalk: no exceptions. Example: In Ruby, the number 1 is an instance of class Fixnum.
* Ruby's OO is carefully designed to be both complete and open for improvements. Example: Ruby has the ability to add methods to a class, or even to an instance during runtime. So, if needed, an instance of one class *can* behave differently from other instances of the same class.
* Ruby features single inheritance only, *on purpose*. But Ruby knows the concept of modules (called Categories in Objective-C). Modules are collections of methods. Every class can import a module and so gets all its methods for free. Some of us think that this is a much clearer way than multiple inheritance, which is complex, and not used very often compared with single inheritance (don't count C++ here, as it has often no other choice due to strong type checking!).
* Ruby features true closures. Not just unnamed function, but with present variable bindings.
* Ruby features blocks in its syntax (code surrounded by '{' ... '}' or 'do' ... 'end'). These blocks can be passed to methods, or converted into closures.
* Ruby features a true mark-and-sweep garbage collector. It works with all Ruby objects. You don't have to care about maintaining reference counts in extension libraries. This is better for your health. ;-)
* Writing C extensions in Ruby is easier than in Perl or Python, due partly to the garbage collector, and partly to the fine extension API. SWIG interface is also available.
* Integers in Ruby can (and should) be used without counting their internal representation. There *are* small integers (instances of class Fixnum) and large integers (Bignum), but you need not worry over which one is used currently. If a value is small enough, an integer is a Fixnum, otherwise it is a Bignum. Conversion occurs automatically.
* Ruby needs no variable declarations. It uses simple naming conventions to denote the scope of variables. Examples: simple 'var' = local variable, '@var' = instance variable, '$var' = global variable. So it is also not necessary to use a tiresome 'self.' prepended to every instance member.
* Ruby can load extension libraries dynamically if an OS allows.
* Ruby features OS independent threading. Thus, for all platforms on which Ruby runs, you also have multithreading, regardless of if the OS supports it or not, even on MS-DOS! ;-)
* Ruby is highly portable: it is developed mostly on Linux, but works on many types of UNIX, DOS, Windows 95/98/Me/NT/2000/XP, MacOS, BeOS, OS/2, etc.

jlliagre · 05-05-2005, 06:23 PM

Quote:

interpreted languages are resource intensive (if you thought KDE and GNOME were heavy weights imagine Suns project Looking glass

Looking Glass was reacting pretty fast last time I saw a demo, not sure if it really eats more resources than KDE or gnome.
Also, I disagree with both the point interpreted languages are resource intensive (that may or may not be the case, and depends a lot on the interpreter runtime) and the point java is itself an interpreted language. This used to be partly true in the first releases (just partly because javac means java compiler which is not what one would expect for an interpreted language), but interpreted can no more be applied to the more recent JVMs, with which intermediary bytecode is compiled on the fly to CPU specific code with native performance.