It struck me, that there does not seem to be a single language that
serves many purposes, suitable for
- business
- databases
- numerical / statistical applications
- textual apps
- web / publishing
- multimedia

C++ comes close, as does Java and C#. C++ seems more suited to
technical engineering and others are suited to scripting / publishing.
I may be wrong, but what else is there ?

imutate (AT) hotmail (DOT) co.uk writes:

What else? Have a look:

http://en.wikipedia.org/wiki/List_of...world_programs
http://en.wikipedia.org/wiki/Compari...ming_languages

For your desires, mostly mid to high(er) level applications, I would
suggest to take a look at the Lisp family (like Common Lisp), ML
family (like Ocaml), Smalltalk (e.g. Squeak), Ruby, Python, Haskell,
Mozart/Oz. Of course there are lot's of other really nice languages
out there and the above list is in random order.

Maybe for high performance number crunshing Ruby and Python are not
the best choices (not too high speed interpreted scripting languages,
but with not too bad C interfaces, so maybe performance is no
problem).

My personal favorites are Common Lisp and Python.

--
Stefan.

imutate (AT) hotmail (DOT) co.uk wrote:
PL/I and/or Cobol perhaps?


:-)
Jan M. Nelken

imutate (AT) hotmail (DOT) co.uk wrote:
The real question is:
Why would you want only one language?

Programming languages are tools of the trade. Which ONE tool would you
pick to build a house? Hammer? Saw? Pipe Wrench? other? See what I
mean? If you need multiple tools to build something simple like a
house, why limit yourself to just one tool (programming language) in
building a software application?

That said, I might choose ADA if I was stuck on a desert island and
could only have one programming language.
Ed

Ed Prochak wrote:
Because it would be integrated.

Not really, most languages have objects and functions.

Say you have C / C++ and SQL, this is a common combination. Then
typically there is a layer between the two an API, this is OK but it
makes for bloat. Yes it does limit you to what the API can do. If it
is seemless then you end up with say embedded strings in the C++ which
gets messy or a huge manual basically copying the SQL language. OK
you cannot compress the functionality of two languages into one without
loosing something. Point taken.

"Greg" <imutate (AT) hotmail (DOT) co.uk> writes:

I think in this case Common Lisp or Scheme would be your only choice
(which other language have the ability to seemlessly change/extend
their own syntax). But what do you mean with "integrated"?

What about first class functions, multiple inheritance, multiple
dispatch, closures, anonymous functions, (static) type inference or
dynamic type system, real macros (in the Common Lisp sense, not this C
like crap), unification, logic variables, concurrency based on data
flow, meta object protocol, introspection, available libraries,...

There is more to programming than just putting a class with some
methods together.

But maybe the worst? Take a look at Common Lisp and CL-SQL
(AllegroCache may be interesting also) or Haskell and HaskellDB. I
think these are really illuminating.

--
Stefan.

Greg wrote:
Back in the late 70's and early 80's when personal computers first came
out, there werre many attempts to write the ONE DO ALL program that
would include everything. It sounds to me like you want the ONE DO ALL
language. Sorry, but there is no such thing. If you stick to only MS
windows platforms, you might come close with VB.
So? You said you were interested in one language that does it all. If
such a language exists, it likely does not follow common paradigms.

Just consider how you might have to write your program in some
glorified do all language. Would it be OO like java, procedural like
C, or nonprocedural like SQL? whichever paradigm style it is, there
will be cases where you would just like to write parrt of your program
in another style.

And here's the final clincher: what do you do about the lowest level
programming? How would assembler fit into that do all language? Which
assembler? x86? Sparc? PowerPC? 8051? PIC?

I would bet most bloat is at the application level, not due to linking
in other libraries.

We are all here to learn.
Ed

Most BASICs are not close to the metal, so not suited to numerical
computing or electronics eng. C++ or C# is more like what you talking
about.

Ooops, no you are wrong, there are stored procedures in SQL, I don't
know if it is part of the standards but it is part of many of the
commercial databases. Also stored procedures can be nested and called
from the "non procedural" parts of SQL.
http://en.wikipedia.org/wiki/Stored_procedure

I mean all. Taking a fuzzy view you basically have full on OO and
various abstractions at one end and 3GL, BASIC and scripting like
languages at the other. The problem is you don't need all that algebra
and abstraction if you are scripting. On the other hand it can be
faster and more bug free if you mix the two, it is just that you need
to pass the scripted language to another compiler or interpreter.

Yes, but maybe it just looks that way, if an app has lots of repetition
it is bloated, it if has efficient wrappers and generic functions it
looks bloated (and might as well be) because it has layers.

There you go, you learnt something about SQL

Stefan Nobis wrote:
OK, these things are good and make for neat and less code. But they
are in the compiler, syntax and are just computations / algebraic. You
could write a prog. with equivalent of inheritance using C or Pascal.
A good procedural programmer does not really need them, they can split
processes and storage into manageble chunks those are the "real
macros". They can do the graph theory in their heads (or program it)
and don't need a compiler to force them to use rules. It is the less
talented programmer that will benefit more from these things. More
bloat in the compiler and libraries means more to learn and remember.


Hmmm, but these abstact data structures you are talking about are made
that way.

Why, it is practical for business and engineering apps.

Macros make it dificult to read.

But not intuitive. I'm not convinced.

I definitely disagree with that one.

The advantage of a sproc is that it can serve 4
- database developer
- database administrator DBA
- developer
- end user

You do need a good debugging tool if it gets too big, but then maybe in
that case it should be a server program or prototyped as a server
program. But generally because it is part of the database it is easier
to optimise.