Slashdot Mirror

Not to be a fanboy, but: a lot of this stuff makes me think "Ah yes, that's why we have D".

We dream of cleaning up the mess

Yep. D is pleasantly free of the mess.

a direct mapping to hardware plus zero-overhead abstraction

Here, D and C++ differ somewhat. D isn't totally unusable without its trusty garbage-collector, but it's not something that's often done.

Being a fan of range/container algorithms

Andrei Alexandrescu agrees. See also these.

Ranges are a standard thing in D.

I think we should think more about isolating unsafe code in a program than to eliminate it. Putting the necessary unsafe code into a different language limits our control of it, limits what can be communicated to it, and typically imposes overheads.

Precisely why D has a safe subset and the @safe and @trusted attributes.

Of course, D doesn't have compatibility with old C++ code, or even with old D code (that's why there's the ancient-but-stable D 1.0 language).

IIRC it was a matter of whether the executable was compiled using the "tiny" memory model or any other; COM programs were the ones compiled using "tiny". Table 7-1 on this page seems to confirm my recollection.

FORTRAN IV of all things: the mind boggles!

If I had the time and the brain power, I'd probably try writing an OS kernel in D

D has had contracts since the get-go. Sometimes I wonder if it would be a better world if all the C and C++ out there was *magically* reimplemented into a better language.

This D May also help prevent all kinds of problems.

I'm a C/C++ developer (mainly C) and I enjoy it. I don't enjoy C++, but I'm paid to use it, so use it I do.

I've been dabbling with scheme for fun. It's very different to C, C++ or any of the other languages you mention, but a couple of hours reading about it and playing with it will really open your mind and be a bit of fun.

By ignoring the .NET languages, you are obviously intelligent and discerning; you don't merely want to follow the heard into a boring, run-of-the-mill job. Good for you. 15 years ago I started to learn Linux when everyone was laughing at it (and me for using it) but I'm in a great position now.

The other language I'm about to try is D which was deliberately designed to address many of the shortcomings of C++. It's a lot simpler and much more pragmatic that C++, by the looks of it. For a start, it doesn't pretend to be backwards-compatible with C, bit it is ABI-compatible. It has a clean syntax, fast compile times and some interesting concepts borrowed from ruby and python.

Ruby is the scripting language I'll be looking at next. I learned PERL a while back for work, and it is a nightmare, but a very useful one. Ruby is much less of a nightmare and much better than PERL at what PERL was intended (notice I didn't say designed) for.

Whatever language you choose next, pick an interesting one... How about creating your own for a challenge?

Finding the appropriate function in modern IDEs is as simple as...

Therein lies the rub.

The point of high-level languages is to make ideas expressible clearly and simply so that the human can understand them and so that the compiler can translate them into efficient machine code.

That we need these huge, complicated, clever IDEs to be productive with many popular languages is very telling.

I've managed to get this far without an IDE. I write C every day at work, shell scripts, Makefiles and the occasional bit of C++. All I use is vim and the GNU command-line utilities. Luckily the C++ that I encounter is small enough (a few thousand lines of embedded stuff) that I don't need special tools to navigate through it. I can simply open a few files and read them.

We use CPPUNIT for unit testing, and again I don't need an IDE. I just read the header files.

Other people whose projects are completely in C++ struggle with Eclipse and SlickEdit.

I love coding. In own time I like reading about other languages. I've dabbled in scheme, Java and ruby, and one day I'll learn them properly. D looks very promising. I must try it out. C++, like PERL, is a necessary evil in our profession and I only do it when I'm paid.

Please turn in your programmer card. You've fallen for the deception that a language specification is the same thing as an execution environment, aka virtual machine, or -- even worse! -- an entire software platform. How did you become confused? Because common practice is to use Java as a cover-all term to mean Java the language, Java the JVM, and Java the platform. A programming language defines semantics, NOT the governing machine. A standard can include library details, but that is NOT the same as the core language itself.

Android uses Java the language, the Android libraries (a DERIVATIVE of the Java libraries), the Dalvik virtual machine, which together form the Android platform. Why are the libraries derivative? Because they are based on the Java class libraries, not in completeness, and the behavior of the identical libraries are not guaranteed to be the same.

Copying standard library specifications is not something new in the programming world. Look at D, which blatantly copies the C++ standard library. Why did D authors make that choice? Because the SC++L cannot feasibly be topped by recreating it; only by extending and improving on it can it be bettered. The Java class libraries were taken by Google because they are familiar to many thousands of programmers across the world, and because they have a long history of reliability and general design quality.

A simple example may help to dispel the confusion. Let's build a compiler. I want to base it on C#. The goal is to produce bytecode that runs on my proprietary VM. Technically, we could make it produce Python/Java bytecode, or (perhaps) native binaries even. After I'm done, the syntax it compiles is exact and conforming to C#, and even behaves the same way. I might take a few .NET libraries and reimplement them to work with my compiler. Not all of .NET though; it's simply too large. The compiler successfully compiles pure C# code, and a varying amount of .NET-using C# code. See the resemblance to Dalvik? My compiler and VM are not .NET-based, and have zip to do with the CLR. It's a 100%-valid C# compiler, but is unrelated to .NET.

Why is the above example easier to understand? Because Microsoft didn't name all its technologies the same: C# was never dubbed "the .NET programming language."

So what? You ever see D's std.* library? It's a mirror of the C++ Standard Library and STL. Frankly, any new language invented today which does not use one of the STL, .NET, or Java libraries should not and probably will not be adopted. These are the de-facto programming libraries which cannot capably be topped without decades of new alternative focus.

I don't know how many times this must be pointed out, but language and official library specifications do NOT compose a software platform, any more than C++ is an integral part to Microsoft Windows.

Or the D Programming Language. Go looks nice for multithreaded apps, but it still lacks an awful lot of basic things, like exceptions and templates.

Why is noone asking to examine the C programming language, to adapt it to modern programming processes and methods?

They have, and it's called the D Programming Language. And it sucks.

Something like this? http://www.digitalmars.com/d/

Unfortunately that's not really true. A const method in c++ can still tweak state it reaches through internal pointers. Const is actually pretty useless in C++ .... it doesn't help with optimization nor multi-threading. A real const system is what you can find in the D2 language.

All IMNSHO (I don't know JS, but I do know a lot of other languages)

• C# is a bad Java clone (tainted by MS)
• Java is a dumbed down version of C++
• C++ tries to be a better C (and largely fails)
• C is 30 years old, and shows it

How does JS compare to a good, modern language - like Python or D?

Can some expert compare Go with the D programming language?. Looks like D already took what's good in C and C++ and now it's a stable and damn fast language.

Have you considered the D Programming language?

From http://www.digitalmars.com/d/ "D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability.

The D language is statically typed and compiles directly to machine code. It's multiparadigm, supporting many programming styles: imperative, object oriented, and metaprogramming. It's a member of the C syntax family, and its appearance is very similar to that of C++. "

I agree, I've done both a lot of shell scripts, web scripts and compiled languages programming; it all comes down to what your goal is, there's no perfect combination of languages for every scenario.

Personally I prefer having a core program written in a compiled language (C++, D), with a bundled library for scripting (LUA, Python) for I do mostly cross-platform programming these days.

However, when doing system admin tasks and automation, nothing beats shell scripts, it takes too much time to write and maintain compiled executables for simple tasks.

On a side note: I also recently found out about rdmd a few days ago, you might want to add that to your shell's arsenal ;)

D has an opIndexAssign operator, which is "[]=". Fortunately, there is progress; an opIndexLvalue operator has been accepted into D2. However, opIndex would be sufficient if it were possible to define the return value itself as an lvalue.

It is also possible to return by reference in D2.

But the redeeming value of the "[]=" operator is that it gives you a simple way to have array-like index assignment without breaking encapsulation. If you return a reference to element 5 then you have no way to control what the caller does with that reference after that. The caller can go on to change the value of it willy nilly as he pleases. This is very annoying if you want to perform some action as a reaction to the value of an element changing. It's exactly the same argument as for why it's generally better to getters and setters to provide member variable access, rather than just making the member public.

A language can still do both... D for example. It can be easy like java (with a garbage collector), if you want you can still allocate/free memory yourself, use pointers, inline assembly, or you can go wild using templates and string mixins everywhere and write ten times less code.

It's almost the only thing the article mentions, you can't go more than three paragraphs before you get "MS sucks the tied D with MSSQL server". I would be interested in knowing what D is. Is there someone with a good article about M or D if that's what it is?

fanboy central here we come..

Hey,
It originated as a re-engineering of C++, but even though it is predominantly influenced by that language, it is not a variant of C++. D has redesigned some C++ features and has been influenced by concepts used in other programming languages, such as Java, C# and Eiffel. A stable version, 1.0, was released on January 2, 2007.
Here's a little explanation taken from wikepedia http://en.wikipedia.org/wiki/D_programming_language more info can be found on http://www.digitalmars.com/d Good luck!

http://www.digitalmars.com/d/

Oh wait, *favorite* programming language? Never mind.

If you think "modern" languages are more expressive, then give "modern" C++ a try (insert comment about recent compilers here).

If I were going to ditch my preferred more expressive language, why wouldn't I just go to something like D?

Ada has two main problems (probably linked). The lack of garbage collection and the inconvenience of using variable length strings. In most other respects I rate it a superior language. (Not the best, but considerably better than C++.)

C and C++ suffer from pointers and macros. They make "clever" code unmaintainable. And that the default mechanism for addressing an array should be via a pointer is atrocious! (The language doesn't require it, but several early dialects severely penalized the use of array indexing. So a history developed.) That said, with sufficient discipline it's now quite possible to write good maintainable code in C and C++. But, like Ada, it doesn't have garbage collection. (Wait for C++ 2010?) Still, the wild use of pointers and macros are much worse than just lacking a garbage collector.

Java is a language I keep coming back to and running away screaming from. It's an excellent basic language design, but it's LIBRARIES!!! They're extensive and many of them are nice, but other have vile user interfaces. And needing a chain of three libraries, each declared with a separate variable, to write a file in the "proper manner", UGH!!

Eiffel is a language I had great hopes for. Had. It had excellent mechanisms for dealing with multiple inheritance. It was clean, elegant, sweet. It devolved into only two variants. One by the original language designer, who wanted to maintain sole authorship of the design, and the other by a group at a French University, who declared that their version was experimental, and came out with a new design that broke nearly all existing libraries (and there weren't that many). So the language is not progressing well. I may be less functional now than it was a decade ago. (I used to use SmallEiffel, which has been renamed SmartEiffel and made incompatible.)

Python and Ruby are rather nice, but slow compared to the other languages that I been discussing. (In fact they're slow compared to Perl.)

Currently I use Python if speed isn't needed, and I'm keeping an eye on D (Digital Mars D) for when I need speed. It's not quite there yet (libraries more than any other reason), but if it can avoid the Java-ization of its libraries, then it looks like a winner.

Sounds like you want D.

Wow, it's not often I strongly criticise articles around here, but that was total garbage.

For the smart ones that didn't RTFA, here's a quick summary:

• I like Erlang.
• Big companies like Google and Amazon make things fast by using concurrency.
• Erlang supports (one type of) concurrency.
• Thus Google and Amazon are [probably] using Erlang.
• Thus everyone should learn Erlang.

For the record, I work for Google and we don't use Erlang anywhere in the codebase. Google Gears restricts you to message passing between threads because JavaScript interpreters are not thread-safe, so it's the only way that can work. Visual Basic threading works the same way for similar reasons. It's not because eliminating shared state is somehow noble and pure, regardless of what the article would have you believe, and in fact systems like BigTable use both shared-state concurrency and message passing based concurrency.

The article says this:

Architects (but also university-professors for that matter) still think they can build current and future industrial-grade and internet-grade systems with the same technologies as they did 10-15 years ago.

But in fact the Google search engine, which is one of the larger "industrial-grade, internet-grade" systems I know of, is written entirely in C++. A language which is much the same as it was 10-15 years ago. Thus the central point of his argument seems flawed to me.

Seeing as the article is merely an advert for Erlang, I'll engage in some advocacy myself. If you have an interest in programming languages, feel free to check out Erlang, but be aware that such languages are taking options away from you, not giving you more. A multi-paradigm language like version two of D is a better way to go imho - it supports primitives needed to write in a functional style like transitive invariance, as well as a simple lambda syntax, easy closures and first class support for lazyness.

However it also compiles down to self-contained native code in an intuitive way, or at least, a way that's intuitive to the 99.9% of programmers used to imperative languages, unlike Erlang or Haskell. It provides garbage collection but doesn't force you to use it, unlike Java. It doesn't rely on a VM or JIT, unlike C#. It provides some measure of C and C++ interopability, unlike most other languages. And it has lots of time-saving and safety-enhancing features done in a clean way too.

For the record, the first C++ compiler that compiled directly to native code was Zortech C++ (which beget Symantec C++, which beget Digital Mars C++). Its author, Walter Bright, is the guy behind D programming language.

I wonder how it compares to Digital Mars' implementation.

I really think you should spend some time looking at the reasoning behind DBC. Reading your comments here makes me suspect that you're already, like me, thinking much in the lines of DBC when you're "unit-testing".

It seems as you, like me, acknowledge that any real-world application tends to be by far too complex to realistically except to be able to fully use unit-tests of all units completely isolated. Instead, you and I (different from the usual definition of a unit in unit-testing) consider a unit to be a hierarchial element of the code, ranging from the system as a whole, including all processes, threads, protocols etc, down to the really simple method such as addTwoInts(a,b).

DBC and unit-tests are closely related, but they are a big fundamental difference.
  * Unit-testing as a methodology tries to impose a certain kind of modularity and isolation on your code. I.e. mocking away everything else than the fundamental unit you're working on requires mostly all code to be implemented through interfaces in a typed language.
  * DBC does not really impose any such requirements on your code (other than to design sensibly and actually define contracts). It relates much more on how your code is used in YOUR application, and defining how it may be used in someone elses. In DBC you also spend some time writing interface-specifications, but here you don't do it for the purpose of mocking the object later, you do it as a part of defining the interface of the unit which can later serve both for automatically driven testing, input validation, and API-documentation.

An example:
Two fundamental units A and B, where B depends on A. Unit-testing suggests mocking away A for testing B, while DBC don't care, and considers testing of A to be a part of the testing of B.

In practice, the big fundamental difference between unit-testing and DBC is that DBC does not make a big difference between unit-testing and all other testing, similarily to what I'm reading between the lines in your posts.

In DBC, you may write a few unit-tests for them both if there's anything in particular you want to constantly verify when building, but the focus of DBC is performing the tests directly in YOUR application, with higly granular verification to easily detect and track down problems.

Am I making any sense? If not, please go ahead and read http://www.digitalmars.com/d/2.0/dbc.html. It's a bit shorter, and maybe more clear. (D-specific but it gives some idea of the concept.)

I'd _like_ to stop using C++, frankly, but I don't seem to have a choice. A lot of my work depends on real-time capability, the kind of speed that is still only really possible on natively compiled languages that don't do dynamic typing.

I don't even mean hardcore real-time mechanical nano-second control of knife-wielding deathbots, just simple, This Must Run As Fast or Faster Than The Rate At Which It Will Be Converted To Analog. Python and Java still don't replace C in this area. (Mainly audio, video, and high-speed mechanical control.) And when it gets complex and you need to get into object oriented models to simplify the programming, there is unfortunately no real alternative other than C++. Combine this with that fact that there are a bunch of great libraries out there written in C++ that would be very difficult to replace, and you're stuck with it.

(I sort of oscillate between liking C++ and hating it, but I'm preferring straight C more and more these days. But like I said, I don't always have the luxury of choice, depending on what libraries I need to use.)

All these other languages mentioned (Java, Python, Ruby, PHP, Perl, etc) do not compile to native code, and all do dynamic memory management. Hell, that's exactly what makes them *good*. But unfortunately they're not so good for real-time tasks.

For real-time, you need deterministic memory management, and native speed. I've been looking at some other languages that compile to native code these days, like D, or Vala, but I haven't really decided yet whether I can start using them on serious projects.

I'd really like to learn more about functional programming in this area, too, but there seem to be very few functional languages that are designed for real-time. FAUST is one, but it's only for audio.

Anyone know any other good natively-compiled languages that actually have well-implemented modern features?

I wish it were possible to have a compiled version of Python, for example, but there are many dynamic features it depends on. (Some stuff could be done in Pyrex, which is a pretty cool little project, but so far I've only used it to make bindings to C libraries.)

D also offers syntax and ease of writing comparable to C#/Java, but is faster, doesn't require VM and compiles to native code linkable with C.

I thought C++ developers were aware of the D Language: http://www.digitalmars.com/d/

BCPL -> B -> C -> C++ -> D

I wish D becomes more popular. It allows the low level efficient coding without the craps of C++. it also borrow and improve many ideas found in java/C# such as javadoc-style documentation.

And was written by a certain "Walter Bright" :-)

That said, it is a very good language, and deserves to be in the list.

http://www.digitalmars.com/d/

And everybody has fogotten D? The most versatile an powerful of all languages?
http://www.digitalmars.com/d/

On the other hand, I is also important that the language of my choice should have a wondeful IDE with an integrated debugger, wonderful and tested libraries with nice GUIs, and a wonderful Linux-Windows-Mac interoperability.

I do not believe there is anything malicious that has caused this inefficiency to rise. The cost of developing software means that slow and bloaty is what we end up producing as software engineers. It just makes more sense economically.

I hope that in the future, with capped per-core CPU speeds, we will see a renaissance in tight programming. Perhaps new languages will spring up that offer the efficiency of C++, but with the coding efficiency of ECMAScript4 or even C#. D is one such language, and there may be many more to come.

We may also see much smarter compilers built on ideas like LLVM that will offer statically compiled languages some of the benefits of dynamically compiled VM code, just as taking advantage of specific architectures, and extensive inter-process analysis of code.

With many software problems becoming better understood, we could see much more extensive system libraries that offer the same features as say the .net environment. Cocoa and QT4 are already heading in this direction, with a really feature rich set of libraries, but also with the eye on cutting down memory usage and CPU cycles. In the future, we may see much more optimized shared library usage for system-level applications. This will lead to a snappier user experience. We won't need to have 100s of megs of shared libraries duplicating so much across so many apps.

I think massive parallelism in user applications will never happen without a complete rethink from the OS up, or a new application development paradigm. Furthermore, most developers simply aren't up to writing thread-safe code - it's very hard to get right, and often you don't gain that much for standard applications. That's because of the types of problems being solved in typical applications. We're having a hard enough time writing single threaded apps regardless.

I admire the managed code empire that M$ has built into vista, but ultimately we may want better performance than this heavy-weight approach can offer. Both OS X and KDE are staying away from the managed code "heaven" for the time being. I believe that apple will find a way to make future versions of Objective-C have most of the benefits that managed code can offer, but also with extremely tight machine code.

Or you could maintain your commitment to Blutarsky-ism and slouch your way to D

Have a look at Clean (http://clean.cs.ru.nl/) for a use of pointers (internally) that makes for efficient execution. An interesting read concerning the subject is found here:

http://clean.cs.ru.nl/contents/Addison__Wesley_book/addison__wesley_book.html

Actual benchmarks to show the efficiency can be examined here (note the comparison is with C-versions of the same algorithms compiled on gcc):

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=clean&lang2=gcc

Here's Java 6 (server version) for comparison:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=gcc

You'll notice that differences are mainly in the memory footprint, already known to be attributable to the large number of libraries (classes) loaded into the vm at start-up, something the Clean runtime isn't quite as encumbered with:

(Java) http://java.sun.com/docs/books/performance/1st_edition/html/JPRAMFootprint.fm.html

So, the difference in speed is often-times negligible, and it's been shown that the memory footprint can be reduced to a size where you can run an embedded jvm in a mobile phone (really!), and rumour has it that someone even wrote an operating system in Java, but the memory footprint still seems the biggest culprit:

http://www.jnode.org/node/573

In other words, it's not Java - the language, but Java - the massive OO-framework, and JVM - the specific implementation, that's the problem. Even C++ or C with an OO-framework can be made into a large memory footprint, if you can believe it:

http://www.microsoft.com/windows/products/windowsvista/editions/systemrequirements.mspx

Then, of course, memory is cheap:

http://www.simmtester.com/page/memory/memprice.asp

But, the over-use of which, sometimes stays with us as itching bugs for too long:

http://blog.wired.com/monkeybites/2007/11/firefox-3-add-o.html

If memory serves me right (http://www.google.com), there's something to be said of the virtues of garbage-collection applied to systems programming:

http://www.digitalmars.com/d/

and the actual (memory and) time efficiency of such an attempt:

http://shootout.alioth.debian.org/gp4/d.php

But I could be wrong. After all, no-one in their right mind would ever attempt to write an operating system in something like, say, Lisp:

http://cbbrowne.com/info/lisposes.html

- let alone design an actual computer around it:

http://en.wikipedia.org/wiki/Lisp_machine

It simply wouldn't run. No, the skills of an engineer depend solely on the language he/she speaks, not on the abstract concepts he/she masters, applied to whatever tool he/she chooses to use/create.

That is why I propose we all forget about abstraction all-together, and revert to coding like this:

010101100001111010110101101101111101111...

But wait, that is itself an abstraction - Turing must have suffered from premature abstraculation. No, let's hear it for using copperwires instead of silicon, so we can attach some large, hand-

I would suggest being taught a programming language such as D, at least in addition. Although the transition from C/C++ to D can be painful, D contains many similarities with C/C++ such as speed, except it's much tidier and has many of the advantages of Java syntax whilst maintaining the power of C/C++ if necessary (optional pointers, optional manual garbage collection etc.).

Sooner or later, languages are going to evolve, and surely it's only a matter of time before something D-like is going to be used anyway. Might as well make the switch sooner rather than later.

I wish someone would develop a language with optional garbage collection and with proper destructors!

D:

http://www.digitalmars.com/d/

You're welcome.

The faster development time with C# is orthogonal to its running in a virtual machine. There are languages around that offer the best of both worlds -- I currently use the D programming language for this.

Granted, the gtk and wx bindings are simple interfaces to the C version of the library, but higher-level abstractions can be written on top of those.

In that case sounds like a possible use for the D programming language which also has GC (supposed to improve dynamic memory performance compared to declarative management) but throws away nasty multiple inheritance.

We're doing things in a reasonable amount of time these days that previously were possible only in an unreasonable amount of time, as far as 3D modeling and such.

I've heard that, in the early days of UNIX, computer time was expensive, so you could be wrong as long as you were fast. But these days, processor time is cheap, so you no longer have to be fast. Some people transfer this into automated verifications -- array bounds checking, for instance, or design-by-contract. Bounds checking is expensive for C/C++ primitive arrays, and not yet practical, but it's used efficiently in other languages.

I really think that good design practices interfere with efficiency in many cases. And I'm happy with that situation. I prefer stability to speed, but we're getting both, to some degree.

For me, the answer has become D http://www.digitalmars.com/d/index.html

Haskell is a wonderful language, but it's another completely different paradigm, it's not to replace C++.

D is, it's C++ done right.

C++ is a freak of programming languages. It has grown like cancer, much like HTML.
If you wanted to add OO features to C, I think a simplistic approach like Perl's would be better.

You could look into D or Python (or Ada, or possibly even C++...but I'm less sure about that). They all support the kind of overload that you want, with differing advantages and drawbacks. Except for speed, Python is the best choice. If you want speed, then of the languages that I know the best choices are D or Ada (and I prefer D).

N.B.: There's more than one D, so the particular one that I mean is: http://www.digitalmars.com/d/index.html

With Python you might get the speed that you need either via Pyrex or NumPy (or possibly it's now PyNumeric). This actually operates via calls to C libraries, but they get hidden by syntactic sugar.

D and Ada are type sensitive to varying degrees. (Ada tends to be verbosely fanatic about it.)

I'm not familiar with Mono, because I don't trust it not to have embedded MS IP of some sort (patents probably, if anything). It's probably safe enough...but I tend to be nervous. That's also why I won't have anything to do with Novell unless through an intermediate who has their own lawyers. Probably there's no MS IP ... but there's no way I would know.

And since I won't let MS products be installed, (Not since I read the last MS EULA!) I can't speak WRT C#.

Another possible choice is ObjectiveC or ObjectiveC++. That gives more flexibility at run time than C or C++ (well, unless you wriggle and turn a lot) with good compatibility. (C libraries are directly callable, and I believe that C++ libraries are as well.) I'm not sure that you could redefine the primitive operators over class operations...but I believe that you could. The major problem with ObjectiveC/C++ is that there doesn't seem to be any significant amount of tutorial material. Still, every legitimate c program is a legitimate ObjectiveC program, so you could learn slowly. And it transfers easily to the Mac. (I'm less sure how well it runs on MSWind.)

I didn't yet mention Ruby or Smalltalk. Both of them can do what you want (though the Smalltalk syntax is peculiar...and might be unacceptable). Unfortunately, Ruby is slower than Python, even though I like the language design better. Smalltalk comes in a variety of forms, but tends to be faster than pure Python code. Unfortunately, it's far easier to link to an external library from Python. Smalltalk tries to be a closed system. So I basically left both of these out of the discussion.

Then there's LISP and Scheme. A good LISP would be essentially as fast as C ... but I don't think you would find the syntax acceptable. So I left it to the end as well. I'm not sure about the speed of various Schemes, but it would have essentially the same syntax problem as LISP.

If interpreted Java is fast enough for you (you didn't mention speed as a consideration), then you should probably give Python a look-see. It's a bit slower when you're using pure Python code, but a lot of stuff is done via library calls, which are generally optimized C code...and thus quite fast.

Otherwise I'd give D strong consideration.

Take a look at D. It's basically C++ with a first class String object and garbage collection, plus a few other nice things borrowed from various languages. It's performance characteristics seem to be on par with C and C++, but it has most of the nice bits from Java and C# as well.

A good alternative to C is D: http://www.digitalmars.com/d/.

Ignore the 2.0 version for the while, it's alpha. Use the 1.0 which is pretty good stuff.