in fact none of the listed things make a language good or bad... It's how all (or some of) those things are used together with a lot of other factors that makes or breaks a language.

For example, C has no OO, MI, AM, namespace, MT, exceptions, RE, yet it's generally considered a pretty good language (of course some of those have been added by third party tools). The same is true for Pascal, Modula, Fortran, Cobol, PL/1, and a host of others.

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus

One of my favorite languages is REXX. It's a bit dated but I think it's still on every IBM OS, and the Commodore Amiga. My reasons are beautiful self consistency (with a few well documented and logical exceptions), an easy, natural syntax and a very clever separation / integration of the language and the environment (OS or application.) It's also very small.

The inventor Mike Cowlishaw and the way he worked were very important to all this. He wrote the complete langauge spec and then gathered a bunch of smart friends around to write hundreds of programs and run them with pencil & paper. Through several iterations of this they refined the language and hammered out things that were inconvenient or difficult.

Finally he wrote an interpreter. By putting that off until last, he assured the implementation had almost no influence on the design of the language. Cowlishaw says that the syntax makes the language user's life pleasant and the job of writing an interpreter very difficult (and a full compiler impossible.) But he only had to write the interpreter once for thousands of us to write programs. A nice trade-off.

Ease of use, extensibility and expressiveness make a language great. Various features and abilities make them appropriate for different jobs.

But as with pop culture: quality != popularity. There's a neat paper that says C, a mediocre language design at best, succeeded not on the merits of the language but because it was very easy to write or port a compiler which enabled it to spread like a disease.

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi

here's my theorem: the quality of a language is inversely proportionate to the number of total tip words published on how to avoid shooting yourself in the foot (divided by the total number of words published on the subject, so as to factor out language popularity).

One of my favorite languages is REXX. It's a bit dated but I think it's still on every IBM OS, and the Commodore Amiga. My reasons are beautiful self consistency (with a few well documented and logical exceptions), an easy, natural syntax and a very clever separation / integration of the language and the environment (OS or application.) It's also very small.

ANSI C is one of my favorite languages for many of the same reasons. It's quite small, clean, and exceptionally self consistent, making it easy to remember the entire language without looking things up. Probably the only real glitch is that the bitwise logical operators should have a higher precedence (something that unfortunately was perpetuated in Java).

There's a neat paper that says C, a mediocre language design at best, succeeded not on the merits of the language but because it was very easy to write or port a compiler which enabled it to spread like a disease.

Sounds like sour grapes to me. C outcompeted contemporary languages like Fortran, Basic, and Pascal that were comparably widely available and easy to port. This can largely be attributable to C's cleaner syntax.

More recently, C++ and Java haven't had much difficulty displacing C where it makes sense to use those more recent languages.

Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791

posted Jan 21, 2005 12:56:00

0

Another metric I apply purely by eye is how much housekeeping code is required to do a bit of business code. I tell my team I want every line of code to sing of insurance and customer service. Any bit-twiddling is a minus. That reveals my strong bias - high level business applications, not operating systems or massive number crunching. I don't have much hands-on with C and C++ but they seemed to do poorly on that scale.

I find I can have "geek fun" and be productive with nearly any language once I know it well enough. I was darned proud of my Turbo Pascal and Clipper programs! So I won't try to tell folks they shouldn't like C/C++ and have a good time using it. More power to ya. But I might try to tell you that if you put the same effort into some other language you might have more fun and productivity and produce more business value

Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 799

5

posted Jan 21, 2005 13:39:00

0

Originally posted by Ilja Preuss: If it's similar to Smalltalk, it can't be too bad.

I don't think you can get more elegant than Smalltalk. The language designers took great care in putting things together to make life easier for developers. For example, Dan Ingalls admitted to me that they consciously chose "cryptics" that didn't require shift-keystroke combinations (for example, they chose to use square brackets [ ] over curly braces { }).

Smalltalk is absolutely lovely. My short stint with it, porting an app from another language for a proof of concept, was a real eye opener. The syntax and the concepts were a total inversion of what I thought I knew. Nine or ten years later now I can't even read it, but I hope I retained some of the goodness.

Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332

2

posted Jan 21, 2005 16:48:00

0

In answer to the original question:

- for general purpose programming, having subroutines or functions makes a language better. In studies done a couple decades ago, users of all "high level" languages were approximately equal in productivity, but they all had higher productivity than assembly language programmers.

- there is growing empirical evidence that for nonrealtime applications, garbage collection makes languages better. While there haven't been formal studies, a many people report productivity improvements of up to a factor of two using languages with garbage collection.

I don't have empirical evidence for the following, but I strongly suspect they are true:

- I think that user defined data structures are almost as important an element for high level languages as subroutines/function calls. However, I don't have empirical evidence for this.

- I think that for large projects (over 100,000 lines), a language with some kind of namespace support is better. These can be Ada packages, C++ namespaces or classes, Java packages or classes, or a variety of other things in recent languages.

And, my personal opinions:

- I think that languages that use punctuation rather than keywords for grouping are clearer and easier to read. I think this is the primary reason why C/C++/Java/MSVC++ won out over Pascal/Ada/Fortran/Basic.

- I think that most other things that people think make languages better don't actually make the languages objectively better; they actually just make those languages better for those people, because that's what they are used to. [ January 21, 2005: Message edited by: Warren Dew ]

What makes a good language? mmmmmm 1. Big libray 2. Simple syntax 2. Flexability, The ability to hide unnecessoryy detail when required. 3. Good use of abstration. The ability to hide the underlaying implementation away from the languages syntax so both can change independantly. Python does this very wall. Python can take advantage of lower level languges like C++ and Java. So if the guys at sun microsystems develope an amazingly fast and flexible version of java, the java implementation of Python (Jython) instantly takes advantage of it. A good GUI would be a very highlevel and basically use the same abstration. PythonCards to my knowledge can implement many GUI tookits so whatever one become successful PythonCards alread takes advantage of it.

Gerald Davis
Ranch Hand

Joined: May 15, 2002
Posts: 872

posted Jan 25, 2005 06:09:00

0

Sometimes I wish that a function implemented as this def add(x1,x2) return x1+x2

Although some may have found that "multiple inheritance is not necessarily a good thing", I agree with Ashik's "* Multiple Inheritance, Multiple Implementation Inheritance" criterion for what makes a language better.

After working in Java for awhile and at first thinking that multiple inheritance was mostly trouble, I've found that there are some things you can't do (at least elegantly) without it. Java's version of multiple inheritance by interface just isn't enough.