Python -> Java -> D ?

[Mike Parker]

Bill Baxter wrote:
> Chris Nicholson-Sauls wrote:
>> Kirk McDonald wrote:
>>> David Finlayson wrote:
>>>> I am a Python scripter in search of a language with better
>>>> performance. I do a lot of signal processing in my job and I think
>>>> I've pushed Python as far as it will go. Recently, I have written a
>>>> few programs in D and have been impressed with (a) how easy the
>>>> transition from Python has been, (2) the large boost in performance
>>>> for my code.
>>>>
>>>> Here's the question:
>>>>
>>>> Should my second language be a new language like D? Or, would I be
>>>> better off mastering something more mainstream such as C or C++?
>>>>
>>>> [...]
>>>
>>> Well, maybe I'm a little biased, but I think Python and D are a 
>>> potent combination. You could do worse.
>>>
>>> That said, you might do well by picking up a copy of K&R[1] and 
>>> learning C.  It is good to learn the low-level details of the 
>>> machine. Also, very nearly every library in existence speaks C; it is 
>>> the closest thing to a lingua franca in the programming world. And a 
>>> lot (but not all) of what you'd learn doing C would apply to D (not 
>>> to mention C++).
>>>
>>> [1] The C Programming Language, by Brian Kernighan and Dennis Ritchie
>>>
>>
>> I'll second that.  I started out with various flavors of BASIC (first 
>> was BASIC/1a on old Tandy machines), then later learned C in school.  
>> With a working knowledge of C in hand, I've found picking up nearly 
>> any other language rather straightforward -- even languages notably 
>> distant /from/ C.
> 
> I'm a K&R devotee too.  Short, sweet, and to the point.  I went from 
> self-taught BASIC to self-taught C via K&R without too much trouble. And 
> that was as a know-nothing college freshman.
> 
> If you're going to continue to use Python then knowing C will probably 
> be more valuable to you in the long run.  C is the lingua franca of all 
> popular operating systems today.  Any C++ APIs presented by the OS are 
> most likely wrappers around an underlying C API.  The Python API for 
> writing extension modules in native code is a C API.  And as you already 
> hinted you are much more likely to find working code that you can borrow 
> in C than you are in D.
> 
> But *after* you learn C then D is probably a great 2nd step.  D is 
> mostly a superset of C, so you more or less have to learn C as part of 
> learning D anyway.  D can also call C libraries directly.  So anything 
> you write or obtain that's written in C, can be used pretty easily from 
> D.  You need to translate the C header file to D, but you don't 
> generally need to write any new functions.
> 
> I think I can sum up my recommendations succinctly by saying
> 
>    "D comes after C"
> 


I throw my hat in with all of these guys. C is a great next step for 
you. One of the things I've always liked about C is that there are very 
few surprises behind the code you type and the compiled output. There 
are a few behaviors in the spec that are undefined and left up to the 
implementation, but for most of what you do things are consistent across 
platforms and compilers.

Since every language knows how to talk to it, a good grounding in C will 
often come in handy. You might need to revert to C to enhance 
performance (e.g., reimplementing a custom python module in C) or 
perhaps interface with legacy code (e.g., when using a more modern 
language like Java or D on a new project in a company that has an 
extensive C code base).

I also think that learning to work with manual memory management and how 
to avoid all of the associated pitfalls (buffer overruns, uninitialized 
variables, etc...) is a great education. It's good to have the big 
picture on why modern languages have so many safety nets built into the 
core.